For active fingerprinting, 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.
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 active fingerprinting takes place in a way that is potentially detectable on the client.
+Ephemeral fingerprinting is a technique to associate separate + simultaneous sessions on a device with one another using observations of events + that occur near simultaneously on multiple origins [[?EPHEMERAL-FINGERPRINTING]]. + These events are typically fired as a result of a change in hardware or environment, + such as when a device's posture + changes or when the + set + of available media devices changes.
+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.
+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]].
+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 cookie-like fingerprinting 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]].
@@ -322,7 +358,7 @@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.
++ If an event is to be fired in response to an environmental or hardware change, + only fire that event when the window's [=associated document=]'s [=Document/visibility state=] is "`visible`", + or in Workers whose [=WorkerGlobalScope/owner set=] includes such a Document. + If background pages need to learn of the event when they're focused, + also fire the event while updating the visibility state. + Consider whether it should be restricted by an iframe sandbox. +
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).