- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 4 Dec 2015 16:40:40 +0100
- To: public-media-capture@w3.org
Den 04. des. 2015 08:02, skrev Stefan Håkansson LK: > On 04/12/15 06:04, Martin Thomson wrote: >> The options would seem to be: >> >> 1. do nothing >> 2. add an allow-usermedia label to the sandbox attribute, which would >> block gUM calls if sandboxing was enabled, but leave it enabled >> otherwise >> 3. add a disallow-usermedia label to the sandbox attribute, which >> would block gUM calls only if the attribute and label were present >> 4. disable gUM by default and require the use of a new allow-usermedia >> attribute to enable it >> >> Note that 3 is quite irregular in that the sandbox attribute only has >> "allow-x" labels currently. >> >> I think that 2 is simplest. It's least disruptive to existing uses, >> while giving sites a way to prevent misuse. However, 4 is the most >> privacy-preserving and I can see a fairly good argument for it. > > This is where I end up too. It would be good to know many apps would > break by going with 4. If very few, 4 seems most compelling to me, but > if not 2 seems like the logical path. > >> >> Of course, choosing option 2 is easier if we choose option 4 for issue >> #267 (i.e., we key permissions on both top-level and iframe origin). > > I agree. Would choosing double-keyed permission mean that if an iframe appears in 7 different contexts, the permissions will have to be stored 7 different times? Note that permission keying affects whether we're able to unify our permissions model with the Permissions API model - that model doesn't appear to consider iframes separately at all at the moment. > >> >> On 3 December 2015 at 22:26, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote: >>> Hi >>> >>> To make the discussion is this issue [1] more visible we move it to the >>> list. >>> >>> [1] https://github.com/w3c/mediacapture-main/issues/268 >>> >> >> > >
Received on Friday, 4 December 2015 15:41:10 UTC