### Rating (1--4): + 3: Weak Accept -- This paper may have flaws, but I would not argue against it at a major conference ### What did this paper do well? + Presented a creative method and provided formal proofs + Proposed method is proactive, backward compatible and appears to be easy to install + Had a working prototype, source codes are available, and decent measurements were done. ### Where did this paper fall short? + The paper did not provide a good background on browser timing attack in order to highlight the relevance and importance of their work. + The paper did not explain well the ideas in each step or at least, their explanations did not come out smooth enough. For example, in the very beginning, when talking about 2 types of RF, while talking about the definition of the first type, the paper wandered into how their definition of "deterministic" is different from others. What could be done (instead) is giving more examples of what are RFs with/without secrets. + Describing the implementations of DeterFox was poor. Some details can be emphasized to highlight the importance of certain design points. ### What did you learn from reading this paper? + The complexity of defending against browser level timing attacks + The term reference frames (RFs) and the strategy of breaking browser up to RFs with a clock for each RF + Firefox and Chrome do not have strong protections against certain browser level timing attacks ### What questions do you have about the paper or the area? + How to redefine the clock within an RF ? + How exactly are RFs formed ? + Why clock information in no target secret RFs need to be communicated to a deterministic RF ?
