There was a time when IE was the dominant browser, and happily did whatever they wanted to.
That was arguably better, because at least they acted predictably. Chrome has been continually altering how autocomplete is handled in the last 5 or 6 major releases
Are you being deliberately obtuse? Choice of which browsers to develop for. You had to support IE6 back in the day. Now you have to support Chrome. When they do weird shit you can't say "well that browser is broken", you have to work around it.
Surely most people here are old enough to remember the days of IE6? It wasn't that long ago.
Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.
IE was far more dominant, and browsers actually had meaningful differences back then. Porting CSS written for IE to Firefox could easily take 50% of the initial implementation time, if not 100%. Today, it's not completely uncommon to have something developed on Chrome working in Firefox and Safari without any changes.
And the most significant problem with IE was obviously that it wasn't FOSS, and was only available for Windows. Neither applies to Chrome.
They are now a major user of chromium, and may contribute, but they do not have any say in what goes into chromium. That is still controlled by google employees. If said google employees do not like microsoft patches, they will reject the proposed changes, and microsoft can then at best push them into their own fork.
Google rejecting Microsoft changes has not yet been observed, it could happen.
Most people think that Google agenda could conflict with Microsoft agendas.
I have read a LOT of chromium issues.
I can tell you that the higher management at Google does not dictate chromium changes as they are too technical for them.
The truth is, except for maybe a few exceptions, chromium evolve through the decisions of engineers that want to create the best possible product.
They are not different to Firefox or edge engineers.
Thus they should collaborate pretty well and a Google and Microsoft team should not have more "conflicts" than between two Google internal teams.
As you said for the exceptions, Microsoft can maintain a fork, it's still order of magnitude more economic and smart than to constantly duplicate work in a redundant browser (firefox)
>I can tell you that the higher management at Google does not dictate chromium changes as they are too technical for them.
Tell that to the webRequest API that ablockers use.
>As you said for the exceptions, Microsoft can maintain a fork, it's still order of magnitude more economic and smart than to constantly duplicate work in a redundant browser (firefox)
Chrome is the redundant browser. Firefox was here first.
webRequest API
Well maybe it's an exception, but they have technical reasons mostly.
Webrequest v3 is not stable so wait and see.
Chrome is the redundant browser. Firefox was here first.
Well Chrome is based on khtml which is not that new but yeah Netscape navigator precede it.
Indeed it would have been better if chrome was based on gecko (FF) at the time.
But now Firefox can be thought of the redundant browser because of both marketshare and being technically an inferior product on most metrics.
If mozilla worked on improving chromium, think of the massive progress it would bring to the World!
Website would have no limits on what is possible to create. Everything would be fast, etc.
> webRequest API Well maybe it's an exception, but they have technical reasons mostly. Webrequest v3 is not stable so wait and see.
Bullshit. They decided they wanted this to fuck with adblockers, then found some "technical reasons" they could use as talking points, afterwards. Also, the reasons are apparently so "technical" and "necessary" that google said it would not apply the proposed crippling of webRequest to corporate deployments of Chrome. Corporate users apparently do not need privacy or performance. Go figure.
"B-but user privacy! Extensions can see request" - This is grand coming from google in the first place. Nonetheless, an easy way to solve this is to have special "webrequest" scripts which can apply rules etc, but cannot communicate out, so cannot exfiltrate data.
"B-but performance" - Wasn't a problem so far. If you're really concerned about those 10ms per request an adblocker might add, then either don't run one (and see how your "perf" behaves when all those nice ads load instead), or run one that uses the declarative stuff, which google can still implement additionally.
>If mozilla worked on improving chromium, think of the massive progress it would bring to the World! Website would have no limits on what is possible to create. Everything would be fast, etc.
By "massive progress" you mean outright monopoly on the internet technology for Google? That's not progress. I'm still mad at MS. Instead of taking google's sabotage (you cannot call it anything else really), they shouldn't just obeyed the new goverloads, but sued the living shit out of google. I bet they now a few good antitrust lawyers.
I seriously can't wrap my head around why anyone decided it would somehow be 'okay' to use googles web browser. Because unless you are a Pollyanna coolaid drinker you know where that's going to lead us.
> It seems to reduce the potential for security leaks
Misguided views like this are exactly how. Turning off autocomplete doesn't improve any sort of security, since the site already needs to trust the browser.
It serves no purpose other than to frustrate the user, and might even reduce security if it prevents the user from easily making use of a password manager.
plenty of stuff (like credit card info for instance) should absolutely never be auto-completed. The browser storing that sorta stuff to disk is stupid and completely avoidable.
Already caught chrome doing this to my Social Security Number before i disabled the functionality entirely. The idea of Chrome automatically auto filling any form it sees labeled "SSN" on any site dosen't inspire confidence.
One CRM webapp I worked on took our frontenders several attempts at different hacks to get Chrome to stop treating the SSN-equiv field as a credit card autofill.
Agreed on password fields, however if you have a webapp crm it causes so many problems. And also giving a solution of "hey just put something that we don't understand in the autocomplete so we won't try to autocomplete it" is really not a solution at all.
Imagine if instead of autocomplete it was something like ignoring font sizes/color because they detected that engagement was low when font size was whatever so they render it differently. A browser should render HTML not make decisions like these
This happens when the auto-complete triggers on things it shouldn't and the user doesn't notice and submits personal details they never wanted to send to the site at all.
I've had to struggle a lot with working around Google's wrong-headed approach to this because this actually happens to real users. It's downright irresponsible, and I think frankly it's just a question of time before EU data protection watchdogs starts to take notice. All it will take is a sufficiently bad case of unintended disclosure of personal information (e.g. imagine a domestic abuse victim accidentally having their new address auto-completed in just the wrong situation).
(EDIT: this also easily happens with web apps where someone has to enter details for different users in the same forms multiple times; it get's very easy to end up not noticing Chrome auto-completing details for unrelated users; if that information is later visible to the user, it creates a real risk of leaking personal information)
Combine that with sites attempting to block pasting in a "complex, secure" password and I start to see Google's point here, bad as I don't want to. How "auth" is handled, at almost every layer, seems about as badly broken as "security" in the U.S. banking system.
Fortunately, Firefox gives me dom.event.clipboardevents.enabled so I at least need not worry about my workaround being broken.
Ok, but how is that abuse? And if autocomplete=off is part of the html standard, how are the password managers spec compliant if they can't deal with it? Are people doing this just to annoy users who prefer password managers?
>Are people doing this just to annoy users who prefer password managers?
People are doing it because they don't understand password managers, and think blocking them makes people more secure. They believe that if a password is in a manager, that password is less secure than if that password was purely in the user's head.
If a bug in the password manager leaked the password to your bank to a third party, many users wouldn't want to pay for any associated costs/expenses when a bad guy steals their money.
Yet the bank also doesn't want to take on security audits for code entirely outside their control.
I consider that similar to a bug in the browser or the operating system. Should the bank require that I only use specific browsers or operating systems? In fact any program I install on my computer could have a vulnerability, or be malicious and thus lead to my password being stolen. Should the bank require that I not install any programs except ones they specifically permit?
The bank should also consider which is more frequent: user account compromises due to weak/reused passwords, or user account compromises due to password manager bugs.
Here's the tricky thing and I don't have a solution that doesn't get abused. I hate that lots of bank do this but I also have a use case for password autocomplete=off. We operate in an industry where shared computer access is very common and the risk of users saving password in browser is real and too high.
As I said don't know what the answer is. I definitely want someone using password manager be able to use them. Using a password manager is a conscious choice with setups involved. Browser's default autocomplete is often not. I don't know how to separate these two out.
In theory it is. But for most customers (who are small) there's almost no IT department and the average computer literacy is lower than you might think (though improving) so the risk is there. Except for that situation I would happily leave them autofill/save password.
From previous discussions I remember payment and bank forms use autocomplete=off and chrome developers don't like it, they want card numbers to be pre-filled.
I think some people want to be able to override it because some sites try to block password managers from filling the password field. Since Chrome has a built in password manager, that is likely their motivation to ignore it.
1. Our programming language has an attribute called "autocomplete" with two possible values: "on" and "off"
2. We will now (without consultation or announcement) simply start ignoring one of those values when you specify it. (and certainly not document the new behaviour!)
3. Here, I made you a convoluted (and undocumented!) workaround for getting the original behaviour of the attribute back.
I'm not sure which horse these FAANG kids who excel at programming challenges rode in on, but this attitude is RIFE in their product SDK's and API's.
All that based on an increase in page submissions. Is that the goal of auto-complete?
The research behind the number (25%) is highly dubious, because the video cited as the source doesn't tell how it was done. At all. Ironically, it follows a section on how MDN is documenting the standards, and how that "contribute(s) a lot".
There are more than 20 different valid field name tokens in the spec, not just “on” and “off”[1]. If web developers actually used the other values correctly then user agents wouldn’t need to use heuristics to figure out the correct data to autofill.
> somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users
And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!
It's complicated. Sometimes website authors do silly things that negatively impact users; browsers ought to help (without breaking things!) where possible.
Some daily annoyances that I wish browsers would actively mitigate, in no particular order: js-based redirects, blocking copy-paste, disabling text selection, hijacking the forward slash to open the website's own search function (I'm looking at you, Github), hijacking any of my other keyboard shortcuts that I rely on, creatively breaking my back and forward buttons (yes I realize there are legitimate reasons for some webapps), and overriding the built in right-click context menu.
The things is that there are valid reasons for all those features: JS-based redirects are useful for many webapps, blocking text selection can be useful for some buttons and such, many people do use custom app-specific key mappings, overriding right-click is useful for many apps (e.g. Google docs), etc. etc.
Of course, all those features can also be abused, but that doesn't mean it's a good idea to try and second-guess website authors; that just makes things much much more complicated for everyone.
Any feature can be abused in any platform, and as the web has moved towards an "application platform" – instead of just a document viewing platform – there are many more features with potential for abuse, but it also becomes much more important that behaviour is consistent and predictable.
I'm most definitely not on the "the specification is holy"-side of things, but from what I read in this issue the Chrome team seems surprising tone-deaf to concerns about Chrome's behaviour here. This is general patterns I see with Chrome, which confuses "it works for the majority of cases/users" with "it works well". These are simply not the same things.
Google is allergic to user interaction. No support, no configuration, no choices, no questions, no customization, no power users.
:/
This should be a simple per-site toggle. And/or a per form/input button to do the autocomplete. It usually only matters for the password field, anyway.
Arrgh. I wish shortcuts like this were more discoverable. Shift+right click seems useful and I'll probably end up using it sometime in the future, but I would have never known about it if it were not for this comment. Same as ctrl-L, and for 99% of people F5 and alt+left/right. There should be a page listed in the Firefox menu with a list of useful shortcuts, from most useful (F5, alt+left/right) at the top (so that normal people can get some efficiency gains easily) and going to to more obscure ones like shift+right click so that power users like us can... well, be power users.
They are in control of their servers. They are not in control of how the user agent (clue is in the name) interprets the javascript and HTML sent to it.
It's really frustrating to have to work around this with hit or miss hidden inputs and such.
So many cases too where auto complete misfires an obliterated forms that had helpful placeholder text.
Just having a user change passwords and auto complete will often put an old saved password in the first field but not the second confirmation password field.
> Just having a user change passwords and auto complete will often put an old saved password in the first field but not the second confirmation password field.
You can hint to the browser which password you want to autofill with autocomplete="current-password" and autocomplete="new-password"
I've found that auto complete still sometimes guesses at what to do in that case depending on what the other fields are. At least it did last time I fought with it.
A few years ago, I left a $1000 tip at the restaurant up the street because Chrome filled out the tip field with my zip code (which thankfully merely defaulted to max $1000 instead). The tip field was off-screen, and the ordering software didn't have a confirmation screen, just a "we just charged your card $X amount" screen, which made my eyes boggle.
EDIT: Looking at the original March 17th, 2015 bug, it would have been at exactly around that time...In fact, checking my emails, this happened on March 18th, 2015. I had ordered from them several times before this with no problems (they used "chownow.com" for their ordering backend).
Of course it's allowed. It would be under one of the Merchant Error chargeback codes since the intent was never there to tip $1000 (and it happened due to an error in their software).
If it's not classed under that code there's also 'Friendly Fraud' code for misrepresentation.
Most credit card companies it would be no problem at all. It shouldn’t be necessary though, a quick call to the merchant should be all that is necessary for them to void it.
This has a lot of really serious implications. I built a form for a charity that allowed users to buy a subscription but include an additional donation amount. Chrome was sometimes filling that field with the two-digit year. The charity got a lot of complaints and it ruined the trust relationship with the donors who didn't understand what was happening and thought it was intentional.
Chrome has other behaviour that I think violates a sort of trust relationship. One of which is that Youtube would ask you "do you want to install Chrome"? Almost as if your current browser is not "what you need to access Youtube". This is especially a problem for elderly people who often use the web but don't really understand how things fit together (the way 5 year olds actually do).
> Almost as if your current browser is not "what you need to access Youtube"
This is not just confusing. It's intentionally misleading and unethical.
And it doesn't just affect old people, or YouTube wouldn't have come up with it. Lots of young people grew up with computers and understand how to do what they want to do, but they never develop a systematic understanding of what they're using.
It gets worse, though. While we tech-folk know that all modern browsers are supposed to have near-parity, Google optimizes its sites for Chrome, leading to additional confusion for both knowledgeable and lay users.
We have trouble in our org with autofill on our New Customer forms. Depending on the browser it can be very difficult to remove the saved autocomplete values.
I wonder how much the [1] hiding of scrollbars and [2] UIs with excessive amounts of whitespace, increasing the need to scroll also contributed to you making this error.
The way I see it, autofill off should mean off and if I click the icon in the address bar to bring up, well, let’s call it “quick access to per-site settings” then maybe I could override it for a specific page load or site, like you can Flash, etc.? This per-site configuration is starting to become “normal” given iOS 13 does the same in Safari for permissions, content blocking, automatic reader mode, etc. It would make sense that the default is “follow the HTML5 spec” but you could put a notice in the address bar if you really felt otherwise...?
Safari does a much better job by only filling visible form fields, I think (though it too has a tendency to put my address both in Line 1 and Line 3, which is annoying...).
Curious as to the global business impact this has had. I personally have spent at least a dozen hours debugging forms and trying to disable autocomplete/autofill on my kiosk-based applications. How many development hours collectively have been wasted on this unilateral decision.
I have not been this frustrated since the days of writing css for ie6, and at least back then the devs response was more "sorry its our rendering engine" and not battre just saying GFY seemingly out of disdain.
I try to be as free-market as possible but I sure wish that the w3c had some teeth when it came to things like this.
You're not the only one. I remember spending a good two days on it this year for a page where the user puts in their credentials for external integrations.
I ran into this last week (with LastPass, not Chrome - this seems to be a common practice):
I have a form where users enter information about their suppliers (I make restaurant management software). This includes a field for the contact email address, which LastPass was autofilling the email address the user used to log in. This happened silently, quickly enough that users wouldn't notice it on page transition, and would overwrite the initial value. Even with autocomplete=off.
This was a DATA LOSS bug - users would load the page, make a few changes, save, and not notice that they'd lost the email address they'd stored for the supplier. Fortunately LP has a method to force disabling of autofill (data-lpignore=on), but this could have all been avoided if they'd followed the spec I was relying on. I still don't know if some other password manager, maybe built in to Firefox or something, will make the same mistake, haven't had time to check yet.
Similar thing at my last job. Some internal webapp that was communicating with a bunch of other services. Whenever you edited the connection to such a backend you'd get a bunch of settings to change, as well as - depending on the backend type - credentials to talk to that other service. So if you were saving your credentials to that web app, whenever you edited such a backend connection, it would overwrite the username and password field in that settings page with your credentials for the web app itself. Even though the fields were pre-filled with the current values in the html the server sent you, chrome just went ahead and replaced them on page load. It happened more than once someone accidentally saved the settings and replaced the actual credentials for the backend with their login credentials for the webapp. So anyone accessing that edit page afterwards could steal their coworkers password.
So at some point a colleague went ahead, found the template and added a fake username and password field at the very beginning of the form that had something like "position: absolute; top: -2000" (after an hour of failed attempts with the autofill attribute and using hidden fields and whatnot).
So yes, f*ck those Google devs on their high horse.
The LastPass on is especially horrific because it fills in fields that are already filled, and it fires a change event. So if you're auto-saving on a change event, that data is lost as soon as the page is loaded.
A recent LastPass version does not fail gracefully and a lot of my webapps started getting weird console errors from users with LastPass extensions that were trying to unsuccessfully inject into our forms. :/
Does Chromium not have anyone doing QA or acceptance criteria? A rogue dev lead could make whatever feature they want, but there should be a robust process of testing by many people before the feature makes it in to a production build.
It's odd that the linked bug report references and complains about W3C specs when browser/HTML specs have been coming from WHATWG for well over ten years now. W3C has ceased publishing HTML with W3C HTML 5.2 in 2017, and has announced an intent to merely publish WHATWG snapshots going forward; so far, I'm not aware of any actual work under this model by W3C.
But OTOH that Chromium interprets form field names heuristically to enable auto-autocomplete is worrying, and reflects poorly on the whole "standardization" process by WHATWG.
Indeed. Chrome and Firefox both autocomplete my user name and password into GitHub's new user registration form, even though I already have an account. It's flaky and just asking to be abused.
Because other people here are throwing in their frustrations, I will at least add that on the flip side I have been frustrated by sites that attempt to disable autofill for illegitimate reasons, like attempting to disallow password managers. I think I understand where this is coming from.
On the other hand, I, too, have been bit by this at least once, in the past. I think it was easier to just disable it at that time, but IIRC, the solution we landed on was to not use form controls at all but switch said text controls over to use content-editable elements. In our case it made sense, since it was not a form at all. My memory could be a bit hazy here, though.
(I do not work on Chrome or use Chrome at home, but as disclosure I do currently work at Google.)
Disabling autocomplete is so incredibly frustrating that I ran an extension in Safari to remove the off tag from sites. Of course I want to use KeyChain, the whole point is that touch based ID is more secure.
I have my own extension for Chrome that yanks the autocomplete attribute. I much rather deal with over eager completion than websites disabling it for silly reasons and pseudo security.
Correct, because a fingerprint makes a password to some extent redundant.
> it's just an identifier and shouldn't be treated as a secret
Correct, identifiers are not secrets. Your face is not a secret and your fingerprint either. The problem is that we use secrets to identfy someone, when we potentially already have tech which can identify someone without having to remember a secret and store it in a dictionary of secrets on someone else's computer in the cloud.
The sole purpose of a password is to identify someone with a certain degree of confidence. If a fingerprint taken from a handheld device, which has already been proven to belong to a person, can provide the same if not even a higher level of certainty about someone's identy, then a password or as you say "secret" is not required at all anymore.
Anonymity is weakened if we tie authentication to biometrics. Something you know (as in password) is always theoretically more secure than something you are (your physical characteristics).
Anonymity is of course weakened, but that is a different debate. Currently there is no anonymity at all if your account is linked to your email address, which you've also used to register your online banking account, your credit card verification, your PayPal account, etc. and when you have your mobile phone number confirmed, etc.
A password gives you 0 extra anonymity in this case. All it is used if for "identifycation" and in this regard it sucks in comparison to true biologial identification.
I think the statement you make about "something you know" always being more secure is not nearly as clear cut as you present it.
A combination of "something you know" and "something you have" is always going to be a very strong authentication scenario, and making "something you have" a non-hackable thing that truly only you can have (i.e not a USB key or a TOTP seed etc.) is a good choice.
The catch here is that when you mention biometrics, you make the assumption of static biometrics (rightfully so, as most methods like Touch ID and Face ID are static), but if you combine lets say face biometrics with liveness checks, you are getting into a territory where faking them becomes much much more difficult (there are various mechanisms out there, the good ones rely on completely random interactions and light-bouncing detection methods as an example).
The real challenge is how do you make these very strong biometric methods frictionless and cheap? Or how do you introduce similar controls - like liveness - for easier methods like fingerprints?
And using any of these (ideally) has absolutely nothing to do with anonymity. You are not anonymous online regardless of what you use for authentication - and you are frankly not smart if you assume thats the case. A company offering a service with biometrics is no different from a company doing the same based on email/username and a password, if they do privacy and security right.
I could actually get into a much longer rant about this last part, as it blows my mind how many netizens are all about privacy and whatnot, yet are willing to expose every single detail about them when its convenient from them...
> And using any of these (ideally) has absolutely nothing to do with anonymity. You are not anonymous online regardless of what you use for authentication - and you are frankly not smart if you assume thats the case. A company offering a service with biometrics is no different from a company doing the same based on email/username and a password, if they do privacy and security right.
Why should I use unchangeable, personally identifiable details when logging into some random joe's website? The mechanics of it are also tied to specific devices if I'm not wrong. I can't just login anywhere without risking leaking secrets. When did fingerprints, iris patterns and DNA go from necessary tools in law enforcement and biology (and for highly secure installations) into casual usage all over the place?
You don't have to identify yourself with a "random Joe's website". You can read the comments here without identification, you can seach for flights without identifying yourself, you can search for hotels without giving away who you are, you can read the news, watch YouTube, etc.
But when you want to access something that should only belong to you, e.g. your bank account, your Google Drive files, your private emails, etc. then you must find a way of identifying yourself with given website. Username/password is one way, biometrics is another way.
Only my family has permission to enter my house. When someone enters my house who doesn't look like my family, then they can throw around all secrets, passwords and usernames they want, I'll kick them out, because in my eyes they don't pass the ultimate test of verification, namely biometrics.
So far we were unable to provide the same level of identificaiton via the web, but technology is changing rapidly, so I don't see why username/password are always going to be more secure. On a theoretical basis it doesn't make sense. Because inforation can be easily shared, spread and copied. My physical composition not.
Biometrics are digital interpretations, which can be copied. The biological sources cannot be easily changed. So _when_ the digital copies leak they become a liability.
Passwords can be easily changed. And until reliable, remote, mind reading technology becomes available they'll continue to be better than biometrics.
> Anonymity is weakened if we tie authentication to biometrics.
I think you mean pseudonimity. There should be no authentication in anonimity.
> Something you know (as in password) is always theoretically more secure than something you are (your physical characteristics).
If you authenticate, you can use methods that are more or less secure. If you use a password method, and use a secret as password, it will be more secure than if you use a biometric as password.
But the security of the authentication method will bear no weight on the "pseudonimization" - meaning on the difficulty of linking the authenticated identity with your real, legal identity.
It's effectively like using one password for every app/site authentication. What if the hashes/keys leak out? Then how easy would it be to change your keys for other sites while still using the same biometrics?
The password is to secure that identity. With TouchID or FaceID you are using them for both. Which reduces security.
> then a password or as you say "secret" is not required at all anymore
Definitely incorrect. Someone can cut your finger off, lift a print off your coffee mug, extract it from a selfie etc. There's been dozens of ways to exploit over the years, many of which have hit HN.
> the password is to secure that identity. With TouchID or FaceID you are using them for both. Which reduces security.
You talk absolute nonsense. You ID is not secured by your password LOOOOL. For example, your email is not secure. It is public. I can send you.. drumroll.. a mail there. So is your Facebook username. It is not secure. It is just a name which is public and tells everyone who you are. The password is the only thing that is used to make sure that only you can log in as you. It is a way of identifying that you are you. Nothing else.
> Definitely incorrect. Someone can cut your finger off, lift a print off your coffee mug, extract it from a selfir etc.
There is more and less secure biometrics. There are biometrics, which cannot be copied or cut off that easily. At the end of the day, your biological composition makes you who you are. If someone can truly fake all your biological attributes, then maybe you have a bigger problem than someone logging in with your online account. They probably can do worse things at this point.
How many emails require a password to send to them? None. It's identifier. The password is the security.
Using biometrics - an identifier - for security as well is a compromise for convenience. As you say yourself biometrics make you who you are, they don't secure who you are.
What is the compromise? What is insecure about me being me? Either we talk past each other not understanding each other's point, or I feel like you profoundly misunderstand the reason for people using username/password for authentication nowadays?
With most things you need to authenticate to gain access. Authentication is only trying to solve one question - identifying that a person is who they say they are. If I walk home and my wife sees me, she can identify me immediately by simply seeing my face and other biological attributes which gives her 100% certainty that I am who I am, therefore she doesn't question me on entering the house or calls the police.
If I was to go through some top secret lab experiment which would change my look (make me younger by 10 years or something) then I'd struggle to walk home and convince my wife that I am me without providing additional evidence, like sharing some secrets which only she and I know and we know that nobody else would know.
With technology so far we didn't have the ability to identify someone as confidently and as fast via biometrics (like my wife does) as via other means, which is why a few decades ago we had to invent a workaround, namely username and password - which is a secret that hopefully only me and the website knows. This was to date the best way to identify someone, but times are changing fast, as as biometric identificaiton via technology is advancing fast, we are more and more removing the need of username + password for authentication.
If we had technology that doesn't exist, we could have secure biometrics.
In practice the computer is just getting a picture, which is semi-public information, and that's why the only thing you can rely on is that it's an identifier. It's not enough to authenticate when you really need security, only in more casual situations.
A biometric identifies you. An identity does not inherently authenticate you.
Identification is knowing which account to log in. dustinmoris, User123 or user124.
That alone is useless, as anyone who knows your name could log in. So we need to add security to authenticate you. To authenticate with reasonable certainty that the person accessing dustinmoris actually is Dustin Moris, at this moment willingly accessing their own account, willingly transferring £1m to NeedMoreTea. :)
Now, it's certainly true that biometrics are uniquely associated with you, but prove identity not authentication - bear with me here.
You leak DNA and fingerprints all over the place, constantly. Fingerprints have even been picked up from photos. That makes fingerprints surprisingly weak authentication. Face IDs have been fooled by video and photos. I'm not at all current on what the state of the art on FaceID hacking and devices is, so can't say more there. In a police interview they can place your thumb on the phone or wave phone under your face. Maybe borrow your thumb while you sleep to transfer that £1m. The bank will say you fully authenticated it, in their highly secure app, you will deny it.
In combining biometrics as identification and authentication we've compromised the system. It does not give certainty, or even especially high confidence. If motivated, anyone in your office could lift a print while you're out. Computer or phone says Dustin Moris is believed awake and accessing, but you're certainly not doing so willingly, nor can you resist if just a touch or look unlocks. In this context, your wife might easily pick up on whether you were willing in a police interview or not, the phone can't, because mere identification is the unlock.
With a password they have to persuade you to reveal it. It is very easy to not leak passwords accidentally on PostIts, and manage the complex with a password manager. The police can certainly beat it out of you, but most places are supposed to have rules against that. Many places actually honour those rules. A judge might question the bruises and missing teeth.
For a lot of people that's a fine distinction that doesn't matter, the convenience of it probably being you willingly unlocking the phone with your thumb is good enough. If security actually matters, it's not.
You highlight flaws in faceid, etc but passwords also have flaws.
- Fingerprints can be lifted from pictures.
- Passwords can be forgotten and thus have seriously flawed reset schemes that often fallback to something as simple as having the right phone or backup code.
- passwords can be lifted by keyloggers
- passwords can easily be phished
- passwords can be shared
Authenticating access can come from 1 or more of: something you know, something you have, something you are.
They don't do the same thing. All the flaws in passwords can be avoided, the semi-public state of biometrics cannot.
Authenticating access, if you follow standard security practice, should be at least two of, and preferably all three of: something you know, something you have, something you are. Not one or more.
There is no axiom that the flaws of biometrics cannot be avoided. “Something you know” is in fact a biometric property of the brain that can easily be transferred.
Touch ID combines something you have with something you are. It’s easily better for 99.9% of the threats out there that result from weak passwords shares across sites and users trained to type them into anything that resembles the real logon page.
> The password ... is a way of identifying that you are you.
That is not correct. The "system" identifies you by your ID (username - biometrics - whatever). And for the system to ensure that whatever actions you perform on it, are really coming from you, you have to add proof of your identity to the orders for those actions. You use a secret to create that proof of identity. The secret is yours, the identity is the system's (what it uses to identify you).
If you use something you don't treat as a secret (such as your fingerprint) as your proof of identity, you'll be loosing it left and right - you'll be inviting everyone around to impersonate you. Drinking a can of coke and throwing it to the bin would be the same as printing your password in cards and passing them around.
Your fingerprint is an additional factor (something you are) for the actual better-than-passwords thing here, the isolates processor/storage in your laptop that handles Touch ID (something you have). Without physical possession of the laptop, the fingerprint is useless.
I think we need a way to disable features only for those developers that abuse them. Like uMatrix but built-in and with rules being supplied automatically as ad blocking lists are.
You autocomplete=off a password field? That attribute won't have an effect on your site anymore.
You auto-play videos when the user doesn't expect it? What videos? The web doesn't support videos – as far as you are concerned.
Scroll hijacking? I hope you used progressive enhancement because you just lost your Javascript privileges.
It would only work if a strict list is the default in browsers that developers are not willing not to support. The point is not to hack around user-hostile patterns. That frequently means entering an arms race you cannot win. Even in the best case, you're doing that site developers' job. Badly: You have to remove the bad stuff while avoiding overblocking. That's a lot harder than not adding it to start with.
I'm proposing to take away tools from developers that abuse them no matter how much that breaks. If you mine bitcoins or annoy the user using pop-ups we shouldn't spend time finding out what scripts are good and which are bad but just disable all of them, till you remove the user-hostile stuff. We just broke your SPA? That's your problem. Better start working then.
Can we have a reliable cross-browser way to say "this is a change password field, so don't autocomplete it" and "this is an email address field not a username field, so don't autocomplete it with the login username"?
The web needs strong typing. Right now most input fields are variants of text boxes and there are no naming standards that can be enforced without breaking millions of sites.
The autocomplete="new-password" (or autocomplete="off" or even autocomplete="some-random-nonsense") method is supposed to be doing that according to the spec. It is ignored by browser developers probably due to abuse. Additionally, all of those also trigger the prompt to save the password. For a password change form, that is the right thing to do, for many others it is not.
I'd very much like to see a way to disable that save prompt too, especially in user management screens. When I create a new user, I want neither my own password to be autofilled, nor do I want to overwrite my saved password with theirs.
I asked if something similar was coming to Brave, and the answer was yes. Opera maintained what i believe was a somewhat community powered site patching repository back in the Presto days.
Shouldn't the work on changing the spec, rather then confusing majority of developers and causing even financial loss and embarrassment for many? This thread is filled with cases where this caused issues.
Google should spend their cycles to work on a standard for password managers. The current design of those is flawed anyway.
We recently had to go through a website project and disable autocomplete on all password fields after a security scan as part of a PCI compliance process. For autofill password it didn’t seem to have any effect in _any_ browser I tested in. How can it be used to thwart password managers?
Exactly this. Some of the checks _are_ valuable. We found a couple of real issues and made good security improvements. But we also ticked off more than a few boxes that made no damn real sense.
> SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Blanket disregard of a SHOULD directive as a UX decision neither falls under "in particular circumstances" nor indicates that they've "understood and carefully weighed" the consequences.
There are no semantics to discuss. Chrome is spec compliant. That's a fact. Words like "should" and "must" have well defined meaning that is clarified in every spec document, which I would highly advise you to read before writing any further comments and insults.
Where developers use some type of abstraction that generates a random id for each field and then assigns it to the original value server side or in javascript.
Just like they already randomise asset filenames to avoid caching.
lol, years and years ago (like 2005) as an attempt at stopping XSS and CSRF attacks and bots I came up with a system that named all the inputs a salted MD5 of the intended name with the salt randomly generated then stored in the users server side session.
It’s still a reasonably effective solution for CSRF, though there are much simpler options, but today’s bots largely have cookie jars so you will likely need a CAPTCHA.
How would it stop XSS? Is it meant to stop attackers from getting JS execution on your site, or to mitigate the attackers' abilities after they have JS execution? I don't see how it would do either.
I mean both CSRF and XSS. If your inputs are named something different on everyone’s machine, per session, you can only XSS yourself. Not very useful, you can already do in many other ways.
Also my comment above is not an endorsement of the methodology, it’s just a thing that happened.
Why can you only XSS yourself? If an attacker has javascript execution on the website, the javascript can identify forms not just via their names, but by relation to other elements in the DOM tree. The javascript can for example do
document.querySelector("form > input");
That doesn't rely on names at all. Just like a human can use eyes to find the right input, the javascript can use the DOM tree to find the right input.
I understand that it provides CSRF protection. It's basically a CSRF token embedded in the name.
You misunderstand. Specifically on sites without cross-user visible content, the JavaScript needs to get into the system via an input, POST or GET. When every user input is named something different, you have no ability to send a link with a JavaScript payload.
Hmm, I guess it could provide some protection against some types of XSS, but it's not comprehensive. It doesn't provide any protection against stored XSS. And even for reflected XSS, it assumes the only dynamic thing in your URL is form inputs.
An example of something dynamic in your URL that's not a form input would be links to various articles posted through some type of CMS. For example http://example.com/article?id=foo or even http://example.com/article/foo . In both cases if foo doesn't exist, a badly-written error page could print out "Error, foo was not found" without escaping foo.
Your comment about randomizing filenames got me thinking. It would be great if we could add a cache key to the HTML element, that way we could cache everything forever with the same filenames and still invalidate things by just making the key being the SHA of the deploy. Too bad that's not a thing.
The problems are 1) side channels. Caching those would mean that a malicious script could use timing to find out if the user accessed specific other websites. Also it enables a channel for cross-domain communication. 2) malicious user tracking would not work as well anymore, which would be good but Google probably will not support that. Currently they get all those nice http log entries from sites that only include fonts etc.
For sensitive files with known names, you should be able to set that the cache is only valid for requests from the same host website (as the server might decide to send another response when the host is different). That would fix the sidechannel.
And you are assuming web devs could configure their servers properly. Anyway, it all boils down to the mentality of lowest common denominator: using that workaround, nobody has any incentive to fix their proxy.
MDN literally mentions jquery.disableAutoFill which basically does that for you under the cover (scrambling the name on display, and unscrambling on submission).
They have tagged the field as autocomplete=off but Chrome just doesn't care.
Also see this linked issue where they collected valid use cases for autocomplete=off. They just seem to ignore 452 use cases (I can't comment on the quality of them, I did not read any).
It's called "user agent", not "developer's agent". We'd be in a terrible situation if the browsers just followed developer's whims. Cf. popup blocking.
Dismissing the above use cases as "developer's whims" is the fundamental issue most people here are taking with these decisions.
I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that. We are arguing for following a guideline that makes sense. This is why we have the w3c, an organization that attempts to weigh the needs of user, developers, and browser maintainers.
The issue is that the browser is supposed to be the meeting place for negotiating between developer and user preferences. Its job is to take into account preferences of both sides, and render the site accordingly. Not to be a third party at the negotiating table. Breaking agreed standard in a way that can't be overridden by the user? Browsers should never do that.
I think this could still be confusing as enough users will likely have no idea who "us" is in that message - if they understand the difference between browser and website at all. It could also be confusing if the website already provided its own autocompletion via JS: The user would get a message that autocomplete is turned off while they see that it seems to be right there.
But I think in general, some kind of prompt or override would work. I absolutely agree that if a user wants to use the browser autocomplete functionality, they should have an option to do so. I have no understanding for websites that just want to disable autocomplete without replacement.
However the concerns seemed to be about autocomplete being incorrect or conflicting with application-provided lists. I can see how that leads to frustration and confusion with users.
The Chrome team seems to trust its algorithm to an amount where they don't seem to find it necessary to deal with incorrect results - a view which doesn't match reality apparently.
Correct behavior is debated and decided in public, resulting in a specification. In this case the HTML spec says "should", not "must". HTML Spec:
> When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user.
RFC2119:
> SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
As I read it, this behavior may or may not be a good idea, but it is not a violation of the standard.
Disclosure: I used to work on the Chrome team at Google, but I have no particular knowledge of autocomplete.
GP is explicitly not dismissing the above use cases, but merely the supposed justification of "the developer wants it" being enough.
> I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that.
Should developer be able to make it impossible to close browser or open 100 new tabs? No.
Should developer decide that fields are autocomplete off or green or show javascript warnings? Absolutely yes.
If user wish to change that, users thing. The browser/google has no business to be mediator here, second guess application they know nothing about and manipulate it.
The browser should be predictable, well specified and harmless. It should not force me to convert all ids into random strings just so that random data do not get prefilled in.
I've heard plenty of people on HN say password managers should ignore autocomplete=off and I agree with them. Because that setting is mostly applied by organisations like banks who incorrectly think they're making things more secure by doing so.
IMHO there are cases where autocomplete=off should be respected, and other times when it shouldn't be - it's certainly not as simple as saying always do or always don't respect it.
That was recommended by Google 3 years ago, but there are a bunch of reports in the bug reporter thread that that doesn’t work now. And credentials go beyond passwords - names, usernames, ID numbers
If the user installs extension to auto fill everything, it is on him.
When the browser decided to ignore spec, it is not user agency at all.
The need for auto fill is extremely application specific and the action is quite often destructive. And it is developer who gets to be blamed for lost data.
That's a bit of an appeal to extremes. Visually rendering static HTML per the spec is a situation where a browser "just followed developer's whims", and it's why protocols and standards exist.
That a browser could reliably infer from context what the right information to insert into a field could be is one of those things that gives great demo and may even work more often than not, but it's a virtually impossible problem to solve comprehensively. Developers have plenty of valid reasons to disable autocomplete and autofill functionality. Taking that away from them and requiring an obfuscating workaround is tantamount to creating an invisible pseudo-standard.
Imagine what would happen if we decided to solve the scourge of signed-unsigned pointer value bugs in C++ by having the compiler virally assume unsigned variable typing for memory related operations based on variable name. It might feel like a quick fix to a widespread problem, but it would break down all over the place and would break the code of developers who A) followed the spec B) knew what they were doing and C), at least some of the time, were doing it for a specific purpose.
These sorts of changes remove the incentive to write standards compliant code, leading to a mangled universe of hacks, quirks, and, in the end, bugs.
Unfortunately a few developers are morons who misuse features, and browser vendors try hard to work around them. Case in point, lots of websites used to put `autocomplete="off"` on password boxes, which breaks some password managers. IIRC that’s why Chrome (and other browsers) decided to sometimes ignore the `autocomplete` attribute in the first place. Of course that doesn’t justify ignoring it completely (just for password fields) but maybe a similar reason is at play.
Exactly. Autocomplete=off gets misused. For example, there was a browsergame I played where because of idiotic "security considerations" autocomplete=off got applied to the login screen. At that time for me that meant typing in the password manually, thus picking a bad password.
So it's a good thing in that situation when the browser ignores the attribute.
Very egoistic and ignorant way of viewing things. Disabling autocomplete on login screens has its uses, especially on any app that has shared-terminal type of use, where you cannot trust the user to make the smart choice of not remembering their password - or evening exposing the previous users emails that were used.
You picking a bad password has nothing to do with this feature.
No, it does not have its uses in those scenarios. Every website with login could be used in such a scenario, in an internet cafe for example. It's not on the web developer to predict this, it's on the terminal to prevent that issue.
It has its uses in some very limited scenarios, like a password field in a blog editor that when set locks the article for users not knowing the password. But that's not a login screen.
Me picking a bad password was absolutely caused by this misuse of autocomplete=off, it had everything to do with it. How can you claim otherwise? I was there, you were not.
This has the added benefit of disabling local password managers like PasswordSafe. Might as well throw in some stupid password policy (like maximum password length, or banning some special characters but not explaining which) to make sure stubborn users won't use a secure password even if they're willing to type it in every time.
That's an interesting hack as autocomplete=new-password will generally disable autocomplete.
Though it may not work every time, as browsers & password managers might also suggest new passwords (following whatever their internal generation rules are).
Finally i know why this happens only in Chromium. This irritates me for quite some time now...
Seems that Chromium based browsers aren't favorable any more:
Tracking, Bugs, uBlock extension is flagged, Manifestv3, etc.
But Firefox has the same problem since it ships with Pocket and other sync stuff. I know that they really do care but they have problems of their own which really make me think which browser to use. The actual situation right now is very frustrating...
I use Firefox as my main browser on all my machines and haven't once been bothered about Pocket or other sync stuff. I vastly prefer it, for moral and technical reasons. I feared the switch from Chrome would be very hard and aggravating but it wasn't.
(The only thing that got me the first few weeks is that opening an incognito window is ctrl+shift+p instead of ctrl+shift+n. Once I got used to that I realized it actually makes sense because ctrl+shift+n re-opens a closed window just like ctrl+shift+t reopens a closed tab.)
(Firefox user here) I find that ctrl+shift+n makes more sense: ctrl+n for a new window, add shift for a modified (incognito) new window.
Although whichever shortcut is a very quick habit change to make anyway
I'm guessing chrome ignores, it because people often place the option when they shouldn't. I don't understand why browsers can't simply respect setting and perhaps provide option for the user to modify behavior per site per field with ability to save. They could go even step further and do what Opera used to do i.e. provide same defaults for most popular sites.
In general, I don't like software defaulting to convoluted "grandpa-friendly" behavior instead of the simple, no-bullshit behavior. Moreover, if you want the simple, sane behavior you're a weirdo and need to justify yourself.
Another example of this is chrome hiding "trivial" parts of the URL. i.e. any subdomain that coincides with "www" or "m".
I do not get from where it comes that it is a rogue developer. I have worked in many companies where developers make mistakes. And, it is always the ways of working, giving more priority to features than quality, and similar cultural attributes of the company at fault.
The only time I saw this being a rogue developer was a commit and run done by a guy on his last day.
It is easy to blame one person when actually is a systemic failure that needs to be addressed at the company level.
I agree - and in fact, I think accusing this guy of being rogue is an unnecessary direct attack on him/her.
They are just doing their job, and in this case, acting in what they believe is best way for users. Here on HN, it seems most disagree, but that is still no reason to accuse someone of being rogue.
Headline should be "Google Chrome actively ignores HTML5 standard"
And not following the spec recommendation has gotten us... Here. Where Google is protecting users from both bad actors and good actors, whether the user likes it or not! The overwhelming response to this issue makes it clear that the heuristics used are simply not good ENOUGH. They can't accurately predict the best user outcome in a majority of situations. The Chrome team has wrenched the onus of autofill responsibility from all other developers, then fumbled it, badly. A good fix for this is to give the onus to the user. Popup toggle buttons, labeled: Autofill: Yes, No, Auto. This means we can all stop hating Chrome team for being patronizing, stop hating web devs for being unable to make their beautiful apps work in our godawful browsers, and start hating ourselves instead!
From the spec - The autocomplete attribute represents either:
a) autofill expectation mantle
b) autofill anchor mantle
If the input type is "hidden", then it is wearing the "autofill anchor mantle". IN ALL OTHER CASES (emphasis mine) it wears the "autofill expectation mantle"
And what are the rules on "autofill expectation mantle"?
"When wearing the autofill expectation mantle, the autocomplete attribute, if specified, must have a value that is an ordered set of space-separated tokens consisting of either a single token that is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII case-insensitive match for the string "on", or autofill detail tokens
...
The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; OR THAT THE DOCUMENT PROVIDES ITS OWN AUTOCOMPLETE MECHANISM AND DOES NOT WANT THE USER AGENT TO PROVIDE AUTOCOMPLETION VALUES. (emphasis mine)"
The "should" is in the spec's description of how to interpret "off": "When an element's autofill field name is 'off', the user agent should not remember the control's data, and should not offer past values to the user."
"The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values."
In 4.10.18.7.2...
"When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user.
NOTE: In addition, when an element's autofill field name is "off", values are reset when traversing the history."
@jeffk - Ok, I now understand where you are getting this interpretation.
I think this is a dangerous interpretation (and perhaps it requires altering the spec to say must). Again Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. How else do you propose we do that, other than following 4.10.18.7.1.
My parent was saying Chrome was not compliant with the spec, but SHOULD directives are not mandatory and a User Agent may decide that it would be a worse experience for users to follow them.
Chrome is claiming that enough developers have marked fields as autocomplete=off in user-hostile ways that it shouldn't be respected, while many people here are making the case that conflicts with site-provided autocomplete and other issues push the other direction. That's how to have this discussion, not by pretending this SHOULD is a MUST.
(I don't work on Chrome and don't know any Google-internal anything about this)
Additional food for thought. Elsewhere, in 4.10.5.1.2 (Text (type=text))...
"If the element is mutable, its value SHOULD (emphasis mine) be editable by the user. User agents must not allow users to insert U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters into the element's value."
If a browser offered a user a way to edit immutable fields, or blocked users from editing mutable fields, the discussion should be "is whatever reason they're doing this for strong enough to outweigh the presumption that following the web developer's request is the right thing to do". Not "the spec prohibits it, no matter how good your reason may be".
For example, you can use the browser's devtools to edit an immutable field, because "allowing someone to develop the site" is a strong enough reason.
This is why form elements should never be hidden after loading. Display none should be the default in the HTML for non-relevant content, which should be enough for most autofillers. It also prevents flashing of content when autofillers try to populate it, causing the hiding to delay, which I recently saw in a production app.
Frameworks like React and Vue don’t even render the HTML into the DOM until conditions are met so the situation is improving.
If you want to be malicious and capture wrong auto fill data, wouldn't a simple AJAX request on change be enough to capture sensitive data before the user gets a chance to correct it?
Yes, and there are popular third party analytics platforms that record all activity on a page, which includes not just every key press, but the speed at which it was done, with or without a submission of the form.
Web browsers should never, ever use auto fill unless the user has already entered that information on that domain already. Popular domains that host third party content should never be able to auto fill.
I'm not really sure but I think the behavior is a bit different with autofill. While the browser show the field highlighted, the data is there for _the user_ but the actual form field has not been actually changed and no dom event is fired.
If you think late rendering or "display:none" will put Chrome off, think again! The anvil.works IDE is Angular, so it's all rendered post-loading, and Chrome still autofills the weirdest things. Relentlessly.
Search boxes? Sure! App titles? Yeah, one week a bunch of our users' apps got renamed to the author's email address.
Being an IDE, of course, there are lots of places where inserting random text will break things. When I open up the console and see it filled with "'meredydd@anvil.works' is not a valid Python identifier"? That's the signal to go hunting for which dynamically-generated off-screen text box Chrome is stuffing credentials into this week.
TL;DR Chrome's autofill is out there. It can't be bargained with. It can't be reasoned with. It does not feel pity or remorse. And it will not stop.
That begs the question, at which point does autofill happen in an iframe? So I pay for an ad, and have a password, creditcard number, address etc. form in the background. Does the browser autofil, or does it autofill when the user starts to fill in a form in the foreground?
Well, that's one way it happens. The language is just the set of conventions the speakers understand. When those conventions change, through ignorance or any other reason, then the language changes. That doesn't mean you can't grumble about it as it happens, though.
I used to really, really agree with your line of thinking, and get an almost depressing feeling that this happens. But if you sit back and think about it, a lot of our 'correct' language started off as mistakes. Mayday, Ammunition, Culprit, to name 3 of a list of likely thousands...
Someone made a movie and called it that. It's not really a word. So yes, you proved words can be created. That however is an opposite process to the one that destroys the meaning of an existing word or expression through repetition by people who don't know how to use it. I'm against that kind of half-assery. Creation, art, those take work and discipline. And as much as creativity demands going against convention, you always first have to learn & be aware of what the conventions are. Not even doing that work, and then just claiming your way is just as legitimate as the accepted way for your own mere convenience, well it's a shortcut, and I mean in the best case you have a very slim chance of "just happening" to be a great artist, and in the worst case it's the height of ignorance and narcissism. So yeah I'm unimpressed. I would accept & respect even a deliberate act of transgression -- knowing the right way and doing it wrong on purpose -- before that kind of shoddy relativism.
Technically correct, but look deeper: Why is this mistake prevalent? What are people trying to say that causes them to borrow (misuse) another phrase to express it? This indicates a "hole" in the language that is filled with the wrong item.
Like a code review, do better than just saying "This line is wrong". Suggest an alternative. Especially one that flows naturally into the prose.
I run a site with a normal login/password, but which maintains passwords for other systems. It's pretty frustrating when the internal external usernames are autofilled with the username from our site. It confuses the user, suggesting that the username from the external site should be the same as our own.
When i see something like this, i also remember that Google is basically a private "spy" company, that benefits the most by having all the data they can of each one of us.
So my feeling is theres must be a lot of pressure inside Google management to not let such a feature be turned of, giving this get sent to the 'mothership' as you type, with the lag you take, fingerprinting etc..
Its a big problem that a company that does what Google do, owns the most popular browser client and the most popular mobile OS where they can serve the interests of the mother company against our own self interest where we want our privacy and major political and civil freedoms respected in the process.
Firefox used to ignore autocomplete="off" until relatively recently. I'm sick of sites thinking they know better than me -- like those who don't let me paste in the password field. While I understand the good use cases for this attribute, given the binary choice I would rather have it ignored.
That is absolutely stuff that the user needs to be able to override. In fact, anything related to cutting and pasting is not something I think the browser should mess with.
Also: websites that generate a custom login name or password for me so I won't remember it, and then refuse to allow autofill or pasting. Fortunately dev tools are standard on the desktop these days.
(I would really, really like access to dev tools on mobile, though. It's simply necessary to get around some broken websites.)
382 comments
[ 55.3 ms ] story [ 6802 ms ] threadThat was arguably better, because at least they acted predictably. Chrome has been continually altering how autocomplete is handled in the last 5 or 6 major releases
And there was a choice, back then alternatives like Opera, did actually ship their own engine.
Surely most people here are old enough to remember the days of IE6? It wasn't that long ago.
Plenty of web sites aren't for international consumption.
Not at all, as only 20% of the people using mobile browsers at all, are using Safari.
IE was far more dominant, and browsers actually had meaningful differences back then. Porting CSS written for IE to Firefox could easily take 50% of the initial implementation time, if not 100%. Today, it's not completely uncommon to have something developed on Chrome working in Firefox and Safari without any changes.
And the most significant problem with IE was obviously that it wasn't FOSS, and was only available for Windows. Neither applies to Chrome.
It doesn't matter if Chrome is open-source, when it is technically owned by a single corporation.
They are now a major user of chromium, and may contribute, but they do not have any say in what goes into chromium. That is still controlled by google employees. If said google employees do not like microsoft patches, they will reject the proposed changes, and microsoft can then at best push them into their own fork.
Most people think that Google agenda could conflict with Microsoft agendas. I have read a LOT of chromium issues. I can tell you that the higher management at Google does not dictate chromium changes as they are too technical for them. The truth is, except for maybe a few exceptions, chromium evolve through the decisions of engineers that want to create the best possible product. They are not different to Firefox or edge engineers. Thus they should collaborate pretty well and a Google and Microsoft team should not have more "conflicts" than between two Google internal teams. As you said for the exceptions, Microsoft can maintain a fork, it's still order of magnitude more economic and smart than to constantly duplicate work in a redundant browser (firefox)
You can see a list of their merged pull requests here: https://chromium-review.googlesource.com/q/author:*.microsof...
BTW I really wonder when Apple will switch back to chromium.
Tell that to the webRequest API that ablockers use.
>As you said for the exceptions, Microsoft can maintain a fork, it's still order of magnitude more economic and smart than to constantly duplicate work in a redundant browser (firefox)
Chrome is the redundant browser. Firefox was here first.
Chrome is the redundant browser. Firefox was here first. Well Chrome is based on khtml which is not that new but yeah Netscape navigator precede it. Indeed it would have been better if chrome was based on gecko (FF) at the time. But now Firefox can be thought of the redundant browser because of both marketshare and being technically an inferior product on most metrics.
If mozilla worked on improving chromium, think of the massive progress it would bring to the World! Website would have no limits on what is possible to create. Everything would be fast, etc.
Bullshit. They decided they wanted this to fuck with adblockers, then found some "technical reasons" they could use as talking points, afterwards. Also, the reasons are apparently so "technical" and "necessary" that google said it would not apply the proposed crippling of webRequest to corporate deployments of Chrome. Corporate users apparently do not need privacy or performance. Go figure.
"B-but user privacy! Extensions can see request" - This is grand coming from google in the first place. Nonetheless, an easy way to solve this is to have special "webrequest" scripts which can apply rules etc, but cannot communicate out, so cannot exfiltrate data.
"B-but performance" - Wasn't a problem so far. If you're really concerned about those 10ms per request an adblocker might add, then either don't run one (and see how your "perf" behaves when all those nice ads load instead), or run one that uses the declarative stuff, which google can still implement additionally.
>If mozilla worked on improving chromium, think of the massive progress it would bring to the World! Website would have no limits on what is possible to create. Everything would be fast, etc.
By "massive progress" you mean outright monopoly on the internet technology for Google? That's not progress. I'm still mad at MS. Instead of taking google's sabotage (you cannot call it anything else really), they shouldn't just obeyed the new goverloads, but sued the living shit out of google. I bet they now a few good antitrust lawyers.
Misguided views like this are exactly how. Turning off autocomplete doesn't improve any sort of security, since the site already needs to trust the browser.
It serves no purpose other than to frustrate the user, and might even reduce security if it prevents the user from easily making use of a password manager.
Already caught chrome doing this to my Social Security Number before i disabled the functionality entirely. The idea of Chrome automatically auto filling any form it sees labeled "SSN" on any site dosen't inspire confidence.
One of LastPass's advertised features is credit card autofill. I assume they advertise it because some users like it.
https://www.lastpass.com/autofill
Imagine if instead of autocomplete it was something like ignoring font sizes/color because they detected that engagement was low when font size was whatever so they render it differently. A browser should render HTML not make decisions like these
These developers wouldn't be complaining if the Autofill functionality was activated by a toolbar button rather than automatically.
When chrome devs believe it is their role to alter ux, they are backseat driving.
This happens when the auto-complete triggers on things it shouldn't and the user doesn't notice and submits personal details they never wanted to send to the site at all.
I've had to struggle a lot with working around Google's wrong-headed approach to this because this actually happens to real users. It's downright irresponsible, and I think frankly it's just a question of time before EU data protection watchdogs starts to take notice. All it will take is a sufficiently bad case of unintended disclosure of personal information (e.g. imagine a domestic abuse victim accidentally having their new address auto-completed in just the wrong situation).
(EDIT: this also easily happens with web apps where someone has to enter details for different users in the same forms multiple times; it get's very easy to end up not noticing Chrome auto-completing details for unrelated users; if that information is later visible to the user, it creates a real risk of leaking personal information)
Unfortunately, disabling autocomplete for password fields is an often used form of security-theatre
Fortunately, Firefox gives me dom.event.clipboardevents.enabled so I at least need not worry about my workaround being broken.
People are doing it because they don't understand password managers, and think blocking them makes people more secure. They believe that if a password is in a manager, that password is less secure than if that password was purely in the user's head.
Yet the bank also doesn't want to take on security audits for code entirely outside their control.
One part of that is a proper risk analysis. Password reuse and weak passwords are much bigger risks than a rouge autocompleter.
The bank should also consider which is more frequent: user account compromises due to weak/reused passwords, or user account compromises due to password manager bugs.
As I said don't know what the answer is. I definitely want someone using password manager be able to use them. Using a password manager is a conscious choice with setups involved. Browser's default autocomplete is often not. I don't know how to separate these two out.
https://thycotic.com/company/blog/2013/09/09/securing-web-br...
Sure, stupid devs can still work around that too, but so can they work around the current ingore-always behavior.
https://bugs.chromium.org/p/chromium/issues/detail?id=468153...
1. Our programming language has an attribute called "autocomplete" with two possible values: "on" and "off"
2. We will now (without consultation or announcement) simply start ignoring one of those values when you specify it. (and certainly not document the new behaviour!)
3. Here, I made you a convoluted (and undocumented!) workaround for getting the original behaviour of the attribute back.
I'm not sure which horse these FAANG kids who excel at programming challenges rode in on, but this attitude is RIFE in their product SDK's and API's.
Dijkstra must be spinning in his grave.
The research behind the number (25%) is highly dubious, because the video cited as the source doesn't tell how it was done. At all. Ironically, it follows a section on how MDN is documenting the standards, and how that "contribute(s) a lot".
[1] https://html.spec.whatwg.org/multipage/form-control-infrastr...
And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!
Some daily annoyances that I wish browsers would actively mitigate, in no particular order: js-based redirects, blocking copy-paste, disabling text selection, hijacking the forward slash to open the website's own search function (I'm looking at you, Github), hijacking any of my other keyboard shortcuts that I rely on, creatively breaking my back and forward buttons (yes I realize there are legitimate reasons for some webapps), and overriding the built in right-click context menu.
Of course, all those features can also be abused, but that doesn't mean it's a good idea to try and second-guess website authors; that just makes things much much more complicated for everyone.
Any feature can be abused in any platform, and as the web has moved towards an "application platform" – instead of just a document viewing platform – there are many more features with potential for abuse, but it also becomes much more important that behaviour is consistent and predictable.
I'm most definitely not on the "the specification is holy"-side of things, but from what I read in this issue the Chrome team seems surprising tone-deaf to concerns about Chrome's behaviour here. This is general patterns I see with Chrome, which confuses "it works for the majority of cases/users" with "it works well". These are simply not the same things.
:/
This should be a simple per-site toggle. And/or a per form/input button to do the autocomplete. It usually only matters for the password field, anyway.
So many cases too where auto complete misfires an obliterated forms that had helpful placeholder text.
Just having a user change passwords and auto complete will often put an old saved password in the first field but not the second confirmation password field.
You can hint to the browser which password you want to autofill with autocomplete="current-password" and autocomplete="new-password"
EDIT: Looking at the original March 17th, 2015 bug, it would have been at exactly around that time...In fact, checking my emails, this happened on March 18th, 2015. I had ordered from them several times before this with no problems (they used "chownow.com" for their ordering backend).
In certain cases, a previously-entered zip code was interpreted as the number of cents to tip.
If it's not classed under that code there's also 'Friendly Fraud' code for misrepresentation.
This is not just confusing. It's intentionally misleading and unethical.
And it doesn't just affect old people, or YouTube wouldn't have come up with it. Lots of young people grew up with computers and understand how to do what they want to do, but they never develop a systematic understanding of what they're using.
It gets worse, though. While we tech-folk know that all modern browsers are supposed to have near-parity, Google optimizes its sites for Chrome, leading to additional confusion for both knowledgeable and lay users.
I wonder how much the [1] hiding of scrollbars and [2] UIs with excessive amounts of whitespace, increasing the need to scroll also contributed to you making this error.
Safari does a much better job by only filling visible form fields, I think (though it too has a tendency to put my address both in Line 1 and Line 3, which is annoying...).
I have not been this frustrated since the days of writing css for ie6, and at least back then the devs response was more "sorry its our rendering engine" and not battre just saying GFY seemingly out of disdain.
I try to be as free-market as possible but I sure wish that the w3c had some teeth when it came to things like this.
I have a form where users enter information about their suppliers (I make restaurant management software). This includes a field for the contact email address, which LastPass was autofilling the email address the user used to log in. This happened silently, quickly enough that users wouldn't notice it on page transition, and would overwrite the initial value. Even with autocomplete=off.
This was a DATA LOSS bug - users would load the page, make a few changes, save, and not notice that they'd lost the email address they'd stored for the supplier. Fortunately LP has a method to force disabling of autofill (data-lpignore=on), but this could have all been avoided if they'd followed the spec I was relying on. I still don't know if some other password manager, maybe built in to Firefox or something, will make the same mistake, haven't had time to check yet.
So at some point a colleague went ahead, found the template and added a fake username and password field at the very beginning of the form that had something like "position: absolute; top: -2000" (after an hour of failed attempts with the autofill attribute and using hidden fields and whatnot).
So yes, f*ck those Google devs on their high horse.
But OTOH that Chromium interprets form field names heuristically to enable auto-autocomplete is worrying, and reflects poorly on the whole "standardization" process by WHATWG.
On the other hand, I, too, have been bit by this at least once, in the past. I think it was easier to just disable it at that time, but IIRC, the solution we landed on was to not use form controls at all but switch said text controls over to use content-editable elements. In our case it made sense, since it was not a form at all. My memory could be a bit hazy here, though.
(I do not work on Chrome or use Chrome at home, but as disclosure I do currently work at Google.)
Correct, because a fingerprint makes a password to some extent redundant.
> it's just an identifier and shouldn't be treated as a secret
Correct, identifiers are not secrets. Your face is not a secret and your fingerprint either. The problem is that we use secrets to identfy someone, when we potentially already have tech which can identify someone without having to remember a secret and store it in a dictionary of secrets on someone else's computer in the cloud.
The sole purpose of a password is to identify someone with a certain degree of confidence. If a fingerprint taken from a handheld device, which has already been proven to belong to a person, can provide the same if not even a higher level of certainty about someone's identy, then a password or as you say "secret" is not required at all anymore.
A password gives you 0 extra anonymity in this case. All it is used if for "identifycation" and in this regard it sucks in comparison to true biologial identification.
A combination of "something you know" and "something you have" is always going to be a very strong authentication scenario, and making "something you have" a non-hackable thing that truly only you can have (i.e not a USB key or a TOTP seed etc.) is a good choice.
The catch here is that when you mention biometrics, you make the assumption of static biometrics (rightfully so, as most methods like Touch ID and Face ID are static), but if you combine lets say face biometrics with liveness checks, you are getting into a territory where faking them becomes much much more difficult (there are various mechanisms out there, the good ones rely on completely random interactions and light-bouncing detection methods as an example).
The real challenge is how do you make these very strong biometric methods frictionless and cheap? Or how do you introduce similar controls - like liveness - for easier methods like fingerprints?
And using any of these (ideally) has absolutely nothing to do with anonymity. You are not anonymous online regardless of what you use for authentication - and you are frankly not smart if you assume thats the case. A company offering a service with biometrics is no different from a company doing the same based on email/username and a password, if they do privacy and security right.
I could actually get into a much longer rant about this last part, as it blows my mind how many netizens are all about privacy and whatnot, yet are willing to expose every single detail about them when its convenient from them...
Why should I use unchangeable, personally identifiable details when logging into some random joe's website? The mechanics of it are also tied to specific devices if I'm not wrong. I can't just login anywhere without risking leaking secrets. When did fingerprints, iris patterns and DNA go from necessary tools in law enforcement and biology (and for highly secure installations) into casual usage all over the place?
But when you want to access something that should only belong to you, e.g. your bank account, your Google Drive files, your private emails, etc. then you must find a way of identifying yourself with given website. Username/password is one way, biometrics is another way.
Only my family has permission to enter my house. When someone enters my house who doesn't look like my family, then they can throw around all secrets, passwords and usernames they want, I'll kick them out, because in my eyes they don't pass the ultimate test of verification, namely biometrics.
So far we were unable to provide the same level of identificaiton via the web, but technology is changing rapidly, so I don't see why username/password are always going to be more secure. On a theoretical basis it doesn't make sense. Because inforation can be easily shared, spread and copied. My physical composition not.
Passwords can be easily changed. And until reliable, remote, mind reading technology becomes available they'll continue to be better than biometrics.
I think you mean pseudonimity. There should be no authentication in anonimity.
> Something you know (as in password) is always theoretically more secure than something you are (your physical characteristics).
If you authenticate, you can use methods that are more or less secure. If you use a password method, and use a secret as password, it will be more secure than if you use a biometric as password.
But the security of the authentication method will bear no weight on the "pseudonimization" - meaning on the difficulty of linking the authenticated identity with your real, legal identity.
The password is to secure that identity. With TouchID or FaceID you are using them for both. Which reduces security.
> then a password or as you say "secret" is not required at all anymore
Definitely incorrect. Someone can cut your finger off, lift a print off your coffee mug, extract it from a selfie etc. There's been dozens of ways to exploit over the years, many of which have hit HN.
You talk absolute nonsense. You ID is not secured by your password LOOOOL. For example, your email is not secure. It is public. I can send you.. drumroll.. a mail there. So is your Facebook username. It is not secure. It is just a name which is public and tells everyone who you are. The password is the only thing that is used to make sure that only you can log in as you. It is a way of identifying that you are you. Nothing else.
> Definitely incorrect. Someone can cut your finger off, lift a print off your coffee mug, extract it from a selfir etc.
There is more and less secure biometrics. There are biometrics, which cannot be copied or cut off that easily. At the end of the day, your biological composition makes you who you are. If someone can truly fake all your biological attributes, then maybe you have a bigger problem than someone logging in with your online account. They probably can do worse things at this point.
Using biometrics - an identifier - for security as well is a compromise for convenience. As you say yourself biometrics make you who you are, they don't secure who you are.
With most things you need to authenticate to gain access. Authentication is only trying to solve one question - identifying that a person is who they say they are. If I walk home and my wife sees me, she can identify me immediately by simply seeing my face and other biological attributes which gives her 100% certainty that I am who I am, therefore she doesn't question me on entering the house or calls the police.
If I was to go through some top secret lab experiment which would change my look (make me younger by 10 years or something) then I'd struggle to walk home and convince my wife that I am me without providing additional evidence, like sharing some secrets which only she and I know and we know that nobody else would know.
With technology so far we didn't have the ability to identify someone as confidently and as fast via biometrics (like my wife does) as via other means, which is why a few decades ago we had to invent a workaround, namely username and password - which is a secret that hopefully only me and the website knows. This was to date the best way to identify someone, but times are changing fast, as as biometric identificaiton via technology is advancing fast, we are more and more removing the need of username + password for authentication.
Hope now my point makes sense.
In practice the computer is just getting a picture, which is semi-public information, and that's why the only thing you can rely on is that it's an identifier. It's not enough to authenticate when you really need security, only in more casual situations.
Identification is knowing which account to log in. dustinmoris, User123 or user124.
That alone is useless, as anyone who knows your name could log in. So we need to add security to authenticate you. To authenticate with reasonable certainty that the person accessing dustinmoris actually is Dustin Moris, at this moment willingly accessing their own account, willingly transferring £1m to NeedMoreTea. :)
Now, it's certainly true that biometrics are uniquely associated with you, but prove identity not authentication - bear with me here.
You leak DNA and fingerprints all over the place, constantly. Fingerprints have even been picked up from photos. That makes fingerprints surprisingly weak authentication. Face IDs have been fooled by video and photos. I'm not at all current on what the state of the art on FaceID hacking and devices is, so can't say more there. In a police interview they can place your thumb on the phone or wave phone under your face. Maybe borrow your thumb while you sleep to transfer that £1m. The bank will say you fully authenticated it, in their highly secure app, you will deny it.
In combining biometrics as identification and authentication we've compromised the system. It does not give certainty, or even especially high confidence. If motivated, anyone in your office could lift a print while you're out. Computer or phone says Dustin Moris is believed awake and accessing, but you're certainly not doing so willingly, nor can you resist if just a touch or look unlocks. In this context, your wife might easily pick up on whether you were willing in a police interview or not, the phone can't, because mere identification is the unlock.
With a password they have to persuade you to reveal it. It is very easy to not leak passwords accidentally on PostIts, and manage the complex with a password manager. The police can certainly beat it out of you, but most places are supposed to have rules against that. Many places actually honour those rules. A judge might question the bruises and missing teeth.
For a lot of people that's a fine distinction that doesn't matter, the convenience of it probably being you willingly unlocking the phone with your thumb is good enough. If security actually matters, it's not.
Sorry that got a bit long.
- Fingerprints can be lifted from pictures. - Passwords can be forgotten and thus have seriously flawed reset schemes that often fallback to something as simple as having the right phone or backup code. - passwords can be lifted by keyloggers - passwords can easily be phished - passwords can be shared
Authenticating access can come from 1 or more of: something you know, something you have, something you are.
They each have flaws. They all do the same thing.
Authenticating access, if you follow standard security practice, should be at least two of, and preferably all three of: something you know, something you have, something you are. Not one or more.
Touch ID combines something you have with something you are. It’s easily better for 99.9% of the threats out there that result from weak passwords shares across sites and users trained to type them into anything that resembles the real logon page.
That is not correct. The "system" identifies you by your ID (username - biometrics - whatever). And for the system to ensure that whatever actions you perform on it, are really coming from you, you have to add proof of your identity to the orders for those actions. You use a secret to create that proof of identity. The secret is yours, the identity is the system's (what it uses to identify you).
If you use something you don't treat as a secret (such as your fingerprint) as your proof of identity, you'll be loosing it left and right - you'll be inviting everyone around to impersonate you. Drinking a can of coke and throwing it to the bin would be the same as printing your password in cards and passing them around.
You autocomplete=off a password field? That attribute won't have an effect on your site anymore.
You auto-play videos when the user doesn't expect it? What videos? The web doesn't support videos – as far as you are concerned.
Scroll hijacking? I hope you used progressive enhancement because you just lost your Javascript privileges.
I'm proposing to take away tools from developers that abuse them no matter how much that breaks. If you mine bitcoins or annoy the user using pop-ups we shouldn't spend time finding out what scripts are good and which are bad but just disable all of them, till you remove the user-hostile stuff. We just broke your SPA? That's your problem. Better start working then.
I'd very much like to see a way to disable that save prompt too, especially in user management screens. When I create a new user, I want neither my own password to be autofilled, nor do I want to overwrite my saved password with theirs.
https://news.ycombinator.com/item?id=20831774
They could still follow it for other fields.
0: https://chromium.googlesource.com/chromium/src/+/master/docs...
Google should spend their cycles to work on a standard for password managers. The current design of those is flawed anyway.
PCI compliance is about checking boxes, not weighing the options and making good choices.
Is it “extreme” now for a computer to do what the user wants and not what a random Google employee wants? How does this differ from malware?
People might not like the spec or it might be incomplete, but adhering to it is a very important part of improving it until it's a good one.
Now I'm no webdev, but I could very well imagine that the spec is already a good one. So the situation might be even worse.
Not arguing in favor of this particular choice, but yes. That is exactly what "should" means in most cases.
For instance, in RFC 2119: https://tools.ietf.org/html/rfc2119
> SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Just like they already randomise asset filenames to avoid caching.
It’s still a reasonably effective solution for CSRF, though there are much simpler options, but today’s bots largely have cookie jars so you will likely need a CAPTCHA.
Also my comment above is not an endorsement of the methodology, it’s just a thing that happened.
document.querySelector("form > input");
That doesn't rely on names at all. Just like a human can use eyes to find the right input, the javascript can use the DOM tree to find the right input.
I understand that it provides CSRF protection. It's basically a CSRF token embedded in the name.
An example of something dynamic in your URL that's not a form input would be links to various articles posted through some type of CMS. For example http://example.com/article?id=foo or even http://example.com/article/foo . In both cases if foo doesn't exist, a badly-written error page could print out "Error, foo was not found" without escaping foo.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Seems like it would be crazy not to use it for caching.
But why? Isn't the whole point of caching to improve delivery if static assets?
Did they run into staleness problems? Then why not use if-modified-since/if-none-match?
https://i.imgur.com/BjYTgSn.png
They have tagged the field as autocomplete=off but Chrome just doesn't care.
Also see this linked issue where they collected valid use cases for autocomplete=off. They just seem to ignore 452 use cases (I can't comment on the quality of them, I did not read any).
https://bugs.chromium.org/p/chromium/issues/detail?id=587466
Literally that and nothing more.
I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that. We are arguing for following a guideline that makes sense. This is why we have the w3c, an organization that attempts to weigh the needs of user, developers, and browser maintainers.
if you would like to autofill the form anyway click"
i made it a little terse, but there has to be a way to make it succinct and human readable.
But I think in general, some kind of prompt or override would work. I absolutely agree that if a user wants to use the browser autocomplete functionality, they should have an option to do so. I have no understanding for websites that just want to disable autocomplete without replacement.
However the concerns seemed to be about autocomplete being incorrect or conflicting with application-provided lists. I can see how that leads to frustration and confusion with users.
The Chrome team seems to trust its algorithm to an amount where they don't seem to find it necessary to deal with incorrect results - a view which doesn't match reality apparently.
This was done by Microsoft by the old days, now it's Google. How ironic.
> When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user.
RFC2119:
> SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
As I read it, this behavior may or may not be a good idea, but it is not a violation of the standard.
Disclosure: I used to work on the Chrome team at Google, but I have no particular knowledge of autocomplete.
> I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that.
GGP was literally arguing that: https://news.ycombinator.com/item?id=21239172
Should developer decide that fields are autocomplete off or green or show javascript warnings? Absolutely yes.
If user wish to change that, users thing. The browser/google has no business to be mediator here, second guess application they know nothing about and manipulate it.
The browser should be predictable, well specified and harmless. It should not force me to convert all ids into random strings just so that random data do not get prefilled in.
IMHO there are cases where autocomplete=off should be respected, and other times when it shouldn't be - it's certainly not as simple as saying always do or always don't respect it.
IMO the distinction could be made to not automatically fill when the autocomplete=off but instead add a button to let the user initiate it
> This is the behavior in Firefox (since version 38), Google Chrome (since 34), and Internet Explorer (since version 11). - MDN
I was pretty sure that it wouldn't do anything except make the security team feel better.
Well, OP that I responded to literally argued that.
I agree the platform needs to expose useful features in a predictable manner for application developers.
But I'd much rather have browsers decide what's reasonable control over the user experience.
When the browser decided to ignore spec, it is not user agency at all.
The need for auto fill is extremely application specific and the action is quite often destructive. And it is developer who gets to be blamed for lost data.
It's pretty annoying that we have to make hacks for a client card page not to automatically assume you want to fill in your own details.
That a browser could reliably infer from context what the right information to insert into a field could be is one of those things that gives great demo and may even work more often than not, but it's a virtually impossible problem to solve comprehensively. Developers have plenty of valid reasons to disable autocomplete and autofill functionality. Taking that away from them and requiring an obfuscating workaround is tantamount to creating an invisible pseudo-standard.
Imagine what would happen if we decided to solve the scourge of signed-unsigned pointer value bugs in C++ by having the compiler virally assume unsigned variable typing for memory related operations based on variable name. It might feel like a quick fix to a widespread problem, but it would break down all over the place and would break the code of developers who A) followed the spec B) knew what they were doing and C), at least some of the time, were doing it for a specific purpose.
These sorts of changes remove the incentive to write standards compliant code, leading to a mangled universe of hacks, quirks, and, in the end, bugs.
YouTubeTV uses feature policy to disable the browser's picture-in-picture feature.
So it's a good thing in that situation when the browser ignores the attribute.
You picking a bad password has nothing to do with this feature.
It has its uses in some very limited scenarios, like a password field in a blog editor that when set locks the article for users not knowing the password. But that's not a login screen.
Me picking a bad password was absolutely caused by this misuse of autocomplete=off, it had everything to do with it. How can you claim otherwise? I was there, you were not.
E: as soon as you submit a search on sbb.ch, the same problem occurs.
https://i.imgur.com/NlzVqhT.png
and here's what it looks like when I enter 's':
https://i.imgur.com/1u4Iy7S.png
(actually, S does not autocomplete in the Swiss site)
I always concluded that it was the fault of the website creators. Guess I have to switch to Firefox...
<input id="fromField" type="text" inputmode="text" class="mod_textfield_control" placeholder="Von" autocomplete="new-password"...
Though, there is also a lot of other stuff going on in that html element I don't understand.
Though it may not work every time, as browsers & password managers might also suggest new passwords (following whatever their internal generation rules are).
Seems that Chromium based browsers aren't favorable any more: Tracking, Bugs, uBlock extension is flagged, Manifestv3, etc.
But Firefox has the same problem since it ships with Pocket and other sync stuff. I know that they really do care but they have problems of their own which really make me think which browser to use. The actual situation right now is very frustrating...
(The only thing that got me the first few weeks is that opening an incognito window is ctrl+shift+p instead of ctrl+shift+n. Once I got used to that I realized it actually makes sense because ctrl+shift+n re-opens a closed window just like ctrl+shift+t reopens a closed tab.)
Not ideal, but worked!
Another example of this is chrome hiding "trivial" parts of the URL. i.e. any subdomain that coincides with "www" or "m".
The only time I saw this being a rogue developer was a commit and run done by a guy on his last day.
It is easy to blame one person when actually is a systemic failure that needs to be addressed at the company level.
They are just doing their job, and in this case, acting in what they believe is best way for users. Here on HN, it seems most disagree, but that is still no reason to accuse someone of being rogue.
Headline should be "Google Chrome actively ignores HTML5 standard"
(Disclosure: I work for Google)
From the spec - The autocomplete attribute represents either:
a) autofill expectation mantle
b) autofill anchor mantle
If the input type is "hidden", then it is wearing the "autofill anchor mantle". IN ALL OTHER CASES (emphasis mine) it wears the "autofill expectation mantle"
And what are the rules on "autofill expectation mantle"?
"When wearing the autofill expectation mantle, the autocomplete attribute, if specified, must have a value that is an ordered set of space-separated tokens consisting of either a single token that is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII case-insensitive match for the string "on", or autofill detail tokens
...
The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; OR THAT THE DOCUMENT PROVIDES ITS OWN AUTOCOMPLETE MECHANISM AND DOES NOT WANT THE USER AGENT TO PROVIDE AUTOCOMPLETION VALUES. (emphasis mine)"
Per: https://html.spec.whatwg.org/multipage/form-control-infrastr...
In 4.10.18.7.1...
"The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values."
In 4.10.18.7.2...
"When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user.
NOTE: In addition, when an element's autofill field name is "off", values are reset when traversing the history."
@jeffk - Ok, I now understand where you are getting this interpretation.
I think this is a dangerous interpretation (and perhaps it requires altering the spec to say must). Again Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. How else do you propose we do that, other than following 4.10.18.7.1.
Chrome is claiming that enough developers have marked fields as autocomplete=off in user-hostile ways that it shouldn't be respected, while many people here are making the case that conflicts with site-provided autocomplete and other issues push the other direction. That's how to have this discussion, not by pretending this SHOULD is a MUST.
(I don't work on Chrome and don't know any Google-internal anything about this)
"If the element is mutable, its value SHOULD (emphasis mine) be editable by the user. User agents must not allow users to insert U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters into the element's value."
https://html.spec.whatwg.org/multipage/input.html
So, according to this spec, the UA is allowed to make an input field type=text non-editable if it so chooses.
Would you argue that this is another place where Chrome would be allowed to act in a manner differently than expected, because "SHOULD" was used?
For example, you can use the browser's devtools to edit an immutable field, because "allowing someone to develop the site" is a strong enough reason.
Frameworks like React and Vue don’t even render the HTML into the DOM until conditions are met so the situation is improving.
Another positive step away from jQuery hackery!
Web browsers should never, ever use auto fill unless the user has already entered that information on that domain already. Popular domains that host third party content should never be able to auto fill.
Search boxes? Sure! App titles? Yeah, one week a bunch of our users' apps got renamed to the author's email address.
Being an IDE, of course, there are lots of places where inserting random text will break things. When I open up the console and see it filled with "'meredydd@anvil.works' is not a valid Python identifier"? That's the signal to go hunting for which dynamically-generated off-screen text box Chrome is stuffing credentials into this week.
TL;DR Chrome's autofill is out there. It can't be bargained with. It can't be reasoned with. It does not feel pity or remorse. And it will not stop.
Asking for a friend.
Offtopic, but no it doesn't [1].
[1] https://grammarist.com/rhetoric/begging-the-question-fallacy...
(p.s. not saying there's no wrong or right when it comes to ideas themselves)
"I _could_ care less (but I can't be bothered)."
I still have to come to terms with it.
Like a code review, do better than just saying "This line is wrong". Suggest an alternative. Especially one that flows naturally into the prose.
It's okay to say something with the same words as an idiom, without using the idiom.
The idiom was a mistake/mistranslation in the first place.
You're trying to push people away from the correct use of the word 'begs' into an incorrect use just because it's tradition.
You cannot switch off Chrome's handling of autocomplete, thus any other autocomplete implementation will be overwritten by Chrome's handling.
Chrome team feel they know best.
So my feeling is theres must be a lot of pressure inside Google management to not let such a feature be turned of, giving this get sent to the 'mothership' as you type, with the lag you take, fingerprinting etc..
Its a big problem that a company that does what Google do, owns the most popular browser client and the most popular mobile OS where they can serve the interests of the mother company against our own self interest where we want our privacy and major political and civil freedoms respected in the process.
What they're becoming is ie6.
Also: websites that generate a custom login name or password for me so I won't remember it, and then refuse to allow autofill or pasting. Fortunately dev tools are standard on the desktop these days.
(I would really, really like access to dev tools on mobile, though. It's simply necessary to get around some broken websites.)
Are we seriously expected to entertain this mess?
So glad I switched to Firefox all those years ago.
https://bugs.chromium.org/p/chromium/issues/detail?id=587466