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

Reply via email to