W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data

From: Evan Stade <estade@google.com>
Date: Fri, 14 Nov 2014 10:10:42 -0800
Message-ID: <CAO4XGS9Gn9QAdN_UX=haWQ8+ud9-WDHiPNnB994osdmO3KkLbw@mail.gmail.com>
To: rescator@emsai.net
Cc: whatwg@lists.whatwg.org
On Thu, Nov 13, 2014 at 11:42 PM, Roger Hågensen <rescator@emsai.net> wrote:

> On 2014-11-14 08:02, Evan Stade wrote:
>> On Thu, Nov 13, 2014 at 5:17 PM, Roger Hågensen <rescator@emsai.net>
>> wrote:
>>  On 2014-11-13 20:20, Evan Stade wrote:
>>>  Currently this new behavior is available behind a flag. We will soon be
>>>> inverting the flag, so you have to opt into respecting
>>>> autocomplete="off".
>>>>  I don't like that browsers ignore HTML functionality hints like that.
>>> I have one real live use case that would be affected by this.
>>> http://player.gridstream.org/request/
>>> This radio song request uses autocomplete="off" for the music request
>>> because a listener would probably not request the same bunch of songs
>>> over
>>> and over.
>>>  autocomplete="off" will still be respected for autocomplete data. This
>> should cover your use case.
>>  Also, banks generally prefer to have autocomplete="off" for credit card
>>> numbers, names, addresses etc. for security reasons. And that is now to
>>> be
>>> ignored?
>>>  I'm not sure what security threat is addressed by respecting
>> autocomplete="off".
> SSN, PIN, and so on.
> Sure, it's the users responsibility to ensure their PC/laptop/tablet is
> secured.
> But it's very quick to press 0-9 and you got a pin, that being said a bank
> should have two factor anyway (or better), and pins can  be changed. SSN
> can not though. Also the government is pretty strict in Norway on the
> leaking of SSN (here's it called Personal Number though) and in that case
> they start with 0-9 so it's quick to get the autocomplete to spit it out.
>  This is also autocomplete, not Autofill (in Chrome parlance).
> In that case, my mistake, autocomplete, autofill, autosuggest, input
> history, it all kind of blurs together, so apologies for that.
> Would there be any point in having a per FORM autofill on/off instead?

autocomplete="off" can already be applied to a form as well as an input

> That way if a autofill="off" is set for the form itself then the user
> could be prompted "This site wishes to not store any form data, Agree? Yes!
> No" and then have the browser remember the choice the user made (so the
> next time based on the user choice, the form is either autofilled or not).
> and maybe word it better than I did there.
> And if the autofill="off" hint is missing (or set to "on") then the user
> is never prompted.
> This would give even more power to the user than currently.

The problem is that we don't think autocomplete="off" is used judiciously.
There's no particular correlation with risk to the user. The user is not
going to be able to make an informed choice in response to that prompt, and
it's added friction.

> If it was my bank I would probably (if shown such a prompt) prefer to not
> have anything autofilled or autocompleted.
> But if it was a comment form on a blog I'd probably want that (autofilled
> and/or autocomplete etc).
> As a user I should be able to choose that easily. (digging around in
> advanced settings is not what I'd call easy.)
> The key though is it defaults to autofill and the user prompt only appears
> if autofill="off" is set as a parameter for the form, and the user choice
> is remembered.
> Geolocation data is prompted for in a similar way as to what I describe
> here right?

Chrome Autofill already prompts the user in the form of a dropdown. If the
user doesn't want to share information with the site, they shouldn't select
one of the rows in the dropdown. A second prompt is not going to add value.

> --
> Roger "Rescator" Hågensen.
> Freelancer - http://www.EmSai.net/
Received on Friday, 14 November 2014 18:11:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:26 UTC