Re: Password autofilling

[Tom Ritter]

On Sun, Jan 21, 2018 at 6:29 PM, Jonathan Kingston  wrote:
>> 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.

Well, there are already websites that stick an unobtrusive login form
in the top header of the site; if my intention was to track users by
getting around a browser defense that blocked my tracking, and that
could do it, I think it'd be easy for me to integrate that design.
Just conjecture.

>> 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?

I think I missed that we already disable autofill on HTTP...

>> 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.

Definitely more complicated. I think the average user experience would
remain unchanged though, since most users aren't clearing history in
their (non-PBM) browser.

-tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Password autofilling

[Jonathan Kingston]

> 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  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  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 
> 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,