The actual paper (PDF) this is based on gives much better information than the article. From that we get some really key information:
To allow FROST to measure SSD contention, the victim must perform activities that result in storage accesses to the same disk as the file used for contention measurement
This can’t ready your SSD. It can only listen in on the conversation between your CPU and SSD when something else reads it or writes to it. The whole FROST approach has a number of clever tricks to generate reads from open applications though. Further, it requires the attacker’s code to be running in an active browser session.
Also, If you have two SSDs, and your browser is on one, this FROST approach can’t see anything written to or read from on the other SSD.
Lastly, there’s a mention in the paper about hardware based SSD encryption being vulnerable, there’s no mention of Software Whole Disk Encryption. Given how the researchers are using the SSD timing exploit, I would guess that a software (not hardware) whole disk encryption might be immune to this attack because the patterns of timings would be different with encrypted data being written to the SSD (instead of the data being encrypted by the SSD when written.
Sounds like a bunch of timing attacks could be rendered useless if access to an accurate timer required special permission. And without the permission, it either limited the resolution or added random jitter to any timer APIs.
The actual paper (PDF) this is based on gives much better information than the article. From that we get some really key information:
This can’t ready your SSD. It can only listen in on the conversation between your CPU and SSD when something else reads it or writes to it. The whole FROST approach has a number of clever tricks to generate reads from open applications though. Further, it requires the attacker’s code to be running in an active browser session.
Also, If you have two SSDs, and your browser is on one, this FROST approach can’t see anything written to or read from on the other SSD.
Lastly, there’s a mention in the paper about hardware based SSD encryption being vulnerable, there’s no mention of Software Whole Disk Encryption. Given how the researchers are using the SSD timing exploit, I would guess that a software (not hardware) whole disk encryption might be immune to this attack because the patterns of timings would be different with encrypted data being written to the SSD (instead of the data being encrypted by the SSD when written.
The paper also mentions that it also takes downloading a 1GB OFPS file and JS in use.
This isn’t so much “researchers can track you” so much as “it’s theocratically possible with stock laptops and browsers, within limitations.”
Sounds like a bunch of timing attacks could be rendered useless if access to an accurate timer required special permission. And without the permission, it either limited the resolution or added random jitter to any timer APIs.