Re: [rtcweb] Conditions for long-term permissions grants

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>> 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.

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.

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 11:40:12 UTC