Hacker News Reader

Comment by untog | Hacker News Reader

I agree and disagree. From the perspective of anyone making a web site it's very easy to secure yourself against JS running on a third party domain: don't load any.

That sites do load these scripts says a lot more about their priorities and the state of online advertising than it does about browsers themselves.

View on HN

> From the perspective of anyone making a web site it's very easy to secure yourself against JS running on a third party domain: don't load any.

No that's only half the solution, the other (much harder) half is to ensure you have no XSS. The GP's point was if they hadn't allowed cross-origin scripting it would have had big security benefits.

Set the Content-Security-Policy in the HTTP response.

But the problem is that the server is deciding for the user. If they want to show me sketchy ad content, they can go fetch it and send it to me as part of my request to them. Don't tell me to go get it myself.

If an ad server is malicious, let it be the web server that has to deal with them, not me.

So suppose they go and fetch these malicious ads and forward them to you. Now you get that malware directly from the first party. The malware has all the same-origin access as the first-party application, and you can't trivially block it with things like uMatrix.

That's what I call server deciding for the user. And now you're in real trouble with security.

Yes, but then the malware can also compromise the server, since it now has js access to all the users and can Masquerade as them when they see the ad - even as admins. Keys to the kingdom. This is a feature, not a bug - it means the user and the server are now in the same boat, and the server will have some friggin diligence about whose code they run.

Also, means the server has to pay for the damned bandwidth.

That's not how it works, the server wouldn't execute JS that is meant for a browser client, it would just serve it like any other static file.

What you're suggesting will actually hamper security, because scripts served from your domain have less limitations(see https://en.wikipedia.org/wiki/Same-origin_policy , https://en.wikipedia.org/wiki/Content_Security_Policy and other mechanisms)

the implication of same-origin would affect all requests made from the client. you can serve malicious js from the server all day long but it would be restricted to only talking back to that same server.

i dont expect site authors to give 2 shits about security when the alternative is ad revenue. that's assuming they even understand the security/privacy implications of spending 5 seconds to add that one-liner social sharing widget.

75% of web devs wont bother to consider it and the other 24% wont care.

it's the job of browser vendors to provide saftey for the masses. of course the giant conflic of interest here is that most browser vendors get a cut of the ad revenue.

there's a massive need for a payment platform that allows for browsing ad-free but still paying directly for content as-you-go. i think Brave is trying to do this.

cryptocurrency may provide the privacy protections for this type of arrangement.

"We show how third-party web trackers can deanonymize users of cryptocurrencies. We present two distinct but complementary attacks."

- "When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies", https://arxiv.org/abs/1708.04748

Reply on news.ycombinator.com