I think something like that might be feasible in the future with things like web bundles[1] and content security policy[2]. In theory you could have a site loaded as a bundle and a CSP that blocks everything not loaded through the bundle, effectively cutting off all network access.

You'd probably also need some sort of Feature-Policy[3] that prohibits access to any form of persistent storage so sites can't just save data until the next non-CSP-protected page load and transmit it then.

[1]: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...

[2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

[3]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Fe...

This a great idea but it would be difficult to implement. Sure, it would be easy to catch (and block) HTTP requests other than OPTIONS and GET.

But even a GET request can be used to send data. Just pack the data you want to send in the query string and voila.

Just some JS call like "startStatic()". At that point, all network activity is shut down for good, and the page gets a badge.

So don’t allow GET with query params. You want the static moniker? It has to be static. No server interaction after load, and no sending any data during load.

You can still hide the data in "folders". /foo/bar/baz/buz can be totally dynamic on the server.

How about after load, that tab automatically goes completely offline. Users can manually do this in Chrome on a tab by tab basis by using developer console and setting Throttling to "Offline"

That sounds more promising. The site might be able to store data and then send it the next time the page is loaded. I think at the end of the day, a malicious dev could probably find a workaround to most implementations. Might just be better to vet out sites and use reputation to state they are truly offline.

I hear what you're saying, but I also believe this to be a solvable problem

Note that the "offline" mode in devtools doesn't kill any websocket connections. It may have other holes i'm not aware of also.

Or in the subdomain, using "DNS exfiltration": https://twitter.com/rsobers/status/1293539543115862016

That's an interesting exploit, thanks for sharing.

I wonder if this could be a browser extension

That would me amazing

What if it didn't send anything to the server. Today. But stored it in local storage. And sends it next week when you come back.

Don't allow that. When a site registers as "local", which gives it the "local" badge, do not allow the site to switch back to non-local.

Perhaps the site could be allowed to update itself. But this update function should not have access to any local/client state.