The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-12-05T11:08:05Zhttps://gitlab.torproject.org/tpo/network-health/exitmap/-/issues/41Allow specifying a target host/website per command line2023-12-05T11:08:05ZGeorg KoppenAllow specifying a target host/website per command lineWe are used to hardcode destinations which `exitmap` is supposed to check but it would be useful to have the option to pass target hosts/websites per command line instead. We could think about allowing host:port changes of destinations o...We are used to hardcode destinations which `exitmap` is supposed to check but it would be useful to have the option to pass target hosts/websites per command line instead. We could think about allowing host:port changes of destinations or maybe just host changes at first.Corl3ssCorl3sshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/13Fix stability issue discovered in WebTunnel2023-03-10T14:14:19ZshelikhooFix stability issue discovered in WebTunnelCurrently, the WebTunnel PT process may quit with "tor[2939]: Aug 25 15:58:19.000 [warn] Pluggable Transport process terminated with status code 512". Investigate is necessary to locate the root casue of problem.Currently, the WebTunnel PT process may quit with "tor[2939]: Aug 25 15:58:19.000 [warn] Pluggable Transport process terminated with status code 512". Investigate is necessary to locate the root casue of problem.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41644fonts linux: test whitelist breakage2023-04-17T15:03:19ZThorinfonts linux: test whitelist breakagenot an issue, but a Q for @pierov
In my much awaited but not yet deployed new fang-dangled snazzy TZP (30% smaller, 30% faster, with MOAR metrics), I am not just collecting font enumeration and sizes, but now also checking that any whi...not an issue, but a Q for @pierov
In my much awaited but not yet deployed new fang-dangled snazzy TZP (30% smaller, 30% faster, with MOAR metrics), I am not just collecting font enumeration and sizes, but now also checking that any whitelist (or RFP's font vis) doesn't leak (as well as for missing bundled fonts in TB). But there is no need to check massive lists in TB, as most fonts are bundled: this would just adds lots of perf overhead
<details><summary>sample code</summary><p>
lists are snipped for brevity where stated
```js
let fntMaster = {
// TB bundled
"bundled": {
"all": [ // 118 win/mac/linux
"Noto Sans Adlam","Noto Sans Balinese", // SNIP
],
"android": [],
"linux": [ // +16
"Arimo","Cousine", // SNIP
],
"mac": [ // +5
"Noto Sans Armenian","Noto Sans Hebrew", // SNIP
],
"windows": [ // +4
"Noto Naskh Arabic", // SNIP
],
},
// TB whitelist
"allowlist": {
"android": [],
"linux": [],
"mac": [
"AppleGothic","Apple Color Emoji", // SNIP
],
"windows": [
"Arial","Cambria Math" // SNIP
],
},
// TB unexpected: to catch failures
"blocklist": {
"android": [],
"linux": [
'Arial','Courier','Courier New','Noto Emoji','Noto Sans','Noto Serif',
'Noto Color Emoji','Noto Mono','Cantarell','DejaVu Sans','DejaVu Serif',
'Droid Sans','STIX','Symbola','Dingbats','FreeMono','Ubuntu',
],
"mac": ["Apple Symbols","Avenir","Charter","Impact","Palatino","Rockwell",],
"windows": ["Calibri","Candara","Corbel","Impact","Ebrima","Gabriola",],
},
```
</p></details>
so we end up with something like this, where the green `[TB]` notation means no bundled fonts were missing _AND_ we didn't leak anything outside the whitelist (I call it an allowlist on the page so as to not be offensive). The bundled list (122) is a subset of allowed (155), which is a subset of the fonts tested (162 - which includes a fake random font as a poison pill)
![example](/uploads/3f3c8ffbbc960747ea70a90a8797b08b/example.png)
Now windows/mac is simple - I can add expected system fonts since win7/macOS10.12 to the "blocklist" and if they are detected then the whitelist is failing.
But linux is trickier. My initial "blocklist"ed items are, I think fairly common, especially on ubuntu and fedora, but I am not super linux font savvy. Can you improve on this list (without going massive on it: smaller is better) - see code examplehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41069Unify the `start-$browser-browser` and the `$browser` scripts2024-01-25T14:34:45ZPier Angelo VendrameUnify the `start-$browser-browser` and the `$browser` scriptsCurrently, we ship two scripts: one is `start-tor-browser`/`start-mullvad-browser`, the other one is `firefox`/`mullvadbrowser`.
The reason seems to be related to the updater (passing the directory with the `libstdc++6` we ship to `LD_LI...Currently, we ship two scripts: one is `start-tor-browser`/`start-mullvad-browser`, the other one is `firefox`/`mullvadbrowser`.
The reason seems to be related to the updater (passing the directory with the `libstdc++6` we ship to `LD_LIBRARY_PATH` when needed).
However, some users might be launching `firefox` instead of `start-tor-browser` (or even worse, the actual binary - `firefox.real`!).
This is a risk, because they're missing home isolation and especially the fontconfig settings.
Could we do something to unify these scripts instead?
The first course of action would be to test Tor/Mullvad Browser (and the updater) in an old system, to trigger the need to use our libstdc++.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/4228913.5 FP list [part 1: the easy stuff]2024-02-27T15:03:37ZThorin13.5 FP list [part 1: the easy stuff]details to follow
cc: @pierov @richard @cypherpunks1details to follow
cc: @pierov @richard @cypherpunks1https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/266Mullvad Browser should also have a gradient in letterboxing2024-02-20T14:40:14ZPier Angelo VendrameMullvad Browser should also have a gradient in letterboxingThe letterboxing gradient of Tor Browser makes some pages much nicer than Mullvad Browser.
E.g., look at this example on GitHub
<details><summary>Screenshot</summary>
![Screenshot_from_2024-02-12_15-30-53](/uploads/e4cfd802058d23f7230...The letterboxing gradient of Tor Browser makes some pages much nicer than Mullvad Browser.
E.g., look at this example on GitHub
<details><summary>Screenshot</summary>
![Screenshot_from_2024-02-12_15-30-53](/uploads/e4cfd802058d23f72306de444f5b1e3d/Screenshot_from_2024-02-12_15-30-53.png)
</details>
It's particularly a problem with sites that have some dark header, especially if close to the letterbox background.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42406Betterboxing's gradient is visible in new pages2024-02-20T14:38:00ZPier Angelo VendrameBetterboxing's gradient is visible in new pagesI think it's a little bit strange to see the gradient for some time while loading new pages, or under certain other conditions.
![screencapture](/uploads/b30950cd64f8a3c46d97377a7aa04604/screencapture.mp4)
What do you think @jag?I think it's a little bit strange to see the gradient for some time while loading new pages, or under certain other conditions.
![screencapture](/uploads/b30950cd64f8a3c46d97377a7aa04604/screencapture.mp4)
What do you think @jag?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42279Investigate UX impact of removing window titles2024-02-27T19:07:30ZJag TalonInvestigate UX impact of removing window titlesInvestigate UX issue of removing window titles in Tor for GNOME and KDE and possibly Windows.
Background: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988
## Design estimate:
* Complexity: medium (3 days)
*...Investigate UX issue of removing window titles in Tor for GNOME and KDE and possibly Windows.
Background: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988
## Design estimate:
* Complexity: medium (3 days)
* Create an option in `about:preferences#privacy` that toggles the titles from being shown on the window.
* Decide if the option should be enabled by default. [Preliminary findings show that it will have minimal impact to usability](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988#note_2971226), but perhaps more research and discussion is warranted.
* Create copy for help pages.
* Uncertainty level: moderate (1.5)
* This is a small, but far reaching change especially when releasing to multiple platforms. I imagine there's some uncertainty in this task.
* Total: 3-4.5 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42385Design dialog to share Lox invites2024-02-27T19:07:34ZJag TalonDesign dialog to share Lox invitescc @donuts @henry
**Design estimate:**
* Complexity: small (1 day)
* Copy existing modals from Firefox's design system.
* Uncertainty level: low (1.1)
* I believe there's no uncertainty here. All we need is something that's good ...cc @donuts @henry
**Design estimate:**
* Complexity: small (1 day)
* Copy existing modals from Firefox's design system.
* Uncertainty level: low (1.1)
* I believe there's no uncertainty here. All we need is something that's good enough for now.
* Total: 1-1.1 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41913Add validation and improve the formatting of manually added bridge lines2024-02-27T19:07:40ZdonutsAdd validation and improve the formatting of manually added bridge linesThe updated copy was added in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552, but not the trickier parts relating to the fancy formatting and validation going on in the text box.
See the Figma file here: [Figm...The updated copy was added in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552, but not the trickier parts relating to the fancy formatting and validation going on in the text box.
See the Figma file here: [Figma link](https://www.figma.com/file/RS584DcR4emXrw1F8g3l5x/Tor-Browser-12.5?node-id=102%3A13802&t=41hhHGHnJTkIHnmo-1)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41620Improve the UX of the request a bridge dialog2024-03-05T18:48:23ZdonutsImprove the UX of the request a bridge dialogFollowing recent improvements to the built-in bridges (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617) and provide a bridge dialogs (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552), w...Following recent improvements to the built-in bridges (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617) and provide a bridge dialogs (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552), we should also take a look at improving the UX of the request a bridge dialog. However it makes sense to wait on the outcome of https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/49 first, where the Anti-Censorship team will be considering a new CAPTCHA strategy.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42347Add a banner warning users about the upcoming EOL for Win ≤8.1 and macOS ≤10.142024-02-01T14:39:44ZPier Angelo VendrameAdd a banner warning users about the upcoming EOL for Win ≤8.1 and macOS ≤10.1413.5 will be the last Windows version, Mozilla bumped the requirement to Windows 10.
We could add a warning to Windows 7 users somewhere, e.g., in about:tor.
We can check the version of the OS with `Services.sysinfo.getProperty("versio...13.5 will be the last Windows version, Mozilla bumped the requirement to Windows 10.
We could add a warning to Windows 7 users somewhere, e.g., in about:tor.
We can check the version of the OS with `Services.sysinfo.getProperty("version")`. It's `10.0` in my Windows 10 VM, and `6.1` in my Windows 7 VM.
Maybe the first versions of Windows 10 also use 6.1, but if that's the case, they're unsupported too.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41482Bridge cards should inform users when a bridge isn't working2024-01-29T19:06:20ZGusBridge cards should inform users when a bridge isn't workingWhen a user requests a bridge using one of the bridge distributors (moat, telegram, connection assist), some of them may be blocked in their region. Users can see which bridge is failing on their Tor logs. Is it possible to display that ...When a user requests a bridge using one of the bridge distributors (moat, telegram, connection assist), some of them may be blocked in their region. Users can see which bridge is failing on their Tor logs. Is it possible to display that information on the bridge card so they don't need to check the logs?https://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/applications/tor-browser/-/issues/41716Figure out how to display conflux circuits in Tor Browser's UI2024-01-29T19:26:13Zmicahmicah@torproject.orgFigure out how to display conflux circuits in Tor Browser's UINow that circuit display was literally just re-implemented...
When 0.4.8 becomes stabilized (this will take a few months still), conflux will come to the network. Conflux will open a new world with tor circuits: circuits are no longer n...Now that circuit display was literally just re-implemented...
When 0.4.8 becomes stabilized (this will take a few months still), conflux will come to the network. Conflux will open a new world with tor circuits: circuits are no longer necessarily static, now they can be dynamic, the TCP circuits can change paths, and can have multiple paths, and doing so can bring some nice improvements for people.
We need to start thinking about how we want to communicate to the user in TB. Specifically that the circuit(s) are conflux circuits. Users knowing that they are using a conflux circuit will provide valuable information to them (and their feedback to us as well).
Because the circuits can now change paths, this could have a lot of UI visualization implications, such as reflecting that there are these paths that are now ready, or that there is a new circuit leg available. That would be the nice (but complicated) signal to users, but starting with something simple by just indicating in the UI that this is a conflux circuit (eg. literally just writing the word 'conflux' in green or something) would be a good first signal step. So there is a UX question here.
For the dev side of things, right now its possible (in 0.4.8) to get from the control port that a circuit is a conflux circuit, but it doesn't have any advanced information that would be useful for multi-leg displays, but if we want to show those types of things, we will need to talk about what would be needed to be added to tor to extract that information.
perhaps we can have a ad-hoc session at our in-person meeting to brief folks on what conflux means and its benefits.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42316TorConnect might restore old settings that were changed from the preferences2024-02-15T14:49:55ZPier Angelo VendrameTorConnect might restore old settings that were changed from the preferencesIn TorConnect we get a copy of the original settings (`this.originalSettings = TorSettings.getSettings();`) only once before trying all the settings we've received from Moat (and we bootstrap for each settings set, so the browser might t...In TorConnect we get a copy of the original settings (`this.originalSettings = TorSettings.getSettings();`) only once before trying all the settings we've received from Moat (and we bootstrap for each settings set, so the browser might take a long time to do stuff).
If the user changes settings, and we failed to bootstrap, we restore the settings we had before, which might be surprising.
So, we should check if the settings we're about to overwrite when we restore the old settings.
As a sequence of events:
1. TorConnect backup configuration A before contacting Moat
2. TorConnect sets the config B it received from Moat
3. While the bootstrap is happening, the user changes settings, producing config C
4. The boostrap fails: TorConnect restores config A!
Also, since we might receive many configuration sets, we might also apply config D, E, F and so on and possibly replace settings from configuration C.
On Android this cannot happen because going to settings stops the bootstrap, and we intend to keep this behavior at least for starters, when implementing the connection assist there.
However, on desktop is more difficult, because we have tabs.
Therefore, we might do something else, e.g., disable all the settings while we're bootstrapping, and display a message bar telling something like "The bootstrap is going on. Cancel it to unlock the settings".
## Design estimate:
* Complexity: medium (3 days)
* Figure out the appropriate solution. Should we prevent people from accessing the Settings on desktop just like on Android? Or do we create a warning for people that their settings might be overwritten?
* Create designs that solve the issue.
* Uncertainty level: moderate (1.5)
* I imagine trying to figure out which solution we should apply and how we apply it can take time.
* Total: 3-4.5 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41655Text in the Try Onion Services popup could be clearer2024-03-13T17:04:49ZhenryText in the Try Onion Services popup could be clearerI feel like some of the text in the "Try Onion Services" popup is a bit misleading:
## Title
It is currently "*Try* Onion Services", but this is a setting a preference that will be applied indefinitely, rather than for a short time. So...I feel like some of the text in the "Try Onion Services" popup is a bit misleading:
## Title
It is currently "*Try* Onion Services", but this is a setting a preference that will be applied indefinitely, rather than for a short time. So it seems like it should be more like "Use Onion Services".
## Body
The first sentence is
> There is a more private and secure version of this site available over the Tor network via onion services.
Given the context of this being shown when you visit a HTTPS site, this seems to be telling the user that the current connection they have to the HTTPS site is less private and less secure than if they used the onion site. Moreover, there is no text in the "Learn more" link (https://tb-manual.torproject.org/onion-services/) to back this up. It only says
> All traffic between Tor users and onion services is end-to-end encrypted, so you do not need to worry about connecting over HTTPS
but we already have HTTPS-Only mode in the browser.
In contrast, the second sentence
> Onion services help website publishers and their visitors defeat surveillance and censorship.
is easily understood and backed up.
I feel like maybe this first sentence should be more of a light overview of what an onion service *is*, with the second sentence being the benefits, making it clear what is benefiting the tor browser user.
## Button label
At least for me, "Not Now" tends to mean "I will bother you again in the future until you select the other option", so it can imply the *popup* will shown again for the next onion-available site, even though the user will never see it again. I think this is *trying* to indicate that you can always set this preference in the "Privacy & Security" settings in the future, but that could just be part of the body text if it is important.
## Design estimate:
* Complexity: low (1 days)
* Think about:
* How would a new user understand this? Do a mini user journey.
* What are the different ways the copy / design can be misunderstood?
* Ask:
* What is this thing?
* How does it benefit me?
* What are you asking me to do?
* Uncertainty level: high (2)
* I don't do much copy, so it's a bit of a challenge for me.
* There could be lenghty back and forth between stakeholders discussing the copy.
* Total: 1-2 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41335Establish a common onboarding template for both browsers2024-02-15T14:50:07ZdonutsEstablish a common onboarding template for both browsersTor Browser's current onboarding template is a port of an older version from Firefox. We should explore alternatives here before deciding on a template, e.g. the practicality of modifying Firefox's current built-in format.Tor Browser's current onboarding template is a port of an older version from Firefox. We should explore alternatives here before deciding on a template, e.g. the practicality of modifying Firefox's current built-in format.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42305(Semi-)Automatically merge translation resources across tor browser releases ...2024-03-26T20:31:08Zhenry(Semi-)Automatically merge translation resources across tor browser releases (desktop)/cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch.../cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch name, and merges the versions found in both branches together with a comment added for strings that will be dropped at the next release. Here is the initial draft of the script if you want a quick look: [combine-translation-versions.py](/uploads/83cf1424566cf3b3222e6a60682bcc56/combine-translation-versions.py)
We could use the output as the `en-US` source files for weblate, combining both the strings needed for the next release as well as for the current stable release. The idea being that in tor-browser we can stop trying to maintain all the old strings in the current development branch that are still needed for the current stable release. And we can avoid having to manual clean ups of old strings, like in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42221.
E.g., if we have `tor-browser.ftl` in tor-browser-xxx-13.5 with the content
```
string1 = String 1
new-string = New String
string2 = String 2
```
and in tor-browser-xxx-13.0 with the content
```
old-string = Old String
string1 = String 1
string2 = String 2
```
the script would output
```
string1 = String 1
new-string = New String
string2 = String 2
## Will be unused in Tor Browser 13.5!
old-string = Old String
```
The reason I add the comment is to provide a little notification to weblate translators in the "Source string description" to let them know that a string has a short lifetime. Weblate doesn't support descriptions for `.dtd` though so it won't work for that format.
@emmapeel and @pierov what do you think? And where would we want to run this script?
I guess we basically want to merge the translations files from both the branch used for current nightly and current stable. I'm not sure if this can be automatically pulled from `tor-browser-build` in a convenient way, or whether we would need some manual input.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42311Firfox doesn't like the embedded PNG in tor-browser-logo.svg2024-01-09T14:38:33ZPier Angelo VendrameFirfox doesn't like the embedded PNG in tor-browser-logo.svgI was checking if the suggestion for the patch to resolve debug problems worked, and I stumbled upon about:tor dying for the assertion in `image/imgLoader.cpp:2474`:
```
MOZ_ASSERT(NS_UsePrivateBrowsing(newChannel) == mRespectPrivacy);
...I was checking if the suggestion for the patch to resolve debug problems worked, and I stumbled upon about:tor dying for the assertion in `image/imgLoader.cpp:2474`:
```
MOZ_ASSERT(NS_UsePrivateBrowsing(newChannel) == mRespectPrivacy);
```
<details><summary>Call stack</summary>
```
__GI___clock_nanosleep (@clock_nanosleep@GLIBC_2.2.5:29)
__GI___nanosleep (@__nanosleep:9)
__sleep (@sleep:17)
common_crap_handler(int, void const*) (/home/piero/Tor/tor-browser/toolkit/xre/nsSigHandlers.cpp:96)
child_ah_crap_handler(int) (/home/piero/Tor/tor-browser/toolkit/xre/nsSigHandlers.cpp:110)
WasmTrapHandler(int, siginfo_t*, void*) (/home/piero/Tor/tor-browser/js/src/wasm/WasmSignalHandlers.cpp:799)
__restore_rt (@__restore_rt:3)
imgLoader::LoadImage(nsIURI*, nsIURI*, nsIReferrerInfo*, nsIPrincipal*, unsigned long, nsILoadGroup*, imgINotificationObserver*, nsINode*, mozilla::dom::Document*, unsigned int, nsISupports*, nsIContentPolicy::nsContentPolicyType, nsTSubstring<char16_t> const&, bool, bool, unsigned long, imgRequestProxy**) (/home/piero/Tor/tor-browser/image/imgLoader.cpp:2474)
nsContentUtils::LoadImage(nsIURI*, nsINode*, mozilla::dom::Document*, nsIPrincipal*, unsigned long, nsIReferrerInfo*, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, nsIContentPolicy::nsContentPolicyType, bool, bool, unsigned long) (/home/piero/Tor/tor-browser/dom/base/nsContentUtils.cpp:4004)
nsImageLoadingContent::LoadImage(nsIURI*, bool, bool, nsImageLoadingContent::ImageLoadType, unsigned int, mozilla::dom::Document*, nsIPrincipal*) (/home/piero/Tor/tor-browser/dom/base/nsImageLoadingContent.cpp:1143)
nsImageLoadingContent::LoadImage(nsTSubstring<char16_t> const&, bool, bool, nsImageLoadingContent::ImageLoadType, nsIPrincipal*) (/home/piero/Tor/tor-browser/dom/base/nsImageLoadingContent.cpp:1027)
mozilla::dom::SVGImageElement::LoadSVGImage(bool, bool) (/home/piero/Tor/tor-browser/dom/svg/SVGImageElement.cpp:146)
mozilla::dom::SVGImageElement::AfterSetAttr(int, nsAtom*, nsAttrValue const*, nsAttrValue const*, nsIPrincipal*, bool) (/home/piero/Tor/tor-browser/dom/svg/SVGImageElement.cpp:215)
mozilla::dom::Element::SetAttrAndNotify(int, nsAtom*, nsAtom*, nsAttrValue const*, nsAttrValue&, nsIPrincipal*, unsigned char, bool, bool, bool, mozilla::dom::Document*, mozAutoDocUpdate const&) (/home/piero/Tor/tor-browser/dom/base/Element.cpp:2653)
mozilla::dom::Element::SetAttr(int, nsAtom*, nsAtom*, nsTSubstring<char16_t> const&, nsIPrincipal*, bool) (/home/piero/Tor/tor-browser/dom/base/Element.cpp:2506)
mozilla::dom::Element::SetAttr(int, nsAtom*, nsAtom*, nsTSubstring<char16_t> const&, bool) (/home/piero/Tor/tor-browser/obj-x86_64-pc-linux-gnu/dist/include/mozilla/dom/Element.h:1000)
nsXMLContentSink::AddAttributes(char16_t const**, mozilla::dom::Element*) (/home/piero/Tor/tor-browser/dom/xml/nsXMLContentSink.cpp:1376)
nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int, bool) (/home/piero/Tor/tor-browser/dom/xml/nsXMLContentSink.cpp:957)
nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int) (/home/piero/Tor/tor-browser/dom/xml/nsXMLContentSink.cpp:903)
non-virtual thunk to nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int) (/home/piero/Tor/tor-browser/dom/xml/nsXMLContentSink.cpp:0)
nsExpatDriver::HandleStartElement(rlbox::rlbox_sandbox<rlbox::rlbox_noop_sandbox>&, rlbox::tainted<void*, rlbox::rlbox_noop_sandbox>, rlbox::tainted<char16_t const*, rlbox::rlbox_noop_sandbox>, rlbox::tainted<char16_t const**, rlbox::rlbox_noop_sandbox>) (/home/piero/Tor/tor-browser/parser/htmlparser/nsExpatDriver.cpp:477)
doContentInternal (/home/piero/Tor/tor-browser/parser/expat/lib/xmlparse.c:2920)
doContent (/home/piero/Tor/tor-browser/parser/expat/lib/xmlparse.c:2664)
contentProcessor (/home/piero/Tor/tor-browser/parser/expat/lib/xmlparse.c:2540)
MOZ_XML_ParseBuffer (/home/piero/Tor/tor-browser/parser/expat/lib/xmlparse.c:2004)
auto rlbox::rlbox_noop_sandbox::impl_invoke_with_func_ptr<XML_Status (XML_ParserStruct*, char const*, int, int), XML_Status (void*, void*, int, int), void*, void*, unsigned long, bool>(XML_Status (*)(void*, void*, int, int), void*&&, void*&&, unsigned long&&, bool&&) (/home/piero/Tor/tor-browser/obj-x86_64-pc-linux-gnu/dist/include/mozilla/rlbox/rlbox_noop_sandbox.hpp:188)
auto rlbox::rlbox_sandbox<rlbox::rlbox_noop_sandbox>::INTERNAL_invoke_with_func_ptr<XML_Status (XML_ParserStruct*, char const*, int, int), rlbox::tainted<XML_ParserStruct*, rlbox::rlbox_noop_sandbox>&, rlbox::tainted<char const*, rlbox::rlbox_noop_sandbox>, unsigned long, bool>(char const*, void*, rlbox::tainted<XML_ParserStruct*, rlbox::rlbox_noop_sandbox>&, rlbox::tainted<char const*, rlbox::rlbox_noop_sandbox>&&, unsigned long&&, bool&&) (/home/piero/Tor/tor-browser/obj-x86_64-pc-linux-gnu/dist/include/mozilla/rlbox/rlbox_sandbox.hpp:790)
nsExpatDriver::ParseChunk(char16_t const*, unsigned int, nsExpatDriver::ChunkOrBufferIsFinal, unsigned int*, unsigned long*) (/home/piero/Tor/tor-browser/parser/htmlparser/nsExpatDriver.cpp:1248)
nsExpatDriver::ChunkAndParseBuffer(char16_t const*, unsigned int, bool, unsigned int*, unsigned int*, unsigned long*) (/home/piero/Tor/tor-browser/parser/htmlparser/nsExpatDriver.cpp:1204)
nsExpatDriver::ResumeParse(nsScanner&, bool) (/home/piero/Tor/tor-browser/parser/htmlparser/nsExpatDriver.cpp:1352)
nsParser::ResumeParse(bool, bool, bool) (/home/piero/Tor/tor-browser/parser/htmlparser/nsParser.cpp:716)
nsParser::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (/home/piero/Tor/tor-browser/parser/htmlparser/nsParser.cpp:1027)
imgRequest::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (/home/piero/Tor/tor-browser/image/imgRequest.cpp:1068)
nsJARChannel::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (/home/piero/Tor/tor-browser/modules/libjar/nsJARChannel.cpp:1312)
nsInputStreamPump::OnStateTransfer() (/home/piero/Tor/tor-browser/netwerk/base/nsInputStreamPump.cpp:584)
nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (/home/piero/Tor/tor-browser/netwerk/base/nsInputStreamPump.cpp:411)
non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (/home/piero/Tor/tor-browser/netwerk/base/nsInputStreamPump.cpp:0)
CallbackHolder::CallbackHolder(nsIAsyncInputStream*, nsIInputStreamCallback*, unsigned int, nsIEventTarget*)::'lambda'()::operator()() const (/home/piero/Tor/tor-browser/xpcom/io/nsPipe3.cpp:73)
already_AddRefed<mozilla::CancelableRunnable> NS_NewCancelableRunnableFunction<CallbackHolder::CallbackHolder(nsIAsyncInputStream*, nsIInputStreamCallback*, unsigned int, nsIEventTarget*)::'lambda'()>(char const*, CallbackHolder::CallbackHolder(nsIAsyncInputStream*, nsIInputStreamCallback*, unsigned int, nsIEventTarget*)::'lambda'()&&)::FuncCancelableRunnable::Run() (/home/piero/Tor/tor-browser/obj-x86_64-pc-linux-gnu/dist/include/nsThreadUtils.h:667)
mozilla::RunnableTask::Run() (/home/piero/Tor/tor-browser/xpcom/threads/TaskController.cpp:555)
mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (/home/piero/Tor/tor-browser/xpcom/threads/TaskController.cpp:879)
mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (/home/piero/Tor/tor-browser/xpcom/threads/TaskController.cpp:702)
mozilla::TaskController::ProcessPendingMTTask(bool) (/home/piero/Tor/tor-browser/xpcom/threads/TaskController.cpp:491)
mozilla::TaskController::TaskController()::$_0::operator()() const (/home/piero/Tor/tor-browser/xpcom/threads/TaskController.cpp:218)
mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_0>::Run() (/home/piero/Tor/tor-browser/xpcom/threads/nsThreadUtils.h:548)
nsThread::ProcessNextEvent(bool, bool*) (/home/piero/Tor/tor-browser/xpcom/threads/nsThread.cpp:1240)
NS_ProcessNextEvent(nsIThread*, bool) (/home/piero/Tor/tor-browser/xpcom/threads/nsThreadUtils.cpp:479)
mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/home/piero/Tor/tor-browser/ipc/glue/MessagePump.cpp:85)
MessageLoop::RunHandler() (/home/piero/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:361)
MessageLoop::Run() (/home/piero/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:343)
nsBaseAppShell::Run() (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:148)
XRE_RunAppShell() (/home/piero/Tor/tor-browser/toolkit/xre/nsEmbedFunctions.cpp:724)
mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) (/home/piero/Tor/tor-browser/ipc/glue/MessagePump.cpp:235)
MessageLoop::RunHandler() (/home/piero/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:361)
MessageLoop::Run() (/home/piero/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:343)
XRE_InitChildProcess(int, char**, XREChildData const*) (/home/piero/Tor/tor-browser/toolkit/xre/nsEmbedFunctions.cpp:659)
content_process_main(mozilla::Bootstrap*, int, char**) (/home/piero/Tor/tor-browser/ipc/contentproc/plugin-container.cpp:57)
main (/home/piero/Tor/tor-browser/browser/app/nsBrowserApp.cpp:375)
__libc_start_call_main (@__libc_start_call_main:26)
__libc_start_main_impl (@__libc_start_main@@GLIBC_2.34:43)
_start (@_start:14)
```
</details>
I'm trying an optimized build with asserts on, so many variables have been optimized out.
However, I managed to see that it was this PNG by checking `href` at the end of `mozilla::dom::SVGImageElement::LoadSVGImage`.
FWIW, I think this is a peculiarity of the YEC homepage.