Hacker News Reader

Comment by lucideer | Hacker News Reader

One of the best UIs I've seen crossing over this line of death was the HTTP Basic Auth popdown in Opera 12. I've always wondered why that UI concept was never taken up by other browsers.

... will try and find a screenshot

Edit: Couldn't find one so just installed it myself: https://pageshot.net/images/4af15a26-6eb8-45a2-b4d5-ed6ea19a...

Edit2: dom0 beat me to it below also

Edit3: reword

View on HN

Both Chrome and Firefox are under the line of death too. Although for Firefox it is a bit trickier to replicate as it uses native components whereas Chrome uses its internal UI kit.

Sorry, perhaps my comment was unclear. I meant "breaking" in a positive way (hence "best") - the UI crossed the line in a very significant and impossible-not-to-notice way.

Still searching for a screenshot unfortunately... may just re-install it and take one myself.

http://schubiserv.de/images/opera-benutzerauthentifizierung....

I still disagree with both lucideer's original and improved wording, but I agree with their message, which praises Opera's basic auth UI as making it clear with the borders and 3D foreground overlay effect that it's a part of the browser-produced "trusted zone", and not the pool of untrusted content behind.

Moreover, these kinds of UIs are still possible with the 'flat' look that's in vogue today, so there's little excuse why others choose not to do it. Perhaps one reason is that basic auth lost out early on to site-supplied login forms, so people got used to entering usernames and passwords into the page content anyway, instead of the browser UI.

For the most part, basic auth only tends to affect uses like intranet sites, router login pages, web services, remote management pages -- settings where phishing can still cause (serious) damage, so a harder-to-fake UI would be beneficial nonetheless.

On my wording, apologies (edited). I was thinking of "breaking" in terms of "breaking/crossing a line/barrier one does not typically cross". Probably not the best wording in retrospect.

On the comments on basic auth losing out, you might be right that that's a reason, but HTML5 APIs requiring some kind of UI confirmation from the user (like HTTP basic auth does) are far more proliferant than they once were (see http://permission.site/ for many examples), so I don't think that excuse is really good enough for browser vendors.

Incidentally, it's worth noting that the UI for this kind of thing (user confirmation prompts) is pretty much a solved problem on mobile: these prompts tend to use the OS notification API, so always appear outside the browser chrome entirely.

Desktop platforms like OS X, most Linux desktop environments, and newer versions of Windows have similarly allowed applications to hook into the OS' own notification mechanism for a while, but for some reason this model never caught on. One can argue that it's much clunkier on these platforms than on mobile, but the capability is now there.

Unfortunately, with HTML5 notifications, the ship has probably sailed on this and it went from being an intriguing idea to a bad one, as now it's getting mainstream for individual websites to generate OS-level notifications. This made a previously privileged pool of messages full of untrusted content.

> one reason is that basic auth lost out early on to site-supplied login forms, so people got used to entering usernames and passwords into the page content anyway, instead of the browser UI

To be fair, basic auth is not particularly user-friendly. If you want to add anything else to the login form, such as a "Remember Me" checkbox or a captcha, you can't put that in the browser chrome, you need to add an additional step in the login flow. If you want an "Did you forget your password? Click here to reset it." error message, the user has to cancel out of the auth dialog in frustration before they can see it (or you have to redirect them to an error page after failed auth, with another link/button to Try Logging In Again.

And even if you solve those problems, the user still needs to enter their username/password when creating their account, and I have never seen Basic Auth used for this scenario.

Basic auth is appropriate mostly for non-Internet or single-user applications. It is eg. commonly used as a simple-no-markup-required input where actual authentication is delegated to LDAP/AD. In these instances the application can neither change the password nor create users anyway.

dom0's comment showed what you meant. That's a much better auth dialog.

It's actually subtly above the line of death in Chrome: https://i.imgur.com/dEootju.png

And Firefox greys out some browser chrome: https://i.imgur.com/JfJ57qA.gif

But these things are probably not going to be noticed by your average user...

It's a nice design. But in this particular case, does it matter? What's the threat, that the credentials you enter into a fake basic auth box could be sent to the server? The credentials you enter into a real basic auth box are just sent to the server -- basic auth doesn't do any password hashing clientside. Why would a phishing site (that's pretending to be another site that uses basic auth) fake a basic auth box when they could just send the right header and get a real one?

What am I missing?

Does the real authbox include a domain that's asking?

Yes

Reply on news.ycombinator.com