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).
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.
In certain cases, a previously-entered zip code was interpreted as the number of cents to tip.
I wonder how much the  hiding of scrollbars and  UIs with excessive amounts of whitespace, increasing the need to scroll also contributed to you making this error.
If it's not classed under that code there's also 'Friendly Fraud' code for misrepresentation.
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).
Literally that and nothing more.
YouTubeTV uses feature policy to disable the browser's picture-in-picture feature.
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.
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.
> 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.
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.
> 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
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
<input type="password" name="other-users-password" id="other-users-password">...
> 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.
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.
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.
So it's a good thing in that situation when the browser ignores the attribute.
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.
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.)
E: as soon as you submit a search on sbb.ch, the same problem occurs.
and here's what it looks like when I enter 's':
(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).
Another example of this is chrome hiding "trivial" parts of the URL. i.e. any subdomain that coincides with "www" or "m".
Not ideal, but worked!
Their tactic of overruling web developers doesn't work, it only make things more complicated for everyone, since many of the workarounds have other negative side-effects.
## Example 1
For a reliable workaround, you can add this code to your layout page:
<div style="display: none;">
<input type="text" id="PreventChromeAutocomplete"
name="PreventChromeAutocomplete" autocomplete="address-level4" />
Chrome respects autocomplete=off only when there is at least
one other input element in the form with any other autocomplete value.
## Example 2
Simply make your input readonly, and on focus, remove it. This is a very
simple approach and browsers will not populate readonly inputs.
Therefore, this method is accepted and will never be overwritten by
future browser updates.
<input type="text" onfocus="this.removeAttribute('readonly');" readonly />
Style your input accordingly so that it does not look like a readonly input.
## Example 3
Tell Chrome that this is a new password input and it won't provide
old ones as autocomplete suggestions:
<input type="password" name="password" autocomplete="new-password">
Naturally the problem is choice. Chrome/G should show a button to auto fill fields.
They could simply unleash some AI magic, train a network to recognize good and bad sites, etc. (Aka. the Apple way. As they also have a we know better policy, and users seem to love that.)
I wouldn't recommend it for public use. There's a lot of subtle behaviour around an input field that you'd need to replicate manually.
great dash use! i almost read that as a race of sad chickens (seriously) but the dash autocorrected me. bravo!
We are becoming more and more reliant on the developers of Chromium to be steadfast stewards of the standardization process. Their massive influence means that any deviation from actual web standards on their part will inevitably create a new and conflicting de-facto standard that will create decades of lasting damage and irreversible tech debt for the entire web (eventually leading to a repeat of the IE6 dark ages).
Decisions like this demonstrate an utter disregard for the crucial role Chromium plays in the web standardization process, and jeopardizes the entire ecosystem.
Analogously to how users are able to selectively grant access to certain default-off features for each website (notifications, camera access), users should also be able to revoke access to certain default-on features for sites that abuse them without affecting the vast majority of sites that use the features for their intended purposes to create a better user experience.
Honestly it seems strange that they go against the standard though considering how much power they have in defining it. Why break from the standard when you can just update the standard. It ends up being the worst of both worlds - documentation that says one thing (that they had a hand in building) and an implementation that does something completely different.
First is the scrollbar thing I mentioned. It means that you can’t use it for layout purposes; you thought you could sit four blocks side-by-side with `width: 25vw`? (And that was pretty much the whole reason why people wanted viewport units in the first place—this being before flexbox provided alternatives that are generally acceptable, though not without flaws, or grid provided often better alternatives.) Sorry, that’ll only work on a platform with overlay scrollbars, not where scrollbars actually take up space. There’s fun history around Firefox’s implementation where they made it possible to get the “right” behaviour, but no one else implemented that, so it was eventually removed from the spec.
Secondly, it was also predicated on the idea that the physical viewport size won’t be changing all the time; but on mobile platforms where the address bar can get out of the way as you scroll that’s simply not true, so you’re stuck with browsers having to decide between two interpretations: vh picking either the smallest or largest value and thus not actually reflecting the viewport height half the time, or vh reflecting the viewport height and causing the page layout to jump around in a jarring fashion when the address bar expands or collapses, when vh is used as part of the layout.
The first can be fixed in two ways (which can be combined): firstly, by defining new units that exclude document element scrollbars (e.g. 100vw2 ≅ calc(100vw - env(scrollbar-layout-width-auto, 0px)), to define it in terms of what follows); secondly, by exposing the layout width of scrollbars to CSS, e.g. as env(scrollbar-layout-width-auto) for the width with `scrollbar-width: auto` and env(scrollbar-layout-width-thin) for the width with `scrollbar-width: thin`. These values would be something like 17px and 8px on Firefox on Windows, and 0px and 0px on platforms with overlay scrollbars.
The second, you probably need to expose new constants for the possible extreme values of viewport height. e.g. I could imagine env(viewport-min-height, 100vh) and env(viewport-max-height, 100vh) working, which would then allow developers to select one or the other, as suited their purpose. Or define new units opinionated on which value should be used, and then deprecate vw and vh since they’re inconsistently implemented.
(In using env(), I must caution that it’s currently rather broken for some sorts of situations: https://github.com/w3c/csswg-drafts/issues/3285.)
Obviously a simple boolean is the wrong design here. But can you suggest a better one?
A better solution could be to just behave reasonably by default but allow the user to re-enable auto-fill with a single click.
Nevertheless, from their stance on the issue so far it stands to reason that the Chromium team would have objected to any efforts to tighten the spec, which would also have led us to this same situation.
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.)
They could still follow it for other fields.
Google should spend their cycles to work on a standard for password managers. The current design of those is flawed anyway.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
PCI compliance is about checking boxes, not weighing the options and making good choices.
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.
(And for the record: As a developer, I have been bitten by Chrome ignoring autocomplete="off" as well.)
TAB -> Arrow Down (select one of the previously filled values I've used) -> Enter
When filling a form. Given that sometimes we order things on made up names, it's quite useful no to have that autofilled when we're not wanting to.
They really, really need to stop trying to autocomplete entire forms, and probably not anything other than "user/password" forms. The whole 'look at this input id and match it to a bunch of categories' approach has been thoroughly debunked as useless.
Just like they already randomise asset filenames to avoid caching.
Seems like it would be crazy not to use it for 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");
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.
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?
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 "'firstname.lastname@example.org' 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.
(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.
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.
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 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.
<input class="..." maxlength="2048" name="q" type="text" jsaction="..." aria-autocomplete="both" aria-haspopup="false" autocapitalize="off" autocomplete="off" autocorrect="off" role="combobox" spellcheck="false" title="Search" value="" aria-label="Search" data-ved="...">
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.
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...).
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".
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.
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.)
The maps team seems to have given up on trying to resolve that.
Chrome team have made a judgement that autocomplete is required and no-one - not even other teams within Google are allowed to override that functionality.
Isn't that how things should work? If other teams within Google had a special way to override autocomplete wouldn't that be worse?
(Disclosure: I work at Google)
This emphasises the craziness of the unilateral decision by the Chrome team which is essentially saying: "we, the Chrome team are correct and everyone else can go jump in the lake".
I'm not suggesting that Google should have secret special ways to do things.