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

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