Wednesday, November 10, 2010

Google Chrome & the Nirvana of Anonymous Browsing

There are numerous strategies and tools that savvy users employ to protect their personal information while browsing. But for most regular folk, browser add-ons and similar extra setups are just too complicated or too much hassle (if they think about it at all). This is why the best solutions are those in the standard browser install. Despite inherent conflicts of interest (virtually all major browser makers are at least partially funded by ad networks), we do see some nice evolutionary improvements in browser privacy controls.

The latest, in the Google Chrome dev channel, is a new setting called 'Click to Play' which keeps plug-ins on web pages disabled until you click on an object that needs the plug-in started. Since I like to keep Chrome on the Stable or Beta channels, I'm using Chromium for this test:


As discussed previously, this has both privacy and performance advantages (particularly on mobile and portable devices).

To enable Click to Play, navigate to Chrome/Chromium Preferences > Under the Hood > Content Settings > Plug-ins > Click to Play, and check the box.

Click to Play doesn't solve all privacy problems, but in addition to improving performance, it does reduce the number of cookies (of several varieties) that sites place on your device and (in conjunction with other basic defenses) reduce the overall trackability of your casual surfing behavior.

Aside from cookies, Click to Play has another limited benefit: reducing browser entropy (the uniqueness of the signature that your browser presents to web servers).




Without Click to Play enabled, my system emits a completely unique browser signature:


With Click to Play enabled, my fingerprint entropy drops by several bits. The key areas that typically compromise the most uniqueness are User Agent, Browser Plugin Details, and System Fonts. The Chromium User Agent tends to be pretty unique, but even Firefox and the other major browsers have many variations. Click to Play doesn't block native plugins, so there is some unavoidable entropy there, but Click to Play does significantly reduce the entropy presented by System Fonts, since fonts are detected via Flash and/or Java (turning off Java and using a Flash blocker will achieve a comparable result).

Most users have no idea how much information about them and their systems get compromised to web servers every day... collected, stored, aggregated, used, and abused. Good persistent storage (e.g., cookie) controls are just the beginning. Chrome does provide a number of powerful Content Settings, but defaults matter. A lot.

My recommendations to all browser makers to regain the trust of users in the present privacy-challenged environment are:
  • Improve basic cookie controls to include all forms of persistent storage. Block all 3rd-party storage by default. Allow whitelists for opt-in persistence.
  • Implement more aggressive persistence management to thwart "evercookies".
  • Reduce browser entropy with simplified User Agent signatures.
  • In conjunction with reputable ad networks, implement Do Not Track HTTP headers.

The web desperately needs more trust, and better support for individual privacy. It probably won't get there without regulation, but there's a slim chance if prominent industry players move past traditional approaches and meaningless "opt out" regimes.

Tuesday, October 5, 2010

What's up with Apple's iAd Opt-Out?


Apple has historically been a good steward of user privacy, but several recent changes have brought that perception into question:
  • Apple's entry and rapid dominance as a mobile ad network (the subject of this post)
  • Apple's handling of geolocation & app access to private data (the subject of a future post)
Let's set aside for the moment that opting out of Apple's iAds only opts you out of "interest-based ads" and doesn't actually opt you out of receiving ads or having your personal information collected and stored. 

The problems are: the opt-out function doesn't work, and how it's supposed to work is quite opaque.

Apple's support document, "How to opt out of interest-based ads from the iAd network" (Last Modified: June 21, 2010) states that "you can opt out by accessing the following link on your iOS 4 mobile device: http://oo.apple.com".

 Well, apparently not:


The screencap above was obtained by visiting the opt-out URL (which I have bookmarked), right after clearing all cookies, cache, history, and databases, on my iOS 4.1 iPhone. Just in case, I try again by clicking the link directly on the page. No dice, now Apple doesn't even think I'm running an iOS device:


Well, let's see if the desktop can shed any light on the issue. In Safari 5.0.2 (OS X 10.6.4), let's set the User Agent to Mobile Safari 4.0.2 - iPhone, again after clearing all cookies, cache, history, and databases:


And again, no dice:


Now, I do have my Safari preferences set to prompt me before allowing storage of any HTML5 databases (a control that doesn't exist on iOS devices):


But no such prompt was forthcoming.

So, iAds opt-out is broken. But more important are these questions:
  • How does the Apple web site determine whether you are running iOS?
  • How does Apple implement the iAds opt-out?
It can't be IP address since any iOS device could be using wi-fi to connect to the internet. It's something beyond User Agent. It's apparently something beyond cookies. It's apparently even something beyond HTML5 database storage.

Both the failure and the opaqueness of the process are disturbing.

Thursday, August 26, 2010

Gmail, Google Talk, Google Voice, and iPhone (Oh My)

As everyone knows by now, starting today Gmail supports outbound and inbound voice phone calls through the Google Talk Chat gadget:


Not widely discussed is that now the Google Voice web interface can also present Google Talk as one of the originating phones:


However, the Google Voice web interface on the iPhone is a bit quirky (don't even get me started on the lack of a native app). It still has the unintuitive lack of feedback when selecting the originating phone.


And now, even though Google Talk is presented as a choice, the call is still routed through the normal iPhone method (a dialog to allow a standard voice phone call to an intermediate local number). Not unexpected for experienced GV users, but the web interface adds some confusion.

Hopefully Google will take a look and tweak the user experience to be a little friendlier.

Wednesday, August 25, 2010

Facebook SMS & iPhone Notifications

Dear Facebook,

Since you won't let me use my Google Voice phone number for SMS notifications (why not?)...


...please add a column in the Facebook Notification settings to allow me to customize push notifications that would be sent to the iPhone app.

Sincerely,
Facebook User #010001110110111101101111011001110110110001100101

P.S. Oh, also... the whole notification scheme on the Facebook iPhone app is wonky. Please fix.

Tuesday, August 10, 2010

Google Voice needs Short Code support

Dear @GoogleVoice,

Please support Short Codes so I actually can "Use one number to manage all your phones".


It would be really nice to incorporate Twitter and other services that use Short Codes into my Google Voice experience.


Sincerely,
Worker 11811