Security of autofill

[alastc]

I picked up a comment from @StommePoes on twitter (thread) 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 from @anttiviljami shows it working now.

There are also issues with tracking scripts sucking data from the page, even if a form isn't submitted they can still get the auto-filled data.

Apparently most recent security advice 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, only on request, only for trusted domains), but there could be reasons that is hard or impossible to do.

[StommePoes]

One solution would be, in a browser setting section dedicated to autofill and similar, is something like the panel from NoScript: users could, with a checkbox system (rather than a more difficult type-in whitelist system) choose, per domain, whether to allow what data to be auto-sent: for example I may want username and password for github, but would have no reason to allow my home address or credit card. Basically a which-info-per-domain setting.

A browser-owned popup similar to "blah.com wants to send notifications. Block/Allow" could be another method (only for those who've turned on autofill): "send full autofill data to foo.com? Yes/No/adjust settings" for example. In adjust-settings you could choose what exactly to send to foo.com, while "no" is for "I'm just reading a news article, they get nothing from me if I go to post a comment using a form."

The SC is meant to help people with a particular set of disabilities, though things like auto-fill are also a convenience for millions without. It would be unfair to offer an assistance to those who need it which may compromise their safety and security.

I'm sure nobody can make autofill airtight (perfect the enemy of the good, but also making settings too complicated would defeat the purpose of the SC as well), but I do feel it can be improved at a basic level, enough for me to change my mind and recommend it to folks.

[patrickhlauke]

To use "standardsy" language, the problem of how browsers securely handle autocomplete/autofill seems "orthogonal" to what the SC is trying to achieve in terms of getting authors to identify more concretely what inputs/controls are for.

And it's definitely a problem that browsers need to solve, and not something that can or should be tackled in WCAG. Not sure if a handwavy "but beware this can have security issues..." type note would be appropriate either, unless it's maintained from now on to point to concrete external sources that authors can check that explain the problem in detail (a level of detail that probably goes beyond what we want in the understanding doc here) and what the status is of browsers tackling in.

As part of this seems to align with HTML5, suggest something should be filed against the spec there with regards to security. I'd also ping @mikewest who may know the best person to speak to more deeply about this.

[alastc]

And it's definitely a problem that browsers need to solve, and not something that can or should be tackled in WCAG.

Agreed, this is primarily a browser issue. I just meant that if it is a big issue then that technique for applying meta-data might disappear. Also, if an extension implements a similar feature, it should track the issues the browsers deal with.

[johnfoliot]

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 ***@***.*** > 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 <#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

[johnfoliot]

Don't confuse "autocomplete" (of a single field) with "autofill" (of multiple fields in a form). I have not seen any implementations of "autocomplete" that will automatically fill in single fields without interaction, or fill in hidden fields. This feature has been around a lot longer than 5 years; 20 maybe, 15 for sure. Adding autocomplete hints shouldn't be harmful in this use, and by giving browsers hints it should help users get more consistently useful data. Password managers are an old form of "autofill" and in some implementations will fill in hidden fields or fill without user interaction. This is dangerous, but autocomplete hints won't make the problem worse. More recently browsers started supporting a more explicitly acknowledged form "autofill" that do take advantage of the autocomplete hints. I haven't yet seen any that will fill forms without user interaction, but several will go ahead and fill hidden fields if the user chooses to fill the form. This is the source of the privacy worries you mention. Current autofill implementations seem to be based around name-and-address type information but it wouldn't be hard to imagine them expanding to incorporate data for more of the standardized HTML5 autocomplete hints in the future. The problematic user-interaction exists and needs to be mitigated whether you recommend the use of the autocomplete attributes or not.

…

-Dan Veditz

[mbgower]

@johnfoliot

Don't confuse "autocomplete" (of a single field) with "autofill" (of multiple fields in a form). I have not seen any implementations of "autocomplete" that will automatically fill in single fields without interaction, or fill in hidden fields

Just a few points on how the distinction in wording isn't so clear (although on rereading, I get the distinction of the actions being discussed). In recent HTML5.3, some of this is covered in autocomplete through the autofill expectation mantle.

The "off" keyword indicates either that the control’s input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the user agent to prefill the value for him; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values.

When an element’s autofill field name is "off", the user agent should not remember the control’s data, and should not offer past values to the user.
In addition, when an element’s autofill field name is "off", values are reset when traversing the history.
Banks frequently do not want user agents to prefill login information:

A concern is that things like credit card info, including the security feature (cc-csc), do not appear to be treated any differently than other keywords, and do not even have a default value of "off". There is also some concern that retention could also be abused through the "form owner" construction.

If the autocomplete attribute is omitted, the default value corresponding to the state of the element’s form owner’s autocomplete attribute is used instead (either "on" or "off"). If there is no form owner, then the value "on" is used.

Not suggesting this is a show stopper (or even that my interpretation of the draft spec is correct), but it is a consideration, and we may need some language around security, especially if authors are required to follow a normative list.

Also, the last line:

The problematic user-interaction exists and needs to be mitigated whether you recommend the use of the autocomplete attributes or not.

But the current intent isn't to recommend the attributes. It's to require them, right? At the risk of repeating myself, it's the combination -- of requiring authors to provide the use of attributes and making a normative list of attribute values that must be used -- that is the concern.

[StommePoes]

This may be off-topic, and if there's an area (probably not necessarily wcag2.1 even) where this is already being addressed, send it my way.

I was reading another 2.1 thread on more coga stuff and this sentence went by (as a comment, not necesarily any speccy language):

"Reduce Steps: Provide settings, shortcuts or other methods for return users so they can reduce the number of steps needed to perform a task. Example: A shopping cart that saves and pre-fills the address and credit card information."

This did freak me a bit, but I am assuming that while the author would be adding attributes and values that could facilitate the above, the shopping cart wouldn't be saving that (most shops refuse to store that stuff for good reason) but the user agent, correct?

As a J Random, Know-Nothing Developer, if I read a spec that suggests or mandates that I set something up so someone's user-agent (or anything else) saves data or tracks where people have been (to know for example if someone is a first-timer or a returnee, as there were some suggestions of offering different amounts of controls based on user familiarity), I think I would still be uncomfortable with the idea that there's WCAG to help end-users and completely separately-- "orthogonally" is the issue of how UAs implement stuff. (I'm still waiting for a CSUN+DEFCON thing to show up somewhere...)

I'm terrified enough to be responsible for data users give me directly, but my responsibility is clear there. I also should be responsible for data taken from users by any third-party scripts/ads I add to my sites, esp if I allow malicious ones as most of the big publishers have been doing.
But where do I, J Developer, stand if I am following any future SC that tells me to instruct browsers/UAs to take/hold/change layouts based on user data (obviously assuming on the other end the user has also said they want/need this)? Am I responsible? Is it so outside WCAG because "well that's up to the browsers"? Just curious.

edit: or, here's the question. @alastc worried that maybe autocomplete/autofill could be removed from browsers (unlikely), but what about the other end-- developers who would like to follow WCAG but decide they implementation by UAs isn't safe for their users? That would kinda suck if you'd otherwise really like to fulfill the SC (either personally or for legal reasons).

[alastc]

I'm missing the context a bit (i.e. who's being required to do this at what sort of level), but I've come across many sites that do save your info. Amazon's an obvious example, one click buying etc.

I don't think WCAG would get into requiring that sort of thing, but if we can provide higher-level guidance somewhere else, where that is framed as 'when appropriate' and noting the security implications, it is good usability advice (which helps people with cognitive issues even more).

[johnfoliot]

Hi Mallory,

Example: A shopping cart that saves and pre-fills the address and credit

card information. ​Hmmm... not sure where you are seeing this, but overall, some of the desired outcomes coming from the COGA TF are often not framed as technical issues, but rather user-outcomes. If that statement comes from one of their research or issue papers then do not take it as a technical comment. For example, if this statement is related to the draft SC 1.3.5 Purpose of Controls​, then what we (they?) are driving at is essentially the auto-fill function available in all browsers today (and in fact we want to try and mandate at least a subset of the allowed tokens in the HTML5.2 spec ( https://www.w3.org/TR/html51/sec-forms.html#autofill-field) - where storing your credit card and address data in your browser is a common practice today. I know you also flagged this as a potential security concern, and we (I) have tried to follow up on that with the Web Application Security Working Group, but to close the loop here, you are correct, it's not the shopping CART, but rather the shopping *experience*, and specifically the point of Check-Out that calls for these data values to be provided. Here the use of autofill, as supported by all of today's modern browsers, is a time-saving device for most users, but for some users with cognitive issues it could be the difference between a successful conclusion of the shopping experience versus a failed shopping experience - it's a matter of scale and personal ability. HTH JF

…

On Tue, Nov 28, 2017 at 4:46 PM, Alastair Campbell ***@***.*** > wrote: I'm missing the context a bit (i.e. who's being required to do this at what sort of level), but I've come across many sites that do save your info. Amazon's an obvious example. I don't think WCAG would get into *requiring* that sort of thing, but if we can provide higher-level guidance somewhere else, where that is framed as 'when appropriate' and noting the security implications, it is good usability advice (which helps people with cognitive issues even more). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#590 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c-WTOLC_cp81eQoNODfIq_TTxKnUks5s7I1TgaJpZM4Qofqh> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[joshueoconnor]

@johnfoliot @alastc Where do you think this is at? Are there further action items that need to happen?

[alastc]

Another example of privacy issues of autofil came up recently, but I think as long as no SC demands automatic-autofil (some user interaction is needed, even just to click a button in the browser that does the autofil) we are ok.

In the Understanding doc it would help to mention that, but it is really aimed at user-agent creators rather than content authors.

[johnfoliot]

+1 to Alastair. In every instance of browser autofill I've seen, you first have to put focus on the input, and then the browser offers to do the autofill: I can accept that helpful offer or reject it on a case-by-case basis. JF

…

On Wed, Jan 3, 2018 at 4:07 PM, Alastair Campbell ***@***.***> wrote: Another example of privacy issues of autofil <https://www.theverge.com/2017/12/30/16829804/browser-password-manager-adthink-princeton-research> came up recently, but I think as long as no SC demands automatic-autofil (some user interaction is needed, even just to click a button in the browser that does the autofil) we are ok. In the Understanding doc it would help to mention that, but it is really aimed at user-agent creators rather than content authors. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#590 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c-gxc3a1jlkBro6rVPMz8PeJBKSkks5tG_oGgaJpZM4Qofqh> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[StommePoes]

Would be good on my end as well-- anything an SC requires means any website that feels it must adhere to WCAG2.1 for legal or whatever reasons, it would be a requirement there as well. So requiring an experience rather than one technique sounds better.

[jnurthen]

I'm not sure this is fully resolved. Take the following for example. https://codepen.io/anon/pen/RxLoZG Here I go to my name and fill it in and my browser will offer to auto-fill the rest of the form. It will fill in all the rest and I can verify the details - but unknown to me the user - it has also filled in my phone number which was hidden off-screen which will also get submitted to the website. regards, James On Thu, Jan 4, 2018 at 6:05 AM, John Foliot <notifications@github.com> wrote:

…

+1 to Alastair. In every instance of browser autofill I've seen, you first have to put focus on the input, and then the browser offers to do the autofill: I can accept that helpful offer or reject it on a case-by-case basis. JF On Wed, Jan 3, 2018 at 4:07 PM, Alastair Campbell < ***@***.***> wrote: > Another example of privacy issues of autofil > <https://www.theverge.com/2017/12/30/16829804/browser- password-manager-adthink-princeton-research> > came up recently, but I think as long as no SC demands automatic-autofil > (some user interaction is needed, even just to click a button in the > browser that does the autofil) we are ok. > > In the Understanding doc it would help to mention that, but it is really > aimed at user-agent creators rather than content authors. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#590 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABK-c- gxc3a1jlkBro6rVPMz8PeJBKSkks5tG_oGgaJpZM4Qofqh> > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. ***@***.*** Advancing the mission of digital accessibility and inclusion — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#590 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpQP0EfLvC9go99CAY5lrS9O--a4yVjks5tHNqYgaJpZM4Qofqh> .

[jnurthen]

Sorry - please ignore this comment. I see this was previously discussed - hard to remember after the holidays.

…

On Thu, Jan 4, 2018 at 10:48 AM, James Nurthen ***@***.***> wrote: I'm not sure this is fully resolved. Take the following for example. https://codepen.io/anon/pen/RxLoZG Here I go to my name and fill it in and my browser will offer to auto-fill the rest of the form. It will fill in all the rest and I can verify the details - but unknown to me the user - it has also filled in my phone number which was hidden off-screen which will also get submitted to the website. regards, James On Thu, Jan 4, 2018 at 6:05 AM, John Foliot ***@***.***> wrote: > +1 to Alastair. In every instance of browser autofill I've seen, you first > have to put focus on the input, and then the browser offers to do the > autofill: I can accept that helpful offer or reject it on a case-by-case > basis. > > JF > > On Wed, Jan 3, 2018 at 4:07 PM, Alastair Campbell < > ***@***.***> > wrote: > > > Another example of privacy issues of autofil > > <https://www.theverge.com/2017/12/30/16829804/browser-passwo > rd-manager-adthink-princeton-research> > > came up recently, but I think as long as no SC demands automatic-autofil > > (some user interaction is needed, even just to click a button in the > > browser that does the autofil) we are ok. > > > > In the Understanding doc it would help to mention that, but it is really > > aimed at user-agent creators rather than content authors. > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > <#590 (comment)>, or > mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/ABK-c-gxc > 3a1jlkBro6rVPMz8PeJBKSkks5tG_oGgaJpZM4Qofqh> > > . > > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > ***@***.*** > > Advancing the mission of digital accessibility and inclusion > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#590 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABpQP0EfLvC9go99CAY5lrS9O--a4yVjks5tHNqYgaJpZM4Qofqh> > . >

[awkawk]

(Official WG response)
While there are some privacy and security concerns with automatically filling in inputs (without the user wanting to), this is ultimately a user-agent/browser issue. The way to solve the issue is to make sure the user agrees to fields being populated (e.g. clicks a button in the browser interface), and avoid filling in hidden inputs. We can note the concern in the understanding document, but if change is needed it is up to the browsers and Web Platform working group to resolve.