Subject: [rtcweb] Agenda time request: Security API requirements for persistent permissions

From: Harald Alvestrand <[email-masked]>
Date: Thu, 19 Mar 2015 10:54:42 +0100

Speaking with my W3C WG chair hat on:

An item has come up that relates to the IETF draft 
"draft-ietf-rtcweb-security-arch".

The issue is this requirement:

    Implementations MUST obtain explicit user consent prior to providing
    access to the camera and/or microphone.  Implementations MUST at
    minimum support the following two permissions models for HTTPS
    origins.

    o  Requests for one-time camera/microphone access.
    o  Requests for permanent access.

.....

    API Requirement:  The API MUST provide a mechanism for the requesting
       JS to indicate which of these forms of permissions it is
       requesting.  This allows the browser client to know what sort of
       user interface experience to provide to the user, including what
       permissions to request from the user and hence what to enforce
       later.  For instance, browsers might display a non-invasive door
       hanger ("some features of this site may not work..." when asking
       for long-term permissions) but a more invasive UI ("here is your
       own video") for single-call permissions.  The API MAY grant weaker
       permissions than the JS asked for if the user chooses to authorize
       only those permissions, but if it intends to grant stronger ones
       it SHOULD display the appropriate UI for those permissions and
       MUST clearly indicate what permissions are being requested.

At the moment, the W3C Media Capture TF doesn't have a mechanism for the 
JS to indicate whether it desires one-time access or permanent access. 
There hasn't been a request for this from app developers, and none of 
the implementations so far have added such a feature.

Having a requirement specification and an API specification that don't 
match is obviously not a Good Thing. There are two solutions that 
suggest themselves:

- Delete the requirement
- Add a mechanism

Discussion on the public-media-capture list did not provide a consensus 
that one of these alternatives is clearly superior to the other, and the 
suggestion was made that face-to-face discussion would be a reasonable 
way to move forward.

Since the security-arch document is an IETF document, and the IETF 
meeting is next week, it seems reasonable to ask for some agenda time 
next week for this issue.

Can this be accomodated?

Harald

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Mar 2015 10:49:17 -0700

We have added this topic to the working copy of the agenda, and it will be
in the first day.  We've allocated 15 minutes for it at the moment, but we
can probably accommodate more on day two if need be.

regards,

Ted

On Thu, Mar 19, 2015 at 2:54 AM, Harald Alvestrand <[email-masked]>
wrote:

> There hasn't been a request for this from app developers, and none of the
> implementations so far have added such a feature.
>
> match is obviously not a Good Thing. There are two solutions that suggest
> themselves:
>
> - Delete the requirement
> - Add a mechanism
>
> suggestion was made that face-to-face discussion would be a reasonable way
> to move forward.
>
> Since the security-arch document is an IETF document, and the IETF meeting
> is next week, it seems reasonable to ask for some agenda time next week for
> this issue.
>
> Can this be accomodated?
>
> Harald
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Mar 2015 19:28:52 +0000

> can probably accommodate more on day two if need be.

Good to see this discussed. I think I have a conflict or I'd be
hoping to be there. If I'm not, I guess I'd be delighted if that
discussion also includes revocation of permissions.

Some folks might consider that the way to handle revocation of
that is to e.g. revoke all camera/mic permissions for all origins
(as is done with e.g. "private data" on some browsers). I think
that approach is very privacy unfriendly and hope that it's not
considered acceptable for WebRTC. The effect of the privacy
unfriendly approach is that a user cannot revoke permissions for
any origin so long as there is one origin for whom they do not
want to revoke permissions. The net of that is that the user will
not revoke permissions, so the feature at that point may as well
not have been present.

I think that is a real problem. I am not asserting that providing
per-origin revocation interfaces is a perfect answer, but I think
it is defensible as being a lot better.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2015 17:02:45 -0700

On Thu, Mar 19, 2015 at 12:28 PM, Stephen Farrell <[email-masked]

> it is defensible as being a lot better.

FWIW I believe that both Chrome and Firefox allow per-origin revocation

-Ekr

Cheers,
> S.
>
>
> >
> > regards,
> >
> > Ted
> >
> > On Thu, Mar 19, 2015 at 2:54 AM, Harald Alvestrand <[email-masked]
> >
> > wrote:
> >
> the
> suggest
> way
> meeting

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Mar 2015 19:29:04 -0700

> FWIW I believe that both Chrome and Firefox allow per-origin revocation

...Both without actually visiting that origin. You can thank Alissa Cooper
for that.