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, 

Re: Password autofilling

[Tom Ritter]

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, dev-platform blocks bigger ones)
>>
>>
>> On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston  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  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, 

Re: Password autofilling

[Jonathan Kingston]

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

On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston  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  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

Re: Password autofilling

[Eric Rescorla]

On Tue, Jan 9, 2018 at 8:43 AM, Gervase Markham  wrote:

> On 01/01/18 20:08, Jonathan Kingston wrote:
> > A recent research post[1] have highlighted the need for Firefox to
> disable
> > autofilling of credentials. The research post suggests web trackers are
> > using autofilling to track users around the web.
>
> Autofill is restricted to same-domain (roughly) so how can they track
> users "around the web"?



The third party JS is loaded into the page's context:

"Thus, third-party javascript can retrieve the saved credentials by
creating a form with the username and password fields, which will then be
autofilled by the login manager."



Other than not being cleared when cookies are cleared, how is this
> technique more powerful than a cookie containing one's email address?
>

Being unclearable is certainly more powerful, but it also allows
cross-correlation
between different tracking domains because the identifiers are stable.

-Ekr


> Autofill is an extremely, extremely convenient browser function, and the
> fact that Firefox's current implementation doesn't always do the right
> thing (e.g. offering me 3 choices of username and, when I pick one, 3
> choices of password rather than autofilling the one which matches the
> username, ) is a source of regular frustration. Let's not break
> the usability more.
>
> Gerv
> ___
> 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

Re: Password autofilling

[Gervase Markham]

On 01/01/18 20:08, Jonathan Kingston wrote:
> A recent research post[1] have highlighted the need for Firefox to disable
> autofilling of credentials. The research post suggests web trackers are
> using autofilling to track users around the web.

Autofill is restricted to same-domain (roughly) so how can they track
users "around the web"?

Other than not being cleared when cookies are cleared, how is this
technique more powerful than a cookie containing one's email address?

Autofill is an extremely, extremely convenient browser function, and the
fact that Firefox's current implementation doesn't always do the right
thing (e.g. offering me 3 choices of username and, when I pick one, 3
choices of password rather than autofilling the one which matches the
username, ) is a source of regular frustration. Let's not break
the usability more.

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

Re: Password autofilling

[Jonathan Kingston]

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, dev-platform blocks bigger ones)
>
>
> On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston  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  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

Fwd: Password autofilling

[Jonathan Kingston]

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

Re: Password autofilling

[Jonathan Kingston]

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

Re: Password autofilling

[Axel Hecht]

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

Re: Password autofilling

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Password autofilling

[Jonathan Kingston]

A recent research post[1] have highlighted the need for Firefox to disable
autofilling of credentials. The research post suggests web trackers are
using autofilling to track users around the web.

Currently we take the stance to require user interaction for addresses and
credit card filling, however we don't do this for user credentials.

I have raised a bug[2] to tackle this issue, however we should discuss if
disabling autofill is the right approach first.

As I mention in the bug, Firefox has changed to be a single interaction to
show the logins for fields, previously this required two interactions. This
change significantly improves the usability of the login manager without
having to autofill.

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.

As part of [2] we could opt to allow users to enable the autofill feature
again in the about:preferences.

More explanation of the threat can be found on a post by Eric Lawrence[3].

Thanks
Jonathan

[1]
https://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427543
[3] https://textslashplain.com/2017/12/28/taking-off-your-nametag/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform