W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2012

PROPOSAL: iframe behaviour

From: Anant Narayanan <anant@mozilla.com>
Date: Mon, 12 Mar 2012 07:02:27 -0700
Message-ID: <4F5E01F3.2030003@mozilla.com>
To: public-media-capture@w3.org
Explicitly specify that getUserMedia called from a document that is not 
"top-level" and from a different origin of the parent document, for 
instance third party <iframe>s, be disallowed. An exception is made for 
an instance where the domain of the <iframe> had already been authorized 
in a separate instance when it was top-level.

We currently have no UI ideas for asking user consent for permissions 
invoked from embedded <iframe>s. The current consent model (in most 
major browsers) implies to the user that the permission is being asked 
for the top-level page (eg Firefox/Opera's "doorhanger"). Based on 
preliminary user research, we have found out that even if we do specify 
the origin of the application asking for permission in the doorhanger, 
most users will assume the permission is being asked for the top-level 
page. (Yes, users don't read the dialogs, surprise!).

In order to prevent unexpected behaviour and to stay on the safe side of 
user's privacy, it may be useful to explicitly mention in the 
specification that calls from <iframes>s be silently denied.

I understand that this might disable some useful embedding use cases 
(Google Hangout widget on my blog?) and my preliminary proposal to 
handle this case is to have the user authorize Google hangouts 
separately when *it* is top-level (hence the 'exception' statement 
earlier). There is some concern even about this approach, and it was 
proposed that we should persist origin-*pairs* for permissions (for 
but I'm willing to compromise on that particular aspect; as I expect 
video embedding from third party sites will be far more popular than 
third party geolocation services, and I see no harm if the user had 
already authorized the "third-party" earlier.

Curious about your thoughts!

Received on Monday, 12 March 2012 14:03:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC