Fingerprint surface coming from MediaRecorder-able types - needs consideration?

[stefhak]

From https://lists.w3.org/Archives/Public/public-media-capture/2018Feb/0005.html

Current specification and implementation also adds an isTypeSupported method which provides drive-by fingerprinting surface, not currently constrained by user permissions or interaction. The current draft of our Mitigating Browser Fingerprinting guidance may be helpful: https://w3c.github.io/fingerprinting-guidance/

[yellowdoge]

I don't think isTypeSupported() increases the fingerprinting: the set of supported profiles is small and has few differences among OSes; it probably never changes among users. E.g. the implementation status shows which video codecs are implemented in Chrome per platform (there are just a few because Chrome must provide a software fallback in case any hardware-accelerated fail -- this also means that it's not possible for a user to identify those codecs that are hardware accelerated). A malicious site could perhaps infer the OS/platform but that information is already in the User Agent string.

Should this analysis be added to the text?

[yellowdoge]

@npdoty

[npdoty]

If the data returned by isTypeSupported won't vary between implementations, or there's some assurance that a particular OS/UA implementation won't have variations inside of it, then that would affect the fingerprintability and I do think that's worth documenting in the specification.

The implementation status page you point to specifically notes that the supported values currently differ based on the chipset (ARM or Intel) in Chrome and link to bugs that suggest that the values will differ based on the particular chipset (chipsets that support VP9). Am I reading those tables/bugs correctly? That may be feature detection that's intended for this functionality, but I think we should not claim that there is no variation or information disclosure if that variation is present or planned.

[npdoty]

Currently, the first example in the specification demonstrates how to enumerate the list of supported codec/container combinations in the user's browser: https://w3c.github.io/mediacapture-record/#example1

I don't think you want to recommend doing this kind of enumeration, as it's a particular example of what a site would do in order to fingerprint a user's device rather than detect a capability in order to provide functionality. Some browsers might want to limit the number of successive isTypeSupported calls to limit disclosure.

[yellowdoge]

The implementation status page you point to specifically notes that the supported values currently differ based on the chipset (ARM or Intel) in Chrome and link to bugs that suggest that the values will differ based on the particular chipset (chipsets that support VP9). Am I reading those tables/bugs correctly?

Those are informational for developers but they are not offered to the JS, i.e. a hardware accelerated version is only supported if and where there's a software fallback, and a positive response to isTypeSupported() is not enough to differentiate among them. In due time we should have wired all possible accelerated encoders, which should be transparent to the users, beyond a nice speed increase / power consumption decrease :-)

[npdoty]

Those are informational for developers but they are not offered to the JS, i.e. a hardware accelerated version is only supported if and where there's a software fallback, and a positive response to isTypeSupported() is not enough to differentiate among them.

Is that intended to be a requirement? If so, that would definitely mitigate privacy concerns about easily detecting hardware properties, but I don't see a requirement in the spec that the list of types supported not be dependent on hardware encoding capability. Is it just Chrome's specific policy that new codecs/types are not supported in the UA unless software encoding is available for all platforms?

[yellowdoge]

Is it just Chrome's specific policy

Yeah hardware accelerated encoders (and decoders, for the case) can fail to initialize/process for a variety of reasons (e.g. a minimu/maximum resolution), so there's always the need for a sw fallback. Note that this is a requirement per platform, i.e. Android/CrOs/Linux/Win/Mac.

[guest271314]

@guest271314 feel free to add to issue #142 if you have comments on the privacy impacts of isTypeSupported.

@npdoty

https://github.com/w3c/mediacapture-record/issues/196#issuecomment-650791762

AFAICT there are no privacy and security considerations re "fingerprinting" and isTypeSupported().

What would an individual or institution do with that information?

[guest271314]

The only information of value that isTypeSupported() can conceivably provide is whether the browser is , for example, Firefox or Chromium or Chrome, which can be determined by various means without executing MediaRecorder.isTypeSupported(), including simply recording a very brief MediaStream with MediaRecorder (no permissions required) and checking if the resulting media file has a duration, where Chrome and Chromium produce media files that do not have a duration.

It can be reasonably concluded that Mozilla browsers will not support h264 or avc1 in a WebM container per https://bugs.chromium.org/p/chromium/issues/detail?id=980822. However, Firefox might, in the future, support FLAC in WebM https://bugzilla.mozilla.org/show_bug.cgi?id=1606822.

Until the specific "Fingerprint surface" vector is clearly described am not certain precisely what the issue is with isTypeSupported()?

[npdoty]

It seems trivial to conceive of isTypeSupported providing more information than the user agent vendor: for example, if an implementer made support of different types dependent on the underlying codecs that have hardware acceleration based on the device.

If type support will never depend on hardware details or user agent software versions, then this spec could provide requirements to that effect and the fingerprinting surface would be minimized.

[guest271314]

@npdoty

Perhaps you did not understand the question that was asked.

Precisely what is "the fingerprinting surface"?

Discovery of hardware capabilities navigator.hardwareConcurrency, navigator.connection, navigator.userAgentData.mobile, navigator.hid, navigator.deviceMemory, navigator.getBattery().then(console.log), navigator.languages?

How is isTypeSupported() different from

navigator.mediaCapabilities.encodingInfo({
    type : 'record',
    video : {bitrate:120000, height: 1080, width: 1920, framerate:30, contentType : "video/x-matroska;codecs=avc1"}
}).then(console.log)

?

What is the exact action an individual or institution can do with the information provided by isTypeSupported()?

[guest271314]

@npdoty As am sure you are aware, any and all mobile devices are a "fingerprint surface" itself, thus making any concern about "privacy" on a mobile device nonsensical, as no such notion exists - without rooting the device and changing practically all of the "features" implemented by default.

[npdoty]

For those who feel any concern about "privacy" is nonsensical, it's likely that issues raised in a privacy review may not be of interest. It may not be worth our time to discuss.

[guest271314]

@npdoty The fundamental objection is wanton use of the term "privacy" without accompanying primary source definition. As of 1999 it was possible to analyze 20TB of data per second in "real-time" http://agoodamerican.org/ . WebRTC exposes IP addresses. MediaStreamTrack from getDisplayMedia() is set to mute with non-action by user https://github.com/w3c/mediacapture-screen-share/issues/141.

The interwebs were not designed to be secure and are not secure right now, so the term "privacy" relevant to web platform applications is not applicable - unless you can provide a reproducible use case where any web or device usage is absolutely "private", e.g., from a random article https://appleinsider.com/articles/20/01/14/the-fbi-has-the-tools-it-ne, https://www.wired.com/2016/09/heres-fbi-hacked-san-bernardino-shooters-iphone/.

If we are really discussing "privacy" then we need to be honest about the fact that all signal communications can be intercepted.

What is nonsensical is to not begin with the premise there is no such thing as "privacy" relevant to web platform applications, and from there try to mitigate exposure, if that is important.

This document does not attempt to provide a single unifying definition of "privacy"

is a glaring omission. Essentially from such a starting position, since "privacy" is not clearly defined, there is no way to test any theory that any mitigation efforts are successful or failures, giving rise to this fundamental question:

How to reproduce "privacy" using the scientific method, by any means?

[guest271314]

@npdoty Will take the time to emphasize your efforts are meaningful. Am simply not equipped with the faculty to ignore acts or omissions.

Occasionally, under the guise of "security" and "privacy" unintended consequences might occur. Consider this PR https://github.com/w3c/picture-in-picture/pull/186/commits/fd0615bc7ce6fee6f9e71a241febf4095f49ecf1 where the actual use case had nothing to do with "privacy" or "security"

From a security and usability perspective, I believe we should keep the minimum window size.

Am not sure how "security" is involved at all, can you indicate how?

If maintaining a minimum PiP window size is a sticking point, keeping that recommendation would be a viable compromise that all parties should be able to move forward in agreement on. The main issue is restricting maximum PiP window size.

rather, a workaround for the then-bug where Chromium could crash if the pixel dimensions of the video track changed mid-stream, proposed to remove minimum and maximum recommendation from the specification, which Chrome, Chromium implement.

The ironic unintended consequence is that the screen is "fingerprint surface" by maximizing the PiP window to get maximum screen capabilities, if not accessible otherwise, which the value is, similar to isTypeSupported() result being accessed by navigator.mediaCapabilities.encodingInfo().

FWIW Am all for anything you are capable of doing to mitigate "fingerprint surface" though will certainly raise questions relevant to how to verify any theory of "privacy" on the interwebs, given the web platform continues to add more "features" that by necessity rely on existing API's which might not have been designed for the application, or new "features" which could expose the same values another API just deprecated. If you are able to manage all of those variables, then, yes, do whatever you can. Just do not tell me that because of your efforts "privacy" has been affected, as no user should have any expectation of "privacy" on the interwebs, as they have no way to verify that state in "real-time" - without potentially exposing said "privacy", if achieved, in the process. Best, /guest271314/

[guest271314]

Re

As am sure you are aware, any and all mobile devices are a "fingerprint surface" itself, thus making any concern about "privacy" on a mobile device nonsensical

There is a portion of the bail hearing in this matter https://www.youtube.com/watch?v=n7zL1l8YcG0, from yesterday, June 30, 2020, where Defendants' attorneys agree to not attempt to remotely "wipe" the cellular phone of Defendant.

The device is in the custody of the State.

And presumably is turned off. And does not have a battery installed.

Yet, the State is still concerned enough about the capability to remotely "wipe" the device that the State made sure to get a clear agreement from Defendants' attorneys to not try to "wipe" the device.

The implication being that at any given time the device can be accessed remotely, potentially without the user of the device even knowing that is occurring.

[jan-ivar]

I think the better argument here is that isTypeSupported reveals no information beyond the inherent functionality exposed. I.e. easily polyfilled by attempting to record to a list of different mime types, and seeing which fail.

So the only mitigation would be to narrow what types can be recorded, and https://github.com/w3c/mediacapture-record/pull/165 seems to address this.

Can we close this since https://github.com/w3c/mediacapture-record/pull/165 was merged and https://github.com/w3c/mediacapture-record/issues/196 opened to cover the remaining issues?

[youennf]

isTypeSupported can be shimed, it is also somehow redundant with media capabilities API. Should we deprecate it?

[guest271314]

Why deprecate isTypeSupported()?

So far have not viewed any examples of how the information returned by the method could be used to do anything.

[jan-ivar]

isTypeSupported can be shimed, it is also somehow redundant with media capabilities API.

Must MediaRecorder support all encodings returned by the media capabilities API?

I'm not opposed to deprecating isTypeSupported but not seeing what that solves either wrt this issue.

[guest271314]

but not seeing what that solves either wrt this issue.

Have yet to see, here, in this issue, precisely how isTypeSupported() is a security issue whatsoever.

Is this somehow different that MediaSource.isTypeSupported(), or querying all of the methods defined at navigator?

Can a clear case of use of isTypeSupported() adversely impacting the user be demonstrated?