Re: Privileged context features and JavaScript

On 4/17/15 7:58 AM, Ashley Gullen wrote:
> I think the existence of the API functions should indicate the browser
> has the capability, and then the API returns an error if it's not
> allowed to be used in the current context. I think this would improve
> the quality of messages seen by users, since for example removing the
> Geolocation API entirely could result in a web page message like "sorry,
> your browser does not support Geolocation, try updating your browser" -
> which is incorrect, it really should say something like "geolocation
> permission denied".

If the page has a codepath for the denied condition, yes.

This is somewhat more likely for geolocation (which involves explicit 
user permission, and the site author may at least consider not being 
granted) than for something like webcrypto (where the site author is 
likely to just not check for rejection at all).

But even for geolocation, you'd end up with a we page message like 
"sorry, you didn't grant permission to use Geolocation, reload the page 
and grant it" which is _also_ incorrect: the correct remediation step is 
to use HTTPS to load the page.  And I bet if the page didn't already 
redirect to an SSL version of itself this step is not available to the 
user anyway...

I would love it if there were a way here to message to the user that the 
page is the thing that's broken (trying to use a privileged feature in a 
non-privileged context), but clearly doing that via messaging the _page_ 
controls is not viable.  The browser _could_ put up an infobar, I 
suppose, in the case that the API is left in place but triggers 
automatic failure if called...

-Boris

Received on Friday, 17 April 2015 14:15:30 UTC