We performed timing tests of our own to evaluate the current browser performances. The high level descriptions of some of the attack vectors in the original research [8] will also be used to implement our own versions and use them to test them in the latest
versions of the browsers.
5.6.1
Evaluation of the Browser Rendering Performance
In the original research of the browser timing attacks [8], experiments were conducted that measured the rendering times of a set of 50 link elements with text-shadow applied to them. Various blur-radius values were used in these experiments, and were done in Firefox 21, Internet Explorer 10 and Chrome 27. We decided to do similar experiments to compare the performance of the current browser versions to the old ones. Even con- sidering the hardware system we used to conduct our experiments was computationally more powerful, the durations were dramatically lower. Rendering the links with a blur radius of 40 pixels, which was the heaviest computational load used in the original re- search, results in minimal delay for all the browsers. In Google Chrome duration to render the first frame seems to range from 28 to 38 ms. In Internet Explorer the du- ration ranges from 0.3 to 7 ms. In Firefox, it takes in between 9 and 11 ms to render the first frame. Although, we must note that in Firefox when the console is open while the rendering process is taking place, larger delay values are seen. When the built-in console is used, only a few milliseconds are added to the duration, which usually results in durations around 15 to 23 ms. When a console from an extension is used to analyse the results, such as Firebug (version 1.12.8 in our experiments), the duration goes up to values in between 25 and 42 ms. This additional delay is probably due to the fact that Firefox is not a multiprocess browser. We advise to be careful with the use of consoles and general debugging tools while timing related testing is taking place.
All the browsers seem to behave slightly different during the initial rendering phases (at the very least due to differences in efficiency). In our experiments with rendering a number of links with large blur radius, we noticed that after the first few frames all of them stabilise around about 16 to 17 ms. The results of the experiments in Firefox, Chrome and Internet Explorer are shown in Appendix B.6.1. One of the documents used for testing the refresh rate is also included; this document was used to produce these results.
Based on these results, we will describe the initial refresh rate and the general be- haviour for each browser in the next subsections. We also note that because our initial test results showed the browsers stabilise at 16 to 17 ms per animation frame, which equates to about 60 fps, we decided to also research the effect of the monitor refresh rate on the duration that was aimed for. These tests results can also be found in the appendix and will also be discussed in the following subsections.
Firefox
Another source that we have consulted for helping us make this analysis for Firefox was [146]2, which contains a large discussion about the implementation of the refresh rate in Firefox. Specifically, this bug addressed the fact that the animation frames generated were sometimes too short or long, especially at the start of animation. As can be seen in the results that we have produced, this is still the case. Firefox seems to usually need about four frames to use as its initial rendering phase in our experiments. These frames can extend the duration beyond the 16 to 17 ms that is aimed for3 because all the elements need to be rendered for the first time. The reader should note that the durations could be affected by other modules as well. The network module could spread the additional delays over multiple frames when it is still receiving parts of the document so that the initial processing of the document is divided into parts; however, this should not be the case here as the document is smaller than 2 kB. The parse and JavaScript modules (adding of the elements to the DOM) also take time to execute their tasks.
To further understand the rendering process in Firefox we decided to examine the Firefox source code responsible for handling the refresh rate. In the bug we consulted before, it was stated that this was part of the Core XPCOM component; however, it can be found in the layout/base folder of the project. The current versions of the header and source files can be found in [147, 148] respectively. Firefox will try to adjust its animation refresh rate to the monitor refresh rate. The code clearly states that vsync timing on Windows with DWM4is used, but that it will fall back dynamically to a fixed rate if required. For more information the bugs in [149, 150] can be consulted. We also tested the frame refresh rate on a monitor running at 75 Hz instead of the often used 60 Hz, Firefox would adjust its target refresh rate accordingly. A source code comment states that timers responsible for the scheduling of the updates will tick based on the current time and when the next tick should be sent if the target rate is being hit. It always schedules ticks on multiples of the target rate. In practice, this means that if some execution takes longer than an allotted slot, the next tick will be delayed instead of triggering instantly.5
However, if the refresh rate of the browser is affected by other phases in the rendering process, it seems to trigger as soon as the frame is ready. This can be seen in the results of the test we have done. In the appendix we have included test cases that show the effect of the layout process and the repaint process on the refresh rate. The effect the
2This bug is listed under the Linux platform, but concerns the general implementation of reques-
tAnimationFrame. It also discusses Windows and other platforms.
3Using a 60 Hz monitor 4Desktop Window Manager.
5A comment mentions that this might not be desirable, and the file includes a piece of code to
repaint process has on the refresh rate is the one that is exploited by the browser timing attacks. This effect is a relatively stable increase of delay in every frame.
Another important aspect of the implementation we discovered when examining the source code is that there is a different refresh driver timer for inactive documents. This one starts off with the base rate which is normally 1 fps, the rate will slowly be reduced until it is disabled altogether after a period of time. The timing attacks need to be ran in the active browser tab to produce the desired results.
One last adjustment to our test document that had slightly different results was the change of calling the requestAnimationFrame function manually, to having it trigger on page load. When it was triggered on page load, the number of frames with higher delay values at the start of the tests seemed to be reduced from four to two. This does not affect the timing attacks, but we mention it for completeness.
Chrome
Chrome seems to handle the processing of the frames in largely the same way as Firefox, but there are some small differences. First, Chrome always seems to only need one or two frames to do the initial rendering phase, even when the requestAnimationFrame function is manually called. Second, it does seem to perform better in general, and the delay introduced by the layout and repaint phases is less. As previously mentioned, because it is a multiprocessing browser each tab will be handled by its own process, which improves the general refresh rate.
The most important similarity that is needed for the timing attack vectors to be viable is that the repaint process also adds a relatively constant delay when triggered in every frame. In our first test document, <a> elements are used. It is important to note that for these elements, style updates are not done automatically; as described before, they can easily be triggered by touching the element. In the second document, the repaint process is simply triggered by the changing of the CSS “class” attribute, and the style update is done automatically.
Internet Explorer
Internet Explorer also seems to handle the processing steps in a similar way to the two other browsers. The biggest difference between Internet Explorer and Chrome is that the two first frames are rendered extremely fast, most of the time taking only a fraction of the target rate. When the load of the rendering process is increased, this does not seem to change much. However, when the layout or repaint phases are triggered in every frame, this does change the results. The layout changing test case produces very unstable frame durations in Internet Explorer, just like it did in the other browsers. The repaint process creates a relatively stable delay in every frame, also the initial frames.
when respectively 120 and 144 Hz monitors are used [151]. It does provide the expected results when running on a system that uses 60, 75, 85 or 100 Hz monitor.
The animation rate performance of a browser can also be tested using the tool in [152]. When using this tool it should be noted that it takes the average refresh time over 25 frames. The tool demonstrates well how the processing time inside the requestAnimationFrame loop affects the frame rate. With a monitor refresh rate of 60 Hz, the loop can contain up to about 14 ms of computation before the rate is affected.
5.6.2
Evaluation of the Implemented Timing Attack Vectors
In this section we will evaluate our own implementations of the browser timing attack vectors, the two first methods in section 4.8.6 were used in the development process of the vectors.
Firefox and Chrome
We have provided attack vector HTML documents for both the browsers in appendix B.6.2. They produce fast and accurate results on our testing system. They were both based on the modified version of method 2 of the timing attacks (section 4.8.6). This was beneficial in our results as we have encountered spike frames in the timing test cases on multiple occasions during our experiments (mostly in Firefox6).
The number of frames that was used to do the eventual evaluation is set at 5 for Chrome and 10 for Firefox.
Chrome has a useful web inspector tool, that can be used to analyse the style recal- culation and painting stages. The results of comparing a visited to an unvisited style recalculation stage can be seen in figures 5.1a and 5.1b. The same comparison for the paint stages can be seen in figures 5.2a and 5.2b.
(a) Unvisited (b) Visited
Figure 5.1: Comparison of the unvisited and visited style recalculation in Chrome when the attack vector is ran.
(a) Unvisited (b) Visited
Figure 5.2: Comparison of the unvisited and visited paint in Chrome when the attack vector is ran.
Internet Explorer
The Internet Explorer timing attack vector is based on method 1 of the browsing timing vectors. The vector works as such that if it can detect a redraw after the original rendering of the DOM, it will be assumed that the link is visited. In appendix B.6.2 we have included an attack vector that works on Internet Explorer and that exploits this method with the intention of history sniffing. We have tested and calibrated it on our testing system and it was able to produce positive results of detection in less than 500 ms, plus the initial rendering of the page. We have chosen to implement this attack for Internet Explorer because the second method does not work for this browser. We have decided to analyse 20 frames, the captured frames exclude the first 5 frames that are rendered because sometimes large spikes can occur in these frames and the link lookup query will always return later than this. Note that this is just the calibration that worked for us, it is possible that this should be set to another more desirable number. The captured frames will be analysed by taking the maximum frame duration and comparing it to a threshold.