- From: Israel Hilerio <israelh@microsoft.com>
- Date: Tue, 17 Mar 2015 22:40:50 +0000
- To: Richard Barnes <rbarnes@mozilla.com>, Mike West <mkwst@google.com>, "Eric Rescorla" <ekr@mozilla.com>, David Baron <dbaron@dbaron.org>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <BL2PR03MB2123A72B88B8704306CE343A9030@BL2PR03MB212.namprd03.prod.outlook.com>
From Microsoft’s perspective, 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. Like Richard says, it seems that it will be useful to initially focus on the definition of what a privileged context is and then outline the factors that will drive features to be in a privileged context. To that end, what if we were to split the current proposal [1] into two documents: * Document #1 would define the concept of a privileged context, identify threat models, and define algorithm (section 1, 2, 3.1, and 5). The initial part of Section 3 can be used to describe factors that may cause a feature to be associated with a privileged context. Perhaps, a high level list without examples. * Document #2 would elaborate on the initial part of Section 3 and would go into details of why privileged context should be considered for new features, Section 4. In this section, we could provide some examples of new features that fit in this category and why (e.g. Service Workers, etc.). The section on Legacy features could be also expanded to outline the various features we believe should be executing on privileged context. In this document, we can define examples and propose individual legacy technologies to pave the way. We might be able to even propose a desired timeframe. We believe that splitting the current proposal will not affect the overall scope, effectiveness, or impact of the group. It will only impact the deliverables. In addition, it helps us move the concepts forward quickly by driving agreement and consensus on areas where there is common understanding. From our perspective, we would like to see Doc #1 have higher priority than Doc #2 but that doesn’t mean that we wouldn’t make any progress on Doc #2. The two docs can be driven in parallel. I’m not sure that following Richard’s advice takes away from the WebAppSec WG ability to assist others when making decisions about whether or not to lock a feature to a privileged context. If anything it seems like it helps us focus. Israel [1] https://w3c.github.io/webappsec/specs/powerfulfeatures/#feature-requires-privilege On Tuesday, March 17, 2015 3:15 AM, Mike West [mailto:mkwst@google.com] wrote: 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.)
Received on Tuesday, 17 March 2015 22:41:20 UTC