- From: Eric Rescorla <ekr@rtfm.com>
- Date: Mon, 2 Jun 2014 12:33:22 -0700
- To: Jim Barnett <1jhbarnett@gmail.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <CABcZeBP758td9Y_nV0dBZLZS-qGKn6hUA1WF5se5i1CPp-Vh-A@mail.gmail.com>
On Mon, Jun 2, 2014 at 12:01 PM, Jim Barnett <1jhbarnett@gmail.com> wrote: > Didn't we have discussions in the past about 're-hydrating' sessions upon > page reload? I don't think the discussions ever got anywhere, but it > certainly sounded at the time like we were assuming that the app could keep > using the device without an additional prompt. > The assumption was that apps who wanted this to work would get persistent permissions. Is there any argument for this more expansive view of permissions other than to spare sites from implementing HTTPS? -Ekr I think Harald is right that users won't expect to be reprompted after a > page reload. It may well be that the security issues that ekr has raised > means that they must be, but I think that they will be surprised/annoyed > when it happens. (Along the lines of: "I already told you that you > could use the camera. I just reloaded the page because the video was > looking weird now you throw everything out and ask me a question that I > already answered.") > > > On 6/2/2014 2:51 PM, Martin Thomson wrote: > >> On 2 June 2014 09:42, Harald Alvestrand <harald@alvestrand.no> wrote: >> >>> The WG has repeatedly rejected having more API surface to manipulating >>> permissions, so "getUserMedia" and "track.close" are the two controls we >>> have; my proposal would be making the last one a no-op, permission-wise. >>> >> Yes, I object to this. >> >> I think that this more easily leads to the surprising situation where you >> can: >> >> a) have the camera turn on at some future point in time >> >> and perhaps more seriously: >> >> b) have a different camera turn on >> >> Both of which I find highly objectionable. >> >> I understand that you would have the "passive" indicator present for >> the duration, but that's still pretty surprising. >> >> I need to understand how you might need this capability. I understood >> Justin's mute scenario well enough. Can you actually make a case for >> this? >> >> --Martin >> >> p.s., track.close() releasing permissions is a perfectly good API >> surface. Why would you suggest that we need a different surface? >> >> > -- > Jim Barnett > Genesys > >
Received on Monday, 2 June 2014 19:34:31 UTC