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

I like Alastair's response. If Alastair would like to incorporate some of
the ideas mentioned that would be OK.

There is one issue that strikes me: the professional environment. Access to
a professional system is an important issue for employment, but the
security issues may be more exacting.

Wayne

On Tue, Jun 5, 2018 at 3:02 PM White, Jason J <jjwhite@ets.org> wrote:

> Safari under Mac OS doesn’t complete form fields unless I move focus to
> the field and explicitly choose to invoke the automatic completion.
>
>
>
> I don’t know whether other browsers will follow this example. Privacy
> concerns associated with autocomplete have surfaced recently, focusing on
> exploitation by third-party tracking scripts associated, presumably, with
> advertising.
>
>
> https://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/
>
>
>
> It should be noted that, as emphasized in the article, the feature is
> working as designed – there’s no hitherto unknown vulnerability here.
>
>
>
> I would suggest including the “autocomplete” technique as planned, but
> adding a note (if it isn’t already in the draft) on its privacy and
> security implications.
>
>
>
> *From:* John Foliot <john.foliot@deque.com>
> *Sent:* Tuesday, June 5, 2018 5:39 PM
> *To:* Alastair Campbell <acampbell@nomensa.com>
> *Cc:* WCAG <w3c-wai-gl@w3.org>
> *Subject:* 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fkb%2Fcontrol-whether-firefox-automatically-fills-forms&data=02%7C01%7Cjjwhite%40ets.org%7C274b19b3fc644995174d08d5cb2d2102%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636638317039281240&sdata=au2k1RUt%2FhHHK%2FAlZN1C6AkYbscaB64sn%2FfsmJxFD2A%3D&reserved=0>
>
>
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Fsec-forms.html%23element-attrdef-autocompleteelements-autocomplete&data=02%7C01%7Cjjwhite%40ets.org%7C274b19b3fc644995174d08d5cb2d2102%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636638317039291248&sdata=eSW5zaAbMErp%2FFmm9IYs4v0DO1iIkEz4xFA6Wk9x6c0%3D&reserved=0> attribute
> is omitted, the default value corresponding to the state of the element’s form
> owner
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Fsec-forms.html%23form-owner&data=02%7C01%7Cjjwhite%40ets.org%7C274b19b3fc644995174d08d5cb2d2102%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636638317039291248&sdata=3OU5mNzjgxDhFjzuZKUEY9QTwqOTThJZ%2B9LSW%2FRP51s%3D&reserved=0>
> ’s autocomplete
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Fsec-forms.html%23element-attrdef-autocompleteelements-autocomplete&data=02%7C01%7Cjjwhite%40ets.org%7C274b19b3fc644995174d08d5cb2d2102%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636638317039301257&sdata=Kq0iW7XKORLkft6xvDipPSlhb2BiJ5D7V3hZeBSAaoY%3D&reserved=0> attribute
> is used instead (either "on
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Fsec-forms.html%23attr-valuedef-forms-autocomplete-on&data=02%7C01%7Cjjwhite%40ets.org%7C274b19b3fc644995174d08d5cb2d2102%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636638317039311261&sdata=6wFioGgQhV9VH802ugndIp%2F7uy6KLKTxLOgzmMpnoa0%3D&reserved=0>"
> or "off
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Fsec-forms.html%23attr-valuedef-forms-autocomplete-off&data=02%7C01%7Cjjwhite%40ets.org%7C274b19b3fc644995174d08d5cb2d2102%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636638317039311261&sdata=tAqVoUkno3Occyx1arjpn2e1bSuUji7gjvseLsxfTrI%3D&reserved=0>").
> If there is no form owner
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Fsec-forms.html%23form-owner&data=02%7C01%7Cjjwhite%40ets.org%7C274b19b3fc644995174d08d5cb2d2102%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636638317039321274&sdata=jwzjfsinklbgLtvzsm1Ej34W9lZ7gndtzUObRaw4Ako%3D&reserved=0>,
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F948&data=02%7C01%7Cjjwhite%40ets.org%7C274b19b3fc644995174d08d5cb2d2102%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636638317039321274&sdata=P8NE1HmvnhluNDS4JtsRpIJJm%2FP4tVbtGye06aOHdyE%3D&reserved=0>
>
>
>
> 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
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>