On Wed, Sep 10, 2014 at 2:09 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote:

> On Tue, Sep 9, 2014 at 8:13 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > 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.)
>

My understanding is that html-media-capture is basically being abandoned
in favor of gUM.



> (Of course, avatars imply login and login *should* imply https...)


I don't disagree with this in principle, but I think we have to admit that
a huge number of sites which do some form of persistent identity/login
and don't use HTTPS. In any case, there are plenty of other legit
applications
such as photobooths, voice control APIs, etc.



> >> > 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?


I don't know. To some extent people are being driven to use HTTPS because
they want persistent permissions.



> > 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.


Sure. However, my sense is that the Chrome people aren't in favor of this
change.



> >> 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.


I sympathise with this position, which is why Firefox doesn't do it this
way.

-Ekr
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to