Re: [w3c/wcag21] Security of autofill (#590)

Hi All,

Adding the Web Application Security Working Group public mailing list to
this thread (thanks in advance WebAppSec WG), to see if anyone over there
has any current information about this.

It's an interesting concern.  A quick search tells me that I can edit all
autofill field values directly from the browser settings (Chrome
<https://www.pcworld.com/article/3145489/browsers/how-to-clear-unwanted-autofill-entries-in-google-chrome.html>here,
Firefox
<https://support.mozilla.org/en-US/kb/control-whether-firefox-automatically-fills-forms#w_deleting-individual-form-entries>here,
Safari <https://macpaw.com/how-to/clear-autocomplete-on-mac-os-x>here, Edge
<https://privacy.microsoft.com/en-US/windows-10-microsoft-edge-and-privacy>here),
and/or disable them completely, although that may defeat our goal.

As a quick explanation to the security folks, we are looking at mandating
the use of the @autocomplete tokens in the next version of the Web Content
Accessibility Guidelines (v. 2.1
<http://rawgit.com/w3c/wcag21/master/guidelines/index.html>) - or at least
a subset of the full 52-odd token values in HTML 5 today (this is still in
flight and not yet completely nailed down). While autocomplete is a help to
many users, for those users with cognitive disabilities, this feature is
significantly more useful and important (think for example of a user who is
dyslexic - having their zip code 'remembered' reduces their need to ensure
they always get the numbers correct, and in the correct order.)

Given what appears to be a significant privacy and security concern here,
is there any indication from the browser vendors around addressing these
concerns? More importantly, if we were to mandate the use of those tokens
(target date for our next Rec is June 2018), will we run into issues down
the road? It seems that the autocomplete feature has been shipping for at
least 5 years now, so I personally suspect it isn't going to go away, but
additionally, the concerns raised seem to be in the category of "Big Deal".

Any information that WebAppSec WG members could provide (either
collectively or individually) would be most gratefully received.

Thanks in advance

JFb Application Security Working Group

On Thu, Nov 23, 2017 at 3:55 AM, Alastair Campbell <notifications@github.com
> wrote:

> I picked up a comment from @StommePoes <https://github.com/stommepoes> on
> twitter (thread <https://twitter.com/stommepoes/status/933594053375127552>)
> about the security of autofill.
>
> This is to a great extent an issue with the browser implementations, but
> it is relevant because if the browsers don't solve it then autofill is
> likely to go-away. That would undermine the SC.
>
> For example, if the browser auto-fills fields by default, any site could
> hide input fields out of view and collect your credit card details.
>
> I think current implementations wait for you to fill in one field (e.g.
> name) and then it fills in the others, but again the site can hide fields.
> This example video
> <https://video.twimg.com/tweet_video/C1UYX2LXcAA_KYJ.mp4> from
> @anttiviljami <https://twitter.com/anttiviljami/status/816585860661518336>
> shows it working now.
>
> There are also issues with tracking scripts sucking data from the page
> <https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/>,
> even if a form isn't submitted they can still get the auto-filled data.
>
> Apparently most recent security advice
> <https://twitter.com/stommepoes/status/933622256911224832> is to disable
> autofill in your browser.
>
> I have a few suggestions:
>
>    - Find someone in W3C with knowledge of what browsers are doing about
>    this (I couldn't find much from a quick search).
>    - Put a note in the understanding that there are potential security
>    issues.
>    - Make clear to anyone currently implementing a browser extension they
>    need to try and mitigate these effects.
>
> Hopefully the browsers will solve this (e.g. only fill in visible fields,
> and only on request), but there could be reasons that is hard or impossible
> to do.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/wcag21/issues/590>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABK-c5w86I3WqnjwzBmiVecTzhix2hKnks5s5UEPgaJpZM4Qofqh>
> .
>



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

Advancing the mission of digital accessibility and inclusion