Showing posts with label privacy. Show all posts
Showing posts with label privacy. Show all posts

Monday, October 17, 2011

Location Sensitive Posts: Do It Right, Or Don't Do It At All

When I posted that, I was at home. I live in Wandsworth (post code: SW18) in London; Camden (post code: N1) is 8 miles away according to Google Maps. To be very clear, I was nowhere near Camden at the time I posted that. (at least not as a Londoner would know it).

On my way home from work, Facebook somehow decided in a different post that I was in South Kensington (post code: SW7), even though I never crossed the river, going straight from OpenGamma HQ to Wandsworth and staying the entire time south of the river.

This is a problem.

No, You Can't Turn It Off

I'm running an iPhone 4S with iOS 5 running the most recent Facebook iOS update. Everything is as far up to date as you can possibly get.

I've tried to turn off location-sensitive Facebook updates. I've tried under Settings/Facebook. I've tried in the Facebook application. There appears to be no way that I (an otherwise relatively computer savvy individual) can figure out to turn it off.

Twitter lets you geo-encode a tweet. You can turn it on, you can turn it off. You can change your defaults and change a particular tweet (usually I tweet geo-encoded off, sometimes I turn it on for a location-sensitive post). You can take a look at where Twitter thinks you are, and if it's off, you can turn it off again. There's no such option for Facebook.

Why This Matters

In London, a distance of 8 miles is the other end of town. It's so far given our geography that it beggars the mind that if I claimed that I was at home, but some computer verified me as being in Camden, that this would not be an acceptable fudge the way that a distinction like Southwark/Lambeth, or Westminster/Kensington might be. I might as well be in Paris.

What I've noticed is that as geo-location gets better and better, people start assuming that the technology must be correct. Part of this is surely the CSI-culture that Hollywood has given us, telling us that computers are never infallible, and that all answers are on the other end of an infallible evidentiary chain. But part of this is that these days people probably do lie more than computers.

Which is why I'm so annoyed at Facebook's failures in this respect. If I tell someone (a friend; a family member; my significant other) that I'm at home watching Glee, and they see a Facebook update that says that I'm in Camden, one of the following will happen:

  • They will think I'm lying and am actually at an Amy Winehouse memorial concert;
  • They will think I'm probably telling the truth, but in the back of their mind think I might be lying and am shopping for Doc Martins;
  • They will 100% know that I'm telling the truth, and immediately blame Facebook's bad software engineering.

Which do you think is the most likely?

Worse off, imagine that we're talking about something where there are Serious Stakes on the line: a divorce ("you claim you were home watching Glee but your phone claims you were in Camden visiting your mistress"); a criminal trial ("you claim you were home watching Glee but your phone claims you were stabbing someone to death in Camden"); a terrorist investigation ("you claim you were home watching Glee but your phone claims you were making a bomb in Camden"). As technology advances, can you even doubt one of those will happen on a regular basis? Do you think the people evaluating the technology are going to ask things like "how accurate was the GPS receiver?" or "how was the coordinate-to-placename database compiled?"

We Owe It To The Humans

As a software engineer, please let me ask for the following code of conduct to prevail:

  • If you enable location-aware anything, make it obvious to turn it off, both as a default, and as a one-off action, before and after the location is determined;
  • Never imply more sensitivity than your entire system (hardware, software, and databases) are capable of;
  • Until and unless you have run your location system past a local in a particular region, don't enable it.

If we all follow these three maxims, we'll not repeat Facebook iOS's current failures putting me in Camden against my will.

Monday, November 03, 2008

SSL For Self-Signed Bad For The Internet?

In an article (originally posted as a blog entry, then archived as a web page), Nat Tuck complains that Mozilla's behavior on self-signed SSL certificates is bad, because it stops people from using encryption where they don't care about the possibility of a MITM attack. I think he's mostly wrong.

The big reason why I think he's wrong is that I think the default behavior is correct: the vast majority of people don't understand the complexities of a Man-In-The-Middle attack and how that can affect any self-signed certificate. However, I totally understand his desire for more encryption.

I'm pretty annoyed at the fact that at the moment, I'm pretty sure that all non-encrypted traffic on the internet is being logged and scanned at some level by multiple governments. I don't like that at all. Encryption is the only way around it.

But we've had technologies for implementing encryption on-the-fly where we don't care about the possibility of an MITM attack for yonks. Just use DH key exchange as a handshake and then use that as the key for a stream cipher. No need for certificates at all. You get strong encryption between endpoints, and acknowledge that you're potentially subject to a MITM attack. You can even combine it with some advanced DNS checking to minimize the chance that your company/government's proxy is MITM-inspecting every connection. The only problem here is that there isn't a clean URL handler supported by RFCs that is available that I know of.

Why not just start one? httpe (HTTP Encoded, but not Secure)?

Tuesday, May 20, 2008

Boingboing, Pheedo, and Cookie Annoyance


I'm one of those paranoid types who likes to keep precise control over who is able to save cookies, and for which duration. For that reason, I have the "Ask me every time" option set in Firefox, so that I can choose for each cookie (and blanket-ban whole domains) whether it will not be allowed to be set, whether it can be set forever, or whether it'll only last for the session. In particular, any advertising related URLs don't get set.

Most of them are pretty nice in playing with Firefox, and they'll try to set a cookie for something like .doubleclick.net, meaning that the same cookie will be used for foo.doubleclick.net, bar.doubleclick.net, whatever. I reject it once, reject everything from .doubleclick.net ever being set, and we're all happy.

The way they do this is by having a single point of entry to their cookie setting, so that:
  • They always serve ads from a single url (like ads.advertising.com)
  • They differentiate the ad either by cookie or by URL (so serving http://ads.advertising.com/8347283479327482937)
  • They properly set the domain to .advertising.com for other usage.


However, then I encountered Pheedo. Their motto appears to be "RSS Advertising Done Right." I might recommend that it's really "RSS Advertising Designed To Annoy Your Audience." I've only encountered them thus far with Boingboing, but it's annoying enough that I might actually drop BB from my blog roll and only read it on the web in the future as a result. Here's what they appear to do.

Every single link that they put into your feed has a unique domain name (not URL) (like e61225ff1c0b2a237f8fb7b3efbe3dd6.img.pheedo.com). That means that you have to individually reject or accept every single image/ad which, by the way, I've already adblocked out. The cookie itself is properly specifying the domain to be .pheedo.com, but the site its being served from is playing DNS differentiation rather than URL differentiation, meaning that the standard Firefox rules don't apply.

I tried to contact Pheedo on this and ask them to stop, but they didn't reply. C'est la vie.

I guess my annoyance is three-fold:
  • Pheedo, for sucking so hard.
  • Boingboing, for using them
  • Firefox's cookie wrangling (which I otherwise love by the way, and is one main reason why I use it on my Mac rather than Safari or whatever) for not allowing more complicated cookie rejection rules (AdBlock has no problem with blocking pheedo stuff, so I never even see the ads anyway).