It seems we are in a bad position here. There's two vectors: The browser and the website are collaborating to mitigate tracking by a third party. The third party makes an invisible login form - well we can restrict autofill to only visible elements. Or make a write-only form field that prevents reading.
But this vector is not realistic. The website _included_ the third party. They want this tracking to occur. If we blocked invisible login forms from autofill - the website will make the forms unobtrusively visible so they get autofilled. If we made write-only form fields, maybe the website will auto-submit the login field to 'help' you login if it can detect there is a value there. In the realistic model the browser is trying defend itself from both the website and the tracking script (which might not even _be_ third party!) We can try to block those scripts with Tracking Protection (and I think we should.) We can disable autofill - but that kind of sucks from a usability standpoint, as Gerv pointed out. Maybe there's a compromise. Assume we can detect _when_ a user submits a login form that we have autofill data for*. What if, alongside cookies and other site data, we store that boolean: userHasLoggedIntoSite. If that boolean is false (the user has never logged into the site) we require user interaction to populate the login form. If the boolean is true, we autopopulate the form (and let some tracking script read it.) I think that would match the tracking capabilities of the site** because if the user had logged in in the past, they probably have a cookie the website can correlate back to an authenticated session. -tom * Can we detect that? I'm hoping we can get it correct 'most' of the time, but it would still have edge cases. ** Ignoring user fingerprinting =) On Mon, Jan 8, 2018 at 8:21 AM, Jonathan Kingston <j...@mozilla.com> wrote: > So it turns out dev-platform is plain text. > > Here is a link explaining the states instead: > https://imgur.com/a/JO6pk > > Thanks > Jonathan > > On Mon, Jan 8, 2018 at 2:10 PM, Jonathan Kingston <j...@mozilla.com> wrote: > >> 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
