Re: Issue 948 SC 1.3.5 Identify Input Purpose - autocomplete technique VS Privacy/Security

Hmmm... a quick check in Chrome (and Vivladi, based on Chromium Blink), and
no, they 'automatically' remember the fields. Firefox doesn't unless told
so (that I can tell), and you can certainly turn off this feature in
Firefox:
https://support.mozilla.org/en-US/kb/control-whether-firefox-automatically-fills-forms

JF

On Tue, Jun 5, 2018 at 5:33 PM, John Foliot <john.foliot@deque.com> wrote:

> > I’m fairly sure the browsers also ask whether to **save** the
> information in the first place, right?
>
> I believe this is correct, yes, but I cannot say for certain.
>
> JF
>
> On Tue, Jun 5, 2018 at 5:12 PM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
>> Thanks John,
>>
>>
>>
>> I’m fairly sure the browsers also ask whether to **save** the
>> information in the first place, right?
>>
>> The commenters point was more about people not realising they were saving
>> information, which would then be available to the next user.
>>
>>
>>
>> In a library / school scenario with shared computers, basic IT practices
>> mean you should either have your own profile, or it doesn’t save any data
>> between sessions (i.e. things like autocomplete are turned off, and
>> browser-history gets wiped like in a private window).
>>
>>
>>
>> In an in-home scenario (e.g. domestic abuse) it is your browser history
>> that is the problem, auto-complete does not give away which forms you have
>> or haven’t filled in (correct?).
>>
>>
>>
>> Cheers,
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *From:* John Foliot
>>
>>
>>
>> ​Additionally, in all of the browsers I've tested (Chrome, Firefox,
>> Vivaldi, Brave) on the Windows platform​, the browser *offers* to
>> auto-complete the fields, but awaits final confirmation from the user -
>> there is no obligation to do so however, and it remains a conscious choice
>> to accept the auto-filling. Additionally, most (all?) browsers allow to set
>> up more than one 'profile', for those 'shared' instances where more than
>> one user's data is stored.
>>
>>
>>
>> Also, both Internet Explorer and MS Edge do not support autocomplete as
>> currently spec'd, so if a user is concerned about this attribute, they
>> could choose to use a different browser (weak come-back, I know, but
>> true...)
>>
>>
>>
>> Finally, there is an additional "super" value for autocomplete (off/on)
>> which you would think could be used to "over-ride" specific values (but
>> doesn't, at least not in my quick testing in 3 browsers). The current spec
>> states:
>>
>>
>>
>> If the autocomplete
>> <https://www.w3.org/TR/html5/sec-forms.html#element-attrdef-autocompleteelements-autocomplete> attribute
>> is omitted, the default value corresponding to the state of the element’s form
>> owner <https://www.w3.org/TR/html5/sec-forms.html#form-owner>’s
>> autocomplete
>> <https://www.w3.org/TR/html5/sec-forms.html#element-attrdef-autocompleteelements-autocomplete> attribute
>> is used instead (either "on
>> <https://www.w3.org/TR/html5/sec-forms.html#attr-valuedef-forms-autocomplete-on>"
>> or "off
>> <https://www.w3.org/TR/html5/sec-forms.html#attr-valuedef-forms-autocomplete-off>").
>> If there is no form owner
>> <https://www.w3.org/TR/html5/sec-forms.html#form-owner>, then the value "
>> on" is used.
>>
>>
>>
>> Might be able to file a bug there (as one state not accounted for, where
>> the "form owner" [aka the parent <form> element] is explicitly set to
>> "off", has not been accounted for). I would suggest that given it's a
>> parent element, that the traditional "cascading" would apply (off at the
>> parent level = off at all the child levels as well), but that will need to
>> be discussed at WebPlatforms WG first.
>>
>>
>>
>> JF
>>
>>
>>
>>
>>
>> On Tue, Jun 5, 2018 at 4:16 PM, Alastair Campbell <acampbell@nomensa.com>
>> wrote:
>>
>> Hi everyone (and particularly John & Lisa),
>>
>>
>>
>> I’d like to run a proposed response past the group before posting to
>> github (and notifying the commenter before the group gets a chance to
>> review).
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/948
>>
>>
>>
>> I’d summarise the core issue as: using autocomplete/autofill could be an
>> issue for privacy/security for people using shared devices (e.g. family
>> computer), and autcomplete shouldn’t be proposed as a technique to fulfil
>> it.
>>
>>
>>
>> You can read the back and forth on the thread, but I’m proposing the
>> response is:
>>
>>
>> The working group have considered the security and privacy aspects of
>> this, and whilst it must be acknowledged there may be some circumstances in
>> which a user would not want fields identified and auto-filled, the working
>> group feel the benefits outweigh the risks.
>>
>>
>>
>> Mitigating factors include:
>>
>>
>>
>> - This is functionality that is already available in user-agents, and
>> used by some websites already.
>>
>> - It is something that must be enabled within the user-account and
>> browser of the device used.
>>
>> - People can use various privacy features if that is a requirement.
>>
>>
>>
>> Currently the autocomplete attribute (for autofill) is the best supported
>> method, so that will be the first technique provided.
>>
>>
>>
>> Personally, I don’t see it as an issue, but I’d appreciate a review from
>> others familiar with autocomplete.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> --
>>
>> John Foliot
>>
>> Principal Accessibility Strategist
>>
>> Deque Systems Inc.
>>
>> john.foliot@deque.com
>>
>>
>>
>> Advancing the mission of digital accessibility and inclusion
>>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

Received on Tuesday, 5 June 2018 21:39:46 UTC