- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sat, 6 Feb 2016 12:25:39 +0000
- To: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 05/02/16 23:12, Jan-Ivar Bruaroey wrote: > On 2/5/16 9:35 AM, Stefan Håkansson LK wrote: >> On 05/02/16 12:29, Martin Thomson wrote: >>> https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0/edit >> It seems to me that the essence of the "floating idea" is that only the >> top level origin should be shown in user prompts (even if the request to >> use certain resources is made by an iFrame). >> >> This seems mostly in line with PR #313. IIUC, #313 adds that any page >> embedding an iFrame must deliberately set the allowusermedia attribute >> for that iFrame to be able to ask for user media. And if it is the top >> level origin only that will be shown in the user prompt, it makes total >> sense to me if the top level origin can prohibit an iFrame to ask for >> user media. > > The floated idea seems to conflict with any "on-by-default" for access > in iframes whatsoever, so I trust we don't have that in PR #313? Unless I am totally mistaken, #313 introduces "off-by-default" for access in iFrames. Currently there is no way (defined in the spec) the parent origin to control if an iFrame can access microphones/cameras using gUM, #313 introduces a control (and as said permission is off by default). > I > thought I saw discussion about maybe there being a more permissive > default in some cases, specifically, if no iframe permission parameters > were specified at all, or did I misunderstand? I'm not very familiar > with this part. > > About the floated idea: The fusing of permissions between iframes and > their top origin sure simplifies, but the move of control from users to > the site concerns me. I fear this will lead to demand for browser > policy-settings to control third-party permissions the way we have today > for third-party cookies... > > .: Jan-Ivar :. > >> There is a part in #313 that would go away: it is said that the iframe >> "needs to identify itself in the security prompt presented to the >> user.", and that would go away. But to me #313 seems sensible for now, >> we can remove that part later if the "floating idea" is adopted. > >
Received on Saturday, 6 February 2016 12:26:13 UTC