Most of the surveillance stories we’ve looked at here lately have involved things you can at least see when you walk past them: cameras at the gate, sensors on the shelf, a label adjusting a price as you move through space.
Probably not. AFAIK docker isn’t a virtual machine in the traditional sense that it has its reserved storage other apps on the machine can’t access. And even if it were, it’s the same physical drive.
Now I’m not too versed myself in SSD firmware so maybe the large file size really is like a wide net, or maybe the file size isn’t important - only the fact you’re doing read operations on a small space on the SSD may give enough volatility in the read speed to infer the exact app that decided to spin up at that moment.
The simplest fix that comes to mind is to have multiple drives (e.g. install and data) and put the browser on the data one. Maybe this added complexity can throw off some naive attacks. Also, a HDD “naturally” has some variability in the access time (since it needs to physically locate the sector with its read heads).
So in essence, laptops with a single SSD are by far the most vulnerable.
However, adding sane limits on the vulnerable API mentioned and throttling read/write speeds (ideally with randomization) seems like a fix good even for single-drive laptops.
What’d probably work with Docker is a similar read speed throttling setup.
Spoofing identifying information won’t help much since read time variability is what matters here. It may make it take more info to infer performance rather than having the transparent information, but a good model is bound to infer pretty well after some initial data.
Probably not. AFAIK docker isn’t a virtual machine in the traditional sense that it has its reserved storage other apps on the machine can’t access. And even if it were, it’s the same physical drive.
Now I’m not too versed myself in SSD firmware so maybe the large file size really is like a wide net, or maybe the file size isn’t important - only the fact you’re doing read operations on a small space on the SSD may give enough volatility in the read speed to infer the exact app that decided to spin up at that moment.
The simplest fix that comes to mind is to have multiple drives (e.g. install and data) and put the browser on the data one. Maybe this added complexity can throw off some naive attacks. Also, a HDD “naturally” has some variability in the access time (since it needs to physically locate the sector with its read heads).
So in essence, laptops with a single SSD are by far the most vulnerable.
However, adding sane limits on the vulnerable API mentioned and throttling read/write speeds (ideally with randomization) seems like a fix good even for single-drive laptops.
What’d probably work with Docker is a similar read speed throttling setup.
Spoofing identifying information won’t help much since read time variability is what matters here. It may make it take more info to infer performance rather than having the transparent information, but a good model is bound to infer pretty well after some initial data.