Re: Privileged context features and JavaScript
On 4/17/15 2:44 AM, Mike West wrote: Consider Geolocation, for instance: users can disable the API entirely in Chrome (and, I assume, other browsers). Should we remove the API in these cases as well? There's no user-facing UI to disable geolocation in Firefox, but there is a preference that can be changed in about:config and there are some instructions for how to change that preference in about:rights on some Firefox platforms (e.g. Firefox on Android). If that preference is toggled, we in fact remove the API entirely, so that 'geolocation' in navigator tests false. -Boris
Re: Privileged context features and JavaScript
On 4/17/15 2:52 AM, Boris Zbarsky wrote: If that preference is toggled, we in fact remove the API entirely, so that 'geolocation' in navigator tests false. Oh, I meant to mention: this is more web-compatible than having the API entrypoints throw, because it can be object-detected. Of course we could have made the API entrypoints just always reject the request instead, I guess; removing the API altogether was somewhat simpler to do. -Boris
Re: Privileged context features and JavaScript
I'd be fine with this, if it's what folks end up preferring. That said, throwing/rejecting gives us the opportunity to explain to a developer _why_ her favorite API isn't available. It's not clear how we'd help them understand what's going on if we just remove the API entirely. Consider Geolocation, for instance: users can disable the API entirely in Chrome (and, I assume, other browsers). Should we remove the API in these cases as well? Either way, expressing the constraint via IDL seems totally reasonable. -mike On Apr 17, 2015 07:19, Anne van Kesteren ann...@annevk.nl wrote: Soon there will be a number of features that are restricted to privileged contexts. Most prominent one being service workers. Within user agents the prevailing pattern is that privileged APIs are not available in unprivileged contexts. However, both Firefox and Chrome currently expose the service worker API everywhere, it just happens to reject. Should we change this and simply not expose the API in unprivileged contexts? E.g. through IDL syntax? That way we don't have to carefully secure all access points. -- https://annevankesteren.nl/
Re: Privileged context features and JavaScript
It's preferable not to do that for us because you can then create a static heap snapshot at compile time and memcpy to start JS contexts faster. On Apr 17, 2015 12:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/15 2:52 AM, Boris Zbarsky wrote: If that preference is toggled, we in fact remove the API entirely, so that 'geolocation' in navigator tests false. Oh, I meant to mention: this is more web-compatible than having the API entrypoints throw, because it can be object-detected. Of course we could have made the API entrypoints just always reject the request instead, I guess; removing the API altogether was somewhat simpler to do. -Boris
Re: Privileged context features and JavaScript
Since we're talking about a binary distinction (privileged vs. unprivileged), presumably you could just make two snapshots? On Fri, Apr 17, 2015 at 3:38 AM, Elliott Sprehn espr...@chromium.org wrote: It's preferable not to do that for us because you can then create a static heap snapshot at compile time and memcpy to start JS contexts faster. On Apr 17, 2015 12:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/15 2:52 AM, Boris Zbarsky wrote: If that preference is toggled, we in fact remove the API entirely, so that 'geolocation' in navigator tests false. Oh, I meant to mention: this is more web-compatible than having the API entrypoints throw, because it can be object-detected. Of course we could have made the API entrypoints just always reject the request instead, I guess; removing the API altogether was somewhat simpler to do. -Boris
Re: Privileged context features and JavaScript
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. On 17 April 2015 at 08:38, Elliott Sprehn espr...@chromium.org wrote: It's preferable not to do that for us because you can then create a static heap snapshot at compile time and memcpy to start JS contexts faster. On Apr 17, 2015 12:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/15 2:52 AM, Boris Zbarsky wrote: If that preference is toggled, we in fact remove the API entirely, so that 'geolocation' in navigator tests false. Oh, I meant to mention: this is more web-compatible than having the API entrypoints throw, because it can be object-detected. Of course we could have made the API entrypoints just always reject the request instead, I guess; removing the API altogether was somewhat simpler to do. -Boris
Re: Privileged context features and JavaScript
On the one hand, I like the idea of giving developers and users better information about why things are failing. On the other hand, it seems unpleasant to make every API that is so restricted accommodate a failing because of non-privileged context modality, which they will undoubtedly do in different ways. On Fri, Apr 17, 2015 at 7:58 AM, Ashley Gullen ash...@scirra.com 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. On 17 April 2015 at 08:38, Elliott Sprehn espr...@chromium.org wrote: It's preferable not to do that for us because you can then create a static heap snapshot at compile time and memcpy to start JS contexts faster. On Apr 17, 2015 12:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/15 2:52 AM, Boris Zbarsky wrote: If that preference is toggled, we in fact remove the API entirely, so that 'geolocation' in navigator tests false. Oh, I meant to mention: this is more web-compatible than having the API entrypoints throw, because it can be object-detected. Of course we could have made the API entrypoints just always reject the request instead, I guess; removing the API altogether was somewhat simpler to do. -Boris
Re: Privileged context features and JavaScript
On 4/17/15 3:38 AM, Elliott Sprehn wrote: It's preferable not to do that for us because you can then create a static heap snapshot at compile time and memcpy to start JS contexts faster. For this specific case, where there are only two possibilities (privileged or not) it seems like you can just have two different snapshots and pick the right one. I agree this uses more memory; there are all sorts of tradeoffs here. But yes, this is an argument against having any sort of dynamic behavior. In the case of Gecko, we have to have _something_ somewhat dynamic anyway, since we expose APIs to extensions that we don't expose to web pages... which I'm sure you do too. -Boris
Re: Privileged context features and JavaScript
On 4/17/15 2:44 AM, Mike West wrote: Either way, expressing the constraint via IDL seems totally reasonable. OK, so let's say we do the API is still present but fails somehow thing. How would one express that constraint via IDL? What would the normative language be? It seems like the best you can do in this situation is an IDL annotation that has no actual behavior implications of its own but serves as a warning to the spec reader to carefully read the prose for what the behavior implications are, right? I say this because I'm seeing people want to apply this to a variety of different APIs which should do a variety of different things in the disabled state, as far as I can tell. Am I missing something and there's something more that such an annotation could do? -Boris
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
Re: Privileged context features and JavaScript
On Fri, Apr 17, 2015 at 4:09 PM, Boris Zbarsky bzbar...@mit.edu wrote: I say this because I'm seeing people want to apply this to a variety of different APIs which should do a variety of different things in the disabled state, as far as I can tell. Am I missing something and there's something more that such an annotation could do? A bunch of the new non-legacy APIs (that is geolocation doesn't count) have some kind of promise thing you need to get past before things start working. For those APIs we could have something with normative language. I don't see how we could make something work for all possible APIs (unless we do the hiding thing). -- https://annevankesteren.nl/
Re: Privileged context features and JavaScript
On 4/17/15 11:13 AM, Anne van Kesteren wrote: A bunch of the new non-legacy APIs (that is geolocation doesn't count) have some kind of promise thing you need to get past before things start working. For those APIs we could have something with normative language. I don't see how we could make something work for all possible APIs (unless we do the hiding thing). OK, so the annotation could be defined as something like adding the following to the operation (and maybe attribute getter?) steps in WebIDL: If the API returns a Promise type, return a Promise rejected with a TypeError (??). Otherwise, the operation steps MUST fail in some way. Or some such. -Boris
Re: Privileged context features and JavaScript
On Fri, Apr 17, 2015 at 7:06 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/15 3:38 AM, Elliott Sprehn wrote: It's preferable not to do that for us because you can then create a static heap snapshot at compile time and memcpy to start JS contexts faster. For this specific case, where there are only two possibilities (privileged or not) it seems like you can just have two different snapshots and pick the right one. I agree this uses more memory; there are all sorts of tradeoffs here. But yes, this is an argument against having any sort of dynamic behavior. In the case of Gecko, we have to have _something_ somewhat dynamic anyway, since we expose APIs to extensions that we don't expose to web pages... which I'm sure you do too. In Blink, we don't include host objects in our snapshot anyway, so this point is probably moot for web APIs. Or at least it's moot until more things are self-hosted. - Adam
Re: Privileged context features and JavaScript
On 17 April 2015 at 08:16, Boris Zbarsky bzbar...@mit.edu wrote: If the API returns a Promise type, return a Promise rejected with a TypeError (??). Otherwise, the operation steps MUST fail in some way. Or some such. SecurityError perhaps. But I still like the idea of an IDL annotation like [SecureContext] that causes the API to disappear as though not implemented.
