Re: Proposed new text for noaccess

On 28 October 2013 05:08, Harald Alvestrand <harald@alvestrand.no> wrote:
> This is an important consideration: Whether a track's access provisions
> can be changed after creation.
>
> If it can be changed (especially if the constraint can be removed and
> replaced), I have issues.

Let's explore those issues.

One approach for addressing these three constraints: noaccess,
peeridentity (or should that be "peeridentity"...) , and what I'll
call "full", is to treat noaccess as requiring no consent,
peeridentity as requiring a very specific, directed consent (site
example.org wants to send to foo@example.com), and generic (site
example.org wants).

But, as Adam observes:

> This has been brought up before, and the conclusion was that this may freak
> people out; to suddenly, without their consent, see a video of themselves on a
> random web page.

I'm actually less concerned about this, though I think it's going to
be necessary to provide appropriate user feedback if this sort of
feature is enabled.

Naturally, I see these constraints as being progressive.  You require
more consent to grant greater privileges, therefore each increase
requires consent.  The first class of problems I see there are with
respect to the consent mechanism itself.  The usual fatigue concerns
apply.  I don't want to see multiple consent dialogs from a site.

I see no concern with downgrading access from full to peeridentity.
In fact, since doing so should be a prerequisite for obtaining an
identity assertion regarding the session, I don't think that there is
a strong reason NOT to allow downgrade of access.

I also see no problem with changing "noaccess" (obtained with
permission) to "full" or "peerIdentity" for the purposes of sending to
a remote peer.  As long as the consent dialog is displayed at that
point, I'm not concerned that there is a risk of exposure or bad stuff
happening.

What concerns me is the elevation from peeridentity to full.  There we
lose all the guarantees we've built around peer identity features.

I think that the state machine should be something like this:

* -> none : ok, no consent
* -> noaccess : no consent
noaccess -> peeridentity : consent
noaccess -> full : consent
peeridentity -> full : forbidden
full -> peeridentity -> ok, no consent

The only thing that really concerns me is how the browser indicates
that noaccess is not available to the site.  Assuming that this
creep-out issue isn't that significant.  There are some interesting UX
issues that arise around that.  I can think of many approaches:
borders (potentially problematic), the word "preview" as a watermark
over the video (no idea what to do for audio...), etc...

Received on Monday, 28 October 2013 17:04:59 UTC