Live data from Hacker News

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

bugs.chromium.org

361–370 of 383 posts

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

#361

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…

I had this issue the other day, I solved it by generating a GUID each time the page loads and appending it onto the end of the ID.

Not ideal, but worked!

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

#362

Earlier quoted context omitted.

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

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

ctrl+shift+p feels more natural to me as Forefox calls it "Private Browsing" whereas Incognito doesn't even start with a n

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

#363
post #362

Earlier quoted context omitted.

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

ctrl+shift+p feels more natural to me as Forefox calls it "Private Browsing" whereas Incognito doesn't even start with a n

(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

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

#364
post #271
post #172

Earlier quoted context omitted.

Not really if the user is non-technical and doesn't even know they'd have to override it.

"this website has asked us to NOT autofill your saved info. 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.

Who is addressing the user here?

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

#365
post #180

Earlier quoted context omitted.

The standard says "SHOULD", not "MUST". (Disclosure: I work for Google)

Where is this supposed "should"? 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 au…

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

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

#367

Earlier quoted context omitted.

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

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.

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

#369
post #365

Earlier quoted context omitted.

Where is this supposed "should"? 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 au…

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

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

#370
post #365

Earlier quoted context omitted.

Where is this supposed "should"? 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 au…

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=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?

Post reply on HN