The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-10-01T15:35:40Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40523Review (and clarify, if necessary) V2 deprecation warning copy2021-10-01T15:35:40ZdonutsReview (and clarify, if necessary) V2 deprecation warning copyUsers who aren't familiar with the version history of onion sites seem to be misinterpreting the error, and are under the impression the deprecation warning applies to their instance of Tor Browser, rather than the onion site itself.
Al...Users who aren't familiar with the version history of onion sites seem to be misinterpreting the error, and are under the impression the deprecation warning applies to their instance of Tor Browser, rather than the onion site itself.
Although the warning does point to the support portal for further info, the learn more link is likely too subtle (and buries a lot of the explaining behind a link).
Let's review the copy here to see if there's a way we can easily clarify it – for example, adding a "What can I do about it?" section that explains in a little more detail that the issue lies with the site itself – not their browser.donutsdonutshttps://gitlab.torproject.org/tpo/core/tor/-/issues/40400Make `ProtocolWarnings 1` less noisy to run2021-10-20T20:25:32ZNick MathewsonMake `ProtocolWarnings 1` less noisy to runWhile investigating the right fix for #40175, Sebastian reminded me that we get lots of frequent protocol warnings. We should make these less frequent so that it's less of a burden to run Tor with protocol warnings enabled.
The most co...While investigating the right fix for #40175, Sebastian reminded me that we get lots of frequent protocol warnings. We should make these less frequent so that it's less of a burden to run Tor with protocol warnings enabled.
The most common warnings that Sebastian encountered are:
```
84853 Rejecting RENDEZVOUS1 cell with unrecognized rendezvous cookie
9975 Didn't recognize cell, but circ stops here
10002 circuit_receive_relay_cell (forward) failed
```
Options are:
* Downgrade to INFO or DEBUG.
* Add rate-limiting
* Identify cases that truly should be protocol warnings, and downgrade or rate-limit the other cases.Tor: 0.4.7.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/team/-/issues/3Rename git master to main2022-08-11T17:25:25ZMatthew FinkelRename git master to mainFollowing tpo/core/team#2 as a template: let's (finally) do this.
We don't have this problem in the following projects:
- Tor Browser
- Fenix
- Android Components
We should rename the default branch of:
- [x] Tor Browser Build
- [...Following tpo/core/team#2 as a template: let's (finally) do this.
We don't have this problem in the following projects:
- Tor Browser
- Fenix
- Android Components
We should rename the default branch of:
- [x] Tor Browser Build
- [x] RBM
- [x] Torbutton
- [x] Tor Launcher
- [x] Tor Android Service
- [x] Tor Browser Bundle Testsuite
- [x] Tor Browser Spec
See also:
- tpo/tpa/gitlab#75
- tpo/web/tpo#90
- https://gitlab.com/anarcat/scripts/-/blob/master/git-rename-to-mainrichardrichardhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40214Have prometheus send alert emails in plaintext rather than HTML2021-04-19T20:24:38ZCecylia BocovichHave prometheus send alert emails in plaintext rather than HTMLI have a general desire for fewer HTML-based emails in my life :)
The prometheus documentation for configuring email alerts suggests that we can choose between text and HTML: https://prometheus.io/docs/alerting/latest/configuration/#ema...I have a general desire for fewer HTML-based emails in my life :)
The prometheus documentation for configuring email alerts suggests that we can choose between text and HTML: https://prometheus.io/docs/alerting/latest/configuration/#email_config
Currently the alertmanager is configured to use the [default email HTML template](https://github.com/prometheus/alertmanager/blob/master/template/default.tmpl#L81), which is very ugly. There is no default text-based email template so we will have to [write our own](https://prometheus.io/blog/2016/03/03/custom-alertmanager-templates/). To do this, we add a custom template file that looks something like:
```
{{ define "email.custom.txt" }}
...
{{ end }}
```
and then modify our alertmanager config to reference this template:
```
receivers:
- name: 'email'
email_configs:
- to: 'receiver_mail_id@gmail.com'
from: 'mail_id@gmail.com'
text: '{{ template "email.custom.txt" . }}'
```https://gitlab.torproject.org/tpo/web/tpo/-/issues/173The expert bundle doesn't actually support XP, 98, etc.2021-04-12T19:59:34ZpastlyThe expert bundle doesn't actually support XP, 98, etc.On the "download the source code" page https://www.torproject.org/download/tor/ ...
Windows Expert Bundle
Windows 10, 8, 7, Vista, XP, 2000, 2003 Server, ME, and Windows 98SE
The network team doesn't support Windows versions th...On the "download the source code" page https://www.torproject.org/download/tor/ ...
Windows Expert Bundle
Windows 10, 8, 7, Vista, XP, 2000, 2003 Server, ME, and Windows 98SE
The network team doesn't support Windows versions that are past EOL. https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SupportedPlatformshttps://gitlab.torproject.org/tpo/community/team/-/issues/34Community, l10n and web repositories on AnonTicket2021-04-12T13:20:37ZGusCommunity, l10n and web repositories on AnonTicketWe're testing this new fantastic tool, [Anonymous GitLab Ticketing](https://blog.torproject.org/anonymous-gitlab).
Let's list on this ticket all the repositories that we want to integrate there.
(cc. @emmapeel, @gaba)We're testing this new fantastic tool, [Anonymous GitLab Ticketing](https://blog.torproject.org/anonymous-gitlab).
Let's list on this ticket all the repositories that we want to integrate there.
(cc. @emmapeel, @gaba)GusGushttps://gitlab.torproject.org/tpo/web/support/-/issues/185Minor grammatical error in FAQ-"Am I totally anonymous if I use Tor?"2021-04-09T13:54:05ZBurnleydevMinor grammatical error in FAQ-"Am I totally anonymous if I use Tor?"I Read through FAQ and saw this grammatical error in the screenshot below:
**Has to be**
"Tor will encrypt your traffic to and within the Tor network, but the encryption of your traffic to the final destination website **depends on t...I Read through FAQ and saw this grammatical error in the screenshot below:
**Has to be**
"Tor will encrypt your traffic to and within the Tor network, but the encryption of your traffic to the final destination website **depends on that website**"
**Or**
"Tor will encrypt your traffic to and within the Tor network, but the encryption of your traffic to the final destination website **depends upon that website**"
**Not**
"Tor will encrypt your traffic to and within the Tor network, but the encryption of your traffic to the final destination website **depends upon on that website**"
![grammatical_-error](/uploads/14ad21bffd301cf5aacfc21313e501a6/grammatical_-error.PNG)BurnleydevBurnleydevhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40328Tor Browser doesn't run on recent arch: Missing server TLS certificates2021-03-08T17:48:09ZJim NewsomeTor Browser doesn't run on recent arch: Missing server TLS certificatesWe've had two reports of users on 10.0.10 on Linux not being able to establish a secure connection to any web site. The url shows https, but "insecure". Clicking through, it looks as if there's no server certificate at all.
One user rep...We've had two reports of users on 10.0.10 on Linux not being able to establish a secure connection to any web site. The url shows https, but "insecure". Clicking through, it looks as if there's no server certificate at all.
One user reported that switching to the alpha version of TBB resolved the issue. ~~The second user reported that it didn't.~~
The second user verified that the browser does correctly report *invalid* certificates, using badssl.com.
The second user was able to fix it with a clean profile. (Update: a clean profile *on alpha*. Still broken on 10.0.10)
![-Hqs](/uploads/20c9440c995efd06e765c0c195b6cdec/-Hqs.png)
![-Hqz](/uploads/f5a88d5735f99a6fa8f5a921f638c9d6/-Hqz.png)
![-HNT](/uploads/0863d0230349bff897b2292c78e8fbd8/-HNT.png)
```
15:40 < rany> Hi, I'm having an issue right now with Tor Browser reporting all HTTPS
connections as insecure. This happened after the update to 10.0.10
15:43 < rany> screenshot: https://0x0.st/-HNT.png
16:47 < jnewsome> rany: what does it say if you click on the right-arrow next to
"connection not secure"?
16:50 < rany> https://0x0.st/-Hqs.png
16:53 < jnewsome> strange. someone reported a similar problem yesterday; I think they
ultimately worked around it by installing the alpha version of the tor
browser
16:53 < rany> and https://0x0.st/-Hqz.png
16:53 < rany> hmm, well it's not bothering too much but i wanted to check if its
intentional cuz i can't find anything in the change log
16:53 < jnewsome> thank you for the screenshots; I wasn't able to get detailed info from
the reporter yesterday
16:54 < rany> so not all TB users have this issue?
16:54 < jnewsome> nope; I'm on the same version and not experiencing that problem
16:55 < jnewsome> is this linux?
16:55 < rany> yes
16:55 < jnewsome> I would be careful about using the browser in this state; you might not
detect a man-in-the-middle attack
16:56 < rany> I'll try the alpha version of TB and check if that fixes it
16:56 < rany> yeah, good point
16:58 < rany> tor browser alpha doesn't fix it for me :/
16:59 < jnewsome> I wonder if this could be an actual attack. Could you try requesting a
few circuits and see if it works for any of them?
17:01 < rany> i've tried a ton of circuits and so far they all have the issue ... so
probably unlikely
17:01 < rany> also bad SSL certificates still get detected fine ... just tried from
badssl.com
17:02 < rany> so it seems like verification is working all right
...
17:25 < rany> though TB works fine with a clean profile
17:26 < rany> not sure why the update broke my old profile
...
17:36 < rany> nevermind, i just got the same issue even with a clean profile
17:36 < rany> /shrug
17:36 < rany> (but that's on stable TB )
```Tor Browser: 10.0https://gitlab.torproject.org/tpo/anti-censorship/emma/-/issues/5Incorporate emma into OONI2024-02-29T15:21:09ZPhilipp Winterphw@torproject.orgIncorporate emma into OONIMaria once suggested adding emma to OONI. Both are written in Go, so it may not be a terribly complex endeavour. I'll have a chat with Simone to get a better sense of what this would entail.
The big benefit of having emma in OONI is th...Maria once suggested adding emma to OONI. Both are written in Go, so it may not be a terribly complex endeavour. I'll have a chat with Simone to get a better sense of what this would entail.
The big benefit of having emma in OONI is that we would get significantly more measurements and we no longer need to expect users to be able to compile programs.https://gitlab.torproject.org/tpo/core/tor/-/issues/40194provide relay health prometheus metrics via MetricsPort2023-02-07T10:25:16Znusenuprovide relay health prometheus metrics via MetricsPorttor recently got support for `MetricsPort` in v0.4.5.1-alpha (#40063).
For more context to this feature request see:
https://lists.torproject.org/pipermail/tor-dev/2019-February/013655.html
I'm proposing to add the following prometheus...tor recently got support for `MetricsPort` in v0.4.5.1-alpha (#40063).
For more context to this feature request see:
https://lists.torproject.org/pipermail/tor-dev/2019-February/013655.html
I'm proposing to add the following prometheus metrics (incl. labels), all metrics show absolute counters since tor started:
(feel free to add constraints like reducing granularity of counters or only updating counters once every x minutes for safety reasons)
## on exit relays (DNS related metrics)
* tor_relay_exit_dns_errors{reason="timeout"}
* tor_relay_exit_dns_errors{reason="SERVFAIL"}
* tor_relay_exit_dns_errors{reason="REFUSED"}
DNS RCODEs:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
I'm not sure if this is even visible to tor (unless ServerDNSResolvConfFile is used)
but if possible this kind of data would ideally be available for each resolver IP so the relay operator can detect and disable the faulty resolver:
* tor_relay_exit_dns_errors{reason="timeout", resolver="1.1.1.1"}
* tor_relay_exit_dns_errors{reason="timeout", resolver="8.8.8.8"}
* ...
* tor_relay_exit_maxdnsqueriespercircuit max amount of DNS queries caused by a single circuit since tor started
* exit stats as defined in (if enabled in torrc)
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1197
## other relay metrics
* tor_memory_bytes total amount of memory used by the tor process in bytes
* tor_relay_dos_circuitskilledwithtoomanycells
* tor_relay_dos_circuitsrejected
* tor_relay_dos_markedaddress
* tor_relay_dos_connectionsclosed
* tor_relay_dos_singlehopclientsrefused
* tor_relay_dos_introduce2rejected
* tor_relay_opencircuits currently open tor circuits
* tor_relay_connections{v="v1",direction="initiated"}
* tor_relay_connections{v="v1",direction="received"}
* tor_relay_connections{v="v2",direction="initiated"}
* tor_relay_connections{v="v2",direction="received"}
* tor_relay_connections{v="v3"...
* tor_relay_traffic{direction="sent"} total traffic sent in bytes
* tor_relay_traffic{direction="received"} total traffic received in bytes
* tor_relay_circuit_handshakes{proto="TAP"}
* tor_relay_circuit_handshakes{proto="NTor"}
* tor_relay_uptime tor process uptime in seconds
* tor_relay_version used tor version
* tor_relay_version_recommended boolean to indicate whether the used version is recommended
* ...
## Flags
* tor_relay_flag_stable
* tor_relay_flag_guard
* tor_relay_flag_exit
* tor_relay_flag_...
Some more:
- amount of closed/failed circuits broken down by their reason value
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1402
- amount of closed/failed OR connections broken down by their reason value
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2202
- cell stats (if enabled in torrc)
as defined in:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1137Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/team/-/issues/15Delete or archive tpo/core projects not maintained by the tpo/core team2020-10-08T13:53:16ZNick MathewsonDelete or archive tpo/core projects not maintained by the tpo/core teamThere are a few projects under tpo/core that we should probably archive, delete, or something.
https://gitlab.torproject.org/tpo/core/pytorctl is superseded by stem. We don't maintain it any more; only obsolete tools like the old torfl...There are a few projects under tpo/core that we should probably archive, delete, or something.
https://gitlab.torproject.org/tpo/core/pytorctl is superseded by stem. We don't maintain it any more; only obsolete tools like the old torflow use it. No commits to that repository since 2015.
https://gitweb.torproject.org/tordnsel.git/ is written in Haskell, and in an old version too. We don't understand it; if we were going to maintain this, we would probably start by just rewriting it. No commits to that repository since 2016.
https://gitlab.torproject.org/tpo/core/rpm-package is not something we maintain, and has no corresponding it repository. There is only one ticket there, and it is about retiring the trac component "rpm packaging"
Not urgent, and let's not actually make these changes till other @tpo/core people can weigh in.Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40150Huge bezels on window sides on OSX after updating to v102021-06-24T20:46:38ZYog SothothHuge bezels on window sides on OSX after updating to v10Currently Tor Browser 10 window on OSX 10.14 looks like that:
![Screenshot_2020-09-24_at_18.33.28](/uploads/13578ac9180eb1dacb84f7b491421cf0/Screenshot_2020-09-24_at_18.33.28.png)
with huge bezels between the window border and actual we...Currently Tor Browser 10 window on OSX 10.14 looks like that:
![Screenshot_2020-09-24_at_18.33.28](/uploads/13578ac9180eb1dacb84f7b491421cf0/Screenshot_2020-09-24_at_18.33.28.png)
with huge bezels between the window border and actual web content, which randomly resize when the window gets resized. What is this and how can that be made normal?https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/72monitor anonymous user account2020-09-30T19:05:30ZMatthew Finkelmonitor anonymous user accountI noticed user `writecode` is now a replacement for the trac `cypherpunks` account with the password in the account's name. I'm not opposed to having an anonymous account, but I know there was concern about creating one when we migrated ...I noticed user `writecode` is now a replacement for the trac `cypherpunks` account with the password in the account's name. I'm not opposed to having an anonymous account, but I know there was concern about creating one when we migrated to gitlab. @gaba suggested we open a ticket, monitor the account's activity, and discuss it at the next gitlab meeting.https://gitlab.torproject.org/tpo/ux/research/-/issues/14Include an instant feedback link in RT responses2020-10-26T18:06:14ZAntonelaantonela@torproject.orgInclude an instant feedback link in RT responsesWe want to understand why users are not replying back our RT responses related with bridges. This can be extended to any other responses eg. installing Tor Browser.We want to understand why users are not replying back our RT responses related with bridges. This can be extended to any other responses eg. installing Tor Browser.Sponsor 30 - Objective 3.2Antonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/58Delete or archive tpo/core projects not maintained by the tpo/core team2020-09-29T17:29:11ZNick MathewsonDelete or archive tpo/core projects not maintained by the tpo/core teamThere are a few projects under tpo/core that we should probably archive, delete, or something.
https://gitlab.torproject.org/tpo/core/pytorctl is superseded by stem. We don't maintain it any more; only obsolete tools like the old torfl...There are a few projects under tpo/core that we should probably archive, delete, or something.
https://gitlab.torproject.org/tpo/core/pytorctl is superseded by stem. We don't maintain it any more; only obsolete tools like the old torflow use it. No commits to that repository since 2015.
https://gitweb.torproject.org/tordnsel.git/ is written in Haskell, and in an old version too. We don't understand it; if we were going to maintain this, we would probably start by just rewriting it. No commits to that repository since 2016.
https://gitlab.torproject.org/tpo/core/rpm-package is not something we maintain, and has no corresponding it repository. There is only one ticket there, and it is about retiring the trac component "rpm packaging"
Not urgent, and let's not actually make these changes till other @tpo/core people can weigh in.Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/core/team/-/issues/4Get coverity scan working again2020-07-16T17:09:23ZNick MathewsonGet coverity scan working againFinally heard back from the coverity scan admins -- they won't be updating the scan to a version that supports GCC 10 until later this year. So for now, I need to build gcc 9.2 for my system and run coverity on that.
In the longer term...Finally heard back from the coverity scan admins -- they won't be updating the scan to a version that supports GCC 10 until later this year. So for now, I need to build gcc 9.2 for my system and run coverity on that.
In the longer term it would be cool to have a cron job, possibly from gitlab CI, run coverity's scan-analyze for us.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/web/lego/-/issues/17Add a fallback font?2021-07-12T16:48:32ZBarkin SimsekAdd a fallback font?Hi, I'm not sure if this is the correct repo to report this issue but this one seems like to be used in all websites.
So, tpo websites use the custom "Source Sans Pro" font and it takes some time to download that font for browsers. The ...Hi, I'm not sure if this is the correct repo to report this issue but this one seems like to be used in all websites.
So, tpo websites use the custom "Source Sans Pro" font and it takes some time to download that font for browsers. The browser shows everything in "Times New Roman" font for a brief amount of time. Yes, it is not the end of the world but I think it looks ugly.
This is how it looks on my end:
![Screen_Recording_2020-07-02_at_2.12.09_AM](/uploads/4df576e4f102f65b094974cf2daa5685/Screen_Recording_2020-07-02_at_2.12.09_AM.gif)
My suggestion would be setting a fallback font like "Helvetica Neue" to show the website in it until "Source Sans Pro" loads. It is not the best solution but at least it is a better transition than "Times New Roman" to "Source Sans Pro".
And it is very easy to solve. You just need to define the font family in this order: `font-family: 'Source Sans Pro', 'Helvetica Neue', Helvetica, Arial, sans-serif;`
I used Source Sans Pro in my project's dashboard page and I had the exact same issue. You can check my website to see how the proposed transition looks like: https://dashboard.captcha.wtf/
If you find a better looking fallback system font, please let me know :)https://gitlab.torproject.org/tpo/core/tor/-/issues/40019git hooks: Stop running practracker constantly2020-10-22T15:12:33ZDavid Gouletdgoulet@torproject.orggit hooks: Stop running practracker constantlyPractracker runs on every commit with the pre-commit hook. It does _not_ run on `maint-` branches but it runs on master but also on EVERY development branch anyone does.
The reason is simple, it is that we never merge things that breaks...Practracker runs on every commit with the pre-commit hook. It does _not_ run on `maint-` branches but it runs on master but also on EVERY development branch anyone does.
The reason is simple, it is that we never merge things that breaks practracker into master so makes sense that every dev branch is tested.
However, I'm arguing here that running practracker constantly is a waste of time and extremely annoying for development.
There is value in practracker but I think we could simply run it once in a while, maybe every release, update the exception file and be done with it. There is even an argument to say that one should only run it in order to measure our technical debt in some ways or wanting to start fixing part of it.
Again, I don't see value in constantly having a perfectly up to date `exceptions.txt` file. There is value that we have the tool available in our repository but not being run all the time. Yes, it can break but this is why we can simply run it as part of our release process.
Thus I vote to remove it from our `pre-commit-git.hook` file.
Thoughts @tpo/core ?David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/15279uMatrix & uBlock to Replace NoScript2022-06-15T02:43:33ZTracuMatrix & uBlock to Replace NoScriptI always slightly hated noscript because if I wanted to add a site exception to enable ONLY javascript, I was forced to risk allowing, for example, cross-site scripting or XHR for that site along with any others that I wanted to keep blo...I always slightly hated noscript because if I wanted to add a site exception to enable ONLY javascript, I was forced to risk allowing, for example, cross-site scripting or XHR for that site along with any others that I wanted to keep blocked.
If I wanted to allow ONLY a function of a 3rd party site required to make the 1st party site run, I had to allow unlimited access to the 3rd party site instead of just what I wanted.
Of course, I could go into noscript preferences and disable "block javascript" but that was GLOBAL and a pain to have to go back in settings to re-enable before browsing another site. Worse, it would be a risk if the current site threw a 3rd-party popup while I had the Global temporarily off...... you get the idea!
The makers of NoScript, in parallel, have been developing_ **HTTP Switchboard**_ for a long time_._ It is the exact same as NoScript but extremely better, allowing FULL flexibility. You can set, per Site, each domain's ability to manipulate the site in EITHER OR ALL categories of cookie(s), css, images, plugins, scripts, XHR, and "others".
This means if I go to yahoo.com, I can allow, either by default or individual site basis, yahoo.com to ONLY push images, css, and images. Then I can allow ONLY any subdomain required for certain functionality to ONLY run those elements needed for that functionality.
If I need to allow a third party, it's all the same and, unless I choose to make that exception global, that 3rd party domain's element will ONLY be allowed on THAT site!
If I want to allow a certain domain's element on ALL sites, by default, that's an option **__but, unlike noscript, I don't have to allow a global exception just to get a local exception for that one site's functionality__**.
They have now went even further to make ___**uBlock**___ and __**_uMatrix**___, two addons that work together. The only difference between uMatrix and HTTP Switchboard is they took the checkbox on the option pages of HTTP Switchboard, to allow all 1st party elements, and put it on the main switchboard/matrix, allowing specific elements on ALL first party sites by default instead of having to either allow ALL elements on first party sites OR manually selecting on each new 1st party domain visited (see pictures).
uBlock, along with either uMatrix or Http Switchboard, are even better now by having auto-updating malicious (uMatrix) and privacy lists (uBlock),__ with the ability to add custom ones to block scripts/xhr on sites that would leak the ip, track you, or be malicious! __ If I choose to unblock an entire subdomain instead of specific elements on that 1st/3rd party (sub)domain, they will still block portions of those domains appearing on the self-updating block lists, unless I go further to override that.
### The BEST PART OF ALL: I've worried about extensions I've installed and what sites they can connect to; with uMatrix, you can choose to have a separate set of permissions to apply to the extensions. Finally, I can restrict extensions that shouldn't connect to anywhere to not being able to :) This is the ONLY and FIRST noscript-like element manager, afaik, that can do this! You can use uMatrix to block uMatrix itself from getting blocklist updates, as I've accidentally done :)
## The abilities to customize what to SAFELY allow and what to keep blocked, no matter what domain or what site, are ENDLESS; this will really help people use Tor more safely! PLEASE TAKE NOSCRIPT TO THE 21st CENTURY BY REPLACING IT WITH UMATRIX AND UBLOCK!
**Trac**:
**Username**: johnakabeanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33530Dir auths should notice relays with wrong clocks and act somehow (BadClock fl...2023-02-07T10:15:08ZRoger DingledineDir auths should notice relays with wrong clocks and act somehow (BadClock flag, withhold Guard)Directory authorities scan every relay every 22 minutes or so, to test reachability.
As part of establishing the Tor connection handshake, they get a netinfo cell from the relay. So if they look at it, they will know whether the relay's...Directory authorities scan every relay every 22 minutes or so, to test reachability.
As part of establishing the Tor connection handshake, they get a netinfo cell from the relay. So if they look at it, they will know whether the relay's clock is right or wrong.
So we're nearly there. Now we should act when we find a relay with a wrong clock, to help the relay operator fix it, and to reduce the harm to clients.
I suggest taking two responses if a relay has a wrong clock:
(A) Don't assign it the Guard flag. Clients rely on their guards for time, e.g. because they need the guards to have proper cached dir info. And in the glorious future where we've made progress on legacy/trac#2628 and friends, while we won't want to rely solely on non-dir-auth relays to tell us if we're skewed, if we can drive down false positives from normal relays, the parameters get easier to pick for whatever solutions we decide on.
(B) Put the "BadClock" flag in our vote about it. We don't need to change the consensus building process, or even get that flag into the consensus itself. Just having it in the votes means that consensus-health and relay-search can look at it and visualize it for relay operators, rather than needing to do their own clock scans. (And having it there helps the operator debug confusing questions like *why* they aren't getting the Guard flag.) And as a bonus here, eventually Serge will put that flag in its bridge networkstatus document, so bridgedb can make a smarter decision, and so relay-search can visualize it too.