The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-06-08T19:26:08Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40198Out of localhost ephemeral ports ("cannot assign requested address") on link ...2023-06-08T19:26:08ZDavid Fifielddcf@torproject.orgOut of localhost ephemeral ports ("cannot assign requested address") on link between snowflake-server and haproxySince 2022-09-28 10:57:26 (53 hours ago) the snowflake-server log is full of:
```
# grep 'cannot assign requested address$' /var/log/snowflake-server/snowflake-server.log | head
2022/09/28 10:57:26 handleConn: failed to connect to ORPor...Since 2022-09-28 10:57:26 (53 hours ago) the snowflake-server log is full of:
```
# grep 'cannot assign requested address$' /var/log/snowflake-server/snowflake-server.log | head
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
# grep 'cannot assign requested address$' /var/log/snowflake-server/snowflake-server.log | tail
2022/09/30 15:44:17 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/30 15:44:18 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/30 15:44:18 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/30 15:44:18 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/30 15:44:18 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
```
The error message means that the kernel could not allocate an ephemeral port number
for a localhost TCP connection.
In this case it for the connection between snowflake-server and haproxy.
My analysis at https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000265.html was incomplete:
the total number of localhost sockets does not matter for the purpose of counting 4-tuples,
but it *does* matter for the purpose of allocating ephemeral ports.
There are currently only 21712 sockets open between snowflake-server and haproxy,
which means the remainder of the ephemeral port range is taken up by other
localhost communication.
My immediate plan for this is to move haproxy to 127.0.0.2:10000 rather than 127.0.0.1:10000,
and maybe similarly with the individual tor instances if necessary.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-30https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/3O1.3: Implement bridges with pluggable transport HTTPT support.2022-10-04T17:27:22ZGabagaba@torproject.orgO1.3: Implement bridges with pluggable transport HTTPT support.HTTPT is a promising new pluggable transport designed to hide traffic behind HTTPS servers. HTTPT has specific benefits for the case of making Tor more accessible to users in China; specifically that it is immune to replay attacks, which...HTTPT is a promising new pluggable transport designed to hide traffic behind HTTPS servers. HTTPT has specific benefits for the case of making Tor more accessible to users in China; specifically that it is immune to replay attacks, which protects it against China’s active probing; it uses existing web servers, so that it’s harder for censors to discover; it requires minimal overhead; and it relies on TLS, a popular protocol, making it much more difficult for censors to block outright. In this Activity we will make Tor Browser and HTTPT work together before pushing for more users in the target region and launching it in Tor Browser.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoo2022-09-30https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40125Update Landing Page (snowflake.torproject.org)2023-03-15T14:48:30ZsereneUpdate Landing Page (snowflake.torproject.org)We've had feedback that the snowflake.torproject.org landing page has been somewhat confusing / unclear. Many users are unsure whether to install the Snowflake Browser Extension, or run Tor Browser. (eg. Many users in Russia have install...We've had feedback that the snowflake.torproject.org landing page has been somewhat confusing / unclear. Many users are unsure whether to install the Snowflake Browser Extension, or run Tor Browser. (eg. Many users in Russia have installed the extension instead, being proxies instead of clients!)
I threw together a draft of an [updated landing page](https://serene.cx/snowflake-torproject-org-draft/ ) by slightly modifying the [current one](https://snowflake.torproject.org/).
To be improved further, but it's an idea:
![Screen_Shot_2022-04-11_at_18.16.33](/uploads/dccb730fb60564a0b9a4cf26a946a223/Screen_Shot_2022-04-11_at_18.16.33.png)
- I think the Tor Browser screenshot also needs to be updated.
- I have another idea, which I'll include in a separate ticket.
- Is this managed / on a separate host from main torproject.org?
This Snowflake landing page can be the very first place people see, so we should make it much more clear & helpful for the users. Let me know next steps @gus @gaba :)meskiomeskio@torproject.orgmeskiomeskio@torproject.org2022-09-30https://gitlab.torproject.org/tpo/core/tor/-/issues/40146Objective 3: Evaluate and implement selected research solutions for performan...2023-03-31T19:23:55ZGabagaba@torproject.orgObjective 3: Evaluate and implement selected research solutions for performance and scalability with the highest impact for our users.A community of academic researchers surround the Tor Project and our tools.1 Many researchers have published papers on improving Tor network performance. Two research topic areas stand out as providing the most overall performance benefi...A community of academic researchers surround the Tor Project and our tools.1 Many researchers have published papers on improving Tor network performance. Two research topic areas stand out as providing the most overall performance benefit in the research literature so far: congestion control and traffic splitting (Conflux).
Congestion control2 allows multiple connections to fairly share the full capacity of a dataflow path, without causing overload or delay at any bottleneck on that path. Lack of congestion control is the reason why Tor has a speed limit of approximately 500KB/sec for bulk data transfer, regardless of how much spare relay capacity is available on the Tor network. Lack of congestion control also contributes to the high variability in Tor latency, as congestion builds up at these bottlenecks.
Traffic splitting, also known as Conflux,3 allows data to be sent along two or more paths, split in proportion to which path has more spare capacity. Traffic splitting is a complementary extension to congestion control--as congestion control algorithms detect congestion on one path, traffic splitting can shift traffic to another path. The total throughput of a user’s Tor connection is then the sum of all available capacity on these paths.
Once deployed, these two systems will vastly improve the experience of video streaming, file transfer, and interactive application usage over Tor, for both censored and uncensored users. We expect congestion control to provide large improvements to average and best-case Tor download throughput metrics, as well as reduce worst-case latency, jitter, and variations in Tor performance metrics. We expect that traffic splitting will further improve these results, especially for throughput. We expect all of these results to be visible in simulation. More importantly, we expect that simulation will guide our choice of algorithm and parameters for live network deployment.
To successfully deploy these systems, we will break work into two phases: first simulation, then live network tuning:
- [ ] [3.1: Evaluate candidate algorithms and parameters in simulated Tor networks.](https://gitlab.torproject.org/tpo/core/tor/-/issues/40153)
- [ ] [3.2: Deploy the best algorithms and parameters from evaluation in 3.1.](https://gitlab.torproject.org/tpo/core/tor/-/issues/40154)Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive places2022-09-30https://gitlab.torproject.org/tpo/core/tor/-/issues/40143Sponsor 61 - Making the Tor network faster & more reliable for users in Inter...2023-03-31T19:23:46ZGabagaba@torproject.orgSponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesIn this project, the Tor Project aims to make the Tor network faster for users with slow connections and old devices by:
- Streamlining the tuning o- f the network;
- Deploying smarter methods for balancing traffic;
- Evaluating and imp...In this project, the Tor Project aims to make the Tor network faster for users with slow connections and old devices by:
- Streamlining the tuning o- f the network;
- Deploying smarter methods for balancing traffic;
- Evaluating and implementing promising performance and scalability research;
- Proactively detecting, diagnosing, and resolving user-facing performance issues.
We meet the first Monday of the month. More information at http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/sponsor61-meeting-pad
Weekly status meetings in irc. More information at https://pad.riseup.net/p/tor-netteam-2020.1-keep
[Objective 1: Improve user-facing performance metrics by streamlining the tuning of the Tor network.](https://gitlab.torproject.org/tpo/core/tor/-/issues/40144)
- [ ] O1.1: Optimize user-facing performance by tuning parameters of previously deployed Tor network improvements
- [ ] O1.2: Ensure quick deployment of performance enhancements by improving how we test and deploy efficiency adjustments to the network.
[Objective 2: Decrease latency for end users by deploying smarter load balancing mechanisms.](https://gitlab.torproject.org/tpo/core/tor/-/issues/40145)
- [ ] O2.1: Reduce the number of slow and extremely slow sessions for our users by developing and deploying load balancing improvements.
[Objective 3: Evaluate and implement selected research solutions for performance and scalability with the highest impact for our users.](https://gitlab.torproject.org/tpo/core/tor/-/issues/40146)
- [ ] O3.1: Evaluate performance improvements presented in research literature.
- [ ] O3.2: Implement promising performance improvements from evaluation in O3.1.
[Objective 4: Improve our ability to proactively detect, diagnose, and resolve user-facing performance issues. ](https://gitlab.torproject.org/tpo/core/tor/-/issues/40147)
- [ ] O4.1: Improve and implement network health monitoring and scanning.
- [ ] O4.2: Find and fix performance-impacting issues and bugs discovered from monitoring and scanning.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive places2022-09-30https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/60Update s28 plugin for v2.5.02022-01-25T21:43:13ZCecylia BocovichUpdate s28 plugin for v2.5.0More details soon. Due date tentative.More details soon. Due date tentative.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)2022-10-01https://gitlab.torproject.org/tpo/core/tor/-/issues/401543.2: Deploy the best algorithms and parameters from evaluation in 3.1.2023-03-31T19:25:31ZGabagaba@torproject.org3.2: Deploy the best algorithms and parameters from evaluation in 3.1.After this initial simulation, we will:
- 3.2.1: Refine implementations in these areas based on those simulation results and any subsequent research in these areas and prepare the most promising options and parameter values for test and ...After this initial simulation, we will:
- 3.2.1: Refine implementations in these areas based on those simulation results and any subsequent research in these areas and prepare the most promising options and parameter values for test and deployment on the live Tor network.
- 3.2.2: Deploy these systems on the live Tor network, and further tune the parameters of these new systems, using the methods detailed in Objective 1.1, while also leveraging lessons learned from the work in that objective towards tuning our existing systems.
- 3.2.3: Monitor the impact of these improvements on our live performance metrics, and ensure that we see similar results as were found in simulation.
- 3.2.4: Monitor network health and overload metrics from Objective 4 during this deployment to ensure these systems do indeed reduce overload and congestion on the network, and do not introduce bugs or new reliability or performance issues.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive places2022-10-01https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/119Update circumvention map in Iran and provide snowflake as first option2022-09-29T18:08:27ZGusUpdate circumvention map in Iran and provide snowflake as first optioncircumvention map:`"ir":{"settings":[{"bridges":{"type":"obfs4","source":"bridgedb"}},{"bridges":{"type":"snowflake","source":"builtin"}}]}`
Snowflake seems to work quite well in Iran according to [OONI probe tests](https://explorer.oon...circumvention map:`"ir":{"settings":[{"bridges":{"type":"obfs4","source":"bridgedb"}},{"bridges":{"type":"snowflake","source":"builtin"}}]}`
Snowflake seems to work quite well in Iran according to [OONI probe tests](https://explorer.ooni.org/chart/mat?probe_cc=IR&test_name=torsf&since=2022-09-14&until=2022-09-21&axis_x=measurement_start_day), while bridgeDB could be distributing blocked bridges.
So, should we change the priority here? Snowflake first, and if it fails, bridgeDB bridges? (cc: @meskio)shelikhooshelikhoo2022-10-03https://gitlab.torproject.org/tpo/operations/team/-/issues/6Prepare and present Oct 13 pitch to Josh for follow-on internet freedom work2023-01-08T18:03:25ZRoger DingledinePrepare and present Oct 13 pitch to Josh for follow-on internet freedom workOn Oct 13 we will have a time slot to pitch our next plans for anti-censorship and beyond.
The audience will be our various friends from the internet freedom funder world, like DRL and OTF, but ultimately the audience will also be Josh,...On Oct 13 we will have a time slot to pitch our next plans for anti-censorship and beyond.
The audience will be our various friends from the internet freedom funder world, like DRL and OTF, but ultimately the audience will also be Josh, who will collect opinions from DRL/OTF/etc to decide which groups to fund.
Here are the instructions we have so far: "We are preparing for a virtual meeting with internet freedom community members to present RACE technologies for rapid potential internet freedom
transition. You should plan on a 30 min "pitch", including time for
questions. The pitch should include cost. Duration of effort is up to two
years, but I would generally expect duration to be ~12 months. This is
part of the rapid transition efforts I mentioned at the last PI meeting."
We need to:
(A) Decide what further tasks we will pitch, including timeframe and cost.
(B) Craft a presentation which presents the tasks and also convinces the listener that we are the right group to do them.
(C) Do the presentation, handle Q&A, and do whatever follow-ups result.Roger DingledineRoger Dingledine2022-10-07https://gitlab.torproject.org/tpo/tpa/team/-/issues/40908reverse DNS broken at cymru2022-10-11T14:13:27Zanarcatreverse DNS broken at cymrui just opened a ticket with cymru named "URGENT: reverse DNS for 38.229.82.0/24 broken", it was assigned the ticket number CST-316.
i noticed this while trying to launch gettor-rdsys (#40789), mails would fail to route to eugeni with:
...i just opened a ticket with cymru named "URGENT: reverse DNS for 38.229.82.0/24 broken", it was assigned the ticket number CST-316.
i noticed this while trying to launch gettor-rdsys (#40789), mails would fail to route to eugeni with:
```
host eugeni.torproject.org[49.12.57.136] said: 450 4.7.25 Client host rejected: cannot find your hostname, [38.229.82.36] (in reply to RCPT TO command)
```
and indeed reverse DNS is broken on that IP... hell, here's a copy of the ticket i sent to cymru:
> ```
> anarcat@curie:~$ host 38.229.82.36
> Host 36.82.229.38.in-addr.arpa. not found: 3(NXDOMAIN)
> anarcat@curie:~[1]$
> ```
>
> It looks like the entire zone delegation was removed:
>
> ```
> anarcat@curie:~$ dig -x 38.229.82.36
>
> ; <<>> DiG 9.16.33-Debian <<>> -x 38.229.82.36
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56474
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;36.82.229.38.in-addr.arpa. IN PTR
>
> ;; AUTHORITY SECTION:
> 82.229.38.in-addr.arpa. 3355 IN SOA ns1.cymru.com. empty.empty. 39 3600 600 1209600 3600
>
> ;; Query time: 52 msec
> ;; SERVER: 1.1.1.1#53(1.1.1.1)
> ;; WHEN: Wed Sep 28 10:24:27 EDT 2022
> ;; MSG SIZE rcvd: 114
> ```
>
> 38.229.82.0/24 used to be delegated to tor's nameservers, which are:
>
> ```
> torproject.org. 86400 IN NS ns1.torproject.org.
> torproject.org. 86400 IN NS ns3.torproject.org.
> torproject.org. 86400 IN NS ns4.torproject.org.
> torproject.org. 86400 IN NS ns5.torproject.org.
> torproject.org. 86400 IN NS nsp.dnsnode.net.
> ```
>
> this is causing an outage on our end as servers in that cluster are
> having trouble delivering mail.anarcatanarcat2022-10-11https://gitlab.torproject.org/tpo/web/donate-static/-/issues/90Update donate.tpo for the year-end campaign 20222022-10-14T17:53:02Zal smithUpdate donate.tpo for the year-end campaign 2022We will need to update https://donate.torproject.org with the new design and swag assets for the year-end campaign, which is meant to launch October 13.
## Necessary updates
- [x] Header image (@nicob will provide)
- [x] Swag asset imag...We will need to update https://donate.torproject.org with the new design and swag assets for the year-end campaign, which is meant to launch October 13.
## Necessary updates
- [x] Header image (@nicob will provide)
- [x] Swag asset images for the $75 and $125 levels (@nicob will provide)
- [x] Add donation ticker to the page, to launch 00:00:00 October 13 UTC, with top limit for the match set at $100,000 (see the only ticker ticket I could find from last year here: #55)
- [x] Update text for $75 level (in comment below)
- [x] Update text for $125 level (in comment below)
- [x] Update "Choose your size and fit" text (in comment below)Year End Campaign 20222022-10-13https://gitlab.torproject.org/tpo/tpa/nextcloud/-/issues/10TPA-RFC-39: Nextcloud user account policy2022-10-17T18:20:09ZanarcatTPA-RFC-39: Nextcloud user account policyI was surprised to find out that Nextcloud wasn't limited to tor-internal, in tpo/tpa/team#40772 (confidential: some offboarding ticket). if not only tor-internal users can have access, we should clarify who *does* get access, for how lo...I was surprised to find out that Nextcloud wasn't limited to tor-internal, in tpo/tpa/team#40772 (confidential: some offboarding ticket). if not only tor-internal users can have access, we should clarify who *does* get access, for how long, and who approves that.
/cc @gaba
Discussion ticket for https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-39-nextcloud-account-policyJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2022-10-13https://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/53Pipeline failures on GitLab CI2022-10-10T13:31:23ZSilvio RhattoPipeline failures on GitLab CIPipelines are failing for mirrors hosted on https://gitlab.com after tpo/onion-services/onion-launchpad#52 was implemented.Pipelines are failing for mirrors hosted on https://gitlab.com after tpo/onion-services/onion-launchpad#52 was implemented.Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-10-14https://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/52Per-language site name2022-10-10T17:51:50ZSilvio RhattoPer-language site nameIntroduce per-language environment variable to set the site name, like `LEKTOR_SERVICE_NAME_ES`.
Site name resolution during build time:
* Checks for `LEKTOR_SERVICE_NAME_{$LANG_CODE}`.
* Fallback to `LEKTOR_SERVICE_NAME`.Introduce per-language environment variable to set the site name, like `LEKTOR_SERVICE_NAME_ES`.
Site name resolution during build time:
* Checks for `LEKTOR_SERVICE_NAME_{$LANG_CODE}`.
* Fallback to `LEKTOR_SERVICE_NAME`.Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-10-14https://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/51Remove "https://" and trailing slash from displayed site address2022-10-06T12:37:43ZSilvio RhattoRemove "https://" and trailing slash from displayed site addressChange from:
> Unable to access [https://service-url.website/](https://service-url.website/)?
To
> Unable to access [service-url.website](https://service-url.website/)?Change from:
> Unable to access [https://service-url.website/](https://service-url.website/)?
To
> Unable to access [service-url.website](https://service-url.website/)?Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-10-14https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41277Attackers could bypass LetterBox in tor browser2022-12-10T21:27:56ZrichardAttackers could bypass LetterBox in tor browserFrom email:
> Dear Mozilla, Tor,
> I would like to report what I believe to be a vulnerability with a
> `low - medium` risk; the vulnerability allows the attacker to resize
> the browser's window into full screen, getting the exact scre...From email:
> Dear Mozilla, Tor,
> I would like to report what I believe to be a vulnerability with a
> `low - medium` risk; the vulnerability allows the attacker to resize
> the browser's window into full screen, getting the exact screen
> dimensions of the device's screen. This, of course, wouldn't be an
> issue if we were talking about casual everyday browsers (chrome,
> firefox, etc), but this is Tor, where every bit of information is
> valuable to someone out there.
>
>
> Risk
> low - medium
>
> 1- Although screen size dimensions might not be the only factor that
> compromises a Tor user's anonymity, they are a crucial piece of data
> that, when combined with other details, can be used to build a user
> profile.
>
> 2- Because almost all other Tor users have similar screen sizes,
> people who fall victim to this vulnerability will be even more unique
> and easier to target.
>
> All the details can be found in this GitHub repo
> (https://github.com/a7maadf/Bypass-LetterBoxing), along with a proof
> of concept video, and the script used.
> I'm ready to answer any questions you have.
> Thank you for everything you have done for the community.
> Regards,
> Ahmad
> ahmad-fawzy.com
> Computer Scientist && Penetration Tester
upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1788839Sponsor 131 - Phase 3 - Major ESR 102 Migration2022-10-17https://gitlab.torproject.org/tpo/tpa/team/-/issues/40906retire web-chi-03 and web-chi-04 nodes2022-10-18T12:51:03Zanarcatretire web-chi-03 and web-chi-04 nodeswe have setup new mirrors to replace web-chi-03 and web-chi-04 in #40904. this ticket is about retiring the latter servers once we are certain there is absolutely no traffic on there.
1. [x] ~~announcement~~ (done), check that traffic ...we have setup new mirrors to replace web-chi-03 and web-chi-04 in #40904. this ticket is about retiring the latter servers once we are certain there is absolutely no traffic on there.
1. [x] ~~announcement~~ (done), check that traffic is still low on the hosts: https://grafana.torproject.org/d/53QNFNtZz/traffic-per-class?orgId=1&var-class=All&var-node=web-bhs-05.torproject.org:9100&var-node=web-bhs-06.torproject.org:9100&var-node=web-chi-03.torproject.org:9100&var-node=web-chi-04.torproject.org:9100&var-node=web-fsn-01.torproject.org:9100&var-node=web-fsn-02.torproject.org:9100&from=now-30m&to=now&refresh=1m
2. [x] nagios
3. [x] retire the host in fabric (which shuts it down), in one week
4. [x] remove from LDAP with `ldapvi`
5. [x] power-grep
6. [x] remove from tor-passwords
7. [ ] ~~remove from DNSwl~~ (n/a)
8. [x] remove from docs
9. [ ] ~~remove from racks~~ (n/a)
10. [x] remove from reverse DNSJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2022-10-19https://gitlab.torproject.org/tpo/web/lego/-/issues/53Decide how to display multi-locale Alphas on /download/alpha2022-10-27T16:54:39ZdonutsDecide how to display multi-locale Alphas on /download/alphaI think the simplest solution would be to retain the current table with a single row for the multi-locale build for Alpha.
We can also add a line/paragraph of copy to the page explaining the change. As a result of removing the individua...I think the simplest solution would be to retain the current table with a single row for the multi-locale build for Alpha.
We can also add a line/paragraph of copy to the page explaining the change. As a result of removing the individual builds, the exact languages Tor Browser Alpha is available in will no longer be obvious – so we should include a list of supported locales somewhere as well.
This will need to get elevated to a support article eventually, but that can wait until this feature reaches stable in Tor Browser 12.0.
Due date is a guesstimate – we'll need to have a plan in place ahead of 12.0a4's launch by the end of the month. See https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40627 for details.2022-10-28https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/92Prepare for s28 PI and ECP presentations: Oct 31 and Nov 1-2 20222023-01-08T18:03:25ZRoger DingledinePrepare for s28 PI and ECP presentations: Oct 31 and Nov 1-2 2022In the tradition of https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62, we have another PI meeting coming up at the beginning of November, where we will want to present the current state of Tor anti-censorship, the situat...In the tradition of https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62, we have another PI meeting coming up at the beginning of November, where we will want to present the current state of Tor anti-censorship, the situation with deployment and usage of our pluggable transports (obfs4 and snowflake in particular), what we're up to next, etc.
The text from the previous ticket is still a good summary of info I'll be trying to collect and present:
* (0) Did we make any changes to the Snowflake architecture as deployed on Race? Did we find and/or fix any especially interesting Snowflake-on-Race issues? It's fine if the answer here is "no, we did all the hard work last year, this time it was clear sailing".
* (1) Our deployed transports (Snowflake, obfs4, and meek/moat):
* user-evident dev progress (security and obfuscation fixes, new features, performance changes)
* adoption (trends in growth of users or capacity or load; or different countries joining the story)
* (2) Task Area One (censorship analysis) progress. Who is censoring components of the Tor ecosystem, how, when, where, for how long?
* (3) Task Area Two (reputation-based bridge distribution strategies) progress.
* (4) Progress on our anti-censorship roadmap tasks. We don't need to make progress on every one of them, but we should have something impressive on some of them. Here are some highlights from the Q1 roadmap where progress would count as interesting:
* Snowflake performance (especially in Asia)
* Conjure and httpt
* Scale Tor reachability through mobile Snowflakes
* React and steer our response to censorship
* Monitor bridge health
* Improved UX for users getting bridges in practice (e.g. "Make it easier for humans & harder for censors to get bridges from moat distributor.", "Improve automatic censorship detection during bootstrapping in Tor Browser (desktop and Android)")
* (5) Collaborations or interactions with external anti-censorship research groups or NGOs that caused (or that we think will cause) the world to become a better place wrt censorship. This one is broad, and we've been too busy and too small to interact much lately, but I have it on the list here in case we notice something, and because hopefully in future iterations we'll start having some answers.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Roger DingledineRoger Dingledine2022-10-28https://gitlab.torproject.org/tpo/core/tor/-/issues/40155O4.2: Find and fix performance-impacting issues and bugs discovered from moni...2023-03-31T19:25:43ZGabagaba@torproject.orgO4.2: Find and fix performance-impacting issues and bugs discovered from monitoring and scanning (from O4.1).Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive places2022-10-30