Modern web-browsers support all sorts of add-ons and plugins. From a privacy perspective, this means you can block adverts and trackers, use tools like GoogleSharing and other request re-directors. However, mobile devices typically don't have the same extensibility. While searching for a way to implement this, I came up with using proxy.pac as a way to do some more advanced network jiggery pokery, without requiring platform specifics (i.e. should work on iOS, Android or even Firefox & Chrome), or the need to jailbreak.

Apple responded to the location logging stuff with a Q&A aimed at dispelling some of they myths all the hype has created. The only problem is, they try to dispel some of the facts too.

After several days of trying all the different solutions proposed as the story has emerged, I think I've finally got a solution that is both usable (i.e. doesn't break anything) and permanent (i.e. apply once and let dry).

My original suggestion of rubbish values + read-only didn't work, untrackerd takes up valuable memory & battery and misses nearly all the worrying data & the SQL triggers file from Tehtri also missed some data and breaks some functionality (most notably the compass). 

Update 3: I've modded Tehtri's approach and it appears to be working nicely, read this post. 

Update 2: untrackerd seems to clear out two tables only, and not the most worrying tables either (at least in my file). After 2 days of use, it didn't change a single entry in my consolidated.db (I was using v0.2). So I've ditched it. However, the guys from Tehtri Security, posted a leet idea to Full Disclosure of using triggers (I had no idea SQLite3 could do triggers). The triggers ensure that the relevant tables get auto-truncated when written to. You can download this SQL file, and apply it to consolidated.db with the command (assuming it's in the same directory):

sqlite3 consolidated.db '.read tehtris-iphone-privacy.sql'

I've checked and applied the triggers, and they seem to be functioning (I watched the file shrink as loc data was written), and location services are working. So far so good. You can either use the backup & restore method discussed below, or if jailbroken, you can scp the file off the device, apply the change and scp back, or install sqlite3 via Cydia and do it on the device.

Update 1 - Warning: This breaks location services. I didn't notice because I spoof my location to a bunch of apps, whoops. The specific aspect that breaks location services appears to be the use of the stub consolidated.db file. The read-only permission flags get ignored on an otherwise "correct" file. You can delete the file regularly and it won't cause any problems however. There is a jailbroken application, untrackerd, which will run a daemon to do it for you. When I get a chance, I'd like to extend the SBSettings GPS switch to delete the file too (i.e. delete consolidated.db on GPS switch on).

Yesterday, Pete Warden and Alasdair Allen released some research and a tool that showed that Apple has been collecting detailed location data since v4 of iOS in a file called consolidated.db. Apart from the worry of wtf Apple is collecting such detailed information, this file is available in the clear in all your iTunes backups, meaning any application on your computer can access it if you haven't encrypted your backups. To demonstrate that, Pete and Alasdair released a demo app that gives a scary amount of detail about your movements.

Firefox 4 implemented the Do Not Track header. This is an option, sent via an HTTP header, to specify to a webserver that the user would like to opt-out of advertising/behavioural tracking. The news came in soon after that the AP News Registry service had implemented support for DNT. So I decided to have a quick look at what this meant. It ended up highlighting why I think DNT will never be a solution by itself, and why it's intended use may even be tenuous.

This is a quick note, partially for my own purposes of memory, of an idea. I tried to hit a GoToMeeting page earlier today. I didn't need to log on, just needed some basic information. The problem was it has one of those irritating cookie detector pages. Essentially, even though it doesn't need to set a cookie, it tries to, and if it can't, redirects you to "Sorry, you don't have cookies enabled."

In those situations, you need to allow the site to set a cookie, and then remove the cookie afterwards. Add-ons like CookieSafe let you use "Temporary Permissions" but those are set for much longer than a single page request. So you end up with an unnecessary cookie, potentially used for tracking that you don't need.

The cookies it sets are:

Set-Cookie: g2mVisitor=FirstVisit%3D1299181701998%26LastVisit%3D1299185151317%26RSN%3DDEFAULT; g2mSession=SessionInfo%3D200000000028062301%253A41EA01704E81824; JSESSIONID=abcldXoZn-6ZjaEQ4q95s

What I tried, was to send a fake Cookie: header, with all three of the cookie names it was looking for, but with blank values for each. It worked perfectly. They looked like:

Cookie: g2mVisitor=; g2mSession=; JSESSIONID=

My suggestion then is that CookieManagers provide a "Stub Cookie" option, where a site that wants cookies, but doesn't need them, can think it has set the cookies, but in truth just be getting blank values. It's a quick change that should have minimal impact. I had a quick look at CookieSafe's code (I can't seem to find any contact details for the author), and I'm hoping it's as easy to implement as it looks.

Time, time, time...

GoogleSharing is something I've written about before, and strongly believe in. It's a way of proxying connections to unauthenticated Google services in such a way that:

• Google can't work out who you are (random session cookies are used)
  
• Google can't work out that you're using a proxy
• The proxy can't see your searches (if using SSL)

However, right now it only runs in Firefox. While there are some people looking to port it to other browsers, there are some options available in the meantime, especially for mobile browsers.

UPDATE: An iPhone developer has turned this into an awesome little SBSetting addon. You'll still need a jailbroken phone but can install it via Cydia.

My previous experiments in killing the Evercookie in Safari sparked similar posts describing how to do the same for Chrome and Firefox. However, my second most frequent browsing platform is my iPhone, and I thought I would investigate how Apple IOS, MobileSafari & embedded WebKit fares. It does much worse. There are two problems; the first is, any app which embeds MobileWebKit has it's own stores for normal cookies, browser cache and HTML5 storage. Even if you go to your Safari settings (Settings -> Safari -> Clear {Cookies|Cache} & Settings -> Safari -> Databases -> Edit -> (delete all present) ) and delete everything, you haven't cleared the cookies, caches & stores in the other apps (e.g. even a simple cookie set for singe.za.net in Twitter.app's embedded browser, will still exist). The second problem is that, in MobileSafari, even if you do clear your MobileSafari store, the HTML5 localStorage mechanism isn't properly cleared and the evercookie reloads itself.

(Hi Slashdot & The Register readers. Make sure to check the 2nd part on killing iPhone Evercookie's too)

Samy Kamar recently released his tool, evercookie. This uses multiple persistent data stores to set unique identifiers that can be used to identify your browser to a website. While my default Firefox browsing setup is safe against it, I noticed that the "disposable" Safari instance I used was not. I sometimes use a clean Safari instance to test or access things the tinfoil on my Firefox does not let me. After each use I reset everything in it. However, I noticed that evercookie would persist. Here's how to delete it and others using the same mechanisms for Safari on OSX 10.6 (working out the same for other browsers/OS' isn't too difficult):

I'll be speaking at IS' Internetix 2010 conference and this was originally posted there. I was asked to put a blog post together as a teaser for my talk.

Privacy is dead, or so the common wisdom says. But that can't be true. Centuries of philosophy tell us that it's vital for our development and existence as human beings. As a trite example, try imagine having a truly intimate conversation with your partner while knowing someone else was listening. But that's not what I want to talk about here. If you want to have that conversation, start with this paper.

Paul Rubin had a piece in the Wall Street Journal describing 10 fallacies of Web Privacy. This is my response, and the start of my blogs official "privacy" category.

This is a cross-post from my other blogging home at SensePost.

Last week we presented an invited talk at the ISSA conference on the topic of online privacy (embedded below, click through to SlideShare for the original PDF.)

The talk is an introductory overview of Privacy from a Security perspective and was prompted by discussions between security & privacy people along the line of "Isn't Privacy just directed Security? Privacy is to private info what PCI is to card info?" It was further prompted by discussion with Joe the Plumber along the lines of "Privacy is dead!"

The talk, is unfortunately best delivered as a talk, and not as standalone slides, so here's some commentary:

Scroogle is no longer working for the second time this year (I archived the announcement at the end of this entry). The author claims Google deliberately killed the simple interface they were using. I've e-mailed to point out that Google Custom search works fine, but relying on Scroogle isn't going to cut it anymore. The obvious solution is to use GoogleSharing. However, not all devices support it due to the requirement of a Firefox plugin; my phone for example. After meeting Moxie I discussed the idea of including a search interface with the GoogleSharing server. The idea would be that <googlesharing server>:<port>/search would provide a plain HTTP interface to search through the server.

For years I've had a tinfoil dilemma. I know that companies trying to own the internet love dropping cookies, and then using those cookies to track you around the tubes. It started with the advertisers like DoubleClick who would drop their cookie, then rely on their distribution of banner ads. Every time your browser hit a page with one of their banner ads, it would send it's cookie along and help them track you around the internet.

This week something special happened, something I'd been saving for the right person, something magical. Today, hackers took my private data. Everything's changed, I feel like a part of the world, connected to so many other people who have shared in this experience. Today, I'm a woman! (Ok, I may have gone a bit far with that last bit)

The skinny is that I use unique e-mail addresses for each service provider that I want to continue communicating with (for the ones I don't I use one-shot addresses). I noticed on the weekend that I was being deluged with pharmaceutical spam to three of these addresses, namely my Threadsy, Numbuzz & Share-it (via a product I bought there, ChatterBlocker) contacts. This lead me to tweet: "Either a security or ethics breach at @threadsy & @nimbuzz Getting Viagra spammed hard on the unique e-mail addresses I gave them."