Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bugs.chromium.org

Post reply on HN
Print view View original

371–380 of 383 posts

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

#371

Post by jefftk »

bullman wrote: post #369
jefftk wrote: post #365

Earlier quoted context omitted.

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

So then the crux of the conflict: 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 th…

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)

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

#372

Post by jefftk »

bullman wrote: post #370
jefftk wrote: post #365

Earlier quoted context omitted.

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

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." https://html.spec.whatwg.org/multipage/input.html So, according to this spec, the UA is allowed to make an input field type=…

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.

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

#373

Post by mxxx »

TekMol wrote: post #40

I guess this will lead to a horrible coding style where instead of having this in the form: We will see stuff like this: 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.

Yep. We recently noticed this problem after renaming form fields for the purpose of accessibility (screen readers)

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

#374

Post by kortilla »

NeedMoreTea wrote: post #367
kortilla wrote: post #331

Earlier quoted context omitted.

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: s…

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.

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

#375

Post by jjcm »

Natanael_L wrote: post #231
jjcm wrote: post #171

Earlier quoted context omitted.

This isn't even the first time we've seen this either. Both Chrome Mobile and Safari Mobile go against the standard and implement `vh` incorrectly. 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 t…

All browsers on iOS are Safari wrappers

In this case I'm referring to Chrome Mobile on Android.

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

#376

Post by donatj »

Thorrez wrote: post #329
donatj wrote: post #103

Earlier quoted context omitted.

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

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.

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

#377

Post by SaladFork »

kerng wrote: post #356
notatoad wrote: post #248

Earlier quoted context omitted.

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.

The entire design of password managers that hijacking the DOM is flawed.

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. :/

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

#378

Post by lone_haxx0r »

carstenhag wrote: post #41

As I had already commented on the issue, it completely breaks Germany's main train ticket selling website: 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.chro…

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

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

#379

Post by Thorrez »

donatj wrote: post #376
Thorrez wrote: post #329

Earlier quoted context omitted.

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

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.

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

#380

Post by sixothree »

nikanj wrote: post #326
andrewstuart wrote: post #89

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

In spirit maybe. But in practice it seems worse.
Post reply on HN