Tor is released: back to unstable development!

by nickm | January 25, 2018

Hi!  There's a new alpha release available for download.  If you build Tor from source, you can download the source code for from the usual place on the website.  Packages should be available over the coming weeks, with a new alpha Tor Browser release some time in February.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor is the first release in the 0.3.3.x series. It adds several new features to Tor, including several improvements to bootstrapping, and support for an experimental "vanguards" feature to resist guard discovery attacks. This series also includes better support for applications that need to embed Tor or manage v3 onion services.

Changes in version - 2018-01-25

  • Major features (embedding):
    • There is now a documented stable API for programs that need to embed Tor. See tor_api.h for full documentation and known bugs. Closes ticket 23684.
    • Tor now has support for restarting in the same process. Controllers that run Tor using the "tor_api.h" interface can now restart Tor after Tor has exited. This support is incomplete, however: we fixed crash bugs that prevented it from working at all, but many bugs probably remain, including a possibility of security issues. Implements ticket 24581.
  • Major features (IPv6, directory documents):
    • Add consensus method 27, which adds IPv6 ORPorts to the microdesc consensus. This information makes it easier for IPv6 clients to bootstrap and choose reachable entry guards. Implements 23826.
    • Add consensus method 28, which removes IPv6 ORPorts from microdescriptors. Now that the consensus contains IPv6 ORPorts, they are redundant in microdescs. This change will be used by Tor clients on 0.2.8.x and later. (That is to say, with all Tor clients having IPv6 bootstrap and guard support.) Implements 23828.
    • Expand the documentation for AuthDirHasIPv6Connectivity when it is set by different numbers of authorities. Fixes 23870 on


  • Major features (onion service v3, control port):
    • The control port now supports commands and events for v3 onion services. It is now possible to create ephemeral v3 services using ADD_ONION. Additionally, several events (HS_DESC, HS_DESC_CONTENT, CIRC and CIRC_MINOR) and commands (GETINFO, HSPOST, ADD_ONION and DEL_ONION) have been extended to support v3 onion services. Closes ticket 20699; implements proposal 284.
  • Major features (onion services):
    • Provide torrc options to pin the second and third hops of onion service circuits to a list of nodes. The option HSLayer2Guards pins the second hop, and the option HSLayer3Guards pins the third hop. These options are for use in conjunction with experiments with "vanguards" for preventing guard enumeration attacks. Closes ticket 13837.
  • Major features (rust, portability, experimental):
    • Tor now ships with an optional implementation of one of its smaller modules (protover.c) in the Rust programming language. To try it out, install a Rust build environment, and configure Tor with "--enable-rust --enable-cargo-online-mode". This should not cause any user-visible changes, but should help us gain more experience with Rust, and plan future Rust integration work. Implementation by Chelsea Komlo. Closes ticket 22840.
  • Major features (storage, configuration):
    • Users can store cached directory documents somewhere other than the DataDirectory by using the CacheDirectory option. Similarly, the storage location for relay's keys can be overridden with the KeyDirectory option. Closes ticket 22703.
  • Major features (v3 onion services, ipv6):
    • When v3 onion service clients send introduce cells, they now include the IPv6 address of the rendezvous point, if it has one. Current v3 onion services running 0.3.2 ignore IPv6 addresses, but in future Tor versions, IPv6-only v3 single onion services will be able to use IPv6 addresses to connect directly to the rendezvous point. Closes ticket 23577. Patch by Neel Chauhan.
  • Major bugfixes (onion services, retry behavior):
    • Fix an "off by 2" error in counting rendezvous failures on the onion service side. While we thought we would stop the rendezvous attempt after one failed circuit, we were actually making three circuit attempts before giving up. Now switch to a default of 2, and allow the consensus parameter "hs_service_max_rdv_failures" to override. Fixes bug 24895; bugfix on 0.0.6.
    • New-style (v3) onion services now obey the "max rendezvous circuit attempts" logic. Previously they would make as many rendezvous circuit attempts as they could fit in the MAX_REND_TIMEOUT second window before giving up. Fixes bug 24894; bugfix on
  • Major bugfixes (relays):
    • Fix a set of false positives where relays would consider connections to other relays as being client-only connections (and thus e.g. deserving different link padding schemes) if those relays fell out of the consensus briefly. Now we look only at the initial handshake and whether the connection authenticated as a relay. Fixes bug 24898; bugfix on
  • Minor feature (IPv6):
    • Make IPv6-only clients wait for microdescs for relays, even if we were previously using descriptors (or were using them as a bridge) and have a cached descriptor for them. Implements 23827.
    • When a consensus has IPv6 ORPorts, make IPv6-only clients use them, rather than waiting to download microdescriptors. Implements 23827.
  • Minor features (cleanup):
    • Tor now deletes the CookieAuthFile and ExtORPortCookieAuthFile when it stops. Closes ticket 23271.
  • Minor features (defensive programming):
    • Most of the functions in Tor that free objects have been replaced with macros that free the objects and set the corresponding pointers to NULL. This change should help prevent a large class of dangling pointer bugs. Closes ticket 24337.
    • Where possible, the tor_free() macro now only evaluates its input once. Part of ticket 24337.
    • Check that microdesc ed25519 ids are non-zero in node_get_ed25519_id() before returning them. Implements 24001, patch by "aruna1234".
  • Minor features (directory authority):
    • Make the "Exit" flag assignment only depend on whether the exit policy allows connections to ports 80 and 443. Previously relays would get the Exit flag if they allowed connections to one of these ports and also port 6667. Resolves ticket 23637.
  • Minor features (embedding):
    • Tor can now start with a preauthenticated control connection created by the process that launched it. This feature is meant for use by programs that want to launch and manage a Tor process without allowing other programs to manage it as well. For more information, see the __OwningControllerFD option documented in control-spec.txt. Closes ticket 23900.
    • On most errors that would cause Tor to exit, it now tries to return from the tor_main() function, rather than calling the system exit() function. Most users won't notice a difference here, but it should make a significant for programs that run Tor inside a separate thread: they should now be able to survive Tor's exit conditions rather than having Tor shut down the entire process. Closes ticket 23848.
    • Applications that want to embed Tor can now tell Tor not to register any of its own POSIX signal handlers, using the __DisableSignalHandlers option. Closes ticket 24588.
  • Minor features (fallback directory list):
    • Avoid selecting fallbacks that change their IP addresses too often. Select more fallbacks by ignoring the Guard flag, and allowing lower cutoffs for the Running and V2Dir flags. Also allow a lower bandwidth, and a higher number of fallbacks per operator (5% of the list). Implements ticket 24785.
    • Update the fallback whitelist and blacklist based on opt-ins and relay changes. Closes tickets 22321, 24678, 22527, 24135, and 24695.
  • Minor features (fallback directory mirror configuration):
    • Add a nickname to each fallback in a C comment. This makes it easier for operators to find their relays, and allows stem to use nicknames to identify fallbacks. Implements ticket 24600.
    • Add a type and version header to the fallback directory mirror file. Also add a delimiter to the end of each fallback entry. This helps external parsers like stem and Relay Search. Implements ticket 24725.
    • Add an extrainfo cache flag for each fallback in a C comment. This allows stem to use fallbacks to fetch extra-info documents, rather than using authorities. Implements ticket 22759.
    • Add the script for automatically generating fallback directory mirror lines from relay fingerprints. No more typos! Add the script for automatically looking up operator contact info from relay fingerprints. Implements ticket 24706, patch by teor and atagar.
    • Reject any fallback directory mirror that serves an expired consensus. Implements ticket 20942, patch by "minik".
    • Remove commas and equals signs from external string inputs to the fallback list. This avoids format confusion attacks. Implements ticket 24726.
    • Remove the "weight=10" line from fallback directory mirror entries. Ticket 24681 will maintain the current fallback weights by changing Tor's default fallback weight to 10. Implements ticket 24679.
    • Stop logging excessive information about fallback netblocks. Implements ticket 24791.
  • Minor features (forward-compatibility):
    • If a relay supports some link authentication protocol that we do not recognize, then include that relay's ed25519 key when telling other relays to extend to it. Previously, we treated future versions as if they were too old to support ed25519 link authentication. Closes ticket 20895.
  • Minor features (heartbeat):
    • Add onion service information to our heartbeat logs, displaying stats about the activity of configured onion services. Closes ticket 24896.
  • Minor features (instrumentation, development):
    • Add the MainloopStats option to allow developers to get instrumentation information from the main event loop via the heartbeat messages. We hope to use this to improve Tor's behavior when it's trying to sleep. Closes ticket 24605.
  • Minor features (log messages):
    • Improve a warning message that happens when we fail to re-parse an old router because of an expired certificate. Closes ticket 20020.
    • Make the log more quantitative when we hit MaxMemInQueues threshold exposing some values. Closes ticket 24501.
  • Minor features (logging, android):
    • Added support for the Android logging subsystem. Closes ticket 24362.
  • Minor features (performance):
    • Support predictive circuit building for onion service circuits with multiple layers of guards. Closes ticket 23101.
    • Use stdatomic.h where available, rather than mutexes, to implement atomic_counter_t. Closes ticket 23953.
  • Minor features (performance, 32-bit):
    • Improve performance on 32-bit systems by avoiding 64-bit division when calculating the timestamp in milliseconds for channel padding computations. Implements ticket 24613.
    • Improve performance on 32-bit systems by avoiding 64-bit division when timestamping cells and buffer chunks for OOM calculations. Implements ticket 24374.
  • Minor features (performance, OSX, iOS):
    • Use the mach_approximate_time() function (when available) to implement coarse monotonic time. Having a coarse time function should avoid a large number of system calls, and improve performance slightly, especially under load. Closes ticket 24427.
  • Minor features (performance, windows):
    • Improve performance on Windows Vista and Windows 7 by adjusting TCP send window size according to the recommendation from SIO_IDEAL_SEND_BACKLOG_QUERY. Closes ticket 22798. Patch from Vort.
  • Minor features (relay):
    • Implement an option, ReducedExitPolicy, to allow an Tor exit relay operator to use a more reasonable ("reduced") exit policy, rather than the default one. If you want to run an exit node without thinking too hard about which ports to allow, this one is for you. Closes ticket 13605. Patch from Neel Chauhan.
  • Minor features (testing, debugging, embedding):
    • For development purposes, Tor now has a mode in which it runs for a few seconds, then stops, and starts again without exiting the process. This mode is meant to help us debug various issues with ticket 23847. To use this feature, compile with --enable-restart-debugging, and set the TOR_DEBUG_RESTART environment variable. This is expected to crash a lot, and is really meant for developers only. It will likely be removed in a future release. Implements ticket 24583.
  • Minor bugfix (network IPv6 test):
    • Tor's test scripts now check if "ping -6 ::1" works when the user runs "make test-network-all". Fixes bug 24677; bugfix on Patch by "ffmancera".
  • Minor bugfixes (build, rust):
    • Fix output of autoconf checks to display success messages for Rust dependencies and a suitable rustc compiler version. Fixes bug 24612; bugfix on
    • When building with Rust on OSX, link against libresolv, to work around the issue at Fixes bug 24652; bugfix on
    • Don't pass the --quiet option to cargo: it seems to suppress some errors, which is not what we want to do when building. Fixes bug 24518; bugfix on
    • Build correctly when building from outside Tor's source tree with the TOR_RUST_DEPENDENCIES option set. Fixes bug 22768; bugfix on
  • Minor bugfixes (directory authorities, IPv6):
    • When creating a routerstatus (vote) from a routerinfo (descriptor), set the IPv6 address to the unspecified IPv6 address, and explicitly initialize the port to zero. Fixes bug 24488; bugfix on
  • Minor bugfixes (fallback directory mirrors):
    • Make search harder for python. (Some OSs don't put it in /usr/bin.) Fixes bug 24708; bugfix on
  • Minor bugfixes (hibernation, bandwidth accounting, shutdown):
    • When hibernating, close connections normally and allow them to flush. Fixes bug 23571; bugfix on Also fixes bug 7267.
    • Do not attempt to launch self-reachability tests when entering hibernation. Fixes a case of bug 12062; bugfix on 0.0.9pre5.
    • Resolve several bugs related to descriptor fetching on bridge clients with bandwidth accounting enabled. (This combination is not recommended!) Fixes a case of bug 12062; bugfix on
    • When hibernating, do not attempt to launch DNS checks. Fixes a case of bug 12062; bugfix on
    • When hibernating, do not try to upload or download descriptors. Fixes a case of bug 12062; bugfix on 0.0.9pre5.
  • Minor bugfixes (IPv6, bridges):
    • Tor now always sets IPv6 preferences for bridges. Fixes bug 24573; bugfix on
    • Tor now sets IPv6 address in the routerstatus as well as in the router descriptors when updating addresses for a bridge. Closes ticket 24572; bugfix on Patch by "ffmancera".
  • Minor bugfixes (linux seccomp2 sandbox):
    • When running with the sandbox enabled, reload configuration files correctly even when %include was used. Previously we would crash. Fixes bug 22605; bugfix on 0.3.1. Patch from Daniel Pinto.
  • Minor bugfixes (memory leaks):
    • Avoid possible at-exit memory leaks related to use of Libevent's event_base_once() function. (This function tends to leak memory if the event_base is closed before the event fires.) Fixes bug 24584; bugfix on
    • Fix a harmless memory leak in tor-resolve. Fixes bug 24582; bugfix on
  • Minor bugfixes (OSX):
    • Don't exit the Tor process if setrlimit() fails to change the file limit (which can happen sometimes on some versions of OSX). Fixes bug 21074; bugfix on 0.0.9pre5.
  • Minor bugfixes (performance, fragile-hardening):
    • Improve the performance of our consensus-diff application code when Tor is built with the --enable-fragile-hardening option set. Fixes bug 24826; bugfix on
  • Minor bugfixes (performance, timeouts):
    • Consider circuits for timeout as soon as they complete a hop. This is more accurate than applying the timeout in circuit_expire_building() because that function is only called once per second, which is now too slow for typical timeouts on the current network. Fixes bug 23114; bugfix on
    • Use onion service circuits (and other circuits longer than 3 hops) to calculate a circuit build timeout. Previously, Tor only calculated its build timeout based on circuits that planned to be exactly 3 hops long. With this change, we include measurements from all circuits at the point where they complete their third hop. Fixes bug 23100; bugfix on
  • Minor bugfixes (testing):
    • Give out Exit flags in bootstrapping networks. Fixes bug 24137; bugfix on
    • Fix a memory leak in the scheduler/loop_kist unit test. Fixes bug 25005; bugfix on
  • Code simplification and refactoring:
    • Remove /usr/athena from search path in Closes ticket 24363.
    • Remove duplicate code in node_has_curve25519_onion_key() and node_get_curve25519_onion_key(), and add a check for a zero microdesc curve25519 onion key. Closes ticket 23966, patch by "aruna1234" and teor.
    • Rewrite channel_rsa_id_group_set_badness to reduce temporary memory allocations with large numbers of OR connections (e.g. relays). Closes ticket 24119.
    • Separate the function that deletes ephemeral files when Tor stops gracefully.
    • Small changes to Tor's buf_t API to make it suitable for use as a general-purpose safe string constructor. Closes ticket 22342.
    • Switch -Wnormalized=id to -Wnormalized=nfkc in to avoid source code identifier confusion. Closes ticket 24467.
    • The tor_git_revision[] constant no longer needs to be redeclared by everything that links against the rest of Tor. Done as part of ticket 23845, to simplify our external API.
    • We make extend_info_from_node() use node_get_curve25519_onion_key() introduced in ticket 23577 to access the curve25519 public keys rather than accessing it directly. Closes ticket 23760. Patch by Neel Chauhan.
    • Add a function to log channels' scheduler state changes to aid debugging efforts. Closes ticket 24531.
  • Documentation:
    • Add documentation on how to build tor with Rust dependencies without having to be online. Closes ticket 22907; bugfix on
    • Clarify the behavior of RelayBandwidth{Rate,Burst} with client traffic. Closes ticket 24318.
    • Document that OutboundBindAddress doesn't apply to DNS requests. Closes ticket 22145. Patch from Aruna Maurya.
    • Document that operators who run more than one relay or bridge are expected to set MyFamily and ContactInfo correctly. Closes ticket 24526.
  • Code simplification and refactoring (channels):
    • Remove the incoming and outgoing channel queues. These were never used, but still took up a step in our fast path.
    • The majority of the channel unit tests have been rewritten and the code coverage has now been raised to 83.6% for channel.c. Closes ticket 23709.
    • Remove other dead code from the channel subsystem: All together, this cleanup has removed more than 1500 lines of code overall and adding very little except for unit test.
  • Code simplification and refactoring (circuit rendezvous):
    • Split the client-size rendezvous circuit lookup into two functions: one that returns only established circuits and another that returns all kinds of circuits. Closes ticket 23459.
  • Code simplification and refactoring (controller):
    • Make most of the variables in networkstatus_getinfo_by_purpose() const. Implements ticket 24489.


Please note that the comment area below has been archived.

January 26, 2018


Could you answer to tor-internals-related questions: [1], [2], [3]?

When tor will move to ECC completely, i.e. RSA code will be removed? As I see, RSA-1024 is still used for communication with tor nodes running old tor versions.

When TorProject and Debian will add support for onion v3 mirrors (deb repositories)?

When my tor cannot connect to network because of misconfigured firewall it tries to connect to other tor nodes, it is normal. However, I recently noticed that it probes also some IP addresses which are not in tor network list. These IPs are not known by atlas and are not known by /var/lib/tor. I don't use bridges and don't have any bridge-related option configured. What are these IPs? Is it normal? When had I googled, I found that some of these unknown IPs were public known tor nodes some months ago. Can they be tor nodes without "Valid" flag? Few days later I checked these nodes in atlas again, and they still were not known.

ExoneraTor desn't display tor nodes flags (which were in the past) correctly. I mean, information from ExoneraTor contradicts to statistics stored in CollectTor. Is it some known issue? Should I create new ticket with particular example?

January 27, 2018


Haaaaaaaaaaaaai nickm!

This is seemingly the first time for you to start a blog entry with "Hi!". I am not so familiar with technological matter, but thank you for daily work to support us!

January 27, 2018


Some subdomains are currently down: and
are inaccessible.

January 29, 2018


Many popular hidden services have stopped supporting v3 addresses. One of them announced the following:

We are sad to announce that we have been forced to disable all our new v3 addresses due
to a possible bug in the Tor v3 system, which makes us less confident hosting them.

At some point after we enabled the v3 addresses, we began noticing some strange behavior
with our Tor engine. This behavior stopped as soon as we stopped the v3 services, which
can only mean that the v3 services caused it.

This is either an innocent bug in the new v3 system, or it could be something worse!
We're just not going to take any chances by having them running like this, and therefore
disabling all of our new v3 services for the time being, while taking further measures.

We don't want to create any panic, but we advice all v3 admins to check their Tor logs for
suspicious log entries, and to keep an eye on the general behavior of their services.

Our legacy service 'xxxxxxxxxxxxxxxx.onion' is hosted on a different system, and thus
not affected by this problem at all. It will stay as our main address and service for now,
and until the Tor devs fix this error/volnuability, and the v3 system matures a little.
We'll probbaly not get any new v3 addresses before this spring or summer.

We have a new v2 storage address: xxxxxxxxxxxxxxxx.onion
This address may change, which will be announced, depending on the level of DoS attacks.

We'll be removing the announcement about the new v3 addresses from the archive, just to
avoid confusion.

We apologize for having gotten carried away some with the v3 hype, but we honestly
expected the Tor devs to do it *properly* when they were about to perform one the most
important updates to the Tor system so far! Obviously they screwed something up.

Hello friend,

v3 onion service developer here.

I was unaware of this post, or any other related posts. Do you know what the "strange behavior" they are referring to is? Without this info it's very hard for us to address it.

In any case, it should be no surprise to anyone that there are computer bugs lurking around the v3 codebase, since it's still quite new. We are trying to kill all of them, but we need help to track them down.

Please let us know what's the best way to learn more info about this (or any other) issues. You can also get in touch pivately if you want at

Cheers :)

Vague, non-specific concerns about v3 onions. Classic psy-ops to try and dissuade people from promoting their take up.

That means they're probably working well. Time to accelerate their roll-out I say. :-)

PS When is Tor gonna design / think tank a solution to the malicious relay issue at large. Right now the anarchy model has led to infestation by government creeps. So, isn't some form of higher security vetting possible over the long term i.e. using libraries, universities and reasonably trusted institutions for (hopefully, eventually) 1000s of relays?

Yes, building a better community and network of trusted relay operators is definitely something we are interested in and we are hoping to do better in the future.

We want to explore ideas like relay operator conferences, and operator networking, build social maps (only of operators who are interested in participating of course), assign trust scores, etc. so that in the future we can do more trust-based path routing too.

> Vague, non-specific concerns about v3 onions. Classic psy-ops to try and dissuade people from promoting their take up.

My first thought also :-/ But then I had second thoughts.

On second reading, I think it is possible that a genuine onion operator really did notice apparent specific and novel problems, panicked, and wrote a somewhat ill-considered post. The biggest thing missing from the post in question is a statement that they are contacting the Tor team with details of the "strange behavior". The reminder that TP might be acting under duress (e.g. if some government with global reach has arrested all the key Tor people and is controlling their actions) is unpleasant, but this point is something which all Tor users must necessarily consider under certain circumstances.

FWIW, I think other explanations are much more likely, given what we know at this point. Assuming the claim is genuine, one intriguing possibility might be that the operator installed the Meltdown patch, that the forced "serialization" of instructions is causing a performance hit while performing cryptographic processing (essential to onion services, obviously, and a good example of the kind of computation most likely to be hit hardest by the performance slowdown), and that this is in turn causing unexpected software failures. Perhaps the v3 onions are susceptible to such a scenario if run on certain hardware. If the operators contact Tor Project, perhaps such problems (if they exist) can be debugged and fixed.

For newbies to this blog: we've often see two broad categories of suspicious claims made in comments:

o sweeping but ambiguous warnings of alleged vulnerabilities/backdoors in Tor, collusion by Tor Project with (often unnamed) baddies, unaccompanied by any evidence,

o enthusiastic recommendations of some "privacy" software or service unaffiliated with Tor-Project, as some kind of panacea for all communications security concerns,

The post in question is actually quite a bit more specific than the typical comment belonging to the former category.

I hope that, assuming the original comment is genuine, the original commentator will not take offense at our speculations. We all operate, thanks to NSA and a host of lesser enemies, under circumstances which render an utter lack of paranoia extremely unwise. This is indeed one of the major reasons why The People must win this war, if future generations are to enjoy any chance of living as humans rather than as slaves.

The post is genuine. Reposter redacted names of onion services and removed original PGP signature. It is some well known HS. Author of HS received information that his announcement was reposted in tor blog. He was advised to contact tor project.

That's what operating systems do with processes, dude.

And if questioner is refering CPU bugs (for example famous Spectre), then processes or virtual machines does not help either.

Then you need different physical CPU.

Agreed, news stories from multiple reputable sources (e.g., agree that hypervisors and cryptography are also broken by Meltdown/Spectre attacks. Everything we thought we knew about computer security over the past six decades is broken by these, because they break the distinction between userspace and kernelspace memory.

(Because cryptography provides no protection if running on a Meltdown vulnerable machine--- because key material must be stored in kernelspace memory, where Meltdown attacks can retrieve it--- VPNs also provide no protection for connections from such a machine.)

Intel promises new chips by Dec 2018, so "Cloud Computing" companies will have to replace all their servers then.

I suggest that people concerned about Meltdown/Spectre who are not sure if they have obtained a good Meltdown patch or Spectre resistance should consider using Tails. In particular, Tails 3.5 (see, may about as immunized from Meltdown (even if running on a laptop using an Intel CPU) as currently possible, and should also be resistant to some Spectre attacks.

January 31, 2018


I've got issues with V3 too. Just testing it out so far.

Problem is my V3 addresses stop working at random times WHILE the V2 addresses hosted on the same Tor process/instance work flawlessly. V3 can stop working for several hours at a time. No error logs. Very frustrating.

Also when using V3 addresses my logs are spammed with "possible replay detected" messages.

Has me worried.

Interesting! Are you using the latest stable, or earlier alpha versions? I suggest you use the stable, or git master since that includes most v3 fixes.

If you are encountering these issues with stable or git master, then perhaps please get in touch so that we can figure it out? Sending us info logs (anonymize them first plz) would be very helpful.

Also which "possible relay detected" message are you getting? I'll have to look into this later today.

Thanks :)

February 02, 2018


Hi ,
i have problems with Tor since Version and the newest. Tor works as relay.
With version my processor works with 3% power over the time.
With version or my processor needs 95-100% performance. This is not acceptable. I downloaded the fils new from the server and i checked the sign. Everything is ok.
Comes with the new version a update for this problem?

February 02, 2018

In reply to by noname (not verified)


Hey, this blog post is about Tor! Are you sure you're experiencing that with this version?

February 02, 2018


Tor Some days back I saw that almost 70-80% of nodes in my circuits were from Germany and France. However, last days it has drastically changed! Now sometimes my tor client make about 5 circuits (in total), which have no any node from Germany. Is it some type of recent DoS mitigations? Is something was changed to consensus weight for German and French nodes? According to atlas German and French nodes are still in place. In particular, Germany has about 1500 nodes now.

February 02, 2018


orbot/orfox blocks several sites, that normally works, for example are in my orfox no more visitable, the browser stalled. in the config dir lots of suspect config files were, is it possible, that someone taked over the control of the orbot-process?

February 02, 2018


Thanks much to all the Tor devs!

The long list of improvements is hugely impressive, even if I understand almost none of it :-)

Sounds like there may be some problems with v.3 onions but given the complexity the programming some initial problems when big changes are first rolled out is not surprising. I hope any onion operators who can reach Tor devs using secure communication methods will share details of what they are seeing in their logs with the devs.

February 04, 2018


hi guys

first off all i would like to say big thank you for your great time and effort being put into keeping our privacy alive.

i think this this is the first time i have some kind of negative feedback and its not even about tor but the new layout of the website. i wish there was a dark version of this blog. this white/light version really hurts my eyes. so for future development please include a dark version for the readers to choose as optional.

now to the main issue, whenever i try to take a screenshot of a websites warning sign for insecure connection that warning window disappear whenever i press the prt button.

if you press the (i) icon in upper left corner next to the address youll get a info message here saying:
secure connection

that specific info window i would like to take a screenshot of on any site.

how can i take screenshots of the warning sign in the upper left (i) address field?

thanks in advance and keep up the great work