Especially, canvas would become useless in an opt-in scenario and would just foster permission fatigue (people just clicking "Allow" because it makes those dialogs go away).
Another option might be to define closely (pixel-by-pixel) how a canvas should look like after a specific action. That way vendors would have less room for 'their way' of drawing things but the result would look equal and would be useless for fingerprinting.
Similarly, one could define a list of fonts which every browser should bring and all other fonts should be loaded from a server. It would eliminate the 'you have special fonts installed' problem completely.
The canvas wouldn’t be opt in, only the pixel reading feature would be - and that’s an edge case that I can’t imagine being used in even one in a thousand uses of Canvas. Just drawing to a canvas has no privacy implications and covers almost all uses.
There's many amazing things only possible in canvas because you can read the pixels directly (especially in displaying complex pixel art), so removing that capability out-right would be highly disappointing.
I suppose a better solution would be to mark the canvas as tainted if any text is drawn onto it, so that pixel reading capabilities are blocked. Another aggressive solution could be to redraw the entire canvas without gpu acceleration if pixel data is requested. Together these would severely limit canvas fingerprinting.
Or just block it and display a warning that the user can accept before the operation is allowed. And as you say: all canvas impls should come in 2 flavors, one “reference” software impl that guarantees the exact same pixels given the exact same operations. Using any other impl should block readpixel or redraw with the reference impl before reading.
I realize there are edge use cases that need reading a pixel I just don’t agree with the idea that they would more important than limiting tracking. So I think the canvas limiting mode (used in ff safe mode) should be default.
