Merge pull request #87 from w3c/priv-sec

Add security/privacy considerations from doc

index.bs

@@ -361,7 +361,62 @@ Report long tasks {#report-long-tasks}
 Security & privacy considerations {#priv-sec}
 ===============================================
 
-Long Tasks API adheres to the same-origin policy by including origin-safe attribution information about the source of the long task.
-There is a 50ms threshold for long tasks. Together this provides adequate protection against security attacks against browser.
+Long Tasks API adheres to the same-origin policy by including origin-safe attribution information about
+the source of the long task. There is a 50ms threshold for long tasks. Together this provides adequate
+protection against cross-origin leaks.
+
+The Long Tasks API provides timing information about the duration and type of tasks executed by the user,
+as well as attribution such as the browsing context causing the function calls. This could enable an attacker
+to perform side-channel timing attacks to guess the user’s action, or identify the user. For example, a pattern of
+long script followed by a long render could be put together to guess user’s interaction with a social
+widget. Detailed function call attribution would be used to determine the user’s action.
+
+While the API doesn’t introduce any new privacy attacks, it could make existing privacy attacks faster.
+Mitigations for this are possible and can be implemented as needed:
+
+* Further clamp the long task duration provided by the API to make attacks harder to exploit (i.e. round the
+    result or add random jitter to the value).
+* Limit the number of origins for which longtasks are exposed by the API, and obfuscate the attribution of
+    any tasks afterwards. For instance, a page with 5 iframes could receive only attribution for tasks from 3
+    of those iframes, and would receive no attribution ({{PerformanceEntry/name}} set to <code>unknown</code>")
+    for tasks from the other 2.
+* Allow dropping the culprit/attribution information after a certain threshold. For instance, after 10 longtasks
+    all entries would receive no attribution and their {{PerformanceEntry/name}} would be "<code>unknown</code>".
+* Add a built-in delay to the timing information exposed to make attacks dependent on longtask volume harder
+    to execute.
+
+What is Exposed to Observers? {#what-is-exposed}
+--------------------------------------------------------
+
+All observers within the top level page (i.e. all iframes in the page and the main frame) will receive
+notifications about presence of long tasks. We expose the start time of the task, its duration, and a
+pointer to the culprit frame. This information can already be observed today, and with higher resolution,
+using setTimeout. An attacker can do this by clearing everything else on the page and adding the
+vulnerable cross-origin resource to ensure that delays from the setTimeout are caused by that resource.
+Observers in other different pages (tabs or windows) should not receive notifications, regardless of the
+architecture of the user agent.
+
+Cross origin rules for what is exposed:
+* Cross-origin observers may see the direction of the culprit e.g if the culprit is a deeply nested iframe,
+    then the host page can see the first cross-origin between itself and the culprit.
+* Conversely, if the culprit is the top level page, then a deeply embedded iframe can see that a longtask
+    occurrred in its cross-origin ancestor but does not receive any information about it.
+
+Attack Scenarios Considered {#attack-scenarios}
+--------------------------------------------------------
+
+The following are the timing attacks considered:
+
+1. <b>Traditional timing attacks</b>: using external resource load time to reveal the size of
+    private data. For instance the number of hidden pictures in a gallery, whether username is
+    valid, etc. See an <a href="http://crypto.stanford.edu/~dabo/papers/webtiming.pdf">example</a>.
+
+1. <b>Side-channel timing attacks</b>: using time for video parsing, script parsing, App Cache reads
+    or Cache API (service workers) usage to uniquely identify a user, or to create a profile of the
+    user’s age, gender, location, and interests etc. For
+    <a href="https://tom.vg/papers/timing-attacks_ccs2015.pdf">instance</a>, status updates from
+    a social network can be limited to certain demographic (eg. females of age 20-30) the file size of
+    the permalink page can be used to determine whether the user is in the target demographic.
 
-However, privacy related attacks are possible, while the API doesn’t introduce any new privacy attacks, it could make existing privacy attacks faster. Mitigations for this are possible and discussed in the security review <a href="https://docs.google.com/document/d/1tIMI1gau_q6X5EBnjDNiFS5NWV9cpYJ5KKA7xPd3VB8/edit">in this document</a>.
+These scenarios are addressed by the 50ms threshold AND respecting cross-origin boundary i.e. not
+showing task type or additional attribution to untrusted cross origin observers.