RE: PROPOSAL: iframe behaviour

This is the same approached used by IE9's "tracking protection" [1] feature.
IE needed a hook (read: specified legitimate way to block requests) for this 
type of scenario in Web Workers. After some discussion, Ian provided a small
"hook" [2]. 

Rather than force the spec to deny these requests, I would suggest a
"softer" approach that provides a similar "hook" for implementations that 
would prefer to block getUserMedia requests in this scenario (which sounds
like a great idea to me).

-Travis
[1] http://ie.microsoft.com/testdrive/Browser/TrackingProtection/Default.html
[2] http://dev.w3.org/html5/workers/#shared-workers-and-the-sharedworker-interface (Step 7.6 of the "SharedWorker" constructor algorithm)


>-----Original Message-----
>From: Anant Narayanan [mailto:anant@mozilla.com]
>Sent: Monday, March 12, 2012 7:02 AM
>To: public-media-capture@w3.org
>Subject: PROPOSAL: iframe behaviour
>
>What
>--
>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.
>
>Why
>--
>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!).
>
>How
>--
>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
>geolocation:
>http://lists.w3.org/Archives/Public/public-geolocation/2011Feb/0001.html),
>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!
>
>Thanks,
>-Anant
>

Received on Tuesday, 13 March 2012 18:52:08 UTC