Live data from Hacker News

Issue 914451: Autofill does not respect autocomplete="off"

bugs.chromium.org

321–330 of 383 posts

Re: Issue 914451: Autofill does not respect autocomplete="off"

#321
post #180

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)

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!

Re: Issue 914451: Autofill does not respect autocomplete="off"

#322
post #227

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

At the same time many many many dumb corp-o-rat shit sites disable autocomplete because cOmpLiEncE. And users love autocomplete...

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"

#323

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

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.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#324
post #94
post #82

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

Re: Issue 914451: Autofill does not respect autocomplete="off"

#325
post #95

Earlier 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…

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.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#326

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

Google really is the new Microsoft

Re: Issue 914451: Autofill does not respect autocomplete="off"

#327
post #138
post #8

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

kiosk mode? Firefox has a great extension for this.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#328
post #98

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

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.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#329
post #103
post #75

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

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.

Re: Issue 914451: Autofill does not respect autocomplete="off"

#330

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

Why would they ever do that. That’s just asking for autofill phishing.
Post reply on HN