The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-04T01:42:54Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42039Make the warning of about:config not skippable2023-11-04T01:42:54ZThorinMake the warning of about:config not skippableWe think we could force release users to always see the `about:config` warning, to remind that it can be dangerous.
We thought of:
- always show the warning (by locking `browser.aboutConfig.showWarning` = true)
- remove the warning che...We think we could force release users to always see the `about:config` warning, to remind that it can be dangerous.
We thought of:
- always show the warning (by locking `browser.aboutConfig.showWarning` = true)
- remove the warning checkbox
- spruce up about:config interstitial (FF example below)
- use TB colors?
- change warning to at least mention fingerprinting (and drop `performance` to keep it short)
- maybe a learn more to the about:manual entry
- we need some RED somewhere ... RED WINDOW OF DEATH sounds good
![FF](/uploads/3e6dafea04251f19575243ecee8f8bf4/FF.png)
from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41797#note_2934868
cc: @pierov @donutshttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/219Enable third party protocol handlers2024-02-15T14:49:00ZruihildtEnable third party protocol handlersAs written in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/5556, there are good reasons for Tor Browser not to support magnet (or any other third party protocol handlers).
But, the threat probably doesn't always e...As written in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/5556, there are good reasons for Tor Browser not to support magnet (or any other third party protocol handlers).
But, the threat probably doesn't always exist for most Mullvad Browser users.
There are roughly 4 cases:
1. no proxy or VPN are in use in the system
1. all connections are going through a VPN Tunnel
1. the whole system is going through a VPN tunnel, except the browser
1. no proxy or VPN are in use in the system, except the browser
1. the whole system is going through a VPN tunnel, the browser is going through a different proxy
For case 1 and 2, there are no proxy/bypass or linkability concerns. (Which would be the big majority of Mullvad Browser users)
For cases 3, 4 and 5, the concerns are similar to Tor Browser.
So I think it would be ok to optionally enable external app links to open in apps.
A good example of how it can be implemented is in Firefox Android, there is a preference called "Open links in apps", where you can chose between "Always" / "Ask before opening" / "Never".
![image](/uploads/b44fd48f67b5442a2f16b0fa3726483b/image.png)
We could offer similar choices.
(Then there is still the scheme flooding concern: https://bugzilla.mozilla.org/show_bug.cgi?id=1711084)https://gitlab.torproject.org/tpo/core/tor/-/issues/40831null pointer dereference if threadpool initialization fails2023-10-08T15:25:20ZAlex Xunull pointer dereference if threadpool initialization fails```
In function 'threadpool_register_reply_event',
inlined from 'cpuworker_init' at src/core/mainloop/cpuworker.c:140:13,
inlined from 'run_tor_main_loop' at src/app/main/main.c:1230:3,
inlined from 'tor_run_main' at src/app/...```
In function 'threadpool_register_reply_event',
inlined from 'cpuworker_init' at src/core/mainloop/cpuworker.c:140:13,
inlined from 'run_tor_main_loop' at src/app/main/main.c:1230:3,
inlined from 'tor_run_main' at src/app/main/main.c:1359:14,
inlined from 'tor_main' at src/feature/api/tor_api.c:166:12,
inlined from 'main' at src/app/main/tor_main.c:32:7:
src/lib/evloop/workqueue.c:631:9: warning: potential null pointer dereference [-Wnull-dereference]
631 | if (tp->reply_event) {
| ^
```
if `threadpool_new` fails, then `tp` will be null. `spawn_func` should not normally fail, and furthermore the result will most likely be a non-exploitable segmentation fault, but it is still technically undefined behavior and should be fixed.Tor: 0.4.9.x-freezehttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/34Weekly Update, Meeting Recap and Agenda2023-11-10T01:37:27ZharletaWeekly Update, Meeting Recap and AgendaPROJECT OVERVIEW
Project Objective
Discover opportunities to ensure Arti's documentation is up to standard and write documentation for Arti
<details><summary>ADDITIONAL EXPECTATIONS(Click to expand)</summary>
Per Monday, August 14th:...PROJECT OVERVIEW
Project Objective
Discover opportunities to ensure Arti's documentation is up to standard and write documentation for Arti
<details><summary>ADDITIONAL EXPECTATIONS(Click to expand)</summary>
Per Monday, August 14th:
1- Please use common language in documentation for all personas
2- The Arti documentation project will be a template or guidance for future documentatio structure.
3- Example of Rust Documentation from the Arti team https://serde.rs/ , https://docs.rs/tokio/latest/tokio/
4- Example of power user documentation and Gabi used the documentation to get started. (always room for improvement!) https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO
</details>
Timeline
Next Step timeline: TBD
Both content audit, UX research, and the final report will be delivered by **September 6th.** -- Completed.
<details><summary>Click for Phase I Deliverables</summary>
[V.1 sitemap](https://drive.google.com/file/d/1EbLU4-NiTWhVIpGVZt4k9es2FB2ZjG3X/view?usp=sharing)
[content audit raw data](https://docs.google.com/spreadsheets/d/1h7AT4C4L5WiH_Svj8RZLCqkPekuohJIfgupkHlMV4RA/edit#gid=1251652576)
[User interview recording](https://drive.google.com/drive/folders/1kv1k6EAphaWyM9QVqRvUHJKmBfwLzpB_?usp=sharing)
[final audit and UX research report here.](https://docs.google.com/document/d/1QmeejQaBnk3y4F8zyB2w9sx2ZzRZxSvTPLmCwkz7QbM/edit#heading=h.2jtu73z9bwl3)
</details>
--------------------------------------------------------------------------------------------------------
KICKOFF PHASE II AGENDA AND MINUTES
Date September 14th, 2023
[Meeting Recording here](https://drive.google.com/file/d/19IHldsKDPY_8zH7K-5BejDSrW4hmctj_/view?usp=drive_link)
_(Recording access is restricted; please let Gaba knows should you need access)_
Final report presentation and findings
<details><summary>The Highlighted Issue and Actionable Next Steps -- click to expand</summary>
I. Documentation is Scattered
Issue: Documentation is scattered. Navigating and grabbing information has proven difficult.
Solution: Implement a sitemap on a single platform with unified docs. (Dependencies on the final sitemap)
Impact: Users can grab information easier and faster.
II. Existing Docs Can Improve User Friendliness
Issue: Based on UX research, Most users are learning Arti and Rust. Therefore, Advance Rust for documentation is not quite as helpful.
Solution: Revise Getting Started and tutorial with a beginner-level Rust user's mindset, more verbose, and easy copy-paste examples.
Impact: A more accessible and lower barrier in Arti documentation.
III. Lack of Context in Documentation
Issue: Some users need more time to understand Arti instructions due to a lack of context in how Arti works.
Solution: Add conceptual guides that include Arti architecture.
Impact: Users can achieve understanding and move on to the next step faster.
IV. Outdated docs
Issue: Some of the documentation is outdated
Solution: Keeping the documentation up-to-date. DocumentWrite team will rewrite some of the documentation.
Impact: Less confusion among users.
V. Lack of common use case
Issue: Related to outdated docs and context. Users can't relate to some of the existing use cases.
Solution: On top of keeping the documentation up to date and always providing context, Arti would need a common example in Documentation, such as embedding Arti or configuring bridges for censorship documentation.
Impact: The user can relate to the use case better.
A more comprehensive explanation can be read in [final audit and UX research report.]
(https://docs.google.com/document/d/1QmeejQaBnk3y4F8zyB2w9sx2ZzRZxSvTPLmCwkz7QbM/edit#heading=h.2jtu73z9bwl3)
</details>
**Summary of agreed upon next step:**
1. Arti and Documentwrite to collaborate on the final sitemap
2. We agree to proceed with Docsaurus as the new documentation platform. Once step one is done, DocumentWrite will build a base and migrate the documentation. _**we've established that Docsaurus can run without javascript_
3. While migrating, our team will revise outdated documentation, write getting started, and tutorials.
4. The Arti design team would be responsible for the front-end part of the documentation. @gaba, would it be possible for the Arti team to help with domain management for the migration?
5. DocumentWrite to help with any future releases.
--------------------------------------------------------------------------------------------------------
Weekly Update Phase II
_11/6 - 11/9_
1. Submitted eight merge requests currently under review by Arti
_10/30 - 11/3_
**Accomplishment**
1. Alignment on review process
2. The Arti team [approved the latest merge requests. ](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/merge_requests/10)
**Next Step**
1. Continue writing documentation
_10/23 - 10/27_
**Accomplishment**
1. Schedule a meeting to review 19 documentation to review
2. [7 documentation submitted and is under review](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/merge_requests)
**Next step**
1. Review the documentation
2. Continue working on Arti documentation.
_10/16 - 10/19_
**Accomplishment**
1. Submitted 19 documentation to review. All documentation to review is under the respective column.
![image](/uploads/516382826d2d974fb4ad2fe2338afaaf/image.png)
@pkafei will discuss with @gaba on review cadence.
2. Discovery meeting with Ian to help write new documentation.
Next step:
1. Receive additional resources to write[ Creating configuration options](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/51)
2. Continue writing documentation.
3. Settle on review process for the submitted 19 documentation
_10/02 - 10/13_
**Accomplishment**
1. Merged the [following here ](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/tree/dev?ref_type=heads)
frequently asked questions (faqs)
safer build options
using bridges with Arti
troubleshooting: fixing some common problems
protocol support and compatibility for arti
compiling for android
compiling for ios
examples (a page with list of example projects from the repo)
overview (how to contribute)
code of conduct
support policy
overview (project status)
changelog
![image](/uploads/0158dc7ed042f7a57fc83a7021460f7b/image.png)
Next step:
1. Continue with documentation writing (Gitlab ticket to be added)
2. Meet with Ian Jackson to get some clarity on net new documentation/article
_9/25 - 9/28_
**Accomplishment**
1. [Deliver sitemap R2 ](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/40#note_2949019)
![image](/uploads/bf827bb0c76f2f629a4a0c706595d80c/image.png)
2. Confirm repositories for docsaurus
**Next Step**
1. Write new documentation "about Arti"
_9/11 - 9/22_
**Accomplishment**
1. Alignment on Arti documentation next step by September 14th
2. Receive the first sitemap feedback
3. Analyze sitemap feedback and adjustments to impact the documentation writing scope.
4. Build Docsaurus base
**Next Step**
1. Gain access to the appropriate Arti repo for docsaurus
2. Provide second draft of sitemap
3. Submit all documentation writing ticket to Gitlab
<details><summary>**Weekly Update Phase I **</summary>
_8/4 - 9/8_
**Accomplishment **
1. DocumentWrite submitted [sitemap](https://drive.google.com/file/d/1EbLU4-NiTWhVIpGVZt4k9es2FB2ZjG3X/view?usp=sharing), [content audit raw data](https://docs.google.com/spreadsheets/d/1h7AT4C4L5WiH_Svj8RZLCqkPekuohJIfgupkHlMV4RA/edit#gid=1251652576), [User interview recording](https://drive.google.com/drive/folders/1kv1k6EAphaWyM9QVqRvUHJKmBfwLzpB_?usp=sharing), [final audit and UX research report here. ](https://docs.google.com/document/d/1QmeejQaBnk3y4F8zyB2w9sx2ZzRZxSvTPLmCwkz7QbM/edit#heading=h.2jtu73z9bwl3)
Next Step
**Priority of the week**
1. Arti and the DocumentWrite team to meet for the final presentation. Feel free to vote the[ time that works best for you here](https://doodle.com/meeting/participate/id/dLJ4rZja).
_8/28 - 9/1_
**Accomplishment **
1. Completing the interview and card sort. The last user was Dan, who was interviewed on August 29
2. Content audit raw data has passed the DocumentWrite QA team check and is under final polish
3. Arti Sitemap's recommendation is submitted to DocumentWrite's internal QA process
Next Step
**Priority of the week **
1. DocumentWrite to finish content audit and UX research final report analysis
2. DocumentWrite to package content audit raw data, content audit and UX research final report
3. Arti and the DocumentWrite team to meet for the final presentation. Feel free to [use this calendar](https://calendly.com/d/233-8wh-367/documentwrite-kickoff) to book a time. Should you need to schedule multiple people, feel free to schedule still and notify Harleta, she'd be happy to add the other guests to the invite.
_8/22 - 8/25_
**Accomplishment **
1. Finalize interview questions
2. Content audit: 60% went through an internal QA check
3. Conducting card sorting session
4. Conducting two out of three [user interviews ](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/30)
Next Step
**Priority of the week**
1. Reschedule Dan. Sadly Dan was a no-show during the interview @charlie-doc-writer is working with him to reschedule
2. Update card sort invite. -- completed.
3. Continue with content audit
_8/14 - 8/18_
**Accomplishment**
1 - Schedule 3 users for an interview
------ Dan August 22nd
------ Pier August 24th
------ Ian August 24th
2 - Schedule 1 user for card sorting
------ Era, Ma, and Micah August 24th
3 - Arti provided a list of [mission-critical tasks](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/35)
4 -[ Content audit early findings here](https://drive.google.com/file/d/1R5jRkNooit4X3Q10tmmbI-tNOBIMIWh7/view?usp=drive_link)
Next Step
**Priority of the week **
(Sorted by highest priority)
1 - Charles to deliver [first draft of interview questions](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/work_items/28) based on the shared [mission-critical task](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/35).
_8/7 - 8/11_
**Accomplishment **
1. Charles connected with the engineer and get the code up and running
2. Understood Arti inventory to proceed with other analysis in [the content audit](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/2).
3. Identifying crucial use case with Arti team needs to happen before Card sorting and user interview. All card sorting date and user interviews are moved to the week of August 21st
4. Gaba found [users to interview ](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/6).
5. Harleta provided new [calendar link for user interview](https://calendly.com/charlesmuzonzini/1-on-1-meeting?back=1&month=2023-08&date=2023-08-25), [doodle for card sorting](https://doodle.com/meeting/participate/id/e5L4l3vd), and [doodle for use case meeting](https://doodle.com/meeting/participate/id/el7NmrMd)
**Priority of the week **
(Sorted by highest priority)
1. [Gaba to encourage Arti team to vote on use case meeting time](https://doodle.com/meeting/participate/id/el7NmrMd). It looked like both Gaba and Ian can't meet at the same time. Would this be a problem?
2. [Card sorting preparation: Gaba to users for card sort ](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/7) using [card sorting link provided here](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/7#note_2930248).
2. Charles and Gaba to start encouraging users to schedule within the week of August 22nd range due to timeline changes
3. Charles to [Complete 40% of the content audit first draft for internal QA.](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/2)
8/1 - 8/4 2023
1. [ Gaba to connect Charles with the engineer who can help him onboard ](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/work_items/12) per August 3rd
2. Charles is working on the scheduled time with engineer on August 4th
Meeting Notes
Date: Monday, August 14th, 2023
**Talking Points**
Date: Wednesday, August 2nd, 2023
**Talking Points**
Team Introduction
a. Portia - Founder of DocumentWrite
b. Charles - Technical writer
c. Harleta - Project manager
d. Gaba - Project owner and Arti project manager
Project Objective
Discover opportunities to ensure Arti's documentation is up to standard and write documentation for Arti
Project Timeline
Both content audit, Ux research, and the final report will be delivered by September 6th.
All updates will be done asynchronously, and Gitlab is our project management system.
All link[ resources are shared here.](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/10)
**Next Step**
1.[ Gaba to complete user interview preparation after receiving the new calendar](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/6)
2.[ Gaba to connect Charles with the engineer who can help him onboard ](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/work_items/12)
3. [Harleta to provide a new user interview calendar that accommodates meetings before 8 PM UT](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/5)
4. [Gaba to complete card sort preparation after receiving the new calendar](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/7)
5. [Charles to sent interview questions draft as soon as Gaba provides more use case to identify further mission critical task.](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/27)
</details>https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40057Allow setting target, target_replace, target_prepend in projects config2023-08-02T16:21:30ZboklmAllow setting target, target_replace, target_prepend in projects configCurrently to use the `target`, `target_replace` or `target_prepend`
options, they need to be defined in `input_files`.
For some projects where we always want to change targets, it could be
useful to be able to define those options direc...Currently to use the `target`, `target_replace` or `target_prepend`
options, they need to be defined in `input_files`.
For some projects where we always want to change targets, it could be
useful to be able to define those options directly in the project's
config to avoid the need to redifine them in all the places where the
project is used in `input_files`.
/cc @richardhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129Recommend not exposing OrPort for bridges2024-02-27T18:53:18Zmeskiomeskio@torproject.orgRecommend not exposing OrPort for bridgesEnabling `AssumeReachable 1` in torrc we can avoid publishing the OrPort in bridges. Are we ok recommending to do that to bridge operators?
If we decide to move forward with this those are the steps needed for it:
* [ ] Don't use the r...Enabling `AssumeReachable 1` in torrc we can avoid publishing the OrPort in bridges. Are we ok recommending to do that to bridge operators?
If we decide to move forward with this those are the steps needed for it:
* [ ] Don't use the running flag in metrics ( https://gitlab.torproject.org/tpo/network-health/team/-/issues/318)
* [ ] update Docker images to don't expose OrPort
* [ ] obfs4
* [ ] webtunnel
* [ ] update documentation https://community.torproject.org/relay/setup/bridge/
* [ ] write an email to tor-relays@lists.torproject.org about itmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/core/torspec/-/issues/211Update statuses for several proposals2023-10-19T23:56:11ZNick MathewsonUpdate statuses for several proposalsWe have a large number of proposals that are fully or partially implemented, but which are not marked as such. We should update their status so that we have less cruft sitting around in our list of active proposals.
I believe that the ...We have a large number of proposals that are fully or partially implemented, but which are not marked as such. We should update their status so that we have less cruft sitting around in our list of active proposals.
I believe that the following proposals are OBSOLETE:
* [`098-todo.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/098-todo.txt): Proposals that should be written (Meta) @nickm ✔️
* [`099-misc.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/099-misc.txt): Miscellaneous proposals (Meta) @nickm ✔️
* [`308-counter-galois-onion.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/308-counter-galois-onion.txt): Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography (Open) (obsoleted by in-progress CGO draft) @nickm ✔️
I think that we have implemented some or all of these proposals, and they should be updated accordingly. Ones that are implemented in the form described here should be FINISHED or CLOSED depending on whether the specs are up-to-date. Ones that are _mostly_ implemented as written should be cleaned up, possibly with a section describing what did and did not get built, and marked as FINISHED.
* [`265-load-balancing-with-overhead.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/265-load-balancing-with-overhead.txt): Load Balancing with Overhead Parameters (Accepted)
* @mikeperry says: This is not done; Deferred until arti-dirauth; may become obsolete by smarter flag assigning before load balancing ✅
* [`282-remove-named-from-consensus.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/282-remove-named-from-consensus.txt): Remove "Named" and "Unnamed" handling from consensus voting (Accepted)
* @dgoulet says: This is NOT implemented. We still have Named and Unnamed being handled by our voting code. And so, it has to stay in Accepted land. ✅
* [`285-utf-8.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/285-utf-8.txt): Directory documents should be standardized as UTF-8 (Accepted)
* @dgoulet says: This is NOT implemented: https://gitlab.torproject.org/tpo/core/tor/-/issues/40131 and so it has to stay in Accepted land. ✅
* [`327-pow-over-intro.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits (Draft)
* @mikeperry says: This is Finished.
* (**Next task** 🏗️ is to review for accuracy then mark as Finished) ✅
* [`329-traffic-splitting.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting (Needs-Revision)
* @mikeperry says: This is Finished.
* (**Next task** 🏗️ is to review for accuracy then mark as Finished) ✅
* [`291-two-guard-nodes.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/291-two-guard-nodes.txt): The move to two guard nodes (Needs-Revision)
* @mikeperry says: This is done via consensus param (set to 2) ✅
* [`292-mesh-vanguards.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/292-mesh-vanguards.txt): Mesh-based vanguards (Accepted)
* @mikeperry says: Should remain "Accepted" - it seems worthwhile to have arti provide it
* (This is the one implemented in the vanguards controller)
* **Next step** 🏗️: Maybe note as "finished" or turn it into a spec along with vanguards-lite?
* [`296-expose-bandwidth-files.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/296-expose-bandwidth-files.txt): Have Directory Authorities expose raw bandwidth list files (Open)
* @dgoulet says: This is implemented. I moved it in Close state. ✔️
* [`301-dont-vote-on-package-fingerprints.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/301-dont-vote-on-package-fingerprints.txt): Don't include package fingerprints in consensus documents (Open)
* @nickm says: I'm pretty sure we did this? I can double-check.
* @nickm says: No; this is not implemented. Let's mark as acccepted?
* Accepted as torspec!159. ✔️
* [`309-optimistic-socks-in-tor.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/309-optimistic-socks-in-tor.txt): Optimistic SOCKS Data (Open)
* @dgoulet says: This is NOT implemented. ❌
* [`311-relay-ipv6-reachability.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/311-relay-ipv6-reachability.txt): Tor Relay IPv6 Reachability (Accepted)
* @dgoulet says: This is NOT implemented. ❌
* [`312-relay-auto-ipv6-addr.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/312-relay-auto-ipv6-addr.txt): Tor Relay Automatic IPv6 Address Discovery (Accepted)
* @dgoulet says: This is NOT implemented.❌
* [`313-relay-ipv6-stats.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/313-relay-ipv6-stats.txt): Tor Relay IPv6 Statistics (Accepted)
* @dgoulet says: This is NOT implemented.❌
* [`324-rtt-congestion-control.txt`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/324-rtt-congestion-control.txt): RTT-based Congestion Control for Tor (Open)
* @mikeperry says: This is Finished (and has been kept up to date with C-Tor)
* (**Next task** 🏗️ is to review for accuracy then mark as Finished) ✅
* [`331-res-tokens-for-anti-dos.md`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/331-res-tokens-for-anti-dos.md): Res tokens: Anonymous Credentials for Onion Service DoS Resilience (Draft)
* definitely not built, @nickm got confused.❌
* [`336-randomize-guard-retries.md`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries (Accepted)
* @nickm says: I believe Arti does this.
* **Next task**: double check, describe implementation status, mark FINISHED. (See !165)✔️
* [`337-simpler-guard-usability.md`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" (Accepted)
* @nickm says: I believe Arti does this.
* **Next task**: double check, describe implementation status, mark FINISHED. (See !165)✔️
We plan to implement this soon; it should be ACCEPTED:
* [`340-packed-and-fragmented.md`](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/340-packed-and-fragmented.md): Packed and fragmented relay messages (Open)
* **next action** 🏗️: @dgoulet says: I can change that. I'm working on it and have already fixes for it.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41902Add "New Circuit" to right-click context menu2023-07-20T17:00:02ZdonutsAdd "New Circuit" to right-click context menuSee [this suggestion](https://forum.torproject.org/t/suggestion-right-click-on-tab-and-offer-new-tor-circuit-for-this-site-option/8352) from a forum user.
The natural position would seem to be below "Reload" in the context menu. We shou...See [this suggestion](https://forum.torproject.org/t/suggestion-right-click-on-tab-and-offer-new-tor-circuit-for-this-site-option/8352) from a forum user.
The natural position would seem to be below "Reload" in the context menu. We should probably use the existing string in title case (i.e. "New Tor Circuit For This Site"), however that's very wordy and I think "...For This Site" can be inferred based on the context, so I'd be in favor of slimming it down to "New Circuit" here.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/169Gettor: distribute TB in bitbucket.org2024-02-27T18:23:51Zmeskiomeskio@torproject.orgGettor: distribute TB in bitbucket.orgIt looks like bitbucket is not blocked in some places where others are.It looks like bitbucket is not blocked in some places where others are.https://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/19Interactive guided tagging user flow2024-01-16T13:50:05ZRoger DingledineInteractive guided tagging user flowIt looks like the initial tagtor flow is designed around a "user realizes they want to tag a specific relay, goes to tagtor, finds the relay, tags it" flow.
To answer overall-network analysis questions, we need another flow which aims a...It looks like the initial tagtor flow is designed around a "user realizes they want to tag a specific relay, goes to tagtor, finds the relay, tags it" flow.
To answer overall-network analysis questions, we need another flow which aims at more comprehensive tagging.
I described one approach to that flow in my July 2020 tor-relays@ post (https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html):
"the next step is to figure out the workflow for annotating relays. I
had originally imagined some sort of web-based UI where it leads me
through constructing and maintaining a list of fingerprints that I have
annotated as 'known' and a list annotated as 'unknown', and it shows
me how my lists have been doing over time, and presents me with new
not-yet-annotated relays.
[...]
One of the central functions in those scripts would be to sort the
annotated relays by network impact (some function of consensus weight,
bandwidth carried, time in network, etc), so it's easy to identify the
not-yet-annotated ones that will mean the biggest shifts. Maybe this
ordered list is something we can teach onionoo to output, and then all the
local scripts need to do is go through each relay in the onionoo list,
look them up in the local annotations list to see if they're already
annotated, and present the user with the unannotated ones."
That is, the flow I am imagining is to have tagtor *sort* the relay families by importance to the network, and then present to me the top n families that I haven't yet tagged as roger-known or roger-unknown. Then I can do a bit of work at a time, put it down, come back later, and at any moment I can be answering the highest impact questions about the network.
Then there are some secondary metrics that would be good to hear, which should pop out of the sorting, such as "what fraction of the network have I tagged in some way", "what fraction is roger-known", "what fraction is roger-unknown".
The sorting function can start really simple, like "sum of consensus weights of members of family" but we can imagine fancier ones later, like putting higher priority on big relay groups that *other people* haven't tagged yet either.TagTor is completed for its scope in Sponsor 112HiroHirohttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf-ansible/-/issues/2Add iptables-nft rules to ansible2024-01-16T14:01:52ZHiroAdd iptables-nft rules to ansibleThere is a part of setting up an onionperf client that we still do manually and this implies adding a redirect between port 443 and 8080 so that tgen can do its measurements. I think we should add this to the recipes.There is a part of setting up an onionperf client that we still do manually and this implies adding a redirect between port 443 and 8080 so that tgen can do its measurements. I think we should add this to the recipes.HiroHirohttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/203Identify any differences in browser fingerprint between Flatpak package and o...2023-09-12T22:15:23ZrichardIdentify any differences in browser fingerprint between Flatpak package and ordinary tarballFlathub: https://flathub.org/apps/net.mullvad.MullvadBrowser
github: https://github.com/flathub/net.mullvad.MullvadBrowser
The flathub community has published and maintains a package for Mullvad Browser. We should make sure package they...Flathub: https://flathub.org/apps/net.mullvad.MullvadBrowser
github: https://github.com/flathub/net.mullvad.MullvadBrowser
The flathub community has published and maintains a package for Mullvad Browser. We should make sure package they ship has the same fingerprint as the tarball on the same system.
@thorin is this something you'd like to o?https://gitlab.torproject.org/tpo/ux/research/-/issues/115Evaluate if Tor Browser is meeting the needs of our users2023-06-28T16:20:06ZMatthew FinkelEvaluate if Tor Browser is meeting the needs of our usersTor Browser has many goals as defined in the [Design document](https://2019.www.torproject.org/projects/torbrowser/design/), but we should take a step backward and look at the larger picture of whether these goals are actually important ...Tor Browser has many goals as defined in the [Design document](https://2019.www.torproject.org/projects/torbrowser/design/), but we should take a step backward and look at the larger picture of whether these goals are actually important for the [people](https://community.torproject.org/user-research/persona/) we are trying to protect.
We should be able to justify our general design requirements through the needs of our users, instead of defining the strictest-possible private browser design and then applying that to all of the use cases. Indeed, this should influence tpo/applications/tor-browser-spec#25021.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/190Create an `about:health` page2023-07-10T15:26:04ZruihildtCreate an `about:health` pageTo quote @ma1 and @thorin from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41845
> (...) some kind of permanent sanity check (one global preference observer would do) which alerts users (in about:tor, about:prefe...To quote @ma1 and @thorin from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41845
> (...) some kind of permanent sanity check (one global preference observer would do) which alerts users (in about:tor, about:preferences, about:config...) of every configuration change which we deem defeats Tor Browser's purpose (we've discussed this in Costa Rica, IIRC).
__
> an `about:fingerprinthealth` dashboard - including the extensions stuff (not bundled, web-accessible, etc) - something like TZP's attack template for css/engine/element/doc properties cover hundreds of pref changes - i.e we expect a deterministic result, and prototype/proxy changes can detect NoScripts signature for extensions
> one issue here is this is a two edged sword, so we would need to word things carefully - i.e just because something is not detected (that affects your FP/health), doesn't mean it isn't there
We could maybe separate `about:health` and `about:fringerprint` in two different issues as well.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/44Review when a bridge is labeled as online or offline2023-10-09T11:24:01ZHiroReview when a bridge is labeled as online or offlineWe currently use both bridgestrap tests and online/offline flag from the bridge authority to mark when a bridge is online or offline.
We might have to review all the rules that we are currently using and document them. If necessary we ...We currently use both bridgestrap tests and online/offline flag from the bridge authority to mark when a bridge is online or offline.
We might have to review all the rules that we are currently using and document them. If necessary we should check if we can change these rules.
@meskio do we have any other test that we are currently performing for bridges besides bridgestrap?https://gitlab.torproject.org/tpo/web/community/-/issues/315[Onion Services] Add other popular and well maintained tools2023-11-01T12:51:00ZGus[Onion Services] Add other popular and well maintained toolsLet's add some popular and well maintained onion services tools here: https://community.torproject.org/onion-services/#tools
- CWTCH: https://tryquiet.org/
- Quiet: https://tryquiet.org/
- Ricochet-refresh: https://www.ricochetrefresh.net/Let's add some popular and well maintained onion services tools here: https://community.torproject.org/onion-services/#tools
- CWTCH: https://tryquiet.org/
- Quiet: https://tryquiet.org/
- Ricochet-refresh: https://www.ricochetrefresh.net/https://gitlab.torproject.org/tpo/core/arti/-/issues/907crate/module organisation: location of dummy implementations, etc.2023-06-26T15:57:37ZIan Jacksoniwj@torproject.orgcrate/module organisation: location of dummy implementations, etc.We have various features that can be compiled out.
The "obvious" way of implementing this is to apply `#[cfg]` to relevant items.
In practice, however, this results in a great proliferation of `#[cfg]`:
it needs to be applied to many st...We have various features that can be compiled out.
The "obvious" way of implementing this is to apply `#[cfg]` to relevant items.
In practice, however, this results in a great proliferation of `#[cfg]`:
it needs to be applied to many struct fields,
constructor parameters
(which is itsself problematic since it makes the arity depend on the config)
expressions, method calls, etc. etc.
Often a better approach is to provide standin types,
when the feature is disabled.
This allows much more of the code to be written the same way.
For an example, consider bridge support.
`tor-guardmgr/src/bridge_disabled.rs` contains:
* `BridgeConfigBuilder`, a unit, which allows the config to be deserialised
* `BridgeConfigBuilder::build` which always fails
* `BridgeConfig`, a configured bridge, as an uninhabited type
As a result, the main config handling code can unconditionally
attempt to build its `Vec<BridgeConfig>` from its `BridgeConfigBuilder`s.
However, we don't adopt this pattern consistently,
partly because there are some unsolved problems:
### Dummy implementation location
When what needs to be stubbed out is a whole crate,
we don't know where to put the implementation.
Options seem to include:
1. `tor-basic-utils`. But that may not have access to all the needed types.
And it seems an abuse of the crate.
2. Some other central crate.
But we might run into crate hieararchy difficulties;
different stubs might to mention, and define,
types that live at different levels in our stack.
3. Possibly several such central crates,
splitting ad-hoc as needed.
This seems like it would be hard to navigate.
4. A dedicated stub crate for each thing we might want to stub out.
But we already have dozens of crates,
and this isn't just one or two more -
it's a multiplying our number of crates by a constant factor >1.
5. In each case in "the next crate up",
and higher-layer crates should depend on that one.
This will produce weird and artificial crate dependencies.
6. By the to-be-stubbed crate, according to some feature flags.
This will mean moving the implementation into an internal module,
which is cfg'd and can be re-exported at the toplevel.
It might result in unwieldy source code paths,
but maybe judicious use of `#[path]` could help.
Of these I think 6 is best.
In particular, it means that types referenced from super-crates
are als "the same type", ie the owning crate's possibly-dummy type,
ensuring additiveness.
But we need to think about what the feature structure is.
We can't have a "stub-only" feature,
since that's co-additive - the opposite of what we want.
So I think we need an "actually does the thing" feature.
Transition plans are left as an exercise to the reader.
### Some types are `Arc<ThingMgr>` or `Arc<MutexMgr<Thing>>`
Suppose `ThingMgr` is stubbed out.
We want it to not impose any runtime or executable size costs.
The manager needs to be inhabited
so one of it can live in `TorClient`;
we want `TorClient` to have a ZST for it.
But even if `ThingMgr` is a unit ZST,
`Arc<ThingMgr>` incurs a heap allocation,
and the `Arc` is the size of a pointer.
Worse is things like `bridge_desc_mgr` in `TorClient`
which is `Arc<Mutex<Option<Arc<BridgeDescMgr>>>>`.
Options seem to include:
1. Live with the heap allocation
2. Have the definer provide `ArcThingMgr` as an alias for `Arc<ThingMgr>`;
when disabled, make it simply be `ThingMgr` or a new newtype?
Not sure how this helps with `Option<Mutex<...>>`.
3. keep applying `#[cfg]`
I think probably 1 or 2 are good for things in `TorClient`,
which is quite heavyweight anyway.
We could do 3 for fields in objects of greater multiplicity.
### Error enums, ensuring additiveness
Typically we will want the stub error enum to just have a "feature disabled" variant.
But to ensure additiveness we should somehow make sure that it's
the same as the real enum's "not implemented" variant.
Options:
1. `#[cfg]` each "real" variant, ie all the ones except the "feature disabled" variant.
Downside: verbose, easy to omit one and incrementally bloat the feature-disabled build.
2. Simply write the two enums out separately,
and try to ensure similarity with tests
3. Macrology of various kinds, for example a macro_rules macro that does
"define error enum with the following variants and also a "feature disabled"
4. (Non-option) generate just the feature-disabled variant with a macro.
Macros are not supported by Rust in enum variant position :-/.
I suggest we do 1 like in `tor_guardmgr::bridge::config::err`, for now.
Possibly derive-adhoc will provide a better way to do this in the future.
CC @gabi-250, @nickmhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/97Consider adding a "No internet" state2024-03-27T17:28:52Zmicahmicah@torproject.orgConsider adding a "No internet" stateI was in an airport, with fairly restrictive internet. I had connected to the captive portal and logged in, so I could use the free airport wifi, and I wanted to turn on the Tor VPN to obfuscate my traffic. I launched it, pressed the con...I was in an airport, with fairly restrictive internet. I had connected to the captive portal and logged in, so I could use the free airport wifi, and I wanted to turn on the Tor VPN to obfuscate my traffic. I launched it, pressed the connect button, and it showed connected, and data transfer rates started to show.
However, nothing was loading in my browser on my device, so I went to go look at the logs, and I found that onionmasq underneath was complaining about failing to connect to the tor network, it clearly was not actually connected and was retrying, but the UI was showing I was connected and that data was being transferred.
I failed to copy the logs, and I realize that its not trivial to re-produce this, but I thought I should file an issue to get this out there.VPN pre-alpha 07donutsdonutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41843Create a pluggable API to interact with tor2023-08-26T04:49:18ZPier Angelo VendrameCreate a pluggable API to interact with torSooner or later, we'll want to interact with Arti.
Therefore, we should create an API that can work with multiple backends:
- the control port
- Arti
- maybe some mock for testingSooner or later, we'll want to interact with Arti.
Therefore, we should create an API that can work with multiple backends:
- the control port
- Arti
- maybe some mock for testinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40803Cannot write to ClientOnionAuthDir when Sandbox is enabled2023-06-05T16:46:55ZanonymCannot write to ClientOnionAuthDir when Sandbox is enabled### Summary
When `tor` has the sandbox option enabled it cannot write to the `ClientOnionAuthDir` directory to store onion auth keys, e.g. when checking the "Remember this key" checkbox in Tor Browser when providing the key.
### Steps ...### Summary
When `tor` has the sandbox option enabled it cannot write to the `ClientOnionAuthDir` directory to store onion auth keys, e.g. when checking the "Remember this key" checkbox in Tor Browser when providing the key.
### Steps to reproduce:
1. Configure `tor` with `Sandbox 1`
2. Configure `tor` with `ClientOnionAuthDir /some/writable/directory`
3. Use Tor Browser to access an onion service with onion authentication
4. Check the "Remember this key" checkbox when providing the key
### What is the current bug behavior?
The onion auth prompt in Tor Browser reports "Unable to store creds for ...", and no key is written to the `ClientOnionAuthDir` directory.
### What is the expected behavior?
No errors, and the key should be written to the `ClientOnionAuthDir` directory.
### Environment
- Tor version 0.4.7.13
- Tested both on Debian Sid and inside Tails with `tor` installed via `apt`
### Relevant logs and/or screenshots
```
Jun 02 13:04:02.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private.tmp (on Tor 0.4.7.13 )
Jun 02 13:00:25.000 [warn] Couldn't open "/var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private.tmp" (/var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private) for writing: Operation not permitted
Jun 02 13:00:25.000 [warn] Failed to write client auth creds file for n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd!
```
### Possible fixes
Update the sandbox rules.Tor: 0.4.9.x-freeze