Live data from Hacker News

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

bugs.chromium.org

281–290 of 383 posts

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

#281

A few years ago, I left a $1000 tip at the restaurant up the street because Chrome filled out the tip field with my zip code (which thankfully merely defaulted to max $1000 instead). The tip field was off-screen, and the ordering software didn't have a confirmation screen, just a "we just charged your card $X amount" screen, which made my eyes boggle. EDIT: Looking at the original March 17th, 2015 bug, it would have…

This has a lot of really serious implications. I built a form for a charity that allowed users to buy a subscription but include an additional donation amount. Chrome was sometimes filling that field with the two-digit year. The charity got a lot of complaints and it ruined the trust relationship with the donors who didn't understand what was happening and thought it was intentional.

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

#282
post #113

Earlier quoted context omitted.

This is why form elements should never be hidden after loading. Display none should be the default in the HTML for non-relevant content, which should be enough for most autofillers. It also prevents flashing of content when autofillers try to populate it, causing the hiding to delay, which I recently saw in a production app. Frameworks like React and Vue don’t even render the HTML into the DOM until conditions are me…

If you want to be malicious and capture wrong auto fill data, wouldn't a simple AJAX request on change be enough to capture sensitive data before the user gets a chance to correct it?

I'm not really sure but I think the behavior is a bit different with autofill. While the browser show the field highlighted, the data is there for _the user_ but the actual form field has not been actually changed and no dom event is fired.

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

#283
post #225

Earlier quoted context omitted.

I think the statement you make about "something you know" always being more secure is not nearly as clear cut as you present it. A combination of "something you know" and "something you have" is always going to be a very strong authentication scenario, and making "something you have" a non-hackable thing that truly only you can have (i.e not a USB key or a TOTP seed etc.) is a good choice. The catch here is that when…

> And using any of these (ideally) has absolutely nothing to do with anonymity. You are not anonymous online regardless of what you use for authentication - and you are frankly not smart if you assume thats the case. A company offering a service with biometrics is no different from a company doing the same based on email/username and a password, if they do privacy and security right. Why should I use unchangeable, pe…

You don't have to identify yourself with a "random Joe's website". You can read the comments here without identification, you can seach for flights without identifying yourself, you can search for hotels without giving away who you are, you can read the news, watch YouTube, etc.

But when you want to access something that should only belong to you, e.g. your bank account, your Google Drive files, your private emails, etc. then you must find a way of identifying yourself with given website. Username/password is one way, biometrics is another way.

Only my family has permission to enter my house. When someone enters my house who doesn't look like my family, then they can throw around all secrets, passwords and usernames they want, I'll kick them out, because in my eyes they don't pass the ultimate test of verification, namely biometrics.

So far we were unable to provide the same level of identificaiton via the web, but technology is changing rapidly, so I don't see why username/password are always going to be more secure. On a theoretical basis it doesn't make sense. Because inforation can be easily shared, spread and copied. My physical composition not.

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

#284
post #226

Earlier quoted context omitted.

When a phrase is used the “wrong” way more often than the right way, it ceases to be wrong.

Through the sheer force of repeated ignorance we change the language?

Unfortunately, yes.

I still have to come to terms with it.

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

#285
post #272
post #109

Earlier quoted context omitted.

If the user installs extension to auto fill everything, it is on him. When the browser decided to ignore spec, it is not user agency at all. The need for auto fill is extremely application specific and the action is quite often destructive. And it is developer who gets to be blamed for lost data.

How do I install extensions into my most commonly used browser (my phone)?

Start using Firefox on your phone.

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

#286
post #268

Earlier quoted context omitted.

Yeah. But people say it enough I've started mentally converting it to: "I _could_ care less (but I can't be bothered)."

which is for all intents and purposes is more insulting than not being able to care less.

I think you mean all intensive purposes

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

#287
post #202

Earlier quoted context omitted.

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

Technically correct, but look deeper: Why is this mistake prevalent? What are people trying to say that causes them to borrow (misuse) another phrase to express it? This indicates a "hole" in the language that is filled with the wrong item.

Like a code review, do better than just saying "This line is wrong". Suggest an alternative. Especially one that flows naturally into the prose.

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

#288
post #179

Earlier quoted context omitted.

> not even other teams within Google are allowed to override that functionality Isn't that how things should work? If other teams within Google had a special way to override autocomplete wouldn't that be worse? (Disclosure: I work at Google)

My point is that this decision from the Chrome team even breaks Google's own software. This emphasises the craziness of the unilateral decision by the Chrome team which is essentially saying: "we, the Chrome team are correct and everyone else can go jump in the lake". I'm not suggesting that Google should have secret special ways to do things.

Angular Material's Autocomplete component is an example of this. Our users would have found that really helpful... if Chrome's autofill behavior didn't break it.

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

#289
post #22

Curious as to the global business impact this has had. I personally have spent at least a dozen hours debugging forms and trying to disable autocomplete/autofill on my kiosk-based applications. How many development hours collectively have been wasted on this unilateral decision. I have not been this frustrated since the days of writing css for ie6, and at least back then the devs response was more "sorry its our rend…

You're not the only one. I remember spending a good two days on it this year for a page where the user puts in their credentials for external integrations.
Post reply on HN