Hacker News new | past | comments | ask | show | jobs | submit login

At least 1st party javascript usually fixes white screen, but sometimes blocking styles does. What I also found interesting is that disabling javascript with CSP can sometimes fix websites too that are hostile in their <noscript> tag and CSP prevented javascript doesn't run <noscript>.

A surprising number of sites use third party cached versions of scripts - and a number still also use static domains... for instance stackoverflow.com uses sstatic.net I assume because all the stack sites refer to the same pool of scripts... this actually used to be a best practice for performant webpages since many browsers would limit the number of parallel resource downloads on a per-domain basis, so yahoo.com could render quicker if it has img3-yahoo.com and img2-yahoo.com and js-yahoo.com - though subdomains may have sufficed for that at that point, I can't quite recall.

I have a keyboard shortcut for a "dangerous" mode that allows 3rd party images, 3rd party styles, but still only 1st party javascript. Works for stackoverflow.com, not that it doesn't show content without any of 3rd party stuff and any scripts. But I get what you are talking about, different, but still technically 1st party domains and separate CDN domains for some websites is the reason I have rules in my extension, it's like whitelisting adblocking.

A possible solution for this would be for the extension blocking third party scripts to have a list of domains that are known to be associated, like stackoverflow.com and sstatic.net, and then consider the latter to be first party for the former, pre-populated for all the major sites.

If the list is domain based then you run into a "Who is paying to maintain the list" problem, and if it's self-registered (i.e. stackoverflow tells you sstatic.net is legit) then who verifies it was actually stackoverflow that told you that - and if you manager to verify that it came from someone within the domain or the registered owner... then how can you verify that sstatic isn't a domain serving malicious scripts and the owner isn't selling out users to the site to make a quick extra buck from some third party ad provider - or that it isn't the former owner who is acting maliciously - or that it isn't the current owner who is trying to undo the former owner who acted maliciously.

I think you could quite sanely track a few sites, maybe the top 200 or 300... after that it'd get unwieldy.

And, for fun, on the other side I believe a few years ago google's in house public hosting of jQuery received a bad push and was serving a tainted package for a while... even the good actors can mess this up.

A peer vetting system might work well (like DNS) but it'd need a lot of careful thought.

Maintaining the list for the most popular sites is not a huge ordeal. You have a bug tracker where people can submit issues, when you get one you take a few minutes to check that the whois matches the main site and the page actually links the script in a way consistent with what we want to approve, and the opposite if you get a report of something having changed the other way. An individual could do it by spending a few hours a month.

For less popular sites, the user can add it manually, or the site operator notices their site is broken for increasingly many users and stops linking scripts from other domains.

> And, for fun, on the other side I believe a few years ago google's in house public hosting of jQuery received a bad push and was serving a tainted package for a while... even the good actors can mess this up.

That's an independent problem. You could have the same thing happen for actual first party scripts.

And in this context if they're really good actors then they fix it as soon as it's discovered, and if they're not then you take them off the approved list.

It can be done and can be pretty nice. I got to around 30 websites myself with just custom CSP policies for each and plenty of ideas what to do next. Like making CSP policies composable, so I can define a rule for say recaptcha and include it for websites that use it and things like that. Javascript walls (cloudflare, sucuri, etc.) is another problem, you wouldn't want to enable javascript just to pass them and you wouldn't want to pass them automatically as it would allow websites to enable javascript. They also may include recaptcha, etc. Still, nothing that can't be solved.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact