Hacker News new | ask | show | jobs
by zamadatix 1745 days ago
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".

2 comments

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?