Re: [mediacapture-record] Fingerprint surface coming from 'isTypeSupported' - needs consideration? (#142)

@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 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/

GitHub Notification of comment by guest271314
Please view or discuss this issue at using your GitHub account

Received on Sunday, 28 June 2020 21:46:19 UTC