Low entropy User-Agent config

[MasterInQuestion]

    Up: https://bugzilla.mozilla.org/show_bug.cgi?id=1868415#c2

    The `Accept: ,*/*` is for:
    [Outdated] [Bug] Repository deep link returned JSON
    https://github.com/orgs/community/discussions/70778
    .
    And [ https://i.redd.it/0czt1ekqww531.png ] alike:
    `Accept: text/html,*/*` coerces HTML page...
    Requires `Accept: text/html,image/*,*/*` alike.
[ ^
    (20250413)
    "image/*" seems no more working.
    However `Accept: text/*,image/*,*/*` seems to workaround...
    (unsure if it breaks other things) ]

    GitLab's "crippled" [1] design expects alike `Accept: ,*/*`...
    E.g. https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues
    .
    `Accept: */*` differed the page itself; and glitched scripts handling.
    (failed assertion on the page's content)
E/> TypeError: URL constructor: undefined is not a valid URL.
    ("vue.runtime.esm.js"#L3065c16)
    @ P ("url_utility.js"#L413)
    @ isIssuableUrlExternal ("issuable_item.vue"#L149)
    ...
[ ^
    This seems to break the whole GitLab... Woefully.
    (not necessarily the same error message, but alike cause)
    Further tested:
    https://gitlab.com/dominicp/tutanota-plain-text-bookmarklet
    https://gitlab.com/dominicp/tutanota-plain-text-bookmarklet/blob/main/README.md
    https://gitlab.com/dominicp/tutanota-plain-text-bookmarklet/blob/main/bookmarklet.js

    Might be related:
    https://gitlab.com/gitlab-org/gitlab/-/issues/407534
    https://gitlab.com/gitlab-org/gitlab/-/issues/345765
    https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=all&in=TITLE&search=Accept+header
    (so broken parameter handling...)
[1]
    Pardon the wording. Probably not really so "crippled".
    Merely quite irritated by that pointless "/-/" and clumsy search parameter handling.
    Plus the garish UI look...
[2]
    In fact the response header of GitLab even explicitly stated:
    "Vary: Accept"
    ; indicating which as even intended..?
    (but for what really?) ]

    [ ↓ Tested: 20240914; no more as of 20250413. ]
    [ https://blog.hubspot.com/ ] reported HTTP 400 Bad Request:
    When using `Accept: ,*/*` with browser-like UA.
    Workaround would be not sending User-Agent.
    Or use "*/*" with browser UA (recommended).
[ ^
    The primary reason is to reduce uniqueness of the HTTP header:
    Making that more like from typical `curl` alike.
    (alike automated traffics are actually the primary part of Internet) ]

    See also:
    [Suggestion] Request headers should not contain more than just-necessary entries
    https://forum.vivaldi.net/topic/77666

[MasterInQuestion]

    Microsoft Azure powered sites ("bing.com", "vscode.dev" etc.) might block Firefox User-Agent without plausible "Gecko/" value:
    Precisely, not very plausible /Gecko\/(\d{8}|\d{2,3}\.\d\s)/i:
    Where $1 cannot exceed "20100101"; or is "999.9 " like [1].

[ [1]
    Per the mobile UA, e.g.
    Mozilla/5.0 (Android 10; Mobile; rv:122.0) Gecko/122.0 Firefox/122.0 ]

[[
* [HTTP/2] [1] OPENED stream for https://vscode.dev/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: vscode.dev]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: (Linux; rv:999) Firefox 999]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [accept-encoding: deflate, gzip]
} [5 bytes data]
> GET / HTTP/2
> Host: vscode.dev
> User-Agent: (Linux; rv:999) Firefox 999
> Accept: */*
> Accept-Encoding: deflate, gzip
>
{ [5 bytes data]
* received GOAWAY, error=0, last_stream=2147483647
{ [5 bytes data]
< HTTP/2 403
< x-azure-ref: 0yyt7ZQAAAADQ6UatO6+gSpAA7Y1YRS8iSEtCRURHRTA3MTYANGM0ZDljZjEtNzZhMy00NjRhLThhODgtNTVmNzNiMDk4Mzdl
< date: Thu, 14 Dec 2023 16:22:34 GMT
<
{ [882 bytes data]
* Closing connection
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, close notify (256):
} [2 bytes data]
]]
    Sending no User-Agent works though...

[MasterInQuestion]

    Twitter expects "Firefox/999" alike.
[[
* [HTTP/2] [1] OPENED stream for https://twitter.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: twitter.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: (Linux; rv:999) Gecko/20100101 Firefox 999]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [accept-encoding: deflate, gzip]
} [5 bytes data]
> GET / HTTP/2
> Host: twitter.com
> User-Agent: (Linux; rv:999) Gecko/20100101 Firefox 999
> Accept: */*
> Accept-Encoding: deflate, gzip
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/2 400
< date: Fri, 15 Dec 2023 01:57:54 GMT
...
    <h1>This browser is no longer supported.</h1>
]]

[MasterInQuestion]

    SiteGround asserts Firefox User-Agent beginning with "Mozilla/"i...
[[
* [HTTP/2] [1] OPENED stream for https://www.siteground.com/blog/brotli-compression
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.siteground.com]
* [HTTP/2] [1] [:path: /blog/brotli-compression]
* [HTTP/2] [1] [user-agent: (Linux; rv:999) Gecko/20100101 Firefox/999]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [accept-encoding: deflate, gzip]
} [5 bytes data]
> GET /blog/brotli-compression HTTP/2
> Host: www.siteground.com
> User-Agent: (Linux; rv:999) Gecko/20100101 Firefox/999
> Accept: */*
> Accept-Encoding: deflate, gzip
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [251 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [251 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/2 403
< server: nginx
< date: Sat, 16 Dec 2023 11:39:00 GMT
< content-type: text/html
< vary: Accept-Encoding
< etag: W/"655b1984-125b9"
< host-header: 8441280b0c35cbc1147f8ba998a563a7
< x-proxy-cache-info: DT:1
< content-encoding: gzip
< via: 1.1 google
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
<
{ [6535 bytes data]
* Connection #0 to host www.siteground.com left intact
]]
    Again, no User-Agent works.

[MasterInQuestion]

    Though discouraged, many sites still rely on User-Agent parsing...
    The currently used:
[[

-Mozilla/5.0 (Linux; rv:999) Gecko/20100101 Firefox/999
+Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

]]
; is already not much different from the regular one.

    Comparing Tor User-Agent:
https://old.reddit.com/r/firefox/comments/18ieem9?sort=old
[[
= Low entropy User-Agent config =
+    https://github.com/MasterInQuestion/talk/discussions/10

    Seeking applicability feedback on mass deployment.
    Thanks in advance.

[ MasterQuestionable @ CE 2023-12-16 12:44:22 UTC:
https://old.reddit.com/r/firefox/comments/18ieem9?sort=old#kderfhw
    Unable to change title, it appears.
    Latest version: Mozilla/5.0 (Linux; rv:999) Gecko/20100101 Firefox/999 ]

@ CE 2025-04-11:
    It works. More reliable than past Tor User-Agent.
    https://unix.stackexchange.com/questions/744795/how-are-some-websites-able-to-detect-on-which-os-i-am-running-the-tor-browser
    https://github.com/TeamNewPipe/NewPipe/issues/3136#issuecomment-905922408
    https://github.com/TeamNewPipe/NewPipe/commit/1193b02ca136080edeab89d71039db3092a7a91b
    https://www.browserling.com/tor-testing
    [ ^ Mozilla/5.0 (Windows NT 10.0; rv:109.0) Gecko/20100101 Firefox/115.0 ]
    https://www.google.com/search?hl=en&gl=ca&num=10&q=Tor+User-Agent

    See also:
    https://github.com/webcompat/web-bugs/issues/139311#issuecomment-2576865367
    https://github.com/MasterInQuestion/ShellUtils/commit/34910eb5ca7ff55f02d337f46aa75c031277ec66
]]