Permission UI

[Anne van Kesteren]

The web already has a bunch of features that require permission UI,
such as passwords, geolocation, notifications, WebRTC, etc.

With service workers this will grow with permissions for push,
persistent storage, one-off synchronization, and periodic
synchronization. And likely more going forward.

I'd like to ask that we start investigating how to best present these
to the user, including their persistence and implications. As well as
strongly considering updating about:preferences to reveal how much we
store for each page (and making it possible to tweak there).
Especially now web page will be able to have things like background
activity and such, being able to centrally manage that to preserve
battery life and limit surveillance is getting increasingly more
important.

I filed the following bugs to consider some of these issues, but
perhaps some mailing list discussion is warranted as well, hence this
post:

* https://bugzilla.mozilla.org/show_bug.cgi?id=1138827
* https://bugzilla.mozilla.org/show_bug.cgi?id=1138829
* https://bugzilla.mozilla.org/show_bug.cgi?id=1138885
* https://bugzilla.mozilla.org/show_bug.cgi?id=1138887

(This is also a heads up of sorts that as platform keeps pushing the
web to turn into an OS, we need pretty close coordination to turn
these new capabilities into something successful for users and web
developers.)


--
https://annevankesteren.nl/

[Dirkjan Ochtman]

On Tue, Mar 3, 2015 at 12:40 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> I'd like to ask that we start investigating how to best present these
> to the user, including their persistence and implications. As well as
> strongly considering updating about:preferences to reveal how much we
> store for each page (and making it possible to tweak there).

As for persistence, we also still have this open:

https://bugzilla.mozilla.org/show_bug.cgi?id=470699

Cheers,

Dirkjan

[Frederik Braun]

The good news is that most of the complicated bits are already
implemented. See about:permissions.

Though it operates on hostnames and not origins (bug 1066517).

[Anne van Kesteren]

On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun <fbr...@mozilla.com> wrote:
> The good news is that most of the complicated bits are already
> implemented. See about:permissions.

That seems like a good start, although it fails to cover a number of
things, such as cache, storage APIs, and the notifications API. And we
should really consider merging it into about:preferences so it can be
discovered (and you can actually manage the preferences for the sites
you browse from where you would expect).

> Though it operates on hostnames and not origins (bug 1066517).

:-( This might get tricky UI-wise, though if we stop offering
persistent permissions when there's no TLS, perhaps there's some way
to get there.


--
https://annevankesteren.nl/

[Eric Rescorla]

This seems like somewhere we should try to get to quickly.

-Ekr


>
> --
> https://annevankesteren.nl/
> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>

[Ehsan Akhgari]

On 2015-03-03 9:36 AM, Eric Rescorla wrote:
>
>
> On Tue, Mar 3, 2015 at 5:55 AM, Anne van Kesteren <ann...@annevk.nl
> <mailto:ann...@annevk.nl>> wrote:
>
> On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun <fbr...@mozilla.com
> <mailto:fbr...@mozilla.com>> wrote:
> > The good news is that most of the complicated bits are already
> > implemented. See about:permissions.
>
> That seems like a good start, although it fails to cover a number of
> things, such as cache, storage APIs, and the notifications API. And we
> should really consider merging it into about:preferences so it can be
> discovered (and you can actually manage the preferences for the sites
> you browse from where you would expect).
>
>
> > Though it operates on hostnames and not origins (bug 1066517).
>
> :-( This might get tricky UI-wise, though if we stop offering
> persistent permissions when there's no TLS, perhaps there's some way
> to get there.
>
>
> This seems like somewhere we should try to get to quickly.

Note that we currently *store* permissions based on host name, and not
the origin. Also, there are probably some permissions that can safely
be stored permanently for non-secure origins, such as the permission to
open pop-up windows.

[Robert Kaiser]

Anne van Kesteren schrieb:

> I'd like to ask that we start investigating how to best present these
> to the user, including their persistence and implications.

Note that one idea that I had about 5 years back is implemented by default in SeaMonkey as "Data Manager" and available as a Firefox add-on under https://addons.mozilla.org/en-US/firefox/addon/data-manager/ (code is available at https://hg.mozilla.org/users/kairo_kairo.at/dataman/ at the moment).

While this approach might not be perfect and I haven't had time or energy to do any maintenance on the code, it's there and one idea on how a rather powerful management UI can be done. That said, it might be overwhelming for a normal user (and it has some bugs as well as room for improvement).

KaiRo

[Javaun Moradi]

+1, Philipp has thought about this a lot. Also: I'm really glad we're
having this conversation. We want to tackle this sooner than later.
On Mar 3, 2015 6:48 PM, "Justin Dolske" <dol...@mozilla.com> wrote:

> I don't actually think about:permissions is a good start, or that it's
> implemented "most of the complicated bits." Quite the opposite, really: it
> was a useful experiment, but has some serious problems. I'd briefly
> summarize the two main flaws as (1) "manager" UIs are generally not great
> (they provide some minimal functionality to change settings but are bad at
> informing the user what's going on) and (2) it isn't a great fit for the
> scopes of various things in the browser (everything from global settings to
> exact-url matches, with lots of subtle variations in between), let alone
> matching that to a user's mental model.
>
> Philipp Sackl (UX) has been poking at this for a while, and has some
> interesting explorations. We can and should definitely do more here, just
> not with about:permissions. :)
>
> Justin

>
> On Tue, Mar 3, 2015 at 5:17 AM, Frederik Braun <fbr...@mozilla.com> wrote:
>
>> The good news is that most of the complicated bits are already
>> implemented. See about:permissions.
>>

>> Though it operates on hostnames and not origins (bug 1066517).

[Anne van Kesteren]

On Wed, Mar 4, 2015 at 12:48 AM, Justin Dolske <dol...@mozilla.com> wrote:
> I don't actually think about:permissions is a good start, or that it's
> implemented "most of the complicated bits." Quite the opposite, really: it
> was a useful experiment, but has some serious problems. I'd briefly
> summarize the two main flaws as (1) "manager" UIs are generally not great
> (they provide some minimal functionality to change settings but are bad at
> informing the user what's going on) and (2) it isn't a great fit for the
> scopes of various things in the browser (everything from global settings to
> exact-url matches, with lots of subtle variations in between), let alone
> matching that to a user's mental model.

The scope of most web-facing features that are exposed directly to
sites is the origin. Cookies deviate, so require some extra attention.
But in general managing site matters at the level of origin seems
sound from a platform perspective.

The kind of things I'd like to see in the end are a list of origins
sorted by storage usage, origins that have recently used geolocation
functionality, origins that have background activity, origins that can
display notifications, etc.

And we should really start looking into this since the more power we
grant origins, the more we should really let users control it.


--
https://annevankesteren.nl/

[Anne van Kesteren]

(Added dev.platform back.)

On Tue, Mar 3, 2015 at 7:04 PM, Shane Caraveo <scar...@mozilla.com> wrote:
> I tend to agree with Gerv, there should be an overly simplistic top level "I
> trust [social network name] to do something wrong but let them do it anyway"
> setting with a way to dig into more detailed settings if I care to.
>
> To bad websites don't have a manifest where they define the permissions they
> need...

If the UI team thinks this is required we could definitely experiment.
There's no reason we could not add something like <meta
name=permissions value="geolocation, notifications">. The problem with
such a declarative solution is that there's no context for the user
why the site wants such permissions. I believe there's some data that
shows that users are much more likely to grant a permission if it's
clear from context (e.g. by instructions from the web page) why it's
needed.

And also, the current system is not going away so either way we'll
need to improve it. Chrome has done some experiments with combining
permissions based on requests coming in roughly at the same time:
http://youtu.be/3dAwZVsS8wo?t=7m10s (that whole presentation is pretty
great viewing if you're interested in permission management).


--
https://annevankesteren.nl/

[Justin Dolske]

I don't actually think about:permissions is a good start, or that it's
implemented "most of the complicated bits." Quite the opposite, really: it
was a useful experiment, but has some serious problems. I'd briefly
summarize the two main flaws as (1) "manager" UIs are generally not great
(they provide some minimal functionality to change settings but are bad at
informing the user what's going on) and (2) it isn't a great fit for the
scopes of various things in the browser (everything from global settings to
exact-url matches, with lots of subtle variations in between), let alone
matching that to a user's mental model.

[Jonas Sicking]

On Tue, Mar 3, 2015 at 11:36 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Wed, Mar 4, 2015 at 12:48 AM, Justin Dolske <dol...@mozilla.com> wrote:

>> I don't actually think about:permissions is a good start, or that it's
>> implemented "most of the complicated bits." Quite the opposite, really: it
>> was a useful experiment, but has some serious problems. I'd briefly
>> summarize the two main flaws as (1) "manager" UIs are generally not great
>> (they provide some minimal functionality to change settings but are bad at
>> informing the user what's going on) and (2) it isn't a great fit for the
>> scopes of various things in the browser (everything from global settings to
>> exact-url matches, with lots of subtle variations in between), let alone
>> matching that to a user's mental model.
>

> The scope of most web-facing features that are exposed directly to
> sites is the origin. Cookies deviate, so require some extra attention.
> But in general managing site matters at the level of origin seems
> sound from a platform perspective.
>
> The kind of things I'd like to see in the end are a list of origins
> sorted by storage usage, origins that have recently used geolocation
> functionality, origins that have background activity, origins that can
> display notifications, etc.

There is another area where we don't use origins, which is storage.
Storage here currently include IndexedDB, Cache API and cached SW
scripts. In the future it'll likely also include localStorage and
other future storage APIs in this.

For storage we have a limit on how much total data all websites can
write (something close to 50% of free space of the user's drive IIRC).

However in order to not allow a single website to suck up all of that
storage, we also put a limit on how much a given website can store. If
we based that purely on origin, a website could work around that by
sharding itself over an unlimited number of subdomains and using those
as storage proxies. I.e. by opening sub1.website.com,
sub2.website.com, etc in <iframe>s and then postMessaging with them.

So instead we measure and limit storage on a per eTLD+1 basis.

This isn't exactly a permission, but would be good to expose to users
in the permissions UI.

Also, we might want to do something similar for permissions. It's
somewhat annoying if a website can keep asking for geolocation by
simply using new subdomains to do so, even if the user repeatedly
clicks "no" and "remember this decision".

> And we should really start looking into this since the more power we
> grant origins, the more we should really let users control it.

Totally agreed!

/ Jonas

[Anne van Kesteren]

On Wed, Mar 4, 2015 at 10:54 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> Also, we might want to do something similar for permissions. It's
> somewhat annoying if a website can keep asking for geolocation by
> simply using new subdomains to do so, even if the user repeatedly
> clicks "no" and "remember this decision".

This would require everything that's like github.io to register as a
public suffix. And if someone actually wants to attack users I doubt
the budget would only allow for a single domain. This is why I'm not
really convinced this eTLD coupling is really of help.


--
https://annevankesteren.nl/

[Karl Dubost]

Le 5 mars 2015 à 06:54, Jonas Sicking <jo...@sicking.cc> a écrit :
> Also, we might want to do something similar for permissions. It's
> somewhat annoying if a website can keep asking for geolocation by
> simply using new subdomains to do so, even if the user repeatedly
> clicks "no" and "remember this decision".

Do we have stats (distributions)

* number of sites visited per user. (aka how many users (percentage) visit 1 to 10 sites, 10 to 20, etc.)
* same above but separated depending on mobile and desktop
* how many sites ask for permissions
* what kind of permissions are the most frequent
* how many sites are trying to store things
* how much to they store
* how many people act on the permission when it's happening (Yes/No,etc.)
* change the permission later on when it has been done.


--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Gervase Markham]

On 05/03/15 07:40, Anne van Kesteren wrote:
> This would require everything that's like github.io to register as a
> public suffix.

github.io already is a public suffix :-) If some private entity is
handing out subdomains to mutually-untrusting 3rd parties, there are a
number of reasons they should be in the PSL. If they aren't, they'll
have bigger problems than one site not being able to use localstorage
because another one has sucked it all up.

> And if someone actually wants to attack users I doubt
> the budget would only allow for a single domain. This is why I'm not
> really convinced this eTLD coupling is really of help.

Doesn't it also prevent accidental as well as deliberate problems? If
there was no eTLD coupling, one site that was doing something they
thought was perfectly reasonable could nevertheless exhaust the
available resources for everyone on a resource-constrained device.

Gerv