A solution to assets management in Rails - <AUTHOR> https://rails-assets.org/

<comment><USER2> TL;DR -> Gem repo which automatically converts Bower packages to gems

Awesome! Was looking for something like this. I used to have a "vendorassets" directory where I could sanely manage 3rd party assets. Still a pain in the ass sometimes.

Rails-gems are usually out of date and everyone seems to jump the bower-ship.

</comment><comment><USER3> Just set bower to install into vendor/assets and link to those instead in your stylesheets/scripts. No need to add an additional layer of indirection and increasing the length of you Gemfile. Your bower.json should be where this information is stored, not you Gemfile.

<comment><USER4> How do you lock your bower dependencies then?

<comment><USER5> Bower deps are bound by semver; and if you're willing to commit them (which you should, if your project is a webapp and not a software library) then you can lock them w 100% certainty and control. /$.02

<comment><USER6> Why exactly should you be willing to commit them? There are certainly ways to lock your versions while still vendoring the files on deploy.

<comment><USER7> But the libraries you depend on may not work nicely together, minor versions for them could create breaking bugs in your app, and a ton of other things that can go wrong. The easiest way to put your app at the real working truth (no difference btween dev, prod, etc) is to commit your vendor files.

<comment><USER6> If you're relying on specific version releases of the libraries, you'll always be vendoring the same files (and if not the deploy should fail). If you are relying on a non-versioned release from a git repo, you can point to a particular commit hash in that library's repo. Neither of these requires checking your app's dependencies directly into its git repo.

Source control is not in itself a solution for dependency resolution. Sure, once your dependencies are worked out you can check them in, if you really want them hard-coded, but it shouldn't be necessary. Claiming so is a failure to understand how dependency resolution works -- part of the point of bower, or rubygems, or what have you, is knowing that you'll always get the same versions in all environments.

<comment><USER7> Yeah, sure buddy. I think you're just kind of a noob and are really not getting the whole picture yet. Google around for the debate, it's been thrown around for ages, or start here maybe.

[https://www.npmjs.org/doc/faq.html#Should-I-check-my- node_mo...](https://www.npmjs.org/doc/faq.html#Should-I-check-my-node_modules- folder-into-git)

<comment><USER6> I didn't realize we were talking about node here, so I suppose you're right. I'm a noob at node. Which of course is _ages_ old. _Way_ older than any of those other technologies I've been using for the past 15 years or so.

Sarcasm aside, I have to say I'm surprised at npm's best practices, but whatever. Personally, I'd rather not make my line count graph explode every time I add or remove a dependency. I still firmly believe that source control is not the only way to reliably vendor files.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Is there an equivalent to this in Python land (I've looked but not seen anything)? It'd be great to have "pip install bower-bootstrap".

<comment><USER9> Fanstatic is pretty close: [http://www.fanstatic.org/](http://www.fanstatic.org/)

</comment></comment><comment><USER10> Oh sweet. Looks like I don't have to put vendor assets code into my git repos anymore. Thanks rails-assets.org

<comment><USER11> That would tie your ability to deploy your code to the availability of rails- assets.org. How many nines are they promising you and how much are you paying for it?

<comment><USER12> You're totally right, we want to decentralize Rails Assets in some way.

On other hand we're pretty close to the uptime of GitHub and we're not going anywhere, so I would't worry too much.

</comment></comment></comment><comment><USER13> I don't get this.

It's not hard to download a JavaScript or css file and put them in app/assets.

What warrants the additional complexity?

<comment><USER6> It's not that hard, but do it 50 times, manually managing a complex dependency tree (which jQuery version does this thing need again?), and you'll realize how nice it would be to have a package manager for your client-side dependencies.

</comment></comment><comment><USER14> This is really neat but my problem with the asset pipeline hasn't been managing library dependencies but the general slowness of the process.

</comment><comment><USER15> What's wrong with just using Bower?

<comment><USER16> Check out [http://bower.io/](http://bower.io/) :

> Bower is a package manager for the web. It offers a generic, unopinionated > solution to the problem of front-end package management, while exposing the > package dependency model via an API that can be consumed by a more > opinionated build stack.

rails-assets is an example of a higher-level, more opinionated stack that adds value on top of bower.

<comment><USER17> You know sprockets includes bower support. Just add the path.

</comment></comment></comment><comment><USER18> (the wrong) solution to asset management in Rails

</comment><comment><USER19> That's pretty nifty.</comment>


[Osmf-talk] exit - <AUTHOR> https://lists.openstreetmap.org/pipermail/osmf-talk/2016-January/003655.html <comment><USER2> More descriptive title: Steve Coast Steps Down from Open Street Maps</comment>


Flat UI Elements Attract Less Attention and Cause Uncertainty - <AUTHOR> https://www.nngroup.com/articles/flat-ui-less-attention-cause-uncertainty/ <comment><USER3> Thank you, Lord! My prayers have been heard. I'm just happy that I am not the only one who got rants about the flat UI. It really should go away. The flat design was born from Microsoft Windows phone Metro UI, if I recall correctly, then other designers quickly jumped on the wagon and claiming it's the next greatest and neatest "UI revolution". What a joke! It totally sacrifices usability. The outcome? A horrible user experience, and job security for the designers.

Link to Flat design: [https://en.wikipedia.org/wiki/Flat_design](https://en.wikipedia.org/wiki/Flat_design) It was indeed first introduced by Microsoft with the name Metro Design.

Microsoft is moving away from the notorious Flat UI to Fluent Design: [http://www.firstpost.com/tech/news- analysis/build-2017-micro...](http://www.firstpost.com/tech/news- analysis/build-2017-microsoft-evolves-beyond-flat-ui-with-its-fluent-design- language-3702669.html)

<comment><USER4> I have always hated this fashion with passion too. For _me_ it makes UIs less aesthetically pleasing _and_ harder to use.

One of the reasons why I still use Windows 7 is that I like its 3D transparent glass-like look and utterly hate the flat design of later versions which I would call soulless and ugly. And the UI elements are harder to distinguish for me.

That being said, many people _do_ like it, and I am not aware of any studies about how many people like it / don't like / don't care in general.

Fortunately for us flat UI haters, that horrible design trend will go away the same way it came - as a fashion. Fashion by definition does not last. Sooner or later flat design will inevitability be considered old and unhip too.

<comment><USER5> Absolutely. I still stick with Windows 7 as well. I just can't stand the flatness, and the obnoxious amounts of space-wasting whitespace.

<comment><USER6> The whitespace is there because people design first for mobile, then port to desktop browsers as an afterthought. That's not going to change any time soon.

<comment><USER7> I remember a admin at a company giving me a before and after on some tool- where the fat-finger-friendly UI reduced the presented information and thus the usefulness off the tool to basically zero.

</comment></comment></comment></comment></comment><comment><USER8> Flat interfaces are nearly unusable for the seniors in my life. Below is a list of UX issues my live-in seniors have regularly, and that they DO NOT learn their way out of. Not specifically flat based, but these changes have been amplified by the flat/minimalist redesigns.

1.Icons are only useful for users that already know what they do. Zero value UX wise for new users. Labels matter, especially on mobile where hover is not an option. Having a "walkthrough" on first load is not a replacement. Also, non-native users do not know about hover tooltips, and they will not learn that behavior, they find them almost exclusively by accident.

2.Gradients on mobile, especially with power save, make apps and pages unreadable for everyone, but especially seniors.

3.Hamburgers and triple dots are not visual indicators for non-native mobile users.

4.Swipe is not an replacement for any UX process for non-native mobile users.

5.Canceling/backing out of any workflow is rarely obvious on flat/minimal designs. Seniors click/tap the wrong thing ALOT. Some giant percentage of their time is spent trying to reverse an action.

6.Zoom is king. Non-button looking buttons get even worse if you remove their context. Mouse over only context buttons might as well be invisible.

7.Seniors do not know what blue/purple/green text means. The underline is the only thing my seniors understand. Also, they click pictures, all pictures, because they are the only thing on these apps/pages that actually look like they are clickable.(see number 6 buttons)

<comment><USER9> Basically every day that I interact with users has this exchange:

"Click the hamburger icon to open the menu."

"Excuse me?"

"The three parallel lines; I agree, it makes zero sense, but now you know."

<comment><USER10> Maybe if you just say, "Click the menu icon in the corner."

<comment><USER9> "What menu icon?"

I've tried; three parallel lines in a flat UI do not indicate "menu" to a great many users; including myself, at one point in time.

<comment><USER10> Well, going forward I think it will be more commonly referred to as a menu icon rather than a hamburger icon. It's almost pervasive on phones now. Do you think the stacked dots are better than stacked lines? A mini-menu icon? It's helpful to have some small icon for the menu on mobile devices so it doesn't take up as much screen space. What is a better alternative?

<comment><USER9> Personally, I turn off icons in apps that allow me to, and stick with words. Mobile is sort of a user experience hell for me; touch screens just don't seem to work reliably.

</comment></comment></comment></comment></comment></comment><comment><USER11> Take a few minutes to look at their examples: [https://www.nngroup.com/articles/heatmap-visualizations- sign...](https://www.nngroup.com/articles/heatmap-visualizations-signifiers/)

Most of the "flat" designs strike me as being created or chosen to confirm the hypothesis.

Explain to me how adding an underline to a link is somehow not-flat? What UX designer would use a "ghost" style flat button for the main CTA? Etc.

The whole thing feels far from scientific.

<comment><USER12> Maybe they did choose things to confirm their hypothesis, but these aren't some mom and pop shops nobody recognizes, these are international well known brands - Hertz, Barnes and Noble, Nest etc...

If you read the entire article, you can see that the point was not Flat UI is bad, but rather Flat UI done bad can strongly hinder UX.

It makes no sense to just pick sites at random, you want to check the extremes so the evidence will be significant. To put it another way - you choose the most obvious candidates so that if you end up without a significant difference you can be positive that the hypothesis isn't correct. Following research can be more nuanced.

<comment><USER13> Right, they aren't "nobodies", they are a shop with a long history of creating biased experiments to validate their initial assumptions. There's a LOT of material available on the net regarding their "methods", a simple google search will do.

<comment><USER12> First, I'm pretty sure that's ad hominem.

Second, I said that it's probably ok that they chose the sites to validate their claims, saying they do that often isn't a counter argument.

Third, twisting my word so blatantly makes you look childish.

<comment><USER13> No, it's not ad hominem. It's me expressing my dislike of the Nielsen Norman Group. They have contributed to the state of the art but they also tend to overblow their claims - famously they said "people don't read on the internet" which is absurd, a slew of more serious research on the subject shows how reading and scanning patterns are not substantially different on screen or in the press, and that users on the internet tend to read MORE than people reading newspapers.

Not to mention the fact that we're interacting in a text only site...

Third, what I've done is not "twisting your words" but connecting to your reply using it as a jump off point. I don't remember the name of that rhetorical figure but it's pretty common.

All in all I don't think there's anything you should be taking personally unless you have some vested interest in the author of the article (haven't checked, are you the author?)

</comment></comment></comment></comment></comment><comment><USER14> Let's not confuse a lack of proper design hierachy with "flat UI". Actionable elements like buttons blending into the background do not signify "flat design" per se. Neither do purple non-underlined links vs. blue+underlined.

The title of this study isn't representative of the tests they actually ran. It falsely lumps together flat design and a terrible design hierarchy, which is expressed by the strategic use of contrast and color.

Further, some of the tests aren't representative of an argument for or against "flat" when they compare [a bright pink button with gradient and drop shadow] to [a white button with a light gray border], both on a mostly white page. Of course people will see a fat blob of pink faster than a faint gray-on-white, regardless of any drop shadows or gradient effects on either of those items. That's an absurd comparison if you want to make a point against "flat ui".

If you want to compare flat vs. non-flat, you better use the same pink button in both cases (or the same faint gray button) - once with and once without any effects such as drop shadows or gradients.

This study is very one-sided and merely confirms what any designer worth their salt already knows: you need to make actionable elements stand out from the rest of the content, plain and simple. Contrast is king, no matter if you're making a flat design devoid of any depth or if you're using drop shadows and rainbow gradients.

</comment><comment><USER15> Flat UI makes interfaces harder to figure out. Many examples here: [http://uxcritique.tumblr.com/](http://uxcritique.tumblr.com/)

<comment><USER5> Thank you, that was a nice read. Could use more examples from outside the apple ecosystem (Google is a goldmine in this regard).

</comment></comment><comment><USER16> I've always thought "flat" designs were created out some ideological belief in minimalism taken to an extreme. Their popularity born from a trendy departure of decades of UI and UX research. That form > function.

Let's learn, and continue making things for humans, not ideologies. That form should equal function, but only after it's passed UAT.

<comment><USER17> I think it was the influx of designers from print media, where bevels and gradient usage are generally considered crutches used by beginners who don't understand the fundamental aspects of design. Likewise whitespace is considered mana from the gods because it's in such short supply on the page.

Because there is now a strong connection between the two disciplines I'm less certain than most that this will simply be a fading trend.

I never had any trouble with flat design but I do have trouble with all the non-convention that arises out of app style design, which I feel is the real culprit of ux woes.

</comment></comment><comment><USER18> It's really not as difficult as it is being made.

This down to "what you need to do to make something stand out", which means sorting out the importance of elements and turning that into a hierarchy.

While there's no way to argue their results, there are plenty of reasons to argue their sampled materials.

Flat design doesn't mean turning a button into an outline. And I'm willing to bet the button would've performed just as well without the skuemorphic gradient, but WITH the solid background colour instead of becoming an outline.

Same with every single other implementation. They mis-implemented a design code.

To come back to my initial point; it's all about hierarchy. In any interface (wether on paper or on a screen) you need to direct a person's attention. This is done by visually prioritising elements. And there are a tonne of ways to do so. A gradient. An inverted colourscheme. An angle. A wording difference. A texture. Bold. Underline. Etc - I'm sure we could all go on for ages coming up with other ways.

 __TLDR: Disagree with their definition of "flat design", or the (exceedingly poor) way flat design was implemented in the examples they gave. __

<comment><USER18> Would love to hear what part of my reasoning rubbed you wrong, silent downvoter! We don't learn if we don't share!

</comment></comment><comment><USER19> Finally! Some recognition about how this whole craze is not working. I am always confused when using google material design pages . And grey text on white ... cmon! Just make it black on white

<comment><USER20> To be honest, real black on real white is horrible from a design/UX point of view.

<comment><USER21> For text? What are you talking about?

</comment></comment></comment><comment><USER12> I think the biggest take away from this research is that a bad non-flat UI can make a site look ugly but a bad Flat UI can hinder user experience.

Frankly, I think that's a pretty obvious insight, but there are a lot of people who don't see it that way, so this research has value.

It seems that the research is well thought out and executed, but it fails to create any meaningful advice for designers - hertz' example is just pure bad design even before the question of flat or non-flat UI, the other examples that proved significant are also glaringly bad design.

A further study should fixate on a single aspect (such as in text links or navigation menus) - which designers could take real input from.

</comment><comment><USER22> They're slapping flat elements onto a UI with a conventional layout. Of course usability will suffer. Flat signifiers rely on positional context and a well- defined set of familiar views/layouts.

</comment><comment><USER23> Flat UI hit the mainstream when John Ive forced it at Apple. But you noticed the timing, didn't you? The iPhone had beautiful skeuomorphic design, the doing of Steve Jobs. Jobs knew that 3D signals are important visual cues for the interface.

John Ive was only able to introduce flat design after Jobs died. Jobs hated flat design and wouldn't let Ive do it. Only after Job's passing was Ive able to go rogue and introduce the flat UI trend, which then everyone copied. The pendulum will swing again, but the damage has been done.

Obviously flat design looks worse, obviously it's harder to use. People follow Apple's design blindly. Jobs knew better, and Ive was only able to get away with it because he had more authority.

<comment><USER24> I thought Microsoft brought it to the mainstream and then everyone copied it: Apple, Google with material design.

</comment></comment><comment><USER25> Flat Interfaces: a brilliant example of Form over Substance.

Usually a well designed UI should be easy to use, with important functionality highlighted in some obvious and consistent way. A Flat UI has no redeeming features, possibly other than appealing to some sense of minimalism.

</comment><comment><USER26> Another thing that e-commerce sites probably are doing wrong? The "hamburger" icon on mobile for your product categories. Here's NN Group's video on the topic: [https://www.youtube.com/watch?v=rdeoPuPzONg](https://www.youtube.com/watch?v=rdeoPuPzONg) .

All these seemingly small design issues add up and before you know it, you're losing serious money because poor design kicks your your customers out of the conversion funnel.

Also, mad props to NN Group for their work on usability and making the web a more sane medium. Their people have been doing usability research for decades and Jakob Nielsen's UseIt.com used to be one of the most useful sites for web designers.

</comment><comment><USER27> Prediction: In the future Flat UI will be perceived similarly as bad retro "80s sci-fi" (like "Hackerman" from _Kung Fury_ wearing a dataglove, etc), in the same sense that it will only have a "nostalgia" aesthetic, not because it was any good.

Once we move past this madness, after a while we'll look back and see it for the unusable "mystery meat navigation" (remember that from the early 2000s web?) that it was. Trying too hard to look "clean".

In as far as Flat UI was usable, it's because of its ubiquity and that after a while we _had_ to get used to it and somehow managed to obtain a somewhat common UI vocabulary.

Like the "hamburger menu", completely unintuitive until you learn what it means. I'm afraid we're gonna be stuck with that one for a while. It was supposed to depict a super-stylized drop-down menu, right? Except that some menus are now a grid of icons.

... and in Chrome the menu is three vertical dots, because ummm it makes people turn their head while thinking "...", I guess. (I was looking at Firefox when I described the hamburger menu).

At least the gear-icon for config/settings makes some sense.

</comment><comment><USER28> Yeah, I think this all comes back to this article [1]. I am only irritated that every UI benefit of skuemorphism was ditched simply to reimagine what the UI could be when it's "authentically digital". Except for the fact that none of the users are authentically digital, nor are their needs.

People need landmarks, UI affordances and a clear mental model of what the UI should do. I understand and even agree with why Apple chose the route they did with iOS7+ and for the most part with how. But beyond font weight, it seemed like the other issues with the flat design were ignored because the company already chose a specific route (again, not disagreeing with that choice, but still affected and irritated by it).

And on a completely tangential point (I mention simply because the larger iPhone screen sizes came along, more or less, with the flat UI look), I also realize now that when it comes to phone sizes, Steve Jobs had it right the first time, and that bigger doesn't mean better. It just means a different set of tradeoffs. I've never been one to say that Apple, post-Steve, sucks. But I do think they've been far more responsive to the markets desires, for better and worse. Then again, I was rarely annoyed by the limitations of the iOS platform, so maybe I'm Mr. Stockholm Syndrome, I dunno. Nor do I care too much, TBH. I just want a phone with recognizable landmarks and that those landmarks be reachable with my ginormous hands on at least their smallest phone, without having to invoke a gesture to bring the screen to my thumb.

[1] [http://www.peterpetrovski.com/post/28032060238/the- authentic...](http://www.peterpetrovski.com/post/28032060238/the- authentically-digital-interface)

</comment><comment><USER29> "Since this experiment used targeted findability tasks, more time and effort spent looking around the page are not good"

Meanwhile we now (maybe) understand why sites like eBay are SO effective for selling - they may be clunkier to navigate but people maybe spend longer looking at them and subconsciously ingesting all the marketing messages whilst around to find something else on the page.

</comment><comment><USER30> Certain I'm the minority, but flat UI can be successful and very effective. With limited user paths and a design aesthetic that leans towards minimalism I have found that the user efficiently accomplishes the 'goals' assigned to them. However, if flat UI is treated as fashion often is (ignoring practicality, testing, and user metrics) then no doubt it will be unsuccessful. No research to refer you to, but I believe many major players in the industry adopted flat UI in an attempt to create a modern appealing look for their brand, and then went about optimizing the UI as they saw fit based upon user metrics and testing. As a designer I often continue to find myself influenced by pseudomorphic design and other formerly trendy design styles, but my goal is always to create something usable and unique rather than adhere to a current design trend. :D

</comment><comment><USER31> One quirk of Mac OS flat design - i can never find the "contacts" icon - <USER2> odd. This is one of the more skeumorphic designs still, too. I guess just the dull brown without much color, easy to overlook.

<comment><USER32> I'm intrigued; what's your use-case as to locating an application file by its icon? I never find myself doing this (Launchpad > "cont" > ENTER is my preferred route).

</comment></comment><comment><USER33> This research seems contrived at best. It compares strong coloured action element's to weakly coloured action element's. It just so happens that the element's on the weakly coloured version's are also using flat design. The major element here is colour.

The "research" is designed to give a certain result. If they wanted to test flat versus 3d, everything should be the same except for whether the elements are 3d or flat.

Flat design is not about using less colour to signify action. It is a lack of 3d and skeuomorphic design.

</comment><comment><USER34> I think flat UI and colorless design have their own artistic niche. I don't think they belong in the mainstream website business. If you want to go buy a flight ticket, you want to find your buttons! no questions asked. On the other hand, if you know that you're visiting a more experimental site, say from an artist of some sort. You should expect alternative solutions to UI.

<comment><USER3> Agree. Unfortunately, this experiment has gone mainstream for the wrong reason.

</comment></comment><comment><USER35> Can someone give a list of the most known 'Flat UI Elements' projects? Microsoft's Metro Design? Google's Material Design? some other javascript projects? Not a UX/UI designer and only knows bootstrap and some vue.js, polymer, not sure what 'Flat UI' really means in practice, and, what are its major alternatives?

<comment><USER36> Metro, Material, and iOS7 (after Ive took over software visual design) are probably the leading examples. Noteable that they all come from the top three brands in consumer tech.

Most of the conversation around flat has been removing all the superfluous ornamentation (shadows, reflections, 3D icons) from when UI designers were taking skeuomorphism too far. So if skeutomorphism was about how unnessarily photo-realistic we could make UI, flat design is an effort to simplfily... to see how minimal a UI can be.

Just like any pendulum swing, some UIs way overcorrected and lost a lot of the small UI affordances that helped make interfaces understandable. Aesthetic preferences aside, it IS harder to know what's a button when buttons are styled to have fewer visual differences from normal, unclickable text.

You'll see that the most recent interpretations likes Material or Windows 10th Annivesary seem to actually be bringing back some of the depth, layering, shadows and other visual cues.

The answer, like so many things, is "just enough and not too much".

<comment><USER35> Helps a lot. Thanks!

</comment></comment></comment><comment><USER37> > As long as in-line text links are presented in a contrasting color, users > will recognize their purpose, even without an underline

I saw that sentence, thought 'it would be most ironic if "presented in a contrasting color" was not actually a link' \--- but then was relieved to see that the text _is_ a link to another of their articles.

</comment><comment><USER38> Practical user experience design:

CEO: "Yeah, yeah, just go with the flat one." Lowly designer: "... yes."

</comment><comment><USER7> Why not have a design market instead of a top down aesthetic dictator?

Give me flat design with cascading style sheets and lets have a real competition here.

</comment><comment><USER39> Yeah but no. Common. This is just bad UX vs good UX. Know what your "call to actions" are and put emphasis on them. Design 101.

</comment><comment><USER40> I suspect it was done for money, which is main cause of minimalism these days (past 50 years or so). Flat elements and colorless icons are much cheaper to design than the alternative.

I personally find minimalism quite ugly. But it doesn't matter, because objectively, it's less expensive. It is also "predictably ugly". Less chance to make it really really ugly => better from the business perspective.

</comment><comment><USER41> yup, been saying that for years, previous iOS versions (i.e iOS 4) had faster user input than iOS 7-11. Same for material design, even Google started doing changes to make buttons more noticeable. I guess we will go back to 90's design :D Color differentiated HIG buttons!

</comment><comment><USER5> My, who could have guessed that making user interfaces where text is visually indistinguishable from clickables would make them harder to navigate... Next you're going to tell me the trend of pushing mobile interfaces to the desktop, or using obnoxious amounts of whitespace, is no good either!

<comment><USER42> Increased spacing around interactive elements is appreciated when you have to use the interface on a touchscreen device.

<comment><USER43> Or a mouse. I'm getting too old to enjoy playing the maze game with 20px nested drop-down menus or Operation with toolbars and razor-thin scrollbars.

<comment><USER44> Even the vote buttons on HN are a bit obnoxiously small for my non-mobile use. Touchpads are a thing.

</comment></comment></comment></comment><comment><USER45> IMO, Flat UI does work well on Mobile but this is not same for big screens.

</comment><comment><USER46> 'non-design' a better way of describing what's happening here

</comment><comment><USER46> So the design approach that lacks any theoretical support to begin with is less functional?

I hope too much effort wasn't wasted on the study but thanks for posting. I'm sick of this stuff.

</comment><comment><USER47> This study is significantly flawed.

It would be like attaching wings to a car, driving it down the highway, and then concluding that wings don't really help with speed.

Or another example would be be to take Pharrell's hat and placing it on some random person's head.

Context matters. Design is not the sum of its parts.

<comment><USER48> > This study is significantly flawed.

Is there a particular way you think it could be improved or do you just think that we shouldn't try to empirically compare something like flat vs non flat buttons?

<comment><USER47> I think these comparisons are silly because they are trying to find some blanket universal rule. What works most of the time might not work in your specific case.

[https://en.wikipedia.org/wiki/No_free_lunch_in_search_and_op...](https://en.wikipedia.org/wiki/No_free_lunch_in_search_and_optimization)

<comment><USER48> > I think these comparisons are silly because they are trying to find some > blanket universal rule.

Says who? The author goes into detail about what exactly they were measuring. The last two headings are "When Flat Designs Can Work" and "Limitations of the Study." Can you clarify exactly what you found "significantly flawed"? I don't get what you're trying to say by your wikipedia link.

> What works most of the time might not work in your specific case.

So what? Is it not worth knowing what works most of the time and under what assumptions?

</comment></comment></comment></comment><comment><USER49>
        **********
        * Button *
        **********

This button above submits the information. I can make it many different colors, go with flat design, or skeuomorphic.

If i test it long enough, one of the designs will be a clear winner. Even when i repeat the test, i may get the same winner, concluding that it is the best design to go with.

But in the end, it's not about the button. It's about the information i want the user to submit. If they filled up the form that came before it, the effect of design is minimal at most.

Edit: also in this day an age, I'll be totally happy with designs that don't attract attention, especially when people think the do.</comment>


Arc: A flat theme with transparent elements for GTK 3, GTK 2 and Gnome-Shell - <AUTHOR> https://github.com/horst3180/arc-theme <comment><USER2> This makes me want to buy a second laptop even more, just to run a Linux distro on.</comment>


How to SSH Properly - old-gregg https://gravitational.com/blog/how-to-ssh-properly/ <comment><AUTHOR> \- Use Ed25519 keys. They are now supported in pretty much every server out there (all recent OpenSSH versions, GitHub, GitLab, etc). RSA 2048 keys are unbreakable for the foreseeable future, and using 4096 bit keys are just being paranoid with no gain. You can fit 4x Ed25519 keys in a tweet.

\- Setup and use ssh-agent. They make the life so easy.

\- You can use Yubikey and pretty much every other solution out there with with OpenSSH now.

<comment><USER2> >Setup and use ssh-agent. They make the life so easy.

My #1 ssh usability tip: put this into ~/.ssh/config:

        AddKeysToAgent yes

It'll automatically add keys to your agent the first time you use them during a session, so you don't need a separate step for adding keys every time you log in.

<comment><USER3> > _It 'll automatically add keys to your agent the first time you use them > during a session_

If you have more than one private key in your agent, then SSH will try each one sequentially. That can lead to mistakenly getting banned by monitoring software for what can appear indistinguishable to be an authentication attack. Not to mention the _wrongness_ of presenting "any and all keys" to any host you connect to.

If you have multiple keys in your agent, you _really_ should manually configure what key to present using `-i` or `IdentityFile`. But you should also use `IdentitiesOnly` too.

<comment><USER4> > If you have multiple keys in your agent, you _really_ should manually > configure what key to present using `-i` or `IdentityFile`.

If you specify -i or IdentityFile, the agent isn't used at all. You will have to type the keyfile password even if the key is in the agent, therefore making the agent useless.

This "feature" has been a big annoyance for me, since I like to use different keys per machine.

<comment><USER5> There's no way that's true. I just checked and I have that option set on many of my ssh aliases, and ssh-agent functions exactly as expected.

Maybe it depends on version or something? I've had the same config for years though over several very different OSes and presumably versions of everything.

<comment><USER4> Wow, you're right. I tried again just now and it worked fine. In the past I tried for some time to get this setup working and was never able to do it. I don't know what I was doing wrong.

<comment><USER6> > If you specify -i or IdentityFile, the agent isn't used at all. You will > have to type the keyfile password even if the key is in the agent, therefore > making the agent useless.

I thought so as well, so the reply to this message surprised. I looked into it, and the following is the case on my Debian 18.04 machine running KDE:

With specifying the key through `IdentityFile` I can happily connect without a running ssh-agent. So it's true, that it can do without using the ssh-agent. But if the key has a password, it will prompt for it everytime it's used. I wouldn't phrase it "the agent isn't used at all", though, because for when ssh-agent is running, and it contains the key+password, it seems to happily use that agent, as it doesn't prompt for the password anymore.

Side note: If my understanding is correct, `IdentifyFile` lessens the need for consulting the ssh-agent as stated above, but, except from consulting it for the key password, the agent might be consulted for one more reason as well: Iterating over keys if using the specified one proved unfruitful. For this to stop, you'd have to specify `IdentitiesOnly yes` as well. But this I didn't test, so it's based on theoretical understanding only.

Edit: Oh, the last part was already explained in some other thread which branched of from this. So this post didn't actually provide some new insights, it seems.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The title of this doesn't properly match the contents. This is basically a how to set up an enterprise SSH environment using certificates. This doesn't tell you anything about "How to SSH Properly".

<comment><USER8> I almost thought so too and was itching to hit back and post an annoyed comment, but there are actually two more sections: using 2FA (straightforward TOTP branded by our favorite not-evil corp though I've not no idea what they've got to do with it) and setting up a jump host / bastion host.

So maybe the title shouldn't be "I like ssh certs" but "ssh security for organisations", but your point still stands.

<comment><USER9> > though I've not no idea what they've got to do with it)

It's the name of the TOTP PAM module they use, which was created by Google: [https://github.com/google/google-authenticator- libpam](https://github.com/google/google-authenticator-libpam)

</comment></comment></comment><comment><USER10> I like that with macos, you can create keys with a passphrase, and then that passphrase can be provided by the keychain which is unlocked at login

      ssh-keygen -t ed25519 -b 521 -f .ssh/id_foo_ed25519
      cat id_foo_ed25519.pub | ssh foo tee -a .ssh/authorized_keys
      ssh-add -K ~/.ssh/id_foo_ed25519

along with:

      Host foo
            HostName foo.bar
            User me
            StrictHostKeyChecking yes
            IdentitiesOnly yes
            IdentityFile ~/.ssh/id_foo_ed25519

<comment><USER11> This sounds really nice, this would be great to have for Linux or wsl...

<comment><USER12> Isn't this default behavior in Gnome? At least when using Fedora, Ubuntu or the more integrated distros. I'm pretty sure I used the fingerprint reader to access SSH with one of my keys on Fedora a few years back.

</comment></comment></comment><comment><USER13> As an alternative to ssh certs, we lookup keys in an LDAP Cluster. Each approach has pros/cons. SSH certificates are decentralized and resilient against failure, but revocation of a breached certificate isn't instantaneous. Keys-in-LDAP offers less resiliency, but offers instant key revocation. It's also simpler and offers a familiar experience to most devs.

The most important thing is to look at your attack surface realistically and plan accordingly. Just blinding putting in an SSH cert authority of an unsecured-non-redundant ldap cluster is worse than no key management at all.

<comment><USER14> 1) Programmatically issue certificates with short lifetimes after authenticating against your IdP. This way if a user is deactivated in LDAP their access will expire on its own after a few hours.

2) Firewall off all but a few bastion hosts and ProxyCommand through those. Immediate revocation can be assured by updating the CRLs on those specific hosts.

<comment><USER15> This is definitely the premise of what I was going for with the post. I'm a firm believer in the idea that short-lived certificates which expire by default are one of the best ways to provide access to infrastructure, and enforcing that access comes from a limited list of bastions gives you an easy choke point to withdraw access as desired when you need to.

<comment><USER16> Isn't there a netflix ssh CA that does this?

<comment> V-eHGsd_ yes, it's called bless.

[https://github.com/Netflix/bless](https://github.com/Netflix/bless)

there's also cashier

[https://github.com/nsheridan/cashier](https://github.com/nsheridan/cashier)

</comment></comment></comment></comment></comment><comment><USER17> All of this is done for you if you set up Hashicorp Vault. In case someone doesn't know, it provides secrets as a service that allows you to store and retrieve static secrets as well as dynamic secrets. The great thing about it is that you can set up authentication from multiple sources including EC2/GCE instances, LDAP and much more. But it also allows you to generate dynamic secrets including, but not limited to, SSH certs, IAM users, AD users, sql users and much more.

It's Hashicorps most mature tool and should be in everyone's toolchain.

<comment><USER18> Vault requires a non-trivial amount of setup and configuration, and then you need to configure SSHD to use it. You also have to maintain the vault server, HA, yada yada. And educate people on how to use it.

Vault truly shines in its ability to provide ephemeral credentials. It can even "package" arbitrary secrets for you, and ensure that they are only ever retrieved once.

It's a fantastic piece of software, one that more companies should be using, but it is not a push button deployment. It is borderline impossible to implement in many 'traditional' organizations.

<comment><USER19> > truly shines in its ability to provide ephemeral credentials. It can even > "package" arbitrary secrets for you

Those credentials should not be generated, stored or provided centrally in the first place.

</comment></comment></comment><comment><USER20> I've found it a good practice to add a YYYYMMDD serial number:

        -z 20200402

That way, keys generated within a certain time interval can be revoked with a simple serial number check.

</comment><comment><USER21> How is ssh certificates the next level up? Feels like the added complexity of using this is might be worthwhile for larger orgs but maybe not smaller shops

<comment> old-gregg Disclaimer: I work at Gravitational, one of our engineers is the author of the article. The added complexity is indeed significant, that's why we built Teleport [1] which is much, much simpler open source alternative to OpenSSH for such use case (the blog post does not mention Teleport because it was written for OpenSSH users).

But generally, certificates have a number of advantages: they expire quickly (you can have one-shot certs), they contain your full name, email address, or whatever you wish via metadata, this allows to implement RBAC on top of SSH. They address "trust on first use" issue, and they're easy to synchronize with other protocols, i.e. you can have the same CA issue certificates for both Kubernetes and SSH (with identical RBAC rules).

When implemented properly, they're actually easier to use. The whole world uses certificates to do online banking and shopping, there's no reason not to have the same seamless experience for SSH.

[1] [https://gravitational.com/teleport](https://gravitational.com/teleport)

<comment><USER22> btw, huge props for not mentioning teleport in that blog post. So many companies have blog posts that masquerade as tutorials for "how to do X" but then change halfway through to "OOOORRRR you can not do all that complicated stuff and just buy our product instead," which feels pretty scummy. Thanks for taking the high road.

<comment> old-gregg Thank you, Gaelan! I am not the author, but will pass this along to Gus.

</comment></comment></comment></comment><comment><USER23> One thing I find useful is to config default usernames.

You can do this by adding a line like below into ~/.ssh/config

Host alias domain.com HostName domain.com User aUser

This allows you to just write `ssh alias` and it will convert it to ssh firstname.lastname@example.com.

<comment><USER24> you can also specify which private key to present using

IdentifyFile /path/to/key/file

when I have different hosts that require different keys to access, this is very useful so I don't have to specify them every time

and agent forwarding is useful as well, for example, I can push to github from a vm using my laptop ssh key and I don't have to generate an additional key for the vm

ForwardAgent true

with the new Windows terminal, I setup different tabs to be SSH to different machines based on my .ssh/config file

{ "guid": "{1c9b268e-7606-4a07-b097-d8bc62fb5207}", "hidden": false, "name": "ubuntu.localdomain", "commandline": "ssh.exe me@ubuntu", "colorScheme": "Elementary" }, { "guid": "{b7161acc-8235-4283-9a85-e93df3d09125}", "hidden": false, "name": "db.localdomain", "commandline": "ssh.exe me@db", "colorScheme": "Ubuntu" },

Windows Terminal with a very nicely define ssh config is a killer combo.

<comment><USER3> If you have more than one private key in your agent, then SSH will try each one sequentially. That can lead to mistakenly getting banned by monitoring software for what can appear indistinguishable to be an authentication attack. Not to mention the _wrongness_ of presenting "any and all keys" to any host you connect to.

If you have multiple keys in your agent, you _really_ should manually configure what key to present using `-i` or `IdentityFile`. But you should also use `IdentitiesOnly` too.

<comment><USER24> thanks for the tips!

</comment></comment></comment></comment><comment><USER25> Is active MITM that much of a threat model item that running a whole SSH host key CA is the answer? I can't see that it is.

I thought this was going to be about Yubikeys or other HSMs.

<comment><USER26> It's not really MITM that's the issue. It's about maintaining access control for SSH access at scale. Once you have a big enough team, and especially if you store sensitive customer data, you generally want to start thinking about a system that can temporarily provision SSH access on demand so that nobody has standing access, at which point going through a CA and bastion servers is a canonical approach.

Exactly how big your team needs to be is a judgement call, but I think a reasonable threshold where you really should start thinking about CAs for SSH access is around where it's no longer possible for the dev ops people to be aware of what everyone who needs production access is working on.

<comment><USER25> I hadn't realized that this blog post is from the same people who make Teleport, which is a bastion/logging/access ssh proxy for solving exactly that problem. It seems to me that the linked article is probably just content marketing spam (much like Digital Ocean's extensive "how to install $x on a vps" posts) to boost the domain's pagerank/authoritativeness.

I still don't think people should be using SSH CAs for anything that isn't a short-lived, single-use bastion/proxy key. They're on the right track with Teleport; not so much with this standalone article.

<comment><USER27> Those how to install X on a VPS articles are requested by active customers, occasionally written by customers, and consumed far more often than you think by customers. DigitalOcean responded to Linode Library (as it was then called) when building that out, and having been somewhat involved in the development of Linode Library, I can assure you that neither SEO nor PageRank was near the top of the rationale list. Maybe tenth on the list as a nice bonus.

The people who worked on Linode Library in the beginning were engineers, not social media people nor content marketers. The person who wrote its first CMS is a former nuclear submariner and Perl guy with like nine followers on Twitter. I'm sure you imagine a huge meat grinder spam operation paying by the word, but basically one _engineer_ thanklessly wrote more than half of it in the beginning and went on to a distinguished career at 10gen/Mongo, not sitting on Mechanical Turk. I'd bet DO's operation is identical and exists for the same reasons, and they're just as proud of it as I am my extremely limited contributions to an offering that _objectively improves the operations discipline_.

It's annoying to watch valuable work that expands the profession get dunked on and called spam by a snide comment for absolutely no reason.

There's no reason to be so cynical about things in a hot take, particularly when it was an irrelevant shot in context. Not everyone is blessed with innate knowledge nor a gift for studying man pages, and those docs are useful checklists to make sure I didn't forget anything with common software like ntpd _to this day_ in my own, principal level, career. People learn Unix operations by buying a Linode. For a $10/month VPS you also get a bunch of tested, free guides that work on them and teach you how to do things. They're not paywalled to customers and show up in your Google results. I know. The abject horror is almost unbearable.

<comment><USER28> Well said. (Despite the final sentence's understandable but unnecessary parting shot.)

</comment></comment></comment></comment></comment><comment><USER29> With regards to using ssh-agent, this is what I have in my .bash_profile:

      export SSH_ENV=$HOME/.ssh/environment_${HOSTNAME}

      function start_agent {
           echo -n "Initialising new SSH agent... "
           touch ${SSH_ENV}
           chmod 600 ${SSH_ENV}
           /usr/bin/ssh-agent -s | sed 's/^echo/#echo/' > ${SSH_ENV}
           echo "succeeded."
           . ${SSH_ENV} > /dev/null
      }

      # Don't use Gnome keyring for SSH
      if [[ $SSH_AUTH_SOCK =~ /run/user ]]; then
        unset SSH_AUTH_SOCK
        unset SSH_AGENT_PID
      fi

      # Source SSH settings, if applicable
      ssh-add -l > /dev/null 2>&1
      if [ $? -eq 0 -o $? -eq 1 ]; then
          echo "SSH Agent found."
      else
          echo -n "Looking for SSH Agent... "
          if [ -f "${SSH_ENV}" ]; then
              . ${SSH_ENV} > /dev/null
              ssh-add -l > /dev/null 2>&1
              if [ $? -eq 0 -o $? -eq 1 ]; then
                  echo "found pid: ${SSH_AGENT_PID}."
              else
                  echo "not found."
                  start_agent;
              fi
          else
              start_agent;
          fi
          ssh-add -l
      fi

This starts up a new ssh-agent if it can't find one, but uses the same agent if it is already running on this machine (I remote into a bunch of systems). So even if I use a bunch of screen sessions, or remote in to a machine multiple times, it will always try to use the same agent.

<comment><USER30> Have you considered using [https://github.com/funtoo/keychain](https://github.com/funtoo/keychain)?

Edit: I see it's been mentioned elsewhere here.

<comment><USER29> Well, that's interesting. And a _whole_ bunch of code. From a quick skim, it is basically solving the same problem in a different style.

I didn't want or need to wrap ssh-agent. I'm fine with using it and ssh-add by themselves. I just wanted to automatically find and re-use an existing agent rather than spawning a new one.

</comment></comment></comment><comment><USER31> It seems weird there wasn't more emphasis on the implications of running your own CA. I can imagine lots of people coming across this article and doing a quick copy pasta not realizing what just happened.

</comment><comment><USER32> There are a number of turnkey solutions for this. One is ScaleFT[1]. My company is another: StrongDM[2]. Our product also keeps audit logs for compliance.

[1] [https://www.scaleft.com/](https://www.scaleft.com/)

[2] [https://www.strongdm.com/](https://www.strongdm.com/)

<comment> old-gregg [https://gravitational.com/teleport](https://gravitational.com/teleport)

Free and open source, made by the authors of the article.

<comment><USER33> > _... made by the authors of the article._

And, just so everyone is clear, your employer.

</comment></comment></comment><comment><USER34> More fitting to the title would be this page: [https://infosec.mozilla.org/guidelines/openssh](https://infosec.mozilla.org/guidelines/openssh)

It's a nice practical guideline with all the basics covered.

</comment><comment><USER35> On a related topic, what is the current best practice for avoiding TOFU for cloud providers? Sure, SSH certificates provide that for normal users, but how does the SSH CA know — ideally in an automated fashion — what that public key is? An admin can SSH into the machine to check it, but then he has to trust the key he sees. He could access it via the console, but that is a manual process. All the other approaches I can think of involve generating at least one key outside the machine which uses it, which seems like a poor solution.

<comment><USER36> At least on AWS, you can parse the System Console Output. On the first boot, the box dumps its pub keys there. We have a tool that parses the output:

[https://github.com/bitnomial/aws- ec2-knownhosts](https://github.com/bitnomial/aws-ec2-knownhosts)

Right now, this is pretty specific to our use of it, specifically our use with Terraform EC2 instances. We'd happily suggest changes to make it more generic. But you can see the parsing logic there.

</comment></comment><comment><USER37> On AWS you can use SSM Session Manager and gain secure shell access to instances without using SSH at all. As long as the instance has the SSM Agent on it and network connectivity to the SSM API, it just works: [https://docs.aws.amazon.com/systems- manager/latest/userguide...](https://docs.aws.amazon.com/systems- manager/latest/userguide/session-manager.html)

(Disclaimer: I work for AWS, but opinions are my own and not necessarily those of my employer.)

<comment><USER38> Does it work with the `ssh(1)` client? I'd be okay with using this as long as it replaced _only_ the network-connectivity and authentication parts. I do use many of the other features made possible by SSH:

1\. Network forwarding (local-to-remote, remote-to-local, dynamic, and unix socket support). The link you supplied mentions only local-to-remote.

2\. Agent-forwarding (don't worry, I have confirmation-on-every-use, see my other comment: [https://news.ycombinator.com/item?id=22753590](https://news.ycombinator.com/item?id=22753590)). This I use all the time to be able to authenticate to other SSH servers and git hosts. This is a must-have for me now for remote development and pair- programming.

3\. sshfs, sftp, and rsync. Again, absolute beauties at the job of managing files remotely.

This is just off the top of my head, because I use these features day-to-day, but there's many other nice things ssh does that have nothing to do with the underlying connection or authentication method.

<comment><USER39> Agent forwarding is powerful but dangerous. Prefer ProxyJump where applicable.

With Agent forwarding any authorised machine you connect to (and thus anyone who controls that machine) gets to use your credentials for the duration, to my knowledge no general purpose clients give you feedback on this usage, so you won't know if this happened - if Agent forwarding is enabled it can be used even if you never use it. With ProxyJump the intermediate doesn't get any view of your credentials, not even whether those are the same credentials you used for that intermediate host, or different. It is only enabling you to connect to a host it can reach that you can't reach directly and nothing more.

<comment><USER38> > ... to my knowledge no general purpose clients give you feedback on this > usage, so you won't know if this happened

I'm afraid you're mistaken here.

ssh-add(1) and ssh-askpass(1) support confirmation per-use: [https://man.openbsd.org/ssh-add.1#c](https://man.openbsd.org/ssh-add.1#c)

The agent I personally use — gpg-agent — also respects this protocol and asks me to confirm each use: [https://www.gnupg.org/documentation/manuals/gnupg/Agent- Conf...](https://www.gnupg.org/documentation/manuals/gnupg/Agent- Configuration.html#index-sshcontrol)

Even if it did not, I can always configure gpg-agent to never cache the passphrase, thus making it ask me for the passphrase every time. This would also adequately serve as a means of confirmation, but thankfully this tedious option is not necessary, because of the above.

> Prefer ProxyJump where applicable.

I already do, but it's pretty orthogonal to agent-forwarding. The uses of agent-forwarding I mention in my original comment simply cannot be served by ProxyJump.

<comment><USER39> Today I Learned. Seems like a key component (AddKeysToAgent Confirm) was in OpenSSH 7.2 in 2016, but I felt like I checked this wasn't an option more recently. Happy to be proven wrong, thank you.

</comment></comment></comment></comment></comment><comment><USER40> Assuming RSA keys are being used for compatibility?

<comment><USER41> Wanted to ask the same. A lot of tutorials still use RSA but I see no reason to use it in 2020. ECDSA keys are supported since an OpenSSL version from 2013.

<comment><USER42> I still use RSA mainly because Yubikey doesn't support them yet with OpenPGP keys.. I felt the increase in security usage was a worthy compromise to using RSA with a key length that's not yet broken.

I think Fido2 mode does support it but I don't know whether I trust Fido2 fully for SSH.. Especially because it seems to still store a private key locally, which defeats the whole purpose of using a hardware key (I saw this here: [https://developers.yubico.com/SSH/](https://developers.yubico.com/SSH/) ). The whole idea is to not have the private key anywhere but inside the token itself. It's also a bit early in development where RSA has proven itself. It has some known weaknesses (including high quantum computing vulnerability) but they're well understood.

<comment><USER39> No, the FIDO OpenSSH support doesn't really store a private key "locally" but I can see why it's confusing. I'll explain.

FIDO was conceived for the Web, and so the SSH authentication model wasn't a core consideration in its design.

In SSH authentication always goes like this:

Client: "I can prove I'm Alice because I can do X" Server: "OK, do X" Client: (Proves they are Alice by doing X)

OR

Client: "I can prove I'm Alice because I can do X" Server: "Not good enough. What else?" (Repeat with a different method or give up)

Whereas WebAuthn (and U2F and other models FIDO was proposed for) have authentication go like this:

Server: Prove you are Alice, if you are you can do Y or Z Client: (Does Z)

In FIDO there's a magic "cookie" used, in theory this could be just a "serial number" for a credential, but in reality for a typical FIDO dongle (such as Yubico's Yubikey) it's actually your private key for that site, encrypted using a symmetric key known only to that Yubikey. This way your Yubikey can unlock a genuinely unlimited number of sites, each with completely fresh credentials that can't be correlated, without infinite flash storage. A site says "Here's that cookie you gave me, now prove you're GekkePrutser" and your Yubikey consumes the cookie, decrypts it to get a private key, then uses that private key to prove you're GekkePrutser.

But as we saw in SSH the authentication doesn't happen in that order. The Security Key needs the cookie first, but the remote server is waiting to hear how you'll prove who you are first, it's a stalemate.

To break the stalemate the cookie is stored on your local system, so that can be fed to the Security Key, and then things can proceed.

Down the road apparently the OpenSSH team will add support for FIDO2's "usernameless" behaviour which doesn't need a cookie but does consume limited resources on the Yubikey. If you just can't accept the idea of storing the opaque cookie value because you know it has your private key encrypted inside it, then that mode will suit. It's also useful for "road warriors" who are willing to trust other people's computers briefly but don't carry their own. But that isn't finished today and it seems they don't expect it to be the usual way this is used, since it requires a FIDO2 (not just FIDO) Security Key.

</comment></comment></comment></comment><comment><USER43> Somewhat off-topic, but I've noticed that ssh-keygen is _much_ faster at generating key pairs that GnuPG, due to the latter wanting more "proper" entropy.

Does that mean that GnuPG is overly paranoid? Or ssh-keygen's keys potentially insecure? (I really hope not). There must be some good explanation for this huge speed difference.

<comment><USER8> The difference must be urandom vs random. You'll find a lot of words spent arguing the misinformed vs the enlightened if you look for those terms, on HN or elsewhere. I'm in the urandom camp and think that's the only thing that makes sense on the condition that it blocks/errors until seeded properly once, which means so much as that gpg is misinformedly paranoid in my opinion and that if ssh keygen had been insecure it would have been fixed long ago, but do read up and form your own opinion.

<comment><USER44> I don't think it's urandom v random.

It really just waits longer.

</comment></comment></comment><comment><USER45> Host certificates are fine, but user certs are pointless landmines when features like AuthorizedKeysCommand exist. why worry about revocations, expiries and all that noise when you can simply have some script just pull the allowed keys? sure maybe login is a bit slower, but does that matter much?

<comment><USER15> Don't get me wrong, using AuthorizedKeysCommand is a lot better than having a static ~/.ssh/authorized_keys file on a server, but it isn't anything like as powerful as using user certificates.

Certificates can do a lot more than authorized keys can, like enforcing the use of specific principals, commands and options and embedding that information into the file itself without needing to modify each server's SSH configuration. They're also self-contained and will still work in situations where some external service providing a list of keys goes down. I've been on the rough side of a huge LDAP outage which prevented necessary access to the infrastructure to fix it, and it was a horrible experience. There's none of that problem with certificates as long as you make sure you have one which is currently valid.

I'm also generally of the opinion that it's safer to enforce the use of authentication which expires by default rather than relying on some external process to do that for you.

<comment><USER46> But AuthorizedKeysCommand and certs are at least equally powerful because they're both ways of specifying the content of the same authorized_keys file.

<comment><USER15> It's something of an implementation detail - you don't generally specify the usage of certs on a user-by-user level, you do it by trusting the entire CA in /etc/ssh/sshd_config and then using the signed content of the individual cert (expiry date, principals etc) to dictate whether someone should be allowed to get access or not.

Look at it in terms of building in a decision at compile-time rather than at runtime. With AuthorizedKeysCommand, you're running something just-in-time on an SSH login to determine whether something should be allowed to proceed. With a CA and a process for issuing certificates, that decision is made at the time the cert is issued and then the cert is good for the duration it's issued for. It's entirely self-contained as sshd itself is making the decision about whether the cert is within its validity period or not.

It's obviously a decision that people can make based on their own infrastructure, but my opinion is that the compile-time model is more reliable as it's a fully self-contained system and doesn't rely on an entire fleet of servers being able to connect back to an external service at runtime to determine whether you should be allowed to log in. That sort of thing invariably comes back to bite you when you really _need_ to be able to log in and you can't because the external service is down.

</comment></comment></comment></comment><comment><USER47> Slightly off topic but the author recommends expiry periods for certificates. Other than rotating a key because of compromise, this seems unnecessary. We've finally decided that passwords should no longer be mandatory rotated, why should certificates?

<comment><USER48> How do you revoke access if the certificate has no expiry?

<comment><USER47> Forgive my ignorance but what's the correlation between expiry and revoking? I'd assume there are several reasons you'd want to revoke a certificate such as it's been compromised. How would it's expiry date help that?

<comment><USER15> Author here. My take on this is that fail-closed is a vastly better security model than fail-open. I am genuinely surprised that OpenSSH actually issues certificates with no expiry date as a default.

If you have a certificate which expires within a day by default then an unsuccessful revocation is no longer a huge cause of stress. In the worst case, you lock down access to your bastions and disallow the issue of any future certificates for that user. Within a day, any potential threat from that certificate has vanished. This seems preferable to having a mandatory requirement of an up-to-date revocation database which is synced everywhere.

<comment><USER47> Just to make sure I understand your example, for users who require regular access you re-issue certificates daily? I could see that being useful for a "one off" type thing (i.e. you want to temporarily grant access for one day) but how does that help regular users?

I'm also not sure it's easier to "lock down access to your bastions" and wait out the certificate expiration instead of having a certificate revocation database. Although OpenSSH does not provide a mechanism to distribute the revocation list it seems trivial to add a certificate to the revocation list and distribute it in an automated fashion.

Lastly, since you have to both lock down hosts and wait out the expiration, does that not constitute a fail-open system? I really don't think an expiration date mechanism makes this a fail closed system. Either method requires manual intervention upon compromise.

<comment><USER15> Yes, even for very regular users I would recommend setting up a process requiring users to get a new certificate on a daily basis with a short validity period. You can automate a lot of this and make it a simple one- command process to get a new certificate - even something like a simple shell script called by ProxyCommand is a good habit to get into. In bigger organisations you'd likely want to centralise this process somehow or institute other tooling.

The overarching reason isn't really a question of "helping users" as such, although I would strongly encourage making the certificate issuing process as quick and easy as possible to encourage adoption and reduce pushback. The people it really helps are security teams and organisations as a whole who can now have more confidence that they haven't left holes in their infrastructure which can be exploited by bad actors. It also checks a lot of boxes for auditing, compliance and reporting purposes which are huge positives in a corporate environment. If you're able to say "yes, disgruntled former employee X had a certificate that would have given them access to all these servers, but it expired three days ago" then that's a lot better than saying "X has a certificate that gives them access to all our servers, but we _think_ we've blocked it from being used everywhere".

Overall, I agree that the model does lend itself better to things like access to critical production infrastructure (where access should be the exception rather than the rule), but in my opinion it's a good practice to get into for access to everything. The ability to log that a certain user requested a certificate at a certain time and then link that to exactly where the certificate was used (via centralised logging, for example) is incredibly powerful.

You're perhaps correct that both do constitute fail-open systems at first. The difference is in the vulnerability period - with an expiring certificate, that ends at a fixed point in the future. With a certificate that has no expiry, that period never ends until such time as you rotate your CA and force everyone to get a new certificate - something which is also far less of a burden when your certificates expire every day by default and you have a process for getting a new one, incidentally.

<comment><USER47> I appreciate your detailed response but I think we'll just have to agree to disagree here. My personal opinion is that there isn't any value in this arbitrary temporal benchmark for certificates expiring. When a certificate is compromised, or needs to be revoked, it needs to be revoked immediately. At that point, your trusting the same mechanisms to remove access in either system. An auditor is going to be interested in the period between the user having access and that access being revoked. The fact that the key expires later on (even within just hours) is irreverent, as it's after revocation and it's already invalid. Anything less provides the bad actor with plenty of time to do something malicious. The example you give in quotes would be immediately followed with "Okay, but how did you disable that access immediately?"

You could make keys valid for only a minute and it wouldn't add any security, as only seconds are needed for a malicious action to take place.

</comment></comment></comment></comment></comment></comment></comment><comment><USER49> This is perfect timing as I just wrote this tool to help sign ssh host keys and user keys. [https://github.com/GRMrGecko/ssh- cert](https://github.com/GRMrGecko/ssh-cert)

</comment><comment><USER50> Is there a way to set up 2 ways auth with andOTP instead of the google auth?

</comment><comment><USER51> what's your opinion of using epass2003/pkcs11 for ssh?

[https://stuff.purdon.ca/?page_id=70](https://stuff.purdon.ca/?page_id=70)

[https://sigg-iten.ch/learningbits/2014/11/13/first-steps- wit...](https://sigg-iten.ch/learningbits/2014/11/13/first-steps-with-the- feitian-epass2003-smart-token-in-os-x/)

<comment><USER33> Oh wow, I had forgotten all about the ePass2003.

I've still got one here, but it's probably been 10 years since I've used it. I haven't forgotten how much of a PITA it was to get it working, though!

</comment></comment><comment><USER52> Just update and use Use Ed25519 keys

resource of how to: [http://wolf-tm.com](http://wolf-tm.com)

</comment><comment><USER53> It's a long article written on April 1st. Please, don't say it's an april's fool joke.</comment>


Computer memory that can store about 1TB on device the size of a postage stamp - <AUTHOR> http://www.kurzweilai.net/rices-silicon-oxide-memories-catch-manufacturers-eye

<comment><USER2> The Popular Science article referenced suggests we should start to see products with RRAM coming out in 2015, and we should see existing flash product supplanted by 2017.

Anybody in the Flash Memory Industry know if it's really that close?

<comment><USER3> Currently only HP has something that appears to be working, and they are unwilling to be a commodity manufacturer. HP announced The Machine as the only way to get your hands on a computer with memristors (someday, if/when tehy finally ship it).

Basically HP knows they are sitting on something big, and so they want to build whole mainframes based on it, like its 1970 again.

<comment><USER4> Wouldn't the consumer market be a bigger money maker for them? If not, do you know why?

<comment><USER3> -razor thin margins outside of server room

-pride

-if they deliver, they could take over whole industry, at least for a few years, ala IBM 5150

</comment></comment></comment></comment><comment><USER5> That is an interesting result, normally conduction paths in your dielectric mean your capacitor is dead :-) I look forward to seeing the first commercial implementations of this technology.

<comment><USER6> According to the original 2010 announcement (1), that's exactly why the phenomenon went unexploited for so long:

"Most people, when they saw this effect, would say, 'Oh, we had silicon-oxide breakdown,' and they throw it out,... It was just sitting there waiting to be exploited."

It's so simple it sounds too good to be true. Two terminals (not three), dielectric in between. High voltage to write (create/destroy the conduction path), low to read (at least the way I understood it). This thing can be stacked in 3D without a problem.

(1) [http://news.rice.edu/2010/09/01/nanocrystal-conductors- could...](http://news.rice.edu/2010/09/01/nanocrystal-conductors-could-lead- to-massive-robust-3-d-storage/)

</comment></comment><comment><USER7> if this actually does come to market in or around 2015, would it be feasible to replace sql databases with blazing fast redis databases entirely?

<comment><USER8> Or blazing fast sql databases? Those are two technologies solving rather different problems, I'm not sure how the underlying storage is going to affect things very much.

<comment><USER9> Redis is so fast because it sits in memory, sql relies heavily on hard disk

<comment><USER10> Getting good relational DB schemas on REDIS is hard (read: not designed for that). It's mostly for flat data.

</comment></comment></comment></comment><comment><USER11> Coming soon, in 10-15 years...

</comment><comment><USER12> Color me excited when we have similar sized batteries that can power smartphones for a week.

<comment><USER13> Or regular sized batteries that can power smartphones for a month.

<comment><USER2> Or any battery that will last a full day on my damn iPhone.

<comment><USER14> OT, but I'd GLADLY trade 2-5mm of phone thickness for a longer-lasting battery; one that can still make it through a long day of heavy usage in a city with lots of interference to power over after the phone is a year old.

<comment><USER2> That's kind of the idea behind the Mophie - it's ironic that Apple goes to all the trouble to shave off some thickness, and as a result, everyone has to connect huge honking plastic shells with spare batteries to them..

<comment><USER15> The point on apple pushing thinness is often put forward as pure design decision, but I am more and more convinced the manufacturing costs might have at least an equal part.

Battery is the same on every model, and bumping the battery amount would force them to split the line in two models, which would need a separate fabrication line just for the bigger model, or have a cheap one with the same amount of battery, wich would significantly bump the entry model price.

</comment></comment></comment></comment></comment></comment><comment><USER16> So how much is a postage stamp in terms of real size? Because I can think of many different sizes. Also, 1TB is kind of vague, they should've given the size in Libraries of Congress.

[https://xkcd.com/1257/](https://xkcd.com/1257/)

<comment><USER16> Also, eight 128GB MicroSD cards are a large-ish postage stamp size, too.</comment></comment>


Show HN: Awesome rent search website in the UK - <AUTHOR> http://cravify.com/rent

<comment><USER2> I looked for a flat in London twice in the past year so I've felt the pain and would love to find something that makes the process easier. I'm not sure you're addressing the true pain points though.

What I found to be truly nightmarish when looking for a flat was:

1) The immense majority of flats listed on rental sites (either aggregators or the letting agencies sites) are either scams, have already been rented or are just baits that letting agencies publish just to get you to ring them so that they can try to sell you the flats they actually have available.

The result if that pretty much all the online rental listing websites and apps are nothing more than a spectacular waste of time as every time you find something that looks decent, it's either already gone, it's a scam or it was never available in the first place.

2) In a place like London, the rent is only one part of what a flat costs you. Council tax, charges and agency fees are massive and can easily add 20%-40% to the cost of your flat. And these charges can vary a lot from one place to another. Yet, no site ever displays the _total_ cost of a flat. This makes it really hard to compare flats.

To address the first point, I always thought that charging _both_ landlords to advertise and tenant to look for flats would cut a lot of the crap. Landlords should only be able to advertise for a maximum of 3 days (they could pay again to extend for another 3 days). Since tenants have to pay to see the listings, landlords shouldn't get harassed by time wasters. Having to pay to advertise should hopefully keep the scammers at bay. And since landlords have to make the effort to renew and pay every 3 days, it should hopefully reduce the amount of flat still listed but already gone.

Of course, it's likely that scammers and letting agencies would quickly find a way around this - but it'd be worth trying. Might not be your space right now since you seem to be focusing on aggregating from existing sites. But if you want to add real value, I really think you need to re-think the way rental sites operate.

(as a side note, the only rental site in London I've found not to be a big fat waste of time is <http://london.spareroom.co.uk/> \- pay for access to the latest listings and you generally find genuine and good offers that are still available. And it's not just rooms in shared houses - there are actually quite a lot of flats to rent there as well)

<comment><AUTHOR> Dear MehdiEG, thanks a bunch for pointing them out.

1) We are indeed trying to solve this problem, our approach is collaboration amongst house hunters. Users who found scam/expired properties can report them, then other won't find it. We also intend to integrate AI in this problem. Pls Keep an eye on this ;)

<comment><USER2> If you can fix this problem, you've got a goldmine in your hands. Never mind the map, simply knowing that the flats you're looking at are actually real would completely change the experience (the map is very handy though - keep it of course).

<comment><AUTHOR> I think you nailed it. Definitely the way to go.

</comment></comment></comment></comment><comment><USER3> @MehdiEG

1 - There are two main reasons why listings are kept online even if they are already taken. Firstly, agencies purposely keep listings on so that they can occupy a slightly larger search percentage on property sites. I believe by law they can continue advertising a property for a further two weeks after being taken.

The second reason is that when you look at the supply chain of how listings get onto a property site - you can see why listings are often already taken, especially in highly populated areas such as London. An agent has their own website to manage - you can bet they update it with new listings daily but do they remove old listings at the same time? Those listings are then pushed to property portals via the software provider in a feed. Usually it will take at least 24 hours until those listings go live on the property portal, which in many cases may already be too late.

2 - In the UK, if you rent through an agency you should expect to pay extra on top. Usually the agency fee covers things like credit/reference checks and prevents time wasters. Imagine if there were no fees and I called up three agencies and told them I wanted to take each property. Then all three removed the listings from their site/property portal - I'm only going to take one property, so two agencies would have their time wasted, maybe all three if I decided I didn't want any of them.

Whilst it is annoying for us to call up for a listing that is advertised as available only to find it has already been taken, I think if we look from both sides it becomes more apparent why it happens. In terms of the "extra" costs, it all boils down to data quality. Even if the option was available for agents to indicate their "extra" costs, I can guarantee most would not use it. If they were forced to use it, most would provide inaccurate data.

My advice to you, is find a property website that you like searching on. The quality of data (as in the listings) all boils down to the source, the agencies, and nothing can be done about it. The only thing property sites can do is to ensure they keep their site as up to date as possible from the feeds (sometimes low quality) they receive.

<comment><USER4> Agency fees are outright illegal in Scotland, although many agencies charge them anyway, hoping people won't challenge them.

There's currently a campaign to raise awareness on this.

<http://www.reclaimyourfees.com/>

</comment></comment><comment><USER5> I made something that looks a bit similar a year ago using Gumtree data: <http://www.live-there.co.uk/>

All the data is now outdated however since there didn't seem to be anything to gain from putting any more work to it (and I would prefer to avoid web development stuff...).

<comment><AUTHOR> it's more of the backend work than frontend thou :).

</comment></comment><comment><USER6> This is really useful, and seems to give better results than PadMapper.

One thing though: I get an error "Ad detail not available at this zoom level" when I zoom out too much, which is somewhat annoying.

Edit: it would also be nice if it saved your search preferences between sessions.

<comment><AUTHOR> yeah because the site is under heavy traffic at the moment, we shall upgrade the server with more CPU to handle this, but not right now.

Saved search reference is now in the plan :). Thanks.

</comment></comment><comment><USER7> Really cool site - my only (minor) criticism would be that the sliders for number of bedrooms let you select (approximately) 1.3 bedrooms, etc. Would be nice if they 'snapped' to 1/2/3... Other than that, very useful!

<comment><AUTHOR> ah ha, 1.3 is actually 1 :D, some people prefer a smooth transition (like me :D), so this will be taken into consideration.

<comment><USER7> Fair enough, I think it's personal preference like you said. Perhaps being able to choose a range would be good too.. recently I was looking for a 1 or 2 bed.

</comment></comment></comment><comment><USER8> Really cool! Can I suggest allowing £/month as an option? Most places in Manchester rent by the month, so seeing prices displayed as a weekly value makes the rent a bit harder to quickly get a sense of.

<comment><AUTHOR> sure, this is in the plan.

</comment></comment><comment><USER9> Wish I'd had this a few months back, found a number of suitable-looking properties on there that weren't shown on sites like Rightmove.

<comment><AUTHOR> yeah because we aggregate data from many different sources like Rightmove, gumtree, oodle, foxton, zoopla, etc, it reasonably has more properties.

<comment><USER10> Please don't aggregate Foxtons. They are utter asshats and half their properties don't exist.

<comment> adam-_- From my experience this is true of ALL rental agents.

<comment><USER10> Perhaps someone needs to get rid of them...

<comment><AUTHOR> Our approach is collaboration filtering amongst house hunters + machine learning. Keep an eye on this ;).

</comment></comment></comment></comment></comment></comment><comment><USER11> I am doing this too in Brazil... we are going to launch soon, but or idea is a bit different.

<comment><AUTHOR> Hope you all the best :)

</comment></comment><comment><USER12> great to see anything that helps finding property in London easier. Any reason you're only showing flats and not including houses as well? I'd imagine once you go outside zone 2 houses will be in the majority.

<comment><AUTHOR> Hi, Flat for rent/Flat for share is indeed just the category name, info of houses are included in the database too. I reckon this is too misleading, and should be changed soon.

</comment></comment><comment><USER13> Good Website

</comment><comment><AUTHOR> DEAR ALL, Please vote up so that more people know about Cravify. Thanks a bunch.</comment>


The Core of Every Great Product. (Hint: Its not the Idea) - <AUTHOR> http://thestartupcentre.posterous.com/the-core-of-every-great-product

<comment><USER2> It's never just one thing or the other but understanding your domain is a necessity and years of experience counts for a lot. Also, the first guy out often ends up with arrows in his back, something I learned from the first couple of startups I worked for.

<comment><AUTHOR> Absolutely. There is a lot of glamour with first mover advantage, but in today's world where iteration is what differentiates the survivor, the first mover has a hefty price to pay. That's another thought.</comment></comment>