Hacker News Reader

Comment by lixtra | Hacker News Reader

There is a downside though: a copy has to be downloaded for each website, so each first website load is slowed down.

What’s missing is a way to tell the browser to use a certain resource (identified by its hash) and a url to download it.

That way the browser could cache the object across websites and download from a source that the requesting website controls.

It could look like this

    hash://sha256/71dc8dd15ea156387fa9efaf380e7f8d39187a549649bec62a39aee3cf4fdc55//https://raw.githubusercontent.com/cdnjs/cdnjs/2c95eae0dc3569f0cb15c8a5f9173220b49156bc/README.md

I also vaguely remember that magnet links were similar.

View on HN

> a copy has to be downloaded for each website, so each first website load is slowed down.

The major browsers (FF, Chrome, Safari) all fragment cache by the domain in the URL bar now, for privacy reasons, so this doesn't apply anymore.

> the browser could cache the object across websites and download from a source that the requesting website controls

You can't do this without reintroducing the same privacy issues that cache fragmentation was introduced to prevent.

Sorry, checking, FF and Chrome don't do it yet, but they will soon: https://www.chromestatus.com/feature/5730772021411840 , https://bugzilla.mozilla.org/show_bug.cgi?id=1536058

Thanks for the cache partition description. This will make projects like cdnjs less beneficial. The proposed hash:// scheme at least would leave it to the attacked site which resources to expose to such an attack.

Performance vs security trade offs seem to be popping up everywhere recently.

A "share cache if hashes match" approach was considered with https://developer.mozilla.org/en-US/docs/Web/Security/Subres... but not included in the initial version. There's been talk (https://hillbrad.github.io/sri-addressable-caching/sri-addre... , https://github.com/w3c/webappsec-subresource-integrity/issue...) about allowing sites to opt in, but then you're opening up a new way of tracking users across sites.

IPFS could provide peer-to-peer CDNs, I'd love to see it, but it needs massive improvement in latency to be a viable competitor.

Immutable cache and subresource integrity get us most of the way there. I don't know if web browsers share those across domains, but I don't think there's a reason not to.

Possibly privacy. If I host a copy of a popular site's Js, I can watch download patterns and have a pretty reliable "has this user logged into site X" detector.

What you could do is the negative "they won't load this file" which could have many reasons (from connection breaking just after the HTML to JS blockers)

And I believe it's a good solution to restrict such a feature to files already marked with a hash on the origin. They would only do that for common libraries found elsewhere as well.

> There is a downside though: a copy has to be downloaded for each website, so each first website load is slowed down.

Just stop loading 100 resources on a single pageload. If a website loads just one css and maybe one js there wouldn't be any performance issues, unless of course those files are several megabytes in size.

If we just keep posting "it's broken for me with JS turned off, it should work without it" on every other Hacker News thread, surely people will be convinced eventually, and everyone will just stop using JavaScript frameworks and libraries and go back to HTML4, with full support for Lynx.

I feel like we're really close now. Come on guys, one last push.

I'm not advocating for no JS or something like that. All I'm asking for is web-devs using less resources. Use all those frameworks, but do you really need 100 requests to show a blog post?

I don't suppose the complaining here was the reason, but I have noticed several major UK sites (in retail and delivery) become more friendly to browsing without javascript recently. So-called progress is not inevitable.

I doubt this could be implemented in a way that avoids fingerprinting browsers (perhaps other than adding support for a new protocol, like ipfs directly in the browser(s)).

This is content-addessing, or a content-addressable network. There's a lot of work being done in this space.

What you are describing is called IPFS.

The mentioned magnet links[1] are closer to what I describe and more than a decade earlier. Neither is supported by default in common browsers without relying on third parties.

[1] https://en.m.wikipedia.org/wiki/Magnet_URI_scheme

Reply on news.ycombinator.com