On July 22, we released the latest version of the Tor Browser Bundle for Windows. It contains updates to Firefox and Pidgin to address security issues.

The bundles can be found at https://www.torproject.org/torbrowser/

The full changelog is:

version 1.3.8: Released 2010-07-22
update Firefox to 3.5.11

version 1.3.9: Released 2010-07-22
update Pidgin to 2.7.2

Tor 0.2.2.14-alpha greatly improves client-side handling of circuit build
timeouts, which are used to estimate speed and improve performance. We
also move to a much better GeoIP database, port Tor to Windows CE,
introduce new compile flags that improve code security, add an eighth
v3 directory authority, and address a lot of more minor issues.

https://www.torproject.org/download

Packages will be appearing over the next few days or weeks. (We've decided
to start announcing alpha versions when they're released, rather than
waiting for all the packages first.)

Changes in version 0.2.2.14-alpha - 2010-07-12
o Major bugfixes:
- Tor directory authorities no longer crash when started with a
cached-microdesc-consensus file in their data directory. Bugfix
on 0.2.2.6-alpha; fixes bug 1532.
- Treat an unset $HOME like an empty $HOME rather than triggering an
assert. Bugfix on 0.0.8pre1; fixes bug 1522.
- Ignore negative and large circuit build timeout values that can
happen during a suspend or hibernate. These values caused various
asserts to fire. Bugfix on 0.2.2.2-alpha; fixes bug 1245.
- Alter calculation of Pareto distribution parameter 'Xm' for
Circuit Build Timeout learning to use the weighted average of the
top N=3 modes (because we have three entry guards). Considering
multiple modes should improve the timeout calculation in some cases,
and prevent extremely high timeout values. Bugfix on 0.2.2.2-alpha;
fixes bug 1335.
- Alter calculation of Pareto distribution parameter 'Alpha' to use a
right censored distribution model. This approach improves over the
synthetic timeout generation approach that was producing insanely
high timeout values. Now we calculate build timeouts using truncated
times. Bugfix on 0.2.2.2-alpha; fixes bugs 1245 and 1335.
- Do not close circuits that are under construction when they reach
the circuit build timeout. Instead, leave them building (but do not
use them) for up until the time corresponding to the 95th percentile
on the Pareto CDF or 60 seconds, whichever is greater. This is done
to provide better data for the new Pareto model. This percentile
can be controlled by the consensus.

o Major features:
- Move to the June 2010 Maxmind GeoLite country db (rather than the
June 2009 ip-to-country GeoIP db) for our statistics that count
how many users relays are seeing from each country. Now we have
more accurate data for many African countries.
- Port Tor to build and run correctly on Windows CE systems, using
the wcecompat library. Contributed by Valerio Lupi.
- New "--enable-gcc-hardening" ./configure flag (off by default)
to turn on gcc compile time hardening options. It ensures
that signed ints have defined behavior (-fwrapv), enables
-D_FORTIFY_SOURCE=2 (requiring -O2), adds stack smashing protection
with canaries (-fstack-protector-all), turns on ASLR protection if
supported by the kernel (-fPIE, -pie), and adds additional security
related warnings. Verified to work on Mac OS X and Debian Lenny.
- New "--enable-linker-hardening" ./configure flag (off by default)
to turn on ELF specific hardening features (relro, now). This does
not work with Mac OS X or any other non-ELF binary format.

o New directory authorities:
- Set up maatuska (run by Linus Nordberg) as the eighth v3 directory
authority.

o Minor features:
- New config option "WarnUnsafeSocks 0" disables the warning that
occurs whenever Tor receives only an IP address instead of a
hostname. Setups that do DNS locally over Tor are fine, and we
shouldn't spam the logs in that case.
- Convert the HACKING file to asciidoc, and add a few new sections
to it, explaining how we use Git, how we make changelogs, and
what should go in a patch.
- Add a TIMEOUT_RATE keyword to the BUILDTIMEOUT_SET control port
event, to give information on the current rate of circuit timeouts
over our stored history.
- Add ability to disable circuit build time learning via consensus
parameter and via a LearnCircuitBuildTimeout config option. Also
automatically disable circuit build time calculation if we are
either a AuthoritativeDirectory, or if we fail to write our state
file. Fixes bug 1296.
- More gracefully handle corrupt state files, removing asserts
in favor of saving a backup and resetting state.
- Rename the "log.h" header to "torlog.h" so as to conflict with fewer
system headers.

o Minor bugfixes:
- Build correctly on OSX with zlib 1.2.4 and higher with all warnings
enabled.
- When a2x fails, mention that the user could disable manpages instead
of trying to fix their asciidoc installation.
- Where available, use Libevent 2.0's periodic timers so that our
once-per-second cleanup code gets called even more closely to
once per second than it would otherwise. Fixes bug 943.
- If you run a bridge that listens on multiple IP addresses, and
some user configures a bridge address that uses a different IP
address than your bridge writes in its router descriptor, and the
user doesn't specify an identity key, their Tor would discard the
descriptor because "it isn't one of our configured bridges", and
fail to bootstrap. Now believe the descriptor and bootstrap anyway.
Bugfix on 0.2.0.3-alpha.
- If OpenSSL fails to make a duplicate of a private or public key, log
an error message and try to exit cleanly. May help with debugging
if bug 1209 ever remanifests.
- Save a couple bytes in memory allocation every time we escape
certain characters in a string. Patch from Florian Zumbiehl.
- Make it explicit that we don't cannibalize one-hop circuits. This
happens in the wild, but doesn't turn out to be a problem because
we fortunately don't use those circuits. Many thanks to outofwords
for the initial analysis and to swissknife who confirmed that
two-hop circuits are actually created.
- Make directory mirrors report non-zero dirreq-v[23]-shares again.
Fixes bug 1564; bugfix on 0.2.2.9-alpha.
- Eliminate a case where a circuit build time warning was displayed
after network connectivity resumed. Bugfix on 0.2.2.2-alpha.

New releases

• On June 1, we released the latest Tor Browser Bundle for Linux, version 1.0.7. This is a compatibility release to allow the bundle to work on a wider variety of Linux distributions.
• On June 2, updated the Vidalia bundle for OS X PowerPC to include Vidalia 0.2.9.
• On June 14, we released orbot 0.0.8. This is a maintenance release to fix issues discovered with Android 2.2.
• On June 17, Tor and the EFF released a Firefox extension called HTTPS Everywhere. The goal is to enable encrypted website viewing by default. More about this release at https://blog.torproject.org/blog/https-everywhere-firefox-addon-helps-yo....
• Damian continues to improve and release new versions of ARM, the console-based anonymizing relay monitor, http://www.atagar.com/arm/. Consider it to be like the graphical control application, Vidalia, for relays without a graphical environment.

Design, develop, and implement enhancements that make Tor a better tool for users in censored countries.

• We updated the geoip mapping database to the Maxmind GeoLite Country database in tor after an analysis of various geoip mapping databases. The Maxmind GeoLite Country database has more accurate mappings for many parts of the world, such as Iran, SouthEast Asia, and many African countries.
• China’s Great Firewall continues blocking connections to the public Tor relays. They also updated their blocking to include bridge relays published via email and https websites. We conducted further research into the blocking mechanisms from inside China. A detailed analysis shows China GFW is blocking 90% of the published bridges in the https and smtp pools. The blocking is simply IP Address and TCP port combinations. Bridge relays that have been seeded into various social networks in China as well as new bridge addresses continue to work well.
• In late June, we started receiving many reports that Nigerian internet providers are blocking many circumvention tools, Tor included. Data about the blocking methods implemented are sparse right now, but we’re continuing to work with a few smart Nigerians to reverse-engineer the blocking regime. More details about this block at https://blog.torproject.org/blog/dear-nigerians-help-us-help-you.

Measures of the Tor Network
https://blog.torproject.org/files/exit-2010-06.png
This graph shows the total quantity of relays and quantity of exit relays in june 2010. Exit relay capacity is one of the potential bottlenecks that affects the overall performance of Tor. The more exit relays we have, the faster it seems to browse the open Internet. As seen in late June, a researcher using PlanetLab hooked up 512 relays to the Tor network for their research into cloud computing and scaling effects on the Tor Network. Before contacting PlanetLab, we removed all 512 nodes from the network consensus so users couldn’t use the suspect relays. We contacted the researcher and the relays were subsequently disabled.

https://blog.torproject.org/files/networksize-2010-06.png
This graph shows the total quantity of relays and the total quantity of bridges in June 2010. The quantity of bridges is stable throughout the month. As seen in late June, a researcher using PlanetLab hooked up 512 relays to the Tor network for their research into cloud computing and scaling effects on the Tor Network. Before contacting PlanetLab, we removed all 512 nodes from the network consensus so users couldn’t use the suspect relays. We contacted the researcher and the relays were subsequently disabled.

https://blog.torproject.org/files/torperf-50kb-torperf-6m.png
This graphs shows how many seconds it took to complete a 50KB download from a standard Tor client. This measurement is from the server torperf, located in Chicago, Illinois. As you can see, latency dropped dramatically over the month for the second month in a row. We believe this is due to the fixes for relays in 0.2.1.26 allow relays to handle older clients flooding circuit requests to relays. As some relays were overloaded and dropped out of the network, the remaining relays had to handle an increasing load of users. Also, we have a budding competition between individuals looking to run the highest bandwidth relays. TorServersdotNet, http://www.torservers.net/, starting running some very high bandwidth relays to increase performance and provide a way for non-technical users to support tor through combined financial donations in exchange for Tor servers. We’re also looking to run this measurement software on a linux client connected to a standard dial-up modem to see how Tor fares in extremely low-bandwidth environments.

Outreach and Advocacy

• Andrew met with the Wesleyan University Humantarian Free and Open Source Software (HFOSS) team working on Tor for their summer project. They are fixing up the Tor Weather application to allow for more features as requested by relay operators and attempting a start a Tor Status re-write, design, and update. http://hfoss.wesleyan.edu/.
• Jacob attended FooCamp 2010.
• Mike, along with Peter Eckersley from EFF, met with the Mozilla team to talk about web fingerprinting, privacy, and Torbutton. Mike’s summary of their discussion is at https://blog.torproject.org/blog/firefox-private-browsing-mode-torbutton....
• Sebastian and Linus gave a Tor talk to the Netherlands Privacy group, PvIB (https://www.pvib.nl/home). Their presentation is at https://svn.torproject.org/svn/projects/presentations/pvib-2.pdf.
• Runa gave a Tor talk to Electronic Frontier Norway, http://www.efn.no/.
• We added an eigth directory authority called “maatuska“ hosted in Sweden.

Preconfigured privacy (circumvention) bundles for USB or LiveCD.
Erinn continues to work on a Tor Browser Bundle for Apple’s OS X. Erinn continues to improve Tor Browser Bundle for Linux with feedback from initial users and other volunteer developers.

Bridge relay and bridge authority work.
Andrew published a template configuration file for tor relays to be a bridge automatically. It seems some relay operators are confused as to configuring their relay as a bridge. The configuration template is at https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/src/config/torrc.... and will be included in future Tor releases.

Andrew created some experimental “bridge by default“ bundles for Microsoft Windows. The idea is to use existing technology and see if we can get users to be bridges by default without any additional configuration. Intitial testing shows it works well if the upstream router or NAT device has Universal Plug and Play (UPNP) enabled. The largest obstacle is still the manual configuration of firewalls, routers, and NAT devices if UPNP is not enabled by default. More details about this experiment are at https://blog.torproject.org/blog/technology-preview-bridge-default-micro....

Scalability, load balancing, directory overhead, efficiency.
Mike spent a lot of effort and research into optimizing the circuit based timing (CBT) codebase. CBT is how clients measure the performance of their tor circuits to better optimize performance.
The changelog of the fixes is:
• Major bugfixes:
– Ignore negative and large timeout values that can happen during a suspend or hibernate. These values caused various asserts to fire in the circuit build times code, crashing Tor. Bug 1245, bugfix on 0.2.2.2-alpha.
– Alter calculation of Pareto distribution parameter ’Xm’ for Circuit Build Timeout learning to use the weighted average of the top N=3 modes. This should improve the timeout calculation in some cases, and prevent extremely high timeout values. Bug 1335, bugfix on 0.2.2.2-alpha.
– Implement a filtering step to recompute synthetic build times every time the timeoutchanges. Additionally, place a lower cap on synthetic build times, and allow this cap tobe controlled by the consensus. This should also improve the build time calculations,and should eliminate a case where Tor was allocating an excessive amount of temporary memory during timeout calculation. Bugs 1335 and 1245, bugfix on 0.2.2.2-alpha.

• Minor bugfixes:
– Eliminate a case where a circuit build time warning was displayed after network connectivity resumed.

• Minor features:
– Add a TIMEOUT_RATE keyword to the BUILDTIMEOUT_SET control port event, to give information on the current rate of circuit timeouts over our stored history.
– Add ability to disable circuit build time learning via consensus parameter and via a
LearnCircuitBuildTimeout config option. Also automatically disable circuit build time
calculation if we are either a AuthoritativeDirectory, or if we fail to write our state file.
Bug 1296.

Karsten web-enabled his ExoneraTor tool on the metrics website at http://metrics.
torproject.org/exonerator.html. ExoneraTor tells you whether there was a Tor relay running on a given IP address at a given time. Many legal advisors, lawyers, and law enforcement ask us for data regarding if a certain IP address hosted a Tor relay at a point in time. Now this data is easily available to all.

Karsten fixed stats on estimated user numbers after we broke the calculations of users from directory request sampling at select relays. We found that we can use entry-stats for better user number estimates.

Karsten compared descriptor tarballs collected by ernie with directory-archive script and found that we’re fine using ernie’s data. Ernie is the code that provides the data processing and backend for the metrics.torproject.org website.

Footprints from Tor Browser Bundle.

Erinn continues work on footprints of the Tor Browser Bundle for Linux and Apple OS X.

Translation work, ultimately a browser-based approach.

• A new translator, pierre, translated the entire website, torbutton, and gettor email autoresponder into French.
• Added pashto (Pakistani) to the portal by request.
• Updated translations for the website, torbutton, orbot, tor, and tor manual pages for French, Spanish, Russian, Mandarin Chinese, Farsi, Italian, Arabic, Dutch, Serbian, Portugese, Danish, Japanese, Polish, and Turkish.

On July 4th, we released Tor Browser Bundle 1.3.7 for Microsoft Windows. This is merely a security update release for Firefox and Pidgin. You can download this at https://torproject.org/torbrowser.

The only changes are:

• update to Firefox 3.5.10 to fix some security issues
• update to Pidgin 2.7.1r2 to fix some security issues

Updated 06/30/2010: Mention Reduced Exit Policy, ISP Shopping Tips, and Abuse Response Templates

I have noticed that a lot of new exit nodes have recently appeared on the network. This is great news, since exit nodes are typically on the scarce side. Exits usually occupy 30-33% of network by capacity, but are currently at a whopping 38.5% (156 MBytes/sec out of 404 total).

However, I want to make sure that these nodes stay up and don't end up being shut down due to easily preventable abuse complaints. I've run a number of exit nodes on a few different ISPs and not only have I lived to tell about it, I've have not had one shut down yet. Moreover, I've only received about 4 abuse complaints in as many years of running exit nodes. This is in stark contrast to other node operators following a more reactive strategy. I'm convinced this is largely because I observe the following pro-active guidelines.

1. Inform your ISP
This is the most important rule for running a long-lived exit node, especially if you have your choice of ISP. Pick an ISP you can trust, and let them know exactly what is going on. A good first email is to ask them if they have an AUP you can read if you can't find one online. You should also ask them if they can provide the services mentioned below in this document, such as additional IP addresses, SWIP, and reverse DNS, and if these services might cost extra.

In a follow up email, you should explain Tor to them, and why it is important to the Internet, the world, and to you, their potential customer. Giving them links to our Tor Users, Tor Overview, Tor Legal FAQ and Tor Abuse FAQ is typically immensely helpful. Mentioning China and the current conflict in Iran are also likely to be helpful. If your ISP is your University, you may also want to peruse this set of recommendations specific to dealing with University administrators.

If your ISP does not approve, all is not lost: you can look into running a middle node, or a much less visible bridge node. It is better to learn this up front, rather than have your Internet connection shut down on you without warning. Exit bandwidth is often scarce, but any node is better than no node.

2. Get a separate IP for the node. Do not route your own traffic via this IP
While it may be tempting to mix in your traffic with your node's exit traffic for cover, this is best avoided. Having a separate IP allows your ISP to more easily recognize that abuse complaints and DMCA notices can be forwarded to you to be quickly responded to with a boilerplate response, as opposed to cutting off your Internet access or providing your personal information to the copyright cartels.

3. Get recognizable Reverse DNS for this IP
Setting a good reverse DNS name for your exit IP helps to prevent knee-jerk reactions from sysadmins and DoS kiddies alike who run into bad apples coming from your node IP. Something like tor-exit.yourdomain.org or tor-proxy-readme.yourdomain.org is the best bet.

4. Set up a Tor Exit Notice
Once you have a good reverse DNS name, you should put some content there that explains what Tor is for those who see the name and try to visit it via http. If you run your DirPort on port 80 with Tor 0.2.1.x or newer, you can use the Tor config option "DirPortFrontPage" to display a notice explaining that you are running an exit node. A sample one is provided in contrib/tor-exit-notice.html in the source distribution. This way, when someone sees tor-proxy-readme.yourdomain.org in their logs, they hopefully will get the hint and read the notice before flaming you. Be sure to update the contact info and other places marked with FIXME in the notice.

5. Get ARIN registration (if possible)
If you can get your ISP to SWIP your IP block to display a contact and abuse email that you control, this can go a long way to reducing aggravation that they may feel from dealing with the occasional abuse complaint, because the vast majority of the few complaints that are still made will go to you instead of them.

6. Consider a Reduced Exit Policy
If you cannot get SWIP set up for your IP block, you should definitely consider a reduced exit policy. Excessive bittorrent abuse over Tor unfortunately means you will likely receive a deluge of DMCA abuse complaints. We (including the very smart lawyers at the EFF) believe Tor nodes qualify as transmission providers under DMCA 512(a), not 512(c). This makes them exempt from "notice and takedown" procedures, including the need to issue "putback" responses. The EFF has even prepared a template response for improper DMCA 512(c) takedown notices that you can use.

However, your ISP may see things differently. If the abuse complaints are arriving in their staff's inbox, they may just want them to stop coming so they do not have to spend resources dealing with them, regardless of their merit. If they still won't provide SWIP registration, you can try a reduced exit policy. Other operators have had great success with allowing 20-22, 53, 79-81, 110, 143, 443, 465, 563, 587, 706, 873, 993, 995, 1863, 5190, 5050, 5222, 5223, 8008, 8080, 8888, and rejecting everything else. In fact, the operator of 4 of our fastest exit nodes has reported that after switching to this policy from the default, the bittorrent DMCA complaints ceased immediately.

With that list, the only abuse complaints you should see will come from occasional comment spam (ports 80 and 443), email spam to misconfigured email servers (port 465 and 587 are supposed to be for authenticated SMTP only), and misconfigured NNTP servers (port 563 is authenticated NNTPS). You may want to review Moritz Bartl's abuse complaint template set, as well as the Tor Abuse Template set, and the Tor Abuse FAQ for information on how to handle these rare cases, when they do come up.

7. Rate limit and optionally QoS your node
I've recently conducted some measurements that showed that nodes that used Tor's BandwidthRate config option to set a limit slightly below their actual capacity were much more reliable than those that did not. Along these lines, it may also be useful to use this Linux-based QoS script to prioritize your Tor IP traffic below other traffic on your machine. Similar QoS can also be achieved via DDWRT, openwrt and of course via commercial routers. If you use do QoS other than that script, you should ensure that you provide Tor with a reasonable minimum bandwidth so that it does not starve when you do other things. Somewhere between 33 and 50% of your connection is a reasonable minimum value.

That's it! Happy operating!

Last week, Peter Eckersley and I met with the Mozilla team in Mountain view to discuss web fingerprinting, privacy and Torbutton. I gave an updated version of my Torbutton Design talk, and Peter discussed Panopticlick. Mozilla was primarily interested in hearing about these projects in the context of their Private Browsing Mode, which they unveiled in Firefox 3.5.

The primary goal of their Private Browsing Mode is to protect against a local after-the-fact attacker - an attacker that has local access to a user's filesystem after browsing has taken place. They offer some limited protections against a network adversary, but this was not their initial goal, and is primarily a side effect of trying to protect against "helpful" web services, such as Google Search History, which record your activity somewhere other than your PC.

This is a significantly weaker adversary model than the one used in the Torbutton design. As a result, from the point of view of Tor usage, Firefox Private Browsing mode suffers from a number of weaknesses that Torbutton does not.

In particular, Firefox does not presently concern itself with plugins, form and password autocompletion, SSL state, Live Bookmarks, external protocols and applications, or browser fingerprinting. The Applied Crypto research group at Stanford recently published a comparison of the four major browser's private browsing modes against a dedicated local and remote adversary which details some of these issues.

It turns out there is some developer interest inside Mozilla in improving resistance to fingerprinting, improving privacy against third party content, and hardening their Private Browsing Mode in general, despite most of these issues being outside of their original model. The current plan is to investigate what would be necessary to develop an Anonymous Browsing Mode that would either take the form of a privacy setting, an enhancement to Private Browsing Mode, or an entirely independent browsing mode. The trick now is to transform this developer interest into something that motivates the Firefox Product Management team to get fully behind the proposed improvements.

As such, Peter and I have been spending some time updating the Fingerprinting and Anonymous Browsing wiki pages to describe who would want such privacy features, and how they would behave, as well as updating and adding relevant Mozilla Bugzilla entries. I've also updated the list of Torbutton Firefox Bugs to reflect some of the more sophisticated unsolved fingerprinting issues that were brought up during our meeting.

This July, the two of us will be doing the same thing with the Google Chrome Privacy Team in Berlin while at the Privacy Enhancing Technologies Symposium. This is primarily to follow up on a meeting we had with Google in December, where we discussed the barriers to the development of a Torbutton for Google Chrome, and to discuss relevant fingerprinting issues and similar shortcomings of the Google Chrome Incognito Mode.

Look for a future blog post in August detailing the results of that discussion.

You've flooded the blog and tor-assistants with lots of cries for help about Tor, Freegate, Ultrasurf, and a slew of VPNs all being blocked. Sometimes this is through MTN Nigera, sometimes not.

http://www.herdict.org/web/explore/country/NG suggests access is a 50/50 chance for some sites.

https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Iins.... That FAQ entry is a fine place to start. Telling us Tor doesn't work lets us know there is a problem. Sending in logs from Message Log would be a great start. We need to know what Tor records while trying to connect to the Tor Network.

Someone could further startup Wireshark and record the entire session of Tor starting up and ultimately failing to connect to the Tor Network.

There are lots of ways ISPs in Nigeria can block Tor and your favorite websites. DNS filtering, IP blacklisting, proxy server keyword filtering, govt mandated blackbox firewalls/proxy servers, or just simply blocking the published tor relays list. The worst case is Nigeria white lists the Internet, allowing you to only visit approved sites (and probably man-in-the-middled as well).

All we know right now is that some ISPs in Nigeria seem to be blocking many websites, tools, and Tor. More data is needed to figure out some solutions.

Updates 2010-07-01: Two people have given us some data from MTN and Etisalat ISPs. It seems these two ISPs have implemented some general "circumvention tool" blocking.

Today the EFF and the Tor Project are launching a public beta of a new Firefox extension called HTTPS Everywhere.

This Firefox extension was inspired by the launch of Google's encrypted search option. We wanted a way to ensure that every search our browsers sent was encrypted, including the search box and URL bar features. At the same time, we were also able to encrypt most or all of the browser's communications with other popular sites that support SSL, but don't provide it by default.

Our approach is based on the NoScript STS implementation, but is more expressive in the manner in which HTTPS-enforcing rules are written.

This tends to work more effectively than NoScript because many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may not offer all pages and applications via HTTPS, or may only allow HTTPS activity via alternate subdomains that require URL rewriting and redirection. In particular, Google's SSL search and Wikipedia both require rather complex URL rewriting and exception filters to work properly.

HTTPS Everywhere should also perform more securely than DOM-based mechanisms such as the GreaseMoney-based SSL Certificates Pro and the Google Chrome-based KB Enforcer. These addons perform redirection at the DOM level, which causes many HTTP fetches to leak prior to the redirect to HTTPS.

We currently provide rule sets for Google Search, Wikipedia, Twitter, Facebook, The New York Times, The Washington Post, IxQuick, and many more popular sites. It is also possible to add user-defined rule files, and/or to submit rules to us for inclusion in future versions.

Note that some of these sites still include a lot of content from third party domains that are not available over HTTPS. As always, if the browser's lock icon is broken or carries an exclamation mark, you may remain vulnerable to adversaries that use active attacks or traffic analysis to compromise your privacy and security.