RE: BIKESHED: Rename "Powerful features"?

I suggested calling them "privileged contexts" on the basis that the features *need* to be in a privileged context to work, not that having the feature makes the context privileged. It is similar to system management programs that need to run as root, but are not setuid root, they just expect you to do something to get into a privileged context before you run them.

From: Mike West [mailto:mkwst@google.com]
Sent: Monday, February 23, 2015 5:45 AM
To: Jeffrey Yasskin
Cc: public-webappsec@w3.org
Subject: Re: BIKESHED: Rename "Powerful features"?

On Mon, Feb 23, 2015 at 2:22 PM, Jeffrey Yasskin <jyasskin@google.com<mailto: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<mailto: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.)