1461764 - Add Telemetry for Cross-Origin SVG/CSS Filters

Status: RESOLVED DUPLICATE of bug 1480695

(Core :: SVG, enhancement, P3)

Description

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Cross-origin filters (both CSS and SVG) have lead to attacks where an attacker can learn the contents of other origins' data in violation of SOP.  The attacker tracks the amount of time that is required to apply a particular filter, and based on that can infer the value of the source image.

To mitigate this, we disabled feDisplacementMap in some contexts (the exact situations it is disabled and what bug that was done in I am unsure of.)

Safari took a more conservative step, and generally disabled most or all cross-origin filters, as seen on this test site: https://ritter.vg/misc/ff/pixel-2.html

I'd like to add Telemetry to determine how often filters are applied cross-origin, and depending on how that looks, explore options (algorithm changes/disabling) for taking a more conservative approach.

Comment 1

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I forgot to add links to Safari's changes regarding this:

https://bugs.webkit.org/show_bug.cgi?id=173388
https://trac.webkit.org/changeset/218300/webkit

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: Bug 1461764 Add Telemetry to track cross-domain canvas use

Review commit: https://reviewboard.mozilla.org/r/249426/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/249426/

Comment 3

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attaching a patch for review.  Code-wise it has a few problems.

1) It might(?) count chrome canvases? Do we use those? I didn't observe the ticker incrementing for them though, so this might not be an issue.

2) When a content process shuts down and destroys canvases then, telemetry for them does not get accumulated.

3) My assumption that the size of the canvas will give us an indication of whether it's for tracking or not might be wrong. Steve?




Data Review:
>    What questions will you answer with this data?

What percentage of our canvases, in what sizes, are using cross-domain data.

>    Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:

It would be nice to be able to restrict SVG filters to not apply to cross-domain content to avoid pixel-stealing attacks, like Safari has done.

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

We could crawl, but we don't have the infrastructure really; nor would it tell us about popularity.

>    Can current instrumentation answer these questions?

AFAIK, no.

>    How long will this data be collected? Choose one of the following:

    I want this data to be collected for 6 months initially (potentially renewable).

>    What populations will you measure?
>    Which release channels?
>    Which countries?
>    Which locales?

Release, Opt-In.

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

Look at pie charts.

>    Where do you intend to share the results of your analysis?

Internally; and with Chrome engineers who also expressed mild interest.

Comment 4

[François Marier [:francois]]

(In reply to Tom Ritter [:tjr] from comment #3)

This is missing Question 5 from https://github.com/mozilla/data-review/blob/master/request.md.

Can you put all of the above answers, plus your answer to question 5 in a text file to attach to this bug please? Then you can r? me on it. That way it's easier to keep track of the version of the data review form that was r+'d.

Thanks!

Comment 5

[Steven Englehardt [:englehardt]]

I'm not sure the size check will be sufficient. When we did our analysis back in 2016 [0] most of the canvases used for fingerprinting were the default size (300 x 150), but that may have changed. I suspect there will be a lot of overlap with other non-tracking canvases (since it's the default). Our detection criteria in [0] was:

1. The canvas element’s height and width properties must not be set below 16 px.
2. Text must be written to canvas with least two colors or at least 10 distinct characters.
3. The script should not call the save, restore, or addEventListener methods of the rendering context.
4. The script extracts an image with toDataURL or with a single call to getImageData that specifies an area with a minimum size of 16px × 16px.

This resulted in 4 false positives out of 3493 scripts identified on a 1 million site measurement. This heuristic was tweaked from an earlier measurement in 2014 [1] to minimize false positives that were the result of increased adoption of canvas for non-tracking uses. I suspect it will need further changes to filter out new types of false positives.

Can you implement some of these filters in telemetry?

[0] https://webtransparency.cs.princeton.edu/webcensus/
[1] https://securehomes.esat.kuleuven.be/~gacar/persistent/the_web_never_forgets.pdf

Comment 6

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Steven Englehardt [:englehardt] from comment #5)
> Can you implement some of these filters in telemetry?

I suppose I could; but going after fingerprinting was kind of orthogonal to the original goal of this Telemetry probe. I think the correct thing to do here is to measure

What percentage of all canvases use tainted input.
What percentage of all canvases use filters.
What percentage of filtered canvases use tainted input.

Comment 7

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: datareview-request.txt

Sorry about that; I had misunderstood question 5.

Comment 8

[Phabricator Automation]

Attachment: Bug 1461764 Add Telemetry to track tainted/filtered canvas use r?mstange

MozReview-Commit-ID: 6tZ8VK7xZgq

Comment 9

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Markus; I attached a patch that shows the theory of what I'd like to do; but testing indicates it doesn't really work.  Canvases with no filters (I tested with https://ritter.vg/misc/ff/canvas.html ) aren't being recorded; and it seems like all canvases are registered with filters.  Finally, the taint tracking doesn't seem to be right (tested with https://ritter.vg/misc/ff/pixel-2.html ) - I never saw anything that had taint.

Would be able to give me suggestions on where to put this code to achieve the desired effect?

Comment 10

[François Marier [:francois]]

Comment on attachment 8983789 [details]
datareview-request.txt

Overall, that looks fine. Just two small things to fix. The first one is the description in Histograms.json (see my review in phabricator for that).

The second is in the request form:

> Measurement Description 					Data Collection Category 	Tracking Bug #
> Number of canvases a user has sen				Cat 3 Web activity data		1461764
> Number of canvases a user has seen using filters		Cat 3 Web activity data		1461764
> Number of canvases a user has seen using tainted data		Cat 3 Web activity data		1461764
> Number of canvases a user has seen using filters & tainted data	Cat 3 Web activity data		1461764

I would say that falls under Category 1: "compatibility information about features and APIs used by websites"

Once that's in place, I'll be happy to give you a datareview. I'm looking forward to seeing the data too :)

Comment 11

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: canvas-telemetry-datareview-request.txt

Comment 12

[François Marier [:francois]]

Comment on attachment 8986271 [details]
canvas-telemetry-datareview-request.txt

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes, in Histograms.json.

2) Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, telemetry setting.

3) If the request is for permanent data collection, is there someone who will monitor the data over time?**

Not permanent.

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?  **

Category 1.

5) Is the data collection request for default-on or default-off?

Default-off on release.

6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc.  See the appendix for more details)?

No.

7) Is the data collection covered by the existing Firefox privacy notice?

Yes.

8) Does there need to be a check-in in the future to determine whether to renew the data?

No, telemetry alerts are sufficient.

Comment 13

[Phabricator Automation]

Comment on attachment 8983874 [details]
Bug 1461764 Add Telemetry to track tainted/filtered canvas use r?mstange

François Marier [:francois] has approved the revision.

https://phabricator.services.mozilla.com/D1569

Comment 14

[François Marier [:francois]]

FYI, this patch has not received an actual r+, I only looked at Histograms.json. Not sure how to flag this in Phabricator...