I disagree. So does the TCSEC ("Orange Book"), which argues that covert channels may be effectively impossible to eliminate but that they should still be reduced, then lays out guidelines on how far they should be reduced for secure computing platforms. Specifically:
In any multilevel computer system there are a number of
relatively low-bandwidth covert channels whose existence is
deeply ingrained in the system design. Faced with the large
potential cost of reducing the bandwidths of such covert
channels, it is felt that those with maximum bandwidths of
less than one (1) bit per second are acceptable in most
application environments. [...] Therefore, a Trusted
Computing Base should provide, wherever possible, the
capability to audit the use of covert channel mechanisms
with bandwidths that may exceed a rate of one (1) bit in ten
(10) seconds.
I'll admit that this definition is at least a couple decades out of date, but at the same time... the standard for the US's intelligence agencies' secure computing platforms was to not even care about hypothetical covert channels slower than .1 bps. In addition, such channels were required to be auditable, not eliminated; I'm certain that less-secure applications were completely fine shipping with demonstrated covert channels in the bits-per-second range. And that's for systems that deal with things like the IDs of HUMINT assets or technical specifications for weapons systems; here on HN we're talking about browser fingerprints and location data.
All of this is to say: If I could limit covert channels from webpages or mobile phone apps to 10 bps I'd do it in a heartbeat. Perfect is the enemy of good enough.
All of this is to say: If I could limit covert channels from webpages or mobile phone apps to 10 bps I'd do it in a heartbeat. Perfect is the enemy of good enough.