Earlier quoted context omitted.
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"
The standard says "SHOULD", not "MUST". (Disclosure: I work for Google)
Issue 914451: Autofill does not respect autocomplete="off"
321–330 of 383 posts
Re: Issue 914451: Autofill does not respect autocomplete="off"
#322This has turned into a sad chicken-race between Google and developers, with lots of innovative workarounds on Stackoverflow. 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. https://stackoverflow.com/questions/12374442/chrome-ignores-... ## Example 1 For a reliable workaround, you can add this cod…
Preach. Them changing the rules and overriding the usage of this attribute is ridiculously stupid in the first place. HTML attributes are there for a reason, developers are supposed to be able to use them and they are supposed to work as expected. But in order to push their password management and form filling functionality, they just give everyone a finger.
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.)
Re: Issue 914451: Autofill does not respect autocomplete="off"
#323Earlier quoted context omitted.
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 hijack…
This is actually a reasonable proposal. A moderate list could be an in-built feature, with some config options.
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.
Re: Issue 914451: Autofill does not respect autocomplete="off"
#324Earlier quoted context omitted.
Imo, valid use case for autocomplete=off is "the developer of webapp wants it". Literally that and nothing more.
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.
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.
Re: Issue 914451: Autofill does not respect autocomplete="off"
#325Earlier quoted context omitted.
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), hijac…
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-gue…
:/
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.
Re: Issue 914451: Autofill does not respect autocomplete="off"
#326The weird thing is that there's other teams within Google who offer autocomplete libraries that simply don't work because Chrome overlays it's own autocomplete on top. 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. It's weird.
Re: Issue 914451: Autofill does not respect autocomplete="off"
#327Earlier quoted context omitted.
It causes spec-compliant password managers to not work. Unfortunately, disabling autocomplete for password fields is an often used form of security-theatre
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.…
Re: Issue 914451: Autofill does not respect autocomplete="off"
#328Earlier quoted context omitted.
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 ne…
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.
> 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.
Re: Issue 914451: Autofill does not respect autocomplete="off"
#329Earlier quoted context omitted.
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.
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.
Re: Issue 914451: Autofill does not respect autocomplete="off"
#330This has turned into a sad chicken-race between Google and developers, with lots of innovative workarounds on Stackoverflow. 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. https://stackoverflow.com/questions/12374442/chrome-ignores-... ## Example 1 For a reliable workaround, you can add this cod…
I think it mentioned chrome is even now ignoring ‘display:none’ and ‘visibility:hidden’ declarations so those workarounds no longer work either.