Re: BIKESHED: Rename "Powerful features"?

On Mon, Feb 23, 2015 at 2:22 PM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

> I think "Privileged Contexts" is actually incorrect. The contexts are
> only privileged if users grant them the actual permissions.


This is an interesting aspect I hadn't considered: the "privilege" in
question actually has nothing directly to do with granted permissions. Some
features (geolocation, for example) may choose to lock themselves behind a
permission grant as well, but for others, simply running on HTTPS will be
enough (WebCrypto, for instance).

That confusion probably dooms the term. Ugh.

Also, I can barely spell priviliged [sic], which is another argument
against. :/


> They're
> not privileged just by virtue of being served over TLS. To some extent
> they're "privilegable", since they're the only contexts in which users
> are allowed to grant the privileges, but that term is too awkward to
> live.
>

I agree, "privilegable" is right out.


> Similarly, defining "A *privileged context* is one in which features
> with the kinds of properties discussed in
> [[#feature-requires-privilege]] can safely execute." is worse than the
> old definition "any settings object is *sufficiently secure* if the
> algorithm defined in [[#settings-sufficiently-secure]] returns
> `Sufficiently Secure` when executed upon it." because you've gone from
> an algorithm to a value judgement.
>

Well, that sentence is followed up by normative definitions of "privileged
document" and "privileged worker", which map directly to the algorithm
you're pointing to. I don't know how to add any sort of prose here
explaining the concept that isn't in some way recursive.

As Yan said, "the normative focus is more likely to be the "is X a
> secure context" section than the "is Y powerful" section.", so it's
> odd to name the whole spec after the non-normative part. I still like
> Mark's suggestion to name the spec "Secure contexts".
>

I'm fine with "secure", if and only if everyone advocating opportunistic
encryption agrees not to start arguments about whether or not such a thing
is "secure".


> Would this be simpler if the TAG collaboration about
> "powerful/privileged features" went into a separate document from the
> just-WebAppSec deliverable of the definition of XYZ Contexts?
>

I don't think there's much value in splitting the discussion between
"[features] that require [things]" on the one hand and "[things] that
enable [features]" on the other. I'd prefer one document.

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)