I don't really think there is a controversy here network wise - mostly applicability is a case of "I know it when I see it" and the emphasis here is on things that are exposed at the webdev level is the right thing. Sometimes that's markup, sometimes that's header names which can touch on core protocol topics (but usually don't)... and just because Content-Security-Policy probably is one of those things, it doesn't mean every other header is too. That's a fine clarification that I think is already in sync with the proposal.
Brian and I deal with a lot of things that can be negotiated on a protocol level and therefore don't have to stand the test of time because they aren't baked into markup or semantics that need to live forever... when done well they have built in fallbacks that allow iteration and real experience before baking them into standards. That's awesome for the Internet and I don't sense anybody on this thread trying to disrupt that. So while we should be experimenting with 50 different implementations to make your network traffic faster and more secure we shouldn't be as freely messing with the semantics of that. And I think we're decent at that.. an interesting case in point is SPDY - I have a stack of requests from folks doing sophisticated Real User Monitoring/RUM (e.g. Akamai) that want to be able to track whether or not a page was loaded with some version of spdy and therefore need some kind of content-js accessible indicator. Its totally reasonable. But, while I have totally rearranged everything about the network transfer with spdy and will probably be doing it again shortly, I've been hesitant to add a small bit of markup to the DOM that might fragment markup and javascript without some effort at standardization. (Chrome has a mechanism if anybody is interested in taking that topic up fwiw.). On Tue, Jun 25, 2013 at 10:11 AM, Brian Smith <bsm...@mozilla.com> wrote: > Robert O'Callahan wrote: > > On Tue, Jun 25, 2013 at 3:08 PM, Brian Smith <bsm...@mozilla.com> wrote: > > > > > At the same time, I doubt such a policy is necessary or helpful for the > > > modules that I am owner/peer of (PSM/Necko), at least at this time. In > > > fact, though I haven't thought about it deeply, most of the recent > evidence > > > I've observed indicates that such a policy would be very harmful if > applied > > > to network and cryptographic protocol design and deployment, at least. > > > > > > > I think you should elaborate, because I think we should have consistent > > policy across products and modules. > > I don't think that you or I should try to block this proposal on the > grounds that it must be reworked to be sensible to apply to all modules, > especially when the document already says that that is a non-goal and > already explicitly calls out some modules to which it does not apply: "Note > that at this time, we are specifically focusing on new JS APIs and not on > CSS, WebGL, WebRTC, or other existing features/properties." > > Somebody clarified privately that many DOM/JS APIs don't live in the DOM > module. So, let me rework my request a little bit. In the document, instead > of creating a blacklist of web technologies to which the new policy would > not apply (CSS, WebGL, WebRTC, etc.), please list the modules to which the > policy would apply. > > It seems (from the subject line on this thread, the title of the proposal, > and the text of the proposal) that the things I work on are probably > intended to be out of scope of the proposal. That's the thing I want > clarification on. If it is intended that the stuff I work on (networking > protocols, security protocols, and network security protocols) be covered > by the policy, then I will reluctantly debate that after the end of the > quarter. (I have many things to finish this week to Q2 goals.) > > Cheers, > Brian > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
