Do you really believe a Whonix DispVM with JS enabled (which is the default because it actually keeps your fingerprint less unique: Qubes Disposables) will learn your identity just by enabling JS on that one site? I have difficulty imagining that, NSA are not gods.
“In the stock Tor Browser configuration, JavaScript is enabled by default for greater usability.”
Did you read the Wiki page I linked?
A decision must be made in advance whether to disable JavaScript by default. There is a usability-security trade-off to consider: fingerprinting and usability is worsened by disabled JavaScript, but this provides better protection against vulnerabilities. Conversely, enabled JavaScript improves usability and increases the risk of exploitation, but the browser fingerprint is (likely) more common.
Security vulnerabilities likely don’t concern us in DispVMs, so better to have less unique fingerprint.
Did you read the Wiki page I linked?
The quote I provided is from a link from that same page (which you now provide back to me).
You asked:
Do you really believe […] NSA are not gods.
This is not about religious belief but about technical possibility. Having JS enabled does not reduce (or increase) your fingerprint per se. It reduces the possibility for more accurate fingerprinting, as JS can measure much more of your system (and your browsing behaviour). Whether you trust the remote host (part of the distrusted infrastructure) will use that possibility or not is up to you.
Compare these cases:
(A) JS enabled - you are “less unique” and the remote host can detect your OS, browser resolution, profile your moves, etc. How do you think Google Analytics, Hotjar and the like work?
(B) JS disabled - you are “more unique” and the remote host cannot do any of the above. The only “extra info” it has about you is that you refuse to provide that additional data. Bonus: you are immune to potential new Spectre-like vulnerabilities.
Anyway, this is going off-topic, so either request a thread split or we better stop.
WIth pure HTML/CSS, no JS required, you can still mine at least:
Examples:
In the future, JS will likely become less-and-less essential for tracking, and thinking that by disabling JS you thwart these attempts is just wishful thinking.
I personally use Tor Browser often, and am surprised how well most websites behave without JS, even cookie notices can be interactively clicked on, and even ads often load, which was rarely the case some years ago. This further solidifies my belief that disabling JS doesn’t really do all that much to prevent tracking.
Out of curiosity, how is this data exported back to the tracker without javascript?
WIth pure HTML/CSS, no JS required, you can still mine at least:
- fonts installed
- pointer type (mouse/touchscreen)
- inner screen size (via @media queries)
- mouse movements!
Examples:
GitHub - OliverBrotchie/CSS-Fingerprint: Pure CSS device fingerprinting.
Also mentioned in the filters of quBO. Yes, CSS is also a vector.
This one doesn’t work without JS - a Catch 22.
In the future, JS will likely become less-and-less essential for tracking, and thinking that by disabling JS you thwart these attempts is just wishful thinking.
I can’t predict the future. As of today, JS’s capabilities are bigger.
I personally use Tor Browser often, and am surprised how well most websites behave without JS, even cookie notices can be interactively clicked on, and even ads often load, which was rarely the case some years ago. This further solidifies my belief that disabling JS doesn’t really do all that much to prevent tracking.
You can do some generic testing in https://coveryourtracks.eff.org.
Since recently, it is no longer possible to report a new issue and even to view comments in issues without JS. In Tor browser one must even reduce “Security Level” from “Safest” to “Safer” to make this work.
You could use gh issue create or gh issue view ##### -c for CLI
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Is this still true in 2025?
Really?
How do you setup a functional Github account without JS in 2025?
Presume Confused 
Example: MAC Randomization Is Flawed: Proposed New Solution - #3 by grandbronze111 please link this thread in the GitHub issue, as I can’t post due to account being created with Tor.
Your expertise @unman could be helpful
There might be a way to use GitHub over Tor but I’ve had multiple accounts shadow banned recently.
I just read this post and saw @unman offer to relay issues to GitHub.
Can you please post MAC Randomization Is Flawed: Proposed New Solution - #4 by grandbronze111 to MAC Randomization for iwlwifi · Issue #938 · QubesOS/qubes-issues · GitHub
You could use
gh issue createorgh issue view ##### -cfor CLI
Yes but:
gh won’t work. This means the Qubes community will loose contributors who value privacy more than contributionsYour words from the parent thread:
More people ready to make a contribution would be a good thing
The core team does not provide any barrier to entry, in terms of making
a contribution to Qubes.
Qubes OS does not have much users, but a large part of them want to remain anonymous, some of them certainly don’t want to contribute back for privacy reasons
I understand GitHub is a free beer but far smaller and less funded FOSS projects use non-privacy-invasive source hosting, bug trackers and discussion platforms.
I would not describe it as a partial workround - it resolves the issue.
And for some users gh provides less of a usability burden: I include
myself.
Yes, if MS blocks Tor tomorrow, then Tor users would be blocked. If they
wish to contribute they will find a way.
I do not know if JS is required for account creation in 2025 - Last time
this was claimed it was not true. Perhaps someone could check this
instead of asking.
I use GH exclusively over Tor without JS. My offer still stands - if
anyone wants to contribute without an account I am happy to proxy for
them.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I would not describe it as a partial workround - it resolves the issue.
It does not resolve the overall issue of using a well-known PRISM company for source code hosting and exposing the whole community to it.
And for some users
ghprovides less of a usability burden: I include
myself.
OK but that is a tiny minority.
Yes, if MS blocks Tor tomorrow, then Tor users would be blocked. If they
wish to contribute they will find a way.
What if they don’t want to contribute and don’t have a GitHub account but are only given a link to an issue?
user@host:~ > gh issue view https://github.com/QubesOS/qubes-issues/issues/858
To get started with GitHub CLI, please run: gh auth login
Alternatively, populate the GH_TOKEN environment variable with a GitHub API authentication token.
I do not know if JS is required for account creation in 2025 - Last time
this was claimed it was not true. Perhaps someone could check this
instead of asking.
That has been checked and confirmed earlier in this discussion.
I use GH exclusively over Tor without JS. My offer still stands - if
anyone wants to contribute without an account I am happy to proxy for
them.
We discussed that too.
@unman does this offer not apply to me? I’ve asked in this thread if you could please relay my post and it was ignored. I’ve also been asking for multiple days in another post and, despite many users expressing interest in seeing my solution implemented, nobody at Qubes is taking my issue seriously.
What on Earth is going on over at Qubes? Why is it so hard for me to contribute to this project? I really don’t get it.
I don’t know if this has changed but IME GitHub has always been quite reasonable about un-banning. It never took me more than dropping them a short message over the contact form saying essentially “your spam filter made an obvious mistake” and a few hours later: account restored.
In contrast, the gitlab.com instance of GitLab has been nothing but pain for me over Tor. I dread even just trying to get CI build results to load, let alone being allowed to log in.
So I am not alone. At least they load. codecov.io reports are entirely blocked if visited via Tor.
hey there, obviously we/i can post your post over at github but i feel like it’s not very sustainable, no? like someone responds and then you have no way of responding… maybe try what rustybird suggested to get your github account un-shadowbanned first?
since the whole history of the topic is in that github issue it would certainly be nice to be able to have the conversation there rather than split between there and a forum thread.
if it’s really not successful after a couple days then i can make the post for you and direct folks to discuss in the forum thread.
I can’t contact support without verifying phone number, even with 2FA enabled as someone else suggested.
ok, just so you know there is also the qubes-devel mailing list – github and that mailing list are the two official places where development & contributions happen.
so maybe for you it would be easiest to start a thread on the mailing list citing the github issue? then you can have smooth & easy conversation, share patches/contributions, etc.
and i can link to the post & the mailing list thread in the github issue so that everything is connected.
