Re: BIKESHED: Rename "Powerful features"?

I see how "able to request a privilege" is itself a privilege, but I
suspect it'll be confusing. In particular, Crispin's analogy 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." is, I think, exactly this kind of confusion. "root" is a
privileged context because it has permission to do all sorts of things. The
system management programs expect you to get into a privileged context
because they want to use the permissions implied by that environment. They
don't use the 'root' environment to just ask for permissions. A
document-served-over-TLS, on the other hand, has only this one unusual
permission by itself. The system management programs wouldn't be able to
just insist on running inside a document-served-over-TLS, and I don't
really want to use the term "privileged context" lest it encourage people
to think it implies other privileges.

However, if I'm the only person worried about this, I don't want to hold
anything up. I've been heard; feel free to agree I'm wrong, or just not
right enough to repaint the bikeshed. :)

Jeffrey

On Mon, Feb 23, 2015 at 8:43 PM, Yan Zhu <yzhu@yahoo-inc.com> wrote:

> +1 for not splitting the document.
>
> I think "privileged context" does make sense because being privilege-able
> is a privilege in and of itself. Contexts that are privilege-able have the
> privilege of getting more privileges.
>
> PS: mike, you should check your privilige :)
>
>
>   On Monday, February 23, 2015 5:47 AM, Mike West <mkwst@google.com>
> wrote:
>
>
> 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.)
>
>
>