===
> The host permission in current extension framework does not distinguish between accessing all the data and connecting to any remote server.
>
> The key issue I see is that it also allows uBO to connect to any remote server. I think it would help a lot to have a _separate_ permission for remote server access, since this is the key privacy issue here: user data leaving the browser to be collected by a remote server.
>
> So what about a new permission specifically dedicated to specify where an extension is allowed to connect? Without this permission, an extension wouldn't be allowed to connect to a remote server, i.e. unable to leak user data.
===
As a mental framework, I consider the ability to see the URL of all requests or all the DOM to be a read operation, while extensions making requests to remote server (directly or indirectly) is a write operation (to the wide internet). The latter is where the real privacy concerns are, and this is what should be tackled in some manner. I don't see manifest v3 addressing this[1].
* * *
[1] https://www.eff.org/deeplinks/2019/07/googles-plans-chrome-e...
Web Extensions caused lots of outcry, when it was mostly about making extensions async and better sandboxed.
EME caused similar outcry, when in fact it migrated us away from plugins riddled with security vulnerabilities (hint Flash). Today most DRM crap runs in a sandbox -- DRM still sucks, but it doesn't compromise my browser :)
I'm suspect, extensions will be sandboxed further, but this will take time.
Elements filtered by uBlock origin are typically not even loaded over the net. That means that an outside observer can see what uBlock origin does.
However, you could envision a variant of uBlock origin that still loads everything, and only does cosmetic blocking.
But eg an extensions that is supposed to protect your privacy will have to have an influence on your browser's network output.
Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests.
If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key.
Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy.
[1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)
In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour.
That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model.
> e.g. IP address or browser user agent string)
Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number).
Security is hard... ~sigh~
[1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua...
https://blogs.akamai.com/2017/09/introduction-to-dns-data-ex...
DNS tunneling is a well-known exfiltration technique which can place data inside of DNS request packets. There are several methods of placing the data in the request packet. In such a case the DNS query might appear as a benign request for IBM.COM's ip address.
The only side channel I can then think of is using page rewriting or timing to communicate when the user browses to a page controlled by the extension owner. This would be something that there is at least a hope of spotting?