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> 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>, @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.)