Re: Rough draft of Async API blog post ready for review

I'm not entirely clear on the context here, so forgive me if this is
irrelevant input.

Security people and mozilla (me included, but others too) are generally
opposed to request*Permission-style APIs.

Instead we advocate having APIs which put up a prompt, if needed, at the
time the the API is used.

For example getUserMedia and the geolocation APIs don't have a separate
"ask for permission" function from the "make the API do useful stuff"
functions.

There are of course exceptions to this. A canonical such exception is
notifications. It doesn't seem possible to create a good UX if permission
to use notifications weren't displayed until a notification was attempted
to be created.

Obviously we are aware that this is not a universally agreed upon solution.
Based on your blog post it sounds like google security folks feel
differently.

I don't expect to persuade anyone here. I just wanted to call out that the
model in the model in the post is not universally though to be a good
design.

That said, I do find the design in the post to be an interesting middle
ground. It doesn't completely separate the "ask for permission" function
from the "do useful stuff" function, but yet keeps them somewhat separate.

Separately, I think there are stronger arguments why has*Permission is not
a privacy leak.

It will only expose privacy sensitive information to websites that the user
has specifically interacted with in the past. I.e. only websites that have
previously brought up UI will receive a non-"default" value. That means
that its essentially not useful as a source of silent fingerprinting or
similar privacy attacks.

Technically it could expose the fact that the user has installed an add-on,
or made a browser configuration, which disables a given API everywhere by
default.

However such an add-on or configuration could hide itself by making
has*Permission return "default" until request*Permission (or similar) is
called. At which point the request would be automatically denied and
has*Permission could start returning "denied" for the given website.

Obviously addons or browser policies could also automatically make
has*Permission return "denied" by default. This might result in better
website UI, at the cost of a small amount of user information being leaked.

So all in all I don't think we should recommend that browsers require that
has*permission is only called from user actions. It seems better to enable
pages to use that information in order to display a better initial UI.

/ Jonas

On Sep 29, 2014 10:21 PM, "Alex Russell" <slightlyoff@google.com> wrote:
>
> Private draft here:
https://gist.github.com/slightlyoff/43cd8c2f64a0719358fe
>
> Very sorry for:
>
> Taking forever with this
> My poor prose
> Not having this ready pre-meeting
> Grateful for any and all feedback.
>
> Regards