The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-27T17:27:57Zhttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/41Figure out how to handle complex DNS queries2024-03-27T17:27:57ZetaFigure out how to handle complex DNS queriesThis was raised in the meeting as part of the VPN app's proposal: what if e.g. an XMPP app wants to make an SRV query? Currently this would just fail, and the Tor network doesn't actually support this kind of DNS query.
Should we perhap...This was raised in the meeting as part of the VPN app's proposal: what if e.g. an XMPP app wants to make an SRV query? Currently this would just fail, and the Tor network doesn't actually support this kind of DNS query.
Should we perhaps use some random DoH / DoT server to forward only those types of query which we can't do?VPN pre-alpha 06https://gitlab.torproject.org/tpo/tpa/team/-/issues/41511upgrade crm-ext-01 to php 8 or retire2024-02-20T20:04:45Zanarcatupgrade crm-ext-01 to php 8 or retirein https://gitlab.torproject.org/tpo/tpa/team/-/issues/41252#note_2990644, @kez tested crm-ext-01 after I upgraded it and found the donate site completely broken by the PHP 8.2 upgrade. apparently, `implode` completely changed signature ...in https://gitlab.torproject.org/tpo/tpa/team/-/issues/41252#note_2990644, @kez tested crm-ext-01 after I upgraded it and found the donate site completely broken by the PHP 8.2 upgrade. apparently, `implode` completely changed signature in PHP and the old signature was dropped in PHP 8, which breaks a *lot* of things.
exactly how much is unclear, @kez estimated just the work to estimate that work to be a few hours of work.
for now i rolled back to the php 7.4 package from bullseye, and added it to the sources.list file (although puppet might have killed the .list file already). we need to figure out a plan to go forward, either port the code, or retire the box, which is the ultimate goal once donate-neo goes to production.Redesign donate.torproject.orghttps://gitlab.torproject.org/tpo/community/team/-/issues/96Call for testers - TBA Alpha Connect Assist2024-03-05T19:13:47ZGusCall for testers - TBA Alpha Connect AssistApplications Team is implementing "connect assist" on TBA and it would be nice to collect users feedback. We should create a Call for Testers on the Forum.
Connect Assist is available on 13.5a3 alpha.
```
## Connect assist comes to And...Applications Team is implementing "connect assist" on TBA and it would be nice to collect users feedback. We should create a Call for Testers on the Forum.
Connect Assist is available on 13.5a3 alpha.
```
## Connect assist comes to Android
This alpha is the first release with Desktop's censorship circumvention feature (connect assist) available on Android! You can try it out for yourself by navigating to the `Settings > Tor Network` and selecting `Enable beta connection features`.
**NOTE**: This feature is very much in development and is still quiet brittle and liable to breakage. Do *not* toggle this option if you value your current Tor Browser for Android Alpha configuration. If this option gets the app into an unusable state, you can get back to the legacy bootstrapping system by clearing the app's storage and cache via the Android system settings. Of course, doing so will also delete any existing configuration options so please do not enable this option if this would be a problem for you.
When this feature ships in 13.5 in late spring/early summer 2024, Android users connecting from censored networks should have the exact same bootstrapping functionality Desktop users currently have. If they are unable to connect to the Tor Network, Tor Browser will query the anti-censorship backend to determine which pluggable transports and bridges they need to use based upon their locale and the current censorship landscape. The browser will then attempt to bootstrap once more with the new settings applied. Our hope is that this will take a lot of the guesswork out of connecting to the Tor Network for our mobile users, and ensure unfettered network access during censorship events.
For now we expect this new bootstrapping UX to be buggy, but we wanted to get it into the hands of users as early as possible so we can iterate and find and fix bugs as early as possible.
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetGusGus2024-03-01https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42321Draw new icons for built-in bridges: obfs4, snowflake, and meek-azure2024-01-30T19:23:26ZnicobDraw new icons for built-in bridges: obfs4, snowflake, and meek-azureWe need custom icons for built-in bridges to :sparkles: jazz up :sparkles: the bridge cards.
@donuts off the bat do you have any suggestions for obfs4 and meek-azure conceptually?We need custom icons for built-in bridges to :sparkles: jazz up :sparkles: the bridge cards.
@donuts off the bat do you have any suggestions for obfs4 and meek-azure conceptually?Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetnicobnicobhttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/12Integrate new front-end with lektor2023-12-05T22:03:00ZdonutsIntegrate new front-end with lektorThe current donate portal's content and config options are spread across multiple lektor files. This ticket is to log each file, review their content and provide direction for the modifications required to support the new front-end templ...The current donate portal's content and config options are spread across multiple lektor files. This ticket is to log each file, review their content and provide direction for the modifications required to support the new front-end templates.
**Donate**: https://gitlab.torproject.org/tpo/web/donate-static/-/blob/master/content/contents.lr
Lektor file for the [donate form](https://donate.torproject.org/).
- [x] Review config options and produce new specification (@duncan)
- [ ] Replace with a new, streamlined file covering all three tabs (@eric, TBC)
**Champions of Privacy**: https://gitlab.torproject.org/tpo/web/donate-static/-/blob/master/content/champions-of-privacy/contents.lr
Lektor file for the [Champions of Privacy landing page](https://donate.torproject.org/champions-of-privacy/).
- [ ] Replace with a modified version of the new Donate lektor file when ready (@eric, TBC)
**Defenders of Privacy**: https://gitlab.torproject.org/tpo/web/donate-static/-/blob/master/content/monthly-giving/contents.lr
Lektor file for the [monthly giving landing page](https://donate.torproject.org/monthly-giving/).
- [ ] Replace with a modified version of the new Donate lektor file when ready (@eric, TBC)
**Cryptocurrency**: https://gitlab.torproject.org/tpo/web/donate-static/-/tree/master/content/cryptocurrency
Lektor file for the [Cryptocurrency landing page](https://donate.torproject.org/cryptocurrency/).
- [ ] Fold into the new Donate lektor file (no further action necessary)
**Donate Thank You**: https://gitlab.torproject.org/tpo/web/donate-static/-/tree/master/content/donate-thank-you
Lektor file for the donate form's [thank you page](https://donate.torproject.org/donate-thank-you/).
- [ ] Review config options and produce new specification (@duncan)
- [ ] Replace with three new lektor files – one for each thank you page (@eric, TBC)
**Donor FAQ**: https://gitlab.torproject.org/tpo/web/donate-static/-/blob/master/content/donor-faq/contents.lr
Lektor file for the [Donor FAQs](https://donate.torproject.org/donor-faq/).
- [ ] Review content and suggest reasonable changes (@smith): https://gitlab.torproject.org/tpo/web/donate-static/-/issues/35
- [x] Convert template to markdown (@kez)
**Donor Privacy Policy**: https://gitlab.torproject.org/tpo/web/donate-static/-/blob/master/content/privacy-policy/contents.lr
- Lektor file for the [Privacy Policy](https://donate.torproject.org/privacy-policy/).
- [x] Convert template to markdown (@kez)
**State disclosures**: https://gitlab.torproject.org/tpo/web/donate-static/-/blob/master/content/state-disclosures/contents.lr
- [x] Confirm what this is for, if it's still required, and where it lives (@smith?)
**Brave rewards**: https://gitlab.torproject.org/tpo/web/donate-static/-/blob/master/content/well-known/contents.lr
- [ ] Scope out technical considerations, i.e. does this file need referenced somewhere on the main donate page (@duncan)Redesign donate.torproject.orgstephenstephenhttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/10Integrate new front-end with lektor, Civi & payment processors2023-12-05T22:03:29ZdonutsIntegrate new front-end with lektor, Civi & payment processorsRedesign donate.torproject.orghttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/8Design high-fidelity mockups of new donate templates2024-01-29T19:01:55ZdonutsDesign high-fidelity mockups of new donate templatesDesign high-fidelity mockups that support our compatibility requirements for screen size & resolution:
> The donate portal should make use of the latest responsive design techniques with mainstream adoption among our target browsers (se...Design high-fidelity mockups that support our compatibility requirements for screen size & resolution:
> The donate portal should make use of the latest responsive design techniques with mainstream adoption among our target browsers (see 'Browser support') to provide user-friendly layouts that adapt to the user's screen size. At minimum, the donate portal should support screens of 320px wide, with no defined upper limit beyond the maximum width of the site's container.
>
> Text and other elements may be reduced in size at smaller screen sizes to reflect higher pixel densities and reduced viewing distances.
In addition, the new designs should align with our commitment to AA compliance with the WCAG 2.1 accessibility standard:
> The donate portal should strive to meet, at minimum, the [WCAG 2.1's success criteria for Level AA compliance](https://www.w3.org/TR/WCAG21/). Should it not be possible for a particular element to meet the criteria for AA compliance, an alternative should be provided or an exemption agreed with the Tor Project.
>
> At a glance, particular care should be taken to meet the following requirements as laid out in more detail in the [WCAG 2.1 technical specification](https://www.w3.org/WAI/standards-guidelines/wcag/glance/):
>
> **Perceivable**
> Provide text alternatives for non-text content.
> Provide captions and other alternatives for multimedia.
> Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
> Make it easier for users to see and hear content.
>
> **Operable**
> Make all functionality available from a keyboard.
> Give users enough time to read and use content.
> Do not use content that causes seizures or physical reactions.
> Help users navigate and find content.
> Make it easier to use inputs other than keyboard.
>
> **Understandable**
> Make text readable and understandable.
> Make content appear and operate in predictable ways.
> Help users avoid and correct mistakes.
>
> **Robust**
> Maximize compatibility with current and future user tools.
**Todo list:**
- [x] Credit card template
- [x] PayPal template
- [x] Cryptocurrency template
- [x] Noscript template
- [x] Thank you page template
- [ ] ~~Supporter, Defender & Champion states~~ ← Removed from the scope for the MVP
- [ ] Campaign takeover example
- [ ] Active, inactive, focus and selected states
- [ ] Error states
On the following formats:
- [x] Desktop
- [ ] Mobile
**High-fidelity mockups**
- [Figma / Marble Style guide / Donate-dot](https://www.figma.com/file/nIpahk0b9VMaeEnubiO33g/Marble-style-guide?type=design&node-id=447%3A3457&mode=design&t=WtHoL3Xw8Yau9G4a-1)Redesign donate.torproject.orgdonutsdonutshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41010Create a project to ship tor binaries in an Android-developer friendly way2024-02-05T18:15:26ZrichardCreate a project to ship tor binaries in an Android-developer friendly way`tor-onion-proxy-library` is going away, we need to setup the torrc and populate tor+PTs using the `tor-expert-bundle` project`tor-onion-proxy-library` is going away, we need to setup the torrc and populate tor+PTs using the `tor-expert-bundle` projectSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/25pass the client IP to tor for country usage stadistics2023-09-21T15:18:26Zmeskiomeskio@torproject.orgpass the client IP to tor for country usage stadisticsThe webtunnel server should use the `X-Real-IP` or another header to get the client IP address and pass it to the tor process so it can produce country based usage statistics.The webtunnel server should use the `X-Real-IP` or another header to get the client IP address and pass it to the tor process so it can produce country based usage statistics.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/26Add a license to the project2023-08-02T14:41:50Zmeskiomeskio@torproject.orgAdd a license to the projectlox-library and lox-wasm have MIT license, but it looks like the rest of the crates don't have any license. We could make all the project be MIT license.lox-library and lox-wasm have MIT license, but it looks like the rest of the crates don't have any license. We could make all the project be MIT license.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/164some bridges are not appearing in the assignments.log2024-03-06T19:11:22Zmeskiomeskio@torproject.orgsome bridges are not appearing in the assignments.log3575906728C3ADCD4CC54915E0D1AA0855480D78 and 226450492AD08A406A9CBED4CC32DF7D362D747D appear in https://bridges.torproject.org/status?id=<fingerprint> as functional, but they are not being assigned to any distributor.3575906728C3ADCD4CC54915E0D1AA0855480D78 and 226450492AD08A406A9CBED4CC32DF7D362D747D appear in https://bridges.torproject.org/status?id=<fingerprint> as functional, but they are not being assigned to any distributor.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/18Create a container image for webtunnel2023-04-19T14:33:45Zmeskiomeskio@torproject.orgCreate a container image for webtunnelWebtunnels bridge operators might want to be able to use a container to run their bridge.
We should produce some documentation on how to run the container.Webtunnels bridge operators might want to be able to use a container to run their bridge.
We should produce some documentation on how to run the container.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41541Update builtin bridges from Circumvention Settings API2024-03-27T15:25:34Zmeskiomeskio@torproject.orgUpdate builtin bridges from Circumvention Settings APIRight now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/m...Right now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md#circumventionbuiltin).
There are two concerns I have about it:
* Users will not be happy with TB making a call to an external API without giving some consent about it.
* We don't want to make easier for censors to notice you are using Tor because of that.
I think it makes sense to update when we do other connections to moat (Connect Assist, captcha bridges, ...), I assume user has already consent to do a request to the API on those cases and having an extra connection over the domain fronting should not make it more noticeable than it already is. We could store when was the last time we had updated them, and don't update them is they are fresh (maybe 24h is a good freshness).
An extra that would be nice is to ask the user if they want to refresh the builtin bridges when they click on Settings to *Select a Built-In Bridge*. I think we should only ask if bridges hasn't being refreshed for a while (maybe 7days). The confirmation popup could have a check box with 'remember that option' or something like that, so the following times they enable builtin bridges we refresh or not without asking (if the bridges hasn't being refreshed in 7days).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetma1ma1https://gitlab.torproject.org/tpo/web/support/-/issues/313Review and update the support article about circumventing censorship in China2023-10-31T16:10:20Zchampionquizzerchampionquizzer@torproject.orgReview and update the support article about circumventing censorship in ChinaWe should encourage users to use Connection Assist (ref. https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_requests/7/diffs)We should encourage users to use Connection Assist (ref. https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_requests/7/diffs)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetGusGushttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40630Update builtin bridges from Circumvention Settings API2022-12-22T11:22:11Zmeskiomeskio@torproject.orgUpdate builtin bridges from Circumvention Settings APIRight now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/m...Right now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md#circumventionbuiltin).
There are two concerns I have about it:
* Users will not be happy with TB making a call to an external API without giving some consent about it.
* We don't want to make easier for censors to notice you are using Tor because of that.
I think it makes sense to update when we do other connections to moat (Connect Assist, captcha bridges, ...), I assume user has already consent to do a request to the API on those cases and having an extra connection over the domain fronting should not make it more noticeable than it already is. We could store when was the last time we had updated them, and don't update them is they are fresh (maybe 24h is a good freshness).
An extra that would be nice is to ask the user if they want to refresh the builtin bridges when they click on Settings to *Select a Built-In Bridge*. I think we should only ask if bridges hasn't being refreshed for a while (maybe 7days). The confirmation popup could have a check box with 'remember that option' or something like that, so the following times they enable builtin bridges we refresh or not without asking (if the bridges hasn't being refreshed in 7days).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/13Fix stability issue discovered in WebTunnel2023-03-10T14:14:19ZshelikhooFix stability issue discovered in WebTunnelCurrently, the WebTunnel PT process may quit with "tor[2939]: Aug 25 15:58:19.000 [warn] Pluggable Transport process terminated with status code 512". Investigate is necessary to locate the root casue of problem.Currently, the WebTunnel PT process may quit with "tor[2939]: Aug 25 15:58:19.000 [warn] Pluggable Transport process terminated with status code 512". Investigate is necessary to locate the root casue of problem.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/11Upload Connection Parameters to rdsys for Distribution2022-12-07T15:43:23ZshelikhooUpload Connection Parameters to rdsys for DistributionCurrently, WebTunnel does not upload sufficient information to Tor process and in turn rdsys for distribution.
We need to find a way to upload these information to rdsys(including sensitive part like URL) to rdsys.Currently, WebTunnel does not upload sufficient information to Tor process and in turn rdsys for distribution.
We need to find a way to upload these information to rdsys(including sensitive part like URL) to rdsys.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/2O1.4: Increase the number of active HTTPT bridges.2023-06-27T18:40:56ZGabagaba@torproject.orgO1.4: Increase the number of active HTTPT bridges.Individuals running more Snowflake proxies is one strategy to increase the number of unblocked bridges to the Tor network. The second step is to increase the number of obfs4 and HTTPT bridges running on unblocked IP addresses. We have tw...Individuals running more Snowflake proxies is one strategy to increase the number of unblocked bridges to the Tor network. The second step is to increase the number of obfs4 and HTTPT bridges running on unblocked IP addresses. We have two strategies in mind for rapidly increasing these numbers:
- O1.4.1 Increase the number of dynamic bridges run by nonprofit partners. The Tor community has a close relationship with trusted relay operator nonprofits1 that run groups of relays, bridges, and exits. We will ask our relay operator nonprofit partners to set up new bridges, with the specific goal of spinning up new bridges when current ones get blocked, and taking blocked bridges offline. We will offer subsidies to trusted relay nonprofits in order to offset some of their infrastructure costs so that this effort can scale rapidly. We will monitor operation costs after scaling to develop a financial plan for long term sustainability together with these nonprofits.
- O1.4.2: Run a public campaign to encourage new individual operators to establish bridges. This campaign will target individuals and nonprofits who are part of the Internet freedom community, like free software advocates, relay associations, technical collectives, and hosting companies. In a previous DRL project titled Empowering Communities in the Global South to Bypass Censorship, we ran a bridge campaign2 and added approximately 100 obfs4 bridges to the network, and we know this strategy is effective in growing the capacity of bridge bandwidth resources.
- O1.4.3: Monitor bridge health. We will build continuous communication with bridge operators, sharing updates with them so they can update bridge configurations so they continue to work in target countries as new blocking attempts are deployed by CCP.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/87Publish a snapshot of what PTs are needed for successful Tor use in each country2022-07-20T21:15:30ZRoger DingledinePublish a snapshot of what PTs are needed for successful Tor use in each countrySeveral countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic curre...Several countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic currently, e.g.:
* OONI has "vanilla Tor" measurements in some countries.
* We have anecdotal stories from talking to users in various places.
* There's the censorship wiki: https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki (legacy/trac#6149)
* metrics-timeline has something similar: https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline
* And the Berkeley folks wrote up their own Tor censorship timeline: https://www.icsi.berkeley.edu/~sadia/tor_timeline.pdf
But what is the situation, this month, in every country? Which ones block the Tor directory authorities, which ones block the public relays, which ones block the default (i.e. included in tor browser) bridges, which ones enumerate bridges from bridges.torproject.org and block them by IP address, which ones use DPI to detect and cut various pluggable transport connections, which ones throttle protocols they don't want, etc?
When Venezuela's CANTV ISP did their IP address based blocking, they also blocked the default obfs4 bridges, which led to confusion and then unfortunate headlines like the one from Access: "Venezuela blocks Tor". (Tor worked fine if you got a fresh bridge, even a vanilla bridge.)
In Taipei I talked to some central asia experts who told me about how Tor only works in a degraded way in Belarus in the default configuration "because a few years ago they blocked all the relay IP addresses, but they haven't updated their block since then".
We need up-to-date information about Tor blocking to provide advice to our users when they ask for support, and also we want it for preemptively including good advice in Tor Launcher's UI. Knowing historical trends will help us prioritize the development of new pluggable transports vs new distribution methods of existing transports.
So, how do we get this information?
One option is that in the glorious future, the standard OONI decks will have all of these tools built-in. But that future is a long way off, and maybe it should never even arrive, since some Tor transports are huge and have no business being bundled into a little mobile testing app.
I think we instead want some combination of the following two plans:
* We have on-the-ground contacts in many countries, and it's often not just individuals but whole NGOs full of Tor enthusiasts. We should pull together our knowledge of who we know in each place, and ask them what they think the current situation is in their country, and talk to them regularly. We can prioritize the various countries that we think were, are, or might be trying to block Tor. Having these on-the-ground experts is going to be necessary no matter what else we add to the plan, and it's why I picked 'community outreach' as the ticket component.
* We should build automated tools to assist people in assessing Tor censorship on their network -- to increase the accuracy of reports that we get, and to make the reports come with actual data that we can compare over time. This idea is legacy/trac#23839.
This ticket is for pulling together one big-picture report. But once we have one, we will want to find ways of keeping ourselves up to date over time.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41054Improve color contrast of purple elements in connection settings in dark theme2022-11-08T14:01:23ZdonutsImprove color contrast of purple elements in connection settings in dark themeThe purple check in the connection status strip in `about:preferences#connection` could do with higher contrast in dark theme:
- [connection-status](/uploads/841682da9722abc61e7f83c3f35a9e6b/connection-status.png)
The same also applies...The purple check in the connection status strip in `about:preferences#connection` could do with higher contrast in dark theme:
- [connection-status](/uploads/841682da9722abc61e7f83c3f35a9e6b/connection-status.png)
The same also applies to the "Connected" pill present on bridge cards, which uses two tones of purple:
- [connected-pill](/uploads/b56e147826f343f285ccc01203d55dcf/connected-pill.png)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetPier Angelo VendramePier Angelo Vendrame