i would recommend autonomous tech collectives for email services if these aspects are important & meaningful: Radical Servers - riseup.net
you will find many that dont require javascript etc. companies have less incentive to meet your expectations and there more legal avenues for compromise.
not perfect but something:
i would recommend autonomous tech collectives for email services if these aspects are important & meaningful: Radical Servers - riseup.net
Riseup requires invitation, which is not easy to get. That process itself (sharing the invite code) is technically traceable, i.e. partially deanonymizing (in case that may be important for someone). I also know about accounts being disabled due to abuse of that process: person A sends invitation to person B, then person B does mischief, then both A and B loose their accounts.
But yes, Riseup is one of the few (if not the only one). FWIW, not long ago they changed their web mail client to a JS-based oneā¦ so even if one uses an IMAP/POP client, to control certain mail settings (such as spam filtering), one needs a JS-enabled web browser.
not perfect but something:
Qubes Partners | Qubes OS
Qubes OS Ā· Expenses - Open Collective
Thanks. I already found the first link earlier.
If these numbers are correct, it seems the income is much higher than the expenses, i.e. there are funds.
BTW the second link requires JS in TB 
just to be clear, that link is a list of ~40 autonomous tech collectives, most of whom provide email services, and many of whom donāt require invitations. riseup specifically created this list to reduce dependency on them & make people more aware of other similar services/efforts that might fit folksā needs better - i imagine in there is a provider that meets your needs.
a provider that meets your needs.
I wasnāt looking for one but thanks for sharing for the community.
As of this thread, what we should look for is a privacy-respecting replacement for GitHub. I have already shared everything I have found so far. Further research is necessary by the main users of GitHub - the developers.
On the question of GitHub, the main objection seems to be that for some
purposes, like registering,password change,token (re)generation, users
have to use a browser with JavaScript enabled, and this is a threat to
privacy.
If there were an onion service that provided vnc access to a disposable
where users could run JS required actions in a Tor browser, would that
help alleviate the problem?
If not, then Iām failing to understand the issue, and could do with some
help.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
If there were an onion service that provided vnc access to a disposable
where users could run JS required actions in a Tor browser, would that
help alleviate the problem?
This means being exposed to the same mouse/keyboard fingerprinting + trusting someone elseās machine where one enters oneās credentials.
If not, then Iām failing to understand the issue, and could do with some
help.
The issue is not JS per se.
Is this the āmemes about Qubes OSā topic or have I gotten lost
The latter:
If youāve ever looked at the results of running vnc over ssh over Tor
you wouldnāt say this.
You have to trust someone.
Can you be specific about where you think the risk lies here? Do you
think the service provider will be sniffing your GitHub credentials? To
what end?
Oh, well, Iāve obviously been misled by the title of this thread, the
initial posts, and the repeated references to having to use Javascript.
Your response here isnāt helpful. Can you set out exactly what you
think the issue is, and how it affects users. At this stage I really
am lost, and if we are to understand the issue, (or issues), then we need
a clear statement of what it is. Absent that, thereās no possibility of
identifying a solution.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
If youāve ever looked at the results of running vnc over ssh over Tor
you wouldnāt say this.
Based on your proposal:
Does the remote Tor Browser run JS? - Yes.
Does one interact with that TB through mouse and keyboard? - Yes.
Can GitHub receive that user input through that remote TB? - Yes.
What has VNC over SSH to do with any of that?
You have to trust someone.
Why should anyone trust a mid man if the goal is secure communication between 2 hosts over TLS?
Can you be specific about where you think the risk lies here? Do you
think the service provider will be sniffing your GitHub credentials? To
what end?
unman, is that you, a respected developer of one of the most secure OS, or has someone hacked your account? I am quite confused by the level of your questions.
Oh, well, Iāve obviously been misled by the title of this thread, the
initial posts, and the repeated references to having to use Javascript.
I have not set that title.
Your response here isnāt helpful. Can you set out exactly what you
think the issue is, and how it affects users. At this stage I really
am lost, and if we are to understand the issue, (or issues), then we need
a clear statement of what it is. Absent that, thereās no possibility of
identifying a solution.
The issue is privacy/anonymity and the ways it is reduced by GitHubās changes. This discussion started as reply to your:
- Some users want to remain anonymous. [ā¦] Perfectly possible to work on GitHub anonymous and over Tor.
Since then, I have explained multiple times why this is not true. Others mentioned that not only JS but also CSS can be involved in the process of tracking oneās interaction patterns. Other issues were also mentioned along the way, including the security/accessibility of the project code, being hosted with a PRISM company, involved in censorship etc. (I canāt repeat everything)
I have also proposed to use web forms for anonymous submissions, which is a workaround (and not a solution) to some of the challenges.
What should the title be then?
What should the title be then?
I donāt know if it should be different. What you quoted was just a reply to a seemingly subtle imputation.
Are you also mislead by the title not describing correctly the topic?
I do not like vague titles, and this topic title is not clear about its association with GitHubās JavaScript requirements being challenging and/or discouraging potential contributors to Qubes OS. At the same time, I am not very interested in engaging in discussion about this topic since I need to use my limited resources towards other projects I can make progress on.
If you were to trace the outputs of (e.g) keypresses in VNC over Tor
you would see that they differ from clearnet traffic, or even traffic over
simple Tor.
Thatās what it has to do with any of that.
This goal was a requirement that you had not previously stated.
Unlike some users here, I have always found it useful to ask questions
to try to understand what issue another user has, or understand exactly
what they think the issue is.
Iāve spent (wasted?) considerable time listening back over this thread,
which has ranged widely. The thread repeatedly comes back to the claim
stated in the title, that use of JavaScript at GitHub stops
contributors. You yourself have referred to JS on many occasions.
And so I am asking you to explain exactly what you think the issue is,
so that we can (possibly) make some progress.
It does seem to me that you would like to have all the features of
GitHub,(and this Forum), which rely on JavaScript, without using
JavaScript. I could well be wrong about this, but that is the impression
I have.
I am asking you to explain clearly about this, because I think it will help you
to be clear about what the issues are, and that may help everyone to
move forward.
Itās obvious that we are making no progress as it is, and have made none in the
past 9 months.
I find that you have said many things. I am trying to find out which you
think are important, and why, and which you think are stopping folk from making
contributions to Qubes.
I am struggling to understand why proxying through a web form would
address the many issues you have raised, and why you think some are
more important than others.
If you were to trace the outputs of (e.g) keypresses in VNC over Tor
you would see that they differ from clearnet traffic, or even traffic over
simple Tor.
Thatās what it has to do with any of that.
But that has nothing to do with GitHub. What I tried to illustrate was that interacting with the website through a browser, running the same JS as a local browser would, does not make any difference in regards to mouse/keyboard patterns.
Thatās why your suggestion does not solve the problem. It only moves it to another machine, thus introducing an additional security issue.
This goal was a requirement that you had not previously stated.
IETF has stated it:
I have never suggested to break security in order to improve privacy. I have also discussed in detail why any of the proxy models you suggest are insecure.
So, the question remains.
Unlike some users here, I have always found it useful to ask questions
to try to understand what issue another user has, or understand exactly
what they think the issue is.
Good. Since I also find this approach useful, I hope you can answer my questions too (including those in other threads that remain unanswered).
Iāve spent (wasted?) considerable time listening back over this thread,
which has ranged widely.
So have I.
And so I am asking you to explain exactly what you think the issue
is, so that we can (possibly) make some progress.
I have already explained that multiple times. If you have any specific question that was not answered, I will answer it.
It does seem to me that you would like to have all the features of
GitHub,(and this Forum), which rely on JavaScript, without using
JavaScript. I could well be wrong about this, but that is the
impression I have.
You are approaching the issue with the assumption that I am somehow personally attached to those features. - I am not. I neither care about stars on GitHub, nor about likes of comments, colorful emoticons, pasting inline images inside messages, etc. I also doubt any developers are in desperate need for any of those.
As I said earlier, when alternatives are considered, features must be researched by those who would use them the most. For source hosting - devs, then part-time contributors, bug reporters.
I am asking you to explain clearly about this, because I think it
will help you to be clear about what the issues are, and that may
help everyone to move forward.
I am clear. I donāt know what exactly to clarify.
Itās obvious that we are making no progress as it is, and have made
none in the past 9 months.
I donāt quite understand what you mean by progress. I have already proposed a super simple temporary workaround. I have also looked for alternatives and mentioned some. That + your proxy suggestions are the only ones so far.
I find that you have said many things. I am trying to find out which
you think are important, and why, and which you think are stopping
folk from making contributions to Qubes.
I donāt know what may be stopping anyone in particular. I just know there are very good experts who would not want touch any privacy invasive technology for various reasons (personal, ideological, political, other). There is visible overall interest in privacy in the community as a whole.
Important issues:
I am struggling to understand why proxying through a web form would
address the many issues you have raised, and why you think some are
more important than others.
It allows to use GitHub without direct access to it - no account, no tracking technology.
I wasnāt participating in this topic from the beginning but even just reading a couple pages I think itās obvious and super clear that is what the topic is about and donāt need any explanation to understand that.
I think itās strange that when it comes to security he think itās natural that users should sacrifice convenience and luxury for better security. But when it is about privacy, then prettier gui and convenience is more important than privacy.
Like you said, lets be real about who the target audience here is. We prefer security and privacy over likes etc.
If I add āno tracking/correlationā to this list (does this cover anonymity well enough?), do we have a good summary of the issues in this thread? The first item I take for granted here - please remind me if there were points about GH and MITM.
Itās been confusing over a long thread (3h??) to jump between the issues here. The thread title (not mine - this was separated from another thread) suggests a focus on the JS/tracking/correlation aspect, rather than a discussion of every way using GitHub can be a concern - it is misleading in the sense that the first attracts people interested in short-term and incremental actions, who definitely wouldnāt expect that from the second. People who are onboard with not exactly loving GitHub still get frustrated when the conversation bleeds into areas that could be much simpler.
I think this thread was at times fairly close to agreeing on actions to deal with the JS/anonymity issue specifically. Unmanās offer to proxy removed JS and registration, and a web form would go further, avoiding JS and offering fuller anonymity and better automation, and that seems to cover this issue well enough, so maybe we could move on to talk about implementation details?
If you do want a single discussion that covers all the items above - and it looks like itās not just you - then itās never too late to move on in a thread with a title that fits, and that would help the users who donāt want to engage with all the issues at once (and itās probably a good thing if that includes some of the dev team).
If I add āno tracking/correlationā to this list (does this cover anonymity well enough?), do we have a good summary of the issues in this thread?
The last item covers that too, although not explicitly. By personal data I mean anything that can identify an individual directly or indirectly (pretty much the GDPR definition of the term).
The first item I take for granted here - please remind me if there were points about GH and MITM.
unmanās suggestions include MITM.
qubes-os.org also uses MITM (CloudFlare) - even if we ignore the pages unrelated to GH, potential pages hosting the web forms are related.
maybe we could move on to talk about implementation details?
I donāt see anywhere an official announcement that a specific solution has been chosen among well-researched alternatives and that someone is willing to work on it. With something not planned by anyone, a discussion on implementation details might turn out to be a waste of time.
If you do want a single discussion that covers all the items above - and it looks like itās not just you - then itās never too late to move on in a thread with a title that fits, and that would help the users who donāt want to engage with all the issues at once (and itās probably a good thing if that includes some of the dev team).
I donāt mind whichever others consider more convenient. If you feel like organizing all the info so far, you can summarize it in separate threads.
I think another problem with the discussion here in this topic, and also generally in qubes os. is that there are many users here who have laser eyes or tunnel vision. I mean they focus in so much in the details and getting to a very very specific problem to solve. But this means they forget about the bigger picture. What is the bigger problem weāre trying to solve.
Because itās about anonymity in the bigger picture. One part of that is the JS problem. But itās just one part of it. If you laser eyes tunnel vision the JS problem and forget about the bigger picture, then the solutions you come up with wonāt necessarily be helpful for solving the bigger problem.
Itās interesting to see the two different mindsets at work. Those who can see the bigger picture and those who canāt because they are so good at focusing in on details instead. Itās something that has been a bit frustrating for me but now that I am just now realizing this, and explaining it to you all as well, we can hopefully work together so the people with the bigger picture vision can help guide the detailed users in the right direction.
Did you just reinvent product executives?
Here what youāve got is a number of people who are good at focusing on and delivering details but can talk about the big picture when they want to. Theyāre good at managing their attention, and theyāve seen enough conversations go nowhere, but they still often make some effort when someone wants to talk.
Itās not safe to assume that the people with experience of the project who are less engaged have less vision - the opposite seems more likely. One reason is that it makes practical sense for busy contributors not to engage fully until whoever invited the conversation has made their suggestions and scope clear.
In real life outside large enterprise, implementation details are a big part of comparing possible solutions.