- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 28 Aug 2014 14:26:32 +0200
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-media-capture@w3.org
Le jeudi 28 août 2014 à 12:24 +0200, Harald Alvestrand a écrit :
> > We could for instance prevent getUserMedia from operating without an
> > "engagement gesture" (see
> > https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#glossary
> > ).
>
> I'm hesitant to go that route. This would add an extra activation step
> to pages whose only purpose is to send video - for instance, it would
> require an engagement gesture before starting the video on
> apprtc.appspot.com.
Right, this would require adding a "start" button there; it does come up
with a cost, but that cost has to be compared with the potential cost of
getting millions of developers to avoid the callme-URL trap.
> > For an ad that would embed an app that would have stored permissions, we
> > may also link the stored permissions to the stack of embedding origins,
> > not just the origin from where the script operates (although I don't
> > know if there is any model we can follow for this).
>
> This is where the embedded app is friendly / trusted, but the embedding
> one isn't.
Right.
> Isn't there a mechanism by which the app can avoid this ("don't allow
> embedding")?
There is the HTTP header X-Frame-Options that let a server prevent
others to embed its content.
> Should we include this in "security advice"?
But then again, this relies on the developers to do the right thing (and
worse, via HTTP headers which are notoriously hard to set in many
situations.)
> >
> > Finally, we may also want to avoid any random app to be able to trigger
> > a getUserMedia prompt when embedded in a Web page (which could easily
> > confuse users); in this case, we should get a new value added to the
> > sandbox attribute in iframe element
> > http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#attr-iframe-sandbox
>
> I'm not sure how iframe sandboxing is supposed to work; what does
> leaving the sandbox attriute off mean in terms of permissions - what's
> the origin of the iframe content?
As far as I know, the sandbox attribute can be used to change the origin
(with allow-same-origin), but that's not that usage I was thinking of:
the allow-pointer-lock value in that attribute doesn't change the
origin, it tells the UA to allow or deny the embedded content to use
some the said feature. (there is a similar separate allow-fullscreen
attribute for historical reasons).
If the sandbox attribute is not set, by default the permission to use
these features are not granted; they're only granted if the embedding
page specifically allows for it.
I'm suggesting we might want to have an "allow-getusermedia" value added
to the sandbox attribute, which unless it is set, will prevent embedded
content from prompting/obtaining the user for their camera/microphone.
Dom
Received on Thursday, 28 August 2014 12:26:51 UTC