Edited to add: I wrote a followup post to address comments here and elsewhere that advertising is working as intended. This paper has been reported incorrectly in several places as being about cookie blocking. Tracking protection blocks all traffic, not just cookies.
My paper with Georgios Kontaxis got best paper award at the Web 2.0 Security and Privacy workshop today! Georgios re-ran the performance evaluations on top news sites and the decrease in page load time with tracking protection enabled is even higher (44%!) than in our Air Mozilla talk last August, due to prevalence of embedded third party content on news sites. You can read the paper here.
This paper is the last artifact of my work at Mozilla, since I left employment there at the beginning of April. I believe that Mozilla can make progress in privacy, but leadership needs to recognize that current advertising practices that enable "free" content are in direct conflict with security, privacy, stability, and performance concerns -- and that Firefox is first and foremost a user-agent, not an industry-agent.
Advertising does not make content free. It merely externalizes the costs in a way that incentivizes malicious or incompetent players to build things like Superfish, infect 1 in 20 machines with ad injection malware, and create sites that require unsafe plugins and take twice as many resources to load, quite expensive in terms of bandwidth, power, and stability.
It will take a major force to disrupt this ecosystem and motivate alternative revenue models. I hope that Mozilla can be that force.
Thursday, May 21, 2015
Thursday, April 2, 2015
Some links about tracking and security
A roundup of links on tracking, advertising and security. These are not complete or even representative, but may be useful to somebody.
Attitudes towards tracking and surveillance
- 91% of adults in the survey “agree” or “strongly agree” that consumers have lost control over how personal information is collected and used by companies (http://www.pewinternet.org/2014/11/12/public-privacy-perceptions/)
- 64% believe the government should do more to regulate advertisers, compared with 34% who think the government should not get more involved (ibid)
- 40% of teen social media users say they are “very” or “somewhat” concerned that some of the information they share on social networking sites might be accessed by third parties like advertisers or businesses without their knowledge (http://www.pewinternet.org/2013/05/21/teens-social-media-and-privacy/)
- 81% of parents report being “very” or “somewhat” concerned about how much information advertisers can learn about their child’s online behavior (ibid)
- 17% of the adults who have heard about the government surveillance programs say they have changed their privacy settings on social media in an effort to hide their information from the government (http://www.pewinternet.org/2015/03/16/how-people-are-changing-their-own-behavior/)
- Smart, Useful, Scary, Creepy: Perceptions of Online Behavioral Advertising (https://www.andrew.cmu.edu/user/pgl/soups2012.pdf)
Advertising and fraud
- Malvertising abuses RTB, using fingerprinting and microtargeting to do things like spearphish (https://threatpost.com/ad-networks-ripe-for-abuse-via-malvertising/111840)
- Doubleclick used to spread malware (https://blog.malwarebytes.org/malvertising-2/2014/09/googles-doubleclick-ad-network-abused-once-again-in-malvertising-attacks/)
- Doubleclick and Zedo used to spread malware (https://blog.malwarebytes.org/malvertising-2/2014/09/large-malvertising-campaign-under-way-involving-doubleclick-and-zedo/)
- Too many to count: https://blog.malwarebytes.org/?s=advertising
- Malvertising doubles every year since 2011 (http://money.cnn.com/2014/10/15/technology/security/malvertising/)
- 67% of bot traffic comes from residential IPs. Bot traffickers remotely control home computers to generate ad fraud profits. 19% of retargeted ads are consumed by bots, and even higher in video (http://www.whiteops.com/botfraud, well worth downloading)
- 56% of ad impressions are never seen, not even for a second (http://think.storage.googleapis.com/docs/the-importance-of-being-seen_study.pdf)
Bugs
- Facebook personal information leak from shadow profiles (https://www.facebook.com/notes/facebook-security/important-message-from-facebooks-white-hat-program/10151437074840766, http://packetstormsecurity.com/news/view/22713/Facebook-Where-Your-Friends-Are-Your-Worst-Enemies.html)
- Google accidentally collects data from unencrypted WiFi (http://www.pcworld.com/article/2048541/google-loses-appeal-in-street-view-privacy-lawsuit.html, http://googleblog.blogspot.com/2010/05/wifi-data-collection-update.html)
- Apple keeps 3G location log (http://blog.chron.com//techblog/2011/04/why-is-apples-ios-logging-location-information-updated/)
Tracking
- NSA uses Google cookies to pinpoint targets for hacking (http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/)
- Facebook cookies and EU law, similar to Facebook Beacon complaints (http://www.theguardian.com/technology/2015/mar/31/facebook-tracks-all-visitors-breaching-eu-law-report)
- How Target figured out a teen girl was pregnant before her father did (http://www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-was-pregnant-before-her-father-did/)
- Acxiom: the company that knows if you own a cat or if you're right-handed (http://www.telegraph.co.uk/finance/newsbysector/retailandconsumer/5231752/Acxiom-the-company-that-knows-if-you-own-a-cat-or-if-youre-right-handed.html)
Some privacy litigation
- Google broke Canada’s privacy laws with targeted health ads according to The Office of the Privacy Commissioner of Canada (http://www.theglobeandmail.com/technology/tech-news/google-broke-canadas-privacy-laws-with-targeted-ads-regulator-says/article16343346/)
- Google loses Safari cookie tracking case and also loses on appeal (http://appleinsider.com/articles/15/03/27/google-loses-uk-appeal-in-safari-cookie-tracking-case-could-face-trial)
- Facebook Beacon lets third party sites publish events to people's feeds (http://www.pcworld.com/article/184029/facebook_halts_beacon_gives_9_5_million_to_settle_lawsuit.html)
- Google Buzz privacy lawsuit (http://mashable.com/2010/09/03/google-buzz-lawsuit-settlement/)
- Suit dismissed against Jetblue and Acxiom for using customer data without their knowledge (http://www.aviationpros.com/news/10433407/ny-federal-judge-dismisses-lawsuit-against-jetblue-acxiom)
- Suit against Acxiom for buying driver data from Arkansas DMV (http://ivebeenmugged.typepad.com/my_weblog/2010/01/dppa-class-actions.html)
Tuesday, March 31, 2015
Two Short Stories about Tracking Protection
Here are two slide decks I made about why online tracking is a privacy concern, and a metaphor for how tracking works.
Thursday, March 19, 2015
How do I turn on Tracking Protection? Let me count the ways.
I get this question a lot from various people, so it deserves its own post. Here's how to turn on Tracking Protection in Firefox to avoid connecting to known tracking domains from Disconnect's blocklist:
- Visit about:config and turn on privacy.trackingprotection.enabled. Because this works Firefox 35 or later, this is my favorite method. In Firefox 37 and later, it also works on Fennec.
- On Fennec Nightly, visit Settings > Privacy and select the checkbox "Tracking Protection".
- Install Lightbeam and toggle the "Tracking Protection" button in the top-right corner. Check out the difference in visiting only 2 sites with Tracking Protection on and off!
- On Firefox Nightly, visit about:config and turn on browser.polaris.enabled. This will enable privacy.trackingprotection.enabled and also show the checkbox for it in about:preferences#privacy, similar to the Fennec screenshot above. Because this only works in Nightly and also requires visiting about:config, it's my least favorite option.
- Do any of the above and sign into Firefox Sync. Tracking Protection will be enabled on all of your desktop profiles!
Wednesday, March 18, 2015
Tracking Protection talk on Air Mozilla
In August 2014, Georgios Kontaxis and I gave a talk on the implementation status of tracking protection in Firefox. At the time the talk was Mozillians only, but now it is public! Please visit
Air Mozilla to view the talk, or see the slides below.
The implementation status has not changed very much since last August, so most of the information is still pretty accurate.
Monday, November 10, 2014
Tracking Protection in Firefox
On Monday a project that I've been working on was officially announced as part of a larger privacy initiative called Polaris. In case you missed it, there is an experimental tracking protection feature in Firefox Nightly that allows people to avoid being tracked by not communicating with known tracking domains, especially those that do not respect DNT. Our initial blocklist is from Disconnect. As a side effect, blocking resources from tracking domains speeds up page load times on average by 20%. Privacy features rarely coincide with performance benefits, so that's exciting.
Currently, tracking protection is available by turning on browser.polaris.enabled in about:config. If you care about privacy in Firefox and are running Nightly, please give it a try. Requiring about:config changes is quite onerous, but we need your feedback to improve tracking protection. You can read official instructions on how to turn on tracking protection or see the animated gif below (original slide deck here for people who like to advance manually).
Wednesday, September 10, 2014
Making decisions with limited data
It is challenging but possible to make decisions with limited data. For example, take the rollout saga of public key pinning.
The first implementation of public key pinning included enforcing pinning on addons.mozilla.org. In retrospect, this was a bad decision because it broke the Addons Panel and generated pinning warnings 86% of the time. As it turns out, the pinset was missing some Verisign certificates used by services.addons.mozilla.org, and the pinning enforcement on addons.mozilla.org included subdomains. Having more data lets us avoid bad decisions.
To enable safer rollouts, we implemented a test mode for pinning. In test mode, pinning violations are counted but not enforced. With sufficient telemetry, it is possible to measure how badly sites would break without actually breaking the site.
Due to privacy restrictions in telemetry, we do not collect per-organization pinning violations except for Mozilla sites that are operationally critical to Firefox. This means that it is not possible to distinguish pinning violations for Google domains from Twitter domains, for example. I do not believe that collecting the aggregated number of pinning violations for sites on the Alexa top 10 list constitutes a privacy violation, but I look forward to the day when technologies such as RAPPOR make it easier to collect actionable data in a privacy-preserving way.
Fortunately for us, Chrome has already implemented pinning on many high-traffic sites. This is fantastic news, because it means we can import Chrome’s pin list in test mode with relatively high assurance that the pin list won’t break Firefox, since it is already in production in Chrome.
Given sufficient test mode telemetry, we can decide whether to enforce pins instead of just counting violations. If the pinning violation rate is sufficiently low, it is probably safe to promote the pinned domain from test mode to production mode.
Because the current implementation of pinning in Firefox relies on built-in static pinsets and we are unable to count violations per-pinset, it is important to track changes to the pinset file in the dashboard. Fortunately HighStock supports event markers which somewhat alleviates this problem, and David Keeler also contributed some tooltip code to roughly associate dates with Mercurial revisions. Armed with the timeseries of pinning violation rates, event markers for dates that we promoted organizations to production mode (or high-traffic organizations like Dropbox were added in test mode due to a new import from Chromium) we can see whether pinning is working or not.
Telemetry is useful for forensics, but in our case, it is not useful for catching problems as they occur. This limitation is due to several difficulties, which I hope will be overcome by more generalized, comprehensive SSL error-reporting and HPKP:
The first implementation of public key pinning included enforcing pinning on addons.mozilla.org. In retrospect, this was a bad decision because it broke the Addons Panel and generated pinning warnings 86% of the time. As it turns out, the pinset was missing some Verisign certificates used by services.addons.mozilla.org, and the pinning enforcement on addons.mozilla.org included subdomains. Having more data lets us avoid bad decisions.
To enable safer rollouts, we implemented a test mode for pinning. In test mode, pinning violations are counted but not enforced. With sufficient telemetry, it is possible to measure how badly sites would break without actually breaking the site.
Due to privacy restrictions in telemetry, we do not collect per-organization pinning violations except for Mozilla sites that are operationally critical to Firefox. This means that it is not possible to distinguish pinning violations for Google domains from Twitter domains, for example. I do not believe that collecting the aggregated number of pinning violations for sites on the Alexa top 10 list constitutes a privacy violation, but I look forward to the day when technologies such as RAPPOR make it easier to collect actionable data in a privacy-preserving way.
Fortunately for us, Chrome has already implemented pinning on many high-traffic sites. This is fantastic news, because it means we can import Chrome’s pin list in test mode with relatively high assurance that the pin list won’t break Firefox, since it is already in production in Chrome.
Given sufficient test mode telemetry, we can decide whether to enforce pins instead of just counting violations. If the pinning violation rate is sufficiently low, it is probably safe to promote the pinned domain from test mode to production mode.
Because the current implementation of pinning in Firefox relies on built-in static pinsets and we are unable to count violations per-pinset, it is important to track changes to the pinset file in the dashboard. Fortunately HighStock supports event markers which somewhat alleviates this problem, and David Keeler also contributed some tooltip code to roughly associate dates with Mercurial revisions. Armed with the timeseries of pinning violation rates, event markers for dates that we promoted organizations to production mode (or high-traffic organizations like Dropbox were added in test mode due to a new import from Chromium) we can see whether pinning is working or not.
Telemetry is useful for forensics, but in our case, it is not useful for catching problems as they occur. This limitation is due to several difficulties, which I hope will be overcome by more generalized, comprehensive SSL error-reporting and HPKP:
- Because pinsets are static and built-in, there is sometimes a 24-hour lag between making a change to a pinset and reaching the next Nightly build.
- Telemetry information is only sent back once per day, so we are looking at a 2-day delay between making a change and receiving any data back at all.
- Telemetry dashboards (as accessible from telemetry.js and telemetry.mozilla.org) need about a day to aggregate, which adds another day.
- Update uptake rates are slow. The median time to update Nightly is around 3 days, getting to 80% takes 10 days or longer.
Due to these latency issues, pinning violation rates take at least a week to stabilize. Thankfully, telemetry is on by default in all pre-release channels as of Firefox 31, which gives us a lot more confidence that the pinning violation rates are representative.
Despite all the caveats and limitations, using these simple tools we were able to successfully roll out pinning pretty much all sites that we’ve attempted (including AMO, our unlucky canary) as of Firefox 34 and look forward to expanding coverage.
Thanks for reading, and don’t forget to update your Nightly if you love Mozilla! :)
Despite all the caveats and limitations, using these simple tools we were able to successfully roll out pinning pretty much all sites that we’ve attempted (including AMO, our unlucky canary) as of Firefox 34 and look forward to expanding coverage.
Thanks for reading, and don’t forget to update your Nightly if you love Mozilla! :)
Subscribe to:
Posts (Atom)
