On Tue, Sep 9, 2014 at 8:13 PM, Eric Rescorla <e...@rtfm.com> wrote: > On Tue, Sep 9, 2014 at 1:32 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> 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. > > Sure, I think there are some reasonable cases. Say that a site asks to > take your picture for the purpose of displaying an avatar. So you give it > temporary access, it takes the picture, and then it relinquishes access. > Because there are UI indicators that show when the camera is being > accessed, and I control what's in front of the camera, and the site > is planning to publish the picture I don't really need to trust the site > much.
Oh. I had thought that that use case was outside the scope of gUM and in scope for http://www.w3.org/TR/html-media-capture/ (possibly to be implemented on top of gUM + https://w3c.github.io/mediacapture-image/ by the Firefox OS browser chrome.) (Of course, avatars imply login and login *should* imply https...) >> >> 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? > > IIRC the main person speaking out against this was from MSFT, Hmm. IIRC, Microsoft wanted a non-TLS variant of HTTP/2. > but I don't think people from Google were in favor either. I guess the Chrome folks aren't coordinated on this kind of thing, then. >> > 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. > > > I'm not sure I understand the question. There certainly is fairly wide gUM > usage. I mean: Does gUM have high non-demo, non-test usage on http origins? > For instance, Hangouts is now WebRTC in Chrome and will be WebRTC in > Firefox soonish, hopefully. As a Google service, Hangouts are going to be https, hopefully. > That obviously doesn't mean things can't be > changed, but I think you'd need WG consensus to do so, and I don't have > the sense we're going to get that. Per the reply Anne got, http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/0030.html , it looks like the WG is deferring the decision to implementors as a "MAY", so it seems to be more an issue of Gecko+Blink consensus than WG consensus. > I think Florian implemented it. Adam Roach deserves the credit for insisting > we do it right. Thanks to both! >> 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 > > Chrome auto-decides whether the grant is persistent based on whether > the URL is http or https. Whoa. That's non-obvious and creepy. As a user, I find it creepy for an UI that looks like a one-time grant to actually do a persistent grant. (Consider the non-http use case about taking a picture for a random site you gave above, that use case happening on an https origin and ending up leaving the origin with a persistent permission to turn the camera on later.) As a site operator, I find that this makes me appear creepier than I want to appear if I host (I currently don't but I want to eventually) SimpleWebRTC app on my site for ad hoc video conferencing without having to trust a third party to do the call setup in a way that doesn't involve extra parties and I don't want to ask the other party of the conversation to have to trust my site not to turn on the camera later after the conversation. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
