Total Tracking Protection

[MasterInQuestion]

[ Master ? @ CE 2023-12-14 23:51:58 UTC:
https://bugzilla.mozilla.org/show_bug.cgi?id=1870172#c0
    Extends:
    https://bugzilla.mozilla.org/show_bug.cgi?id=736373#c30
    https://bugzilla.mozilla.org/show_bug.cgi?id=1746668#c25
    Enhanced Tracking Protection
    Total Cookie Protection
    ...

    Measures to enhance privacy cannot be considered separately.
    Elements are each other coupled and constitute a blob of whole that may contain unawarely implications.

    I'll conduct a through review of every interface available during web browsing:
    Analyzing the actual use of them, and how will each change influence functionalities dependent.
    There devise a full-scale defense against every possible dimension that may be utilized to deploy fingerprinting:
    Meanwhile being practical for deployment as Firefox default.

    In brief, the goal is:
    To make standard Firefox leak nothing, nor break anything. ]

[MasterInQuestion]

=== Font visibility ===

    The remote site doesn't really need to know whether the client supports particular fonts or not, most of the time.
    Therefore, it's plausible to make the browser unconditionally report "supported" (or "unsupported") for arbitrary font availability query.
    (meanwhile still making use of the requested fonts, without revealing anything)

    Proposed:
    Asserting "unsupported" for any font query by default; configurable option per site:
    3 options:
    |1| Assert "unsupported"
    |2| Assert "supported"
    |3| Expose font availability

    Rationale:
    "unsupported" may eventually fallback to remote fonts, if it's really important.
    "supported" may at times be more desirable; but may fail seriously.
    Expose availability for fringe case optimization.

    This is actually part of the # Unintended remote accessible.


=== Screen size ===

    Contrived before # Unintended remote accessible.
    In brief, asserting 1920x1080 or 1080x1920 (based on if width > height) should adequately work for most cases. (without significant breakage)

    Rationale:
    Most videos filmed are of 16:9 SAR (1920x1080 scalable).
    While they still play reasonably well on various screen sizes.


=== Canvas fingerprinting ===

    Background:
    The ...


=== Unintended remote accessible (WebGL, screen size, input actions etc.) ===

    Certain variables (and their interpolation) are not supposed to be reported to the remote end:
    They by design should be only used locally.
    A sanity check for such variables should be implemented in the JavaScript engine:
    Allowing only those of valid use to be sent to remote.

==== Implementation details ====

    Regulate every interface that may initiate remote connection.
    (XMLHttpRequest, HTML "src" attribute of various elements, "<form>" submit, CSS "url", JavaScript "window.open", etc.)
    This requires recording how each variable was generated: i.e. what sensitive variables involved. [1]

    The change would potentially cause a performance penalty of generally less than 15%.
    Whatsoever the AngularJS, React, jQuery etc. JavaScript on JavaScript frameworks, which typically have performance overhead over 50%: regardless widespread.

[ [1]
    If it's just to block everything potentially sensitive: knowing what sensitives involved alone would suffice.

    To allow some of them pass through (via the prompt) meanwhile automatically reject the rest that have no valid use (via continuing with neutered value):
    A full stack trace for such variables might be needed (so to reverse the change and recompute the neutered value).
    .
    Outright rejecting everything only involves the unintended remote accessible of course works, and requires no stack trace:
    But that may be more inclined to breakage. (perhaps using a content filter to replace the offending codes would be more appropriate solution)

    This may cause beyond expectation performance cost. ]

==== Caveats ====

    For those need to be sent to remote [1]: prompt the user what would be sent. (similar to what attained in the Dev console)
[[
    The remote connection contains variable interpolated from potentially sensitive device information:
    | Involved sensitive | Value |
    | ...
    Continue anyway?

    IF ( repeated offense ):
    [ ] Blacklist the site from making such requests. (which can be later reconfigured in "Site permissions")
]]

[ [1]
    Very few of them have plausible use, as far as I've fathomed:
    |1| Canvas "toDataURL" [ Google's feedback functionality relied to take screenshot. And potentially of use to web-based image editors? ]
    |2| Selection related API [ Some forums' reply to selection. ]
    |3| Localized time [ Potentially used by text editors to insert time then save file to remote?.. ] ]


=== WebRTC ===

    ...


=== Request header ===

    See:
    https://github.com/MasterInQuestion/talk/discussions/10


=== TLS fingerprint ===

    ...


=== DoH (DNS over HTTPS) ===

    ...