- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 18 Mar 2015 18:26:18 +0000
- To: Eric Rescorla <ekr@rtfm.com>
- CC: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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? FWIW, to me the question seem straightforward enough to handle in an off-line discussion. > > 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 18:26:51 UTC