4 ms·

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

by niftich 10y ago

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.

lucideer 10y ago
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/ 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.
- niftich 10y ago
  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.
DCoder 10y ago
> 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.
- dom0 10y ago
  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.

by niftich 10y ago

lucideer 10y ago

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/ 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.

niftich 10y ago
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.

DCoder 10y ago

> 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.

dom0 10y ago
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.