- From: Eric Rescorla <ekr@rtfm.com>
- Date: Wed, 18 Mar 2015 12:10:24 -0700
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <CABcZeBP97ChPdTEjjzGP7TFhez6ZOmL_FBPMw8f=bV3o_i5PKA@mail.gmail.com>
On Wed, Mar 18, 2015 at 11:26 AM, Stefan Håkansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 18/03/15 15:12, Eric Rescorla wrote: > > > > > > On Wed, Mar 18, 2015 at 4:39 AM, Stefan Håkansson LK > > <stefan.lk.hakansson@ericsson.com > > <mailto:stefan.lk.hakansson@ericsson.com>> wrote: > > > > On 13/03/15 14:20, Eric Rescorla wrote: > > > > > > > > > On Fri, Mar 13, 2015 at 3:50 AM, Harald Alvestrand < > harald@alvestrand.no <mailto:harald@alvestrand.no> > > > <mailto:harald@alvestrand.no <mailto:harald@alvestrand.no>>> > wrote: > > > > > > I have argued in the past that we should separate the > > > ask-for-permissions step from the use-device step, and found > that the > > > consensus of the group was that the two should not be > separated. > > > > > > However, if the group were to change its mind, it would not be > illogical > > > to attach the "and store this permission for this origin > forever or > > > until the user revokes it" to the ask-for-permissions step > rather than > > > the use-device step. > > > > > > This would, however, be an incompatible change from what > browsers > > > currently do, which is to save permissions whenever they think > it's > > > reasonable to do so. > > > > > > > > > That's not quite what Firefox does. Firefox only saves persistent > > > permissions > > > if the user asks it to. > > > > > > (If we were to retrofit the explicit model of permissions > storage onto > > > the getUserMedia joint model without an API change, we could > define a > > > constraint called "permissionPersistence" with values > "this-call" and > > > "until-revoked" > > > > > > > > > Yes, this is roughly what I think the Security Architecture > document > > > contemplates. Again, I should emphasize that I'm willing to be > convinced > > > that the Security Architecture requirements are wrong, but if > that's so, > > > we do need to determine what, if anything, the specs say here. > > > > My conclusion of the discussion so far is that we do not have > consensus > > to change the gUM API to enable the application to specifically > request > > persistent permission, so I think we should simply change the > Security > > Architecture document requirement. > > > > > > I don't really think this gets the job done. The Security Arch document > > has been through IETF WG LC, so just changing it isn't really right > > either. I think we actually need to discuss this in some live forum, > > whether a telechat or a meeting. > > The sec architecture document is an IETF document; are you proposing an > IETF live forum (of some kind), or a W3C Media Capture TF forum? > Well, ultimately this is a levy on the TF from the IETF. I'm happy to discuss this in the IETF context, but if IETF decides not to change it (and for the record, my view is we should not) then we're going to be right back here. FWIW, to me the question seem straightforward enough to handle in an > off-line discussion. That may be, but IMO this present discussion is nowhere near enough to override the IETF WG consensus on a document that has been through WGLC. -Ekr > On the second part, if, and if so how, the text in the gUM document > > > > should be changed I'm less sure. I think that we at the very least at > > some stage need to go through what is stated, and how it is stated, > now, > > because currently we have under the main heading "Implementation > > Suggestions" and sub-heading "Best Practice 2: Stored Permissions" > the > > text "Such storing MUST only be done when the page is secure (served > > over HTTPS and having no mixed content)." It is not entirely clear > to me > > if something under "suggestions" and "best practice" is normative or > > not. > > > > > > I think that's an editorial problem. My understanding is that there is > > consensus > > that this is a MUST-level requirement, so the editors should just move it > > out of this section. > > I agree. > > > > > -Ekr > > > > > > Stefan > > > > > > > > -Ekr > > > > > > - one could then use the constraint resolution model to > > > let the UA get a constraint failure if the UA refused to > > store the > > > permission, if that's a desirable function.....) > > > > > > > > > > > > On 03/12/2015 10:48 AM, Stefan Håkansson LK wrote: > > > > On 10/03/15 19:50, Justin Uberti wrote: > > > >> I think we should follow the precedent that has been set > for > > > this sort > > > >> of thing on mobile devices, namely that apps ask for > > consent the > > > first > > > >> time they need the camera, and this permission is stored, > as > > > mentioned > > > >> in > > > >> > > > > > > http://useyourloaf.com/blog/2014/07/16/ios-8-camera-privacy-settings.html. > > > > Personally I don't agree (more on why below), but my > takeaway > > > from that > > > > is that we should perhaps leave the document as is since > it is > > > unlikely > > > > that we would find consensus if we try to add more detail > > on the > > > > behavior regarding stored permissions in a normative part > > of the > > > spec. > > > > > > > > Why I don't agree: I think there is a difference between > > an installed > > > > app and a web page. Installing an app is a much more > conscious > > > decision > > > > than, there is (usually) an app store involved, and an app > > can be > > > > uninstalled (of course you can revoke stored permissions - > but > > > that is > > > > not as intuitive to the average user IMO). > > > > > > > > Moreover, it is quite easy to imagine sites to ask for > > access to > > > camera > > > > and microphone (e.g. get support during a purchase in a > > web shop) in > > > > situations when you really like that access to be one time > > (I'd > > > not like > > > > that web shop to be able too use my camera next time I'm > > browsing its > > > > pages). > > > > > > > > And https is a good thing, but not sufficient IMO. Most > sites > > > will move > > > > there (and don't get me wrong: that is a good thing), so > > I'm not sure > > > > that "served over https" always equals "well behaved" and > > in addition > > > > not all of those sites will be professionally managed and > > could be > > > > hacked. So my very personal opinion is that allowing any > > site (served > > > > over https) to store permissions to use camera and > microphone > > > without my > > > > explicit permission to do so is not right. > > > > > > > > > > > > > > > > > -- > > > Surveillance is pervasive. Go Dark. > > > > > > > > > > > > > > > > > >
Received on Wednesday, 18 March 2015 19:11:34 UTC