Hacker News Reader

Comment by cxr | Hacker News Reader

> When the stylesheets are not accessible by document.styleSheets API (e.g. on a third party domain, what!?)

I agree with the !? sentiment. An even bigger WTF, though, is that the server gets to control through CSP which off-site style sheets the user can link against and even whether use of the style attribute is permitted. CSP is one of the worst pieces of Web security infrastructure that modern browsers unwisely agreed to go along with. Incredibly user-hostile and worse, effectively irreversible—there's basically no going back now because browsers don't have the option at this point to say, "Yeah, we're not going to honor this anymore," without putting users at an even greater risk than before CSP ever existed. So not just detestable in the vein of WEI, but an utterly abominable technical work.

View on HN

> An even bigger WTF, though, is that the server gets to control through CSP which off-site style sheets the user can link against and even whether use of the style attribute is permitted.

I don't understand the problem. This is exactly the use case for CSP - allow the server to lock down to a more restricted, and safer subset of the web platform. It plays an important part in providing a failsafe for displaying untrusted/user content on the web (and elsewhere).

I know of one podcast client that uses CSP to safely render HTML podcast notes, blocking the loading of images and any external assets. Pretty neat if you ask me.

Why do you think CSP is user hostile?

There's a difference between user content, which could include injection attacks. And what might be called operator content (operator of the browser in this case, which could also be considered a user), sure I want to be protected against hostile injection, but I should be able to inject code into my own browser without any issue.

Would a userscript running in Greasemonkey/Violentmonkey help in this case?

I inject code into every site I visit.

I think browsers should make a distinction between server-provided scripts and local-user-initiated scripts. From what I can tell, CSP should only apply to server-provided scripts. They are a way for the server to restrict the capabilities of its own scripts. “I only require resources from these domains. If you hear otherwise, it wasn’t from me.”

For local-user-initiated scripts, this restriction is unnecessary. The server has limited what scripts it itself can run, but that shouldn’t impact what scripts the user can run.

It's rather an origin check instead of CSP I believe [1], and I can imagine a lot of possible attacks if it's open wide...

[1] https://drafts.csswg.org/cssom/#concept-css-style-sheet-orig...

To be clear: I wasn't saying that restricted cross-origin access to style rules was a consequence of CSP; I was likening the effects of document.styleSheets restrictions to the effects of CSP restrictions. (It happens that CSP has other, worse effects.)

> CSP is one of the worst pieces of Web security infrastructure

I disagree. Like many things, it's a trade-off, in this case between configurability and extensibility for those who know what they're doing and security for those who don't. In the grand scheme of things, it seems pretty reasonable.

That doesn't make sense. CSP is opt-in.

> CSP is one of the worst pieces of Web security infrastructure that modern browsers unwisely agreed to go along with

This got me interested - care to provide a reasoning behind it? I'd love to read more on the subject and better understand it.

Thanks.

Unfortunately, someone would have to write it first. (Why not you?)

My reasoning is in the next sentence: «Incredibly user-hostile and worse, effectively irreversible—there's basically no going back now because browsers don't have the option at this point to say, "Yeah, we're not going to honor this anymore," without putting users at an even greater risk than before CSP ever existed.»

I still don't understand WHY is it "Incredibly user-hostile". Will do my own research anyway.

Refer to the place in the linked article where the part I quoted appears in a section called "Limitations"—the bookmarklet is stopped in its tracks when it encounters style sheets that are loaded from off-site (but that are still loaded nonetheless and have an effect on the current page). Considering that the user is the one who invokes bookmarklets and has their own personal accessibility reasons for doing so, that's an unwelcome limitation.

There's a similar effect with CSP: server operators and content authors can use CSP to prevent the use of bookmarklets that ordinarily work by overriding the author's style rules through $element$.style (i.e. the style attribute), inserting style elements with the user's own CSS, or loading/linking against off-site style sheets.