The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-11-23T18:25:49Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16404Review WebGL2 spec for fingerprinting issues2022-11-23T18:25:49ZMike PerryReview WebGL2 spec for fingerprinting issuesWebGL2 is available in FF38, but is off by default via a pref (webgl.enable-prototype-webgl2). I imagine it is likely it will be finalized by FF45, so we should review the spec by then.
Here's the spec:
https://www.khronos.org/registry/...WebGL2 is available in FF38, but is off by default via a pref (webgl.enable-prototype-webgl2). I imagine it is likely it will be finalized by FF45, so we should review the spec by then.
Here's the spec:
https://www.khronos.org/registry/webgl/specs/latest/2.0/
This URL also proved useful in the past:
https://www.browserleaks.com/webgl
See also legacy/trac#16005 and legacy/trac#13022.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16403Set search params for disconnect2020-06-27T14:40:37ZMike PerrySet search params for disconnectIn order to help Disconnect recognize Tor Browser users for the donation page and general accounting, we offered to set special search parameters for our search box and homepage. They sent us a search plugin with these params. We should ...In order to help Disconnect recognize Tor Browser users for the donation page and general accounting, we offered to set special search parameters for our search box and homepage. They sent us a search plugin with these params. We should use it in 5.0a3 and possibly 4.5.3.https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/16401Fail-fast if file access permissions for out and status prevent an update2020-06-27T14:24:19ZTracFail-fast if file access permissions for out and status prevent an updateRegular backups of the _out_ and _status_ folders for an Onionoo server is encouraged. When running as a separate user it wouldn't be uncommon to have the archives owned by another user. Onionoo's updater doesn't check the access permiss...Regular backups of the _out_ and _status_ folders for an Onionoo server is encouraged. When running as a separate user it wouldn't be uncommon to have the archives owned by another user. Onionoo's updater doesn't check the access permissions for _out_ and _status_ until after rebuilding the folder _in_, and it basically fills the logs with entries for every file it failed to access. So if you didn't recursively set access permissions that's a lot of log entries before the updater finally stops.
If the Onionoo updater were to check the permissions early and fail-fast it would prevent this behavior.
**Trac**:
**Username**: leeroyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16400Bug: Assertion cp failed in microdescs_parse_from_string at ../src/or/routerp...2020-06-27T14:01:04ZTracBug: Assertion cp failed in microdescs_parse_from_string at ../src/or/routerparse.c:4168
Since upgrading tor via my linux mint debian edition 2 upgrade mechanism i get following error in /var/log/tor/debug.log whenever i try to start the tor daemon
```
Jun 19 13:16:47.000 [err] tor_assertion_failed_(): Bug: ../src/or/rout...
Since upgrading tor via my linux mint debian edition 2 upgrade mechanism i get following error in /var/log/tor/debug.log whenever i try to start the tor daemon
```
Jun 19 13:16:47.000 [err] tor_assertion_failed_(): Bug: ../src/or/routerparse.c:4168: microdescs_parse_from_string: Assertion cp failed; aborting.
Jun 19 13:16:47.000 [err] Bug: Assertion cp failed in microdescs_parse_from_string at ../src/or/routerparse.c:4168. Stack trace:
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(log_backtrace+0x52) [0xb76a54a2]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x94) [0xb76b33c4]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(microdescs_parse_from_string+0x6dc) [0xb76095bc]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(microdescs_add_to_cache+0x6d) [0xb75c14dd]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(microdesc_cache_reload+0xb1) [0xb75c2901]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(get_microdesc_cache+0xab) [0xb75c2a1b]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(nodelist_set_consensus+0x32d) [0xb75caa9d]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(networkstatus_set_current_consensus+0x993) [0xb75c6ba3]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(router_reload_consensus_networkstatus+0x7f) [0xb75c711f]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(do_main_loop+0x90) [0xb75bd4a0]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(tor_main+0x14f5) [0xb75c0315]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(main+0x35) [0xb75b99c5]
Jun 19 13:16:47.000 [err] Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0xb70ba723]
Jun 19 13:16:47.000 [err] Bug: /usr/bin/tor(+0x26a14) [0xb75b9a14]
```
**Trac**:
**Username**: torkelnTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16399Create rendcache.{c|h} for hidden service descriptor cache2020-06-27T14:01:04ZDavid Gouletdgoulet@torproject.orgCreate rendcache.{c|h} for hidden service descriptor cacheFor developers and reviewers mental sanity, it would be great to move the ABI/API of both service and client hidden service descriptor cache to its own set of files.
Furthermore, to resolve legacy/trac#16389, it would help a lot to do t...For developers and reviewers mental sanity, it would be great to move the ABI/API of both service and client hidden service descriptor cache to its own set of files.
Furthermore, to resolve legacy/trac#16389, it would help a lot to do that so we can ease development, maintenance, review and have better documentation in one single file.
I propose `rendcache.{c|h}`.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16398systemd startup timeout on v0.2.6.9 (git-145b2587d1269af4)2020-06-27T14:01:04ZTracsystemd startup timeout on v0.2.6.9 (git-145b2587d1269af4)I'm using experimental builds on Ubuntu 15.04. Since the last update systemd is looping forever in restarting Tor, because it detects a start timeout:
```
Jun 18 12:26:27 dharma systemd[1]: Starting Anonymizing overlay network for TCP.....I'm using experimental builds on Ubuntu 15.04. Since the last update systemd is looping forever in restarting Tor, because it detects a start timeout:
```
Jun 18 12:26:27 dharma systemd[1]: Starting Anonymizing overlay network for TCP...
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:26:27 dharma tor[11487]: Configuration was valid
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.400 [notice] Opening Socks listener on 127.0.0.1:9050
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.400 [notice] Opening Control listener on /var/run/tor/control
Jun 18 12:27:12 dharma systemd[1]: tor.service start operation timed out. Terminating.
Jun 18 12:27:12 dharma systemd[1]: Failed to start Anonymizing overlay network for TCP.
Jun 18 12:27:12 dharma systemd[1]: Unit tor.service entered failed state.
Jun 18 12:27:12 dharma systemd[1]: tor.service failed.
Jun 18 12:27:12 dharma systemd[1]: tor.service holdoff time over, scheduling restart.
Jun 18 12:27:12 dharma systemd[1]: Starting Anonymizing overlay network for TCP...
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:27:12 dharma tor[11572]: Configuration was valid
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.875 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.881 [notice] Opening Socks listener on 127.0.0.1:9050
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.882 [notice] Opening Control listener on /var/run/tor/control
```
... and goes on like this forever. This wasn't happening until few days ago, where this last update was distirbuted.
**Trac**:
**Username**: maxxerhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16397Tor Browser crashes on some SVG images2020-06-27T14:40:37ZTracTor Browser crashes on some SVG imagesHello,
When I visit this link http://www.theplantlist.org/browse/B/Sphagnaceae/Sphagnum/ Tor Browser just closes even if I have multiple tabs/windows open.
**Trac**:
**Username**: mcapHello,
When I visit this link http://www.theplantlist.org/browse/B/Sphagnaceae/Sphagnum/ Tor Browser just closes even if I have multiple tabs/windows open.
**Trac**:
**Username**: mcaphttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16395Circuit isolation by SOCKS proxy may be breaking other proxies or non-proxies2022-06-16T02:12:03ZTracCircuit isolation by SOCKS proxy may be breaking other proxies or non-proxiesIf, for whatever reason, the user wants to disable the Tor Browser from connecting to their local Tor daemon (such as to prevent tor-through-tor with forced transparent torrification, or use the Tor Browser for it's security rather than ...If, for whatever reason, the user wants to disable the Tor Browser from connecting to their local Tor daemon (such as to prevent tor-through-tor with forced transparent torrification, or use the Tor Browser for it's security rather than it's anonymity, or point the Tor Browser to an SSH SOCKS proxy), they will find that since the release of the Tor Browser 4.5.1, it will fail to connect to any SOCKS proxy that isn't a Tor daemon, and it will complain saying, "Firefox is configured to use a proxy server that can't be found." when proxies are disabled.
I believe the cause of this issue is https://gitweb.torproject.org/torbutton.git/commit/?id=59445b7baed58e712bd38c02e6dc75882ff0c997 or a related commit to the Tor Button. Disabling the Tor Button resolves the issue, but this isn't desired as the Tor Button provides additional protections such as the HTML5 canvas extraction.
This can easily be recreated by having the 32-bit Linux package of the Tor Browser, and the attached 0000tor-use-system-4.5.2test.js file in the current directory, and then running something along the lines of:
```
xz -d < tor-browser-linux32-4.5.2_en-US.tar.xz | tar -xv
cp 0000tor-use-proxy-4.5.2test.js tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/preferences/
tor-browser_en-US/Browser/start-tor-browser --verbose
```
The above assumes there is a SOCKS5 proxy running on your machine on port 1080. This can easily be done with something like
```
ssh -Dlocalhost:1080 localhost -N
```
**Trac**:
**Username**: GigabyteProductionshttps://gitlab.torproject.org/tpo/core/tor/-/issues/16393Include a readpassphrase implementation for Linux, Windows2020-06-27T14:01:04ZNick MathewsonInclude a readpassphrase implementation for Linux, WindowsThanks to legacy/trac#13642, we have encrypted key storage. It might be clever to actually have a good way to read passphrases for it. We use readpassphrase where availabe; let's include a freely redistributable implementation for unic...Thanks to legacy/trac#13642, we have encrypted key storage. It might be clever to actually have a good way to read passphrases for it. We use readpassphrase where availabe; let's include a freely redistributable implementation for unices that don't have it.
(Windows will be harder.)Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/16391TorBrowser-4.5.2-osx64_ru.dmg is zero size2020-06-27T14:19:50ZTracTorBrowser-4.5.2-osx64_ru.dmg is zero sizehttps://dist.torproject.org/torbrowser/4.5.2/TorBrowser-4.5.2-osx64_ru.dmg
**Trac**:
**Username**: yurikoleshttps://dist.torproject.org/torbrowser/4.5.2/TorBrowser-4.5.2-osx64_ru.dmg
**Trac**:
**Username**: yurikoleshttps://gitlab.torproject.org/tpo/core/tor/-/issues/16389Redesign the HS client descriptor cache2020-06-27T14:01:04ZDavid Gouletdgoulet@torproject.orgRedesign the HS client descriptor cache**We merged a patch here, but see arma's comment below.**
Bug legacy/trac#16381 vs legacy/trac#14219 demonstarted an important issue with the current design of the HS client descriptor cache.
In a nutshell, we can't rely on the timesta...**We merged a patch here, but see arma's comment below.**
Bug legacy/trac#16381 vs legacy/trac#14219 demonstarted an important issue with the current design of the HS client descriptor cache.
In a nutshell, we can't rely on the timestamp to order descriptors because the timestamp is rounded down to the nearest hour thus any change in that time period will never be seen by the client (legacy/trac#16381). Furthermore, we can't rely on comparing the descriptor content because we have two replicas with the same content but have different descriptor ID (legacy/trac#14219).
One solution proposed by arma (and +1 by special) is to redesign the logic to be cleaner, and keep an intro point failure cache. It seems like every time we encounter this "we keep state about the previous hs desc by keeping a copy of it, and then seeing if the new one is different, get it?" logic, somebody finds it confusing. Maybe now is a good time for it to die? :)Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16388Bump OpenSSL to 1.0.1o for Tor Browser2020-06-27T14:40:37ZGeorg KoppenBump OpenSSL to 1.0.1o for Tor BrowserWe shipped 4.5.2/5.0a2 with OpenSSL 1.0.1n although it contained an ABI breakage. Although we came to believe after further inspection that even advanced Tor Browser usages should not be affected it seems wise to ship 1.0.1o in upcoming ...We shipped 4.5.2/5.0a2 with OpenSSL 1.0.1n although it contained an ABI breakage. Although we came to believe after further inspection that even advanced Tor Browser usages should not be affected it seems wise to ship 1.0.1o in upcoming Tor Browser versions.https://gitlab.torproject.org/tpo/core/tor/-/issues/16387Improve reachability of hidden services on mobile phones2022-06-17T18:02:52ZGeorge KadianakisImprove reachability of hidden services on mobile phonesMobile phones are unstable and their IP changes all the time. Hidden services don't work well on them.
Here are some things that can go wrong when the mobile phone (and hence the HS) loses network or changes its IP address:
- The circu...Mobile phones are unstable and their IP changes all the time. Hidden services don't work well on them.
Here are some things that can go wrong when the mobile phone (and hence the HS) loses network or changes its IP address:
- The circuits to the intro points get broken, the HS establishes new intro points and republishes its descriptor. Its clients are not aware of the new intro points, and keep on trying the old ones. This is legacy/trac#8239 which might be fixed soon.
- The rendezvous circuits to current clients get broken, and the HS does not reestablish them. Then clients keep on trying the same broken rendezvous point on and on, instead of re-introducing themselves (or fetching a new descriptor entirely). We should verify that this behavior is broken, and think of better ones here.
A related thread can be found on [tor-dev] here:
https://lists.torproject.org/pipermail/tor-dev/2015-May/008841.htmlhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/16386Chutney generates network with no bandwidth weights2020-07-23T21:07:50ZGeorge KadianakisChutney generates network with no bandwidth weightsHello,
when chutney makes a Tor network, it sets the following options in the dirauth torrc:
```
TestingDirAuthVoteExit *
TestingDirAuthVoteGuard *
```
which results in a network where all nodes are guards and exits.
This results in to...Hello,
when chutney makes a Tor network, it sets the following options in the dirauth torrc:
```
TestingDirAuthVoteExit *
TestingDirAuthVoteGuard *
```
which results in a network where all nodes are guards and exits.
This results in totally unbalanced bandwidths (0 guard bandwidth, 0 middle bandwidth, full guard+exit bandwidth) and authorities will not generate bandwidth weights:
```
[warn] Consensus with empty bandwidth: G=0 M=0 E=0 D=65770 T=65770
```
This is quite different from the real Tor network.
It would be great if chutney could assign Exit/Guard flag in a smarter way to only a few nodes, so that bandwidth can be allocated more widely.https://gitlab.torproject.org/tpo/core/tor/-/issues/16382man page has misleading info about the min bw rate2021-07-22T16:25:32ZNima Fatemiman page has misleading info about the min bw rate```
GENERAL OPTIONS
BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits
A token bucket limits the average incoming bandwidth usage on this node to the
specified number of bytes per second, and the av...```
GENERAL OPTIONS
BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits
A token bucket limits the average incoming bandwidth usage on this node to the
specified number of bytes per second, and the average outgoing bandwidth usage to that
same value. If you want to run a relay in the public network, this needs to be at the
very least 30 KBytes (that is, 30720 bytes). (Default: 1 GByte)
```
The number has been lifted to 250KBytes in our [online documentation](https://www.torproject.org/docs/tor-relay-debian) and this one should probably get fixed too. Anything below 250KBytes (each direction) is probably hurting the network.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16381Bad timestamp check when storing an HS descriptor on the client2020-06-27T14:01:05ZDavid Gouletdgoulet@torproject.orgBad timestamp check when storing an HS descriptor on the clientFortunately, this bug "should" happen rarely in the real Tor network but still could lead to reachability issues for high traffic hidden service.
Let's assume that all introduction points (IP) of an hidden service need to be changed (in...Fortunately, this bug "should" happen rarely in the real Tor network but still could lead to reachability issues for high traffic hidden service.
Let's assume that all introduction points (IP) of an hidden service need to be changed (intro2 max count or expiring) in a single `RendPostPeriod` (default is 1 hour), we do the intro dance with our newly picked introduction points, close the old ones and upload the new descriptor. The usual.
Now, let's say we have a client that did connect to the service before in the same hour so the client has the descriptor in its cache. Then, the client tries to connect again, the IPs located in the cached descriptor are used and the client will eventually get a NACK from all of them since the service just cycled them all. This will eventually trigger a refetch of the descriptor since we have no more IP that we can use. So far so good.
Here is when it goes wrong, when receiving the new descriptor just published by the HS, we do a series of check in `rend_cache_store_v2_desc_as_client()` which all passes correctly in our case except this one:
```
e = (rend_cache_entry_t*) strmap_get_lc(rend_cache, key);
if (e && e->parsed->timestamp >= parsed->timestamp) {
log_info(LD_REND, "We already have a new enough service descriptor for "
"service ID %s with the same desc ID and version.",
safe_str_client(service_id));
goto okay;
}
```
The HS protocol speficies that the timestamp in the descriptor MUST be rounded down to the nearest hour. For instance, if it's 16h54, it will be set to 16h00. See `rend_service_update_descriptor()`:
```
d->timestamp = time(NULL);
d->timestamp -= d->timestamp % 3600; /* Round down to nearest hour */
```
The side effect of this is that if an HS uploads a new descriptor with a new set of IPs, they won't be usable until the next hour because the tor client doesn't keep the new descriptor even though the intro points did actually change. Thus this means that anything that changes in a time period of one hour will not be seen by the client if the descriptor was already cached before.
Keep in mind that a client reuses a rendez-vous circuit but stops after `MaxCircuitDirtiness` (default: 10 minutes) so after 10 minutes it will redo the introduction and rendezvous circuits.
(I was able to trigger this in a chutney network by setting a lifetime of 30 seconds for introduction point which creates a lot of rotation.)
I think the fix here should look like this (fun fact, it's what `rend_cache_store_v2_desc_as_dir()` does):
```
- if (e && e->parsed->timestamp >= parsed->timestamp) {
+ if (e && e->parsed->timestamp > parsed->timestamp) {
```Tor: 0.2.7.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/16380Minor spacing and comment fixes2020-06-27T14:01:05ZteorMinor spacing and comment fixesFix spacing in tortls.c and a comment in networkstatus.cFix spacing in tortls.c and a comment in networkstatus.cTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/16379Your bugtracker does not work on Opera 9.272020-06-27T14:19:50ZTracYour bugtracker does not work on Opera 9.27Your bug-tracker ( https://trac.torproject.org/projects/tor/newticket ) shows me captcha infinitely even if I enter it correctly.
**Trac**:
**Username**: Ilya_SpongeBobYour bug-tracker ( https://trac.torproject.org/projects/tor/newticket ) shows me captcha infinitely even if I enter it correctly.
**Trac**:
**Username**: Ilya_SpongeBobJens KubiezielJens Kubiezielhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16378In TorBrowser 4.5.1 youtub_ live streaming does not work2020-06-27T14:40:37ZTracIn TorBrowser 4.5.1 youtub_ live streaming does not workE.g. https://www.youtub_.com/watch?v=7cKOWdEdVTc
Flash video-player rectangle says:
Your browser does not currently recognize any of the video formats available. Click here to visit our frequently asked questions about HTML5 video.
Addi...E.g. https://www.youtub_.com/watch?v=7cKOWdEdVTc
Flash video-player rectangle says:
Your browser does not currently recognize any of the video formats available. Click here to visit our frequently asked questions about HTML5 video.
Additional question: Where I must put NPSWF32.dll. If Firefox portable ( http://sourceforge.net/projects/portableapps/files/Mozilla%20Firefox%2C%20Portable%20Ed./ ) I can put it in "D:\FirefoxPortable\Data\plugins\".
**Trac**:
**Username**: Ilya_SpongeBobhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16376Firefox bug - When I close Tor Browser, it clears clipboard.2020-06-27T14:40:37ZTracFirefox bug - When I close Tor Browser, it clears clipboard.Please add an option to turn of clearing clipboard on browser close.
**Trac**:
**Username**: Ilya_SpongeBobPlease add an option to turn of clearing clipboard on browser close.
**Trac**:
**Username**: Ilya_SpongeBob