- From: Mike West <mkwst@google.com>
- Date: Mon, 23 Feb 2015 10:59:27 +0100
- 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>
- Message-ID: <CAKXHy=f0izXfAS9Wpk7CThac8TeORRpYQppCmReojbEw3mur0Q@mail.gmail.com>
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