Closed Bug 1901799 Opened 1 year ago Closed 1 year ago

Collect CSS Pointer Capabilities

Categories

(Core :: Privacy: Anti-Tracking, task, P3)

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
129 Branch
Tracking Flags:
Tracking Status
firefox129 --- fixed

People

(Reporter: fkilic, Assigned: fkilic)

Details

Attachments

(1 file)

Bug 1901799: Collect CSS Pointer Capabilities. r?timhuang
48 bytes, text/x-phabricator-request
Details | Review
No description provided.

DATA REVIEW REQUEST

  1. What questions will you answer with this data?

How unique is the user's pointer type.

More generally: What is the most productive use of engineering time to make fingerprinting an ineffective method of tracking users? As detailed in https://bugzilla.mozilla.org/show_bug.cgi?id=1879151

  1. Why does Mozilla need to answer these questions? Are there benefits for users?
    Do we need this information to address product or business requirements?

We want to improve our fingerprinting defenses. We don't want to guess at what will make an improvement, so we want to make a decision based on data. We also want to know how much of an improvement we have made, so we can state it and know how much further we have to go.

  1. What alternative methods did you consider to answer these questions?
    Why were they not sufficient?

We considered privacy preserving metric collection (DAP), collecting it indirectly (e.g. via hashes of the data), using exisiting (lmited) data we currently collect, not collecting the data at all and using academic literature. These options are detailed in https://docs.google.com/document/d/1m_j0BQEprQleRHZ7tVT7mG-krc8UA171GD5Vl6gZbL0/edit

  1. Can current instrumentation answer these questions?

As detailed in https://docs.google.com/document/d/1m_j0BQEprQleRHZ7tVT7mG-krc8UA171GD5Vl6gZbL0/edit - some attributes are collected by current instrumentation. However, using this data (and not using the other data we don't collect) will give an incomplete picture that may mislead us into choosing a task that does not make an appreciable change for users. We will also be unable to accurately state the improvement we have made.

  1. List all proposed measurements and indicate the category of data collection for each
    measurement, using the Firefox data collection categories found on the Mozilla wiki.
Measurement Name Measurement Description Data Collection Category Tracking Bug
characteristics.pointer_type Pointer type of the user. technical https://bugzilla.mozilla.org/show_bug.cgi?id=1901799
characteristics.any_pointer_type Union of pointers the user have. technical https://bugzilla.mozilla.org/show_bug.cgi?id=1901799
  1. Please provide a link to the documentation for this data collection which
    describes the ultimate data set in a public, complete, and accurate way.

This collection is Glean so is documented in the Glean Dictionary.

  1. How long will this data be collected?

This collection will be collected permanently.
tom@mozilla.com will be responsible for the permanent collections.

  1. What populations will you measure?

All channels, countries, and locales. No filters.

  1. If this data collection is default on, what is the opt-out mechanism for users?

These collections are Glean. The opt-out can be found in the product's preferences.

  1. Please provide a general description of how you will analyze this data.

The general question is "What engineering tasks should we do". To determine that, we will answer sub-questions like:

  • How many users are uniquely identifiable via fingerprinting?
  • For the users who are not, how large a cohort are they bucketed into?
  • What attributes contribute the most to making users unique, or placing them in small buckets
  • What attributes correlate with each other, such that we would need to address them in tandem
  1. Where do you intend to share the results of your analysis?

We hope to publish an academic paper, actually, as this is a significant contribution to the topic of browser fingerprinting. We can also expect to do a blog post. The decisions about what engineering tasks we choose to do to decrease the uniqueness of our users will be filed as Bugzilla Bugs that will contain descriptions of why this is the engineering task to do.

  1. Is there a third-party tool (i.e. not Glean or Telemetry) that you
    are proposing to use for this data collection?

No.

Pushed by tihuang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/970c5b02280e Collect CSS Pointer Capabilities. r=timhuang

Backed out for causing leakcheck failures

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | leakcheck | default 3472 bytes leaked (APZEventState, ActiveElementManager, IAPZCTreeManager, IMContextWrapper, InputQueue, ...)
    TEST-UNEXPECTED-FAIL | leakcheck | tab 2176 bytes leaked (DrawTargetSkia, MozPromiseRefcountable, Mutex, PuppetWidget, StringBuffer, ...)
Flags: needinfo?(fkilic)

I working on a fix. I couldn't find the main reason for the leak. I have suspicion that it is about pointer event collection timing out the test, although I have to verify.

Flags: needinfo?(fkilic)
Pushed by tihuang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/929d9508ad19 Collect CSS Pointer Capabilities. r=timhuang

Backed out for causing multiple failures.

  • Push with failures - build bustages
  • Failure Log
  • Failure line: /builds/worker/checkouts/gecko/gfx/gl/GLContextProviderWGL.cpp(475,8): error: no viable conversion from 'mozilla::CastableTypedEnumResult<CreateContextFlags>' to 'bool'
Flags: needinfo?(fkilic)

Working on a fix right now, thank you!

Flags: needinfo?(fkilic)

Hello !
The following alert was generated by the backout . Do you think this bug or one of the following bugs Bug 1901799, Bug 1897271, Bug 1900863, Bug 1902364, Bug 1902671, Bug 1902086, Bug 1901771, Bug 1902003, Bug 190235 is responsible for generating the alert ?

Perfherder has detected a browsertime performance change from push 5f6f41a83f0ea8d64264cf04f49a5940f9c8705b.

Regressions:

Ratio Test Platform Options Absolute values (old vs new) Performance Profiles
22% wikipedia fcp android-hw-a51-11-0-aarch64-shippable-qr warm webrender 69.60 -> 85.21 Before/After
11% speedometer3 TodoMVC-Preact-Complex-DOM/Adding100Items/Sync macosx1400-64-shippable-qr fission webrender 0.70 -> 0.78 Before/After
8% speedometer3 TodoMVC-Svelte-Complex-DOM/Adding100Items/Sync macosx1400-64-shippable-qr fission webrender 1.51 -> 1.62 Before/After
7% speedometer3 TodoMVC-Svelte-Complex-DOM/Adding100Items/Sync windows10-64-shippable-qr fission webrender 3.21 -> 3.43 Before/After
6% speedometer3 TodoMVC-Svelte-Complex-DOM/Adding100Items/Sync windows10-64-nightlyasrelease-qr fission webrender 3.17 -> 3.37 Before/After
5% speedometer3 TodoMVC-Preact-Complex-DOM/Adding100Items/total macosx1400-64-shippable-qr fission webrender 5.19 -> 5.44 Before/After
4% speedometer3 TodoMVC-Svelte-Complex-DOM/CompletingAllItems/total windows10-64-shippable-qr fission webrender 7.37 -> 7.69 Before/After
4% speedometer3 Charts-chartjs/Show tooltip/Sync macosx1400-64-shippable-qr fission webrender 0.08 -> 0.08 Before/After
4% speedometer3 TodoMVC-Svelte-Complex-DOM/CompletingAllItems/Async windows10-64-shippable-qr fission webrender 5.97 -> 6.18 Before/After
3% speedometer3 TodoMVC-Preact-Complex-DOM/total macosx1400-64-shippable-qr fission webrender 11.59 -> 11.93 Before/After
2% speedometer3 TodoMVC-Preact-Complex-DOM/DeletingAllItems/Async macosx1400-64-shippable-qr fission webrender 1.74 -> 1.78 Before/After

Improvements:

Ratio Test Platform Options Absolute values (old vs new) Performance Profiles
17% fandom largestContentfulPaint linux1804-64-shippable-qr fission warm webrender 47.46 -> 39.44 Before/After
9% speedometer3 TodoMVC-Svelte-Complex-DOM/Adding100Items/Async windows10-64-nightlyasrelease-qr fission webrender 9.35 -> 8.52 Before/After
8% wikia FirstVisualChange linux1804-64-shippable-qr cold fission webrender 330.15 -> 305.37 Before/After
7% speedometer3 TodoMVC-Svelte-Complex-DOM/Adding100Items/Async windows10-64-shippable-qr fission webrender 9.36 -> 8.67 Before/After
7% wikia largestContentfulPaint linux1804-64-shippable-qr fission warm webrender 193.05 -> 180.32 Before/After
... ... ... ... ... ...
2% speedometer3 Charts-observable-plot/Stacked by 6/Async macosx1400-64-shippable-qr fission webrender 2.38 -> 2.33 Before/After

As author of one of the patches included in that push, we need your help to address this regression.
Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the patch(es) may be backed out in accordance with our regression policy.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run these tests on try with ./mach try perf --alert 899

For more information on performance sheriffing please see our FAQ.

Flags: needinfo?(fkilic)

There's a high chance Bug 1902086 is the cause, but we replaced it wholly. So the commits later in the stack should fix this issue, I will try to verify it. Thank you!

Flags: needinfo?(fkilic)

Just to confirm, are we sure that it is my patches that caused the slowdown or the backout? This is my first time dealing with perfherder so I might be wrong, but on the alert you linked, isn't the base commit my patches, while the new commit is the backout? My commits didn't land, so I there's not much for me to do for

let us know your plans within 3 business days, or the patch(es) may be backed out

I could be totally wrong though.

Flags: needinfo?(fbilt)

We came to conclusion which patch made the difference here.

Flags: needinfo?(fbilt)
Pushed by tihuang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4c5563165c35 Collect CSS Pointer Capabilities. r=timhuang

Backed out for causing mochitests failures in browser_usercharacteristics.js.

Pushed by tihuang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/77372bb33e5f Collect CSS Pointer Capabilities. r=timhuang

https://hg.mozilla.org/mozilla-central/rev/77372bb33e5f

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox129: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 129 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: