[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tor-browser-spec/master] Bug 40003: Document the Canvas Breakage Ideas conversation from [tbb-dev]
commit 1b265d8711626b6511e8ce4a3300360d873d8da7
Author: Sanketh Menda <sanketh@xxxxxxxxx>
Date: Mon Aug 17 16:15:16 2020 -0400
Bug 40003: Document the Canvas Breakage Ideas conversation from [tbb-dev]
---
.../xxx-canvas-tainting-for-fp-resistance.txt | 134 +++++++++++++++++++++
1 file changed, 134 insertions(+)
diff --git a/proposals/ideas/xxx-canvas-tainting-for-fp-resistance.txt b/proposals/ideas/xxx-canvas-tainting-for-fp-resistance.txt
new file mode 100644
index 0000000..0c4fd17
--- /dev/null
+++ b/proposals/ideas/xxx-canvas-tainting-for-fp-resistance.txt
@@ -0,0 +1,134 @@
+Filename: xxx-canvas-tainting-for-fp-resistance.txt
+Title: Canvas Tainting for Fingerprinting Resistance
+Authors: David Fifield, Matthew Finkel, Sanketh Menda, and Tom Ritter
+Created: 21-Aug-2020
+Status: Draft
+
+1. Motivation
+
+ Canvas permissions currently break the following workflow:
+ 1. user uploads image
+ 2. website tries to display the image back to the user
+ 3. this image is white or noise (if canvas fuzzing is enabled.)
+
+ Here are some instances of this breakage:
+ 1. Uploading images to WhatsApp Web:
+ https://bugzilla.mozilla.org/show_bug.cgi?id=1631673
+ 2. Image cropping in Expensify:
+ https://bugzilla.mozilla.org/show_bug.cgi?id=1456378
+ 3. Uploading images to Craigslist:
+ https://bugzilla.mozilla.org/show_bug.cgi?id=1573834
+
+ This workflow does not seem to be invading the user's privacy so it would be
+ nice to support it. Currently, to unbreak this functionality, the user has to
+ give full canvas permissions which may be abused by websites.
+
+ This proposal specifies an approach towards allowing some use of the canvas
+ without sacrificing privacy.
+
+2. Proposal
+
+2.1 The Key Idea
+
+ Keep track of whether the canvas is safe (in terms of fingerprintability) to
+ extract or not, and allow extractions if it is safe.
+
+ This idea was first proposed by Gijs Kruitbosch [0] in analogy to canvas
+ tainting used to prevent cross-origin image loading [1].
+
+2.2 Canvas Tainting for Fingerprinting Resistance
+
+ We attach a state variable `isFPSafe` to the canvas, define three classes
+ of operations: safe, unsafe, and extraction, and when the canvas is
+ manipulated, we perform the following depending on whether the operation is
+ safe or not.
+
+ ```
+ if (safe operation) pass;
+ elif (unsafe operation) isFPSafe = false;
+ elif (extraction operation) {
+ if (isFPSafe) extract;
+ else return placeholder;
+ }
+ ```
+
+ See the canvas element section of the HTML spec [2] for details on canvas
+ operations.
+
+2.2.1 Safe Operations
+
+ - `canvas.getContext`: returns the canvas object
+ - `canvas.drawImage` for user uploaded images: draws the given image onto the
+ canvas
+
+ We hypothesize that allowing these operations unbreaks the aforementioned
+ workflow (see Research Question 1) and is safe (see Research Question 2).
+
+ These operations are also probably safe:
+ - `canvas.getContextAttributes`
+
+2.2.2 Unsafe Operations
+
+ All operations that have not been classified as safe (i.e., not listed in
+ Section 2.2.1) are considered unsafe.
+
+2.2.3 Extraction Operations
+
+ - .toDataURL`: returns a dataURL of the canvas
+ - `canvas.toBlob`: returns a blob of the canvas
+
+3. Concerns
+
+3.1 Scaling inside drawImage
+
+ The specification [3] does not specify how to scale images, so the scaling
+ algorithm may be implementation dependent and is a possible fingerprinting
+ vector.
+
+3.2 Image format encoding
+
+ The specification [4] does not specify how to do image format encoding so it
+ may be implementation dependent and is a possible fingerprinting vector.
+
+ Gómez-Boix, Laperdrix, and Baudry [3, p.314] noticed that compressing a canvas
+ to an image format adds entropy. However, in the case of user uploaded images,
+ this might be less of an issue (see Research Question 3.)
+
+3.2.1 `quality` levels
+
+ `quality` levels add another layer of uncertainty to image format encoding as
+ they are not standardized [4].
+
+3.2.1 Wide-gamut colors
+
+ This does not seem to be in the HTML standard yet but it seems like WebKit and
+ Chrome already support it so it is worth looking into (see Research Question
+ 3).
+
+ WebKit: https://github.com/whatwg/html/issues/299
+ Chrome: https://github.com/whatwg/html/issues/4167
+
+4. Research
+
+ We would like to perform experiments to answer the following questions.
+ 1. Does this approach unbreak the motivating workflow?
+ 2. Are "safe operations" (the ones listed in 2.2.1) safe against
+ fingerprinting attacks?
+ 3. How bad are issues mentioned in the concerns?
+
+5. Acknowledgements
+
+ We thank Alex Catarineu and Gijs Kruitbosch for insightful conversations,
+ and Georg Koppen for valuable comments on drafts of this document.
+
+6. References
+
+[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1631673#c8
+[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image
+[2]: https://html.spec.whatwg.org/multipage/canvas.html
+[3]: https://html.spec.whatwg.org/multipage/canvas.html#drawing-images
+[4]:
+https://html.spec.whatwg.org/multipage/canvas.html#serialising-bitmaps-to-a-file
+[5]: Hiding in the Crowd: an Analysis of the Effectiveness of Browser
+Fingerprinting at Large Scale. Gómez-Boix, Laperdrix, and Baudry. WWW '18.
+https://doi.org/10.1145/3178876.3186097
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits