Showing posts with label firefox. Show all posts
Showing posts with label firefox. Show all posts

Saturday, March 21, 2009

The benefits of using opt-outs

This blog post provides a legal/policy argument in support of opt-out cookies. While the author knows a decent amount about Internet law, he is not a lawyer, and this is not legal advice.

While the response to my Targeted Advertising Cookie Opt-Out (TACO) Firefox add-on has been hugely positive, a number of users have questioned the utility of this tool, as compared to other pro-privacy and anti-advertising solutions.

As just one example of this line of mild criticism, Jim Harper over at the Tech Liberation Front, suggests that users can simply make use of the "block third party cookies" feature available in most Web browsers.

This is an approach that is similarly recommended by Google, which only provided an opt-out software extension to users of Internet Explorer and Firefox. Users of other browsers (such as Safari and Chrome) are advised to just block all advertising cookies.

The problem with blocking any form of unwanted behavior, is that it just leads to an arms race.

Arms races, and the lessons from the pop-up war

Consider, for example, the scourge that was pop-up advertisements. These were a huge problem on the web, and continue to be so for anyone unlucky enough to be using an ancient browser. Their over-use by Web sites can make browsing an unpleasant, and at times, unusable experience.

So how did we do away with them? First, a number of browser add-ons began to offer pop-up blocking functionality. However, these were only used by technically savvy users. It wasn't until similar functionality was included in Firefox and Safari, often by default, that the tables really turned.

Once anti pop-up technology came baked into the browser, the advertising industry effectively lost one of its most powerful tools.

These firms had a strong incentive to find a way around this blocking, and so, over the past few years, new, sneakier forms of advertising, some even using pop-up style effects, have become commonplace.

Advertisers didn't observe the blocking of their previous techniques, and think, 'Oh, I guess we should respect people's preference to not see annoying ads", but instead took it as an invitation to innovate, and create newer, more aggressive and unblockable forms of advertising.

That is, pop-up blocking technology, while providing users with some temporary relief, merely added fuel to the arms race.

Targeted advertisements use more than cookies

Over the past ten years, cookies have gotten a lot of criticism from privacy circles. Browsers have evolved to include sophisticated cookie handling tools, particularly in Safari and IE8. As a result, cookies have become far less useful as a way to track users. After all, every Safari user automatically rejects third party cookies by default.

Just as with the pop-up example mentioned above, this use of blocking technologies has merely encouraged an arms race, with advertisers turning to other methods for long term tracking. Technologies like Adobe's Flash, AIR, Microsoft's Silverlight, and the offline content in HTML5 can all be used to provide cookie-like tracking functionality.

Better yet for the advertisers, most users don't know that these technologies can be used to invade their privacy.

Ending the arms race

Should we follow the traditional approach, and just escalate the arms race? For example, the excellent BetterPrivacy Firefox add-on allows users to protect themselves against the tracking Flash cookies/LSO files used by YouTube, eBay and many other sites.

In my opinion, this cat and mouse game is a huge waste of energy. What we need is a way to remove ourselves from this cycle, and I think that opt-out cookies are a way to do this.

Unlike all of the previous anti-advertising technologies, the opt-out mechanism provides users with a way to positively affirm that they do not wish to be tracked and targeted. This opt-out cookie is something that advertisers cannot ignore.

Now, consider the following hypothetical situation: In a year or two Google/Doubleclick sees that 50% of Web users have opted out of their targeted advertising. In an attempt to innovate around this, the company switches to the use of Flash-based cookies to target and track users.

While the company's privacy policy specifically talks about the use of cookies, it would be tough to see how Google could argue that it had the right to use alternative tracking technologies to track users who had opted out of its older cookie-based system.

The Federal Trade Commission and Congress would likely take an interest, and any attempt by Google's lawyers to argue that opt-outs only applied to html cookies, even if their privacy policy stated as much, would draw laughter and ridicule.

Simply put, opt-out cookies are a game changer. Once consumers affirmatively state their desire to not be tracked, companies can not continue the cycle of innovating around blocking technologies. For the advertisers, the game is over.

Best practices, defense in depth

The funny thing is, you don't need to actually accept third party cookies to get the benefits of opt-out cookies.

On my own computer, I disable all third party cookies, I've set the browser to clear all cookies upon starting, I use the awesome AdBlock Plus and NoScript. However, I still use my own opt-out cookie add-on.

With the other technologies and policies that I've set, no advertising network can use the existing cookie based technologies in order to track and target me. Some might say that the opt-out cookies provide no added value.

However, I see them as a form of defense-in-depth. If these advertising firms find a way around AdBlock Plus, and innovate around the third party cookie block, my positive declaration of my desire to not be targeted might provide me with some more protection.

At the very least, if the advertisers are ever caught tracking opt-ed out users via some other technology, my own use of opt-outs will give me a far better position, should I wish to take legal action.

So -- what are you waiting for? Download the Targeted Advertising Cookie Opt-Out (TACO) add-on today.

Friday, March 13, 2009

Freedom from evil cookies

Executive Summary: I've modified Google's new Advertising Cookie Opt Out Firefox Plugin to allow users to opt-out of the tracking by 16 other advertising companies. The software is super alpha right now (the result of a few hours hacking this afternoon), and will hopefully be available on addons.mozilla.org in the next few days. If you're not a developer, please don't download it yet. If you are, you can find it here

A large number of commercial companies now track users' browsing across the web, in order to profile them, and then serve them targeted advertising. This so called behavioral advertising is a threat to the average user's privacy.

An industry group, The Network Advertising Initiative, provides an easy way for users to opt-out of the tracking performed by its member companies. Users can visit a single web page, and then easily set opt-out web cookies for all of the NAI members advertising networks.

The problem with this is that the moment a user clears his or her cookies, they also lose the opt-out cookies. Regularly clearing browser cookies, or better, setting the browser to erase them all at the end of a session, is a recommended practice. Unfortunately, by doing this, users are then required to re-visit the NAI opt-out page each time they start browsing the web. This is obviously not a reasonable thing to expect.

Google recently announced that it would be engaging in the large scale collection and use of targeted advertising information. However, in addition to offering an opt-out cookie, the company has also developed a Firefox add-on, so that users can maintain the opt-out cookies, even if they regularly erase the other cookies.

Google should be commended for releasing such a useful privacy enhancing technology (even though their use of targeted advertising is creepy, and should be prohibited by the FTC). If only this add-on could be used to protect people from the prying eyes of the other advertising networks.

Since Google released the Firefox-addon as an open-source project (under the Apache 2.0 license), I have forked the code, and added in the opt-out cookies of 16 other advertising networks.

By installing this add-on, you will receive long-term opt-out cookies for the following NAI member advertising networks:



  • Google / Doubleclick

  • Collective Media

  • Acerno

  • Turn

  • Next Action

  • Audience Science


  • BlueLithium

  • Advertising.com

  • [x+1]

  • Fox Audience Network

  • AlmondNet

  • Safecount

  • Tacoda Audience Networks

  • Traffic Marketplace

  • Tribal Fusion


  • Undertone Networks




The Bad News

All of the above companies use a cookie similar to "OPT_OUT=1". Unfortunately, some other NAI member companies force a unique tracking ID upon users in the process of opting out of the targeted ad tracking. That is, in addition to an "OPT_OUT=1", they'll also force a "USER=12345678" cookie, which could enable them to uniquely track visitors to their site.

For example, when trying to opt out of Yahoo's tracking, I was given the cookie
B=c97l3894rlqpf&b=3&s=cf.


Similarly, Akamai gave me this cookie
AOOC=368398094.


Simply put, we shouldn't have to trust these companies to not track us. Users should not be given unique IDs in order to opt-out.

The following companies force unique IDs upon users wishing to opt-out. This add-on does not currently provide opt-out functionality for these networks, since I don't want to encourage their sketchy ways. Hopefully, being listed here might shame them into providing a more pro-privacy way of opting out.

These companies are:



  • Akamai

  • Atlas

  • Blue Kai

  • BlueLithium

  • FetchBack

  • Interclick

  • MindSet Media

  • Media 6 Degrees

  • 24/7 Real Media


  • Specific Media

  • Yahoo



Disclaimer: This code is based on the Advertising Cookie Opt Out Plugin by Valentin Gheorghita, a Google Engineer. It was not sanctioned by Google, the Network Advertising Initiative. While the folks at the Berkman Center (who pay me) are huge supporters of privacy, I have done this in my personal capacity, and this is not an official blessed Berkman project.

Thursday, June 28, 2007

Facebook Cares More About Privacy Than Security

Kudos to Facebook. It looks like they fixed the privacy flaw within hours of Ryan Singel's Wired News story hitting the presses. By the time I woke up this morning, Brandee Barker, Facebook's Director of Corporate Communications had left a comment in my previous blog post to let me know that Facebook's engineers had "updated the advanced search function so that profile information that has been made private by a user, such as gender, religion, and sexual orientation, will not return a result."

Facebook's head privacy engineer, Nico Vera, seems to reside in some sort of Cheney-ish undisclosed location: He's not listed in the corporate phone directory, has instructed Facebook's receptionist to not accept outside calls, and did not reply to my intra-Facebook email.

Luckily - Facebook's PR people are a bit more responsive. It's amazing what a few calls from journalists, and a Boing Boing blog post can do to motivate a company to act quickly.

I tried a few sample searches, and can confirm that Facebook has indeed fixed the bug. My days of searching for private profiles of Facebook users under the age of 21 who list beer or marijuana as one of their interests is over. It's a shame too, as it made for a great "be careful with your information online" example when I lecture undergrads.




While Facebook offers a fantastic level of privacy controls for users, in this case, they clearly erred. Many users had gone to the effort to make their profiles private - and as such, Facebook should have assumed that they would also not wish for their profile information to be data mined through a number of iterative searches. Opt-out privacy is not the way to go - especially for users who have already communicated their intent to have their data be restricted to a small group of friends.

Facebook's engineers fixed the problem within 36 hours of the initial blog post going live, and within a business day of the blog post being linked to from Boing Boing. This rapid response is fantastic, and the Facebook team should be proud of the way they demonstrated their commitment to protecting users' private information.

Contrast this, however, to the Firefox extension vulnerability I made public one month ago. I first notified the Facebook team of the flaw in their Facebook Toolbar product over 2 months ago, on April 21, while the story hit the news a month later on May 30th.

As of this morning, it looks like Facebook has still not fixed their toolbar - such that it continues to seek and download updates from an unauthenticated and insecure server (http://developers.facebook.com/toolbar/updates.rdf). Google and Yahoo who fixed the same problem in their products within a few days.

Yes - being able to quickly and effortlessly find out someones sexuality, religion and drug of choice (when they believe that their profile is private) is a major problem. It's far more serious than the chance that someone in an Internet cafe will take over your laptop - which is probably why Facebook rushed to fix the privacy problem so quickly. However, the security flaw in the Facebook toolbar remains an unresolved issue, and there is simply no excuse for them to wait two months to fix this vulnerability.

Wednesday, May 30, 2007

A Remote Vulnerability in Firefox Extensions



See a demo of the attack against Google Browser Sync: (12MB Quicktime).

Executive Summary

A vulnerability exists in the upgrade mechanism used by a number of high profile Firefox extensions. These include Google Toolbar, Google Browser Sync, Yahoo Toolbar, Del.icio.us Extension, Facebook Toolbar, AOL Toolbar, Ask.com Toolbar, LinkedIn Browser Toolbar, Netcraft Anti-Phishing Toolbar, PhishTank SiteChecker and a number of others, mainly commercial extensions.

Users of the Google Pack suite of software are most likely vulnerable, as this includes the Google Toolbar for Firefox.

The latest version of all of these listed, and many other extensions are vulnerable. This is not restricted to a specific version of Firefox.

Users are vulnerable and are at risk of an attacker silently installing malicious software on their computers. This possibility exists whenever the user cannot trust their domain name server (DNS) or network connection. Examples of this include public wireless networks, and users connected to compromised home routers.

The vast majority of the open source/hobbyist made Firefox extensions - those that are hosted at https://addons.mozilla.org - are not vulnerable to this attack. Users of popular Firefox extensions such as NoScript, Greasemonkey, and AdBlock Plus have nothing to worry about.

In addition to notifying the Firefox Security Team, some of the most high-profile vulnerable software vendors (Google, Yahoo, and Facebook) were notified 45 days ago, although none have yet released a fix. The number of vulnerable extensions is more lengthy than those listed in this document. Until vendors have fixed the problems, users should remove/disable all Firefox extensions except those that they are sure they have downloaded from the official Firefox Add-ons website (https://addons.mozilla.org). If in doubt, delete the extension, and then download it again from a safe place.

In Firefox, this can be done by going to Tools->Add-ons. Select the individual extensions, and then click on the uninstall button.






Frequently Asked Questions


Q: Who is at risk?

A: Anyone who has installed the Firefox Web Browser and one or more vulnerable extensions. These include, but are not limited to: Google Toolbar, Google Browser Sync, Yahoo Toolbar, Del.icio.us Extension, Facebook Toolbar, AOL Toolbar, Ask.com Toolbar, LinkedIn Browser Toolbar, Netcraft Anti-Phishing Toolbar, PhishTank SiteChecker.

Q: How many people are at risk?

A: Millions. Exact numbers for each toolbar/extension are not released by the vendors. Google Toolbar, which is one of the most popular of the vulnerable extensions, is installed as part of the download process with WinZip, RealNetworks' Real Player and Adobe's Shockwave. Google publicly pays website publishers $1 for each copy of Firefox + Google Toolbar that customers download and install through a publisher's website.

Google confirmed in 2005 that their toolbar product's user base was "in the millions". Given the number of distribution deals that have been signed, the number of users can only have grown in size since.

Q: When am I at risk?

A: When you use a public wireless network, an untrusted Internet connection, or a wireless home router with the default password set.

Q: What can happen to me?

A: An attacker can covertly install malicious software that will run within your web browser. Such software could spy on the you, hijack e-banking sessions, steal emails, send email spam and a number of other nasty tasks.

Q: What can I do to reduce my risk?

A: Users with wireless home routers should change their password to something other than the default.

Until the vendors release secure updates to their software, users should remove or disable all Firefox extensions and toolbars. Only those that have been downloaded from the official Firefox Add-Ons page are safe.

In Firefox, this can be done by going to the Tools menu and choose the Add-ons item. Select the individual extensions, and then click on the uninstall button.

Q: Why is this attack possible?

A: The problem stems from design flaws, false assumptions, and a lack of solid developer documentation instructing extension authors on the best way to secure their code.

The nature of the vulnerability described in this report is technical, but its impact can be limited by appropriate user configuration. This shows the relation between the technical and social aspects of security. For numerous other examples, please see the publications listed at www.stop-phishing.com. It also illustrates the need for good education of typical Internet users. This has been recognized as a difficult problem to tackle, but some recent efforts, e.g., www.SecurityCartoon.com look promising.





Description Of Vulnerability

The Firefox web browser includes the ability for third parties to release code, known as extensions, that will run within the user's browser. Firefox also includes an upgrade mechanism, enabling the extensions to poll an Internet server, looking for updates. If an update is available, the extension will typically ask the user if they wish to upgrade, and then will download and install the new code.

An exploitable vulnerability exists in the upgrade mechanism used by Firefox. The only real way to secure the upgrade path is for those websites hosting extensions and their updates to use SSL technology. The Mozilla team have provided a free hosting service for open source extensions, which is secure out of the box, by having the code served from https://addons.mozilla.org

For the most part, any extension which gets updates from a website that looks like http://www.example.com is insecure, while an extension that gets its updates from a website that looks like https://www.other-example.com is secure.

The vulnerability is made possible through the use of a man in the middle attack, a fairly old computer security technique. Essentially, an attacker must somehow convince your machine that he is really the update server for one or more of your extensions, and then the Firefox browser will download and install the malicious update without alerting the user to the fact that anything is wrong. While Firefox does at least prompt the user when updates are available, some commercial extensions (including those made by Google) have disabled this, and thus silently update their extensions without giving the user any say in the matter.

A DNS based man in the middle attack will not work against a SSL enabled webserver. This is because SSL certificates certify an association between a specific domain name and an ip address. An attempted man in the middle attack against a SSL enabled Firefox update server will result in the browser rejecting the connection to the masquerading update server, as the ip address in the SSL certificate, and the ip address returned by the DNS server will not match.

When Are Users Vulnerable

Users are most vulnerable to this attack when they cannot trust their domain name server. Examples of such a situation include:

  • Using a public or unencrypted wireless network.

  • Using a network router (wireless or wired) at home that has been infected/hacked through a drive by pharming attack. This particular risk can be heavily reduced by changing the default password on your home router.

  • Using a 'network hub' - either at the office, a university, or elsewhere.

Such users are vulnerable to a number of attacks such as DNS spoofing, DNS poisoning and ARP spoofing. A potential hack can occur when a malicious person is able to convince a victim's Firefox browser to connect to a malicious host, instead of going to the intended update server.

Using this vulnerability, an attacker can force a user's browser to download and install malicious code. Such code runs within the browser, and does not run as a superuser or privileged user. A malicious extension could spy on the user, perform an active man in the middle attack on e-banking sessions, steal emails, send spam from the user's account, perform local network port scanning, and a number of other nasty tasks.

Fixing The Problem


The number of vulnerable extensions is more lengthy than those listed in this document. Until vendors have fixed the problems, users should remove/disable all Firefox extensions except those that they are sure they have downloaded from the official Firefox Add-ons website (https://addons.mozilla.org). If in doubt, delete the extension, and then download it again from a safe place.

In Firefox, this can be done by going to Tools->Add-ons. Select the individual extensions, and then click on the uninstall button.

The vendors can either host their extensions on https://addons.mozilla.org, or if they choose to host them on their own webservers, they should turn on SSL. While this is not a particularly difficult engineering effort, for those extensions with millions of users, it may require a few additional machines to cope with the extra load required by all of those SSL connections.

As a matter of general policy, vendors really should not have their software silently install updates without asking the user's permission. It is asking for trouble.

The Mozilla Security Team has updated their developer documentation to properly address the risks that hosting updates from an insecure server can pose. The updated documentation can be found online.

There seems to be one commercial vendor whose extension does get its updates from a secure website. The McAfee SiteAdvisor does things correctly, and is thus not vulnerable to this attack.


Why Are Commercial Vendors' Extensions Vulnerable


The vast majority of commercial software vendors do not have their extensions hosted on the https://addons.mozilla.org website. They prefer to control the entire user experience, and thus wish to have the users connect to their own servers for the initial download and future updates. These vendors are not hosting the updates on a secure, SSL-enabled webserver, and thus the update process for these extensions is vulnerable to a man in the middle attack.

Some vendors have made things much worse by having their extensions automatically update without asking the user for permission. The majority of the open source extensions follow the Firefox defaults, and thus require that the user "OK" any software updates.


What About Code Signing


The code signing functionality in Firefox is fairly limited. The main difference is that a signed extension will show the signer's name when the user is prompted to install the extension, while an unsigned extension will list "un-signed" next to the extension name.

The availability of an update without signatures for extensions that previously had a valid signature does not raise any kind of error. Furthermore, the signature is thrown away as soon as the new extension update is installed.

Code signing is not currently an effective method of securing the extension upgrade path. Developers should instead have their updates served by a SSL enabled webserver.

Notification of Vendors


The Mozilla Security Team was notified of this on April 16th. They do not believe that this is a Firefox bug or vulnerability, due to the fact that the vast majority of extensions (those hosted at https://addons.mozilla.org) are secure by default.

The Ebay developed, but Mozilla cobranded Firefox/Ebay extension was vulnerable, but the Mozilla Security Team fixed the problems and rolled out an update within 2 days of being notified.

The Mozilla developers have created an entry in their bug tracking database for the insecure updates issue, but it is not slated to be fixed until Firefox 3.0.

The Google Security Team was notified of the problem on April 16th. They were given a full explanation of the vulnerability. An additional four emails were sent between April 20th and May 24th. These included additional information on the problem, offers to provide help as well as offers to delay publication of the vulnerability. The Google Security Team replied on May 25th stating that they were working on a fix, and expected to have it ready and deployed before May 30th. At the time of publishing this vulnerability disclosure, it does not appear that Google has rolled out an update yet.

The Yahoo Security Team was notified of the problem on April 21st. A human being replied to the initial report with intelligent questions, in less than 12 hours, on a Saturday. There has been no further communication from Yahoo.

The Facebook Security Team was notified on April 21st. They replied with two emails from a human being confirming receipt of the report. There has been no further communication from Facebook.

The number of vulnerable extensions continues to grow. It is just not feasible to provide advanced notification to every creator of a Firefox extension. Advanced notice has thus been given to those major vendors who the research initially focused on.

The CERT disclosure policy states that "All vulnerabilities reported to the CERT/CC will be disclosed to the public 45 days after the initial report, regardless of the existence or availability of patches or workarounds from affected vendors." Given the fact that fixing the flaw is a fairly trivial engineering task (changing a couple urls from http->https), and it is very easy for users to protect themselves (remove the vulnerable toolbars), sitting on this information any longer would be a bad idea.

Another other well respected responsible disclosure policy sets a 5 days time limit. If the vendor does not keep in touch with the security developer every 5 days, then the vulnerability will be made public. While this path was not followed, it is worth noting that neither Google, Yahoo or Facebook made an attempt to keep the lines of communication open. Following such a policy, this information would have thus been revealed a number of weeks ago.


Self Disclosure/Conflict of Interest Statement



Christopher Soghoian is a PhD student in the School of Informatics at Indiana University. He is a member of the Stop Phishing Research Group. His research is focused in the areas of phishing, click-fraud, search privacy and airport security. He has worked an intern with Google, Apple, IBM and Cybertrust. He is the co-inventor of several pending patents in the areas of mobile authentication, anti-phishing, and virtual machine defense against viruses. His website is http://www.dubfire.net/chris/ and he blogs regularly at http://paranoia.dubfire.net

This vulnerability was discovered and disclosed to vendors during the spring semester, while he was paid as a researcher assistant at Indiana University. He is now currently working at an internship in Europe. This disclosure announcement, and the vulnerability in no way reflect the opinions or corporate policy of his current employer nor those of Indiana University.

Information on this vulnerability was disclosed for free to the above listed vendors. Christopher Soghoian has not been financially compensated for this work. He has no malicious or ill feelings towards any of the vulnerable software companies.

He was an intern with the Application Security Team at Google during the summer of 2006. Finding this vulnerability did not involve using any confidential information that he learned while employed by Google. It was done solely with a copy of Firefox and a packet sniffer.