Re: BIKESHED: Rename "Powerful features"?

"Privileged features" would be fine too, if the document needs to be
named after the features. "Privileged features require secure
contexts" makes sense to me.

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. 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.
>
> 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.
>
> 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".
>
> 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?
>
> Jeffrey
>
>
> On Mon, Feb 23, 2015 at 10:59 AM, Mike West <mkwst@google.com> wrote:
>> It looks like there's rough consensus to rename the draft to "Privileged
>> Contexts". I've done so in
>> https://github.com/w3c/webappsec/commit/ee4f1d83de5fbb720541a440c07f44ececdc98a6,
>> along with marking the formerly "powerful features" section as
>> non-normative.
>>
>> Thanks, folks!
>>
>> -mike
>>
>> --
>> 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.)
>>
>> On Sat, Feb 21, 2015 at 2:24 AM, Oda, Terri <terri.oda@intel.com> wrote:
>>>
>>> +1 to "privileged context" as well.  I'm not convinced it's the best
>>> possible term, but I haven't been able to think of anything better at the
>>> moment and I do think it's at least a bit more clear and a little less
>>> overloaded than "powerful" is.
>>>
>>> On Wed, Feb 18, 2015 at 6:59 PM, Alex Russell <slightlyoff@google.com>
>>> wrote:
>>>>
>>>> I think "privileged" works well. I've worried in past that such a
>>>> restriction would cause debates about new layout features which are unlikely
>>>> to create new opportunities to alter the origin model and (perhaps this just
>>>> me), but "privileged" seems to exclude features like that but capture
>>>> features which have the ability to change the relationships between origins
>>>> (e.g., Service Workers or hardware token access in Web Crypto).
>>>>
>>>>
>>>> On Wed, Feb 18, 2015 at 3:53 PM, Crispin Cowan <crispin@microsoft.com>
>>>> wrote:
>>>>>
>>>>> I'm still not entirely clear on the semantics, but my gut says that a
>>>>> more relevant term would be "Privileged context"; the feature needs higher
>>>>> privilege to be able to access something that enables the feature.
>>>>>
>>>>>
>>>>>
>>>>> From: Mark Watson [mailto:watsonm@netflix.com]
>>>>> Sent: Wednesday, February 18, 2015 1:00 PM
>>>>> To: Crispin Cowan
>>>>> Cc: Mike West; public-webappsec@w3.org; Yan Zhu; Brian Smith
>>>>>
>>>>>
>>>>> Subject: Re: BIKESHED: Rename "Powerful features"?
>>>>>
>>>>>
>>>>>
>>>>> It's hard to argue that a feature which exposed a vast library of
>>>>> advanced mathematical functions is not "powerful", but - correctness and
>>>>> speed aside - such a library could equally well be built in Javascript, so
>>>>> it's also hard to argue that it requires a secure origin. One can imagine
>>>>> features that access the users machine in a way that requires user
>>>>> permission but which aren't otherwise all that powerful and one can well
>>>>> argue that such a feature - because of the desire to know to whom permission
>>>>> is being granted - should require a secure origin.
>>>>>
>>>>>
>>>>>
>>>>> "Powerful" and "Requires a secure context" are not well aligned.
>>>>>
>>>>>
>>>>>
>>>>> Why not call the document "Secure contexts" and the features "Features
>>>>> requiring a secure context" ?
>>>>>
>>>>>
>>>>>
>>>>> ...Mark
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 18, 2015 at 12:44 PM, Crispin Cowan <crispin@microsoft.com>
>>>>> wrote:
>>>>>
>>>>> How about we go to the required semantics, and then reverse-engineer a
>>>>> name?
>>>>>
>>>>>
>>>>>
>>>>> I have not read the spec. Rather than giving excuses or whining about it
>>>>> J I will use it as a forcing function: someone plese post no more than 100
>>>>> words why some "powerful" features need Foo treatment, and other "!powerful"
>>>>> features need bar treatment. From there we hopefully can derive a good name
>>>>> for this feature property.
>>>>>
>>>>>
>>>>>
>>>>> Why 100 words? If it takes more than that, then I submit the concept
>>>>> isn't baked yet.
>>>>>
>>>>>
>>>>>
>>>>> From: Mike West [mailto:mkwst@google.com]
>>>>> Sent: Wednesday, February 18, 2015 8:03 AM
>>>>> To: Mark Watson
>>>>> Cc: public-webappsec@w3.org; Yan Zhu; Crispin Cowan; Brian Smith
>>>>> Subject: Re: BIKESHED: Rename "Powerful features"?
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 18, 2015 at 4:49 PM, Mark Watson <watsonm@netflix.com>
>>>>> wrote:
>>>>>
>>>>> I'm sorry you feel this is a "bikeshed"
>>>>>
>>>>>
>>>>>
>>>>> That was supposed to be a joke. :) I thought your concerns were
>>>>> reasonable, and I think it's worth bringing them back to the group
>>>>> explicitly.
>>>>>
>>>>>
>>>>>
>>>>> - the objective is to *avoid* future pointless nebulous discussions of
>>>>> the kind "is X 'powerful' ?" in favor of a more concrete "does X require a
>>>>> secure context ?". "Secure context" is a term we can own and define
>>>>> rigorously, "powerful" is not.
>>>>>
>>>>>
>>>>>
>>>>> I think you underestimate the ability of people to argue about terms. :)
>>>>> "Secure" is certainly something that folks can and will debate. See, for
>>>>> instance, the long, long threads discussing opportunistic encryption. Is
>>>>> that secure? I certainly have an opinion, and I know completely reasonable
>>>>> folks who completely disagree with me.
>>>>>
>>>>>
>>>>>
>>>>> You could reasonably drop the qualifier "sufficiently" on the grounds
>>>>> that we don't generally bother writing specs for things that are
>>>>> "insufficient" and you could name the section "Features requiring secure
>>>>> contexts".
>>>>>
>>>>>
>>>>>
>>>>> I think at some point we need to accept that we're defining a term. If
>>>>> it's the case that defining "sufficiently secure" is as likely to cause
>>>>> debate as defining "powerful feature", then let's leave things as they are,
>>>>> because "POWER" is a totally radical name for a spec.
>>>>>
>>>>>
>>>>> --
>>>>> 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.)
>>>>>
>>>>>
>>>>
>>>>
>>>
>>

Received on Monday, 23 February 2015 13:35:11 UTC