Add references for Ephemeral Fingerprinting

index.html

@@ -129,6 +129,18 @@
               "authors": ["Ashkan Soltani","Shannon Canty","Quentin Mayo","Lauren Thomas","Chris Jay Hoofnagle"],
               "title": "Flash Cookies and Privacy"
             },
+            "EPHEMERAL-FINGERPRINTING": {
+              "href": "https://github.com/asankah/ephemeral-fingerprinting",
+              "date": "1 September 2020",
+              "authors": ["Asanka Herath"],
+              "title": "Ephemeral Fingerprinting On The Web"
+            },
+            "RENDERING-CONTENTION": {
+              "href": "https://www.usenix.org/system/files/sec22summer_wu.pdf",
+              "date": "August 2022",
+              "authors": ["Shujiang Wu", "Jianjia Yu", "Min Yang", "Yinzhi Cao"],
+              "title": "Rendering Contention Channel Made Practical in Web Browsers"
+            },
             "FLASHCOOKIES-2": {
               "href": "https://ptolemy.berkeley.edu/projects/truststc/education/reu/11/Posters/AyensonMWambachDpaper.pdf",
               "authors": ["Mika Ayenson", "Dietrich Wambach", "Ashkan Soltani", "Nathan Good", "Chris Hoofnagle"],
@@ -260,6 +272,12 @@ <h3 id="active">Active</h3>
           <p>For <dfn>active fingerprinting</dfn>, we also consider techniques where a site runs JavaScript or other code on the local client to observe additional characteristics about the browser, user, device or other context.</p>
           <p>Techniques for active fingerprinting might include accessing the window size, enumerating fonts or plug-ins, evaluating performance characteristics, reading from device sensors, and rendering graphical patterns. Key to this distinction is that <a>active fingerprinting</a> takes place in a way that is potentially detectable on the client.</p>
         </section>
+        <section>
+          <h3 id="ephemeral">Ephemeral</h3>
+          <p><dfn>Ephemeral fingerprinting</dfn> is a technique to associate separate simultaneous sessions on a device with one another using observations of events that occurr near simultaneously on multiple origins [[?EPHEMERAL-FINGERPRINTING]].  These events are typically fired as a result of a change in hardware or environment, such as MediaDevices.devicechange [[?mediacapture-streams]].</p>
+          <p>Ephemeral fingerprinting is not typically a concern except in certain threat models - it is only useful when an attacker is unable to link two sessions via passive or active fingerprinting techniques, which would typically include considering the sessions' IP address.  In uncommon situations, those techniques can fail, but ephemeral fingerprinting can still be used to link sessions between e.g. two entirely different browser applications or two tabs that are sent over different network connections.</p>
+          <p>Ephemeral fingerprinting may be possible with complex CSS, but typically requires JavaScript and it can be done in a reactive manner where JavaScript merely observes events, or it can be done in a proactive manner by heavily utilizing resources such as the CPU or GPU that another origin can observe. This type of attack between cooperating origins is typically referred to as a "covert channel" and there have been many papers about them using different techniques, for example [[?RENDERING-CONTENTION]].</p>
+        </section>
         <section>
           <h3 id="cookie_like_setting_retrieving_local_state">Cookie-like</h3>
           <p>Users, user agents and devices may also be re-identified by a site that first sets and later retrieves state stored by a user agent or device. This <dfn>cookie-like fingerprinting</dfn> allows re-identification of a user or inferences about a user in the same way that HTTP cookies allow state management for the stateless HTTP protocol [[?RFC6265]].</p>
@@ -322,7 +340,7 @@ <h2 id="identifying">Identifying fingerprinting surface and evaluating severity<
         <dt>entropy</dt><dd>How distinguishing is this new surface? Consider both the possible variations and the likely distribution of values. Adding 1-bit of entropy is typically of less concern; 30-some bits of entropy would be enough to uniquely identify every individual person. Different data sources may provide different distributions of variation; for example, some characteristics may reveal a common hardware class while other characteristics may reveal user configurations that vary between individual people.</dd>
         <dt>detectability</dt><dd>Will use of this feature for browser fingerprinting be observable to the user agent or likely to be discoverable by researchers? Because detectability is an important &mdash; and perhaps the most feasible &mdash; mitigation, increases to the surface for <a>passive fingerprinting</a> are of particular concern and should be avoided.</dd>
         <dt>persistence</dt><dd>How long will the characteristics of this fingerprinting surface stay unchanged? Can users control or re-set these values to prevent long-lived identification? While short-lived characteristics may still enable unexpected correlation of activity (for example, between two browser profiles on the same device), persistent or permanent identifiers are particularly concerning for the lack of user control.</dd>
-        <dt>availability</dt><dd>Will this surface be available to the "drive-by Web" or only in certain contexts where a user has granted a particular sensor permission or directly authenticated? While browser fingerprinting is still something to mitigate in the permissioned context, the concern that a feature will end up used primarily for fingerprinting is reduced.</dd>
+        <dt>availability</dt><dd>Will this surface be available to the "drive-by Web" or only in certain contexts such as when a document is visible or where a user has granted a particular sensor permission or directly authenticated? While browser fingerprinting is still something to mitigate in the permissioned context, the concern that a feature will end up used primarily for fingerprinting is reduced.</dd>
         <dt>scope</dt><dd>Is this surface consistent across origins or only within a single origin? In general, characteristics or identifiers that are tied to a particular origin are of less concern and can be handled with the same tools as HTTP cookies.</dd>
       </dl>
 
@@ -357,6 +375,9 @@ <h3>Weighing increased fingerprinting surface</h3>
             <p class="practicedesc">
               What browsing contexts, resources and requests need access to a particular feature?  Identifiers can often be scoped to have a different value in different origins. Some configuration may only be necessary in top-level browsing contexts.
             </p>
+            <p class="practicedesc">
+              If an event is to be fired in response to an environmental or hardware change, can that event be fired only on visible documents, and queued for firing in non-visible documents? Should it be restricted by an iframe sandbox?
+            </p>
             <p class="practicedesc">
               Should access to this functionality be limited to where users have granted a particular permission? While excessive permissions can create confusion and fatigue, limiting highly granular data to situations where a user has already granted permission to access sensitive data widely mitigates the risk of that feature being used primarily for browser fingerprinting in "drive-by" contexts. For example, Media Capture and Streams [[?mediacapture-streams]] limits access to attached microphone and camera device labels to when the user has granted permission to access a camera or microphone (while still allowing access to the number and configuration of attached cameras and microphones in all contexts, a noted increase in drive-by fingerprinting surface).
             </p>