Permalink
Browse files

CSP 1.1: Remove note about extensions.

Based on the discussion at [1], dropping this bit entirely is
the right thing to do to address the formal objection raised.

[1]: http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0165.html
  • Loading branch information...
mikewest committed Jan 29, 2014
1 parent 27ae7a0 commit cbfaa8edfadebf21a9c7428242c12e45934d8c55
Showing with 0 additions and 4 deletions.
  1. +0 −4 specs/content-security-policy/csp-specification.dev.html
@@ -902,10 +902,6 @@ <h3>Processing Model</h3>
usurp the resource's privileges that have been restricted in this
way.</p>
<p>Enforcing a policy SHOULD NOT interfere with the operation of

This comment has been minimized.

@pombredanne

pombredanne Mar 3, 2014

FWIW, 73963d5 now has a compromise wording, which is IMHO quite a weak guideline

user-supplied scripts such as third-party user-agent add-ons and
JavaScript bookmarklets.</p>
<p>To <dfn id="monitor">monitor</dfn> a policy, the user agent MUST
<a href="#parse-a-policy">parse the policy</a> and monitor each of
the directives contained in the policy.</p>

24 comments on commit cbfaa8e

@scoates

This comment has been minimized.

scoates replied Feb 19, 2014

👎

@mitar

This comment has been minimized.

mitar replied Feb 19, 2014

Very bad move. How can I raise formal objection to this formal objection?

@newlog

This comment has been minimized.

newlog replied Feb 19, 2014

WTF! This are not good news...

@g4jc

This comment has been minimized.

g4jc replied Feb 20, 2014

-1
This would effectively kill userscripts.org and other excellent websites which give users control over their data. At most a warning could be displayed asking the user if they wish to run it, completely denying this ability is fairly draconian.

@mushon

This comment has been minimized.

mushon replied Feb 20, 2014

@mikewest to answer to the complaints raised above, would you explain how would this change indeed affect user scripts and other client-side manipulations of web content? Does it indeed hinder the rich and important culture of JS browser extensions?

@mikewest

This comment has been minimized.

Member

mikewest replied Feb 20, 2014

I think there's a bit of misunderstanding here: I apologize that the context from the disucssion on the list didn't quite make it into this commit message. http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0006.html sums up where I think we've landed.

In short: removing this sentence does not mean that I'm going to change Blink to prevent extensions from running in a page otherwise protected by CSP, nor does it change Firefox's commitment to treat CSP-blocked add-ons as bugs. Since both extensions and add-ons are explicitly vendor-specific, talking about them in a spec whose normative obligations must be tested cross-browser doesn't make sense. User agents remain free to make whatever choice makes sense for their context, just as they were before. That's it. Nothing nefarious intended.

Does that clear things up?

@mitar

This comment has been minimized.

mitar replied Feb 20, 2014

No. Because the point of a standard is to define behavior of implementations which is desired by the wider community. I think the confusion here is that some feel that the wider community feels implementations SHOULD be implemented so that CSP does not interfere with user specified scripts. So if an implementation wants to adhere to the standard, it should not interfere. Not that it is left to the implementation to decide that. Of course implementation can still decide not to adhere to the standard.

And do not forget that we are here talking not just about vendor specific add-ons and extensions, but about bookmarklets as well. I think for add-ons and extensions is more clear, but for bookmarklets is not so clear how it should behave. And standard should make this more clear. This is what standard are for?

One more question. The message you linked above is saying:

Relevantly, the WG polled its participants on this question back in September 2013[1], and the response was quite negative to the question as to whether "We should make changes to core CSP 1.1 behavior (including possibly specifying a new directive about user script) as requested by Bug 23357?" It appears that Cox was the only positive vote on that poll. Brad, please correct me if I missed additional votes.

I am reading this right that the response on the pool was quite negative to removing the paragraph and the paragraph was still removed?

@devd

This comment has been minimized.

Contributor

devd replied Feb 21, 2014

Hi everyone! Thanks for all your interest in CSP! I am super glad!

Can I request everyone to participate on the mailing list too? While Mike and a few interested people keep an eye on this project, (for better or worse) it is really the mailing list where these issues are discussed and consensus achieved.

Bringing up these issues on the mailing list could really help highlight your (I believe valid) concerns to the broader working group instead of just the few folks who keep an eye on this project. Additionally, others can respond to the concerns you raised.

To be double certain that I am not misunderstood: I am actually encouraging you to voice your concerns more broadly, but I think mailing lists are the right place for this and not Github.

@Pomax

This comment has been minimized.

Pomax replied Feb 22, 2014

As a reality check, note that mailing lists are an excellent way to make sure only those in the know find out about this kind of thing. This change affects everyone in the world, not just those who keep up with the W3C webappsec mailing list.

This commit yields a universal specification that would now allow browser makers to lock down the web in a way that prior to this commit was explicitly forbidden, so a crucial part in keeping the web free (browsers taking certain default actions and users being able to override their browser because they know better) has been removed from this specification.

If any vendor decides to now make CSP override any and all bookmarklets and extensions, that's spec-compliant. Facebook strikes a deal with a vendor to prevent its site from ever being console-inspected? Too bad, that's now in-spec, even if Blink never goes down that path, because it's not about whether individual implementations start exploiting this permission, it's about the fact that this change now explicitly allows anyone to aid in lock-down. Something that we collectively really shouldn't want, nor should be trying to defend. After the discussion threads are archived, the only thing left to guide implementations is the spec itself. No booknotes or interpretation clarifications, the spec must stand on its own. Once formalised, there is no court that we can appeal to other than the text we "all" (never mind that almost no one with an opinion on this will know they even had to voice it) agreed on: when it comes to holding a browser vendor accountable for the behaviour of their browser, this spec is all we have.

And the browser market isn't nearly open enough to tell people to just use another browser if one or more of them exploit this permitted lockdown - there is no guarantee that the three big browsers won't all simply do the same thing, unless we state that this is not be allowed in the spec.

I'll try to comment on the list as well, but this decision is huge, and a w3c mailing list is a little bit like a bubble - those on it can easily forget their decisions impact the entire world in perpetuity, without ever asking that world for feedback, simple expecting them to already know that a specific mailing list (from amongst thousands) exists =)

@Arty-chan

This comment has been minimized.

Arty-chan replied Feb 22, 2014

Others have written a better explanation than I can already as to why this is a problem. I can only add to it that as an advocate of web accessibility; the user having full control of how to browse websites is a very important part of even having the ability to understand what's going on, for which things like modifying the website are essential. If CSP can overrule these plugins "over security concerns", more thought needs to go into this change.

I'll post this to the list as well, but I would like to point out that the process to post a simple message like this to the list is essentially a big huge wall (find the list address, find how to sign up somewhere else, sign up, confirm the sign up, then when you think you can post to the list, discover you need to permit archiving before the first lines you wanted to say can even make it to the list). The process alone might deter people from voicing their opinion on the mailing list rather than as a comment here (where the process is getting a github account, then posting a message). While I understand that to have a discussion, you might need a centralized point, people should not be deterred from voicing their support or opinions either way in as many modes of communication as possible and then those on the mailing list being informed of what "others" think.

@mitar

This comment has been minimized.

mitar replied Feb 22, 2014

I posted my concerns to the mailing list already. Feel free to pitch in there as well.

@DavidBruant

This comment has been minimized.

DavidBruant replied Feb 22, 2014

As a reality check, note that mailing lists are an excellent way to make sure only those in the know find out about this kind of thing. This change affects everyone in the world, not just those who keep up with the W3C webappsec mailing list.

Yeah... like everything on es-discuss, public-script-coord, public-webapps, whatwg, www-dom, www-style, etc.
For better or worse, that's how web technologies are designed. Either you have enough leverage to make everyone transition to something easier to use/"more open"(?) or accept things as they are. I'm registered on ~15-20 standard mailing-lists. I really don't like this situation, but I don't know how to change it.
Note that although complaining, you did hear about the change since you're here (W3C moving spec work to github was a good move to encourage more participation)

This commit yields a universal specification that would now allow browser makers to lock down the web in a way that prior to this commit was explicitly forbidden, so a crucial part in keeping the web free (browsers taking certain default actions and users being able to override their browser because they know better) has been removed from this specification.

When I read "allow browser makers" and "forbidden", I have the impression that you don't understand how web technologies happen (and I'm not blaming you, it took me years to understand). First and foremost, the W3C is a restaurant. The W3C specs don't force anything on anyone. Rather, most of the time, specifications catch up on reality of what has been implemented in browsers.
Like it or not, implementors have the power to do anything they want. anything. Even to diverge from specs, even to refuse to implement a spec, even to implement things that are in no spec (multiple examples of all three have existed in all version of all browsers).

Specs don't allow or forbid, they codify an agreement among browsers.

@mitar

This comment has been minimized.

mitar replied Feb 22, 2014

Specs don't allow or forbid, they codify an agreement among browsers.

But isn't an agreement for Blink and Mozilla at least that they will not block extensions and bookmarklets? Let's then codify that.

And it is not really so. For example, in the discussion on Mozilla ticket for CSP affecting bookmarklets, people are referencing CSP standard as one of the arguments how implementation should behave. Now with standard has this removed, they cannot reference it anymore. Even worse, the other side can now say: hey, text was even removed from the standard, what does this tell you? Should Mozilla block or not block user scripts?

@DavidBruant

This comment has been minimized.

DavidBruant replied Feb 22, 2014

Specs don't allow or forbid, they codify an agreement among browsers.

But isn't an agreement for Blink and Mozilla at least that they will not block extensions and bookmarklets? Let's then codify that.

The problem is that this paragraph deals with something that is vendor-specific. If a browser doesn't want to comply to this paragraph, who has leverage to make the browser comply? Certainly not the W3C, not any law, not even interoperability (since this isn't part of how an HTML/CSS/JS document is processed). The best answer is market pressure. And to some extent, that's what guides Blink and Moz decision. They know their decision is what is best for users, so they know they at least preserve their market share doing so.

For example, in the discussion on Mozilla ticket for CSP affecting bookmarklets, people are referencing CSP standard as one of the arguments how implementation should behave. Now with standard has this removed, they cannot reference it anymore. Even worse, the other side can now say: hey, text was even removed from the standard, what does this tell you? Should Mozilla block or not block user scripts?

I think Mozilla position has been clearly stated and they want to support bookmarklets (but face a tough engineering challenge which is the reason it's not happening in the short term). I haven't seen too much debate about it, have you?

Mozilla didn't wait for a standard to make Firefox customizable by addons. There is actually no spec for that. They know to make the right decision even when there is no spec and room for choice ;-)

@mitar

This comment has been minimized.

mitar replied Feb 22, 2014

The problem is that this paragraph deals with something that is vendor-specific. If a browser doesn't want to comply to this paragraph, who has leverage to make the browser comply?

Nobody can force compliance, but we can point to them and say that they are not standard compliant and this is why my add-on/extension/bookmarklet does not work. The language in original note was SHOULD anyway so there was already some space for vendors to not implement it.

@mitar

This comment has been minimized.

mitar replied Feb 22, 2014

I think Mozilla position has been clearly stated and they want to support bookmarklets (but face a tough engineering challenge which is the reason it's not happening in the short term). I haven't seen too much debate about it, have you?

Yes. I linked to the ticket. See here:

So see the way of logic here? Already just because W3C was considering removing it, people used this as an argument not to implement a fix. And now W3C removed it. This will make life even easier for them.

@npdoty

This comment has been minimized.

Collaborator

npdoty replied Feb 22, 2014

Hi @Arty-chan

I'll post this to the list as well, but I would like to point out that the process to post a simple message like this to the list is essentially a big huge wall (find the list address, find how to sign up somewhere else, sign up, confirm the sign up, then when you think you can post to the list, discover you need to permit archiving before the first lines you wanted to say can even make it to the list). The process alone might deter people from voicing their opinion on the mailing list rather than as a comment here (where the process is getting a github account, then posting a message). While I understand that to have a discussion, you might need a centralized point, people should not be deterred from voicing their support or opinions either way in as many modes of communication as possible and then those on the mailing list being informed of what "others" think.

For what it's worth, you don't need to subscribe to a public W3C mailing list in order to send comments to it (so you can skip the find-how-sign-up, sign-up, confirm sign-up steps if you don't plan to participate in more than a particular issue). Every draft we publish is required to include at the top (in "Status of This Document") a link to the mailing list where you can send comments (as a mailto: link, so it should be one click) in order to make it fairly easy to find. I'm not sure there's anything we can do to avoid the permission-to-archive step without surprising some people that their messages are now permanently publicly available.

I think W3C groups in general would be open to finding ways to make it easier to comment, or to accept comments via different channels. As you've seen, you can often get the attention of the editors and some particularly interested participants via comments or issues on Github (and I suspect that more W3C spec work will be moving to Github over time), but messages to the group mailing list are the only guarantee of getting a message expressly to everyone in the Working Group. We could perhaps introduce an informal agreement for drafts published via Github that the editors/chairs will triage comments and issues raised via Github and make sure points are summarized for the mailing list.

@Arty-chan

This comment has been minimized.

Arty-chan replied Feb 23, 2014

@npdoty Thanks. I suppose it just isn't very clear that the email only about the one issue option is available when the user is approaching from github. I admit that I'm rather ignorant of the ways in how w3c communicate, so it's good to know that option is out there. Certainly, if documents are being hosted on github, users with accounts will take advantage of the commenting system, so having a process of bringing discussion points brought up on github into the appropriate mailing list in some way is worth looking at.

@Pomax

This comment has been minimized.

Pomax replied Feb 23, 2014

@DavidBruant as a small correection, w3c specs are actually used as basis for legal policies, whether that's the w3c's intent or not; people who have no idea how the internet works will use the w3c specs to lay down the law in certain cases. Want to run a university website in, say, Ontario, Canada? Now you need to be WCAG compliant, which means implementing several w3c specs to the letter, even if doing so doesn't guarantee a website actually does what the politicians thought WCAG would do. So it might be just a spec, but it's a w3c spec. w3c specs hold tremendous power =)

Baking in user rights and freedoms is an exceptionally good idea, and a change where that was the case but the freedom got removed should always be analysed with skepticism.

As for the "you heard about this" bit: I did indeed, but the fact that I did has nothing to do with how visible this working group is =( I found this issue because someone who overheard me complain about how CORS, mixed-content blocking, and XHR policies have turned the internet from an open landscape to a progressive more and more dictatorially locked down landscape, without a way for users to undo those things in their browser "for their own good". They sent me a pastebin of mitar's reaction, and that got me incredulous enough to seek out the commit and the mailing list. The fact that I even heard about it mostly an accident.

@mitar

This comment has been minimized.

mitar replied Feb 23, 2014

@Pomax: Then please join the mailing list and reply to my post about this with all the arguments you are writing here. This would really help!

@Pomax

This comment has been minimized.

Pomax replied Feb 24, 2014

already did. You can't reply to a post that was posted before you joined, but I wrote a new post with the same subject.

@eossipov

This comment has been minimized.

eossipov replied Apr 26, 2014

Wow, maybe I could just interject a little something here,

I feel this really needs to be taken a step/degree further. This goes right to the very heart of pretty much all the issues on the internet involving interaction and intelligence gathering.
Corps or govs, it's all the same to me, they gather my every move.
When I delete a Pup (potentially unwanted program), removed every trace of it I can find, unload the dll, reboot the computer, and the damn thing re-installs itself through an API I've neither requested access for or a key for, I think some of the corps need to be reigned in.

NO ONE should have the right to come into my home, install anything on equipment, wall, tv, whatever without Specifically stating exactly what they are putting on my machine AND providing uninstall scripts which will return my machine back to it's original state. They should be required to get my specific permission and tell me exactly (by a list ) which files they may or may not be modifying. I feel very strongly about this. If we give them an inch they take your fucking arm, and then tell ya to go buy a new one. If we don't draw the line, If we don't stand together and say No... No More. It's only going to get much worse in the future. imho. Let me just ask you this much, Have you or have you not seen this get worse exponentially in the last 12-18mos.?

@Pomax

This comment has been minimized.

Pomax replied Apr 26, 2014

After extensive discussion about this on the mailing list, this PR got ammended to https://github.com/w3c/webappsec/blob/master/specs/content-security-policy/csp-specification.dev.html#L931

@DestyNova

This comment has been minimized.

DestyNova replied Jan 12, 2015

I'm a bit late to the party, but just wanted to add that the apparent lack of process by which this change was pushed through is very concerning. It seems to have been done mostly at the behest of one vocal party (Cox), despite most other participants in the discussion disagreeing? Given that the change can only lead to browsers implementing changes that diminish the user's freedom to control their browser, this is a disappointment. At least the PR has been amended since, although I agree that the "compromise wording" is weak. The original was IMO better as it more explicitly called for protection of the user's freedoms.

Please sign in to comment.