RE: Privileged contexts charter text

“describe factors that factors to be considered” looks like a typo, right around the pivotal phrase. Should that actually say “describe factors to be considered”?

From: Mike West [mailto:mkwst@google.com]
Sent: Tuesday, March 17, 2015 3:15 AM
To: Richard Barnes; Eric Rescorla; David Baron
Cc: public-webappsec@w3.org
Subject: Re: Privileged contexts charter text

Thanks for following up on last night's call, Richard!

+ekr@ and dbaron@ to make sure we're all on the same page.

On Tue, Mar 17, 2015 at 3:13 AM, Richard Barnes <rbarnes@mozilla.com<mailto:rbarnes@mozilla.com>> wrote:
Dear WebAppSec,

This is the thread where we discuss the question of scoping the "Privileged Contexts" deliverable.  Without further ado, here's our proposed charter text:

-----BEGIN-----
Privileged Contexts (FPWD) - A  recommendation defining a notion of privileged contexts, which can be used by other features to define security boundaries, e.g., to protect  access to sensitive personal information.  The recommendation will  describe factors that factors to be considered in deciding when the  use of a privileged context should be required.  This work will be a  joint deliverable with the W3C Technical Architecture Group.
-----END-----

The major differences here are (1) it focuses on the definitional aspect of the document, and (2) instead of "non-normative advice", it calls for "factors to be considered".

I think the rewrite's focus on #1 is fine, and probably increases clarity. The normative force of the document lies in defining the term "privileged contexts", and that's the piece I expect other specifications to latch onto (as Service Workers and others already do).

I don't understand the value you see in #2. "These are the factors to be considered." vs "We non-normatively advise you to consider these factors." doesn't soin Moreover, I continue not to understand how giving folks a list of factors to consider is anything other than "advice". I feel like we're arguing about this word just to have something to argue about.

My feeling is this: the WebAppSec group is qualified to assist other working groups when making decisions about whether or not to lock a feature to a privileged context. We can and should feel empowered to do so, individually and as a group (in the same way that the PING is asked to weigh in on privacy concerns, the a11y group on accessibility concerns, and etc). We say as much elsewhere in the charter: "In addition to developing Recommendation Track documents in support of these goals, the Web Application Security Working Group may provide review of specifications from other Working Groups...". Do you and ekr@ disagree with that core assumption? If so, what business do we have producing recommendations at all?

If these words about this specific deliverable make you happy enough to withdraw your formal objection, I can live with giving other working groups advice in the form of "factors to be considered".

Now, why do we think this is better?  In brief, because it gets work done -- it focuses on the areas where there is very widespread consensus, and punts on questions that will slow this work down.

I think it's quite admirable to focus on things that will speed us up.

That said, I don't generally agree that avoiding controversial questions in the pursuit of speed is a reasonable tradeoff. Questions without a clear answer are often the interesting questions. Punting them might let us "get work done", but if the work doesn't provide guidance, it's not clear why it's valuable to achieve. In other words, why have "factors to be considered" at all, if our goal is to minimize disagreement?

Let me start by saying that we are totally on board with the idea of privileged contexts and the idea that more of the web needs to live there -- ideally the whole web.

This is something we agree on! How about we just say "User agents SHOULD stop sending the kinds of data outlined in 'Factors to be Considered' section over unauthenticated plaintext transport." and let UAs determine deprecation schedules based on that optional requirement?

The question is how best to move toward that state.  There's a need here to balance between building momentum behind privileged contexts by providing good tools, while not creating negative energy that will slow it down.

Is your claim that "advising" other groups about considerations which would lead to locking a feature to privileged contexts is "negative energy"?

There is very widespread agreement that a consistent definition of privileged contexts would be a useful tool for building the web, and even the considerations that one has to balance when deciding when to use them.

Could you list the considerations that you think should be added or removed to the categorizations proposed in https://w3c.github.io/webappsec/specs/powerfulfeatures/#feature-requires-privilege? It sounds like you have several in mind already, and it would be interested to see how they differ practically from what I've proposed.

Worse, it's not hard to imagine that once the rest of the community gets wind that criteria are being defined for what should be restricted (as sections 3 and 4 do), folks will show up to make sure that their favorite API isn't covered.

ekr@ noted in the call that, in heated arguments, "non-normative advice" is used to justify recommendations. Do you think that's going to change by calling it something else? Folks with strong feelings will continue to have strong feelings regardless of the words used to describe the thing they have feelings about. :)

How would this change the current document?  First, the overall focus of the document would be more on what's currently Section 5, defining what a secure context is.  I would also like to see more discussion of what the use of a privileged context means for an API; what guarantees it gets.  Likewise, it would be helpful to expand the threat models in section Section 3.1, again explaining the implications of these models for evaluating API risks.  Section 3 and Section 4 are where the real problem lies.  They are very prescriptive, and since they provide no justification of how they arrive at their prescriptions, not very helpful to API designers.

This is totally reasonable criticism. Thank you.

Perhaps it would be helpful for you to take a stab at outlining the factors you'd suggest that folks consider, in a way that is less prescriptive than the current 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.)