W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: BIKESHED: Rename "Powerful features"?

From: Mike West <mkwst@google.com>
Date: Mon, 23 Feb 2015 10:59:27 +0100
Message-ID: <CAKXHy=f0izXfAS9Wpk7CThac8TeORRpYQppCmReojbEw3mur0Q@mail.gmail.com>
To: "Oda, Terri" <terri.oda@intel.com>
Cc: Alex Russell <slightlyoff@google.com>, Crispin Cowan <crispin@microsoft.com>, Mark Watson <watsonm@netflix.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Yan Zhu <yzhu@yahoo-inc.com>, Brian Smith <brian@briansmith.org>
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 10:00:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC