That’s not what I’m proposing at all. I merely propose that websites only run their own code.
-
-
Replying to @johnwilander @arturjanc
The web has that feature - it's script-src self (+whitelists for the site/etld+1). It's opt in, and the adoption rate is poor for many reasons. Mandating it seems like a very difficult task, as very few authors would want to have such limitations.
1 reply 0 retweets 2 likes -
Replying to @kkotowicz @arturjanc
That is the tragedy of the commons. Developers want the freedom but not the consequences. Endusers are deceived and pay the price. We can do something about it.
2 replies 0 retweets 1 like -
Replying to @johnwilander @arturjanc
XSS, for the most part, is not caused by distributed code loading in your app. It lurks in a total codebase complexity of modern apps, and a lack of safe defaults. Changing domain names does not solve XSS.
3 replies 3 retweets 6 likes -
Replying to @kkotowicz @arturjanc
I believe you’re talking about bugs. I’m talking about what scripts get executed. Only files and only from your domain or from one chosen CDN with your own eTLD+1 scope and checked through SRI. Any other script will not be executed.
1 reply 0 retweets 0 likes -
Yes, koto started the thread talking about XSS which is a class of bugs. You're talking about intentional 3rd party scripts. That's not XSS. Unlikely to go away unless we find a non-advertising model for the web.
2 replies 0 retweets 5 likes -
I think it’s XSS if you don’t have SRI, because any XSS, compromise, or ill will from that server and you’re running arbitrary code on your pages. Cross-Site Scripting – it’s in the name.
3 replies 0 retweets 0 likes -
Evil 3rd party scripts are like vampires: they can't come in your house unless you invite them. XSS attacks are monsters that break in. Names matter because the defenses are different
1 reply 0 retweets 3 likes -
Agreed, the attacks differ. But the consequences are the same – malicious scripts running on your site, and the defense I argue for (file-only scripts, SRI enforced for 3rd-party) works for both.
2 replies 0 retweets 0 likes -
Sadly, file-only scripts don't help security in the general case because of all the issues developers have with setting safe script-src whitelists: JSONP endpoints, libraries with gadgets (e.g. Angular), responses with user-controllable prefixes, or file uploads.
1 reply 0 retweets 0 likes
SRI for external scripts is also a useful concept, but often not adoptable because many services change the contents of their scripts depending on user configuration and other factors. If a static, SRI-locked script did the job you could just host it same-origin instead.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.