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

On Wed, Mar 18, 2015 at 4:39 AM, Stefan Håkansson LK <
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>> 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.

 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.

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