Don't Get Clever with Login Forms - <AUTHOR> http://bradfrost.com/blog/post/dont-get-clever-with-login-forms/ <comment><USER2> Another rule: make all fields pastable. If you have a form I can't fill in with my password manager, I can copy and paste my username and password with my password manager. Unless... you make those fields so I can't paste into them. Then, I have to open two windows side by side and manually type in my 16 digit password with caps, numbers, and symbols. Tedious.

<comment><USER3> I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.

<comment><USER4> > Don't break the back button.

Can someone please tell SAP?

<comment><USER5> Add it to the giant list of suck.

</comment></comment></comment></comment><comment><USER6> There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

<comment><USER7> That is quite useful however with some federated auth flows, where you just need the email to see where to send them for the actual auth (e.g. Office365 and SAML login), otherwise you'd needlessly be entering your password.

I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.

<comment><USER8> Pretty sure that is why... you enter your username and it checks to see what authentication flow to use, if it's a password flow then you get a password screen.

Pisses me off too

<comment><USER9> Bingo. This is why we went with a stepped process. Did you log in with Google, Twitter, Enterprise SSO, or Email? Do you even have an account, maybe you need to create one?

It frustrated everyone.

Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, and overall login attempts dropped.

It's not perfect, but all indicators are it's better than a screen full of options - it allows us to guide users to the correct action.

Sure, it can still be annoying, but less so than what it was.

<comment><USER10> Your comment confuses me, can you clarify?

> This is why we went with a stepped process. [..] It frustrated everyone.

But then:

> Since we've implemented the stepped process (and made other changes) > complaints have all but disappeared

<comment><USER11> "[..]" was a list of all the problems that frustrated people before the stepped process.

<comment><USER10> Oh, I see, thanks. The list sounded to me like a description of the stepped process, so I was confused.

</comment></comment></comment></comment></comment></comment></comment><comment> Al-Khwarizmi Tip from a non-native English speaker: if you want your website to be more friendly to an international audience, don't use the terms "sign in" and "sign up", use more distinct terms (like "login" and "register") instead.

Phrasal verbs, in general, are difficult to speakers of languages that don't have them, especially when the same verb has different meanings depending on the added preposition. Someone with a basic/intermediate level of English may have difficulty telling between "sign in" and "sign up". In my own case, I have a good level of English so I know what they mean, but "sign in" and "sign up" always take 2 or 3 seconds for me to disambiguate, while "login" and "register" (or similar) are instantaneuous.

<comment><USER12> Afaik, you "sign up" for something, like a newsletter, or health insurance. You sign into a hotel, ie leave your signature at the check-in (or sign-in) desk. Btw, also not a native speaker.

<comment><USER13> Native speaker here. You sign in when you arrive at a fitness club, or when you take your child to daycare. It's a regular, reoccurring action that you use to indicate you've arrived. I wouldn't normally use sign in for a hotel visit since it's not normally reoccurring; you check in to a hotel, not sign in. Sign in would be appropriate if the hotel had a policy of asking you to sign every time you enter or exit (to keep a minute to minute record of when you're in your room). I've never seen a hotel that does this though.

By the way, this is why an English speaker would say "sign in to a website" but not "check in to a website". Check in is generally a non reoccurring action.

<comment><USER14> A minorly relevant note is that GP said 'sign into' a hotel, while you said 'sign in to', which is a subtlety difference a native speaker would know.

<comment><USER12> Oh, I actually use Writefull to check phrases, this one came up in Google Books. ([https://writefullapp.com/](https://writefullapp.com/))

"after the raid, it is known that Brown wrote to Kagi that he would sign into a hotel as I. Smith and Sons. As he began recruiting supporters for an attack"

These are the results I get for web:

        - sign in to a hotel appears 0 time in Google.
        - sign into a hotel appears 81 times in Google.
        - check into a hotel appears 577,000 times in Google.
        - check in to a hotel appears 69 times in Google.

<comment><USER14> OK, that's interesting. I wouldn't really trust to google books since it is OCRed.

I can't get Google results like those with numbers on mobile, as far as I know. What comes up for me is discussions about what is grammatically proper in this case. [https://www.quora.com/Which-is-grammatically-correct- check-i...](https://www.quora.com/Which-is-grammatically-correct-check-into-a- hotel-or-check-in-to-a-hotel) for instance. All I had to search for was the phrase "check into hotel", and the results show this is a hot topic of grammatical discussion because that is what came up rather than information about hotels.

'Check into' sounds different than 'sign into' to me, probably because few say sign vs check for a hotel. I suppose grammatically they're the same.

I would certainly flag it when editing. I also do not commonly see anyone use the contracted form for this. The reason is that the verb is the phrase "sign in". The word 'in' is not a candidate to be modified by being combined because it is paired with 'sign'. We would never modify a single-word English verb by adding a suffix like 'to', and the same rule applies for phrase verbs. Beyond that, I'm not a grammar expert, so I would imagine the above link could shed more light than I can.

<comment><USER13> Right, "check into the hotel" makes me think you're going to examine it, like you're suspicious of it's going to be a good one or something. Similar to how you might say "I'll check into that" if someone tells you to investigate something.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> Magic links are a valid method of login that is "right" for many users who end up resetting their accounts anyways.

It's better than using true SSO in the sense that "email is decentralized." Yes, that means if their email is compromised the account is compromised, but how many accounts are there are aren't already compromised when using a random password if the email account is insecure? Every story I've heard of an attacker gaining "access to everything" involves attacking the Email account in some way to then password reset everything.

You may also complain that Email is literally not secure so the link could be intercepted unless it was PGP encrypted (somehow). I grant that I think this is perfectly legitimate when the user is facing more advanced attackers (possibly those with passive access to traffic or backend access to emails. NSA or Company IT come to mind) and hence maybe the need for U2F or TOTP.

We get so many "password reset" emails on our old system that I think it'd just be better if they could login with just an email.

Users should use strong and secure methods for their email(s) and websites so err on the side of Magic Links or SSO. Preferably Magic Links because they expose less about the user by default except their email.

<comment><USER16> I like the magic links, but more as a secondary option or at least an equal option to a password. I have yet to see a site completely depend on the magic links and I hope that doesn't become a thing.

I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote.

<comment><USER17> Notion uses magic links only for their login and it's aggravating. It may be nice for some users, but using my password manager's autofill is much faster than going to my inbox and clicking a link.

<comment> huy-nguyen I think Medium does this too (unless you want to log in with your social account, which I don't like for privacy reason) and it really annoys me.

</comment></comment></comment></comment><comment><USER18> The worst offender I have seen in the wild is treasurydirect.gov. The password must be click in on an online keyboard, and they do not allow password managers to enter the passwords.

Screenshot here: [https://en.m.wikipedia.org/wiki/TreasuryDirect](https://en.m.wikipedia.org/wiki/TreasuryDirect)

<comment><USER19> > A virtual keyboard, with keys that display in random order, is available to > deter others from learning your password.

This is a weird way to describe keyloggers if that is actually what they are talking about.

The random order I don't understand either unless the "keylogger" is also recording mouse positions.

Otherwise, if this is actually talking about over shoulder lookers it probably has the exact opposite effect because of the increased time require to enter a password.

<comment><USER20> The irony is that if someone managed to install a keylogger, they could've installed any other RATing tool such that the machine itself and everything it touches it completely compromised.

<comment><USER21> I imagine 99% of keyloggers are the 'put this on as many machines as possible and look for worthwhile logins' type, which are well-thwarted by this approach.

Anything more bespoke than that is probably much rarer.

</comment></comment></comment></comment><comment><USER22> > don't split login across multiple pages

This is often necessary for enterprise applications; what they're often doing is making an intermediate request once they have your email address to determine how you log in. Do you use a password? Do you use SSO? If you use SSO, is it SAML? Do you have multiple accounts?

Here's my experience, as an engineer at an enterprise company. We tried to put everything on one page, and that included an SSO button for every type of SSO provider. Users UNIVERSALLY hated it. They didn't create their account; their company did, who purchased our product. They don't know whether they should log in with Email, Password, SSO, hell: Most of them didn't even know what SSO is or what Provider they use. They see a Google button and they click it, then try to log in with their personal Google account; their company doesn't use G-Suite, they use Office 365, we reject the login because they don't have an account, we get a support ticket.

Its absolutely hilarious to me that all of these Suggestions are motivated by the use of password managers. The number of people using password managers is literally a rounding error.

<comment><USER23> There needs to be a standard or something here to facilitate password mangers. Everyone should be using one and not reusing the same password.

<comment><USER24> I hate password managers with passion. In general passwords are hard to remember. Especially when every site has their own requirements. Password managers add too much friction.

I very much like login in with google. Even two factor TOTP is nice. I don't have to remember things. I just need to carry a device with me.

<comment><USER25> The trick is to install a password manager browser extension, not to use a password manager that operates as an isolated app / CLI tool / website / etc. Then you unlock it once at the beginning of your session (or whatever frequency you feel like) and it will fill in passwords for you when you click, without having to copy/paste them. It's about as easy as external login / login with Google.

(inb4 "but password manager extensions have bugs that cause them to fill in the password on the wrong site": get one that doesn't. [https://news.ycombinator.com/item?id=18984582](https://news.ycombinator.com/item?id=18984582))

<comment><USER26> Having auto-fill may be rather dangerous even if your password manager extension has no bugs whatsoever. I would not recommend this configuration.

Having one touch form fill for credentials is good enough. It adds one touch to every intended login, but deletes the risk of credentials being captured when you weren't actually even trying to log in.

<comment><USER27> Regarding auto-fill, I second this. Password managers are great, but I would go so far as to advise against using password manager browser extensions entirely. You're adding several more vectors to be compromised, and imo the risk is not worth it.

Navigate to the site, open the password manager, copy and paste the username and password into their respective fields. Yes, it's less convenient, but as we know convenience is the bane of security.

With authorization we have a few things available to us - something you know, something you have, something you are. To remain secure you will always use at least two of these when authorizing with a service.

The login information for my password manager is stored in my brain - something I know. The 2FA code I enter from my phone is gathered from not only something I have (my phone), but must be authenticated to with something I am (my face (although they could probably just brute force my pin)). I take it a step further by storing the 2FA codes for my most valued accounts on a completely separate device that I leave at home. /protip

<comment><USER25> > _Navigate to the site, open the password manager, copy and paste the > username and password into their respective fields._

This leaves you vulnerable to (at least) two attacks:

1) Phishing. The password manager extension will refuse to send the password to the wrong site; it can't be fooled when tired the same way you can be fooled when tired.

2) The password stays around in your clipboard. There's a general risk of accidentally pasting it (e.g. to the next site you log into). There's a specific risk of sites that capture activity on unsubmitted form fields, which is becoming way too common.

You should decide for yourself how you weigh these risks, but I'm a pretty paranoid person (e.g., I have a Chromebook in a corner of my room which I use as an SSH / web client for certain high-security sites like my domain registration and maintaining certain servers) and my conclusion is that the risk of phishing and mispastes is high and the risk of my particular password manager extension having serious bugs is much lower.

> _Yes, it 's less convenient, but as we know convenience is the bane of > security._

I'll be honest, I don't know that. Security keys are more convenient than SMS- based 2FA, and significantly more secure. Signal is more convenient than PGP, and (depending on threat model) more secure in real-world use. Doing string processing in Python is way more convenient than doing it in C, and way more secure.

"It's annoying, therefore it must be secure" is a fallacy. Sure, there's some correlation, but it's not a perfect correlation.

<comment><USER26> Yeah, Security Keys definitely illustrate that "more convenient" isn't "less secure". Signing in with a Security Key is so painless, it's just a shame I can't do it in more places.

Use the clipboard as interprocess communications for secrets does seem dangerous. The 'pass' password manager I use has an option to do that if you want that, but I've rarely used it. However it may be less dangerous than you realise - by default pass will destroy clipboard items it added after 45 seconds. This is easy on X and, as far as I know, any modern graphical desktop, because the "clipboard" isn't (usually) really a static buffer, it's a live negotiated relationship between desktop clients, so "pasting" is an operation in which the copying software is itself actively involved, so if it were to crash, the content is gone, not left on the clipboard.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> My list:

1\. Don't have your website take a longer password than your mobile app and then not let correct passwords login inexplicably

2\. Don't break completely on valid passwords because there's a char you didn't expect, testing is a good thing in security critical code.

3\. Don't mess up MFA if you're a financial app logging into a 3rd party bank for a user by trying to replay a token code

4\. If you login to any 3rd party services on behalf of a user, support a method that doesn't require asking the users for their password such as OAuth2

<comment><USER28> My biggest one is...

Requiring users to login with a username or customer id. (instead of email).

<comment><USER29> My biggest (related) one is…

In the sign-up process, validate the email (don't trust the user). I get a lot of emails that companies never validated, including for a while, from Wells Fargo.

<comment><USER30> Unfortunately, the trend is in the opposite direction. People have realized that email validation is a step in the funnel where you lose users. And when you look at it as a funnel conversion optimization problem, you arrive at myopic conclusions that are insecure and have externalities like the one you noticed.

</comment></comment></comment></comment><comment><USER31> Something I've noticed, since I've been living for a few days with "my cell phone is my computer." When a login form appears, my on-screen keyboard pops up and covers half the form. Thus, anything at the bottom of the form is likely to be hidden unless I remember to look there. So a cell phone friendly login form should put the most vital info in the upper half.

</comment><comment><USER32> > _don't put logins in modals_

LastPass fills out my username and password on modals just fine. Tested it out on Hertz just now. If other password managers don't... then they should be improved, no?

Why should a site bother with a slower page load when an instant modal works just fine, as long as it's properly implemented?

> _don't split login across multiple pages_

I've never seen this done except when it's necessary because depending on the account identifier (username) a different authentication method is used -- e.g. redirecting to your institution's authentication page.

Of course if you have a direct account you have no idea and it just seems annoying. But it is a feature, not a bug.

I'm not convinced the author has really done their full research here.

<comment><USER33> >> don't split login across multiple pages

>I've never seen this done except when it's necessary because depending on the account identifier (username) a different authentication method is used -- e.g. redirecting to your institution's authentication page.

I've actually noticed this becoming more common and I find it super annoying when there's no obvious need for it. Even Google does this now:

[https://i.imgur.com/ZH1yiqH.jpg](https://i.imgur.com/ZH1yiqH.jpg)

<comment><USER34> That allows federated login. You can federate Google login to Okta etc.

<comment><USER35> Paypal and iCloud have 2 step logins as well. It doesn't seem likely that they would need to support federated logins.

<comment><USER15> And yet they most likely do.

</comment></comment></comment></comment></comment><comment><USER36> It's 2019 and we're still doing email based signups, by default. What's wrong with this industry? OpenId was a pretty neat idea twelve years ago. And given the amount of password databases getting compromised, quite many websites would have been better off federating identity with a competent provider. But no, world plus dog still outsources security to email providers like hotmail, gmail, or worse. Basically compromise somebody's inbox and you gain access to most of what they ever signed up for. Single point of failure, and even if you protect it properly you are still at the mercy of their support not falling for some social engineering attempts.

It would be nice if Mozilla followed through with their repeated attempts to integrate authentication in the browser (they've been experimenting with this for most of this decade) and deliver something that 1) works, 2) is stupidly easy to start using for websites, 3) is bleedingly obvious to use for end users. The current implementation of webauthn fails all 3 tests. I've not seen it work once. I rarely encounter websites that support it and it does not work with mainstream hardware like the nano ledger or now very common finger print readers on many laptops.

I've had finger print readers on my laptop for ages. I've yet to encounter a website or browser capable of doing anything productive with that. I thought webauthn was supposed to be it but it seems to be out of scope and instead require USB dongles. Even Apple, who apparently love dongles, are not bothering to support that with a dongle or other people's dongles. The first browser to do the bleedingly obvious thing to support built in fingerprint readers in combination with webauthn would instantly incentivize hordes of website developers to start relying on that. So much easier than messing with passwords. Also, MS seems to perpetually get stuck doing proprietary whatever instead of fixing security properly. Apple has been shipping touchid for a few years now. Lenovos came with fingerprint readers last decade already.

<comment><USER37> I also don't understand why Mozilla killed these projects. The original persona (BrowserID) was a pretty solid idea, but I think it's pretty expected for these things to take years of advocacy to pick up.

I wonder if it was changed and canned simply because they didn't hit their early metrics.

<comment><USER38> My (lay) reading of it was that it was indirectly killed by the FirefoxOS efforts. A lot of the enthusiastic BrowserID/Persona folks got roped into the login/auth parts of FirefoxOS. I think a lot of good enthusiasm/energy was burnt by FirefoxOS not doing well, and that burnout was accidentally/indirectly the death of BrowserID/Persona more than anything else.

</comment></comment></comment><comment><USER39> Progressive disclosure can be made to work with password managers, notably Apple's Apple ID login page[0] does this while still allowing the password manager to fill both username and passwords in one action.

0: [https://appleid.apple.com/](https://appleid.apple.com/)

<comment><USER40> As does [https://accounts.google.com](https://accounts.google.com)

</comment></comment><comment><USER41> I have seen some sites that only show a username field but nevertheless are compatible with my password manager (1Password). What I suspect is going on is that the password field is present but visually hidden (not missing and probably not with display: none, but perhaps by being placed in an overflow: hidden box with a height of zero or a similar technique).

I haven't confirmed this hunch as to the technique but it seems like a good compromise if there is a good reason to hide the password field initially. And I think there are some such good reasons. For example, if you are Google: Not everyone logs in to Google with a password. I have to log in to my work account using our company's SSO provider, so that Google account has no password. In this case, I shouldn't see a password field, as its presence will be more confusing than helpful. Still, a hidden-but-present password field would allow my password manager to work in the case that my Google account does in fact take a password. (Presumably care should be taken to avoid adding extra confusion to users of assistive technology.)

</comment><comment><USER42> The login form on TreasuryDirect is cancer.

\- They split the form into two parts: Username/Account-Number and Password.

\- The Username field disables autofill.

\- The password field on the next page has a virtual keyboard. No autofill, the field is readonly.

I have been using this bookmarklet to "fix" these fields and let the password manager work on these fields:

javascript:document.querySelector("input[autocomplete='off']").removeAttribute('autocomplete');document.querySelector("input[readonly]").removeAttribute('readonly');

<comment><USER43> I came here to specifically complain about TreasuryDirect. Thanks for the bookmark fix. I've just been going in to devtools and manually deleting the readonly. This will save me time and frustration.

</comment></comment><comment><USER44> How about username/password fields that actually look like data entry fields? In the Delta example, the "fields" are indicated by a faint grey underline with placeholder prompts nearly as dark as the page text. I've seen this on multiple sites; I guess it's not fashionable to show "ugly" text entry boxes in the UI, but without them, it's hard to immediately recognize where I should click to enter my username.

</comment><comment><USER45> Could web developers and password manager developers get together and develop a standard web API for authenticating with a website?

I want to specify a URL and have my password manager run a behind-the-scenes conversation with the website and, ultimately, drop me into the home page in a logged-in state.

<comment><USER46> Ditto for a standard API for updates. That way you could have your password manager automatically rotate your password, either on a schedule or in response to a known breach. Hell we should have an API or machine readable stream for breaches too.

<comment><USER47> At that point, you might as well just move to full public-key based authentication. [https://www.w3.org/TR/webauthn/](https://www.w3.org/TR/webauthn/)

</comment></comment></comment><comment><USER48> My company is planning to roll out a new login form with a "don't remember me" checkbox. The guy who implemented is standing by it because that's what the mockup showed, and the designer essentially covers his ears and shouts LA LA LA LA when you try to address it with him.

So yeah, I expect some fun comments when that eventually rolls out.

<comment><USER49> This default is only going to create security risks as users login on public- facing devices, like a library or device they don't own.

I hope you don't make PII or transactions available inside your app, otherwise I would urge escalating this issue internally.

<comment><USER50> I'm probably in the minority, but I just expect web sessions to persist regardless of what checkboxes I check. If I have to login to anything on a computer that isn't mine, I just open a private session (usually incognito in Chrome).

</comment></comment></comment><comment><USER51> Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.

<comment><USER52> It is funny how trends shift.

A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead.

Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.

<comment><USER53> So everyone is happy with depending on a password manager? Because having 100 different passwords and having to rotate those isn't going to happen any other way.

<comment><USER54> There is no reason anyone needs 100 different passwords and/or those passwords to rotate. This is terrible advice, you don't need it and you shouldn't do it.

As of current, haveibeenpwned hasn't found any breaches connected to my current email address, which I switched to around three years ago. Which is to highlight: Most breached password data is _really, really old_. A surprising number of breaches come via an email address I was only signing up for accounts on more than six or seven years ago.

Furthermore, most of your accounts don't matter. Things like your email, your bank, your web hosting, need to be secured well. An account you used once to sign up for a newsletter does not. Don't save your credit card info in every single web store you log into, and your security on those accounts don't matter either.

Focus your security and your password uniqueness and complexity on accounts that matter, and stop caring about ones that don't. People have reached security overload after being told all of their accounts must be secured, and then offloaded the problem to a bad solution.

<comment><USER55> But with a password manager, you don't need to make that distinction. If it's trivial to make all passwords unique, why not do it?

<comment><USER54> The issue is that password managers are a huge weak point and a significant compromise in your security. Generally password managers have some sort of master password, which unlocks access to _all of your other accounts_. Why bother setting different passwords for every account if one password unlocks them all anyhow?

Password manager security flaws are also a dime a dozen, and none of them have been without significant flaws at some point or another. None of them are operated by companies with an ironclad reputation for security. And if you don't want to have a lot of issues going from computer to computer to phone, you more than likely will do what many password managers suggest, which is _storing your password data in the cloud_ , which is even more laughable, because now we've secured all of your accounts with a single password, and then put the data that password unlocks out on the Internet where anyone can try to crack it.

Which is to say, if you really want to manage your passwords, don't use a password manager. Use a scrap of paper in your wallet, or a notebook, or a sticky note. Because all of those are vastly less attackable than a password manager, because they require physical access or physical proximity and probably the will and risk of accosting your person to get. Password managers, on the other hand, are somehow both the stupidest security idea we've ever come up with, and the thing that every "security expert" currently recommends ad nauseum. I don't understand it at all.

Now, sure, all those accounts you don't care about, if you want to randomize their passwords and store them in a password manager and say it's "better" than using a handful of common low security passwords, more power to you. I'm going to say you're wasting your time and effort (and probably money), but you're not hurting anything.

The problem is when you entrust that same password manager to your high security accounts like your email, your banking, etc. Accounts that deserve far more security than a single point of failure with some cloud app written by some company that doesn't do much else.

<comment><USER56> Because that one password is pretty long and secure, and you enter it only on your own machine, into one known binary, no-where else.

It strikes me as sensible advice.

Connecting your password manager to the browser for auto-fill already compromises the security, granted, but what other flaws have there been otherwise?

</comment></comment></comment></comment></comment></comment></comment><comment><USER57> Don't: Force users to come up with a username separate from their email if they aren't going to be interacting with others under that name. (eg. Hacker News this is OK. Logging into my bank account is not.)

Do: If the username is always the users email, call the field "email" and not "username". (Looking at you, ComEd)

</comment><comment><USER58> Most of his issues with magic links don't exist everywhere. Maybe "Notion's" magic links are bad, but not everyone does that.

They're not tedious if you persist the login beyond 1 session.

There's also no need for any type of codes. You just receive the email, open it, click the link and then you could be potentially logged in for months or longer (it's up to the site who issues the link).

It's one of the easiest and fastest flows you can ask for with technology that works today in all major browsers.

<comment><USER59> How long should the link work for though? What are the security implications?

Also, you get cases where someone has email checking set up on their phone but not the machine they're on so clicking the magic link isn't ideal. This can be helped by supplying a code in the email you can type into the site though.

As a side note, how do developers working on systems that need magic links deal with them while developing? Usually you need some way to bypass the email checking part while you develop.

<comment><USER58> > How long should the link work for though?

Up to you. An hour or 2 seems ok as a general rule.

> Also, you get cases where someone has email checking set up on their phone > but not the machine they're on so clicking the magic link isn't ideal.

Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.

> As a side note, how do developers working on systems that need magic links > deal with them while developing? Usually you need some way to bypass the > email checking part while you develop.

Couple of options. Bypassing it is a valid choice. Also if your framework supports it, you can often configure things in development so that emails aren't really sent, but you're given a URL that you can visit which opens a web based inbox page. This way you can preview your emails and click links. It's basically an in-memory no-op local mail server for receiving email. Rails and Phoenix do this well.

<comment><USER59> > Up to you. An hour or 2 seems ok as a general rule.

Oh, I meant how long after you click the link should you stay logged in for? My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.

> Does that really come up? I've never experienced this. If I'm signing up for > something on my desktop workstation, it is always capable of retrieving > email. A lot of password confirmation links (as an alternative to magic > links) would also expect you to click a link to verify your account, which > means you would have to do it on the same machine you signed up with.

I haven't used magic links enough to be honest but when I sign up using dev/test email addresses I don't often check, the hassle to get the email is annoying. I guess that's true for account verification emails as well though, which is a good point.

<comment><USER58> > Oh, I meant how long after you click the link should you stay logged in for?

That's up to the service. I think for most use cases having the login last 3, 6 or even 12 months is ok and then it would get invalidated early if the user explicitly logs out, they change their email address or the server blacklists the token.

> My bank makes me reenter my password after maybe 1 hour of inactivity for > example which would be super annoying with magic links.

1 hour of inactivity is a very very long time for a bank. I think my bank logs me out after 15 minutes or so but I can't remember when that last happened.

Are you really idling for long periods of time on your bank's site? I typically login with a specific purpose. Maybe it's to check my balance, or see if a recent charge / deposit went through, etc.. It's things like that where I'm in and out in 30 seconds, or at most a few minutes.

In both the password and magic link case, you can still re-validate the session without any user intervention as long as they are actively using the site. If there was a legit use case where people's sessions needed to expire after 10-15 minutes of inactivity and it was very common for that session to expire I would re-think the entire user experience and design things so sessions expiring weren't so common because this sounds like a really poor user experience in any case. But if the 0.00001% use case came up where you wanted to torture your users with logging in every 10 minutes, then I would avoid magic links.

</comment></comment></comment></comment></comment><comment><USER60> This seems like brad coming up with a list of things that annoy him, without any data to back it up. I also like using password managers, but all that really matters are the results that services get from different flows. Magic links, for example, have almost certainly been a/b tested by the services using them, and most likely lead to better outcomes. There are a lot of genuine issues with passwords that password managers solve, but I would guess most people still don't use a password manager. For this kind of thing, doing experiments and following the numbers seems like the only way to do it. Why trust your gut when you can so easily get real data?

<comment><USER61> I think you and Brad are making different arguments. I think you're both right in different ways.

You're correct that convenience features like this, despite undermining password managers and interrupting power-user security practices, create positive business outcomes. Ditto for things that win A/B tests.

But user experience != business experience. Positive business outcomes don't imply that users are being maximally well served under the winning system. Example: anything by Comcast or Verizon.

\---

Separately, I believe in the case of Notion specifically, their use of emailed unique strings in place of passwords is a security decision made by them to avoid storing credentials, which they consider riskier than the magic links. While I find this tedious as well, I respect the decision and it's not a frequent PITA.

<comment><USER62> The magic link / Notion example is completely lost on me.

"The pattern is incredibly tedious"

That's the point. You log in to your email to log in to your Notion. It's not 2FA, but maybe there should be some other term for it (like External Factor Authentication). I think unifying all of our logins against our email would be a step forward, not backwards. Then, sure, use your password manager for your email log in.

"This doesn't work at all with password managers"

Yes, because there's no password to manage. Even if password managers end up supporting this flow, that'd require email access, and that seems like a Bad Idea™. Funnily enough, I'm sure that if password managers started supporting magic links with email access, UX people would rejoice even though it's a security concern.

"It forces users to learn a new convention"

Yes, it does. Granted, the Notion flow could be easier by injecting the temporary password into the log in URL, such that the end-user doesn't have to copy and paste it over.

</comment></comment></comment><comment><USER63> Splitting username and password across two different steps:

Google recently switched to this model/workflow, but for good reason. They introduced support for integration with third-party authentication (using SAML) so that you could authenticate to your Google account using your own company's auth as it's source of truth (AD or Duo or whatever). And since it decides whether or not you need a password based on your username, you can't ask for both at the same time.

</comment><comment><USER64> I would go further than this: don't get clever with logging in. Here's a list of "don't"s:

\- DON'T arbitrarily restrict my password from being too long

\- DON'T arbitrarily restrict me from using special characters

\- DON'T arbitrarily me require to use certain classes of characters (eg 1 uppercase, 1 lowercase and 1 number as a requirement; see [https://xkcd.com/936/](https://xkcd.com/936/))

\- (this is a big one) DON'T TRY AND STOP ME PASTING MY PASSWORD. I can't tell you how infuriating this is.

Login forms aren't hard yet the desire to "add value" with little restrictions and tweaks (because security) is maddening.

<comment><USER65> A good idea is just to follow NIST SP 800-63B rules and recommendations for passwords ("memorized secrets") unless you have a really compelling reason to deviate from it. And to be extremely skeptical if you think you have such a reason.

This actually includes all of your rules and others, such as excluding use of password hints and server-specified "security questions" (which are just a kind of weak password used to protect a stronger password), and accepting Unicode.

<comment><USER66> Do you have a good source for those rules in an easily digestible form?

<comment><USER65> NIST (computing, at least) publications in general, and 800-63B specifically, are pretty straightforward and digestible to start with, IMO.

</comment></comment></comment></comment><comment><USER67> How do people feel about the passwordless option discussed in the article?. I feel like it can be done smoothly by:

\- giving the user a link to their email service

\- providing a link in the email that completes the auth flow, no need to copy paste anything.

<comment><USER47> Well, for one it's far more secure than password-based logins are. (No need to worry about weak passwords, brute-force attempts, credential stuffing, etc.)

</comment></comment><comment><USER68> While we're on the subject of bad login pages, can we also please stop showing UI elements (e.g. upvote/downvote/flag in comment sections) that jarringly take you to a completely separate login page when clicked (rather than giving you a modal or some other non-jarring login opportunity)? The more egregious ones don't even take you back to where you were after you login.

</comment><comment><USER69> I think this falls under the principle of 'good design is as little design as possible'.

</comment><comment><USER70> Here's another one - DON'T disable the submit button if the fields are empty since some native password managers like Chrome iOS will render as if they've filled the fields, but only provide the values on the user's first interaction on the page. A simple form doesn't have an issue with that.

</comment><comment><USER71> What is the fundamental nature of a login page?

Is a login page a first-order feature of a site, a real piece of functionality that should have its own url (aka `/login`)?

Or.....

Is a login page just one possible state of an actual page? For example, if you have a secret dashboard page at `/secret-dashboard`, and Bob is logged in he would see his dashboard data, while if Suzy was logged in she would see different data for her (different pages). Doesn't it follow that a non-logged- in user would simply be presented their "data", which in this case would be no data at all and a login page instead? All while the url stays at `/secret- dashboard`.

This would still allow being able to directly visit a login page (as the article recommends) by simply going to any protected url.

</comment><comment><USER72> I was a regular user of Expedia until some genius got the idea to disallow pasting into the password prompt. That was a few years ago and I couldn't tell you to this day if they fixed it or not. It was probably a short lived experiment.

</comment><comment><USER73> One bit of cleverness I would like to see is allowing username and password to be entered together in the same field.

Provide the normal, separate username and password fields, and if both are filled out proceed normally.

If, however, the username is blank but the password is not, check to see if the value in the password field contains internal white space.

If it does, split it on the first run of internal white space, taking the resulting two strings as the username and password.

This allows entering both the username and password with a single paste operation. This would be convenient for people who are managing their passwords via some mechanism that cannot automatically fill out fields in their browser.

<comment><USER74> Unless you have spaces in your password

<comment><USER73> It's only a problem if you have leading spaces in your password. If you want the option of single field login you would have to avoid that.

I suppose an interior space in a password also raises the possibility of accidentally logging in as someone else. Suppose your password is "foo bar.spam", and you try to login using the normal two field approach, so you put your username in the username field and "foo bar.spam" is the password field, but somehow botch filling out the username field so it is blank.

The system will try the alternative interpretation, that you want to login as user "foo" with password "bar.spam". If there happens to be someone with "foo" as a username who happens to have "bar.spam" as a password, you will end up logged in as them!

This could be addressed by requiring some special value in the username field to signal you want to use the one field option. Say, "a" as the username means look for combined username/password in the password field. It's slightly more work for the user as they do have to enter something in username now, but still only needs one copy/paste which is the main point.

</comment></comment></comment><comment><USER75> Also, for the love of all the gods, don't prohibit pasting in the password field!!

</comment><comment><USER76> I agree with a lot of this but magic links are great and I love them. Don't take away my magic login emails.

<comment><USER77> You might be the only one...

<comment><USER78> They're not the only one. Don't shame other people for their preferences.

</comment></comment></comment><comment><USER79> Can anyone explain to me the rationale for the recent trend to split the input of username and password into two steps? I noticed more and more services (including Outlook, iCloud, Evernote, etc.) have adopted such an annoying design, which makes no sense to me. I guess the purpose for doing so is to preempt user from typing a wrong/non-exist username so that server resources for checking unmatched credentials are saved and brutal force attacks are prevented? But do they justify all the hassle caused to daily users?

</comment><comment><USER80> > don't split login across multiple pages

At a company I work with, we found that splitting account creation and login fields across several pages actually simplified the account process for customers and led to increase sign ups and more reliable log-ins. It's not as efficient for password managers—I use 1Password, too, and it's a minor friction point for me personally—but for users, we have some evidence it actually increases clarity through focus.

</comment><comment><USER81> Is there any technical reason that a password manager cannot be made to work with split logins or hidden fields? Shouldn't they have access to the same web browser that user does? I'd think that could be scripted to handle these things. Obviously this makes it more complex for password managers to auto- enter passwords, different websites will have different scripts but I see no reason for this to be an insurmountable issue.

<comment><USER82> I made a custom password manager a while back [1] where I used the MutationObserver API [2] to detect when a field is unhidden or newly added. I mainly did it to deal with iClouds login flow. The performance of that could probably be improved by figuring out the container of the login and only attaching the observer to that. But the whole thing was never really finished and I eventually forgot about it.

[1] [https://github.com/schroffl/browser- password](https://github.com/schroffl/browser-password) [2] [https://developer.mozilla.org/en- US/docs/Web/API/MutationObs...](https://developer.mozilla.org/en- US/docs/Web/API/MutationObserver/blob/master/content-scripts/login.js#L11)

</comment></comment><comment><USER83> I contacted notion about their lack of passwords and having to use the login link every time. It is inconvenient when you work as an IT field agent and you're all over the place on different networks and devices needed to look up IP addresses or passwords.

they did reply that the reason they did it was security so that they didn't have to store passwords and worried about data breaches, which I can appreciate.

</comment><comment><USER84> > Since password managers are terrible

Wait, why are password managers terrible? That's not an opinion I see much, can you explain why you say that?

</comment><comment><USER85> Also, set the autocomplete attribute: [https://developer.mozilla.org/en- US/docs/Web/HTML/Attributes...](https://developer.mozilla.org/en- US/docs/Web/HTML/Attributes/autocomplete)

</comment><comment><USER86> This list reads like Brad trying to offering semi reasons why XX is bad, but then at the end of each point his real motive comes out which is he's just annoyed his password manager doesn't work smoothly. Some points are valid, but the post just appears very biased.

</comment><comment><USER87> I think I'd settle for not using javascript to actively block autofilling passwords! I've actually encountered this with the washington post and it was just amazing that they took active measures to break my ability to log in with a password manager. They did fix it after I complained a bunch though!

I see the point of some other posters about enterprise systems, but I would be thrilled beyond belief if simple websites with simple login flows who and aren't offering complex services, at the least, keep things simple.

I shouldn't need to spend minutes of active attention to log in to a news website. (but kudos to the washingtonpost for eventually getting my point)

</comment><comment><USER88> Despite its simple appearance, login forms bring in a bunch of usability failures that so many sites suffer from, actually most of them. Social media login hasn't necessarily helped matters either.

There's a whole book dedicated to good, simple, mobile input-friendly and accessible forms at [https://www.smashingmagazine.com/printed-books/form- design-p...](https://www.smashingmagazine.com/printed-books/form-design- patterns/) and it has a whole chapter dedicated to good login forms... sorry for the plug, but I think it's a really good book — I learned a whole lot while reading it!

</comment><comment><USER89> The reason the Delta interface hides the last name field is it's only necessary when entering a username. If you enter a Skymiles account # and password, you're not prompted for a last name (or at least I'm not).

</comment><comment><USER90> I just want to call out Mullvad VPN (in a good way) for only having one field, a super long account number, that acts as both username and password. Extra simple and extra private!

</comment><comment><USER91> Here's another one:

Don't do what some banks do when they separate the password field into multiple boxes for various characters in your password. It's enough of a hassle trying to remember the password sometimes, let alone when you've got to randomly work out what the 3rd, 7th, 10th and 15th characters of it are too.

They also do this for the pin number too, which is obviously much easier to figure out but again adds unneeded stress for little extra security.

</comment><comment><USER92> I disagree a bit with the article. The premise is that you shouldn't make login forms behave badly for password managers, and I agree with this. But at the same time, people using password managers are not necessarily the major use case for a site or some software. You should make it easiest for the largest number of people you can, and that might mean decluttering the UI and co-incidentally making it harder for password managers.

</comment><comment><USER93> I agree with the many points but it's worth noting that login forms are made for humans to identify themselves with a service and all his suggestions are designed to make it as easy as possible for a bot/machine to identify as the human. There is always another side to the story and whilst password managers are one type of machine for which this becomes useful, it's not the only one.

</comment><comment><USER94> Progressive disclosure works with password managers as long as the hidden fields are still in the DOM and are simply rendered invisible to the user. For example, Apple's login forms work this way where they don't show the password until you've entered your Apple ID, but it still works just fine with 1Password (and with Safari's built-in password manager).

</comment><comment><USER95> Point well made for 99% of the cases. Years back though, I worked on a web application for the elderly – try not getting clever with login forms to a userbase that doesn't know the difference between logging in and signing up. There are definitely situations where it's merited to (try to) overcome a lack of tech-savviness with unconventional UIs.

</comment><comment><USER96> I think the Delta example looks pretty ok. If the user enters a number in a field a second field isn't required. Then it shouldn't be visible and enabled until we know that it's needed.

We don't make a worse UX for humans to make a better "api" for scripts.

There must be a way of satisfying both here without being worse for humans. If not: optimize for humans.

</comment><comment><USER97> I keep running into the hidden fields mentioned in this article. I'm also maddened by Evernote, which has a login link on it's home page that's only visible to the desktop. If the window is too narrow, is a phone/tablet interface and the only link for login is at the bottom of a clickable menu.

</comment><comment><USER98> The reason password entry is sometimes split to two forms is because of SSO logins. The alternative is what Microsoft does which is to dynamically check the email after filling it and passing on to the password field and quickly redirecting if needed which is also weird. That's also why Google does it.

</comment><comment><USER99> One of these days someone will "solve" login and we won't need all this. Today is not that day.

<comment><USER100> Based on some really outstanding examples I've seen in the wild, the solution is here, it's just not evenly distributed yet.

</comment></comment><comment><USER101> What does HN think of Google Invisible Recaptcha on login pages?

We have it implemented but have been receiving feedback lately that it doesn't play nicely in many cases (no Google account, private browser windows, privacy plugins, etc). I'm trying to decide whether to remove it.

<comment><USER15> I really dislike when it's blocked, but I have no idea.

Login forms should 100% have an error state shown to the user when the problem is the captcha not loading, being sent, etc.

I personally white-list the Recaptcha stuff just because there is a legit security benefit to it and not much else I'm aware of to work as well as it does.

</comment></comment><comment><USER102> Google has probably the most tedious logins of all services, with multiple pages and maneuvers you need to do to login with another account without automatically linking the accounts. Often it's just easier to clear all google cookies than try using the login interface

</comment><comment><USER103> Shopify started not just splitting the login, but also redirecting to another domain for the password entry. This leads to the situation, that the password manager can not find the correct password anymore as the login domain is not visible during password entry.

</comment><comment><USER104> Evernote is guilty of this. They don't create the password field until you've typed in your username, breaking every login manager. This along with their synchronization getting worse over time has effectively caused me to stop using it.

</comment><comment><USER105> Since these threads often become: patterns I think are stupid.

On the Xbox One (which runs the home theater in our house): it hides the characters of your password, which I think is somewhat silly to begin with, but you type it in with a giant, on screen keyboard!

<comment><USER106> As someone else in the room who doesn't want to see your password, it's a lot easier to avoid seeing all the characters you're typing in than avoid accidentally seeing the password if it's in plaintext on the big screen.

</comment></comment><comment><USER107> How to create a responsive login form with CSS [https://www.w3schools.com/howto/howto_css_login_form.asp](https://www.w3schools.com/howto/howto_css_login_form.asp)

</comment><comment><USER108> > I think this may have started with Slack, but I'm seeing other digital > products [...] send users a temporary password to their email in order to > login

Pretty sure that's about as old as time itself, I don't think it was invented by Slack

</comment><comment><USER109> regarding his point about separating the login process in multiple pages, not only does spotify do this, google, outlook, they all do this, i think it's because there's enterprise custom single sign on which requires a different flow, so they commonize the parts from enterprise and consumer. i'm not saying that i think this is a good workflow or not, just saying that there's reason to it. and it probably breaks password managers, but for enterprise, there are a lot of different password managers like vmware workspace one, etc which may be different from 1password

</comment><comment><USER110> Entering an email address first, and then the password, is needed for systems that support SSO.

If you're dealing with enterprise users, supporting SSO is the most important thing you can do to keep logins quick and seamless.

</comment><comment><USER111> Atlassian does this multi page login and it's shit. Google too though as least their shitty implementation works with password managers without having to fill in the info multiple times. There's a simple rule one can follow: if it doesn't work with a password manager, the login is completely broken and your engineers and product team are morons. If it kinda works with a password manager, the above still applies. Login has been a solved problem for awhile so messing with it just shows what little care the website has for its customers and how out of touch it is with them and the rest of the internet. Such websites should be ashamed of themselves for not getting the simplest part right. I'm looking at you jira. After login it just gets worse and worse.

</comment><comment><USER112> > But it's not just about creating consistency within your own ecosystem, it's > about being consistent with the rest of the internet.

FINALLY someone understands how important this is!!! Great article!

</comment><comment><USER113> OpenCollective's method of emailing you a link that sets a 30 day cookie is a pain for me as I have to be logged into my email on another tab and it seems very insecure to me.

</comment><comment><USER114> One thing I ran into recently: a signup form that did not allow pasting a password (one generated by my password manager). It was very annoying to have to type it in manually.

</comment><comment><USER115> Every time I logon to the AWS console I curse because the login is split across two pages and I have to select the correct login to autofill from my pwd manager twice.

</comment><comment><USER116> This site looks great and loads quickly on mobile and desktop. Makes me so much more inclined to seriously weigh this advice, which seems solid anyway.

</comment><comment><USER117> Just build your login form like this. [https://my.spark.app/login](https://my.spark.app/login)

</comment><comment><USER118> 1 more pain point...I almost always forget my "special" username, so login forms that have the email as the username are my preference

</comment><comment><USER119> Here's another don't: Don't block pasting passwords!!

Amazingly there are some sites that do this. I never understood the theory behind it.

</comment><comment><USER120> I stopped using Notion because of the email login thing. It got too annoying every time and slowly eroded my love of the product.

</comment><comment><USER121> In Wales, they'd say "Don't Tit About with Login Forms".

Seems like a thing to print on T-shirts and hand out at trade shows.

</comment><comment><USER122> The Delta example is not quite the case. It only asks you for the last name if you provide a username instead of their number.

<comment><USER123> Yeah I was looking at that one thinking something was off. I log in to my delta account frequently with a password manager and haven't had an issue. I guess that's why

</comment></comment><comment><USER124> Pretty obvious stuff what's not obvious is the attention it got on here, I'm not hating just making an observation.

</comment><comment><USER125> > don't get funky with magic links

I am not sure why he brought up this. Magic links the single best option that could have happened with website logins in the last while.

I have extremely well guarded email setup with MFA (app based not SMS based) and any suspicious login gets flagged immediately. How many websites can do the same? I appreciate sites who allow me to identify myself with my email without using a password. It is one step froward for a better web.

</comment><comment><USER126> "Don't split login across multiple pages" should be #1. Why is this a thing?!

</comment><comment><USER127> tumblr.com manages to hit 3 don'ts out of 4: modal login window, magic links and multi-stage login where you have to enter your username first, then password on another page. It's extremely painful.

</comment><comment><USER128> I think the article misses a larger point - why is everyone re-inventing the wheel?

We really don't need 'how to create a wheel' tips and tricks - it's a solved problem. We can move on. Can't wait for a sane registration/login cross platform widget to end this madness.

</comment><comment><USER129> Tumblr and iCloud also split up username and password onto separate pages.

</comment><comment><USER130> "Don't hide fields" this is a honeypot. Not a required field...

</comment><comment><USER131> Now do one of these for Captive Portal WiFi please!!

</comment><comment><USER132> Perhaps being predictable is most of it, UX wise.

</comment><comment><USER133> Yes, in that case ok. All others, no.

</comment><comment><USER134> TLDR: I use some password managers that don't work on websites unless you use the format the particular password manager _I chose_ to use, is using. Therefore, web devs, please adjust _your_ code so that _my_ password manager of choice will work, and keep up with the ever growing list of password managers that have nothing to do with your website. It will make my life easier. Thank you!

</comment><comment><USER135> the split sign up fields is actually a security design

</comment><comment><USER136> Must be those blasted full-stack developers at it again.

</comment><comment><USER137> Modality is ok. The reason being, a 'login' is often an interruption to the normal flow of experience. Trying to do 'A' then 'B' \- need to login for 'B'. This is why modals exist.

The background to the modal gives the context to 'where the login is happening'.

If there is no context then it can have it's own screen.

The absolute worst is when you're doing a bunch of stuff, you login, and the app does not forward you on to 'that thing' you were trying to do, rather, you just get to the home page after login and have to re-search etc..

<comment><USER138> Agreed. Modality isn't bad. The author's concerns about them can be boiled down to "make sure your login form has a URL".

<comment><USER91> Yeah. Works fine to have a modal based login form for those with JavaScript and a static page version as a non JS/general fallback, and that'd be the best of both worlds.

</comment></comment></comment><comment><USER78> Most of these patterns are fine if implemented correctly. It's not hard to trigger a modal with a URL for example.

Password managers work fine with multi-page forms, you just have to label the inputs correctly and the user might have to press a button twice.

Magic links are fine, and can even be good if it's you include a log-in link in the email that does the work for you. Certainly better than a weak password (most people don't use password managers).

I'd suggest that implementing a magic link for log-in would be superior to all of these recommendations because it's a better layer of security than the _literal nothing_ most people use to secure their accounts.

</comment><comment><USER54> Since password managers are terrible, I'm not fond of any of his advice here. Every bit of feedback is regarding supporting password managers. I'll expand a bit more on why they're completely unnecessary here: [https://news.ycombinator.com/item?id=19172769](https://news.ycombinator.com/item?id=19172769) but suffice to say, this is a recommendation that is getting really old, really fast, and breaks every well-understood security principle. Single point of failure for your entire online presence is really, really dumb.

One-time login codes are, in fact, really the ideal way to handle login, and he's expressly asking you to not for the benefit of a far weaker security method. And in an attempt to emphasize how frustrating it is, he adds a lot of steps that rarely, if ever exist. Usually, you switch the tab to your email which is already open, and click the link, which opens into a tab where you are logged in. Two steps, not eight.</comment>


The Hot College Gig: Online Brand Promoter - <AUTHOR> https://www.nytimes.com/2018/08/31/technology/college-students-online-influencers.html <comment><USER2> Things like this always remind me of the excellent Roger Waters album "Amused to Death".

      But on eliminating every other reason

      For our sad demise

      They logged the only explanation left

      This species has amused itself to death

</comment><comment><USER3> I'm curious (genuinely) - is there evidence that this form of marketing is effective in terms of ROI? My initial reaction would be that people are savvy to the fact these are paid posts, but perhaps I'm just not the target market!

<comment><USER4> I don't know if this satisfies your definition of evidence, but Tinder's execs have previously spoken about how it's what they used to form their initial userbase.

I believe Yik Yak also pursued a similar strategy.

<comment><USER5> It's probably strongly tied to what your product is. Influencers aren't a good way to sell CNC lathes.

</comment></comment></comment><comment><USER6> [https://news.ycombinator.com/item?id=17878131](https://news.ycombinator.com/item?id=17878131)

Also covered by The Atlantic.

</comment><comment><USER7> "Shills"

</comment><comment><USER8> Step 1 - Be a hot young woman.

If first step not achievable, you better have some seriously awesome content and savvy marketing skills.

<comment><USER9> That's also like every dating article

1) Be attractive

2) Don't be unattractive</comment></comment>


Show HN: Puffin for Facebook – An alternative Facebook app saving 83% data usage - <AUTHOR> https://itunes.apple.com/us/app/puffin-for-facebook/id1031088757 <comment><USER2> One of the best app I've ever had on my mobile device. Extremely useful when you want to stay connected with friends on low quota plan or traveling aboard with roaming network.

<comment><AUTHOR> clyang, thank you :)

We are glad that we can help you.

</comment></comment><comment><USER3> Can't you just disable the background app refresh?

<comment><AUTHOR> Hi blainesch,

Thank you very much :)

We think we have fixed this issue in 1.2.

If you still have this issue in >= 1.2, could you tell us your condition?

</comment></comment><comment><USER4> I am thankful that I am on a (basically) unlimited data plan for €20 a month

<comment><AUTHOR> Hi eecks,

We are happy that it is useful for you :)

Thank you!

</comment></comment><comment><USER5> Awesome app, it just works like a charm!

<comment><AUTHOR> Hi rezacks,

Thank you :)

We are happy that you like it!

</comment></comment><comment><USER6> Awesome for 83% saving

<comment><AUTHOR> Kudochien, thank you :)

</comment></comment><comment><USER7> It's awesome!

<comment><AUTHOR> sunghau, thank you :)</comment></comment>


The physics behind how fire ants band together into robust floating "rafts" - <AUTHOR> https://arstechnica.com/science/2019/12/the-physics-behind-how-fire-ants-band-together-into-robust-floating-rafts/ <comment><USER2> I have a vivid memory of seeing this. Post-Hurricane Gustav in Louisiana, I was wading in nearly waist-high water toward my former car. I then see several of these fire ant rafts floating within about two feet of me, each several inches across. The thought of the fire ants crawling onto me in such large numbers, had I not noticed and waded into them, was terrifying.

</comment><comment><USER3> Also by David Hu: The universal law of mammalian urination time:

[https://www.pnas.org/content/111/33/11932.short](https://www.pnas.org/content/111/33/11932.short)

</comment><comment><USER4> I've always wondered why the military hasn't created massive airship aircraft carriers using a collection of small bladder cells each isolated from the other, inside of a heavily armored hull.

Such a platform could remain stationed above a battlefield, above the range of small arms fire, and if properly constructed, even tolerant of multiple SAM hits.

<comment><USER5> Physics, mostly. To hold the weight of any significant armor, fuel, materiel, etc. you would need an unbelievably large interior space surrounded by a relatively thin exterior.

Deployment is another issue - how do you get it to where it needs to be quickly?

Armor also isn't a good defense against modern missiles. The goal is to intercept or avoid getting hit in the first place, rather than sustain multiple hits.

<comment><USER4> I'm thinking more about a battlefield like Afghanistan, where the opponents aren't firing anything larger than a stinger, and there is already air superiority. As buoyancy is a function of volume, which increases to the third power, and armor just needs to increase proportional to the surface area, which is the second power, a heavily armored floating aircraft carrier seems possible.

<comment><USER4> A 97000 ton aircraft carrier is equal in weight to the amount of air in a 450M x 450M x 450M cube. Aircraft carriers are only 320M long, so this doesn't seem that far fetched.

</comment></comment></comment></comment><comment><USER3> From the group of David Hu, who also brought us "cubic wombat poo".

See [https://news.ycombinator.com/item?id=20975633](https://news.ycombinator.com/item?id=20975633)

</comment><comment><USER6> This is reminding me to reread "Leiningen Verus the Ants" [1] again.

[1]: [https://www.classicshorts.com/stories/lvta.html](https://www.classicshorts.com/stories/lvta.html)

</comment><comment><USER7> The scientific term for such a raft is "Isle of the Deep".</comment>


OpenLayers 3 Full Screen demo (click arrow button in top right) - <AUTHOR> http://twpayne.github.io/ol3/full-screen-control/examples/full-screen.html

<comment><AUTHOR> More info: <https://github.com/openlayers/ol3/pull/521></comment>


Trickery of Photoshop revealed in gory detail Realtime retouch throughout video - <AUTHOR> http://www.dailymail.co.uk/femail/article-2543818/Trickery-Photoshop-revealed-gory-Pop-singer-retouched-real-time-music-video-hardly-recognise-end.html

<comment><AUTHOR> The viral video: [https://www.youtube.com/watch?v=5qrGOi41iwE](https://www.youtube.com/watch?v=5qrGOi41iwE)</comment>


Evidence is growing that peopling of Americas began more than 20k years ago - <AUTHOR> https://www.nature.com/articles/d41586-020-02137-3 <comment><USER2> Do we know if humans spread out evenly when they move into a new area?

Could it be possible that the lack of evidence farther north was because it was more sparsely populated or there wasn't a consistent population?</comment>


Lumia phones are leaking private information to US-servers - <AUTHOR>

The biggest Finnish newspaper Helsingin Sanomat is reporting that Lumia phones are sending sensitive information to Microsoft servers in the US.
http://www.hs.fi/sunnuntai/Nokian+Lumia-puhelin+vuotaa+tietoja+ulkomaille/a1393046974949
On the 14th of July 2014 the Finnish Communications Regulatory Authority (FICORA) send an official inquiry to Nokia, asking them to confirm that no "confidential communitacions, positional information or other private information is revealed to third parties without the users' permission".
Nokia did not answer the inquiry.
FICORA met with Nokia in August to discuss what kind of confirmation they could give. They agreed upon that answer that Nokia is unaware of any hardware functionality added during the manufacturing process that would allow private information to leak to third parties.
Other magazines in Finland are specifying that the Windows Phone OS is sending, by default, "the position information, text massages, contacts and web browser usage information" to Microsoft servers. <comment><USER2> I've got an Android, an iPhone (and a Windows Phone arriving tomorrow), I assumed that both of these were already sending location and web browser usage stats to Google and Apple servers.

I think Microsoft does a pretty good version of outlining their data collection in easy to understand terms [http://www.windowsphone.com/en- us/legal/wp8/windows-phone-pr...](http://www.windowsphone.com/en- us/legal/wp8/windows-phone-privacy-statement#CollectUseInfo), I just hope they aren't collecting more than they say they are.

</comment><comment><AUTHOR> Here's an other article from HS detailing the data that is sent to US-based servers.

[http://www.hs.fi/sunnuntai/HSn+testiss%C3%A4+Lumia+otti+yhte...](http://www.hs.fi/sunnuntai/HSn+testiss%C3%A4+Lumia+otti+yhteytt%C3%A4+Yhdysvaltoihin/a1393047541358)

All an all, the content seems aimed to people who do not understand the realities of modern computing. Things proxies, cloud services etc. or the phone communicating with servers even when you're not doing anything with it.

Using the default settings, web browsing (or at least DNS-queries) is proxied through the United States. Also the Nokia Maps & navigation services are sending your location information to "foreign servers".

It also says "Lumia can save photos and text messages to a Microsoft cloud service".</comment>


Beyond Streets and Avenues: Simple Visual Guide to Different Types of Roads - <AUTHOR> http://99percentinvisible.org/article/beyond-streets-avenues-simple-visual-guide-different-types-roads/ <comment><USER2> Interesting and maybe useful to me - if UK taxonomy is similar. However:

"Avenue (Ave): may have trees on one side, perpendicular to streets"

I can't think of a sensible tree/road relationship in which the tree is not perpendicular to the road direction. Does this make sense to anyone else?

<comment><USER3> What I can think of the the UK, please add or disagree, perhaps there's also regional variation:

* Street - A road that traditionally had shops; may or may not today

* Road - Linking 2 places, may or may not have buildings

* Lane - Traditionally lined by bushes, winding, or otherwise 'small'

* Gardens - Limited to residential housing

* Court - Enclosed square

* Square - With a road/roads encircling it

* Causeway - Next to the sea, sure

* Avenue - Can recall a handful growing up but nothing made them distinguishable. Roads invariably as straight lines, other than the ones the Romans built, are an alien concept

* Boulevard - Never met a boulevard in the UK

* Parkway - Only one I can think of is Bristol Parkway, but I think of that as a train station

<comment><USER4> Some Scots ones:

\- Loan

\- Close

\- Brae

<comment><USER2> Any clue as to what these signify? Close I think I know.

<comment><USER5> A close is an alleyway off which one or more doors to residential tenements open. Alternative names are entry, court, and wynd, with some nuances: a court is more likely to open up into a courtyard, and a wynd more likely to be a means of getting from A to B, rather than just somewhere people live.

<comment><USER4> Just though of another one: "vennel" \- which I thought was just The Vennel in Edinburgh but which actually seems to just be an example of a vennel:

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

</comment></comment></comment></comment></comment></comment><comment><USER6> Where is this for? I can't think of anywhere I've lived in the northeast (NJ, NY, PA) where this strongly applies.

Here's one: I live on a "Drive". It's road built through townhouse complex. Pretty much the exact opposite of what I'd call "long, winding road shaped by natural environments". It connects to a "court", which is another road through the complex that most certainly does not "[end] in a circle or loop – like a plaza or square".

Edit: "Road" isn't even on this list!

2nd Edit: I've consulted some traffic engineers. I'm genuinely curious to see what they say.

<comment><USER7> I live in a Pacific Northwest suburb and they pretty much follow this convention to the letter. Probably has something to do with how recently everything here was built.

</comment></comment><comment><USER8> A freeway has no stop lights or stop signs; traffic is free to move along the entire way.

An Interstate is a freeway that is part of the Interstate Highway System.

<comment><USER9> A freeway has no tolls.

<comment><USER8> [https://en.wikipedia.org/wiki/Controlled- access_highway](https://en.wikipedia.org/wiki/Controlled-access_highway)

<comment><USER9> Among controlled access highways, some have tolls, and these are not referred to as freeways.

<comment><USER8> The Wikipedia article I linked notes that the ITE defines a freeway as:

> Freeway: A divided major roadway with full control of access and with no > crossings at grade. This definition applies to toll as well as toll-free > roads.

</comment></comment></comment></comment></comment><comment><USER10> I added a Google Map at zoom 16 or so for customer addresses in the backend of an ecommerce store to help improve deliverability. These addresses are primarily in the USA and I set it to the tilted 'drone' view. This seems to be a world that is always sunny. I am constantly taken aback by the geometry of some of the places that show up in this map view, often a 'crescent' informs you that the address must be correct because it is a 'crescent' that you expect the pin to be on, the shape visually confirms things nicely. 'Crescent' is an obvious clue but you would be surprised with what registers at a glance to confirm the address is likely to be correct.

</comment><comment><USER11> Then of course there's Avenue Road in Toronto en.m.wikipedia.org/wiki/Avenue_Road

And the awful Stroad [https://www.strongtowns.org/journal/2013/3/4/the- stroad.html](https://www.strongtowns.org/journal/2013/3/4/the-stroad.html)

</comment><comment><USER12> I lived on 72nd St in Queens. The next block was 72nd place, and there was a 72nd terrace since renamed after someone.

</comment><comment><USER13> I found it amusing they gave this definition:

Turnpike (Tpke): usually an expressway with a toll booth

but there is no definition of expressway listed.

</comment><comment><USER14> Roundabout - [https://www.youtube.com/watch?v=sCXtcXD17qU](https://www.youtube.com/watch?v=sCXtcXD17qU)

Taxiway - is a path for aircraft at an airport connecting runways with aprons, hangars, terminals and other facilities.

</comment><comment><USER15> I read a page on this quite recently (but can't find it right now); however the definitions were somewhat different - iirc, a road connects two places, a street is perpendicular to a road, avenue is perpendicular to a street.

</comment><comment><USER16> My childhood home was on "Eighth Street Drive." It's a two block long strip that is about ten feet shy of connecting with Eighth Street, so they slapped a different name on it.

</comment><comment><USER17> How about a 'Common'? My town has given to naming roadways like:

Winding Ridge Common

Maple Leaf Common

Etc.</comment>


10 Rules for Creating a Mobile Look and Feel - <AUTHOR> https://medium.com/outsystems-experts/10-rules-for-creating-a-mobile-look-and-feel-dc81341660e4#.mysjyal5q <comment><USER2> Thanks, guys. I believe we were able to capture the key concerns for both the Mobile Look and Feel. Developers tend to miss a lot of these, as they start their mobile development.

</comment><comment><USER3> What an insightful article. Hope to see more about feel, since motion is the new UI for interfaces.

<comment><USER4> Hadn't thought about it that way, what do you mean by that? Care to share some thoughts about that?

</comment></comment><comment><USER5> Love the side by side comparison graphics. helps understand the concepts so much better!

</comment><comment><USER6> great insights! great job putting this together

</comment><comment><USER7> Amazing article!!!</comment>


Ten things you might not know about antimatter - <AUTHOR> http://www.symmetrymagazine.org/article/april-2015/ten-things-you-might-not-know-about-antimatter

<comment><USER2> > If the original title begins with a number or number + gratuitous adjective, > we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to > "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is > meaningful, e.g. "The 5 Platonic Solids."

And in general I found it linkbaity</comment>


Nigerian scholar solves 156-year-old Mathematics problem, 'Riemann Hypothesis' - <AUTHOR> http://www.olisa.tv/2015/11/15/nigerian-scholar-solves-156-year-old-mathematics-problem-called-riemann-hypothesis/ <comment><USER2> Blogspam.

Source is: [http://www.vanguardngr.com/2015/11/nigerian-solves-156-yr- ol...](http://www.vanguardngr.com/2015/11/nigerian-solves-156-yr-old-riemann- mathematics-hypothesis/)

Source is incredibly dubious. Contains the following sentence:

      Dr. Enoch had previously designed a Prototype of a silo
      for peasant farmers and also discovered a scientific
      technique for detecting and tracking someone on an evil mission.

A Dr. Enoch Opeyemi is indeed on the schedule for ICMCS 2015, but the title of his talk was just "A Matrix That Generates the Point Spectral of the Riemann Zeta Function": [http://computer.conference- site.com/program.docx](http://computer.conference-site.com/program.docx) I haven't been able to find the contents of that talk.

The CMI page for the problem hasn't been updated yet: [http://www.claymath.org/millennium-problems/riemann- hypothes...](http://www.claymath.org/millennium-problems/riemann-hypothesis)

I haven't been able to find anything about a new proof of the Riemann Hypothesis in any of the usual places. (math.SE, etc)

<comment><USER3> > _With this breakthrough, Dr Enoch, who teaches at the Federal University, > Oye Ekiti, FUOYE, has become the fourth egghead to resolve one of the seven > Millennium Problems in Mathematics._

Egghead? Is that... is that a term that's not considered as pejorative as it sounds in Nigeria?

<comment><USER4> Obviously this is fake news.

</comment></comment></comment><comment><USER5> Story is a hoax is seems:

[http://www.nairaland.com/2739995/opeyemi-enoch-not-solved- ri...](http://www.nairaland.com/2739995/opeyemi-enoch-not-solved-riemann)

All who upvoted should be ashamed of themselves.

</comment><comment><USER3> Bah, this is some sloppy writing.

> _" Dr Enoch Opeyemi ... has become the fourth person in the world to resolve > the Mathematics problem called the Riemann Hypothesis."_

I think the accurate statement is below,

> _" Only three people have been able to solve three out of the seven > millennium problems in the past 16 years. Dr Enoch is the fourth."_

Except they're the Millenium Prize problems: [https://en.wikipedia.org/wiki/Millennium_Prize_Problems](https://en.wikipedia.org/wiki/Millennium_Prize_Problems)

Is there a less crappy source for this?

edit: Apparently, there's an abstract on page 8 of this PDF: [http://computer.conference- site.com/proceedings_icmcs_2015.p...](http://computer.conference- site.com/proceedings_icmcs_2015.pdf) \- which is hosted on what appears to be the conference website.

<comment><USER6> I am looking for a less crappy source and have not found one yet. Given that his proof was supposedly presented on November 11 and I haven't heard any mathematicians say anything about it, I'm not getting too excited yet.

</comment></comment><comment><USER7> So what's the answer? Are all the solutions on the real 1/2 line? Or is there a counterexample?

</comment><comment><USER8> I'd say "claims to solve" would be a better title until we see a lot more analysis.

</comment><comment><USER9> Out of instinct I first checked todays date to make sure it's not April 1st... Would expect a serious proof candidate to a have attracted much more attention in the media/internets. Anyone have more information?

</comment><comment><USER10> Looks like there is a database error on their end.</comment>


The fastest way to flatten a list in Python - <AUTHOR> https://chrisconlan.com/fastest-way-to-flatten-a-list-in-python/ <comment><USER2> There's also the less obvious but still I think quite well-known recipe that uses itertools.chain. How it compares speed-wise I don't know.

<comment><AUTHOR> Do you mind sharing? I'd like to add it here. [https://github.com/chrisconlan/fast- python/blob/master/src/f...](https://github.com/chrisconlan/fast- python/blob/master/src/flatten_lists.py)</comment></comment>


A New Study About Overly Nice People Has a Rude Awakening - <AUTHOR> http://www.attn.com/stories/4821/polite-people-betray-friends-more-often <comment><USER2> Original Story in Science News: [https://www.sciencenews.org/blog/culture- beaker/few-key-sign...](https://www.sciencenews.org/blog/culture-beaker/few- key-signs-betray-betrayal)

Paper: [http://vene.ro/betrayal/niculae15betrayal.pdf](http://vene.ro/betrayal/niculae15betrayal.pdf)</comment>


Academic Research going Agile - <AUTHOR> http://computationalimagination.com/interview_deepart.php <comment><AUTHOR> Interviewer here: This profile features deepart.io founders Łukasz Kidziński & Michał Warchoł. They are both academic researchers by day. Possibly the most interesting part of our discussion was Łukasz' points about the use of Agile methods in academic research. At one point he asserts

"I believe that github is a better validation of scientific value than any journal peer-review process."

Hope you enjoy the profile article.</comment>


The Muffin Man - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2009/05/31/cityexposed.DTL <comment><USER2> Occasionally I fantasize about doing something in the food space. Not a very leveraged use of time, but I really like cooking and whatnot.

Sadly I already used the best domain name ever for this for something unrelated to food.</comment>


Encourage 'Dutch reach' to stop cyclists' car-door deaths - <AUTHOR> https://www.theguardian.com/lifeandstyle/2017/sep/11/encourage-dutch-reach-to-stop-cyclists-car-door-deaths-says-charity <comment><USER2> The 'Dutch Reach' isn't universally taught drivers in the Netherlands, I'm Dutch and I've never heard of it before. Though everyone is taught about the dangers of opening your car door without looking.

What's keeping cycling deaths low in the Netherlands is simply keeping cyclists off the road and putting them on separate bicycle paths.

The article links to an article with this video: [https://www.theguardian.com/politics/video/2016/dec/15/trans...](https://www.theguardian.com/politics/video/2016/dec/15/transport- secretary-chris-grayling-knocks-over-cyclist-as-he-opens-his-car-door-video)

The traffic situation for cyclists in that video is what we would refer to here as a death trap. It's a busy road with not even a bicycle lane marked on the road. In the Netherlands you would either get off your bike and walk or risk a fine and cycle on the sidewalk.

<comment><USER3> Indeed, I don't think that particular video was a good choice for the article. Too many people will notice that the cyclist who got doored, and the one with the camera, were passing improperly.

<comment><USER4> What is the correct way, on that road?

The cycle lane resumes a hundred metres beyond the collision point.

<comment><USER3> That's a good question. It looked to me like there was simply no cycle lane before the collision point. If there's no cycle lane, then for better or worse, the default is to do what you'd do in a car: Wait behind the red bus.

If they were actually in a cycle lane, then of course the correct thing to do would be to ride in it. Either way, nobody deserves to get doored, and if it were me in the car, I'd have been extremely cautious about getting out.

I have to flip the picture left-to-right in my mind, to get a sense of it. Where those cyclists were riding, a narrow slot at the edge of a lane, is possibly near the top of my list of situations to avoid. Buses make me even more nervous. I'd have hopped up onto the sidewalk, or found a different route. Of course that's easy to say, not knowing if there are even any alternatives.

<comment><USER4> The video starts at [1], going north along Abingdon Street, though the Streetview car was driving in the other direction.

In central London, there's simply no other reasonable option to cycling past stationary traffic if you wish to proceed by bicycle. I've looked up the rules, and it's neither recommended nor forbidden, and both drivers and cyclists are advised to be cautious.

There's also no other practical route, since the cyclist was probably heading to (or from) a bridge over the Thames.

At this location, it seems the problem is the anti-terrorism barriers. The traffic engineers should have insisted that the road be closed to motor traffic when they were installed, but it was probably long enough ago that only motor vehicles were considered. Closing the south and east sides of Parliament Square (just ahead), and this road, would be great.

[1] [https://firstname.lastname@example.com,-0.1258692,3a,60y,350...](https://firstname.lastname@example.com,-0.1258692,3a,60y,350.26h,91.15t/data=!3m6!1e1!3m4!1snaXE3awdLJr1nJbRbY0B1g!2e0!7i13312!8i6656)

<comment><USER3> Ah, thanks for the context. It looks like a pretty bad situation all around.

</comment></comment></comment></comment></comment></comment><comment><USER5> Dooring, while dangerous, is a small percentage of the risk on the roads.

The most effective change would be to have a 3-5 foot (1-1.5m) passing rule. If it's not safe to go into the next lane to pass a cyclist, it's not safe to pass the cyclist at all.

(edit: and, if we're going to do the work to make people realize that they could be safer, make sure you're all the way past the cyclist before you pull in or turn right (left in the UK). Many motorists get their head past the cyclist and neglect the back half of their car, or the trailer they're towing)

<comment><USER6> > If it's not safe to go into the next lane to pass a cyclist, it's not safe > to pass the cyclist at all.

Cyclists may ride in the center of the lane when they want to force this.

> The most effective change would be to have a 3-5 foot (1-1.5m) passing rule.

Assuming people actually follow that rule, that is.

From my (limited) experience as a cyclist, I think most motorists think they have more of a right to be on the road than bicycles do. This is false from a legal standpoint, but knowing the motorist was technically at fault probably won't make the cyclist feel any better when he's sitting in the hospital after getting hit by a car.

See this for more info: [http://cyclingsavvy.org/hows-my- driving/](http://cyclingsavvy.org/hows-my-driving/)

<comment><USER7> I had a friend who hated cyclists and thought "they should get out of the way". She made no effort to accommodate them on the road.

I think improvements to culture can work, but I think laws of this nature have a pretty insignificant effect on the culture.

<comment><USER5> The garda (irish police) will (occasionally) issue a fixed penalty notice (3 pts + ~80eur fine) if you have video evidence of extremely unsafe passes.

There's still no 1.5m rule here, but it's supposed to be introduced soon.

</comment></comment></comment></comment><comment><USER8> This has been in and out of the news the past few years. Each time the Dutch, including me, feel obliged to respond that no dutchy opens his/her doors like that. We have mirrors, we use them. If we have fewer accidents it must be because we have a lot of bicycle lanes and our cyclists (every Dutchy) is a master evader by years of training in what we call large cities.

Dutchy out.

Drops mic.

Cycles away.

</comment><comment><USER9> I've lived and driven in the Netherlands for five years, and until now I never heard of this. Neither have I observed Dutch drivers doing it. Not saying it isn't true, but...

</comment><comment><USER10> Even more dangerous to cyclists are the cyclists themselves.

At least in Amsterdam there is something called "Amsterdam Red" meaning: red does not neccesarily mean stop to cyclists.

When a car/truck is parked on the cycle lane they will happily move to the car lane without looking...

Helmets. They are not mandatory, and nobody uses them.

So yes, drivers need to look, but cyclists might want to start following rules and best practices as well.

</comment><comment><USER11> Seems like a great solution. Unfortunately I don't see it working here in Toronto, the cabbies don't even follow the basic rules of the road, they can't be expected to make a pro-social effort of this sort.

It is encouraging that so few deaths have resulted from dooring though. Ever slightly over one per year, not to downplay the seriousness of any loss of life, seems very reasonable.

</comment><comment><USER12> The door handle of the Mini Cooper affords doing the Dutch Reach.

It is a circle with a shelf that faces forward in a way that makes it awkward to use the hand nearest the door to open. So, you reach across your body with your other hand and in doing so, you turn your body and head and your peripheral vision can catch a moving cyclist.

</comment><comment><USER13> I am Dutch and learned to open the door this way. But judging the comments of other Dutch people, it seems it is not universally taught. I am puzzled why it would be offensive to call it the Dutch reach. I see it as a compliment.

</comment><comment><USER14> Won't stick with Angelenos. They'll continue to kick their car doors open w/o a thought as to whether bike or car is barreling down towards them.

</comment><comment><USER15> As a Dutch person the 'Dutch reach' is offensive. No one I know opens doors this way. We don't need some 'trick' to remind ourselves not to be assholes.

Just look before you open the door.

<comment><USER4> Don't you teach your children to open the door safely? Or people that aren't often in a car?

On my first day in Denmark,tThe taxi driver who picked me up at Copenhagen Airport reminded me to look for bikes before I opened the door. The director at my new job here, who drove me home on my first day, told me to open the door this way.

So, although I'm not Danish, I doubt calling it the "Danish rearch" would offend any Danes.

<comment><USER15> The key point is that the 'Dutch reach' is supposedly a specific technique (opening the door with the 'wrong' hand) that we teach, which prevents accidents.

But in reality this doesn't exist. No one uses it. We all learn to just look, and not through some trick. And we have other reasons (e.g. better street design) so our country is more cyclist friendly, but those are ignored in lieu of some silly trick that doesn't exist and isn't needed.

</comment></comment></comment><comment><USER16> Just force car manufacturers to make it so that the door is hard to open unless you're using the opposite hand, it should be easy enough.

</comment><comment><USER17> Wow, when I rode road bikes, the onus on avoiding suddenly opening car doors was on me. If bike riders won't pay attention to avoid car doors, expecting drivers to is a fools errand.

<comment><USER18> As a cyclist you may have less than one second to avoid an opening car door. You can't always give a wide berth because bike lanes in the US are usually very narrow.

<comment><USER17> You can have all the time you need, if you slow down.

<comment><USER19> Do you apply the same logic to intersections? You never know when someone might blow through a red light, so you'd better go through every intersection at 2MPH so you have enough time to stop if they do.

<comment><USER17> I do when I'm driving, I slow enough so I can clearly see both ways before I go through.

<comment><USER18> You do realize that unexpected slow downs also result in many accidents, right? The behavior you just described is _more_ risky than the default.

<comment><USER17> no it's not, i'm not stopping in intersections. I'm not exceeding the speed limit, I'm going a little less. Fast enough to see oncoming traffic and not to be rear ended.

<comment><USER19> Going a little less than the speed limit is not nearly enough. If someone stopped at the perpendicular red light suddenly floored it, you wouldn't have enough time to stop. The maximum safe speed through a typical intersection is probably only about 10MPH. Less if there's not much room between the stopped traffic and your lane.</comment></comment></comment></comment></comment></comment></comment></comment>


Announcing Google Cloud DNS - <AUTHOR> http://googlecloudplatform.blogspot.pt/2014/03/announcing-google-cloud-dns.html

<comment><USER2> As far as I can tell, a carbon-copy of AWS' Route53, except ever-so-slightly cheaper. Should be fun to see what comes next from either of them.

<comment><USER3> Haven't test it out yet. But i fully expect Google DNS to be a lot faster then Route53, which I dont think it was build for speed at all.

It is also a lot cheaper then DNSMadeEasy or EdgeCast DNS, both i consider to be extremely performant for a small price.

Looks like Google are starting a price war with Google Drive, Google Cloud infrastructure.</comment></comment>