Re: PROPOSAL: iframe behaviour

Heya,

While I agree on the general premise – that users don't/won't verify who asks for a permission to do something – I think the proposed solution would unduly burden third party service providers that don't have, or choose to not have, an end-user presence. To put in concrete terms, the following use-case would be at a usability disadvantage.

Suppose I'm developing a game with voice chat. I'd like to use some existing mixer service (think hosted murmur server) instead of making/hosting my own. In order to facilitate that, the user would need to be redirected to a top-level page of a site they've never seen or heard of before (murmur is an existing game voice chat server) in order to enable a feature in what is essentially my product. The problem would be compounded if I used a host in Sweden, whereby a user would suddenly end up on a .se site and wonder what's going on.

From my perspective, what actually happens if I, as a developer, choose to include a third party service in an iframe, and that service with my knowledge requests user media, then I don't see the distinction between that service asking for the media or myself asking for it directly. Admittedly, I do not have full control over the contents in that iframe, but this is a matter of terms of service between me, the developer, and them, the service provider; an analogous relationship to that which is already happening with Akamai and https certificates. 

If iframes would require an additional step (even beyond the getUserMedia() prompt) the path of least resistance would become to not embed iframes but to include the javascript directly from the third party, whereby the getUserMedia() call's origin becomes the top level page, and the users won't be bothered. Even with the opening provided to produce a better isolated/modular embedding scenario with iframes, there will be a concrete disincentive to using them: additional end-user annoyance. I hope we can avoid adding even more steps to that.

Consequently, I would suggest the exception is shifted, or an additional exception added, to allow the document including an iframe to explicitly allow the iframe to access user media. If this is a mutually beneficial agreement between the developer and service provider, this would effectively be an endorsement of the service provider by the developer. Therefore, it shouldn't make a significant difference whether the getUserMedia() request is from the developer, or through the third party service used by the developer. And requiring the relationship to be stated explicitly, beforehand, means that any random iframe cannot just request media without the developer's consent.

Cheers,
Vladimir

> 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