And then you can’t prevent mouse fingerprinting, so what’s the use then?
That is why I never registered with GitHub. There is a saying: you can’t fuck without getting it in.
3 Likes
I guess unman is not anonymous but pseudonymous, which does allow to build trust by spreading the public key over his messages around the web. It seems to me it’s done well and the trust is there in this particular case, just like with Qubes OS itself. If somebody is truly anonymous, I can’t imagine how to build any trust indeed.
3 Likes
Ideally there shouldn’t be any need for trust. That’s the point of open source vs proprietary code. But qubist made a good point that a middle man like alzer could be banned from github if they find out he is opening and managing accounts for other people as a proxy, so he needs to know the developer is not going to snitch to github.
2 Likes
I don’t think that a complete lack of trust is realistic, even with FLOSS. Nobody can verify millions of lines of code running on their computers, not even if you regularly pay to somebody for such verification. Trust is a way to decrease your work in reading the code, which helps a lot in saving your time and resources. It’s an additional, useful mechanism on top of the community verification.
2 Likes
Thanks.
As to “I have explained what I mean”, @qubist stated his opinion as fact. I
think it not true because there are many examples of trust between people
who are not known to each other. (I do not speak for “entities”)
Building a resistance movement through isolated cells is an example of
this. Of course that trust can be misplaced, but so it can with people
who are known to each other.
But this is far removed from the stated issue in this thread.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
I, like many others, am prepared to take that. It used to a
part of onboarding at a company I worked for, and I imagine it’s
relatively common.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
2 Likes
I guess unman is not anonymous but pseudonymous, which does allow to build trust by spreading the public key over his messages around the web. It seems to me it’s done well and the trust is there in this particular case, just like with Qubes OS itself.
You are making this personal. I am trying to illustrate a principle. - It doesn’t matter who your proxy is and how reputed he is. Nice guys also get hacked, monitored, laptops get stolen etc. What matters is what the consequences of exposing your identity are.
Validating the key for the Qubes ISO is different - the project is not anonymous and validating the key does not require to establish communication with a specific entity.
3 Likes
As to “I have explained what I mean”, @qubist stated his opinion as fact.
I just gave a few examples. That is not an opinion.
I think it not true because there are many examples of trust between people
who are not known to each other. (I do not speak for “entities”)
There are also factual examples of such people successfully being targeted and suffering the consequences, so it is not really “simply false” as you say. Not only it is true, but thanks to the marvelous technology targeting through the infrastructure is becoming more and more AIfficient.
Of course that trust can be misplaced, but so it can with people
who are known to each other.
Exactly. That’s why I say it is not that simple. Life > computers.
BTW, regarding your earlier “at no cost” - if these figures are what the project receives as funds, I don’t understand the “no cost” requirement as a factor for not self-hosting, even for a dedicated one:
https://www.leaseweb.com/en/products-services/dedicated-servers
1 Like
In regards to proxying, here is an idea which just came to my mind.
Bug reporting:
A simple web form on qubes-os.org - no registration required, onion domain already available. The backend can use an internal GitHub account and a script will submit the request through gh.
Issue reading:
An even simpler web form where the user enters the GitHub issue URL, the backend script fetches the whole issue (again using a service account) and displays it. Similarly - the user remains anonymous.
Code submissions:
I have not done it so far, so I am not familiar with the details but since gh can do that too, it should be no problem to have a similar web interface.
If some limits exist on GitHub (e.g. number of submissions/requests per user account), a few backend accounts can be used and auto-switched by the backend.
To protect the web forms from flooding, a static-image captcha can be used.
None of this requires any personal data, peer-to-peer communication or trust (assuming no Cloudflare or other decrypting MITM is used), and is possible to implement without JS or CSS. It also does not need a particular person to be burdened with registering accounts for others.
All this has the disadvantage of not getting email notifications (e.g. about replies or other events). Perhaps it is possible to have the backend generate RSS feeds URLS to which the backend will respond with proper content (fetched through gh) upon HTTP request. Then, the anonymous user can subscribe and refresh the URL periodically. To reply to an update, one can use a web form again.
I do not claim this is a solution but it is a simple and possible workaround until an alternative is implemented.
4 Likes
I thought that you were against this kind of workaround… So I misunderstood what you said, and I fully agree with your conclusions. As for “Issue reading”, the github API seems to be accessible without account (but with a rate limit). See that script from @alimirjamali as an example:
(or as a raw file: https://raw.githubusercontent.com/alimirjamali/personal-qubesos/refs/heads/main/Infrastructure/qubes-issues-tt)
I believe that captchas are not accessible (and maybe useless?) that’s why I proposed manual reviewing in order to limit the potential flooding. Some kind of rate limit could be better. Like, if there are more than X forms completed in a certain period of time, then a manual review is needed, etc.
2 Likes
Oh. Yes. That is correct. I use that script to randomly look at e.g. 6 issues at a time (like rolling dice), then I try to solve them if I find them interesting. This way I have found many neglected or forgotten issues, sometimes already solved or very easy to solve. I do not use it a lot these days as I left “good first issues” for the 1st time contributors, more focusing on medium sized projects personally.
I believe Github already publishes a CLI tool for advanced issue management but I am not certain. Something which could be easily piped via Tor and would totally eliminate requirement for mouse. Maybe it was already mentioned in this now very long thread.
3 Likes
I thought that you were against this kind of workaround…
Was it proposed earlier?
As for “Issue reading”, the github API seems to be accessible without account (but with a rate limit).
Is it necessary to do it without an account, assuming that service accounts will be available in the backend anyway?
I believe that captchas are not accessible (and maybe useless?)
Why?
manual reviewing
would require human resources. Currently there is no manual reviewing before an issue is created.
1 Like
Yes, but not as clearly as you did.
That’s just an idea on how to start, reading issues seems to be the easier part.
As for captcha, obviously an image is not accessible for someone with visual impairment. The rest is, let’s say, “personal beliefs”, as I have nothing to prove it 
1 Like
As for captcha, obviously an image is not accessible for someone with visual impairment.
It is possible to have multiple captchas - image, audio, text (arithmetic questions, etc.).
1 Like
Well, like I said, I’m more than happy to host whatever needs to be hosted. Whether it’s an API (rate-limited, of course…) that can be accessed via SSH/telnet/curl/some other method that isn’t a web browser that will create a GitHub account and corresponding access token (so whoever is using it can interact with the repo via CLI), whether its static pages for the issues, or whatever.
I just ideally would prefer it if personally identifiable information is also kept to a minimum. I don’t particularly want to handle that stuff. Mainly because it’s a lot of extra work to keep it safe, and honestly, I don’t really want to do unnecessary work.
3 Likes
Well, like I said, I’m more than happy to host whatever needs to be hosted.
1 Like
I’d like to repeat my previous comment - if you dont want to use the web
interface to GitHub (and that seems to be what this thread is now
about), then you can interact with GitHub using git and gh.Again, if anyone wants to open an account but is unwilling to do
this because it requires JS, then I’m happy to do this via Tor on your behalf.
I just saw on the website:
“To change your password, ensure that Javascript is enabled in your browser.”
and in gh docs I find no info on how to change password through gh.
So, even without all the other things discussed, a person being a proxy for others for the sake of avoiding JS simply won’t work.
Additionally, now I found this in GitHub’s terms:
- One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that’s fine, but it can only be used for running a machine).
- Your login may only be used by one person — i.e., a single login may not be shared by multiple people. A paid Organization may only provide access to as many Personal Accounts as your subscription allows.
which I read as: a second account is OK but you have to pay for it. There is a condition against sanctioned countries/persons too.
So, proxy registrations are not OK - neither technically, nor legally.
2 Likes
You’re in danger of stopping anything being done by this, just as
stupidity stopped distribution of Ubuntu templates.
It’s not likely that GitHub are monitoring your messages to find
evidence of such activity but there’s no need to broadcast this. People
who are in difficult situations are often working outwith regulations.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
I don’t know anything about Ubuntu templates. You say I am in danger. - How? I am not the one broadcasting suggestions to register accounts for others. I am telling you this because you are doing this, i.e. to protect you from doing it, because you claim this is a solution.
As for what GitHub is likely or unlikely to do… that was discussed earlier.
2 Likes
You misunderstand what I said.
I have told you that I am not concerned about this, and your
“protection” is not wanted or needed.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
2 Likes