tag:blogger.com,1999:blog-23654893643680977562024-02-19T02:15:31.724-08:00Monica at MozillaMonicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-2365489364368097756.post-23349890197422905812015-11-19T09:55:00.000-08:002015-11-19T09:58:22.928-08:00Tracking Protection Officially Supported in Firefox 42Mozilla officially started supported <a href="https://blog.mozilla.org/blog/2015/11/03/firefox-now-offers-a-more-private-browsing-experience/">Tracking Protection in Private Browsing mode</a> with Firefox 42, which launched a couple of weeks ago. Congratulations to everyone who worked on the launch! The onboarding looks awesome and the unified UI is a nice touch, although I have to admit a preference for the original, engineer-designed marketing aesthetics pictured below.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgk7Z1T9AV6oLsMs2iI_qvWB7eGAxBo13LFAAO8eEY6Y2IB2RlLCnGJqCU8XqUPvf_14Y2Btg7dXZlbtPl6eTaXNpW-Te9eqKhgPVSsXBAmEpmyg-GwYielTtSazLVmUZeskATIZrS-xBF2/s1600/mugshot.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgk7Z1T9AV6oLsMs2iI_qvWB7eGAxBo13LFAAO8eEY6Y2IB2RlLCnGJqCU8XqUPvf_14Y2Btg7dXZlbtPl6eTaXNpW-Te9eqKhgPVSsXBAmEpmyg-GwYielTtSazLVmUZeskATIZrS-xBF2/s320/mugshot.jpg" width="240" /></a></div>
<br />
<br />
Even outside of Private Browsing mode, you can still take advantage of Tracking Protection by going to<span style="font-family: "courier new" , "courier" , monospace;"> about:config</span> and turning on <span style="font-family: "courier new" , "courier" , monospace;">privacy.trackingprotection.enabled</span>. This behavior has been supported for over a year since Firefox 34, so it's great to see Mozilla making this more usable by turning it on in Private Browsing mode.<br />
<br />
I hope that Mozilla continues to use its products to challenge the notion that we owe our eyeballs, our computing resources and our entire browsing history to the ad industry, with no questions asked.<br />
<br />Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com6tag:blogger.com,1999:blog-2365489364368097756.post-127569260031903902015-05-28T10:59:00.000-07:002015-05-28T10:59:12.367-07:00Advertising: a sustainable utopia?Advertising generates <a href="http://www.iab.net/media/file/IAB_Internet_Advertising_Revenue_FY_2014.pdf">$50 billion annually</a> in the US alone, but how much of that figure reflects real value? Approximately <a href="http://www.wsj.com/articles/SB10001424052702304026304579453253860786362">⅓ of click traffic is fraudulent</a>, leading to <a href="http://www.campaignlive.co.uk/news/1322083/">$10 billion</a> in wasted spending annually. Counting revenue due to fraud towards the value of advertising is like counting money spent on diabetes treatments as part of the GDP -- if those figures went to zero, it would reflect a healthier ecosystem, or healthier people in the diabetes case. For people making money on advertising, it is difficult to accept that a reduction in annual revenue can mean that things are better for everyone else.<br /><br />Even when ads are displayed to real people, they often create little to no value for the ad creator. According to Google, <a href="http://think.storage.googleapis.com/docs/the-importance-of-being-seen_study.pdf">half of ads are never viewable</a>, not even for a second. In addition, <a href="http://blog.pagefair.com/2014/adblocking-report/">adblocking usage grew by 70% last year</a>, and 41% of people between 18-29 use an adblocker. The advertising industry responds to these trends by making ads increasingly distracting (requiring large amounts of resources and unsafe plugins to run), collecting increasingly large amounts of data, and creating more opportunities for <a href="http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/">abuse by government agencies</a> and <a href="http://en.wikipedia.org/wiki/Superfish">other malicious actors</a>. As Mitchell Baker put it, <a href="https://blog.lizardwrangler.com/2013/06/11/total-surveillance/">do we want to live in a house or a fish bowl</a>?<br /><br />There has to be a better way. Why can’t a person buy and blank out all of the ad space on sites they visit at a deep discount, since targeting machinery would no longer be relevant? Why aren’t subscriptions available as bundle deals, like in streaming video? Solutions like these are hypothetical and will remain so as long we maintain the fiction that the current advertising revenue model is a sustainable utopia.Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com2tag:blogger.com,1999:blog-2365489364368097756.post-32623536894450273332015-05-21T14:29:00.000-07:002015-05-28T11:02:50.695-07:00Tracking Protection for Firefox at Web 2.0 Security and Privacy 2015<i>Edited to add: I wrote a <a href="http://monica-at-mozilla.blogspot.com/2015/05/advertising-sustainable-utopia.html">followup post</a> 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 <a href="http://imgur.com/CAcyLiJ">blocks all traffic</a>, not just cookies.</i><br />
<br />
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 <a href="https://air.mozilla.org/tracking-protection-for-firefox/">Air Mozilla talk last August</a>, due to prevalence of embedded third party content on news sites. You can <a href="http://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf">read the paper here</a>.<br />
<br />
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.<br />
<br />
Advertising does not make content free. It merely externalizes the costs in a way that incentivizes malicious or incompetent players to build things like <a href="http://en.wikipedia.org/wiki/Superfish">Superfish</a>, infect <a href="http://googleonlinesecurity.blogspot.com/2015/05/new-research-ad-injection-economy.html">1 in 20 machines with ad injection malware</a>, and create sites that require <a href="http://blog.trendmicro.com/trendlabs-security-intelligence/trend-micro-discovers-new-adobe-flash-zero-day-exploit-used-in-malvertisements/">unsafe plugins</a> and take twice as many resources to load, quite expensive in terms of bandwidth, power, and stability.<br />
<br />
It will take a major force to disrupt this ecosystem and motivate alternative revenue models. I hope that Mozilla can be that force.Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com25tag:blogger.com,1999:blog-2365489364368097756.post-69425484992864147072015-04-02T14:59:00.001-07:002015-04-02T14:59:19.592-07:00Some links about tracking and security<h2>
<span style="font-size: small;"><span style="font-weight: normal;">A roundup of links on tracking, advertising and security. These are not complete or even representative, but may be useful to somebody.</span></span></h2>
<h2>
Attitudes towards tracking and surveillance</h2>
<ul>
<li>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 (<a href="http://www.pewinternet.org/2014/11/12/public-privacy-perceptions/">http://www.pewinternet.org/2014/11/12/public-privacy-perceptions/</a>)</li>
<li>64% believe the government should do more to regulate advertisers, compared with 34% who think the government should not get more involved (ibid)</li>
<li>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 (<a href="http://www.pewinternet.org/2013/05/21/teens-social-media-and-privacy/">http://www.pewinternet.org/2013/05/21/teens-social-media-and-privacy/</a>)</li>
<li>81% of parents report being “very” or “somewhat” concerned about how much information advertisers can learn about their child’s online behavior (ibid)</li>
<li>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 (<a href="http://www.pewinternet.org/2015/03/16/how-people-are-changing-their-own-behavior/">http://www.pewinternet.org/2015/03/16/how-people-are-changing-their-own-behavior/</a>)</li>
<li>Smart, Useful, Scary, Creepy: Perceptions of Online Behavioral Advertising (<a href="https://www.andrew.cmu.edu/user/pgl/soups2012.pdf">https://www.andrew.cmu.edu/user/pgl/soups2012.pdf</a>)</li>
</ul>
<div>
<h2>
Advertising and fraud</h2>
<div>
<ul>
<li>Malvertising abuses RTB, using fingerprinting and microtargeting to do things like spearphish (<a href="https://threatpost.com/ad-networks-ripe-for-abuse-via-malvertising/111840">https://threatpost.com/ad-networks-ripe-for-abuse-via-malvertising/111840</a>)</li>
<li>Doubleclick used to spread malware (<a href="https://blog.malwarebytes.org/malvertising-2/2014/09/googles-doubleclick-ad-network-abused-once-again-in-malvertising-attacks/">https://blog.malwarebytes.org/malvertising-2/2014/09/googles-doubleclick-ad-network-abused-once-again-in-malvertising-attacks/</a>)</li>
<li>Doubleclick and Zedo used to spread malware (<a href="https://blog.malwarebytes.org/malvertising-2/2014/09/large-malvertising-campaign-under-way-involving-doubleclick-and-zedo/">https://blog.malwarebytes.org/malvertising-2/2014/09/large-malvertising-campaign-under-way-involving-doubleclick-and-zedo/</a>)</li>
<li>Too many to count: <a href="https://blog.malwarebytes.org/?s=advertising">https://blog.malwarebytes.org/?s=advertising</a></li>
<li>Malvertising doubles every year since 2011 (<a href="http://money.cnn.com/2014/10/15/technology/security/malvertising/">http://money.cnn.com/2014/10/15/technology/security/malvertising/</a>)</li>
<li>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 (<a href="http://www.whiteops.com/botfraud">http://www.whiteops.com/botfraud</a>, well worth downloading)</li>
<li>56% of ad impressions are never seen, not even for a second (<a href="http://think.storage.googleapis.com/docs/the-importance-of-being-seen_study.pdf">http://think.storage.googleapis.com/docs/the-importance-of-being-seen_study.pdf</a>)</li>
</ul>
</div>
<h2>
Bugs</h2>
<div>
<ul>
<li>Facebook personal information leak from shadow profiles (<a href="https://www.facebook.com/notes/facebook-security/important-message-from-facebooks-white-hat-program/10151437074840766">https://www.facebook.com/notes/facebook-security/important-message-from-facebooks-white-hat-program/10151437074840766</a>, <a href="http://packetstormsecurity.com/news/view/22713/Facebook-Where-Your-Friends-Are-Your-Worst-Enemies.html">http://packetstormsecurity.com/news/view/22713/Facebook-Where-Your-Friends-Are-Your-Worst-Enemies.html</a>)</li>
<li>Google accidentally collects data from unencrypted WiFi (<a href="http://www.pcworld.com/article/2048541/google-loses-appeal-in-street-view-privacy-lawsuit.html">http://www.pcworld.com/article/2048541/google-loses-appeal-in-street-view-privacy-lawsuit.html</a>, <a href="http://googleblog.blogspot.com/2010/05/wifi-data-collection-update.html">http://googleblog.blogspot.com/2010/05/wifi-data-collection-update.html</a>)</li>
<li>Apple keeps 3G location log (<a href="http://blog.chron.com//techblog/2011/04/why-is-apples-ios-logging-location-information-updated/">http://blog.chron.com//techblog/2011/04/why-is-apples-ios-logging-location-information-updated/</a>)</li>
</ul>
</div>
<div>
<h2>
Tracking</h2>
<div>
<ul>
<li>NSA uses Google cookies to pinpoint targets for hacking (<a href="http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/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/</a>)</li>
<li>Facebook cookies and EU law, similar to Facebook Beacon complaints (<a href="http://www.theguardian.com/technology/2015/mar/31/facebook-tracks-all-visitors-breaching-eu-law-report">http://www.theguardian.com/technology/2015/mar/31/facebook-tracks-all-visitors-breaching-eu-law-report</a>)</li>
<li>How Target figured out a teen girl was pregnant before her father did (<a href="http://www.forbes.com/sites/kashmirhill/2012/02/16/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/</a>)</li>
<li>Acxiom: the company that knows if you own a cat or if you're right-handed (<a href="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">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</a>)</li>
</ul>
</div>
<h2>
Some privacy litigation</h2>
</div>
<ul>
<li>Google broke Canada’s privacy laws with targeted health ads according to The Office of the Privacy Commissioner of Canada (<a href="http://www.theglobeandmail.com/technology/tech-news/google-broke-canadas-privacy-laws-with-targeted-ads-regulator-says/article16343346/">http://www.theglobeandmail.com/technology/tech-news/google-broke-canadas-privacy-laws-with-targeted-ads-regulator-says/article16343346/</a>)</li>
<li>Google loses Safari cookie tracking case and also loses on appeal (<a href="http://appleinsider.com/articles/15/03/27/google-loses-uk-appeal-in-safari-cookie-tracking-case-could-face-trial">http://appleinsider.com/articles/15/03/27/google-loses-uk-appeal-in-safari-cookie-tracking-case-could-face-trial</a>)</li>
<li>Facebook Beacon lets third party sites publish events to people's feeds (<a href="http://www.pcworld.com/article/184029/facebook_halts_beacon_gives_9_5_million_to_settle_lawsuit.html">http://www.pcworld.com/article/184029/facebook_halts_beacon_gives_9_5_million_to_settle_lawsuit.html</a>)</li>
<li>Google Buzz privacy lawsuit (<a href="http://mashable.com/2010/09/03/google-buzz-lawsuit-settlement/">http://mashable.com/2010/09/03/google-buzz-lawsuit-settlement/</a>)</li>
<li>Suit dismissed against Jetblue and Acxiom for using customer data without their knowledge (<a href="http://www.aviationpros.com/news/10433407/ny-federal-judge-dismisses-lawsuit-against-jetblue-acxiom">http://www.aviationpros.com/news/10433407/ny-federal-judge-dismisses-lawsuit-against-jetblue-acxiom</a>)</li>
<li>Suit against Acxiom for buying driver data from Arkansas DMV (<a href="http://ivebeenmugged.typepad.com/my_weblog/2010/01/dppa-class-actions.html">http://ivebeenmugged.typepad.com/my_weblog/2010/01/dppa-class-actions.html</a>)</li>
</ul>
</div>
Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com0tag:blogger.com,1999:blog-2365489364368097756.post-50939794064453393702015-03-31T15:00:00.002-07:002015-03-31T15:00:28.784-07:00Two Short Stories about Tracking ProtectionHere are two slide decks I made about why online tracking is a privacy concern, and a metaphor for how tracking works.<div>
<br /></div>
<div>
[<a href="http://imgur.com/OhrzCnf">Animated gif version</a>]<br /><h2>
<iframe allowfullscreen="" frameborder="0" height="355" marginheight="0" marginwidth="0" scrolling="no" src="https://www.slideshare.net/slideshow/embed_code/46512009?startSlide=2" style="border: 1px solid rgb(204, 204, 204); margin-bottom: 5px; max-width: 100%;" width="425"></iframe></h2>
<div>
<br /></div>
<div>
<br /></div>
[<a href="http://imgur.com/CAcyLiJ">Animated gif version</a>]<h2>
<iframe allowfullscreen="" frameborder="0" height="355" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/46512229?startSlide=2" style="border: 1px solid rgb(204, 204, 204); margin-bottom: 5px; max-width: 100%;" width="425"></iframe></h2>
</div>
Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com0tag:blogger.com,1999:blog-2365489364368097756.post-54460106169356831422015-03-19T06:00:00.000-07:002015-03-19T07:58:27.228-07:00How do I turn on Tracking Protection? Let me count the ways.<br />
<div>
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 <a href="https://disconnect.me/">Disconnect's</a> blocklist:</div>
<ol>
<li>Visit <span style="font-family: Courier New, Courier, monospace;">about:config</span> and turn on <span style="font-family: Courier New, Courier, monospace;">privacy.trackingprotection.enabled</span>. Because this works Firefox 35 or later, this is my favorite method. In Firefox 37 and later, it also works on Fennec.</li>
<li>On Fennec Nightly, visit Settings > Privacy and select the checkbox "Tracking Protection".<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2eX_aT1BQfM6YjPcUfaavjdi5M74vNIsyogQZwI_5rESme88OgIESl_D8IlDQzFfDrlFrEZW9HjwFTaG5JH8XB0-zCnJWNEffucY_9KPz7MM0Zu_DNGpE9x_DAxhcNxVNZCW83_ZmxjTJ/s1600/fennectp.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2eX_aT1BQfM6YjPcUfaavjdi5M74vNIsyogQZwI_5rESme88OgIESl_D8IlDQzFfDrlFrEZW9HjwFTaG5JH8XB0-zCnJWNEffucY_9KPz7MM0Zu_DNGpE9x_DAxhcNxVNZCW83_ZmxjTJ/s1600/fennectp.png" height="320" width="192" /></a></div>
</li>
<li>Install <a href="https://addons.mozilla.org/en-US/firefox/addon/lightbeam">Lightbeam</a> 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!<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjX_ft-pYBjUrKxC09qVq6wNlBZcYww1KEOEKltu9csIXY_mIh5_azvXcuXs9up5DQXR94K8RXh8i8-OqEB6ztYpO-UWZHegxc7niKedhd04OlB56FUjfFiz8ObxXOb3OdR9e8r38PasfUH/s1600/tracking+protection+off+vs+on.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjX_ft-pYBjUrKxC09qVq6wNlBZcYww1KEOEKltu9csIXY_mIh5_azvXcuXs9up5DQXR94K8RXh8i8-OqEB6ztYpO-UWZHegxc7niKedhd04OlB56FUjfFiz8ObxXOb3OdR9e8r38PasfUH/s1600/tracking+protection+off+vs+on.png" height="316" width="640" /></a></div>
</li>
<li>On Firefox Nightly, visit <span style="font-family: Courier New, Courier, monospace;">about:config</span> and turn on <span style="font-family: Courier New, Courier, monospace;">browser.polaris.enabled</span>. This will enable <span style="font-family: Courier New, Courier, monospace;">privacy.trackingprotection.enabled</span> and also show the checkbox for it in <span style="font-family: Courier New, Courier, monospace;">about:preferences#privacy</span>, similar to the Fennec screenshot above. Because this only works in Nightly and also requires visiting <span style="font-family: Courier New, Courier, monospace;">about:config</span>, it's my least favorite option.</li>
<li>Do any of the above and <a href="http://support.mozilla.org/en-US/kb/what-firefox-sync">sign into Firefox Sync</a>. Tracking Protection will be enabled on all of your desktop profiles!</li>
</ol>
Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com2tag:blogger.com,1999:blog-2365489364368097756.post-14094941523800517512015-03-18T17:46:00.002-07:002015-03-18T17:46:59.466-07:00Tracking Protection talk on Air MozillaIn 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
<a href="https://air.mozilla.org/tracking-protection-for-firefox/">Air Mozilla</a> 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.
<iframe src="//www.slideshare.net/slideshow/embed_code/46013890" width="476" height="400" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com0tag:blogger.com,1999:blog-2365489364368097756.post-30266743504867826172014-11-10T17:41:00.000-08:002014-11-10T17:41:44.216-08:00Tracking Protection in Firefox<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both;">
On Monday a project that I've been working on was officially announced as part of a <a href="http://blog.mozilla.org/privacy/2014/11/10/introducing-polaris-privacy-initiative-to-accelerate-user-focused-privacy-online/">larger privacy initiative called Polaris</a>. 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 <a href="https://disconnect.me/">Disconnect</a>. 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.</div>
<div class="separator" style="clear: both;">
<br /></div>
<div class="separator" style="clear: both;">
Currently, tracking protection is available by turning on <span style="font-family: Courier New, Courier, monospace;">browser.polaris.enabled</span> in <span style="font-family: Courier New, Courier, monospace;">about:config</span>. If you care about privacy in Firefox and are running Nightly, please give it a try. Requiring <span style="font-family: Courier New, Courier, monospace;">about:config</span> changes is quite onerous, but we need your feedback to improve tracking protection. You can read <a href="https://support.mozilla.org/en-US/kb/tracking-protection-firefox?as=u&utm_source=inproduct">official instructions</a> on how to turn on tracking protection or see the animated gif below (<a href="http://www.slideshare.net/monicachew/how-to-turn-on-tracking-protection-for-firefox">original slide deck here</a> for people who like to advance manually).</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/nu9cMnj.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://i.imgur.com/nu9cMnj.gif" height="480" width="640" /></a></div>
<div class="separator" style="clear: both;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
Many thanks to everyone who helped get this landed, especially my awesome intern, <a href="https://www.cs.columbia.edu/~kontaxis/">Georgios Kontaxis</a>, and the team at Disconnect for open sourcing their blocklist.Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com14tag:blogger.com,1999:blog-2365489364368097756.post-59495594240138646862014-09-10T07:00:00.000-07:002015-11-19T23:40:25.280-08:00Making decisions with limited dataIt is challenging but possible to make decisions with limited data. For example, take the rollout saga of <a href="http://monica-at-mozilla.blogspot.com/2014/08/firefox-32-supports-public-key-pinning.html">public key pinning</a>.<br />
<br />
The <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=744204">first implementation of public key pinning</a> included enforcing pinning on addons.mozilla.org. In retrospect, this was a bad decision because it <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1005364">broke the Addons Panel</a> and <a href="http://telemetry.mozilla.org/#filter=nightly%2F32%2FCERT_PINNING_EVALUATION_RESULTS&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Table">generated pinning warnings 86% of the time</a>. As it turns out, the pinset was <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1005364">missing some Verisign certificates</a> used by services.addons.mozilla.org, and the pinning enforcement on addons.mozilla.org included subdomains. Having more data lets us avoid bad decisions.<br />
<br />
To enable safer rollouts, we implemented a <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=772756">test mode for pinning</a>. 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.<br />
<br />
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 <a href="http://arxiv.org/abs/1407.6981?context=cs">RAPPOR</a> make it easier to collect actionable data in a privacy-preserving way. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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 <a href="https://github.com/monicachew/pinning-dashboard">dashboard</a>. Fortunately <a href="http://www.highcharts.com/products/highstock">HighStock</a> supports <a href="http://www.highcharts.com/stock/demo/flags-general/grid">event markers</a> 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.<br />
<br />
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:<br />
<div>
<ul>
<li>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.</li>
<li>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.</li>
<li>Telemetry dashboards (as accessible from <a href="http://telemetry.mozilla.org/docs.html">telemetry.js</a> and <a href="http://telemetry.mozilla.org/">telemetry.mozilla.org</a>) need about a day to aggregate, which adds another day.</li>
<li>Update uptake rates are slow. The <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1017269#c4">median time to update Nightly</a> is around 3 days, getting to 80% takes 10 days or longer.</li>
</ul>
<div>
Due to these latency issues, pinning violation rates take at least a week to stabilize. Thankfully, <a href="https://groups.google.com/d/msg/mozilla.dev.planning/2ScJSX0QTOs/XSZbWEyN0ggJ">telemetry is on by default in all pre-release channels</a> as of Firefox 31, which gives us a lot more confidence that the pinning violation rates are representative.<br />
<br />
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.<br />
<br />
Thanks for reading, and don’t forget to update your Nightly if you love Mozilla! :)</div>
</div>
Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com0tag:blogger.com,1999:blog-2365489364368097756.post-85631594698410422932014-08-26T16:15:00.002-07:002015-05-21T13:37:54.772-07:00Firefox 32 supports Public Key Pinning<b><a href="https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning">Public Key Pinning</a> helps ensure that people are connecting to the sites they intend</b>. Pinning allows site operators to specify which certificate authorities (CAs) issue valid certificates for them, rather than accepting any one of the hundreds of built-in root certificates that ship with Firefox. If any certificate in the verified certificate chain corresponds to one of the known good certificates, Firefox displays the lock icon as normal.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhySppuM_x5JnbEvFQNF9KIGHZsQPgjE84j4mMfGp-hM9UzWuM6CmxujjPVFIVFqNqrfIglVqjkOaR0xekZYD0QIujWy8bUTpM4lwu11HtjRARsUiJ6S1IH09zUYncXqGcrc2N2adAHa8G/s1600/pinning+ok+(1).png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhySppuM_x5JnbEvFQNF9KIGHZsQPgjE84j4mMfGp-hM9UzWuM6CmxujjPVFIVFqNqrfIglVqjkOaR0xekZYD0QIujWy8bUTpM4lwu11HtjRARsUiJ6S1IH09zUYncXqGcrc2N2adAHa8G/s1600/pinning+ok+(1).png" width="371" /></a></div>
<div>
<b><br /></b>
<b>Pinning helps protect users from man-in-the-middle-attacks and rogue certificate authorities</b>. When the root cert for a pinned site does not match one of the known good CAs, Firefox will reject the connection with a pinning error. This type of error can also occur if a CA <a href="https://blog.mozilla.org/security/2011/08/29/fraudulent-google-com-certificate/">mis-issues a certificate</a>.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwIChXlTjG87keeneVpIkvs2O8STrkaH2L2iweZm8pjy87XUhmizgxLdvaJbYYJxzYMd6YYc_0NdF0TNNYvM4XpIQpcL5bRgoyfL0PWojJZuWjV_z1nkiymCNUcsWNSqxhwfhNJMp_Brl1/s1600/pinning+fail+(1).png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwIChXlTjG87keeneVpIkvs2O8STrkaH2L2iweZm8pjy87XUhmizgxLdvaJbYYJxzYMd6YYc_0NdF0TNNYvM4XpIQpcL5bRgoyfL0PWojJZuWjV_z1nkiymCNUcsWNSqxhwfhNJMp_Brl1/s1600/pinning+fail+(1).png" width="371" /></a></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="margin-left: 1em; margin-right: 1em;">
<br /></div>
<div>
<b>Pinning errors can be transient</b>. For example, if a person is signing into WiFi, they may see an error like the one below when visiting a pinned site. The error should disappear if the person reloads after the WiFi access is setup.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbfayzz59tXxMJJPxLrn6YDv8JW-DtWHvT9bMDOMdhJZcc5I8LOskIIX95AIDEFpVb7EGkLJOnuzqJghDvUJaqEvslaw6MsbPMubQN3N9xy_v0F55HXg6CEgqt0b4rD_sOIF9H0u4VYRl7/s1600/Screen+Shot+2015-05-21+at+1.36.37+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbfayzz59tXxMJJPxLrn6YDv8JW-DtWHvT9bMDOMdhJZcc5I8LOskIIX95AIDEFpVb7EGkLJOnuzqJghDvUJaqEvslaw6MsbPMubQN3N9xy_v0F55HXg6CEgqt0b4rD_sOIF9H0u4VYRl7/s320/Screen+Shot+2015-05-21+at+1.36.37+PM.png" width="320" /></a></div>
<br />
Firefox 32 and above supports built-in pins, which means that the list of acceptable certificate authorities must be set at time of build for each pinned domain. Pinning is enforced by default. Sites may advertise their support for pinning with the <a href="http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20">Public Key Pinning Extension for HTTP</a>, which we hope to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=787133">implement soon</a>. Pinned domains include addons.mozilla.org and Twitter in Firefox 32, and Google domains in Firefox 33, with <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1004350" target="_blank">more domains to come</a>. That means that <b>Firefox users can visit Mozilla, Twitter and Google domains more safely</b>. For the full list of pinned domains and rollout status, please see the <a href="https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status">Public Key Pinning wiki</a>.<br />
<br />
Thanks to Camilo Viecco for the initial implementation and David Keeler for many reviews!</div>
</div>
Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com25tag:blogger.com,1999:blog-2365489364368097756.post-47892003118512826002014-07-23T17:00:00.000-07:002015-11-19T23:40:55.285-08:00Download files more safely with Firefox 31<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<br />
<b>Did you know</b> that the estimated cost of malware is <a href="http://www.microsoft.com/en-us/news/downloads/presskits/dcu/docs/idc_031814.pdf">hundreds</a> of <a href="http://www.vanguardngr.com/2013/03/consumers-to-spend-22b-on-malware-impact-recovery-study/">billions</a> of <a href="http://www.business2community.com/tech-gadgets/staggering-cost-of-malware-now-over-100-billion-a-year-0559763">dollars</a> per year? Even without data loss or identity theft, the time and annoyance spent dealing with infected machines is a significant cost.<br />
<br />
Firefox 31 offers <b>improved malware detection</b>. Firefox has integrated Google’s Safe Browsing API for detecting phishing and malware sites since <a href="http://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-US/firefox/2.0/releasenotes/">Firefox 2</a>. In 2012 Google <a href="http://blog.chromium.org/2012/01/all-about-safe-browsing.html">expanded their malware detection</a> to include downloaded files and made it available to other browsers. I am happy to report that <a href="https://wiki.mozilla.org/Security/Features/Application_Reputation_Design_Doc">improved malware detection</a> has landed in Firefox 31, and will have expanded coverage in Firefox 32.<br />
<br />
In <a href="https://wiki.mozilla.org/Security/Features/Application_Reputation/Preliminary_Results">preliminary testing</a>, this feature <b>cuts the amount of undetected malware by half</b>. That’s a significant user benefit.</div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<br />
<b>What happens when you download malware?</b> Firefox checks URLs associated with the download against a local Safe Browsing blocklist. If the binary is signed, Firefox checks the verified signature against a local allowlist of known good publishers. If no match is found, Firefox 32 and later queries the Safe Browsing service with <a href="https://wiki.mozilla.org/Security/Features/Application_Reputation_Design_Doc">download metadata</a> (NB: this happens only on Windows, because signature verification APIs to suppress remote lookups are only available on Windows). In case malware is detected, the Download Manager will block access to the downloaded file and remove it from disk, displaying an error in the Downloads Panel.<br />
<br />
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<b>How can I turn this feature off?</b> This feature respects the existing Safe Browsing preference for malware detection, so if you’ve already turned that off, there’s nothing further to do. Below is a screenshot of the new, beautiful <a href="http://msujaws.wordpress.com/2014/05/18/in-content-preferences/" style="vertical-align: baseline;">in-content preferences</a> (Preferences > Security) with all Safe Browsing integration turned off. I strongly recommend against turning off malware detection, but if you decide to do so, keep in mind that phishing detection also relies on Safe Browsing.<br />
<br /></div>
Many thanks to Gian-Carlo Pascutto and Paolo Amadini for reviews, and the Google Safe Browsing team for helping keep Firefox users safe and secure!</div>
</div>
Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com10tag:blogger.com,1999:blog-2365489364368097756.post-55782863129281695042013-10-23T14:14:00.000-07:002013-10-23T14:19:37.868-07:00Cookie counting<h4>
Understanding cookies through user studies</h4>
A <a href="http://en.wikipedia.org/wiki/HTTP_cookie">cookie</a> is a small piece of data stored in the browser by websites. Although cookies are mostly invisible, they serve many purposes such as saving items in shopping carts, authenticating to websites, and displaying targeted ads or other personalized content. Understanding more about how websites use cookies allows us to write tools that manage cookies effectively.<br />
<br />
In June 2013, the Mozilla User Research team ran a paid study of 573 Firefox users that included data on cookie and browsing events. The user population was census-balanced and included only US users. The study ran for a median of 18.8 days, during which time we observed 18.4 million attempts to set cookies by examining <a href="http://en.wikipedia.org/wiki/HTTP_cookie#Setting_a_cookie">HTTP Set-Cookie</a> headers. Each Set-Cookie header counts as a single event, even though it may contain multiple cookies. Storing multiple pieces of information across separate cookies or combining them into a single cookie are equally powerful. Set-Cookie headers are not the only method for setting cookies, but they are sufficiently prevalent to be representative. We did not observe read events due to volume constraints. We observed 2.84 million pages loaded, measured by counting <a href="https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/tabs.html#ready">tab-ready events</a>.<br />
<br />
<table border="1">
<tbody>
<tr>
<td>N = 573</td>
<td>Tab-ready events</td>
<td>Set-Cookie events</td>
<td>Tab-ready events/day</td>
</tr>
<tr>
<td>Median</td>
<td align="right">3552</td>
<td align="right">12297</td>
<td align="right">189</td>
</tr>
<tr>
<td>Total</td>
<td align="right">2842270</td>
<td align="right">12439439</td>
<td></td>
</tr>
</tbody></table>
<h4>
Counting origins</h4>
Throughout this post we use <a href="http://publicsuffix.org/">top-level domains</a> (from the <a href="http://en.wikipedia.org/wiki/Public_Suffix_List">Public Suffix</a> list) plus one component to count origins. For example, we consider foo.example.com and bar.example.com to represent the same origin. The public suffix mechanism is not perfect, because a single organization may own many origins (e.g., doubleclick.net and google.com both belong to Google).
In total, study users visited 40682 unique origins (counted by tab-ready events) and received set-cookie events from 32786 unique origins. Below is the distribution of cookie events per tab event.<br />
<h4>
<img src="https://lh6.googleusercontent.com/1RL8hv8vEiS7IEKppioQyNWApyfdHi3ZN9Z7DLPW8NHY_qzRoNCTETlgKmKqRH5Ok1FifW9mCiA5-XsSJNLBeSPVLzisJkg914HV7Ayk8gR92H38hyPYCHyr" /></h4>
<h4>
Who uses cookies?</h4>
Building effective cookie management tools requires understanding who sets cookies. Cookie activity is difficult to characterize because sites vary highly in both the number of cookies they set and the amount of third-party content (which may set cookies on behalf of the third-party site) that they include. Although each page load event incurs on average around 3.6 Set-Cookie events, many sites incur an order of magnitude more.<br />
<br />
The graph below shows the 20 origins responsible for the most set-cookie events. These origins represent 0.05% of unique cookie-setting origins and are responsible for 42.7% of set-cookie events seen in the study data. Set-cookie attempts are either first-party, where the origin of the cookie being set is the same as the one in the location bar, or <a href="http://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookie">third-party</a>, where the origins don't match.<br />
<img src="https://lh3.googleusercontent.com/YdkikRCQLx-OHGcuuQcQENkGEJkGfI3DTFDrUknD81-dRk97wjomvNEdBjkRTtRQfqW56DhjqC43lvHbbSHx-0Bt4yZnqfibmDvsJH8PUx4yKjhZ4dbnBYnq" /><br />
<h4>
Who uses third-party cookies?</h4>
Third-party cookies have many purposes. For example, social widget implementations usually rely on third-party cookies to display personalized content, and inline ads rely on third-party cookies to provide targeted ads and perform frequency capping. Of the 12.4 million set-cookie events in the study, 50.4% are for third-party cookies (shown in red in the graph above).<br />
<br />
The graph below shows the top 20 origins setting third-party cookies, responsible for 41.1% of third-party set-cookie events. adnxs.com belongs to AppNexus, an ad exchange. Facebook sets mostly first-party cookies, but because Facebook's social widgets are included on many sites, Facebook sets many third-party cookies (which may have originally been created in a first-party context). Of the top 20 origins, 18 primarily offer advertising services.<img src="https://lh5.googleusercontent.com/WGLYqQXTiADnOWSwdfVau9GRh8edWFuwG5V9adDA7cg5qS0zvKRrJQyueifvNPG11Lr5fUUXtIVxFYWjiyhcBAQBvp_POUnRdX7C5mqeww3uxP-W_IYEUs0A" /><br />
<br />
It is interesting to compare this data to Table IV from Eubank et al.'s <a href="http://w2spconf.com/2013/papers/s2p2.pdf">survey on third-party cookies</a>. In the Eubank survey, the authors used simulated data from crawling Alexa's top 500 websites, included all types of third-party embedded data, and did not canonicalize domains using the public suffix list. Even though the methodology is different, many origins in the top 20 overlap.<br />
<h4>
How many third-party cookies are from origins the user knows?</h4>
One interesting question is whether or not users intentionally accept cookies, especially in the case of third-party cookies. We examine two possible heuristics for estimating whether a user interaction with an origin is intentional:<br />
<ol>
<li>The user has already accepted cookies from the origin (pre-existing cookie condition)</li>
<li>The user has visited the origin by entering it into the location bar (simulated history condition)</li>
</ol>
Both of these conditions rely on previous interactions. Any potential changes to the way browsers handle third-party cookies must consider what to do with previous interactions (in this case, existing cookies and location bar history).<br />
<h4>
Pre-existing cookie condition</h4>
We did not ask study participants to clear cookies before beginning the study. Of the third-party set-cookie events, 90.8% of them were sent to users who had already accepted cookies from that origin. The graph below shows this percentage for the top 20 origins that set third-party cookies. In this graph, nearly all origins are above 75% with the exception of doubleclick.net. This dip can be explained by a handful of users who have a particular security addon installed.<br />
<img src="https://lh5.googleusercontent.com/B_D1p_1wlhjdsEhBsjHqTf9s0Gd1KUun4Nl-SiKTv5C3NWd7prxQYbcRMDqwlA9TeVM-s5qP4hwf1NWYbUfv7njRgUJ1GM9QtQ3lUXDRQzBflboT-dCwsQKy" /><br />
<h4>
Simulated history condition</h4>
Another heuristic for evaluating if a user has interacted with a site is whether that origin has appeared in the location bar, as measured by tab-ready events. This lets us count third-party origins that have previously appeared in a first-party context.<br />
<br />
For each user, we take the entire set of origins extracted from tab-ready events to simulate that user’s history, then count whether the origins in the Set-Cookie events appear in the simulated history. The graph below shows this percentage for the top 20 origins of third-party cookies.<br />
<img src="https://lh3.googleusercontent.com/irAtuWye1oBT6Sabtwt1-bdvsimtw8UJk-7elXb4RExo7yJOiIC6rlRYwbDtju4PRE10gAH7EsgIuqJ0irWbwkJO4Cj0eUC0jZWqM-qoRL34yGhGtO-NvrQ-" /><br />
<br />
Overall, 19.6% of third-party cookie events came from origins in users’ simulated history in the course of the study. Not surprisingly, nearly all users had visited facebook.com and youtube.com, which are currently ranked <a href="http://www.alexa.com/siteinfo/facebook.com">2nd</a> and <a href="http://www.alexa.com/siteinfo/youtube.com">3rd</a> most visited sites according to <a href="http://draft.blogger.com/">Alexa</a>. Interestingly, adnxs.com also appeared much of the time in simulated histories, even though the <a href="http://www.alexa.com/siteinfo/adnxs.com">rank of adnxs.com</a> is currently 576 in the US according to Alexa. From looking through tab-ready events, adnxs.com appeared in redirects and popups.<br />
<h4>
How long do cookies live?</h4>
The Set-Cookie HTTP header has an optional expiration time that tells the browser how long to keep the cookie. From the graph below, many cookies are long-lived, possibly longer-lived than the installation of the operating system or browser. 20% of third-party cookie expiration times were one week or less, and 51% of third-party cookie expiration times were longer than 6 months.<br />
<img src="https://lh5.googleusercontent.com/X2GaHWRPj3zd3KzG1IUnWbTUaDAEbHvXaD6E5m8ZgdZaMu91GJ5tMxNiVTU7V4wTgAV1RBTcIPhU7lWaxr8A5NOYFRjRjkJHPriXvVXzIQ9tshIs7STz8E8FjQ" /><br />
<h4>
What's next?</h4>
Data from real users is crucial to understanding how websites use cookies and therefore what kind of technical solutions to cookie management make sense (or if indeed we should be concentrating on cookies at all). We hope that this is just the start of using data to shape our technologies and policies. Please join <a href="https://groups.google.com/forum/#!forum/mozilla.dev.privacy">dev-privacy</a> to continue the discussion.<br />
<br />
Many thanks to Gregg Lind for deploying the study and to Jonathan Mayer, Alex Fowler, John Jensen, and Chris Karlof for reviewing this post.Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com1tag:blogger.com,1999:blog-2365489364368097756.post-84903866175369762242013-07-17T10:41:00.000-07:002013-07-17T10:41:27.704-07:00Be who you want, when you wantBack in May I presented a <a href="http://w2spconf.com/2013/papers/s1p2.pdf" target="_blank">paper on contextual identity</a>, coauthored with <a href="http://blog.sidstamm.com/" target="_blank">Sid Stamm</a>, at the <a href="http://w2spconf.com/2013/" target="_blank">Web 2.0 Security and Privacy</a> workshop. Contextual identity is the notion that people choose how to present themselves depending on context, such as their audience or location. In contrast, external forces (such as naming policies imposed by social networks) promote the idea of having all your identities in one big identity. Although this is often convenient or desired, conflating all your identities can lead to serious privacy violations.<br />
<br />
The desire for spontaneous, positive human interaction often requires sharing personal information, and sharing information doesn't negate the need or desire for privacy. We still have far to go when it comes to understanding how typical users think about privacy, publicity and identity, though I am delighted that the Mozilla User Research team has recently made inroads into understanding <a href="https://blog.mozilla.org/ux/2012/12/distributed-qualitative-analysis-for-the-firefox-behavioral-segmentation-study/" target="_blank">user data types</a>.<br />
<br />
For your amusement, my talk slides are below. Be on the lookout for Snoop Lion and the popemobile!<br />
<div style="text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="356" marginheight="0" marginwidth="0" mozallowfullscreen="" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/24303144" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" webkitallowfullscreen="" width="427"> </iframe> </div>
<div style="margin-bottom: 5px;">
<div style="text-align: center;">
<strong> <a href="http://www.slideshare.net/monicachew/contextual-identity-w2sp" target="_blank" title="Contextual identity w2sp">Contextual identity w2sp</a> </strong> from <strong><a href="http://www.slideshare.net/monicachew" target="_blank">monicachew</a></strong> </div>
<div style="text-align: center;">
<br /></div>
</div>
Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com0tag:blogger.com,1999:blog-2365489364368097756.post-88750275489339293782013-05-30T18:14:00.000-07:002013-06-06T10:16:20.373-07:00Blushproof<h4>
Personal embarrassment, Firefox, and you.</h4>
Have you ever been personally embarrassed because your friends or housemates found out something about your browsing history? Even sites that you visit by accident stick around, in the form of your browser history and other local storage. Adult sites are not the only kind of site that have the potential to embarrass, either: it could be something as simple as not wanting your coworkers (or anyone else who has the opportunity to look over your shoulder) to know that you enjoy making <a href="http://en.wikipedia.org/wiki/Ikebana">ikebana</a> arrangements to blow off steam, or are a huge fan of <a href="http://hannahmontana.sourceforge.net/">Hannah Montana</a>.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://en.wikipedia.org/wiki/Whitehouse.com" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="This domain is now parked, btw" border="0" height="312" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPF83To0LkE-h_T20gC2CEBLpIR4dfxmGH75xd9HAkvZV4HJLmHCVVxEqvX1r6ILEwQroJRspxA-9Tc5YM_sJw-RBp2eoN5joY5eyERcbAi-Us4e7Kao5YLmlYi-1haMOkQ2hGSskIS4Vd/s320/qm.jpg" title="Typed whitehouse.com instead of whitehouse.gov" width="320" /></a></td></tr>
</tbody></table>
<h4>
Avoiding personal embarrassment.</h4>
Life is full of surprises, some of which are terrifying rather than delightful. Fortunately Firefox has the tools to help, starting with <a href="http://support.mozilla.org/en-US/kb/private-browsing-browse-web-without-saving-info" target="_blank">Private Browsing Mode</a>. Private Browsing Mode is intended to be a temporary mode that erases data that accrues while you're in it.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUdJl0mN_GpWlQibviZJjMvWNUxjOIT4jzDKvYZQJdSX7BQ2HJIOeI60N1sCtg2rrtTWnDrJoI4eI7NWHbeKSY3HcUjFfVl6Y5ss6UD1zKlAg6OoO5GfqMbAm2TtE9dqW3Dv085k_RtMSP/s1600/pbmode.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUdJl0mN_GpWlQibviZJjMvWNUxjOIT4jzDKvYZQJdSX7BQ2HJIOeI60N1sCtg2rrtTWnDrJoI4eI7NWHbeKSY3HcUjFfVl6Y5ss6UD1zKlAg6OoO5GfqMbAm2TtE9dqW3Dv085k_RtMSP/s200/pbmode.png" width="170" /></a></div>
Firefox also has a feature to <a href="http://blog.mozilla.org/theden/2012/06/28/remove-a-single-website-from-your-firefox-history/" style="text-align: start;" target="_blank">forget a single website</a>, which will erase data associated with that site. Note that reaching "Forget About This Site" requires multiple steps (Go to the Firefox menu, select "History", then "Show all history", then navigate to the site in the Library window that you'd like to forget, then right-click, then select "Forget About This Site.")<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYdMbyMyXaFdoikt219PlkfsLO-KaZnlVfM1sGTo7lAKONI9Nxoae8KN_FSgmrLXe_Oz7g1uVwQa8JGPBcgNTHN62SSwP9OZei7EqiULlUqohxahJT6wZvfVTnkFL8d9NitnsQ0NxaWHjx/s1600/forgetaboutsite.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="303" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYdMbyMyXaFdoikt219PlkfsLO-KaZnlVfM1sGTo7lAKONI9Nxoae8KN_FSgmrLXe_Oz7g1uVwQa8JGPBcgNTHN62SSwP9OZei7EqiULlUqohxahJT6wZvfVTnkFL8d9NitnsQ0NxaWHjx/s400/forgetaboutsite.png" width="400" /></a></div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYdMbyMyXaFdoikt219PlkfsLO-KaZnlVfM1sGTo7lAKONI9Nxoae8KN_FSgmrLXe_Oz7g1uVwQa8JGPBcgNTHN62SSwP9OZei7EqiULlUqohxahJT6wZvfVTnkFL8d9NitnsQ0NxaWHjx/s1600/forgetaboutsite.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><br /></a>
<br />
<h4>
What if you forget to forget?</h4>
Like any other feature, both Private Browsing Mode and Forget This Site are easy to misuse. A person might forget to use Private Browsing mode when visiting a potentially embarrassing site, forget to clear history, or not know these features exist in the first place!<br />
<h4>
Try out Blushproof!</h4>
Fortunately, there's a better solution, <a href="https://github.com/mozilla/blushproof/wiki">Blushproof</a>! This is joint work with <a href="https://twitter.com/mozkeeler" target="_blank">David Keeler</a>, who is also responsible for implementing recent advances in <a href="https://blog.mozilla.org/security/2012/10/11/click-to-play-plugins-blocklist-style/" target="_blank">Click-to-Play</a> and <a href="https://blog.mozilla.org/security/2012/11/01/preloading-hsts/" target="_blank">HSTS</a>. The <a href="https://github.com/mozilla/blushproof/" target="_blank">source code</a> is freely available on <a href="https://github.com/mozilla/blushproof/" target="_blank">Github</a>, and you can install it by visiting the <a href="https://addons.mozilla.org/en-US/firefox/addon/blushproof/" target="_blank">Blushproof add-on page</a>.<br />
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://raw.github.com/mozilla/blushproof/master/blushproof.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" height="320" src="https://raw.github.com/mozilla/blushproof/master/blushproof.png" width="284" /></a></div>
<br />
<br />
<br />
<h4>
How it works</h4>
Blushproof helps both preventing mistakes and recovering from mistakes that might cause you to blush! Blushproof comes with a blushlist of potentially embarrassing sites and search terms, and prompts you to enter Private Browsing Mode when visiting one of those sites.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjHS-C6W734b6HIbWvO2Nsh-Jp7LXPYJJQOs0drN3lLukqckBXXssU8cfbhhpgCACZP4fBYMOGyOKAHNIAGC6RHwwavJZzpi0kkaRaket7I6utgEK53yGir_kyzjY6z4CvKs33XFFW4GL1/s1600/prompt.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="169" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjHS-C6W734b6HIbWvO2Nsh-Jp7LXPYJJQOs0drN3lLukqckBXXssU8cfbhhpgCACZP4fBYMOGyOKAHNIAGC6RHwwavJZzpi0kkaRaket7I6utgEK53yGir_kyzjY6z4CvKs33XFFW4GL1/s320/prompt.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">A potentially embarrassing search term</td></tr>
</tbody></table>
<br />
<br />
It also lets you forget about sites more easily, and add them to your own personal blushlist.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjoMBv3DGykq1t9EcRWaVHwhepD9yJrKlTGrViEfibtbzlFfDnnSeIRIif1apTMWsYKWZGPw0h1h_ZZ1lnNB8dr7x3NQtxiVboSqMOkAfEPcid2cXRhoF6iHADFa6NnvlsadT9yHojFs14/s1600/blushthis.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjoMBv3DGykq1t9EcRWaVHwhepD9yJrKlTGrViEfibtbzlFfDnnSeIRIif1apTMWsYKWZGPw0h1h_ZZ1lnNB8dr7x3NQtxiVboSqMOkAfEPcid2cXRhoF6iHADFa6NnvlsadT9yHojFs14/s1600/blushthis.png" /></a></div>
<br />
For more information about how Blushproof works, please visit the <a href="https://github.com/mozilla/blushproof/wiki">wiki</a>.<br />
<br />
Many thanks to <a href="https://github.com/gregglind" target="_blank">Gregg Lind</a> for the name, initial prototype, and ideation, and to <a href="https://twitter.com/zii" target="_blank">Zach Carter</a> for the awesome logo. Please <a href="https://addons.mozilla.org/en-US/firefox/addon/blushproof/" target="_blank">give it a whirl</a>, and <a href="https://github.com/mozilla/blushproof/issues/new">let us know</a> if you find any issues!</div>
Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com2tag:blogger.com,1999:blog-2365489364368097756.post-37537505578584874202013-03-06T11:24:00.000-08:002013-04-02T15:06:22.182-07:00Can't live with them, can't live without themPasswords have been around for approximately forever, and despised for nearly that long. However, while <a href="http://en.wikipedia.org/wiki/Multi-factor_authentication">great</a> <a href="http://support.google.com/accounts/bin/answer.py?hl=en&answer=185833">strides</a> have been made in improving password-based authentication, these improvements are not a <a href="http://www.wired.com/threatlevel/2011/03/rsa-hacked/">panacea</a>, often come with <a href="http://support.google.com/accounts/bin/answer.py?hl=en&answer=1070455">maintenance costs</a> of their own, and sometimes even serve as additional <a href="https://blog.duosecurity.com/2013/02/bypassing-googles-two-factor-authentication/">attack vectors</a>. While we should keep striving to improve authentication, it is also important to recognize that passwords are not going away any time soon, to understand the drawbacks of existing password solutions, and to try to improve them.<br />
<br />
Many of the best practices for passwords (prohibiting reuse, requiring unguessable passwords, being able to remember passwords) seem impossible without a password manager. Firefox has implemented a <a href="http://support.mozilla.org/en-US/kb/password-manager-remember-delete-change-passwords">password manager</a> since inception. The built-in password manager detects the presence of login form and prompts the user to store the password via a notification.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://support.cdn.mozilla.net/media/uploads/gallery/images/2011-07-21-11-52-06-25f9d9.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="203" src="http://support.cdn.mozilla.net/media/uploads/gallery/images/2011-07-21-11-52-06-25f9d9.png" width="320" /></a></div>
We use data from the same Test Pilot study as in <a href="http://monica-at-mozilla.blogspot.com/2013/02/writing-for-98.html">the last post</a>, this time focusing on password statistics. Approximately 5.5% of users have disabled the password manager, which is enabled by default. However, are the remaining 94.5% of users actually using the password manager with intent?<br />
<br />
To answer this question, let's first examine the number of users who have stored at least one password in the password manager (as obtained by querying <span style="font-family: Courier New, Courier, monospace;">nsILoginManager </span><span style="font-family: inherit;">for all logins). The graph below shows the distribution of the the number of passwords stored in password manager for users who have no more than 30 passwords. This graph represents 96% of the nearly 12K users in the study.</span><br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhhmIJWzl0s5rftFJJDGtDkOT9zcVFsmYzfZQKmzn3irpxy_y64YP2Yb9BKha6M5B6f5tPoxO91B5zqIzXVF70V8kVuR9cVPDnvikjPqEs5DvaGjKdvmRSM_NJPbd4zwc1j6LjrZ2garCZ/s1600/password_distribution.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhhmIJWzl0s5rftFJJDGtDkOT9zcVFsmYzfZQKmzn3irpxy_y64YP2Yb9BKha6M5B6f5tPoxO91B5zqIzXVF70V8kVuR9cVPDnvikjPqEs5DvaGjKdvmRSM_NJPbd4zwc1j6LjrZ2garCZ/s1600/password_distribution.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="text-align: start;">
<span style="font-family: inherit;">The graph above shows 73.4% of users store at least one password in the password manager, but it's not clear at all that this is not accidental use: after all, 13.9% of users store only a single password, and it is doubtful that a password manager is necessary or beneficial in the single password case. We can also take a look at the distribution of the number of sites stored in the password manager, for users who have no more than 30 sites stored. </span></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9N_O6U7jwcf18CUArpIr9VGjD79u2aFWo5c7embgbLSszaeOVDOUYUKIJZVU064aSiiSq7ovaxIpWvyn0Hsq1xqxOL5p0WZh1GZ6vEaHxDABspoPQ0jQtvFcodYO6Ma3ERUTAWZL-YSE_/s1600/site_distribution.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9N_O6U7jwcf18CUArpIr9VGjD79u2aFWo5c7embgbLSszaeOVDOUYUKIJZVU064aSiiSq7ovaxIpWvyn0Hsq1xqxOL5p0WZh1GZ6vEaHxDABspoPQ0jQtvFcodYO6Ma3ERUTAWZL-YSE_/s1600/site_distribution.png" /></a></div>
<br />
<span style="font-family: inherit;">Interestingly, the site distribution has a slightly longer tail than the password distribution, so this graph represents only 89% of users. The shape of the graph is very similar, however, and lends credence to the hypothesis that much of the information stored in the password manager represents accidental use, if we believe that the password manager is not beneficial in the case of a single site.</span><br />
<br />
<span style="font-family: inherit;">Because this study did not collect how frequently the password manager triggered on login forms, we can't definitively conclude that users storing only one password represents accidental use. Alternative explanations, ranked in order of increasing possibility according to my personal prejudice:</span><br />
<ol>
<li><span style="font-family: inherit;">I only use this browser for work and I don't care about my work password.</span></li>
<li><span style="font-family: inherit;">I have a secure, memorizable password scheme but can't remember the requirements for this one site.</span></li>
<li><span style="font-family: inherit;">I only have one main password but it doesn't meet this one site's requirements.</span></li>
</ol>
Does this data hint at anything interesting about password reuse? Let's examine mean number of passwords stored versus the number of sites.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsawHS2EfxXmbxip4yaQJ0wke1YoY5tBxA_gEvPHKo-26tL8m-bsjWwX8Zqj1nbxJlYNjdIj0t42WU60gUjPdiEEui9R2Y-MYUjBJT_if-VLN8bhP6GQoaBV4Yq7dpqdHawEdghpi4pUO2/s1600/passwords_per_site.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="293" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsawHS2EfxXmbxip4yaQJ0wke1YoY5tBxA_gEvPHKo-26tL8m-bsjWwX8Zqj1nbxJlYNjdIj0t42WU60gUjPdiEEui9R2Y-MYUjBJT_if-VLN8bhP6GQoaBV4Yq7dpqdHawEdghpi4pUO2/s400/passwords_per_site.png" width="400" /></a></div>
This graph represents 97.5% of users and omits 43 outliers who have more than 100 passwords stored. The vertical error bars represent the standard deviation from the mean. This graph falls far south of <span style="font-family: Courier New, Courier, monospace;">x=y</span>, the ideal case of storing one password per site. So we can conclude that even while using a password manager, people still reuse passwords across sites.<br />
<br />
This level of reuse is not necessarily due to user choice. For example, subdomains on the same intranet frequently require the same password, due to LDAP linkage. This in itself is not a security problem if the security guarantees are identical across subdomains. However, it is a problem when those intranets outsource services to outside vendors through LDAP, requiring password reuse at external parties. Note to future study authors: please include counts for effective TLDs in addition to domains in order to account for this case.<br />
<br />
In summary, it seems that even though 94.5% percent of people have the password manager enabled, far fewer users gain any benefit from the password manager. Over the years I have heard the following arguments against using password managers:<br />
<ul>
<li>I only use one password so I don't need one.</li>
<li>They don't work across all my devices.</li>
<li>They don't work across all my browsers.</li>
<li>I don't trust local password managers against local attacks.</li>
<li>I don't trust cloud password managers because I don't trust third parties.</li>
</ul>
<div>
The first argument is especially egregious, considering the combined forces of account hijacking, phishing, and password database hacks. The second two arguments can't be solved with a local password manager, or even a browser-specific password manager. The fourth argument can be solved somewhat with master password, but only 1 out of 12K users had master password enabled (<span style="font-family: Courier New, Courier, monospace;">security.ask_for_password</span> in <span style="font-family: Courier New, Courier, monospace;">about:config</span>), so either that feature is undiscoverable, unusable, or <a href="http://securityxploded.com/firemaster.php">regarded as too insecure to be effective</a>. It is clear from the data that not enough people take advantage of password managers. I look forward to further progress from the <a href="https://wiki.mozilla.org/Identity/AttachedServices">identity team</a> to solve some of these issues.<br />
<br />
Many thanks to <a href="http://connectioni.st/">Paul Sawaya</a> and <a href="https://blog.mozilla.org/tanvi/">Tanvi Vyas</a> for advice on this post, and to Paul for writing the code to capture password manager statistics. </div>
<br />
<br />Monicahttp://www.blogger.com/profile/12258842422801876253noreply@blogger.com11tag:blogger.com,1999:blog-2365489364368097756.post-20121849155699354182013-02-21T10:05:00.000-08:002013-04-02T15:06:22.181-07:00Writing for the 98%How often do users change their default preferences? According to <a href="http://www.uie.com/brainsparks/2011/09/14/do-users-change-their-settings/">one 2011 study</a> of MS Word users, users rarely do. One could conclude from this that users never change their defaults, and so having user-mutable preferences at all is a waste of effort.<br />
<br />
However, this view is reductive! To illustrate, compare the risk of having unintended MS Word settings with having unintended Facebook settings. Both applications will probably continue to function, but one is much more likely to surprise and dismay the user. Thus, users are more highly motivated to change social network settings than editor settings. In fact, according to <a href="http://www.pewinternet.org/~/media//Files/Reports/2010/PIP_Reputation_Management_with_topline.pdf">Pew</a>, 71% of people under 30 self-report changing their social network settings (and 55% of those over 50 do). Perhaps the lesson here isn't that users never change defaults, but rather that users change defaults when it's important enough for them to do so.<br />
<br />
It's not always clear what the default for any given preference or feature should be. When the vast majority of users clearly express a preference for one default over another, then the question is easy. When the split is less one-sided, then choosing a default preference can be fraught. This is particularly true when a substantial minority of users are operating under a drastically different risk model. It is hard for one default set of security and privacy preferences to meet the needs of a heterogeneous user base where one person is concerned about invasive network attacks, and one person is concerned about shoulder-surfing.<br />
<br />
Which security and privacy preferences are compelling enough for Firefox users to change? Back in December Ilana Segall from <a href="https://testpilot.mozillalabs.com/">Test Pilot</a> team ran a study measuring those preferences that are exposed in <span style="font-family: Courier New, Courier, monospace;">about:config</span> and also in the UI. The population for this study is approximately 12000 users who are on the Aurora and Beta channels, and a relatively small number of users who have opted-in by installing Test Pilot on the release channel. In other words, this population is <i>not</i> representative of the Firefox user base, since nearly all Firefox users are on the release channel. In fact, the Test Pilot population is probably much more likely to change settings in general, since they are passionate enough to test Firefox pre-release.<br />
<br />
<br />
The dates of data collection were from approximately 12/18/2012 for approximately a week, and includes nearly 12000 users. Here's a series of snapshots of the current preferences UI with no changes to default. The preference as named in <span style="font-family: Courier New, Courier, monospace;">about:config</span> is listed on the left, along with the percent of users who changed them.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHGDd76NqHpdTB9OS7328aYYh4mk-xyPhiO-tfij2DbOtpIA2Dg9rgP_Uib8MvBDRddCVIlWDVPIdX6V87qLyLap-dxtwqPZVXIBjcqRX1V4buH8WyF-zxExHirYe5PXZq1AttF9CdYFxq/s1600/security-prefs-annot-cropped.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="248" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHGDd76NqHpdTB9OS7328aYYh4mk-xyPhiO-tfij2DbOtpIA2Dg9rgP_Uib8MvBDRddCVIlWDVPIdX6V87qLyLap-dxtwqPZVXIBjcqRX1V4buH8WyF-zxExHirYe5PXZq1AttF9CdYFxq/s640/security-prefs-annot-cropped.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="" style="clear: both; text-align: left;">
Obviously, no one touches the default security settings very much. There are at least three plausible, possibly-overlapping interpretations: Firefox predicted the most useful default settings correctly, Firefox is doing a poor job converting user actions into saved preferences, or the population who cares about browser security preferences is really that small. The most frequently changed preference on this tab, <span style="font-family: Courier New, Courier, monospace;">signon.rememberSignons</span>, controls whether or not Firefox prompts the user to remember passwords. The question of when or why people use the password manager is complex and I'll save it for a later discussion. It is also interesting that fewer people disable Google SafeBrowsing checks for malware than for phishing (<span style="font-family: Courier New, Courier, monospace;">browser.safebrowsing.enabled</span> and <span style="font-family: Courier New, Courier, monospace;">browser.safebrowsing.malware.enabled</span>). Presumably these are disabled for <a href="http://blog.sidstamm.com/2012/02/malware-and-phishing-protection-in.html">privacy</a> or <a href="http://www.morbo.org/2012/02/new-safebrowsing-backend.html">performance</a> reasons. Are users who disable one and not the other making a mistake, or do these users consider themselves phish-proof but not drive-by-download-proof? If it is a mistake, why do we allow users to construct a set of preferences that are internally inconsistent in reasoning?</div>
<div class="" style="clear: both; text-align: left;">
<br /></div>
The privacy preferences tab is more complicated than the security preferences tab.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1vIbdj3L3vCGLazytxUzG_z1JZb4Ygocp18q8svuDm752go2eEgoFdbe7CremfBC5vQHh5OlRqPW48UV00CAFUUIO8m27sdS7gT9TwyP8hHhnyU2HyjVW7WvYN4R6-nQiHbi19Yfib1oy/s1600/history-dropdown.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="371" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1vIbdj3L3vCGLazytxUzG_z1JZb4Ygocp18q8svuDm752go2eEgoFdbe7CremfBC5vQHh5OlRqPW48UV00CAFUUIO8m27sdS7gT9TwyP8hHhnyU2HyjVW7WvYN4R6-nQiHbi19Yfib1oy/s400/history-dropdown.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
A whopping 11.3% of users enabled Do Not Track (<span style="font-family: Courier New, Courier, monospace;">privacy.donottrackheader.enabled</span>). This is an astonishingly high number of users to enable an HTTP header that broadcasts user intent, but is unable to enforce anything client-side. It is a testament to DNT advocates that adoption is this high, but even though this preference is changed by a large minority of users, <a href="https://blog.mozilla.org/privacy/2011/11/09/dnt-cannot-be-default/">Firefox should not enable it by default</a>.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
A more modest number of users (1.2%) change the autocomplete settings of the location bar (<span style="font-family: Courier New, Courier, monospace;">browser.urlbar.autocomplete.enabled</span>) to use a smaller subset of "History and Bookmarks", 1.5% of users have completely disabled browser history (<span style="font-family: Courier New, Courier, monospace;">places.history.enabled</span>), and 2.75% of users use custom history settings (<span style="font-family: Courier New, Courier, monospace;">privacy.sanitize.sanitizeOnShutdown</span>). The custom history settings are even more complicated:</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjUKkWOmVKthoqhi6kdyO5H3tkfd6cLONcmaHhThaVQcFxhS3jSVXub97CoavioDE-QgcjNGnLDA5xoBuDPWNdnvvvRVy4v_Vm_kMzCI2M14RAuNd-YlwczpdizviGFGXripzi9CCYL5w05/s1600/custom-history.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="297" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjUKkWOmVKthoqhi6kdyO5H3tkfd6cLONcmaHhThaVQcFxhS3jSVXub97CoavioDE-QgcjNGnLDA5xoBuDPWNdnvvvRVy4v_Vm_kMzCI2M14RAuNd-YlwczpdizviGFGXripzi9CCYL5w05/s320/custom-history.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
An astute reader will have noticed that there are already two ways to autostart in private browsing mode: using <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1vIbdj3L3vCGLazytxUzG_z1JZb4Ygocp18q8svuDm752go2eEgoFdbe7CremfBC5vQHh5OlRqPW48UV00CAFUUIO8m27sdS7gT9TwyP8hHhnyU2HyjVW7WvYN4R6-nQiHbi19Yfib1oy/s1600/history-dropdown.png">"Never remember history"</a> and checking "Always use private browsing mode" in the screenshot above which automatically disables browsing, download, search and form history. Approximately 5% of users always use private browsing mode (<span style="font-family: Courier New, Courier, monospace;">browser.privatebrowsing.autostart</span>). 0.83% of users have modified their cookie settings to be something other than "Accept all cookies," including 7 hardcore users who don't accept cookies at all. One intriguing explanation is that more users are concerned with local attacks (shoulder-surfing or accidental disclosure on shared devices, by people that they know) than remote attacks.</div>
<br />
It is troubling that there are two sets of parallel preferences named <span style="font-family: Courier New, Courier, monospace;">privacy.cpd</span> (short for clear private data) and <span style="font-family: Courier New, Courier, monospace;">privacy.clearOnShutdown </span><span style="font-family: inherit;">that control custom history settings. Both appear to be used in the same way in the code, but Firefox allows users to enter an internally inconsistent states by maintaining multiple sets of preferences for the same functionality.</span><br />
<br />
Finally let's take a look at the "Encryption" settings under the Advanced preferences tab.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT28rj9fqIXSuaTemVDUTjYpML5Gy-TJdY2-32m5eHaqhlnvYvCHOAmmnk1WU_f6WIMw6d9aQZttWsx8LQeMNeU64ycTHgGjXelGRQJXIonqcSy6QGSLwg5s6Who12ZWm5dyOvevmaH2m0/s1600/advanced-prefs.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="297" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT28rj9fqIXSuaTemVDUTjYpML5Gy-TJdY2-32m5eHaqhlnvYvCHOAmmnk1WU_f6WIMw6d9aQZttWsx8LQeMNeU64ycTHgGjXelGRQJXIonqcSy6QGSLwg5s6Who12ZWm5dyOvevmaH2m0/s320/advanced-prefs.png" width="320" /></a></div>
Unsurprisingly, users touch this panel least of all. 0.02% have disabled SSL 3.0 (<span style="font-family: Courier New, Courier, monospace;">security.enable_ssl3</span>), 1.6% have disabled TLS 1.0 (<span style="font-family: Courier New, Courier, monospace;">security.enable_tls</span>), and 1.0% of users have opted to automatically select a personal certificate (<span style="font-family: Courier New, Courier, monospace;">security.default_personal_cert</span>). Is it really worth having a preference panel that benefits fewer than 2% of users overall?<br />
<br />
Similarly with the Online Certificate Status Protocol preferences:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyksc1QXF83TH6SkR04xrnUtwfNG5eCnZAHJZZKWolfobxRKV_Ao9l1mpovuN1GBDvDbtj25ddLYd_oDOaMZNPuDMGVImKXnKYtmkCm8gYhvelKhztqCS9GmmxUNaSaZAWpe2blx0wRPKY/s1600/ocsp.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="62" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyksc1QXF83TH6SkR04xrnUtwfNG5eCnZAHJZZKWolfobxRKV_Ao9l1mpovuN1GBDvDbtj25ddLYd_oDOaMZNPuDMGVImKXnKYtmkCm8gYhvelKhztqCS9GmmxUNaSaZAWpe2blx0wRPKY/s320/ocsp.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
1.75% of users have disabled OCSP (<span style="font-family: Courier New, Courier, monospace;">security.OCSP.enabled</span>), and 0.03% of users require it (<span style="font-family: Courier New, Courier, monospace;">security.OCSP.require</span>). Without knowing anything about OCSP other than its name and a few <a href="https://threatpost.com/en_us/blogs/what-you-need-know-about-diginotar-hack-090211">recent</a> <a href="http://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ssl-certificate-fiasco-what-happened-and-what-happens-next/">stories</a> about certificate authorities, a reasonable person might conclude that requiring OCSP by default is a good thing. I am guessing that enabling it by default breaks in some cases. However, with so few people requiring OCSP no one is likely to gather enough implementation experience to require OCSP by default for everyone.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
For fun I also measured <span style="font-family: Courier New, Courier, monospace;">browser.default.searchenginename</span><span style="font-family: inherit;">, the preference that controls which search engine to use when the string in the location bar is not a URL. This preference probably has the most impact on privacy besides the preferences exposed in the privacy panel. Interestingly, it is modified 43.7% of the time (from</span><span style="font-family: Courier New, Courier, monospace;"> chrome://browser-region/locale/region.properties</span><span style="font-family: inherit;">, which is how complex preferences get set). The topmost occurring replacements include <a href="https://www.google.com/search?q=ask+firefox+search">Ask</a>, <a href="http://www.bing.com/search?q=babylon+firefox+search">Babylon</a>, and <a href="http://search.yahoo.com/search?p=avg+firefox+search">AVG</a>, all of which produce interesting search results when combined with "firefox search" on various search providers. One might question if actual user intent underlies changing such an inaccessible preference so frequently, and if not, what to do about it. That, too is a topic that deserves further discussion.</span></div>
<br />
I'll close with a few open questions for the reader:<br />
<ul>
<li>Is there a better way to choose default preferences when a large minority of users expresses a different opinion (e.g., DNT)?</li>
<li>Is it worth the engineering effort, UX effort, and screen real estate to make user-visible (to say nothing of discoverable) preferences if fewer than 2% of users benefit?</li>
<li>How can we use use this data to make Firefox better?</li>
</ul>
<div>
Thanks for reading!</div>
Monica Chewhttp://www.blogger.com/profile/05283712618776541812noreply@blogger.com12