The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-10-19T07:06:09Zhttps://gitlab.torproject.org/tpo/community/policies/-/issues/7Include a description of the Tor Community which includes Employees, Contribu...2023-10-19T07:06:09ZGusInclude a description of the Tor Community which includes Employees, Contributors, Trainers, Translators, Operators, Dir AuthsWhile discussing how to improve the Tor network health, some contributors have raised their concerns regarding the clarity of who is considered to be part of "The Tor Project" and should adhere to its policies. This ambiguity can be inte...While discussing how to improve the Tor network health, some contributors have raised their concerns regarding the clarity of who is considered to be part of "The Tor Project" and should adhere to its policies. This ambiguity can be interpreted in various ways, such as excluding Directory Authorities or referring solely to Tor Project, Inc. (TPI).
It is crucial to clarify that when using the term "The Tor Project" in [such statements](https://gitlab.torproject.org/tpo/community/policies/-/blob/master/code_of_conduct.txt#L11), it encompasses the entire organization, including the community, network, contributors, operators, TPI, TPI board of directors, and directory authorities.
To address this confusion and ensure inclusivity, I propose a revised description to be included in the document:
"The Tor Community consists of a diverse group of contributors, including the Tor Board of Directors, Tor Directory Authorities, network operators, trainers, translators, researchers, employees, contractors, and others valued participants. This policy is applicable to all members, including the Tor Board of Directors, Tor Directory Authorities, network operators, trainers, translators, researchers, employees, contractors (regardless of their employment status with The Tor Project, Inc.), and others valued participants, as well as individuals and entities involved in the Tor Community and its network."
Update: here is a new version of the same paragraph - https://gitlab.torproject.org/tpo/community/policies/-/issues/7#note_2913009Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40337Dark mode in Tor Browser2024-01-21T20:34:40ZsukhmanDark mode in Tor BrowserI want to enable **full dark mode** (all websites become dark) in the tor browser, not just a theme, as I am sensitive to white light. I can't use the tor browser for more than 2 hours (approx.) because of this white light. Is there any ...I want to enable **full dark mode** (all websites become dark) in the tor browser, not just a theme, as I am sensitive to white light. I can't use the tor browser for more than 2 hours (approx.) because of this white light. Is there any way to enable it without using any external add-on(s)?
What I'd tried?
I can see there is a setting, in _about:config_, named as "_widget.content.allow-gtk-dark-theme._"But when I enable it nothing happens.
Edit: I know it is more like a question, not an issue but, in my case, I can count it as an issue.https://gitlab.torproject.org/tpo/team/-/issues/223Improve real-time text communication channels for TPI and the Tor Community2023-12-04T13:16:21ZGusImprove real-time text communication channels for TPI and the Tor CommunityDuring the All Hands retrospective (2023-10-11), some Tor contributors shared that onboarding and using IRC can be frustrating and painful experience.
These problems are also seen and experienced throughout the broader Tor Community. I'v...During the All Hands retrospective (2023-10-11), some Tor contributors shared that onboarding and using IRC can be frustrating and painful experience.
These problems are also seen and experienced throughout the broader Tor Community. I've witnessed this during Outreachy and GSoC internships, Community Team public meetings, and IRC meetings with partners. I believe we must improve our real-time text based comms.
We already started to improve our chat experience with [Matrix bridge](https://blog.torproject.org/entering-the-matrix/), but it's still not smooth enough:
- If you want to join some IRC private channels, you'll need to run some extra steps
- Sometimes the Matrix bridge fails or disconnects and you need to run these extra steps again
- Sometimes the Matrix bridge fails and you loose some messages
- Moderation issues
Instead of just replacing it with another random tool, we should review how different teams are using IRC, list major pain points, and which features we would like to have (or we need to fix), and then look for better options.
As this will impact the entire organization and the Tor Community, we should follow our [voting process](https://gitlab.torproject.org/tpo/community/policies/-/blob/master/voting.txt?ref_type=heads#L11), i.e., write a proposal, call for a discussion period, try to reach a consensus or vote.https://gitlab.torproject.org/tpo/core/tor/-/issues/40744Increase the amount of allowed relays per IP address to 82023-06-30T11:10:46ZNothing to hidemail@nothingtohide.nlIncrease the amount of allowed relays per IP address to 8Tor currently restricts relay operators to a maximum of two Tor relays per IPv4 address. With this issue we propose to change this limitation, with the aim of enabling Tor operators to run more Tor relays per IPv4 address.
## Reasoning ...Tor currently restricts relay operators to a maximum of two Tor relays per IPv4 address. With this issue we propose to change this limitation, with the aim of enabling Tor operators to run more Tor relays per IPv4 address.
## Reasoning for restriction
The original intent of restricting the amount of Tor relays per IP address is to increase the cost for a [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack). Despite the restriction, Sybil attacks have been [detected](https://lists.torproject.org/pipermail/tor-consensus-health/2020-November/011602.html) in the past.
The "two relays per IP" restriction is likely to impede poorly organized adversaries' efforts. But on the other hand it's hard to imagine that more organized adversaries would be held back by this limitation.
## Reasoning for changing the restriction
The server market has been focused on increasing the amount of threads (instead of high clockspeeds) for more than a decade now. And with great success: AMD64 CPU's with 128 threads are commonplace now and it won't be long before CPU's with 256 threads will make their debut.
While this is great in general, it also adds significant complexity for Tor operators since Tor does not scale well on multi-core CPU's. In order to effectively use a modern server with a large amount of threads, you would need to run many Tor relays. This has many downsides, such as complex system management and additional OS/system overhead. But the biggest challenge by far is overcoming the restriction of two Tor relays per IPv4 address. The TCO and amount of IPv4 addresses Tor operators need to acquire in order to run a high amount of Tor relays on a modern server is disproportionately high.
And we all know the reason. The available IPv4 address space has become sparse and significantly more expensive over the past ten years. In 2013 the price of one IPv4 address was around € 6,00. At the time of writing this proposal, the price fluctuates between € 50,00 and € 55,00 per IPv4 address. This steady increase in cost is passed on to Tor operators one way or another. For Tor operators using colo/DPS/VPS the increase in cost is reflected in the colo/cloud providers' rates. Tor operators running their own ASN/datacenter have to spent a large amount of money or need to spent considerable time on lobbying for a sympathetic party that owns and wants to sponsor IPv4 addresses. The latter is getting more difficult by the year, since the IPv4 address space is running dry for pretty much everyone.
All in all we experience the aforementioned restriction as a disproportionate measure in terms of benefits vs. cost for Tor operators. It's safe to say that this restriction currently and increasingly limits the amount of CPU cycles and bandwidth Tor operators can contribute to the Tor network (and make contributing to the network significantly more expensive). This will only become worse with time.
The Tor project is putting effort in a multi-threaded rust implementation of Tor named [Arti](https://blog.torproject.org/announcing-arti/). However, Arti is still a long way off and does not solve the problem we face for the coming years.
## Changing Tor
To solve this problem, we propose to implement one of these options:
### 1) Enable 32 Tor relays per IPv4 address
The number is somewhat arbitrary and could be less or more. Modern servers with 64-96 cores/128-192 threads are readily available on today's server market. A lot of Tor operators run one Tor process per thread, so this would mean 4-6 IPv4 addresses per modern server CPU instead of 64-96 IPv4 addresses. Detecting operators that make use of this increased limit should be trivial.
### 2) Allow relay operators to request exceptions
If after discussion our first proposal is still met with hesitation/resistance, the Tor project could provide exceptions for Tor operators that request an increase or even removal of the restrictions in place. This would be a manual process and a Tor operator could request such an exception based on:
* IP address/network (e.g. 1.1.1.1 or 1.0.0.0/24).
* Authenticated Relay Operator ID (AROI).
* Autonomous System Number (ASN).
All of these options have advantages and disadvantages. IP addresses/networks used by an operator will change over time, which could add significant maintenance for managing the exceptions. AROI is a long term static ID (domain) that should be less likely to change than IP addresses. The ASN provides a long term static ID as well, but is only applicable to a small number of Tor operators.
We are not asking the Tor project to implement both options, one option that works for us is all we need. We will also bring this topic to the next Tor Relay Operator Meetup on 2023-01-28.
https://applied-privacy.net/<br>
https://artikel10.org/<br>
https://nothingtohide.nl/Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40220Close stale connections in standalone proxy2022-11-29T14:20:34ZCecylia BocovichClose stale connections in standalone proxyWe've received several reports (#40211) of standalone proxies that have long-lived connections with clients but zero bytes transferred. The browser-based snowflake proxies (i.e., the web extension and badge) have a [timeout in place to c...We've received several reports (#40211) of standalone proxies that have long-lived connections with clients but zero bytes transferred. The browser-based snowflake proxies (i.e., the web extension and badge) have a [timeout in place to close stale connections](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/29a4cc6e0970f2e10ed610b8ae8449eafe75472c/proxypair.js#L163) after [30 seconds](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/29a4cc6e0970f2e10ed610b8ae8449eafe75472c/config.js#L38) of inactivity. This aligns with a [client-side timeout](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/ac8562803ab9621d037bd1b3710c59799c7aa6d5/client/lib/snowflake.go#L49) that closes stale connections to proxies after 20s of inactivity.
It's possible that the long-lived connections these standalone proxies are seeing are from clients not using our snowflake client code. Or that the client-side closures are not being received by the proxies. In any case, we should add an inactivity timeout to the standalone proxies to try and clean up these connections and free up resources in a similar way that the browser-based proxies do.https://gitlab.torproject.org/tpo/web/community/-/issues/301Improve guide for running standalone Snowflake proxy2024-02-05T19:12:52ZrayaImprove guide for running standalone Snowflake proxyFollowing a discussion with @MarkC, we want to start collecting detailed feedback on the guide for running a standalone Snowflake proxy: https://community.torproject.org/relay/setup/snowflake/standalone/
Importantly, we want to make sur...Following a discussion with @MarkC, we want to start collecting detailed feedback on the guide for running a standalone Snowflake proxy: https://community.torproject.org/relay/setup/snowflake/standalone/
Importantly, we want to make sure that the guide is comprehensive enough for users who're not technical but curious to want to try and run a standalone proxy - lowering the barriers of entry.
cc: @nah @gusGusGushttps://gitlab.torproject.org/tpo/ux/research/-/issues/103Test the Snowflake landing page with the help of regional partners2024-03-14T17:05:33ZNahTest the Snowflake landing page with the help of regional partnersSnowflake landing page was [updated recently](https://snowflake.torproject.org).
As part of Sponsor 9, we're going to create a plan to understand users view and pain points. This research plan needs to be adapted to local needs and cha...Snowflake landing page was [updated recently](https://snowflake.torproject.org).
As part of Sponsor 9, we're going to create a plan to understand users view and pain points. This research plan needs to be adapted to local needs and challenges, and will be conducted by partners in specific regions.
- [x] Create Research Plan
- [x] Onboard Partners
- [x] Collect Feedback
- [x] Publish Report
Issue related: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40209
Some feedback are being registered in the Forum:
- https://forum.torproject.net/t/collecting-feedback-on-snowflake-landing-page-content-and-related-guides/5277/3
- https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40209Sponsor 9 - Phase 6 - Usability and Community Intervention on Support for Democracy and Human RightsNahNahhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41092Enable tracking query parameters stripping2023-10-03T15:36:13ZArthur EdelsteinEnable tracking query parameters strippingURL query parameters (aka URL search parameters) are a major vector for cross-site tracking. They comprise what is perhaps the most significant category of cross-site tracking vector that remains unblocked in Tor Browser.
Fortunately, F...URL query parameters (aka URL search parameters) are a major vector for cross-site tracking. They comprise what is perhaps the most significant category of cross-site tracking vector that remains unblocked in Tor Browser.
Fortunately, Firefox [has announced](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/osQQROd2jKA) that they will be enabling tracking query parameter stripping for Strict mode and Private mode. (As of Firefox 103, this protection seems to be enabled in Strict Mode only in Release.) It would be great if Firefox's feature can be enabled in Tor Browser and expanded to cover more parameters that Firefox doesn't, including Google's gclid and dclid and Microsoft's msclkid. For a longer list of candidate parameters, see https://privacytests.org/Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40397Create a new build target to package tor daemon, pluggable transports and dep...2023-03-21T10:16:44ZrichardCreate a new build target to package tor daemon, pluggable transports and dependenciesTo support censorship-circumvention, 3rd party app developers (like briar, onion share, ricochet-refresh, etc) need a way to package tor + pluggable transports with their application. The current solutions of either 'build them yourself ...To support censorship-circumvention, 3rd party app developers (like briar, onion share, ricochet-refresh, etc) need a way to package tor + pluggable transports with their application. The current solutions of either 'build them yourself using tor-browser-build' or 'extract them from tor-browser releases' is less than ideal (see: https://forum.torproject.net/t/are-there-any-official-reproducible-tor-obfs4proxy-binaries/831/3 ).
We should separately archive and publish the contents of what becomes the 'Tor' directory in tor-browser in a standard place as part of our release process so 3rd parties can easily integrate tor+PTs into their own applications.
@boklm @msimonellirichardrichardhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40138Create a static HTML page at: status.torproject.org2021-01-30T00:53:33ZDavid Gouletdgoulet@torproject.orgCreate a static HTML page at: status.torproject.orgThe idea here is for TPO to have a `status` page where we can post status problem we know about so the world can learn if problems are known to the Tor team.
A great example would have been the v3 outtage recently where we could have pu...The idea here is for TPO to have a `status` page where we can post status problem we know about so the world can learn if problems are known to the Tor team.
A great example would have been the v3 outtage recently where we could have put out a small FAQ right away (go static HTML!) and then update the world as we figure out the problem but also expected return to normal.
I propose a static website at the moment in order to have this page going very soon and easily editable by many of us namely likely the network health team and we could also have the network team to help out.
We can then over time think of better automated way to get status on that page like automatic reports of sensors/metrics we have and so on. But for the moment, just a DNS + static HTML would be grand.
Thanks!
Update, next steps:
- [x] brainstorm/discuss requirements (see [goals](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status#goals))
- [x] prototype cstate (@anarcat, people seem happy with it)
- [x] basic theming (thanks @duncan!)
- [x] rush deployment on static site network (@anarcat)
- [x] basic documentation (see [service page](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status))
- [x] grant access to other teams
- [x] setup a mirrored repo in gitolite (allow access to the same members as here!)
- [x] setup CI in Jenkins @hiro
- [x] figure out which categories we want? (update as needed)
- [x] document the new git workflow for updates (@hiro)HiroHirohttps://gitlab.torproject.org/tpo/core/team/-/issues/2Rename git master to main2021-07-09T18:32:08ZDavid Gouletdgoulet@torproject.orgRename git master to main*edited by nickm*
Following emerging best practices (eg [`draft-knodel-terminology-05`](https://datatracker.ietf.org/doc/draft-knodel-terminology/), [current gitlab defaults](https://about.gitlab.com/blog/2021/03/10/new-git-default-bran...*edited by nickm*
Following emerging best practices (eg [`draft-knodel-terminology-05`](https://datatracker.ietf.org/doc/draft-knodel-terminology/), [current gitlab defaults](https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/)), we should rename `master` to `main`. This affects the main repository so the ticket is here instead of in tor.git.
Renaming:
* [x] Chutney
* [x] Trunnel
* [x] Tor
* [x] Torspec
* [x] Onionbalance (up to George)
* [x] Torsocks (up to David)
Places to update:
* [ ] Gitweb (redirects may be needed)
* [x] github CI scripts
* [x] gitlab CI scripts
* [x] OSS-Fuzz scripts
* [x] nick's dodgy coverity script
* [x] `scripts/git/*`
* [x] TBB nightly build scripts?
* ... what else?Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/12631Tor Browser for ARM architecture2024-03-28T13:16:10ZMatt PaganTor Browser for ARM architectureThe Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and...The Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and probably other platforms too.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42436Allow for multiple configured (front, reflector) domain fronting pairs in Moa...2024-03-06T18:39:12ZCecylia BocovichAllow for multiple configured (front, reflector) domain fronting pairs in Moat moduleIt's happened twice now that the domain fronting settings for Moat have stopped working:
- [when `cdn.sstatic.net` moved to CloudFlare](https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000314.html)
- [when Fastl...It's happened twice now that the domain fronting settings for Moat have stopped working:
- [when `cdn.sstatic.net` moved to CloudFlare](https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000314.html)
- [when Fastly stopped supporting domain fronting and `foursquare.com` renewed its cert](https://github.com/net4people/bbs/issues/309)
When Moat stops working, it leaves us scrambling to find new front domains, the update process requires a new release, and it can be difficult for users to receive updates or connect if Connection Assist is unreachable. It's also difficult to choose a single front domain that will work in almost every place. Even though Connect Assist allows us offer country-specific circumvention settings, we have only a single setting for using Connect Assist itself.
Ideally, we could provide multiple (front, reflector) pairs, and iterate through them until a working pair is found. That pair can be saved for future use until it stops working and the module will re-iterate through the list until a new pair is found.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42226Reduce Customisability of default fonts and colours2023-11-30T08:57:19ZrichardReduce Customisability of default fonts and coloursWe should provide some pre-defined 'themes' that are inline with user's accessibility needs in order to minimize the number of potential fingerprinting buckets.
This would require a few parts:
- identifying which sets of default provid...We should provide some pre-defined 'themes' that are inline with user's accessibility needs in order to minimize the number of potential fingerprinting buckets.
This would require a few parts:
- identifying which sets of default provided 'themes' we should provide
- it seems some set of options could be:
- default || dark mode
- default || high-contrast
- default || large text
- new UX for this entire section of about:preferences:
![afbeelding](/uploads/8c681c883216218f7aaf91cdf6aef275/afbeelding.png)
/cc @henry @donuts @thorinhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41895flip RFP's prefers-color-scheme to dark2023-11-01T23:10:07ZThorinflip RFP's prefers-color-scheme to darkRFP reduces this binary metric to useless (in our Tor Browser set of users) by always returning `light`. We can achieve the same FPing protection by always returning `dark`.
This is, IMO, not technically an accessibility issue, as the C...RFP reduces this binary metric to useless (in our Tor Browser set of users) by always returning `light`. We can achieve the same FPing protection by always returning `dark`.
This is, IMO, not technically an accessibility issue, as the CSS standard is arbitrary, not universal - i.e only a few websites (but arguably large popular websites) implement it. That said, I am not an accessibility expert, or knowledgeable about or experience light hurting eyes and creating migraines etc. I will say I've never heard of anyone claiming dark sites did the same (but of course the default is light and we enforce light)
In ESR115 as a major milestone, we could change test always returning `dark`. My logic for this is
- entropy is not affected
- accessibility _may_ be helped
- I strongly believe accessibility re colors is best served under existing/upcoming standards that are universal (which we could preset/harden)
- there are degrees of usefulness, and accessibility advocates indicate that this helps (maybe they're lying just to advocate their perference, but I'm inclined to agree that it can't hurt and would likely help)
We currently get RFP users (and tom will confirm), who complain about the _same few_ RFP items: it's _always_ timezone, prefers-color-scheme, and now timing (60FPS). It is my belief that no matter what we do, people will complain, but by returning `dark`, user's complaints are no longer anywhere near the validity of e.g. saying it causes migraines - in fact users who complain they get dark themed sites are just aesthetics (unless someone can prove dark themes are an accessibility problem)
In other words - flipping to dark cannot hurt fingerprinting, and can/would help usability
Class, discuss! cc @donutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41876Remove Firefox View from title bar2023-10-03T17:15:56ZhenryRemove Firefox View from title barI'm guessing we don't want the `firefox-view-button` in the title bar. We can remove it in the "Bug 41736: Customize toolbar for base-browser." patch.I'm guessing we don't want the `firefox-view-button` in the title bar. We can remove it in the "Bug 41736: Customize toolbar for base-browser." patch.https://gitlab.torproject.org/tpo/core/arti/-/issues/870Restrict contact information field in arti to just allow an email address2024-01-23T12:37:50ZGeorg KoppenRestrict contact information field in arti to just allow an email addressOver the years folks have put all sorts of information into the contact information field. When working on arti relay we should be more strict than that. I think we should only allow an email address and ignore all the other stuff people...Over the years folks have put all sorts of information into the contact information field. When working on arti relay we should be more strict than that. I think we should only allow an email address and ignore all the other stuff people try to put there. We have recently seen scammers that abuse that field for lack of any other usable one and I think with arti relay it's time to prevent that from happening in the future.
EDIT (05/30/2023): However, to be clear, this is not the only reason for this ticket. See e.g.: https://gitlab.torproject.org/tpo/core/arti/-/issues/870#note_2906733.
I have no strong opinion on whether we should allow some kind of obfuscation mechanisms like `[@]` instead of a plain `@` but it could be something to consider.
/cc @ahf @gushttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/57Remove third-party trackers (Google and Adobe)2023-04-04T10:12:33ZNothing to hidemail@nothingtohide.nlRemove third-party trackers (Google and Adobe)Since I'm a GDPR legal advisor by trade, I always check the services I use for their privacy implications on me as a data subject. Tor Weather is no exception in this regard ;).
Weather.torproject.org uses third-party resources that rec...Since I'm a GDPR legal advisor by trade, I always check the services I use for their privacy implications on me as a data subject. Tor Weather is no exception in this regard ;).
Weather.torproject.org uses third-party resources that receive PII of any visitor. This is always bad from a privacy/freedom standpoint (and certainly not privacy by design), but since the third-parties in this case are Google[1][2] and Adobe[3][4] it's even more of an issue. Both of these companies have a bad track record of long-term and consistent privacy/GDPR violations. But even disregarding the specifics, I feel a organization like the Tor Project should keep Tor operators far from the grasps of these kind of big tech companies.
But this is also in clear violation of the GDPR[5][6][7] since there is no legal basis for this. There is no explicit and freely given consent[8][9] (or any other applicable GDPR legal basis such as legitimate interest) being used for sharing PII with Tor's hired/appointed processors of PII. Tor Project is responsible for this processing (i.e. the controller[8] in GDPR terms) since Tor Project determines the purposes and means of processing these personal data.
I also don't think this use of third-party trackers is even proportional let alone necessary or subsidiary[6][11]. It looks like they are only used for loading in fonts, and those can be hosted locally as well (which makes using the third-party resources fail the proportionality and subsidiarity requirements in the GDPR).
And lastly there is also no privacy statement. Normally as a data subject I would tolerate this if the service is created following privacy by design principles and I find the organization behind it trustworthy, but when there are third-party resources (also note that Akamai is a data processor of the Tor Project) in play this is a whole other story. Transparency is essential for trust and freedom (and also legally required in this case)!
My suggestion is to at least remove the third-party trackers and just host the resources you need locally on the webserver.
[1] fonts.googleapis.com<br>
[2] fonts.gstatic.com<br>
[3] p.typekit.net<br>
[4] use.typekit.net<br>
[5] https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/<br>
[6] https://gdpr-info.eu/art-5-gdpr/<br>
[7] https://gdpr-info.eu/art-6-gdpr/<br>
[8] https://gdpr-info.eu/art-7-gdpr/<br>
[9] https://gdpr-info.eu/recitals/no-43/<br>
[10] https://gdpr-info.eu/art-4-gdpr/<br>
[11] https://gdpr-info.eu/recitals/no-39/<br>Sarthik Guptasarthikg@icloud.comSarthik Guptasarthikg@icloud.comhttps://gitlab.torproject.org/tpo/community/relays/-/issues/62Help partner organizations to setup standalone snowflake proxies2023-06-07T17:06:24ZGabagaba@torproject.orgHelp partner organizations to setup standalone snowflake proxiesSnowflake works by creating a “flurry” of available proxies all around the world. Individuals who want to help people bypass censorship can install a Snowflake proxy into their web browser and become a temporary proxy as long as their br...Snowflake works by creating a “flurry” of available proxies all around the world. Individuals who want to help people bypass censorship can install a Snowflake proxy into their web browser and become a temporary proxy as long as their browser is open and online. This means that it’s extremely easy for many people to run proxies–we’ve seen an increase from about 30,000 to about 110,000 in the last month!
It’s also possible to set up standalone Snowflake proxies that run on their own machines or servers. While they are not as easy as a browser plugin to run, standalone Snowflake proxies have some benefits:
(1) standalone Snowflakes are connected 24/7 (instead of just when a user’s browser is on);
(2) they have a dedicated, fast, and stable connection in a data center; and
(3) they have unrestricted NAT–this is important because when using residential connections, modems and routers limit a lot of what can connect to an individual’s proxy.
In order to accommodate the amount of new traffic on the network, we need to increase the number of standalone Snowflake proxies.
In this activity, we will work with partner organizations and individuals to set up, host, and run standalone Snowflake proxies and offer them technical support. We also will help the operators monitor their proxies for blocking and respond when there are censorship events or changes so that these proxies remain available.Sponsor 139: Rapid Response IranGusGushttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41083TPA-RFC-53: consider propagating 2FA everywhere, maybe at the April Tor Meeting2023-05-23T16:06:02ZanarcatTPA-RFC-53: consider propagating 2FA everywhere, maybe at the April Tor MeetingI've been meaning to do a training or work session or "EVERYONE GETS A YUBIKEY PARTY" thing for a while now. I don't know how it will look like. I don't know quite the requirements yet. But it feels like an opportunity.
/cc @shelikhoo @...I've been meaning to do a training or work session or "EVERYONE GETS A YUBIKEY PARTY" thing for a while now. I don't know how it will look like. I don't know quite the requirements yet. But it feels like an opportunity.
/cc @shelikhoo @linusanarcatanarcat2023-04-06