3 ms·
I've long wondered if there was a place for a httpv mode. Where traffic is signed but not encrypted. This would allow local caching or torrent-like distributed
by kevincox 3y ago
I've long wondered if there was a place for a httpv mode. Where traffic is signed but not encrypted. This would allow local caching or torrent-like distributed fetching but not modification.
The obvious downside is that the page contents are not private.
Chrome implemented something sort of like this with https://developer.chrome.com/blog/signed-exchanges https://developer.chrome.com/blog/signed-exchanges. However this is very limited. It requires the linking site to cooperate. For example Google Search can link to a signed exchange rather than the original site. But this just moves traffic from the site's CDN to Google's. It also packages full bundles so shared resources need to be duplicated. Also any navigation inside that site will go to the origin and can't be cached.
Overall it seems like it probably isn't worth it. But I find it an interesting idea.
- Jerrrry 3y agoThis 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.
- pkage 3y agoI 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.
- Jerrrry 3y agoThat'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
- franga2000 3y agoI 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.
- bcye 3y agoWhat's the downside of HTTPS that you'd want to remove the encryption feature?
- boneitis 3y agoI could see some forms of advertising or spam (or scams) preferring this.
- droopybuns 3y agoCaptive portal detection is endlessly buggy.
- rezonant 3y agoThat's explicitly why captive portal detection does not use HTTPS. If your OS of choice fails to detect captive portal (or doesn't implement detection), and you have the ability to visit a website, you can visit example.com to get into the captive portal. The really annoying part is when a device (cough, Switch at launch) doesn't have portal detection nor a web browser, making it useless on hotel wifi.
- netsharc 3y agoI guess one could bring a laptop, spoof the Switch's WiFi MAC on the laptop and use it to login through that portal, and then disconnecting, and connect the "authorized" Switch. And make sure the Switch doesn't have "randomize MAC" like on Android/iOS. But that's a huge workaround for many.
- rezonant 3y agoYep I've done it. What a pain. Thankfully now the Switch does have captive portal detect and a little purpose built web view for agreeing to the terms.
- kevin_thibedeau 3y agoYou could do it today with TLS_RSA_WITH_NULL_SHA if null ciphers were still supported.