Ask HN: Can Browsers Have a Universal Hotkey for Website Login?
I am tired of finding the login button for various websites I visit. A universal browser hotkey would be fantastic. I suppose there would need to be a change to html as well?
Browsers have a built-in auth system for HTTP-auth—there's no reason it couldn't have been improved over the years, such that it's actually a decent choice for login.
Why no built-in sorting HTML tables, and easy hooks into them for custom sorting? Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? Why were features like frames left to rot rather than improved? They're a common element in UI toolkits, and we're using the Web to make "apps" now!
The waste of developer and user time due to the Web platform seeming to just abandon tons of its own functionality and failing to address common and high-cost use cases head-on, is truly staggering.
I agree with your premise, but this is a bad example. Universal payment systems are not a simple task. Even remotely. Go out to any American city, for instance, and as you walk through the stores, catalog the various credit card terminals you see. Not even the PoS system as a whole, but just the credit card interface. You will see dozens of different designs and play on designs by dozens of different manufacturers.
If it's hard to do in the physical world, what makes you think it'd be easy in a browser? Everyone wants a share of the pie and that means fragmentation all the way down.
If you have a store and discover people are aborting the purchasing process because your UI is unique, you're going to fix it.
your objection is short-sighted; there are steps.
https://en.m.wikipedia.org/wiki/Payment_card_number
They are usually 16 digits. Except when they're 15 like Amex.
Security codes are 3 digits... Except when they're 4 digits like Amex.
Magnetic stripes have two separate tracks with two different encoding schemes developed by different organizations, and some point of sale readers will read one, the other, or both.
But yes, tell me more about how all these things are standardized.
> your objection is short-sighted; there are steps.
My point was that everyone wants a piece of the action, meaning standardized interfaces are disincentivized. This is true in the real world and is true in browsers. Do you have any actual rebuttal to that?
Improving the web hurts app store commissions. Apple/Google can't monetize your super awesome fancy web app, but they can snipe 15-30% of your revenue through their stores.
We ranted so much when Chrome added Google Login half a decade ago.
First, there will always be edge cases. What about platforms which use OAuth? What about platforms which use another third-party authentication service? Weird password requirements? 2fa? 3fa? As a result the login implementation will be bulky, making the browser even more huge and creating new CVEs.
Second, even accounting for these edge cases, many websites will simply not participate. Which means that now you have 2 types of login forms: ones that use the new API and ones that don’t. And orthogonally you already have n types of login methods that are OAuth, Yubikey, Ledger, …, username/password. So, the login interface itself will also become bulky and old people will be even more confused.
With that out of the way, I 100% support a unified login interface, unified sorting, unified payment, unified content embedding, etc. I still think it’s worth it to develop the Semantic Web. But, I’m not counting on Google and Mozilla to work on this.
Maybe we should create a Semantic Web community and implement these systems ourselves, as JavaScript libraries with common conventions and a “Semantic Web approved” sticker. And maybe we should develop a Semantic Web browser that can intercept and implement these libraries itself, making them a fallback for traditional Web browsers. If we build up enough support eventually we’ll get new browser competition and regular browsers to start actually adopting the Semantic Web.
But…that creates n + 1 different libraries/protocols that all accomplish the same thing…which is ironic considering “a big problem with the Semantic Web is that a lot of people like to do things their own way”.
It could be worse: we have username/password autofill which has been around for decades so it actually works for 99% of websites.
Because as soon as you do this <table> is no longer a layout element, now it is specifically made for displaying and sorting csv style data.
Here's one of the groups: https://www.w3.org/community/fed-id/
Here is their meeting notes/use case flows, etc: https://github.com/fedidcg/
> The waste of developer and user time due to the Web platform
I think this is because the development is happening at a higher abstraction level (in JS frameworks, mostly). Why? Because those iterate a ton faster. Browsers are slower moving because of complexity, backwards compatibility and distribution. This is similar to the place the browser put the operating system in the 1990s and 2000s.
"The Wheel of Time turns and Ages come and pass."
When you visit a server using mutual TLS, you'll get a prompt showing all your client certificates that match CAs that the server accepts. Once you select one, all your future requests will use that client certificate and be associated with that identity.
The client certificates can even be placed into smart card hardware devices (which can be USB or actual smart cards) that require a PIN or some other factor to use.
Because it's all built on public/private key encryption, the server has no credentials to lose in a data breach. Nobody can steal your credentials and reuse them to attack your other accounts.
And this is supported by all browsers today.
Either way, I usually do not want to login or be prompted to login to sites I visit. When I do want to login, either via Mutual TLS or by entering my credentials, I would like to have a hotkey I can push that brings me to the login page, pushes the login button, or inserts my TLS cert.
If you intentionally did the hard path of owning all your keys then didn't back them up - yes.
But most users would be subscribing to some auth service (Google, their bank, etc) and that organization would have recovery issues.
> I would like to have a hotkey I can push that
This is already super simple with no new tech - just make your login button of class "LoginButton" or something we pick, and the plugin will just click it via code.
The UI really is slick. When the site requests auth the browser pops up a window with the help of the system's secret storage and shows you your identities. This could be automated to avoid even that single popup if desired.
If you lose your ID card, you have to go back to the issuer of ID cards and request a new one. Similarly, with client certificates, you go back to the Certificate Authority to get a new client certificate.
Furthermore, browsers support different kinds of storage for client certificates. You could, in theory, make a cloud hosted client certificate store that you unlock once per session to use with your browser.
Ultimately, it addresses the whole "finding the login button" concern by eliminating login flows from the application completely. If you have no certificate, then you can't access the service at a protocol level, period.
I wish well-known would be actually more... known and used by both websites owners and browsers
Not offering a solution, just complaining.
Partly it's poor ergonomics: a password manager should fill in the credentials for you, and 2FA could be a one-touch token.
I wonder what industry are you in with such intense security requirements.
My password manager saves login URL, so if I click on an item it opens it and fills in login info. If it's on the same page I'm looking at it puts the fields in focus.
Where it fails is when websites implement separate pages for username and password (making me have to autofill twice), and where the login is behind a dropdown.
Depending on a browser and password manager, there must be some way to trigger it via keyboard shortcut.
So, you ask for email first, then you can look up the user and see if the use a password to login, or if they need to be redirected to some other system to manager authentication.
I worked at a company that supported authentication with any of the InCommon Consortium members, and the solution was to provide a drop-down[1] where the user could select their institution (mostly academic or academic-adjacent) and then be directed to the provider to authenticate. As you might imagine, this only worked when there were a handful of institutions and the users were somewhat sophisticated. As of now there are nearly 600 institutions. With that many selection in the dropdown and less sophisticated users, that UX was unsustainable.
1 for example: https://spaces.at.internet2.edu/download/attachments/1686917...
It also has keyboard shortcuts for filling out login details.
We already have Ctrl+K and Ctrl+/, I think it's time to formalize these conventions, and more! There is a gap of semantic interoperability across websites that needs some fixin'.
[1] https://hyperupcall.github.io/blog/posts/semantic-hotkeys/
Ctrl+/ is usually used to show all the keyboard shortcuts, or at least the most common ones. Usable on Discord, Slack, VSCode, etc.
Manually hiding certain elements can make a big difference and I highly encourage trying it out.
You could write an extension and make a case for login/logout/session management and/or generalized hotkeys and go with that into the w3c or ietf to propose an auth mechanism.
I mean, it can be something as simple as having more meaningful aria-attributes on the HTML tags that you parse out and make usable via hotkeys.
It's hard to talk about an idea not yet finished enough so that it can be specified, but I'm sure there is a HUGE need for accessibility improving browser extensions to begin with.
Completely independent of the rendered HTML and no web developer would ever have to work those buttons into the design. They would be like the HOME or BACK buttons.
This kinda exists as "basic auth". The UI is just terrible so nobody uses it. It's not a button though. A button would be pretty nice to be fair.
1. Usernames and passwords sent clear text in URLs.
2. Hijacking is worse than cookie hijacking because you get the permanent credentials with no way to force session invalidation
3. Credentials would be cached (and visible) in browser history
It was a byproduct of the early web and isn't fit for purpose.
It gets even more complicated when I have multiple accounts. Who lets me pick what account I want to use? Is the site responsible for that, or does the browser now need a concept of storing multiple IDs (whatever they might be) and managing them?
It gets extremely complicated extremely fast.
[1] https://github.com/fedidcg/FedCM/blob/main/meetings/2021/Web...
The beauty of decentralisation can also lead to rather long wait times for new standards to establish themselves.
It took meeting a blind developer at work for me to realize how bad parts of the web still are for the visually impaired. And many of the barriers are prevented simply by putting some thought into accessibility in the planning stage.
What needs to happen is for digital signatures need to replace session cookies which can be stolen and are the last frontier in web authentication insecurity.
Both passwords and long term private signing keys would be backed by an encrypted backup for moving identity between devices but for runtime usage TPM or FIDOx would store them, far from the reaches of malware.
There would be no "login" but rather "identity selection" where you have to type in a password to access the private key (1st factor of auth) after which periodically updated challenge tokens by the site are signed by the TPM or FIDOx device for every request.
"Registration" would mean enrolling your public key, that's it. What settings you pick like an account name would be out of scope for the standard. A browser prompt would ask if you want to enroll with a site and have you store the password and related private keys under a named identifier for having multiple accounts.
Account recovery is also handled by browsers. They can backup the backup file in their own or someone else's service along optionally with an alternate key for it. That recovery service would let you manage how to do recovery: just email, some other messaging account, offline keys, a different account,etc... users can also opt-out and backup their keys on a separate FIDOx device theu manually sync.
Now, what I just suggested means cookies for auth will not be needed. Email will not be needed for security/recovery (or hopefully anything else) and mostly eliminate credential theft/phishing including MFA bypass by way of cookie/token theft.
Existing authentication threat models also have you out of scope and unprotected in the event you have operating system malware. This would offer significant risk reduction there.
There is a technique now where you "vnc" stream a remote desktop and webusb for usb devices and authenticate to the real site with even a yubikey and the attacker still gets your session cookie and runs off with it to do what they want. This would force them to have you maintain an active session with them with new signed challenges to maintain access. If the challenge is renewed every minute then at most they have access to your account for one minute after you get phished and close the tab. But more than that, the usual auth prompt is by your browser outside of any tab so even ina full screen tab they would need to make the remote vnc in the tab look like your browser UI which can have a security picture associated with it to prevent just this type of phishing.
What I am against is drastically changing auth workflows without re-thinking auth workflow/UX.
With my idea you kill many birds with one stone. Even the most unaware user can't get phished or easily lose access to their account or have to figure out the right auth UX on a site. And site/app owners just have to get their code to issue new challenge tokens and verify them with their own signing key. No more having to manage and securely store user secrets or support registration/login UI. Better security and risk burdens for everyone!