5 ms·

I guess the lesson to learn here is that you shouldn't rely on externally hosted assets. Just host it yourself, its not that hard. If you're concerned about the

• lixtra 7y ago
  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.
  • scrollaway 7y ago
    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.
    • captncraig 7y ago
      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.
      • johannes1234321 7y ago
        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.
  • dna_polymerase 7y ago
    > 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.
    • Camillo 7y ago
      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. /s
      • dna_polymerase 7y ago
        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?
      • buckminster 7y ago
        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.
  • jefftk 7y ago
    > 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.
    • jefftk 7y ago
      Sorry, checking, FF and Chrome don't do it yet, but they will soon: https://www.chromestatus.com/feature/5730772021411840 https://www.chromestatus.com/feature/5730772021411840 , https://bugzilla.mozilla.org/show_bug.cgi?id=1536058 https://bugzilla.mozilla.org/show_bug.cgi?id=1536058
      • lixtra 7y ago
        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.
        • jefftk 7y ago
          A "share cache if hashes match" approach was considered with https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity 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-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre... , https://github.com/w3c/webappsec-subresource-integrity/issues/22 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.
  • sneak 7y ago
    What you are describing is called IPFS.
    • lixtra 7y ago
      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 https://en.m.wikipedia.org/wiki/Magnet_URI_scheme
  • cjslep 7y ago
    This is content-addessing, or a content-addressable network. There's a lot of work being done in this space.
  • Avamander 7y ago
    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.
  • e12e 7y ago
    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)).
• tasogare 7y ago
  With the added benefit of working on the local network without access to the internet (I cite that because I encounter this requirement recently at work).