Hacker News Reader

Comment by pattyj | Hacker News Reader

i've wondered about this myself for a while

maybe an html meta tag that blocks all XMLHTTPRequests until the user consents. i don't think it would even matter if it was browser-specific

View on HN

And WebSockets and WebRTC and form submissions and so on. It'd be a whole policy for many things like gp suggests not just blocking one function.

Of course that being said the policy would basically have to be "disable network" at a trigger point not just uploads as you can just as easily leak large amounts of data via triggering GETs by making img placeholders come into view or other equally tricky things that can't be distinguished from "app is just still loading".

Even just basic hyperlinking would have to be heavily restricted.

For example...

1. Cross origin hyperlinks would have to be completely disabled 2. Same-origin URLs would need all url information (query params, path, etc) to remain completely client-side. The only thing transmitted to the server would be the base domain.

It's interesting to think about, at least.

Post restriction there is no such thing as allowing network requests (same origin or cross origin) without opening a side channel which can work around said restriction (e.g. timing). However pre restricted mode there is no reason to restrict anything be it same origin or cross origin.

Pre-restriction would have to disallow running javascript in that case. Otherwise an app could save data to localstorage, refresh the page programmatically (or wait for the user), and then transmit.

Or rather have the browser treat the no-network session period with private window logic where the session is deleted if the no-network browsing session ends or dies (e.g. incognito puts a virtual session data container in RAM). That would even allow the app data (prior to triggering the mode) to stay cached without risking side channels with future resource loads.

The whole premise was to return to the pre-web 2.0 days but have the option for a user to enable modern web app capabilities. Which your idea would be a step towards.

Please remind me, what extra data can be sent via img URL besides the data in the original html request?

I think DoNotTrack shows how well webdevs will respect flag/switch/honor system type of ideas. They won't.

I've thought that a great grassroots response to GDPR and superfluous cookie banners is for websites to start respecting DNT on their own.

Alanis says wouldn't that be ironic.

Unfortunately, we've learned that the hard way.

Surely, though, a blocked network request never reaches the server and so it can't be used a 'flag'?

Reply on news.ycombinator.com