Hacker News Reader

Comment by kevincox | Hacker News Reader

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. 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.

View on HN

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.

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.

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

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.

You could do it today with TLS_RSA_WITH_NULL_SHA if null ciphers were still supported.

What's the downside of HTTPS that you'd want to remove the encryption feature?

I could see some forms of advertising or spam (or scams) preferring this.

Captive portal detection is endlessly buggy.

That'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.

I 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.

Yep 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.

Reply on news.ycombinator.com