> But this vector is not realistic. The website _included_ the thirdparty. 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.
Do we know this? My understanding was most research suggested trackers use every technique possible that go undetected. If these scripts then obviously degrade user experience then users complain to the site owner. These scripts could already do many malicious things anyway. > In the realistic model the browser is trying defend itself from both the website and the tracking script Yep. In reality we are trying to ensure the user wants to authenticate with their consent. I think we should continue investigating Credential Management or other protections of user data from tracking scripts. However this won't protect the user in the short term. > We can try to block those scripts with Tracking Protection (and I think we should.) I agree, however this won't always be perfect. > We can disable autofill - but that kind of sucks from a usability standpoint, Given we disable this on HTTP pages and also behave differently with CC and address autofill; why should this have a different experience? > Maybe there's a compromise. Assume we can detect _when_ a user submits a login form that we have autofill data for*. I think this makes it much more confusing to be honest. On Thu, Jan 18, 2018 at 10:06 PM, Tom Ritter <t...@mozilla.com> wrote: > 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
