The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-12-07T12:16:52Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1016Remove webpki transitive dependency somehow.2023-12-07T12:16:52ZNick MathewsonRemove webpki transitive dependency somehow.Because of https://rustsec.org/advisories/RUSTSEC-2023-0052 , we want to get rid of the transitive `webpki` dependency from `tls-api` in `arti-hyper`. The `webpki` crate is unmaintained; the `rustls-webpki` crate is apparently what is r...Because of https://rustsec.org/advisories/RUSTSEC-2023-0052 , we want to get rid of the transitive `webpki` dependency from `tls-api` in `arti-hyper`. The `webpki` crate is unmaintained; the `rustls-webpki` crate is apparently what is recommended instead.
I've opened an issue in `tls-api` as https://github.com/stepancheg/rust-tls-api/issues/45.
But also see #509 and https://github.com/stepancheg/rust-tls-api/issues/44. I suspect `tls-api` may be unmaintained?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42032Opening NoScript settings before the bootstrap opens about:blank2023-10-11T21:41:00ZPier Angelo VendrameOpening NoScript settings before the bootstrap opens about:blankWe get this permission error:
```
Security Error: Content at moz-extension://c725a3ae-a1ae-4fa9-a895-f27a86f59f86/ may not load or link to about:torconnect?redirect=moz-extension%3A%2F%2Fc725a3ae-a1ae-4fa9-a895-f27a86f59f86%2Fui%2Fpopup...We get this permission error:
```
Security Error: Content at moz-extension://c725a3ae-a1ae-4fa9-a895-f27a86f59f86/ may not load or link to about:torconnect?redirect=moz-extension%3A%2F%2Fc725a3ae-a1ae-4fa9-a895-f27a86f59f86%2Fui%2Fpopup.html%23tab1.
```
Steps to reproduce:
1. Open the browser, and stay on `about:torconnect`
2. Right click on NoScript (you'll need to click on its icon in the Extensions panel)
3. Click again on NoScript
4. You will get an empty about:blank
Probably, we should not redirect `moz-extension` URLs, and let that other page load.https://gitlab.torproject.org/tpo/core/arti/-/issues/1012Consider using `cackle` to check our dependencies' API usage2023-10-14T10:59:54ZNick MathewsonConsider using `cackle` to check our dependencies' API usageThis looks potentially interesting: https://crates.io/crates/cackle
It audits crates to make sure they aren't calling anything that you think they shouldn't.This looks potentially interesting: https://crates.io/crates/cackle
It audits crates to make sure they aren't calling anything that you think they shouldn't.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/229uBO doesn't apply cosmetic filters unless added via picker and only for the s...2024-03-05T14:56:58ZThorinuBO doesn't apply cosmetic filters unless added via picker and only for the sessionat least for images (from https://github.com/mullvad/mullvad-browser/issues/127 )
STR
add cosmetic filters, save/apply
```
||www.google.com/images/branding/googlelogo/*x/googlelogo_light_color_272x92dp.png$image
||www.google.com/images/...at least for images (from https://github.com/mullvad/mullvad-browser/issues/127 )
STR
add cosmetic filters, save/apply
```
||www.google.com/images/branding/googlelogo/*x/googlelogo_light_color_272x92dp.png$image
||www.google.com/images/branding/googlelogo/*x/googlelogo_color_272x92dp.png$image
```
visit google.com .. image loads
now add the filter from the picker (doesn't matter if it adds a duplicate entry), the image is removed. open a new tab, close the current google tab, open google, image is blocked.
restart, check filters (they are there), load google .. image is not blocked
note: can't reproduce the issue on ESR102 starting PB mode, or any FF releaseshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42025Purple elements (e.g. Tor buttons) need dark theme variants2024-01-29T19:17:37ZdonutsPurple elements (e.g. Tor buttons) need dark theme variantsThere are several components in the browser that use the Photon purple color scheme instead of Fx's default blue, including (but potentially not limited to):
- "Tor Browser" in the identity block
- "Connect" buttons
- ".onion" available...There are several components in the browser that use the Photon purple color scheme instead of Fx's default blue, including (but potentially not limited to):
- "Tor Browser" in the identity block
- "Connect" buttons
- ".onion" available buttons
- "Connected" status in the title bar
- "Connected" flag on bridge cards
- Connection status spinners
And in the new homepage being developed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41333:
- Links
- Onionize toggle
Typically, these use the following values for light theme:
- default: purple-60 `#8000D7`
- hover: purple-70 `#6200A4`
- pressed: purple-80 `#440071`
- focus: purple-60 `#8000D7`
And were designed to use the following values for dark theme, however this never happened:
- default: purple-30 `#C069FF`
- hover: purple-40 `#AD3BFF`
- pressed: purple-50 `#9400FF`
- focus: purple-60 `#C069FF`
There are three issues here:
1. Semantic color tokens for dark theme were never created.
2. As @henry has rightfully pointed out, the previous design for dark theme went darker on interaction – which is unusual, and not accessible. However we were limited by a lack of having anything lighter than purple-30 in the browser.
3. The purples used are out of date (having originated from Photon), and have since been superseded by new purple color tokens documented in the [Acorn](https://acorn.firefox.com/latest/styles/color-MZHBVuZc) and [Protocol](https://protocol.mozilla.org/docs/fundamentals/color.html) styleguides.
In order to fix this, we'll need to update our existing purple color tokens to include lighter steps. This could be done by migrating to the new values documented in Acorn/Protocol, or by using a custom purple palette.https://gitlab.torproject.org/tpo/core/tor/-/issues/40836Update recommended/required protocol lists?2024-01-16T15:38:37ZNick MathewsonUpdate recommended/required protocol lists?We haven't updated the recommended/required protocol lists since 2021, possibly longer. If we mark more protocols as required or recommended, we can more correctly reason about the network.
The protocols that are unconditionally suppor...We haven't updated the recommended/required protocol lists since 2021, possibly longer. If we mark more protocols as required or recommended, we can more correctly reason about the network.
The protocols that are unconditionally supported by 0.4.7.7 (our oldest supported stable) are:
* `Cons=1-2 Desc=1-2 DirCache=2 FlowCtrl=1-2 HSDir=2 HSIntro=4-5 HSRend=1-2 Link=1-5 LinkAuth=3 Microdesc=1-2 Padding=2 Relay=1-4`
The protocols that are unconditionally supported by the most recent Arti are not currently listed anywhere or enforced in Arti. :disappointed: So maybe we should take care of that first?
The protocols that the consensus currently recommends are:
* `recommended-client-protocols Cons=2 Desc=2 DirCache=2 HSDir=2 HSIntro=4 HSRend=2 Link
=4-5 Microdesc=2 Relay=2`
* `recommended-relay-protocols Cons=2 Desc=2 DirCache=2 HSDir=2 HSIntro=4 HSRend=2 Link=4-5 LinkAuth=3 Microdesc=2 Relay=2`
The protocols that the consensus currently requires are:
* `required-client-protocols Cons=2 Desc=2 Link=4 Microdesc=2 Relay=2`
* `required-relay-protocols Cons=2 Desc=2 DirCache=2 HSDir=2 HSIntro=4 HSRend=2 Link=4-5 LinkAuth=3 Microdesc=2 Relay=2`
cc @dgoulet @mikeperryNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1006Enable -Dwarnings for every-crate script?2023-08-23T13:59:06ZNick MathewsonEnable -Dwarnings for every-crate script?See !1507: it appears pretty easy for warnings to accumulate for these configurations. We could detect them more readily if we added `export RUSTFLAGS="-Dwarnings"` to `maint/every-crate`, but doing so would be yet one more thing that o...See !1507: it appears pretty easy for warnings to accumulate for these configurations. We could detect them more readily if we added `export RUSTFLAGS="-Dwarnings"` to `maint/every-crate`, but doing so would be yet one more thing that our CI would sometimes complain about.
@gabi-250 @Diziet What do you think? Is this worth it?Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/109Leak Canary reports ConnectionFragment.binding as having a distinct leak2023-09-07T21:25:43Zmicahmicah@torproject.orgLeak Canary reports ConnectionFragment.binding as having a distinct leakUsing the 425e2e1d version of the vpn, on a google pixel 4a(5g), running calyxOS. I get often a LeakCanary reporting a problem.
This is the leak trace that I printed to Logcat, I am not sure which pieces are useful to share, but I can p...Using the 425e2e1d version of the vpn, on a google pixel 4a(5g), running calyxOS. I get often a LeakCanary reporting a problem.
This is the leak trace that I printed to Logcat, I am not sure which pieces are useful to share, but I can provide more:
```
08-11 11:14:04.988 22504 22535 D LeakCanary: LeakCanary is running and ready to detect memory leaks.
08-11 11:20:59.863 22504 22504 D LeakCanary:
08-11 11:20:59.863 22504 22504 D LeakCanary: ┬───
08-11 11:20:59.863 22504 22504 D LeakCanary: │ GC Root: System class
08-11 11:20:59.863 22504 22504 D LeakCanary: │
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ android.app.ActivityThread class
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (MainActivity↓ is not leaking and a class is never leaking)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ static ActivityThread.sCurrentActivityThread
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ android.app.ActivityThread instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (MainActivity↓ is not leaking)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ mInitialApplication instance of org.torproject.vpn.TorApplication
08-11 11:20:59.863 22504 22504 D LeakCanary: │ mSystemContext instance of android.app.ContextImpl
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ ActivityThread.mActivities
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ android.util.ArrayMap instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (MainActivity↓ is not leaking)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ ArrayMap.mArray
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ java.lang.Object[] array
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (MainActivity↓ is not leaking)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ Object[1]
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ android.app.ActivityThread$ActivityClientRecord instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (MainActivity↓ is not leaking)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ activity instance of org.torproject.vpn.MainActivity with mDestroyed = false
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ ActivityThread$ActivityClientRecord.activity
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ org.torproject.vpn.MainActivity instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (ConnectionFragment↓ is not leaking and Activity#mDestroyed is false)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ mApplication instance of org.torproject.vpn.TorApplication
08-11 11:20:59.863 22504 22504 D LeakCanary: │ mBase instance of androidx.appcompat.view.ContextThemeWrapper
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ ComponentActivity.mOnConfigurationChangedListeners
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ java.util.concurrent.CopyOnWriteArrayList instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (ConnectionFragment↓ is not leaking)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ CopyOnWriteArrayList[5]
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ androidx.fragment.app.FragmentManager$$ExternalSyntheticLambda0 instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (ConnectionFragment↓ is not leaking)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ FragmentManager$$ExternalSyntheticLambda0.f$0
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ androidx.fragment.app.FragmentManagerImpl instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (ConnectionFragment↓ is not leaking)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ FragmentManager.mParent
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ org.torproject.vpn.ui.connectionsettings.ConnectionFragment instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: NO (Fragment#mFragmentManager is not null)
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Fragment.mTag=a2ad2df2-7ab9-468b-87c5-c4f7355dccb2
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ ConnectionFragment.binding
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ~~~~~~~
08-11 11:20:59.863 22504 22504 D LeakCanary: ├─ org.torproject.vpn.databinding.FragmentConnectionsettingsBindingImpl instance
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Leaking: UNKNOWN
08-11 11:20:59.863 22504 22504 D LeakCanary: │ Retaining 464.4 kB in 4226 objects
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ↓ ViewDataBinding.mRoot
08-11 11:20:59.863 22504 22504 D LeakCanary: │ ~~~~~
08-11 11:20:59.863 22504 22504 D LeakCanary: ╰→ androidx.coordinatorlayout.widget.CoordinatorLayout instance
08-11 11:20:59.863 22504 22504 D LeakCanary: Leaking: YES (ObjectWatcher was watching this because org.torproject.vpn.ui.connectionsettings.ConnectionFragment
08-11 11:20:59.863 22504 22504 D LeakCanary: received Fragment#onDestroyView() callback (references to its views should be cleared to prevent leaks))
08-11 11:20:59.863 22504 22504 D LeakCanary: Retaining 2.7 kB in 71 objects
08-11 11:20:59.863 22504 22504 D LeakCanary: key = 67f37547-40c5-44fc-a4de-cac3c33512f6
08-11 11:20:59.863 22504 22504 D LeakCanary: watchDurationMillis = 31085
08-11 11:20:59.863 22504 22504 D LeakCanary: retainedDurationMillis = 26083
08-11 11:20:59.863 22504 22504 D LeakCanary: View not part of a window view hierarchy
08-11 11:20:59.863 22504 22504 D LeakCanary: View.mAttachInfo is null (view detached)
08-11 11:20:59.863 22504 22504 D LeakCanary: View.mWindowAttachCount = 1
08-11 11:20:59.863 22504 22504 D LeakCanary: mContext instance of org.torproject.vpn.MainActivity with mDestroyed = false
08-11 11:20:59.863 22504 22504 D LeakCanary:
08-11 11:20:59.863 22504 22504 D LeakCanary: METADATA
08-11 11:20:59.863 22504 22504 D LeakCanary:
08-11 11:20:59.863 22504 22504 D LeakCanary: Build.VERSION.SDK_INT: 33
08-11 11:20:59.863 22504 22504 D LeakCanary: Build.MANUFACTURER: Google
08-11 11:20:59.863 22504 22504 D LeakCanary: LeakCanary version: 2.9.1
08-11 11:20:59.863 22504 22504 D LeakCanary: App process name: org.torproject.vpn
08-11 11:20:59.863 22504 22504 D LeakCanary: Class count: 25281
08-11 11:20:59.863 22504 22504 D LeakCanary: Instance count: 191621
08-11 11:20:59.863 22504 22504 D LeakCanary: Primitive array count: 129463
08-11 11:20:59.863 22504 22504 D LeakCanary: Object array count: 24642
08-11 11:20:59.863 22504 22504 D LeakCanary: Thread count: 29
08-11 11:20:59.863 22504 22504 D LeakCanary: Heap total bytes: 26478243
08-11 11:20:59.863 22504 22504 D LeakCanary: Bitmap count: 1
08-11 11:20:59.863 22504 22504 D LeakCanary: Bitmap total bytes: 222481
08-11 11:20:59.863 22504 22504 D LeakCanary: Large bitmap count: 0
08-11 11:20:59.863 22504 22504 D LeakCanary: Large bitmap total bytes: 0
08-11 11:20:59.863 22504 22504 D LeakCanary: Stats: LruCache[maxSize=3000,hits=115115,misses=192140,hitRate=37%]
08-11 11:20:59.863 22504 22504 D LeakCanary: RandomAccess[bytes=9849438,reads=192140,travel=93180964532,range=31716041,size=39433354]
08-11 11:20:59.863 22504 22504 D LeakCanary: Analysis duration: 9444 ms
```VPN pre-alpha 03cybertacybertahttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/222Hide "List all tabs" when the tabs don't overflow2023-09-28T17:41:51ZruihildtHide "List all tabs" when the tabs don't overflowA new Firefox (or is it chromium?) innovation is to add an icon at the end of the tab bar with a dropdown showing a list of all tabs open.
It's possible only display the icon when tabs are overflowing by setting `browser.tabs.tabmanager...A new Firefox (or is it chromium?) innovation is to add an icon at the end of the tab bar with a dropdown showing a list of all tabs open.
It's possible only display the icon when tabs are overflowing by setting `browser.tabs.tabmanager.enabled` to `false`.
This was the default behavior until ESR 115.
It feels to me that it may be better to keep that option, because it keeps it cleaner for those who don't tab hoard and will appear when you need it.
If users really want it, then we could change it a that point to default.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41992Tor Browser Android Onboarding missing in 13.02024-03-04T15:04:58ZDan BallardTor Browser Android Onboarding missing in 13.0tor browser android has an onboarding built into the home page on android. the changes to onboarding appear to be preventing it from triggering
<details><summary> screenshot of onboarding from 12.5</summary>
![20230809_161407](/uploads/...tor browser android has an onboarding built into the home page on android. the changes to onboarding appear to be preventing it from triggering
<details><summary> screenshot of onboarding from 12.5</summary>
![20230809_161407](/uploads/f9a6cbc10d7c3163411006639457b089/20230809_161407.jpg)
</details>Dan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988Tor Browser history leaked to syslogs via GNOME2023-12-18T13:51:55ZhonortonTor Browser history leaked to syslogs via GNOME### Summary
Tab titles are sometimes logged by GNOME to `/var/log/syslog`, effectively causing browsing habits to persist on the system, even after closing Tor Browser. As Tor Browser does not save history by default, many users will not...### Summary
Tab titles are sometimes logged by GNOME to `/var/log/syslog`, effectively causing browsing habits to persist on the system, even after closing Tor Browser. As Tor Browser does not save history by default, many users will not expect this.
### Steps to reproduce:
1. Open a new Tor Browser window.
2. (optional) "Connect" to the Tor network and navigate to an arbitrary website.
3. Press the Super key (default) to open the GNOME activities menu.
4. Review syslog via `cat /var/log/syslog | grep -i "browser"`
### What is the current bug behavior?
I see results containing Tor Browser tab titles, such as the titles of opened websites.
### What is the expected behavior?
I expect not to see my visited website titles in any system file without my authorization.
More strongly, I don't expect GNOME (which may log all sorts of things) to require access to my visited website titles.
### Environment
- OS Version: Pop! OS 22.04
- GNOME Shell Version: 3.38.6
- Tor Browser Version: 12.5.2
- Tor Browser Installation Method: "Linux" binary from `https://www.torproject.org/download/`
### Relevant logs and/or screenshots
```
[/var/log/syslog]
[snip]
Aug 9 11:23:52 pop-os gnome-shell[2864]: Couldn't find child [0x5558d69f7880 Gjs_ui_windowPreview_WindowPreview ("cute cats at DuckDuckGo — Tor Browser")] in window slots
Aug 9 11:23:53 pop-os gnome-shell[2864]: Couldn't find child [0x5558d69f7880 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("cute cats at DuckDuckGo — Tor Browser")] in window slots
Aug 9 11:27:28 pop-os gnome-shell[2864]: Couldn't find child [0x5558da9ea870 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("[Wayland] [3.38.3] Shell freezes/stops reacting to most input (#3706) · Issues · GNOME / gnome-shell · GitLab — Tor Browser")] in window slots
Aug 9 11:27:31 pop-os gnome-shell[2864]: Couldn't find child [0x5558da9ea870 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("[Wayland] [3.38.3] Shell freezes/stops reacting to most input (#3706) · Issues · GNOME / gnome-shell · GitLab — Tor Browser")] in window slots
[snip]
```Pier Angelo VendramePier Angelo Vendrame2023-11-13https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41987Tor Browser Android Onboarding Plan2024-02-15T14:50:10ZDan BallardTor Browser Android Onboarding PlanWe want a plan for onboarding in Android. Mozilla did a big refactor in 113 and 114 to theirs. I've captured what it looks like in the attached screen shots. It's flow is:
- single page asking about notifications
- onboarding "cards" pag...We want a plan for onboarding in Android. Mozilla did a big refactor in 113 and 114 to theirs. I've captured what it looks like in the attached screen shots. It's flow is:
- single page asking about notifications
- onboarding "cards" page with settings for
- dark/light theme
- url bar placement (top/bottom)
- sync / signin
- Privacy / "Total cookie protection"
- link to privacy policy
<details>
<summary>large screen shots</summary>
![20230809_120707](/uploads/57f8e9ffe15473f2f308113c6521fc1b/20230809_120707.jpg)
![20230809_120714](/uploads/08705434d1b35a26e76526263964906a/20230809_120714.jpg)
![20230809_120724](/uploads/751321394849bef7cac7a7878213f1b0/20230809_120724.jpg)
![20230809_120730](/uploads/ddf2d454b9620716e56b7c9162edf08b/20230809_120730.jpg)
</details>
Apparently Desktop onboarding in torbrowser just asks about Security Level right now
Current plan agreed upon by @pierov and @donuts is:
- nuke the onboarding entierly in android for 13.0
- try and have onboarding for 13.5 with our security level and url bar placement
- @dan notes trying to use the new card based approach might be viable and easy once learned
- @pierov suggests maybe just adding it tor about:tor html pagehttps://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/ux/team/-/issues/82Consider merging the global "UX" and "UX Team" labels into "Needs UX"2024-03-07T14:49:42ZdonutsConsider merging the global "UX" and "UX Team" labels into "Needs UX"At present, we have two similar-but-different global UX labels:
- ~UX: which people use across the Tor Project to indicate an issue that has some impact on the user experience of our products.
- ~"UX Team": which we use to track issues ...At present, we have two similar-but-different global UX labels:
- ~UX: which people use across the Tor Project to indicate an issue that has some impact on the user experience of our products.
- ~"UX Team": which we use to track issues that will require work from a member of the UX Team.
Given that the bucked of issues that could be tagged as ~UX is very, very broad – and not necessarily useful to filter by – I'm beginning to think we should replace both with a `Needs UX` label that's far narrower in scope. This label should then be used to invoke a UX team-member, rather than pinging people individually in Gitlab or IRC, and can remain tagged as such until the UX Team feels it's no longer necessary to track the issue on our kanban.
So, thoughts?https://gitlab.torproject.org/tpo/core/arti/-/issues/1001Connection problems where Arti 'sticks' to a faulty circuit2023-11-15T19:01:19ZetaConnection problems where Arti 'sticks' to a faulty circuitI'm writing this from a train using arti & onionmasq-linux (!) -- and earlier in the journey, I noticed some probably erroneous behaviour:
- I had connected to an `.onion` service successfully, and then my connection changed (due to me ...I'm writing this from a train using arti & onionmasq-linux (!) -- and earlier in the journey, I noticed some probably erroneous behaviour:
- I had connected to an `.onion` service successfully, and then my connection changed (due to me switching wifi networks).
- This presumably meant the old circuit was no longer usable. However, Arti continued to try and use it anyway for new connections to that service (understandable enough).
- The first attempt to do so failed, with "timed out waiting for exit" given as error reason.
- However, subsequent attempts tried to use it also failed, with the same error message -- I could no longer connect, despite having (now) working internet connection more generally.
- Restarting Arti got things to work again.
It would be nice if we had some sort of mechanism to detect 'stuck' circuits and retry by building different circuits, since this behaviour is quite annoying! I wonder whether it's specific to onion services, since I haven't noticed this in any other usecase.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41975Downloads warning text too narrow in 13.0 alpha2023-10-03T13:28:21ZdonutsDownloads warning text too narrow in 13.0 alphaSomething odd is going on with the width of the downloads warning description in the downloads wingpanel:
<img src="/uploads/6acb35f78c2e973d26c916feb844d6eb/downloads-warning-13-0_2x.png" width=508px />Something odd is going on with the width of the downloads warning description in the downloads wingpanel:
<img src="/uploads/6acb35f78c2e973d26c916feb844d6eb/downloads-warning-13-0_2x.png" width=508px />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/-/issues/997New function (on NetDirProvider? or extension trait?) to block until a netdir...2023-08-04T15:52:12ZNick MathewsonNew function (on NetDirProvider? or extension trait?) to block until a netdir is availableSee discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1465#note_2928347 : it's probably useful sometimes to have an async function that either returns a timely netdir, or blocks until we have one.
(This is espec...See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1465#note_2928347 : it's probably useful sometimes to have an async function that either returns a timely netdir, or blocks until we have one.
(This is especially handy for code that wants to act sensibly while waiting for re-bootstrap.)
I'm adding one to tor-hsservice as part of my intro-points work, but it's likely it should move elsewhere.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41966Cannot remove locales from the locale alternatives list2023-09-18T19:45:01ZhenryCannot remove locales from the locale alternatives list## Steps to reproduce
Tested in 12.5.2:
1. Go to "Language" in "about:preferences".
2. Click "Set Alternatives...".
3. Add a language to the list.
## Result
No way to remove the added language from the alternatives list because the "...## Steps to reproduce
Tested in 12.5.2:
1. Go to "Language" in "about:preferences".
2. Click "Set Alternatives...".
3. Add a language to the list.
## Result
No way to remove the added language from the alternatives list because the "Remove" button is disabled. The only option is to move it up and down.
## Expect
Be able to remove locales from the list.
I think this is a limitation may be coming from firefox to not allow the user to removing packaged locales.henryhenryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/995Make ErrorReport not be Sized so we can return Box<dyn ErrorReport> for Arti ...2023-08-28T12:36:27ZSaksham MittalMake ErrorReport not be Sized so we can return Box<dyn ErrorReport> for Arti errorsIt'd be nice to have all Tor-related errors be represented as `Box<dyn ErrorReport>` so we can call the `report()` method on them for a nice, pretty-printed error.
This way, other application developers could possibly use the report out...It'd be nice to have all Tor-related errors be represented as `Box<dyn ErrorReport>` so we can call the `report()` method on them for a nice, pretty-printed error.
This way, other application developers could possibly use the report output and display it in different ways, as well as be able to represent Arti-related errors conveniently.