Deletion of data is achieved by permanently discarding the encryption key which is stored and managed elsewhere where secure erasure can be guaranteed.

If implemented honestly, this procedure WORKS and cloud storage is secure. Yes the emphasis is on the "implemented honestly" part but do not generalize cloud storage as inherently insecure.

What is so difficult about this?

0. Define 2 blocklists: one for local domains and one for local IP addresses

1. Add a per-origin permission next to the already existing camera, mic, midi, etc... Let's call it LocalNetworkAccess, set it false by default.

2. Add 2 checks in networking stack:

2a. Before DNS resolution check the origins LocalNetworkAccess permission. If false check the URL domain against a domain blocklist, deny the request if matches.

2b. Before the TCP or UDP connect check the the origins LocalNetworkAccess permission. If false check the remote IP address against an IP blocklist, deny the request if matches.

3. If a request was denied, prompt the user to allow or disallow the LocalNetworkAccess permission for the origin, the same way how camera, mic or midi permission is already prompted for.

This is a trivial solution, there is no way this takes more than 2-300 lines of code to implement in any browser engine. Why is it taking years?!

And then of course one can add browser-specific config options to customize the blocklists, but figure that out only after the imminent vulnerability has been fixed.