Re: Password autofilling
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
> 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, dev-platform blocks bigger ones) > >> > >> > >> On Wed, Jan 3,
Re: Password autofilling
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, which does this. > > I wonder if there's a way to require user inte
Re: Password autofilling
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
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
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
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
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
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
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
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
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
