On Fri, Sep 5, 2014 at 1:47 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Fri, Sep 5, 2014 at 10:34 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> >> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan <rob...@ocallahan.org> >> wrote: >> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen <hsivo...@hsivonen.fi> >> > wrote: >> >> Is current gUM restricted to authenticated origins? If it isn't, is it >> >> realistic to restrict it to authenticated origins? >> > >> > That's a good idea but it's a separate issue. >> >> Is it already being pursued or should I file a bug? > > > I don't know. > > How about other site-specific sticky state? about:permissions suggests the > full list is > * Passwords
It's not really worthwhile not to remember passwords on http origins, since the user will then type the password anyway, so we can't really protect the user against an active MITM going after passwords on http sites. > * Geolocation In principle, I think geolocation should be restricted to authenticated origins. Unfortunately, it might be too late compatibility-wise to do that at this point. Also, since the geolocation responses are easily proxied over postMessage, I think the potential for wind is less than with gUM, whose response is a special kind of object that doesn't travel (I hope!) over postMessage. > * gUM Yes. I'm hoping that the non-demo uses of gUM are already often enough on authenticated origins for it not to be too late to restrict gUM to authenticated origins. > * Cookies Being able to limit cookies to authenticated origins only would be a big win, but it would probably "break the Web "too much. :-( > * Popup windows As far as annoyances go, Web Notifications require a permission, right? > * Offline storage This one is tricky, since it is somewhere between cookies, which we probably can't fix, and Service Workers, which we can. Probably by now, it would "break the Web" too much to limit offline storage to authenticated origins only. > * Fullscreen Unfortunately, this has use cases together with MSE and sites that use MSE will probably have the hardest time migrating to authenticated origins, because mixed-content XHR is blocked, MSE assumes the media data to be fetched using XHR and migrating the media data to https is a big deal. Assuming that all browsers together don't adopt some way to do mixed-content XHR such that the response data can't be read by JS but can be pushed to MSE. Since MSE is already out there in IE, Chrome and test versions of Safari and we are under notable pressure to ship MSE ASAP, it seems too late to introduce such a mixed-content exception mechanism for XHR. :-( > Cookies are segregated by http vs https, right? Cookies marked secure and served over https are. Cookies not marked secure infamously are not. (And the Same Origin violations of cookies don't even stop at the scheme, since they aren't fully segregated by host name, either. It's very sad.) > I hope other kinds of > offline storage, and passwords, are as well. My understanding is that stuff other than cookies is Origin-based, so the scheme matters. > Popup windows are just a > nuisance so not important here. Yes. > That leaves gUM, geolocation and fullscreen. > Can we make them all require TLS? For the reasons given above, I think we could require authenticated origin for gUM but not fullscreen. Requiring an authenticated origin for geolocation would break things, but we *might* be able to live with the level of breakage. (Though likely not.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
