- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 17 Apr 2015 10:14:58 -0400
- To: Ashley Gullen <ashley@scirra.com>, Elliott Sprehn <esprehn@chromium.org>
- CC: Anne van Kesteren <annevk@annevk.nl>, Mike West <mkwst@google.com>, public-webappsec@w3.org, public-webapps <public-webapps@w3.org>, public-script-coord <public-script-coord@w3.org>
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:31 UTC