I wanted to follow up to make it clear what the change would look like. Here is what autofill population looks like:
Here is what the it looks like after autofill is disabled: This then becomes consistent with Private Browsing mode and HTTP sites already work. This is also consistent with how we fill Credit Cards and Addresses, we always require a user selection. When the user has multiple accounts we choose not to populate by default also: The term Autofill is used inconsistently in Nightly, to mean "On selection" and also "Populate field on load". The research post concentrates on just the pre-population of fields in which advertisers are stealing details from users that are unaware. Making this change to credential population will make autofill a consistent UX. The login manager filling happens over multiple pages (like the Google accounts screenshots above) which works the same with or without this change. Can we move to making signon.autofillForms = false the default on Nightly and Early Beta and see if we have issues? Kind regards Jonathan (Sorry for the super tiny images, dev-platform blocks bigger ones) On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston <j...@mozilla.com> wrote: > There are some other alternatives that we could take here: > > 1. Improve the UX of autofill > a. present the credentials to the user on visible forms when the page > loads > - Google had a project on doing this and it never got completed. It > appears there are many issues with this solution [4]. > 2. Prevent autofill on third party forms > - might not actually address the issue as advertisers are often first > party > 3. Add heuristics on if the form should be autofilled > a. Don't fill when a form isn't visible, editable etc > > I also think that removing autofill aligns with the Credential Management > API, providing incentive for developers to use over having their forms > autofilled by default and that users expect their details to require an > interaction for filling. > > > There's an about:config pref, as [1] points out, which does this. > > My comment regarding this wasn't possible was misleading however I don't > expect the pref is discoverable to most. > > [4] https://twitter.com/estark37/status/947667756400361474 > > > On Tue, Jan 2, 2018 at 5:23 PM, Axel Hecht <l...@mozilla.com> wrote: > >> Am 02.01.18 um 17:22 schrieb Gijs Kruitbosch: >> >> On 01/01/2018 20:08, Jonathan Kingston wrote: >>> >>>> We have the ability to turn off the whole login manager within Firefox >>>> preferences: "Remember logins and passwords for web sites" but no way to >>>> prevent autofill. >>>> >>> >>> There's an about:config pref, as [1] points out, which does this. >>> >>> I wonder if there's a way to require user interaction only when pages >>> contain non-same-origin scripts. Then again, it's not clear that that'd be >>> "worth it", in the sense that that would actually significantly reduce the >>> number of pages where user interaction would be required, nor that it >>> wouldn't make the browser's behaviour less understandable to end users (as >>> we would sometimes autofill without interaction, and sometimes wouldn't). >>> >>> In other form code we also care about whether form fields are focusable >>> (ie visible, editable etc.), which is something we could also potentially >>> use to mitigate these attacks, though it could probably be bypassed by >>> having a visible element that is positioned "offscreen" in an >>> overflow:hidden container, or something of that sort. >>> >>> ~ Gijs >>> >> >> Or could we start blocking tracking-providers with this practice in >> general? >> >> As much as this sounds like an arm-race, these providers are only >> valuable if they're on a lot of sites, so this might actually be a winnable >> arm-race. >> >> Axel >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
