Make sure MediaError.message does not aid to fingerprinting
MediaError got a new property message that might contain system information, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1322606 and https://github.com/mdn/dom-examples/blob/master/media/mediaerror/main.js.
We should find out whether that's the case and if so probably just remove that part.
Activity
A MediaError object contains a single field, MediaError.code, with one of four possible values:
Name Val Description MEDIA_ERR_ABORTED 1 The fetching of the associated resource was aborted by the user's request. MEDIA_ERR_NETWORK 2 Some kind of network error occurred which prevented the media from being successfully fetched, despite having previously been available. MEDIA_ERR_DECODE 3 Despite having previously been determined to be usable, an error occurred while trying to decode the media resource, resulting in an error. MEDIA_ERR_SRC_NOT_SUPPORTED 4 The associated resource or media provider object (such as a MediaStream has been found to be unsuitable.Checking for a MEDIA_ERR_DECODE or MEDIA_ERR_SRC_NOT_SUPPORTED error in principle might say something about the user's codecs. On the other hand, there are other very easy ways to test whether a Media Element is playing or not, so I'm not sure we are providing much additional protection by hiding these error codes. We would be wise to ensure that the available codecs are standardized for Tor Browser for each platform (Linux, Mac, Windows, Android).
Setting as review to see if my colleagues agree or disagree.
Trac:
Keywords: N/A deleted, TorBrowserTeam201704R added
Status: new to needs_review
Replying to arthuredelstein:
A MediaError object contains a single field, MediaError.code, with one of four possible values: ...
What about the
messagefield? Is it always an empty string?Replying to mcs:
Replying to arthuredelstein:
A MediaError object contains a single field, MediaError.code, with one of four possible values: ...
What about the
messagefield? Is it always an empty string?Ugh, it seems I somehow got confused -- I realize now the main concern of this ticket is the message property, not the code property. I'll look into the message property.
I did a lot of exploration of the code that generates MediaError.messages. I didn't find any that seemed likely to reveal any system information. On the other hand, I may have missed a case, and I can imagine more privacy-violating messages might be introduced in the future. So, to be safe, I wrote a patch that censors any messages when "privacy.resistFingerprinting" is enabled:
https://github.com/arthuredelstein/tor-browser/commit/21792
Trac:
Status: accepted to needs_review
Keywords: TorBrowserTeam201704 deleted, TorBrowserTeam201704R addedReplying to arthuredelstein:
Checking for a MEDIA_ERR_DECODE or MEDIA_ERR_SRC_NOT_SUPPORTED error in principle might say something about the user's codecs. 7.0a3 ends up with
[...] Error playing media: MediaError { code: 4, message: "" } jwplayer.js:4:291for any media, blocked by NoScript.
messagefield looks like human-readable description ofcodefield (not implemented by jwplayer yet?).
Replying to mcs:
Your patch looks okay, although it would be safer to return an empty string in aResult in the
privacy.resistFingerprinting = truecase.I agree. Could you please change that, Arthur?
Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201705R deleted, TorBrowserTeam201705 addedReplying to gk:
Replying to mcs:
Your patch looks okay, although it would be safer to return an empty string in aResult in the
privacy.resistFingerprinting = truecase.I agree. Could you please change that, Arthur?
Yes, good point. Here is the changed patch: https://github.com/arthuredelstein/tor-browser/commit/21792+1
Trac:
Keywords: TorBrowserTeam201705 deleted, TorBrowserTeam201705R added
Status: needs_revision to needs_review-
Replying to arthuredelstein:
Yes, good point. Here is the changed patch: https://github.com/arthuredelstein/tor-browser/commit/21792+1
r=brade, r=mcs Looks good.