Performance for Benign Users

A core indicator of the GUI program’s performance is its reaction time to user actions. To accurately measure the reaction time, we used Wireshark6to monitor the X11 packets passed through the TCP socket in the client machine. The reaction time was calculated as the difference between the departure time of the first user input packet and the arrival time of the last graphical output packet triggered by the user action.

We measured the reaction time of various actions performed on LibreOffice Writer (the word processor), LibreOffice Calc (the spreadsheet), and Gedit (the code editor). Each measurement was repeated 10 times. The actions we tested are the following.

3_{https://www.libreoffice.org/}

4_{https://www.openhub.net/p/libreoffice/analyses/latest/languages summary} 5_{https://www.x.org/}

Start the program. Each program was started by entering a command in the terminal. The reaction time was measured as the duration between the command key press and the first window of the program displayed on the screen.

Open a file. We opened a 46KiBtext file in Writer, a 25KiBspreadsheet in Calc, and a 88KiB source code file in Gedit. The reaction time was measured as the duration between the open button click and the full text rendered on the screen.

Close the program. We exited each program by closing its first window. The reaction time was measured as the duration between the close button click and all graphical resources released by the program.

Scroll down. For each program, we clicked the scroll bar once to scroll down the window by one page. The reaction time was measured as the duration between the scroll bar click and the new text rendered on the screen.

Search a string. We searched a string in each program. The reaction time was measured as the duration between the search button click and the string being located on the screen.

Paste text. We pasted a 3984-character sentence in Writer, a 47-by-14 spreadsheet table in Calc, and a 13-line source code snippet in Gedit. The reaction time was measured as the duration between the paste button click and the pasted text rendered on the screen.

These actions were tested in five settings. In the first setting, the GUI program ran locally in the client machine, which is the normal setting without data protection from remote-only access. To assist reaction-time measurement, the X11 packets were transmitted through local TCP sock- ets. In the other four settings, the GUI program ran on the server machine, and the user interacted with the program through the client machine. Among these four settings, the first one ran the pro- gram natively without instrumentation; the second one ran the program under the protection of Snowman; the third one ran the program under the “null tool” of Pin [97] (v3.6); and the last one ran the program under the “taint tool” of Pin (v3.6) with the reading bytes from the opened file marked as tainted. The Pin “null tool” does the minimal amount of instrumentation to maintain

Figure 4.4: Reaction time for common user actions when running the programs locally 1) in the client machine, remotely 2) in the server machine without instrumentation, 3) monitored by Snowman, 4) by the Pin “null tool”, or 5) by the Pin “taint tool”

supervised execution of the program. The Pin “taint tool” conducts multi-label taint tracking and employs the same set of taint analysis rules as Snowman. It was implemented by us and was used to debug and validate the implementation of Snowman’s taint analysis engine.

Figure 4.4 shows the average reaction time of various actions in different settings, where the error bar represents the standard deviation. Overall, the reaction time of the actions in Snowman was 0.92×to 2.41×the reaction time of those actions in the remote-only setting without any instrumentation. Among these actions, opening a file, starting and closing the program have rela- tively large overhead (1.16×to 2.41×) because Snowman needs to record the non-deterministic inputs and take extra steps to set up and tear down the environment for recording. However, we don’t expect this would have significant impact on user experience since these actions are not frequently triggered by the user in typical workloads. The reaction time of other actions in Snow- man are comparable to those in the remote-only setting (0.92×to 1.19×).

Additionally, Snowman performs better than the Pin “null tool” and “taint tool” in all tests. Compared with the remote-only setting without any instrumentation, the reaction time overhead is 1.05×to 23.07×in the Pin “null tool” and 4.3×to 133.1×in the Pin “taint tool”. The actions triggering taint propagation (opening a file, scrolling down, searching a string, and pasting text) have huge overhead in the Pin “taint tool”. We don’t claim this multi-label taint tracking tool implemented by us has the best possible implementation. But we expect other similar tools would have similarly considerable overhead because the taint analysis routines are inlined with the nor- mal program code by the Pin instrumentation. Besides, considering that the “null tool” doesn’t implement any instrumentation for taint analysis, which represents a lower bound for taint analy- sis approaches implemented with Pin, Snowman should perform better than any Pin-based taint analysis tools.