3 ms·
JS as an attack vector can be effectively mitigated by denying access to high-precision timers (and a few features that can be used to construct high-precision
by Tuna-Fish 9y ago
JS as an attack vector can be effectively mitigated by denying access to high-precision timers (and a few features that can be used to construct high-precision timers). At least Chrome and Firefox are doing this, so just make sure that you are keeping your browser up to date.
If you feel paranoid, you might also want to disable JS by default and only enable by whitelist on any machines that hold particularly sensitive or valuable data.
- rolux 9y agoKeeping JavaScript from constructing high-precision timers is going to be a cat and mouse game. See the "Fantastic Timers" paper. Link to HN discussion: https://news.ycombinator.com/item?id=16080235 https://news.ycombinator.com/item?id=16080235
- Xylakant 9y agoAlso: if you don’t have high precision timers, you probably could also go and increase the number of guesses to cancel out noise. After all, this is a statistical side channel attack. This will be fun for quite some time.
- Tuna-Fish 9y agoDoing that is harder than usual, because the time before rollback is very limited, reducing the amount of cache lines you can pull into the cache and you can measure a given cache line only once. The attack is already pretty damn slow (1kB/s) in C, if you have to collect a statistically significant sample in JS it might well slow down enough to not really work properly.