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

211–220 of 383 posts

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

#211

Post by michaelt »

watwut wrote: post #201
Vinnl wrote: post #124

Earlier quoted context omitted.

GP is explicitly not dismissing the above use cases, but merely the supposed justification of "the developer wants it" being enough. > 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

Should developer be able to make it impossible to close browser or open 100 new tabs? No. Should developer decide that fields are autocomplete off or green or show javascript warnings? Absolutely yes. 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…

I've heard plenty of people on HN say password managers should ignore autocomplete=off and I agree with them. Because that setting is mostly applied by organisations like banks who incorrectly think they're making things more secure by doing so.

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.

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

#213

Post by yoz-y »

capableweb wrote: post #135
yoz-y wrote: post #39

Earlier quoted context omitted.

Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.

"the most "valuable" users are all on mobile Safari" Not at all, as only 20% of the people using mobile browsers at all, are using Safari.

Yes but these users account for a very disproportionate amount of spending.

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

#214

Post by lowercased »

> This causes some problems, e.g. in , the "name" can refer to different concepts (a person's name or the name of a spare part).

Maybe I need context, but I don't understand why they're trying to 'guess' context around 'name' and trying to autofill something - either a spare part or a person's name.

Doesn't "name='name'" indicate that it should refill with the previously filled value of field named 'named' on that same page/document/url? Why are they trying to add algorithmic complexity on to already existing stuff?

This might make more sense, no? Let chrome try to determine a 'name' based on whatever logic they want.

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

#215

Post by Santosh83 »

chrismorgan wrote: post #189
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…

Admittedly, the viewport units are just all-round badly thought out and fundamentally broken. (The corresponding problem with vw is that the viewport units includes viewport scrollbars, so that on a page with vertical scrolling, `width: 100vw` will cause horizontal scrolling on platforms where the scrollbars take space.)

Genuinely curious but how are they fundamentally broken? Or at least, any more so than px or cm or em etc? They all have weird edge cases at extreme usage scenarios... Or rather, if you were to 'fix' vw/vh, how would you go about it?

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

#216

Post by calcifer »

yk wrote: post #202
VMG wrote: post #46

Autofill for offscreen elements gives me the creeps even without the data getting misinterpreted

That begs the question, at which point does autofill happen in an iframe? So I pay for an ad, and have a password, creditcard number, address etc. form in the background. Does the browser autofil, or does it autofill when the user starts to fill in a form in the foreground? Asking for a friend.

> That begs the question

Offtopic, but no it doesn't [1].

[1] https://grammarist.com/rhetoric/begging-the-question-fallacy...

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

#217

Post by cuu508 »

dustinmoris wrote: post #194
Santosh83 wrote: post #192

Earlier quoted context omitted.

Anonymity is weakened if we tie authentication to biometrics. Something you know (as in password) is always theoretically more secure than something you are (your physical characteristics).

Anonymity is of course weakened, but that is a different debate. Currently there is no anonymity at all if your account is linked to your email address, which you've also used to register your online banking account, your credit card verification, your PayPal account, etc. and when you have your mobile phone number confirmed, etc. A password gives you 0 extra anonymity in this case. All it is used if for "identifycat…

You are mixing up terminology. When logging in a website, your username identifies you, and your password authenticates you.

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

#218

Post by duxup »

johneth wrote: post #148
duxup wrote: post #6

It's really frustrating to have to work around this with hit or miss hidden inputs and such. So many cases too where auto complete misfires an obliterated forms that had helpful placeholder text. Just having a user change passwords and auto complete will often put an old saved password in the first field but not the second confirmation password field.

> Just having a user change passwords and auto complete will often put an old saved password in the first field but not the second confirmation password field. You can hint to the browser which password you want to autofill with autocomplete="current-password" and autocomplete="new-password"

I've found that auto complete still sometimes guesses at what to do in that case depending on what the other fields are. At least it did last time I fought with it.

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

#219

Post by mnoorenberghe »

antoinevg wrote: post #15
the_pwner224 wrote: post #5

Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=914451... https://bugs.chromium.org/p/chromium/issues/detail?id=468153...

...which really makes it worse: 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…

There are more than 20 different valid field name tokens in the spec, not just “on” and “off”[1]. If web developers actually used the other values correctly then user agents wouldn’t need to use heuristics to figure out the correct data to autofill.

[1] https://html.spec.whatwg.org/multipage/form-control-infrastr...

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

#220

Post by velox_io »

There's a major security flaw with auto-fill when it comes to passwords. Sure, it's hidden on screen, but you only have to change the password box's type, so it isn't "type='password'" and it is revealed. This only takes a matter of seconds.

Chrome should remove the password if there is any attempt to change that form object.

This flaw has been there for years, it's actually handy if I'm not sure what the password is.

Post reply on HN