News for hackers. Stuff that matters.
Re:Hotel WiFi JavaScript Injection (2012) by Jerrrry on Friday April 26, 2024 @12:42PM (#40171458)
This is awesome.

Propose an RFC - seriously.

This simplifies, democratizes, and makes transparent the "internal resource sharing/caching" that some browsers can do, like when needing to load the latest jQuery for the 15th time in the last minute, even across domains.

Also would be perfect for captive portals, or other static LAN content.

Re:Hotel WiFi JavaScript Injection (2012) by pkage on Friday April 26, 2024 @02:17PM (#40172464)
I think the problem comes down to fingerprinting. For example, resources used to be cached in the browser regardless of site exactly as you described, but then ad companies figured out you can track a user's browsing history by timing the cache accesses to see if a user had loaded a bundle from another site. To remove that vector, browsers split up caches per domain.
Re:Hotel WiFi JavaScript Injection (2012) by Jerrrry on Friday April 26, 2024 @03:26PM (#40173058)
That's a vector for literally all assets so adding a random delay to every layer up to the last Paint() is the only real counter.

It can be mitigated by adding a property to scripts to allow/default/deny shared domain resource caching, and the ecosystem can benefit from jquery/etc from being hot but still maintain opt-in default/backwards-compat status.

that, combined with the already established HTML <script> integrity Attribute and you are gravy

Re:Hotel WiFi JavaScript Injection (2012) by franga2000 on Friday April 26, 2024 @02:20PM (#40172505)
I believe one of the big reasons why things aren't cached cross-domain is the possibility of fingerprinting by looking at which requests are cached. It's also a lot less beneficial in today's (one could say unfortunate) world of JS and CSS bundling/compilation/whatever.