Comment by TekMol
6 months ago
The worker could still send the data back to the page via side-channels.
For example by using up resources like the cpu, the gpu or ram in timed intervalls. The page would then probe for the performance fluctuations of these resources and decode the data from the pattern of the fluctuations.
IMO that shouldn't be part of the threat model. I could run an ad right now that consumes CPU in timed intervals and estimates CPU usage using a microbenchmark to communicate with js on other pages. This sort of fingerprinting and bits/minute side-channels are impractical to block. You'd have to give each origin its own CPU cores, cache partitions, etc
Sigh. You don't prune threats you can't control from a threat model, you document them so that the consumers and maintainers of the target of assessment can intelligently reason about the threats as the product evolves.
If a page can already deduce performance fluctuations all on its own, then you don't need a special access-limited performance API, do you? Just have the page do whatever you're imagining could be done to extract this side-channel info on the performance of the host — and then leak the results of that measurement over the network directly.
(I imagine, if such measurements done by pages are at-all distinguishable from noise, that they are already being exfiltrated by any number of JS user-fingerprinting scripts.)
A page can deduce performance fluctuations. It just needs to do the same calculation multiple times and measure the times.
The issue with the API is that it provides specifics about the CPU like "Apple M2 Max". If you give this info to a worker, the worker can encode it into a side-channel and send it to the page.
I imagine you could "solve" this (for a painful and pointless value of "solve") by 1. only allowing the Service Worker to do constant-time versions of operations (like the constant-time primitives that cryptographic code uses), and 2. not allowing this special Service Worker the ability to ever... execute a loop.
But at that point, you've gone so far to neutering the page-controlled Service Worker, that having a page-controlled Service Worker would be a bit pointless. If the Service Worker can only do exactly one WebGL API call for each metric timeseries datapoint it receives, then the particular call it's going to be making is something you could predict perfectly in advance given the datapoint. So at that point, why have the page specify it? Just let the browser figure out how to render the chart.
So I revised the design to do exactly that: https://news.ycombinator.com/item?id=40929284