W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2014

Re: [Bug 25809] Security issue: Abuse of "call me" URLs

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 28 Aug 2014 12:24:38 +0200
Message-ID: <53FF0366.4070201@alvestrand.no>
To: public-media-capture@w3.org
On 08/28/2014 11:37 AM, Dominique Hazael-Massieux wrote:
> Le jeudi 03 juillet 2014 à 10:56 +0200, Harald Alvestrand a écrit :
>> I think the web developers mostly will read books and pages written by 
>> people who (hopefully) read the spec - and those people will hopefully 
>> read it from end to end, so it doesn't matter much where.
>> I think putting it in the (non-normative) security considerations 
>> section will do nicely.
> This sounds reasonable; I've put a pull request to that effect.
> https://github.com/w3c/mediacapture-main/pull/9
> But I wonder if we could not do more to make that footgun less likely to
> be triggered.
> 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

> 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.
Isn't there a mechanism by which the app can avoid this ("don't allow
Should we include this in "security advice"?

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

If I understand the text correctly, "sandbox" without properties
generates an unique origin, so they don't get stored permissions.
Restricting the ability to trigger prompting for access seems a bit tough.

If we ever want an iframe in a sandbox to grab a camera based on the
permissions of the embedding page, I agree we need to ask for another
attribute here. Unfortunately, I don't see an extension description in
the sandbox text.

> Dom

Surveillance is pervasive. Go Dark.
Received on Thursday, 28 August 2014 10:25:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:29 UTC