About Tor: The Closet Under the Staircase; Lifting Tor's Hood
About Tor: The Closet Under the Staircase; Lifting Tor's Hood
The Closet Under the Staircase; Lifting Tor's Hood
[Image: walking down and up the “onion” encryption staircase, by the author.]
Acknowledgement: Thanks to all members of the Tor community who run relays.
Publication date: 2022-04-20
Update 2022-04-21: A new source for guard node policy has been added and referenced in the relevant section of the article. The author is grateful to the member of the Tor community who provided the reference.
Update 2022-04-26: Culture section added.
Update 2022-05-27: Improvements to commentary beneath the culture section video.
Introduction
The historical background to, the nature of, and the political basis for Tor and its community have been described. Use the Part 1 introduction for an overview of and links to sections in this article series.
Your author now takes a challenge; a deep description of the techniques used in the operation of the Tor network which can be understood by a non-technical audience.
If you have not read Part 2, please do. Therein are descriptions of what a VPN service is, how it operates, how its goals are different to Tor's and most importantly how Tor segments information to prevent any single element of the network being able to provide complete records of your activity when using Tor.
Lastly, if you have not already watched the first 26 minutes of the Moxie Marlinspike presentation included under the Sources section of part 1, please take the time to do so.
A Graphical Beginning
This interactive graphic by the Electronic Frontier Foundation gives an excellent "bird's eye view"of Tor. Consideration is given also to how a website using encryption, "HTTPS", also helps provide privacy. The two in combination are particularly well suited to protecting your right to privacy.
[Image: a screenshot of and link to this excellent work by EFF.]
Take the time to interact with this most instructive graphic. Look at who is "watching" and what they can learn, and how that changes as Tor and HTTPS are added or removed. Note there are four states:
no Tor and no HTTPs
only one of Tor or HTTPS (being two states), or
having both Tor and HTTPS
Thanks to the EFF for producing this informative, interactive graphic.
TLS and Forward Secrecy
Before getting into Tor, two important topics need be covered. The first is the HTTPS protocol, which was involved in the EFF interactive graphic above. The second is "Forward Secrecy".
During a rather lamentable late night session the Netscape Browser team, way back in the day, decided to use a model for applying cryptography to the Internet with which we are stuck. Its known as the "Trusted Third Party" model. This amounts to trust being placed in what are known as Certificate Authorities to issue certificates for websites. Embedded in these certificates are cryptographic details which allow secure communications between web browser applications and web sites which have these certificates. This was the mechanism that allowed secure internet banking and then internet commerce. For this the Netscape team deserve much credit. Why the "Trusted 3rd Party" model is lamentable is only briefly touched upon in this article, though we will see how Tor itself uses a different model.
These certificates enable the communication to be secure, and Diffie and Hellman's "New Directions in Cryptography" paper and its key exchange mechanism are the core technical underpinning of these secure communications.
HTTPS is HTTP + Secure, the secure version of the protocol used for web browsing. The suite of cryptography which can be used with HTTP has evolved almost out of sight of what it was, and the name has evolved too. It used to be SSL (Secure Socket Layer) and these days is referred to as TLS (Transport Layer Security). HTTPS today means HTTP + TLS, where TLS (currently 1.3) defines the best standardized cryptography available. The production of TLS 1.3 involved thousands of technical experts from around the world. It is one of the IETF's crowning achievements.
An “encryption” scheme provides more than privacy. The commonly used acronym to remember the three core properties of a secure communications scheme is humorously "CIA" representing Confidentiality, Integrity and Authenticity.
Confidentiality is the actual encryption. This means that people watching (or copying) the traffic cannot understand what is being exchanged. More precisely, the communications exchange is indistinguishable from random noise.
Integrity, an often overlooked topic, ensures that if anyone modifies the exchanged traffic the parties know about it, and can thus stop communicating. This is a defense against a devastating attack known as a "man in the middle" attack. In this attack an interloper sits between the communicating parties and either passively copies all of the traffic, or modifies parts of it to mislead the parties.
Authenticity is to ensure that you are actually speaking with the real entity, not someone impersonating that entity. One can see that this is an additional defense against a passive “man in the middle” attack.
Any secure communications scheme must provide all three properties. The level of security of a scheme is measured in how reliably these properties are provided.
Public and Private Keys
Before the "New Directions" paper and the key exchange mechanism it offered, there were many forms of cryptography, but only one "keying" mechanism -- symmetric key based encryption. Symmetric means that both parties need access to the same key. This in itself creates the fundamental problem of cryptography. Both parties NEED the SAME key for the cryptography to work.
If one has a secure channel to distribute the shared key, then why not just use that for the message?
[Image: the parable of the donkey caught between two equally attractive piles of hay.]
This is the big theoretical problem of symmetric encryption. It is "worked around" by the keys being shorter than the messages. When one see's old films of people with briefcases hand-cuffed to their wrists boarding an aeroplane, the contents of the briefcases are likely cryptographic keys, which then enable the exchange of encrypted messages; one briefcase, thousands of messages.
The Public/Private model completely destroys this problem. It is very easy to understand conceptually, though the mathematics are mathematics. So, we'll stick to the concepts.
A Public Key allows anyone to encrypt a message which can only be decrypted by persons who knows the Private Key.
That is it. The implications may not be immediately obvious.
A Public Key (hence the name) can be distributed to anyone, everyone even. This Public Key distribution leaks no secrets and does not impact the security of communication. It is only the Private Key that needs be guarded. Thus, there are no more needs for operatives with hand-cuffed briefcases. One can publish a Public Key in a newspaper or on a website, completely in the open, and describe who the intended recipient of any communication should be!
The symmetric key shackles are broken. However, one must, as a private key holder, guard that key as carefully as the conveyors of symmetric keys did theirs.
Symmetric key distribution is gone. We are in the "new direction" of Public Private Key Cryptography. Symmetric keys themselves, make an unexpected comeback.
Certificate Authorities
Certificate Authorities (CA's) are the solution to the Authenticity problem that Netscape chose: How do I know that I am speaking to the real person (or website)? Because, they have been issued with a certificate which enables the encryption by a CA who has verified that they are who they claim to be. Thus, one places trust in the CA to guarantee the authorization. One can immediately see problems emerging with this this model. What is a CA’s authorization? For which sites can it issue certificates? What if a CA’s motives differ from my own?
[Image: A minor fail or a total “crash and burn” for a Certificate Authority? The DigiNotar case.]
The process of Certificate Authorities receiving requests for a new certificate to replace one that is about to expire, and then generating and securely delivering the private key of the new certificate was involved and challenging. Thus, certificates were generally issued from 3 to 5 years to alleviate this "certificate update" annoyance. However, within this is a deeper problem. If the private key of a certificate is somehow compromised, then all communications past, present and future are vulnerable to decryption until the certificate is removed from use. Indeed, all of the “old” communications remain vulnerable to attack. This is a huge problem, as intelligence agencies like to record encrypted traffic. If you have watched the wonderful documentary, Citizen Four, it begins by showing construction of the USA’s intelligence services storage facilities outside Bluffdale, Utah.
If a private key is exposed, millions of past recorded interactions can be decrypted, and until the certificate is updated all current and future communications are immediately vulnerable to decryption.
This applies pressure to reduce the period of certificate validity to minimize the amount of past communications which may be decrypted. Given that certificate updates had been troublesome, a more frequent update would create further difficulty.
Summary
Symmetric encryption, in which all parties need to share the same keys, was usurped by Public/Private Key cryptography.
The gathering of encrypted data by whomever means that if a private key is exposed, it enabled the decryption of all past communications. This was a big problem.
The process of updating certificates for websites to enable secure communications was cumbersome, and the key exposure threat puts pressure on increasing the frequency of the cumbersome certificate update problem.
Forward Secrecy
Cryptographers solved the "decrypt old communications" problem by what became known as "Forward Secrecy". The simple trick is to not actually use directly the cryptographic details in the certificate. Once they have been used to establish a secure channel one then derives a temporary "session key" from them or other data only known to the parties in communication. These "session keys" are unique, per session, thus the name. If a certificate's private key is compromised it is possible to attack future session keys, but not those previously generated. This solves the problem of past sessions being easily able to be decrypted when a private key is compromised. This changes the calculus on certificate update times from how long a certificate is valid to how long until a key compromise is identified and addressed.
Currently the challenge of certificate update is largely solved by the ACME protocol developed by LetsEncrypt, a project initiated by the EFF. Certificates can now be shorter lived because of the ACME protocol (LetsEncrypt uses 90 days as a standard certificate lifetime). The Forward Secrecy components of session keys are still used which provides a much more robust Certificate Authority based secure communications infrastructure.
LetsEncrypt and the ACME Protocol
Current implementations for establishing secure communications with websites are now almost entirely based on the IETF's TLS 1.3 suite, which is an improvement on TLS 1.2 which standardized Forward Secrecy. Thus, your secure communications irrespective of Tor are benefiting from these cryptographic standards improvements. The combination of TLS 1.3 and the dramatic increase in the deployment of certificates facilitated by LetsEncrypt is a huge improvement to secure web browsing.
[Image: Firefox telemetry data shows the astounding change in secure web browser communications from around 25% to 80% between 2014 and 2022.]
Initiated by the EFF, LetsEncrypt quickly gained sponsorship from most of the major IT and network organisations. There are many ways to consider this. One is that the major IT and network companies were sick of the Certificate Authority cartel.
In addition to dramatically increasing the widespread use of certificates and thus encryption by many sites, LetsEncrypt also targeted the certificate update problem. Website operators needed better tools to automate the update of certificates on their sites. Take a moment to see this from the perspective of those who are wishing to see an increased use of cryptography on the Internet.
More certificate usage is needed, hence free certificates.
Getting in the way of that is the difficulty in certificate updates.
LetsEncrypt took on both problems.
The provision of free, but short term, certificates goes some way to solving the first problem. The second problem is alleviated by developing a cross platform automated certificate update mechanism called ACME. This has been developed and trialed. (I know, I was "on the ground" as a customer in the early phases of this). Finally, when the core tool was stabilized it was standardized through the IETF.
[Image: LetsEncrypt explain the ACME protocol.]
Two results emerge from this. Firstly, widespread and sustainable adoption of cryptography by most websites is enabled. Secondly, its a dramatic marketplace change for the private "Certificate Authority" companies. Those "CAs" still have a role left for them by LetsEncrypt; the issuing of "higher validity" certificates, or more technically "extended validation" certificates.
This clever move by LetsEncrypt to encrypt the Internet and keep it encrypted using standardized cryptography (TLS 1.3) and the standarized ACME certificate update protocol cements the continued use of freely available certificates. Meanwhile, LetsEncrypt allows the CA's to continue to operate in the "extended validation" marketplace. This deft market segmentation reduces the resistance to LetsEncrypt’s intervention. The “major player” sponsorships supported the market segmentation ploy.
Summary
Our dive into the background before we look at Tor is complete. You should understand:
The concepts behind Public/Private Key cryptography and why pure symmetric cryptography has been banished to remote history
Why "Forward Secrecy" was a big problem, and how it relates to certificate lifetimes and the certificate update problem
Both the increase in certificate (encryption) usage by website because of LetsEncrypt's free issue of certificates, and also why that is sustainable because of their provision of a standardized mechanism to ease the certificate update problem for webiste operators.
Now we "lift the hood" on Tor.
Building Circuits
A Tor client, be that the TBB or any other, needs circuits to use Tor. The core privacy properties which are exhibited by Tor come from the circuits via their design, construction and usage. Circuits are the key window into Tor. This summary of Tor circuit operations is based on the "Tor: The Second-Generation Onion Router" design paper helpfully provided to the author by the lead architect of Tor, Roger Dingledine.
As we get "under the hood" this article focus on computers interacting with computers. One should not forget that it is people who use and people who run the Tor network.
When one starts the TBB (Tor Browser Bundle), it automatically starts a special program on one’s computer which is called an Onion Proxy (OP). Its job is to accept communication requests from programs running on one’s computer, and only one’s computer, to enable those clients to use the Tor network. All requests are served with the use of circuits. The OP is responsible for the creation of circuits, their use to service requests and the destruction of circuits. The OP is the facilitator of the use of Tor by programs running on the local computer.
Each circuit has a unique identifier, or name, and may serve multiple requests. The OP is constantly creating new circuits, discarding ones which are "too old" (about a minute), listening for new requests and delivering data to a client from a request already sent. The full communications process involves somebody instructing a client, like the TBB to contact an endpoint, usually a website, the OP using a circuit to do that, with the last point in the circuit contacting the endpoint and receiving its response which is then sent back along the circuit to the OP and finally to the client so that the person can see the response. Henceforth, we ignore the person and the "client" application, be that TBB or whatever else. Even the endpoint only gets a brief mention.
Our focus is on the Onion Proxy and the (default) three relays involved in the circuit.
Infrastructure
Two core pieces of infrastructure enable circuit creation and usage:
The Directory Authorities
The Tor Relays (henceforth just 'relays')
[Image: The graphic shows the local Onion Proxy (OP) and its communication with the Directory Authorities, and 3 of the thousands of Tor relays with green secure communications between them. This is a simple view of the situation before any circuit creation has begun. This is the first of four images by the author to provide a graphical representation of the core element of Tor, circuit usage.]
A small collection of around 10 servers called the Directory Authorities know about all relays that are a part of Tor, and their essential properties. The Directory Authorities can be queried by any relay or OP to learn about all relays and their details.
Each relay maintains a TLS (secure) connection with every other relay. As we have seen in part 2 there are currently about 7 thousand relays, so that's about 50 million constant connections maintained amongst the relays within the Tor network. This looks scary, but it is not. Assume it takes ten thousand bytes (pieces) of memory to maintain one connection. That is about 500 million bytes or 500 MB for all of them for a single relay. This is a small amount of memory on a modern computer. Each connection will require a few milliseconds of attention to maintain it, every few seconds. Again, this is miniscule for a relay, because relaying Tor traffic is all it does. Though this is not a significant burden on a relay, remember that this web of pre-existing secure communication channels exists between all of the relays all of the time.
The observant reader will notice that there is a missing “green” connection in the above diagram, that between the first and third relay. It exists, along with all of the 50 million odd connections. It is omitted as it clutters the diagram while we focus on the OP’s use of circuits.
The infrastructure elements are the Directory Authorities with their information service about all of the relays, and the relays themselves with their pre-existing secure communication channels to every other relay.
Building a Circuit
The process of building a circuit using the default of three relays is careful and sequential. The OP regularly asks the Directory Authorities for the latest picture of the Tor network and its relays so that the OP has accurate information at hand to use for interacting with the relays.
Circuit construction begins with the first relay, the "guard" node (a relay).
The "guard" relay is preferentially reused. This is a trade off against the Sibil Attacks which were discussed in part 2. The idea is that long standing relays are less likely to be compromised, as "rogue" relays will be discovered and ejected as nodes in the network. This is a difficult compromise and there is no perfect solution. Power is delivered to the end user. You can delete your 'state' file and force Tor to generate a new random first relay, should you wish. For a discussion of the complexity of policy choices behind the use of Guard nodes, see this article from TorProject. The article references three recent, at the time of publication, academic papers on guard node policy tradeoffs. A simple observation which one can make is how seriously the Tor community take these discussions.
The OP begins the process of circuit creation by contacting the guard node. The first thing that needs to be established is the TLS encrypted transport. Recall, all of the relays already have this with each other, but the Onion Proxy is not a relay. It runs on your computer automatically whenever you start or stop TBB (or do so manually).
When the OP asks for the details of all of the relays from the Directory Authorities, for each relay the OP knows many things including a long term and a short term key for each relay. Long term may be thought of in weeks to months, and short term in hours to days. Each key is a public key for the relay. The short term "onion key" allows the OP (or anything, actually) to securely communicate with the relay. This enables the TLS encypted transport to be established between the OP and the guard. Without this nothing is possible and the OP process (via TBB usually) will inform you that it cannot connect to Tor. The process is a variant of the Diffie-Hellman key exchange with Forward Secrecy, a Diffie-Hellman ephemeral key exchange. This is the green Transport Key as we shall see in diagrams.
Next, another "Diffie-Hellman" type key exchange is begun between the OP and the guard. The purpose here is to establish a Circuit Key which is different, and unique, between the OP and the guard. This is the first of a sequence of individual keys held by the OP and each relay which is the signature of Tor; the first step on the cryptographic staircase.
A Diffie-Hellman exchange is essentially one party sending half a key to the other, with the other party forming their own "second half" and sending that back. When both parties have both parts this forms a symmetric (shared) key. One can see here the use of public/private key cryptography being used to bootstrap symmetric encryption.
The Tor version of this process also involves the non-originating party responding not only with "their half" of the key, but also a "picture" (cryptographic hash) of the complete key. The relay can do this because it has received the first half, and has itself formed the second half. The "picture" only assists the OP and each "half" key is also unhelpful because of the magic of the Diffie-Hellman exchange.
Summary
Two things have been established:
The Transport (TLS) encrypted link, noted by the "Transport Key", has been created. We shall soon lose sight of this, but don’t forget it. The OP has now joined the first (guard) Tor relay. All of the other relays already have "Transport Keys" (TLS sessions) with all of the other relays.
The Circuit Key from the OP to the guard node (1st relay) has also been securely created.
[Image: A picture of the essential keys employed when the OP uses a circuit. At this stage our OP has only established the topmost (light blue) circuit key. All of the bottom green “transport” links with their keys are established.]
Extending Circuits
Now comes the important part in which the "Onion" part of "The Onion Router" emerges, or as this author puts it, the “staircase” looms into view.
What is happening now is the circuit being extended to the second "middle" relay. This is very similar what happened when the OP established its TLS "Transport" security with the guard node, and then established their "Circuit" key.
[Image: a detailed picture of the phases of extending the circuit to include the second “middle” relay. Time moves forward as we move down the three depictions of the relationship between the OP and the two relays with which it is in communication. Each of the two halves of the key exchange between the OP and middle relay are depicted, as is the state of completion of the circuit extension to include the middle relay.]
The OP wishes to extend the circuit beyond the guard to a middle relay, which the OP has chosen, and for which it has obtained the short term (onion) key via the Directory Authorities.
The OP creates a message asking for key exchange with the new middle relay in which the OP includes its half of the key exchange. It then encrypts this information with the obtained onion key for the new middle relay. This encrypted data "blob" is then wrapped in a request to the guard relay to extend the circuit to the middle relay. This "extend" request includes the addresses of the new middle relay. This "extend" request is then encrypted with the just established circuit key for the guard relay. This package of doubly encrypted data is then sent to the guard over the TLS "transport" encrypted channel.
Really? Is all of this is involved for just adding one new part of the circuit? Yes. The reason for this seeming madness has already been partially revealed, its about limiting knowledge within the circuit building and of securing the key exchange between the OP and the new “middle” relay.
The fact that all of this already "doubly" encrypted data is then sent over an encrypted TLS link may seem puzzling. It is defensive and partially historic. When the first version of Tor was designed, there were questions about the reliability of publicly available cryptography. Some of this concerned the "export cryptography" which was deliberately weak in much the same way as the Clipper Chip contained deliberately weak cryptography. Thus, back in the academic phase of Roger Dingledine working with the Naval Research Labs there were good reasons to be concerned about the reliability of cryptography, especially in non-USA regions. These "regions" amounted to most of the intended geographic reach of the network. Things cryptographic have changed markedly since 2002 and the current TLS 1.3 suite is very well reviewed by international cryptographers. The core "Diffie-Hellman" exchanges negotiated between the OP and each relay do not actually need protection. However, if one has the ability to use reliable and universally available cryptography to do so, then it makes a 'defense in depth' sense to employ them.
The guard receives the package. The transport layer encryption is "transparently" decrypted. Then the guard decrypts the request to "extend" the circuit using the circuit key just established, and understands what to do. The guard then contacts the supplied address(es) for the middle relay given by the OP using its established TLS "transport" encryption. The guard sends the encrypted details for extending the circuit to the "middle" relay.
The new middle relay receives the information via the TLS channel (and transparently decrypts it) and then uses its short term private key to decrypt the request to extend the circuit. The middle relay sees the OP's half of the key exchange, and creates its response half. It combines this with the initial half from the OP to form the complete key. It responds with its half of the new key, and a "picture" (cryptographic hash) of the combined key. This information is sent back to the guard via the TLS connection, but is otherwise unencrypted.
The guard receives this success message for the extension of the circuit, and then encrypts that with the established "circuit" key it shares with the OP. This alreaday encrypted data is sent over the encrypted TLS channel. The OP decrypts this and verifies than the new relay's half of the key does combine with its half to produce the same "picture" (hash) as reported by the middle relay. If so, all is good, and the circuit has been extended.
Both the new "middle" relay and the OP know their "circuit level" shared key.
Summary
Before the "extension", the OP has a transport and circuit key with the guard
Every single relay in Tor has a transport key (connection) with all other relays
Using both levels of security, the transport and circuit keys, the OP has exchanged halves of a new key with the middle relay with the help of the guard relay.
The OP and the middle relay both have their circuit key and nobody else, including the guard relay, knows this key.
An observant reader will have detected an imbalance in the information exchange between the OP and the middle relay. The OP’s half of the key is encrypted with the middle relay’s onion key, though the middle relay’s reply with its half of the key (and the hash) is not encrypted. This is faintly represented in the image, with orange used in the delivery of the circuit extension hinting at the usage of the onion key from the Directoy Authorities by the OP. This imbalance always trips the author. It feels wrong. There is, however, no problem at all. The Diffie-Hellman exchange is theoretically secure, and the OP has used the middle relay’s onion key to even hide the visibility of its half of the key exchange from any observer, including the guard relay. There is an imbalance here. However, it does not threaten the key exchange, but secures it even further in one direction.
Information Compartmentalization: A Review
This is all a little complex, and its worth reviewing who knows what.
All of this keying knowledge is divided into two parts, the circuit keys and the transport (TLS) keys. The TLS links ate just for neighboring relays (and the OP) to be able to securely exchange messages. The circuit level keys are about limiting who knows what about the actions being requested of the circuit by the OP.
At this stage, the OP has a TLS link with the guard node, and two circuit keys, one for the guard, and the other for the new "middle" relay. The guard has a TLS link with both the OP and the "middle" relay (and every other relay), and knows its and only its, circuit level key. The new middle relay knows its (and only its) circuit level key and has an established TLS link with the guard (and every other relay).
Completion
The process continues to complete the next circuit extension. It follows exactly the same process, except that now even more "onion" layers of encryption are wrapped around communications heading out from the OP and returning via the two existing relays. The encryption staircase is in use with relays unwrapping encryption as we head down or outward, and those relays adding encryption as we head back of up the staircase.
Finally, a circuit is constructed. The OP knows all of the individual circuit level keys, which are individually known by each relay.
A circuit is born.
Using Circuits
The nature of the layered encryption, or the staircase, is neatly displayed when the OP requests the formed circuit to access an external resource, a web site. The exact nature of what is happening can be seen in the following diagram. First, note the outgoing request and how layered circuit level encryption is used to inform the final "exit" relay about what the OP wishes it to do. This is "walking down" the encryption staircase. Then note how the "onion" layered encryption is used in reverse to send the response back along the circuit to the OP; walking up the encryption staircase.
[Image: the two parts of the diagram highlight the use of the circuit keys by the OP and each relay. The transport links/keys are omitted. The exchange between the third “exit” relay and the website is in black as we do not know what type of encryption is offered by the site, if any at all. This concludes the author’s graphics.]
An important additional property of this design is authentication. Upon receiving the triple layered encryption the OP knows that the message was passed between the relays that form the circuit it built, and in the correct order. To return to the Certificate Authority "trusted third party" model for authentication chosen by Netscape for secure Internet traffic, we see a very different approach being taken here. The question is from the point of view of the OP. Because of the tripley circuit key encrypted response from the exit relay via the other two, the OP knows that the circuit keys were used. The OP is already very confident that these keys are only known by each individual relay and itself. A nasty exit relay could lie about the response from the website. There is no way for the OP to know about this or defeat this attack. However, the OP's job is to ensure that the circuit it chose was used properly. It can know this immediately.
Hopefully it is now clear why all of this work is being done. The TLS links serve their purpose of allowing secure, authenticated messaging between components of the circuit. The circuit level keys ensure isolation of knowledge on a "need to know" basis, and provide the OP with confidence that all is working exactly as it should.
What is the TBB doing?
All this complicated encryption to establish, use and then tear down circuits is performed by the local onion proxy (OP). TBB is using its services to communicate with some "out of Tor" web services.
A very big security issue is known as "fingerprinting". JavaScript, which runs in your browser or TBB in our "Tor" case, can ask your computer about many, many things.
What is your Operating System? How big is the window (of the browser)? What fonts do you have available? The combination of the different answers to these questions creates a unique identifier for your computer. This knowledge is recorded by the website, a summary of which is written in a long term "cookie" stored on your computer. This is the core mechanism of not just tracking you on one website, but on many, as you move around. Fingerprinting is the primary mechanism for the modern Panopticon.
TBB's job is to stop this, as best it can. TorProject follow what surveillance mechanisms are being used by the most pernicious players, like Google and Amazon or Tencent and Alibaba, and update TBB to defend against them.
The Tor network gives you the core protection. The OP allows any local process to make use of its services. Those using one of the most common, a Web Browser, are well advised to use TBB. Its protections against fingerprinting, and JavaScript in general, provide further privacy.
For Web Browsing, TBB is an essential compliment to the protections offered by the Tor network itself.
Conclusion
Running a global low-latency privacy preserving network is a complicated endeavour. The CypherPunk and "Crypto-War I" history, with the Free Software movement and the USA's Naval Research Lab's efforts to develop the network make for an engaging background to Tor, TorProject and its ethos.
The Funding Attack against Tor remains a concern, though the author cannot quantify its efficacy.
The Sibil Attack is a result of the nature of the network itself; a strength and a weakness.
Tor remains the most effective, global, Free and Open Source Software privacy protecting network. The censorship resistance raises its visibility in times of political strife, the likes of which we are now seeing in Western societies where freedom of expression is under threat.
Afterward
I thank you for staying with the article, and apologize for its length. Such is the challenge of technical articles for non-technical audiences. I hope you feel informed, and perhaps more importantly, equipped with relevant language to engage in questions which interest you.
Life is a learning experience on offer.
Sources
Tor: The Second-Generation Onion Router, Roger Dingledine, Nick Mathewson and Paul Syverson, TorProject, 2004-05-18
Improving Tor's anonymity by changing guard parameters, arma, TorProject, 2013-10-16
Culture
Paul Kelly, Missy Higgins 'From little things big things grow', Missy Higgins Archives, youtube channel, uploaded 2017-12-07
This is an amazing cultural gift.
Paul Kelly is an Australian musician and songwriter. He’s been compared to Bob Dylan. To my mind he is far more principled and powerful. The original version of this song, and another work Kelly has performed with Australian indigenous peoples were highlighted in an earlier Culture section.
The story of Vincent Lingiari and the act by Australian Prime Minister Whitlam is the beginning of the deconstruction of the Terra Nullis legal doctrine based upon which the colonialists committed genocide and stole the livelihood of native populations; their land. Whitlam’s famous speech on the steps of the old Australian Parliament building following his dismissal by the British Monarchy is also featured in an earlier article (not the Culture section, the top of the article). The removal of Whitlam is the singular occasion on which a regal coup occurred in Australia since her formation in 1901.
If you have listened to the original version of the song, you’ll be able to hear a signature change that Missy Higgins adds to the chorus. She embellishes the song and steals the show.
Kev Carmody wrote the song with Kelly and has his role too. It took them months to write the song, to verify reports coming from indigenous groups and correlating that with independent reporting. The song, the performance and the history are a celebration of collaboration .
Kev signs off the song with “Our spirit walks with you.” A pause of applause begins. Then, as also highlighted in an earlier Culture section, the rhythm section storms back to carry the event to close. Before we return to that, we must acknowledge the camera operators (there must have been at least 10), the sound engineering staff, and the video editors who assembled the publication. At least one hundred people are involved in the creation, execution, recording, editing and gifting of this piece of culture. One should note the work done by ABC reporters included at the beginning, and later, in the video production. Video and sound production is by SBS, Australia’s multilingual government broadcaster. Collaboration is rife.
Let’s not be blind. One could not create this without the audience. Thus, we need the venue and their staff, the ticket sellers and advertisers, and the public transport workers who moved the audience to and from the venue. Tens of thousands of people were involved.
At 6 minutes 22 seconds, as Higgins creshendoes through the last verse into the final chorus, watch Kelly’s left leg as he enthusiastically pounds the ground.
The rhythm section’s drummer re-starts; the time keeper in action. Earlier we receive a glimpse of the base player. Following the bows to the audience by the array of front line performers they turn to acknowledge the rhythym section. The final shot is of the violinist who closes the song with the dummer. One then realizes that the core have been “carrying” the entire 9 minutes.
From little things, in deed.
If you like what you read here, you can please the author by sharing it.
Do Not Subscribe: This blog does not issue "notifications" via Substack. Use RSS. The URL is the obvious: https://yesxorno.substack.com/feed .
Following @YesXorNo1 on Twitter is the next best alert mechanism.
Copyright and Licensing
This work is copyright to the blog's author with CC BY-SA 4.0 licensing. Have fun, reuse, remix etc. but give credit and place no further restrictions. Lets build culture.