On Mon, Sep 8, 2014 at 6:06 PM, Eric Rescorla <e...@rtfm.com> wrote: > On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla <e...@rtfm.com> wrote: >> > On Fri, Sep 5, 2014 at 3:34 AM, 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? >> > >> > It's not being pursued. It was considered in the WG and rejected. >> >> Do *you* think the WG's stance on this was and continues to be the >> right call for our users > > > Eh.. Not sure. AFAIK, there's not much of a reason why arbitary > sites shouldn't be able to access your camera and microphone, provided > that you're not placing trust in the site to do anything in particular > with your data.
I can see that being a valid abstract argument. I wonder, though, if there are non-demo use cases where it's appropriate to ask the user to assume lack of trust. Considering that camera and microphone are particularly privacy-sensitive, I'm worried about not erring on the side of privacy in the absence of non-test, non-demo use cases for allowing gUM on http: origins. > With that said, I wouldn't be upset if HTTPS was required > here, and at one point I argued for that for PeerConnection on the grounds > that the apparent security properties weren't the real ones. OK. >> Do you have a pointer to the WG's rationale for the rejection? I tried >> to search for it, but I failed to find either a decision or rationale. >> The closest I could find was >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats >> https origins as special and says that stored permissions should only >> be available for them. > > It was less a rationale than a lack of people being convinced. I raised it > once > or twice and there were a lot of people strongly opposed, and since the > default > is that things work on HTTP, that's where it stayed. Do you recall when this happened and if Chrome representatives were against restricting gUM to authenticated origins? Except as a path dependency thing where you assume you never change things you've already shipped, Chrome's situation of restricting Web Crypto to authenticated origins but not restricting gUM to authenticated origins seems to be the wrong way around and, therefore, quite bizarre. On Mon, Sep 8, 2014 at 8:10 PM, Martin Thomson <m...@mozilla.com> wrote: > On 08/09/14 10:08, Anne van Kesteren wrote: >>> >>> >That's been the question people have asked, and I think that the answer >>> > was >>> >that we don't want to break test pages and that sort of thing >>> > unnecessarily. >> >> Whoa, that definitely seems like the wrong way to prioritize things. >> Tests or demos should not influence design choices. > > Don't look at me. My assessment is that this isn't superb, but it's not a > hill worth dying on. Is gUM already in a "hill worth dying on" stage? With Presto out of the picture, the implementations are just Gecko and Blink, right? And both Gecko and Blink still have gUM vendor prefixed. (Which, if you believe how prefixing is supposed to work, which I don't believe but am willing to pretend in this case, should mean that we can still change stuff.) And at least now if not at the time of first shipping gUM, there's will among Chrome folks to restrict stuff to authenticated origins. Also, DV certs are cheap enough that demo sites should be able to afford one. > You are welcome to disagree, of course: public-media-capt...@w3.org Hmm. The W3C list search (which sometimes fails) indicates that neither Ryan Sleevi nor Chris Palmer has ever posted to the list. I wonder if there's a disconnect between the Googlers arguing for restricting APIs to authenticated origins and the Googlers working on media capture. On Tue, Sep 9, 2014 at 3:10 AM, Daniel Veditz <dved...@mozilla.com> wrote: > On 9/8/2014 2:16 AM, Mounir Lamouri wrote: >> On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote: >>> It's more the case that a persistent positive grant from permission >>> manager would be ignored for non-secure origins and non-secure origins >>> would not show any option to persist. >> >> I don't know the specifics about the UI, but you don't want to have a >> prompt showing up every time a call to an API is being made. It would be >> terribly frustrating for users and developers. > > It wouldn't be every API call, it'd be the first API call. Would it help > to have an option to remember for the session (rather than > per-document)? We have no guarantee that the foo.com you connect to > tomorrow is the same foo.com you trusted today, especially if you're > connecting to a new network (e.g. coffee shop, airport, hotel). I should have tested this *before* starting this thread, of course, but I tested now: We already distinguish between http: and https: so that our UI don't allow persistent permission grants to http: but allows them for https: in the gUM case. (Kudos to whoever implemented this and didn't leave this as a dead letter of WG deliberations!) It seems that Chrome doesn't offer have persistent grants in either case. https://hsivonen.fi/gum-test/ http://hsivonen.com/test/moz/gum-test.html -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
