Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardening the Firefox Front End with Content Security Policies

attackanddefense.dev

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Hardening the Firefox Front End with Content Security Policies

#41

Post by Perseids »

eru wrote: post #36
chrismorgan wrote: post #18

Earlier quoted context omitted.

> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…

I think that's a limitation of our implementations. In principle, it's just bytes that we shoving down the pipe to the browser, so it shouldn't matter for performance whether those bytes are 'inline' or in 'external resources'. In principle, you could imagine the server packing all the external resources that the browser will definitely ask for together, and just sending them together with the original website. But I…

This feature actually existed (see https://en.wikipedia.org/wiki/HTTP/2_Server_Push ) but was deemed a failure unfortunately (see https://developer.chrome.com/blog/removing-push )

Re: Hardening the Firefox Front End with Content Security Policies

#42

Post by bgirard »

chrismorgan wrote: post #18
theandrewbailey wrote: post #5

CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.

> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…

> If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it

Do you have data to back this up? What are you basing this statement on?

My intuition agrees with you for the reasons you state but when I tested this in production, my workplace found the breakeven point to be at around 1KB surprisingly. Unfortunately we never shared the experiment and data publicly.

Re: Hardening the Firefox Front End with Content Security Policies

#43

Post by LegionMammal978 »

allan_s wrote: post #21
chrismorgan wrote: post #18

Earlier quoted context omitted.

> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…

note that for inline style/script, as long as you're not using `style=''` or `onclick=''` , you can use `nonce=` to have a hash and to my understanding, newly added inline script will not be tolerated, allowing to have the best of both world

It does seem like CSP nonces do not play well with caching (since they must have a different value on each page load), which would make them a detriment to performance.

Re: Hardening the Firefox Front End with Content Security Policies

#44

Post by bgirard »

theandrewbailey wrote: post #40
chrismorgan wrote: post #18

Earlier quoted context omitted.

> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…

It's called Content Security Policy, not Content Performance Policy. My thoughts: 1. Inlining everything burns bandwidth, even if it's 100KB each. (I hope your cloud hosting bills are small.) External resources can be cached across multiple pageloads. 2. Best practice is to load CSS files as early as possible in the header, and load (and defer) all scripts at the end of the page. The browser can request the CSS befor…

> Source? I'd really like to know how and when slow caches can happen.

I don't have a source I can link to or share. But cache outliers are a real thing. If you aggregate Resource Timing results, you'll find some surprising outliers in that dataset where transferSize=0 (aka cached load on Chrome). You'll have users with a slow/contended disk where as they might have a fast link, but you'll also have the reverse where you'll have users with a fast cache and a slow network link (high latency, low bandwidth or both).

There's no universal answer here and I feel like the above poster tries to oversimplify a complex problem into one-size-fits-all answers. You'll have different users making up your distribution and you'll have to decide how you weight optimizations. This could very much depend on your product, the expectations and if your user are power users running a complex SaaS frontend, or a news site supporting a range of mobile devices.

A few years ago I traced and notice that Chrome has a pseudo O(n^2) behavior when pulling a bunch of sequential resources from its cache. I reported it but I'm not sure if it got fixed.

Re: Hardening the Firefox Front End with Content Security Policies

#45

Post by [deleted] »

bgirard wrote: post #42
chrismorgan wrote: post #18

Earlier quoted context omitted.

> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…

> If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it Do you have data to back this up? What are you basing this statement on? My intuition agrees with you for the reasons you state but when I tested this in production, my workplace found the breakeven point to be at around 1KB surprisingly. Un…

[deleted]

Re: Hardening the Firefox Front End with Content Security Policies

#46

Post by theandrewbailey »

bgirard wrote: post #44
theandrewbailey wrote: post #40

Earlier quoted context omitted.

It's called Content Security Policy, not Content Performance Policy. My thoughts: 1. Inlining everything burns bandwidth, even if it's 100KB each. (I hope your cloud hosting bills are small.) External resources can be cached across multiple pageloads. 2. Best practice is to load CSS files as early as possible in the header, and load (and defer) all scripts at the end of the page. The browser can request the CSS befor…

> Source? I'd really like to know how and when slow caches can happen. I don't have a source I can link to or share. But cache outliers are a real thing. If you aggregate Resource Timing results, you'll find some surprising outliers in that dataset where transferSize=0 (aka cached load on Chrome). You'll have users with a slow/contended disk where as they might have a fast link, but you'll also have the reverse where…

> If you aggregate Resource Timing results, you'll find some surprising outliers in that dataset where transferSize=0 (aka cached load on Chrome).

I've been digging into the JS resource timing API. You've suggested a fascinating avenue for me to explore!

Re: Hardening the Firefox Front End with Content Security Policies

#47

Post by SahAssar »

LegionMammal978 wrote: post #43
allan_s wrote: post #21

Earlier quoted context omitted.

note that for inline style/script, as long as you're not using `style=''` or `onclick=''` , you can use `nonce=` to have a hash and to my understanding, newly added inline script will not be tolerated, allowing to have the best of both world

It does seem like CSP nonces do not play well with caching (since they must have a different value on each page load), which would make them a detriment to performance.

You can also include a hash of the contents in the CSP, which plays well with caching.

Re: Hardening the Firefox Front End with Content Security Policies

#48

Post by eru »

erikerikson wrote: post #37
eru wrote: post #36

Earlier quoted context omitted.

I think that's a limitation of our implementations. In principle, it's just bytes that we shoving down the pipe to the browser, so it shouldn't matter for performance whether those bytes are 'inline' or in 'external resources'. In principle, you could imagine the server packing all the external resources that the browser will definitely ask for together, and just sending them together with the original website. But I…

In principle there's no difference between principle and practice.

Simple models are still useful: understanding exactly how and why they fail is instructive. There's a reason spherical cows in a vacuum come up again and again.

Re: Hardening the Firefox Front End with Content Security Policies

#49

Post by eru »

Perseids wrote: post #41
eru wrote: post #36

Earlier quoted context omitted.

I think that's a limitation of our implementations. In principle, it's just bytes that we shoving down the pipe to the browser, so it shouldn't matter for performance whether those bytes are 'inline' or in 'external resources'. In principle, you could imagine the server packing all the external resources that the browser will definitely ask for together, and just sending them together with the original website. But I…

This feature actually existed (see https://en.wikipedia.org/wiki/HTTP/2_Server_Push ) but was deemed a failure unfortunately (see https://developer.chrome.com/blog/removing-push )

Thanks for the links! Yes, my comment was based of a vague recollection of this kind of thing.

I'll read up on the '103 early hints' and 'preload' and 'preconnect' which might be close in enough practice.

Re: Hardening the Firefox Front End with Content Security Policies

#50

Post by [deleted] »

bgirard wrote: post #42
chrismorgan wrote: post #18

Earlier quoted context omitted.

> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…

> If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it Do you have data to back this up? What are you basing this statement on? My intuition agrees with you for the reasons you state but when I tested this in production, my workplace found the breakeven point to be at around 1KB surprisingly. Un…

[deleted]
Post reply on HN