Re: Security of Autocomplete - Good News!

Hi Alastair,

RE: Horizontal Security Review: I think that the time is *now* (as other
specs come to APA for their accessibility horizontal review at around this
same time - i.e. CR or sooner).  I suspect that (request) will be a Chairs
Task *very* soon...



RE: This security concern: I am conflicted here.

In at least Firefox (and apparently Safari - but needs confirmation), when
you 'activate' (or contemplate activating) the autofill function, in those
browsers there is a not-so-obvious-until-you-realize-it 'security' feature
that shows which fields are actually being "filled". See the screen capture
below (taken while testing the following URL: https://anttiviljami.github.
io/browser-autofill-phishing/):

[alt: screen capture, showing the Firefox notice of which fields are being
autocomplete'd]​

I have to admit that at first I didn't even realize that this was being
shown, and in checking in Chrome, they do NOT have a similar feature. (And,
being based upon Blink, neither does Vivaldi nor Brave that I have
determined through testing. Additionally, it does not appear that Password
managers are doing anything similar either, and the test page noted above
'phished' my Password manager as well.)

And while it is easy to say that end-users are ultimately responsible for
securing their own personal data, given one of the key target audiences
here is users with cognitive issues, I personally feel that the burden is
even greater on those users.

>  I’m not sure how useful it is for us to be security testing an HTML
feature that should have already been tested?


Indeed, I have a number of questions about that as well, which I will be
directing towards the Chairs of Web Platforms. Between the number of token
values not natively supported
<https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research> in
the browsers, coupled with the glaring and trivial-to-accomplish security
(phishing) concern around @autocomplete, I'm aghast at how sloppy and
'Mickey Mouse' this is turning out to be. I am stunned that the
browsers have not addressed this *STILL*. (I fully realize this is further
complicated by the uneasy situation between the W3C and the WHAT WG, and
maintaining two versions of HTML 5.x. Still, I find the current situation
untenable).

I realize that we've already given one response, and it seems that the
response was also adequate for the latest issue as well -
https://github.com/w3c/wcag21/issues/775

However, I personally feel we are at a bit of an ethical dilemma here;
despite being a huge proponent for this *technique* to support the SC
requirement of SC 1.3.4
<https://www.w3.org/TR/2018/CR-WCAG21-20180130/#identify-common-purpose>
that common form inputs be *Programmatically Determinable*, I am concerned
that we are causing as much bad as good with this Technique (and you just
have to know how crushed I am about that). I don't think this is a
death-blow to this SC, and I am investigating other potential techniques to
support this requirement, but I also believe we need to have a discussion
around whether or not using @autocomplete is something we encourage, or
demand at this time.

JF



On Wed, Feb 28, 2018 at 3:35 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Before we get stuck into testing this, I’d note we had basically the same
> comment before, with a response:
>
> https://github.com/w3c/wcag21/issues/590#issuecomment-359288754
>
>
>
> I’m not sure how useful it is for us to be security testing an HTML
> feature that should have already been tested?
>
>
>
> Plus it is actively working in browsers now. If we were proposing a
> completely new feature which only had un-tested ser-agents it would be
> different, but this is an advantage of scoping to a browser-supported
> feature.
>
>
>
> As EA said, browsers tend to require user-action before filling things
> out, that seems to be the main mitigation.
>
>
>
> In any case, I happen to have been reading some W3C process stuff
> recently, and apparently we should be asking for ‘horizontal reviews’ soon,
> including security. I can’t find that reference right now (in the pages of
> seemingly random links Michael provided), but I assume that will be soon.
> I’ll find out.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
> *From: *James Nurthen
>
>
>
> John,
>
> The issue cited was hiding the fields using the following
>
>       <p style="margin-left:-500px">
>
>         <input id="phone" name="phone" type="text" placeholder="Your
> Phone">
>
>       </p>
>
>
>
> Before responding please repeat your test using off-screen techniques to
> hide the fields.
>
>
>
> Regards,
>
> James
>
>
>
> *From:* John Foliot
>
> Greetings all,
>
>
>
> On today's call, I took the action to respond to Issue #775
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_wcag21_issues_775&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I&m=KkDSaYcqHGmRC2JTiCM9wi-GL7ucqU9_tJdP18QSAt4&s=qOMpGTAX3xpK-6eEBdOe0DOm6taaNyqqXjVQJbtiuks&e=>.
> Before responding, I needed / wanted to do some basic testing myself.
>
>
>
> I have created two forms that both include all 53 of the current
> @autocomplete tokens. The first form (https://john.foliot.ca/demos/
> autofill.php
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__john.foliot.ca_demos_autofill.php&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I&m=KkDSaYcqHGmRC2JTiCM9wi-GL7ucqU9_tJdP18QSAt4&s=bt7lHc7aD9swLTUkzH2RlNKPbj0wkvtTSp8_3JOXIqY&e=>)
> uses input type="text" for all 53 inputs, and submitting the form echo's
> back the data being captured in the form fields. (Go ahead, give it a
> whirl.)
>
>
>
> I have also created a second form, but this time I changed the bulk of the
> inputs to type="hidden" (I left the name-related fields as type="text", as
> most browsers and helper apps need at least "Name" to trigger the
> autocomplete functionality). The second form can be found at:
> https://john.foliot.ca/demos/autofill_hidden.php
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__john.foliot.ca_demos_autofill-5Fhidden.php&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I&m=KkDSaYcqHGmRC2JTiCM9wi-GL7ucqU9_tJdP18QSAt4&s=WNhgOBCLftJCQi44CAE009T1SSQXYrMDlDiq5qi2i7E&e=>
>
>
>
> My basic testing confirms that when a field input is marked as "hidden",
> the autocomplete functionality is removed or otherwise disabled by the
> browsers to preserve user security. I have not done any further (advanced)
> testing, and so I cannot rule out the possibility of rogue sites using other
> scripted methods
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__freedom-2Dto-2Dtinker.com_2017_11_15_no-2Dboundaries-2Dexfiltration-2Dof-2Dpersonal-2Ddata-2Dby-2Dsession-2Dreplay-2Dscripts_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I&m=KkDSaYcqHGmRC2JTiCM9wi-GL7ucqU9_tJdP18QSAt4&s=jHMQ58ZLpj-jaZ_EROCyh0mHtjpEVYwzMmLgS6phzSk&e=>
> to try and attempt to override this security feature. We likely need to add
> a comment in the Understanding document noting this fact (maybe?).
>
>
>
> I am in need of testing assistance for the OSX platform, as well as iOS.
> If you care to help, please ping me off-line.
>
>
>
> Based upon these test results, I will craft a response for Issue 775 later
> today.
>
>
>
> ​JF
>
> --
>
>
>



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

Advancing the mission of digital accessibility and inclusion