W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2016

Re: [mediacapture-main] Pull Request: Extend iframe with a new allowusermedia attribute (issue: #268)

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 9 Feb 2016 20:56:57 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <A222C88B6882744D8D4B9681B31588902954D7E9@ESESSMB307.ericsson.se>
On 2016-02-09 13:15, Stefan Håkansson LK wrote:
> On 09/02/16 12:27, Harald Alvestrand wrote:
>> Den 08. feb. 2016 04:20, skrev Martin Thomson:
>>> On 6 February 2016 at 01:35, Stefan Håkansson LK
>>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>> This seems mostly in line with PR #313.
>>>
>>>
>>> I agree, but #313 has the same problems as this proposal in that it
>>> breaks sites.
>>>
>>> And I would be opposed to adding an attribute that we'd have to
>>> support indefinitely if there is a good chance that we'll have to add
>>> an attribute with similar, if not identical, properties.
>>>
>>> Since this is a very late change to functionality, I want to make sure
>>> that everyone is OK with the change.  That includes users of the API
>>> especially.
>>>
>>
>> My read is that #313 is in concordance with the "floating proposal" (to
>> require permission at top level only), and is absolutely necessary in
>> order for the "floating proposal" to be viable (otherwise, the "floating
>> proposal" would automatically grant permission to all nested iframes, no
>> dialogue needed - which would be a privacy disaster).
>
> It is in concordance with "floating proposal", but the later proposes a
> different way (than #313) for the parent origin to declare what
> permissions the iframe can request:
>
> <iframe id="embedee" src="..." permissions="geolocation notifications
> midi"></iframe>
>
> I am confused about where the "floating proposal" is discussed though.
> There is nothing said about it in the WebAppsSec list, I find nothing
> anywhere in the WebPlatform WG or the WhatWG spaces either.
>
>>
>> So I see #313 as a Good Thing to merge - it makes the "floating
>> proposal" feasible, because all the pages that would have to be broken
>> under the "floating proposal" are already broken by #313.
>
> I also think it makes sense to merge, but we should probably add a note
> saying that discussion is ongoing and this particular feature may change.

Given that it's not clear in what state the "floating proposal" is in, 
it might be worth documenting our solution under the current 
circumstances (i.e. without the consensus for the "floating proposal"). 
With a note as Stefan mentioned.

/Adam
Received on Tuesday, 9 February 2016 20:57:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 9 February 2016 20:57:31 UTC