Hacker News Reader

Comment by mike-cardwell | Hacker News Reader

Yeah. It's "secure" as long as none of Filecha, Cloudfare, Google, Facebook, jQuery or Akamai get hacked, compromised or coerced.

There's no reason he can't host all of these javascript resources on the same domain, substantially reducing the attack surface area.

I know people like to use CDNs and third party hosted analytics software, but can we at least come to the compromise that if you're going to say your app is "secure" or "private", that you at least attempt to host what you can on your own domain...

[edit] I'm probably being unfair. He makes the code available so you can host it yourself. I'm sure most people who install it will leave the CDNs in place though.

View on HN

You're not being unfair at all, IMO. The instance he hosts says secure, yet it includes lots of 3rd party resources, and of course you're still trusting his server every time you run it.

> you're still trusting his server every time you run it.

Is there any way to initiate transfers between two browsers over WebRTC without the use of a server?

Yes, but that's not the point here. The point is getting the code that knows what to do with the WebRTC connection.

Since you asked: https://github.com/cjb/serverless-webrtc/

What would it take to get the w3/html5 folks simply add a src-hash="$algo:$value" to any tag that can load remote resources?

Seems like a low-impact way to significantly boot the usefulness + security of CDN's. If the source page (requested over https, and presumedly not MITM'ed already) declares "I want to load that resource over there, and I expect it to hash to this value", then we get all the benefits of caching + trust that it has not been tampered.

Last time I saw this mentioned someone posted s link to the w3 pointing out that it is in fact being discussed for future implementation.

This exists, subresource integrity: http://www.w3.org/TR/SRI/

Thanks for pointing it out. It is still in development. The reason i was using CDN was because of bandwidth and reusing the cached JS if the user already has that. What will be the best way to tackle this? If I put all those under one CDN then I guess the bandwidth problem will be solved but I wont be able to reuse the JS that user might already have. At the end of the day I still have to trust the third party JS.

The general consensus is that you won't (meaningfully) be able to "reuse the JS that a user might already have" anyway. The idea of well-know-domain.com/well-known-framework-well-known-version-0-1.js being cashed is interesting -- but a) it doesn't appear to work to well in practice (I seem to recall 30% hit rate for the "best case" of jquery-latest on some big CDN) b) It's not that much data anyway.

Lets say you have 500kb of compressed js. If you have 2 million unique visitors, that'll just eat 1TB of bandwidth -- and if you don't screw up your own cache headers -- that'll be that -- it'll be cached.

Reply on news.ycombinator.com