xsite-tracking-model.bsinc

## Cross-site recognition ## {#model-cross-site-recognition}

<table class="threatmodel">
<tr class="goals">
  <td></td>
  <th><div><div>[[#goal-transfer-userid]]</div></div></th>
  <th><div><div>[[#goal-userid-tracker-to-self-in-pub]]</div></div></th>
  <th><div><div>[[#goal-userid-tracker-in-pub1-to-self-in-pub2]]</div></div></th>
  <th><div><div>[[#goal-prob-transfer-userid-no-nav]]</div></div></th>
  <th><div><div>[[#goal-prob-transfer-userid]]</div></div></th>
</tr>
<tr>
  <th>[[#cap-iframes]]</th>
  <td data-goal="transfer-userid" style="color:green">✘</td>
  <td data-goal="userid-tracker-to-self-in-pub" style="color:green">✘</td>
  <td data-goal="userid-tracker-in-pub1-to-self-in-pub2" style="color:green">✘</td>
  <td data-goal="prob-transfer-userid-no-nav" style="color:green">✘</td>
  <td data-goal="prob-transfer-userid" style="color:green">✘</td>
</tr>
<tr>
  <th>[[#cap-first-party-js]]</th>
  <td data-goal="transfer-userid" style="color:green">✘</td>
  <td data-goal="userid-tracker-to-self-in-pub" style="color:green">✘</td>
  <td data-goal="userid-tracker-in-pub1-to-self-in-pub2" style="color:green">✘</td>
  <td data-goal="prob-transfer-userid-no-nav" style="color:green">✘</td>
  <td data-goal="prob-transfer-userid" style="color:green">✘</td>
</tr>
<tr>
  <th>[[#cap-read-logs]] on other publishers</th>
  <td data-goal="transfer-userid" style="color:green">✘</td>
  <td data-goal="userid-tracker-to-self-in-pub" style="color:green">✘</td>
  <td data-goal="userid-tracker-in-pub1-to-self-in-pub2" style="color:green">✘</td>
  <td data-goal="prob-transfer-userid-no-nav" style="color:green">✘</td>
  <td data-goal="prob-transfer-userid">
  <details>
    <summary style="color:red">✓</summary>
    Publisher 2 reads their own logs for the page load and publisher 1's logs for the click tracking of the navigation click. [=User IDs=] that clicked on publisher 1 approximately the same
    time as that link's target loaded on publisher 2 are
    probabilistically correlated.
  </details>
  </td>
</tr>
<tr>
  <th>[[#cap-run-on-server]] on the target publisher</th>
  <td data-goal="transfer-userid">
    <span style="color:green">✘</span>
  </td>
  <td data-goal="userid-tracker-to-self-in-pub">
    <details>
    <summary style="color:red">✓</summary>
    The tracker adds a path segment, possibly encrypted, in their links to the
    publisher, encoding the user's ID within the tracker. They convince the
    publisher to <a href="#ess-server-defined-paths">ignore that path segment in
    their server processing</a>. The tracker running inside that publisher reads
    the URL, decodes the tracker site's user ID, and <a
    href="#ess-js-requests">sends that and the tracker-within-publisher user ID
    up to the tracker's server</a>.
  </details>
  </td>
  <td data-goal="userid-tracker-in-pub1-to-self-in-pub2" >
    <span style="color:green">✘</span>
  </td>
  <td data-goal="prob-transfer-userid-no-nav" >
    <span style="color:green">✘</span>
  </td>
  <td data-goal="prob-transfer-userid">
    <span style="color:green">✘</span>
  </td>
</tr>
<tr>
  <th>[[#cap-first-party-js]] or [[#cap-run-on-server]] on the source site and [[#cap-run-on-server]] on the target publisher</th>
  <td data-goal="transfer-userid">
    <span style="color:green">✘</span>
  </td>
  <td data-goal="userid-tracker-to-self-in-pub" >
    <details>
      <summary style="color:red">✓</summary>
      The tracker adds a path segment, possibly encrypted, in their links to the
      publisher, encoding the user's ID within the tracker. They convince the
      publisher to <a href="#ess-server-defined-paths">ignore that path segment in
      their server processing</a>. The tracker running inside that publisher reads
      the URL, decodes the tracker site's user ID, and <a
      href="#ess-js-requests">sends that and the tracker-within-publisher user ID
      up to the tracker's server</a>.
    </details>
  </td>
  <td data-goal="userid-tracker-in-pub1-to-self-in-pub2" >
    <details>
      <summary style="color:red">✓</summary>
      The tracker adds a path segment, possibly encrypted, in the publisher 1's
      links to publisher 2, encoding the user's ID within publisher 1. They
      convince publisher 2 to <a href="#ess-server-defined-paths">ignore that
      path segment in their server processing</a>. The tracker running inside
      that publisher reads the URL, decodes publisher 1's user ID, and <a
      href="#ess-js-requests">sends that and publisher 2's user ID up to the
      tracker's server</a>.
    </details>
  </td>
  <td data-goal="prob-transfer-userid-no-nav" >
    <span style="color:red">✓</span>
  </td>
  <td data-goal="prob-transfer-userid">
    <span style="color:red">✓</span>
  </td>
</tr></table>

Further cross-site recognition is available by combining capabilities with the
ability to [[#cap-first-party-js]] (or [[#cap-run-on-server]] to add
attacker-controlled javascript):

<table class="threatmodel">
<tr class="goals">
  <td></td>
  <th><div><div>[[#goal-prob-transfer-userid-no-nav]]</div></div></th>
</tr>
<tr>
  <th>[[#cap-type-identifier]]</th>
  <td data-goal="prob-transfer-userid-no-nav">
      <details>
        <summary style="color:red">✓</summary>
        The tracker gets a report of the identifiers typed in both publisher
        sites, along with each publisher's [=user id=]. If they're equal, the
        [=user ids=] probably refer to the same user. The probability depends on
        the type of identifier: email addresses or credit card numbers are very
        high probability. Names or dates of birth are lower probability unless
        combined with other information like a zip code.
    </details>
  </td>
</tr>
<tr>
  <th>[[#cap-same-device-same-time]]</th>
  <td data-goal="prob-transfer-userid-no-nav">
      <details>
        <summary style="color:red">✓</summary>
        The tracker reads the two devices, and if they give the same output at
        approximately the same time, the user is probably the same. For devices
        like cameras and microphones, detection is likely to be very accurate.
        Others, like ambient light, might only give a few bits per sample, and
        so need a long period of overlap in order to provide a good correlation.

        For some devices, this transfer can be mitigated by turning off input
        when the site isn't visible or isn't focused, but user expectations
        limit where that mitigation is applicable.
    </details>
  </td>
</tr>
<tr>
  <th>[[#cap-same-rw-device]]</th>
  <td data-goal="prob-transfer-userid-no-nav">
      <details>
        <summary style="color:red">✓</summary>
        The tracker writes identifying content to the device and then reads it
        back when the other site is opened. This is visible to varying degrees
        depending on the device: an individual native file or a Bluetooth or USB
        device that isn't designed to cooperate with this sort of tracking, is
        likely to break in obvious ways when the tracker tries to write an
        identifier. A native directory, on the other hand, has many available
        filenames that could hold identifying information without a user being
        likely to notice.
    </details>
  </td>
</tr>
<tr>
  <th>[[#cap-open-for-browser-event]]</th>
  <td data-goal="prob-transfer-userid-no-nav">
    <span style="color:green">✘</span>
  </td>
</tr>
<tr>
  <th>[[#cap-visible-for-browser-event]]</th>
  <td data-goal="prob-transfer-userid-no-nav">
      <details>
        <summary style="color:red">✓</summary>
        Browser-wide events generally need to be visible immediately when a user
        is looking at a website, so the tracker just needs to notice that the
        event's parameters are the same, and its timestamp across two sites is
        close together. The probability of identifying a single user goes up as
        more events are observed.
    </details>
  </td>
</tr>
</table>