Hacker News Reader

Comment by leeoniya | Hacker News Reader

the biggest security blunder of the web platform is allowing third party domains to inject code into https pages, which completely violates the trust that https is meant to establish.

and it's here to stay, folks! because the entire trillion-dollar ad industry is built upon it, vacuuming up data about users across the internet.

a huge amount of security and privacy issues would vanish overnight simply by requiring same origin.

the fact that my banking backend has third-party metrics scripts injected [without uMatrix/uBlock Origin] is unforgivable.

and of course half the web is broken without allowing 2 or 3 CDNs or cloudflare to track me everywhere i go.

View on HN

Absolutely, let the server go to the advertiser and fetch the ad content to push, don't make the client do it. I'd go far as to say that any content coming from a 3rd party - even images - has caused more trouble than it's worth.

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.

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

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.

> 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.

Reply on news.ycombinator.com