Archive for the ‘privacy’ Category

irony is not dead

Tuesday, March 29th, 2011

Installing counterize to analyse trivia’s logs has been instructive. I now know that some of my most visited pages are consistently those of a “how-to” nature (in particular, those about postfix, dovecot and, strangely, reflashing the old BT home hub). In many ways this is satisfying since one of the objectives of this blog is to document solutions to problems I have encountered personally.

But counterize provides much more than this. For example, I now know that of my visitors, 46.09% use firefox, followed by 27.24% using IE, with safari trailing in third place on 8.75%. Further, the top browser by version is IE 6.0 (now there’s a surprise…) at 13.14% and the most used OS is windows XP at 42.65% (sad, but you can’t argue with the stats).

However, what really intrigues me is the referer analysis. Some are fairly obvious given the content viewed. For example one of the top referers is a page on the-scream.co.uk which points to my articles on the home hub. Others are less so. One that caught my eye today is a referer from a website which sells a tool to spy on mobile phones. That site has a privacy policy (!) which says the following:

Privacy Policy

This privacy policy applies to the use of http://www.spybubble.com

We highly value your privacy and make this policy easily available throughout our site to assist you in understanding the handling of information in the course of using this site.

As Terry Wogan would say, “is it me?”

click here

Sunday, January 23rd, 2011

The Cory Doctorow article referenced at the end of the post below mentions URL shorteners as potentially dangerous because they completely obscure the actual URL you will be taken to if you click them. By way of experiment I thought I’d post one here just to see how often it is used.

damn, I think I got hit by a 419er

Sunday, January 23rd, 2011

I am normally pretty careful about my on-line security and privacy. I take a lot of care to ensure that my home network is nailed down tightly and all the clients and servers on it are also nailed down as well as I know how. I don’t use software which is susceptible to the majority of the malware out there; my browser is nailed down as tightly as I can get it whilst still allowing it to be useful (roll on HTML5, I hate flash, but it is so damned useful); I do some, very specific, browsing (such as on-line banking) from within a VM and do not use that browser or machine for anything except that specific activity; I routinely bin cookies and flash LSOs (in fact I find it better to disallow all LSOs in the first place); this blog does not include any email addresses harvestable by ‘bots; my email client is a niche (i.e. minority) product and is configured only to allow text (no HTML or embedded images or webbugs); I use tor when I want to be as anonymous as possible; my local DNS server blocks access to a whole range of addresses I don’t like; and I never respond to unsolicited email.

But I got phished. Damn.

Here’s what happened.

I advertised an unwanted mobile phone on gumtree. I chose gumtree in preference to ebay because a) adverts are free, and b) gumtree allows you to target the advertising to a specific location. I like this idea because it means you can say “I’ve got a doohickey for sale in South London. Come and see it and pay cash if you want it”. My ad gave details of the item for sale and, as is recommended, I chose to have responses emailed to me. Here I made mistake number one – I used my normal email address rather than a disposable one. To be fair, gumtree don’t expose any of your private details, they just forward any responses to the address you give. Here’s where I made mistake number two, I responded to queries about the ad from the address given to gumtree. Damn. Idiot. So stupid.

So why do I think the responses weren’t kosher? Well there were a number of giveaways. Firstly the requests were for information already in the ad (“how much do you want?”); secondly, there were a suspiciously high number of “spilling misteaks” in the emails; thirdly, the correspondent wanted me to mail the ‘phone to a location outside the UK (“Thanks for your quick respond actually i will love to buy the Ad for my Daughter who is currently studying at British international college (BIC) in West Africa so am willing to pay you additional £48.76 for the shipping via Express Air Mail.” (sic)); fourthly, the respondents all seemed desperately keen for me to accept paypal as the preferred payment option. I’m normally quicker on the uptake than this, but sadly it took me four or five emails to realise that there was a pattern here and that the people after the phone seemed to be following a script and were completely ignoring my responses. Here’s a sample:

Someone calling him or her self “Janet Mason”:

“Hello Seller,
Can I know the condition of the item? I think you will accept PayPal. And I will pay the postage and packing cost for the item. If you can send me paypal payment request now and I will make the payment straight away without any delay. Hope to hear from you very soon.”

My response:

“Janet

As the ad say, the phone is in “as new condition”. This means what it says. The phone is completely clean and has no visible markings or scratches.”

“Janet’s” reply:

“Ok send me your paypal Payment request now so that I can make the payment now.”

My response:

“I’d like a bit more detail first please.

Where are you? (Full address and telephone mumber so that I can confirm that I am sending to “Janet Mason”.

Details of your confirmed paypal account (so that I know that Paypal have verifed you).

If you want to know why I am concerned please read the paypal guidance for sellers – particularly the bit about sending only to UK or US based addresses and getting signatures on receipt of goods.

I have received several requests to send the phone to “my daughter/son/nephew” or whatever in various Countries outside the EU. I am naturally suspicious.”

“Janet” then says:

“Hello, 
Am in London right now but due to the nature of my work here in London I will not be able to post the item to my Business Partner Daughter in Nigeria as a New Year Gift. But I will pay for the postage and packing cost via FedEX. Get back to me with your paypal payment request now so that I can make the payment now and get the item posted out tomorrow Morning.”

Correspondence ends…..

Now whilst I have not lost the ‘phone, I have verified a usable email address to a bunch of scammers. I expect my spam volume to that address to increase dramatically. Never mind though, I’m not alone in losing out to the bad guys, and at least I haven’t lost any passwords in the process.

Still, I’m pretty pissed off.

google opt out village

Saturday, October 9th, 2010

The Onion News Network reports:

This is not satire……

it’s not that I’m anti google

Saturday, September 4th, 2010

I’m just pro privacy. And google just happens to be one of the worst offendors when it comes to breaches of my privacy. El Reg yesterday ran an article pointing to the consumerwatchdog.org ad depicting Eric Schmidt as a “privacy pervert”. Deliciously, that ad is hosted on youtube.

But consumerwatchdog have long campaigned about google’s attempts to trample on users’ privacy. The video below shows how google’s chrome browser fails to protect the user’s privacy even when “incognito mode” is used. Incidentally, the video also shows how google’s javascript based, supposedly helpful, “stem searching” capability during searches effectively adds a keystroke sniffer to your PC. Note that this capability is not specific to chrome, it happens whatever browser you use when you use google’s search engine.

Be careful out there.

phone home

Sunday, August 29th, 2010

Google’s chrome browser first appeared back in 2008, since when many commentators have sung its praises. Apparently it is “blindingly fast” (well, let’s face it firefox can be a tad slow, particularly if loaded down with a swathe of plugins) “clean”, and “simple”. Until recently I had not tried chrome (for some fairly obvious reasons) but I thought it might be interesting to fire up a copy in a VM just to see what all the fuss was about. So I did. And whilst I was doing that I ran tcpdump and etherape to see what was happening under the hood. What I found intrigued me.

First I spun up a completely new clean install of ubuntu in a virtualbox VM. Then I downloaded the latest chrome .deb from the google site and installed it. Before launching chrome for the first time in the guest system I fired up the sniffers in the host system. This is what I found:

image of etherape capture

Note that etherape shows five connections which are instantly recognisable as going to google servers (the 1e100.net domain), three to verisign, and a further three to IP addresses with no associated names (these appear to be either youtube or google image cache machines – also owned by google of course). You can ignore the rlogin.net servers, they are all mine.

A quick look at the tcpdump record shows that the verisign connections all check for SSL certificates and/or revocations – perfectly sensible and understandable. But the google connections are less illuminating until you follow the tcp streams. Two of the connections are SSL encrypted so it is not possible to be certain what is carried in them, but they appear to be certificate exchanges (or updates), a third gets a certificate revocation list whilst two more get simple html or xml schema probably associated with building the welcome screen (I didn’t explore in detail). One connection gets a shockwave flash file and two get and set cookies in the youtube domain. At least one of the google connections also gets and sets cookies in the google domain.

Now none of this is inherently suspicious (well, alright, it might be) but the point is that all this happens upon first connection and without reference to the user. And if you don’t want google (or youtube) cookies on your machine you will have to delete them when first you use the browser. I have an instinctive (OK, partly irrational) dislike of software which “phones home” without telling me – and chrome does that on quite an impressive scale. I’m not sure what would happen in prolonged usage of the browser because I wasn’t impressed enough to want to use it in anger.

I’ve trashed the VM of course.

update to autossh – or how ServerAliveInterval makes this unnecessary

Friday, August 27th, 2010

I had a couple of comments on my earlier post about autossh which suggested that I should look at alternative mechanisms for keeping my ssh tunnel up. Rob in particular suggested that setting “ServerAliveInterval” should work. Oddly I had tried this in the past whilst trying out various configuration options and I swear it didn’t work for me. But since the autossh mechanism felt inelegant I thought I’d revisit my ssh_config file as Rob suggested. And indeed setting ServerAliveInterval to 300 (i.e. 5 minutes) solved my tunnel drop problem. I’d guess that other intervals of less than 1 hour would equally work but I haven’t checked.

I have no idea why my earlier experiments failed.

they are taking over the entire net

Monday, August 2nd, 2010

Some time ago I disabled my wp-recaptcha plugin because it had the unfortunate side effect of marking all comments as spam. I don’t have a particularly high comment rate, but the ones I do get, and which get past akismet, are usually OK. Apparently a flaw in version 2.9.6 surfaced when wp-recaptcha was used in conjunction with wordpress 2.9.2. I obviously got caught with this when I updated my wordpress installation so when I noticed the problem I just disabled wp-recaptcha. Of course I have since updated wordpress again and I noticed that the plugin had also been updated to 2.9.7 so I thought I would upgrade and reactivate. Upon doing so, however, I discovered that my public/private key pair had disappeared as a result of the deactivation and I was invited to apply for a new set. OK, no problem, happy to do so but a bit peeved that the keys seemed to be deleted when the plugin is deactivated. This strikes me as unnecessary.

But, and this is now a big but, this is what I was greeted with when I attempted to get a new set of keys:

“reCAPTCHA is now part of Google. In order to use it, you must create a new Google Account or sign in with an existing Google Account.
If you are a previous user of reCAPTCHA, you can migrate your old account after signing in with a Google Account.”

Yikes! It seems that re-captcha is now part of google. The chocolate factory have bought yet another piece of internet infrastructure which will no doubt feed the maw of the advertising goliath with statistics gained from my site.

Well bollocks to that. It can stay disabled. I’ll look for another captcha mechanism.

autossh – or how to use tor through a central ssh proxy

Sunday, August 1st, 2010

Since I first set up a remote tor node on a VPS about this time last year, I have played about with various configurations (and used different providers) but I have now settled on using two high bandwidth servers on different networks. One (at daily.co.uk) allows 750 Gig of traffic per month, the other (a new player on the block called ThrustVPS) allows 1000 Gig of traffic. These limits are remarkably generous given the low prices I pay (the 1000 Gig server cost me £59.42, inc VAT, for a year. OK, that was a special offer, but they are still good value at full price) and they allow me to provide two reasonably fast exit servers to the tor network. Both suppliers know that I am running tor nodes and are relaxed about that. Some suppliers are less so.

I fund fast exit nodes as a way of paying something back to the community – but as I have pointed out before, they also allow me to have a permanent entry point to the tor network which I can tunnel to over ssh, thus protecting my own tor usage from snoopers. For some time I used a configuration based on tyranix’s notes documented on the tor project wiki. But eventually I found that to be rather limiting because it meant that I had to remember to run an ssh listener on each machine I used around the house (my laptop, netbook, two desktops, my wife’s machine etc) and to configure the browser settings as necessary. Then I hit upon the notion of centralising the ssh listener on one machine (I used the plug) in a sort of ssh proxy configuration. This meant that I only had to configure the local browsers to use the central ssh listener as a proxy and everything else could be left untouched. It also has the distinct advantage that my wife no longer has to worry about anything more complex than switching browser when she wants to use tor.

But I hit a snag when initially setting up ssh on the plug. For some reason (which I have never successfully bottomed out) the ssh process dies after an hour of inactivity. This is not helpful. Enter autossh. Using autossh means that the listener is restarted automagically whenever it dies so I can be confident that my proxy will always be there when I need it.

Here’s the command used on the plug to fire up the proxy:

autossh -M 0 -N -C -g -l user -f -L 192.168.57.200:8000:127.0.0.1:8118 tornode

That says:

- M 0 – turn off monitoring so that autossh will only restart ssh when it dies.
- N – do not execute a command at the remote end (i.e. we are simply tunneling)
- C – compress traffic
- g – allow remote hosts to connect to this listener (I limit this to the local network through iptables on the plug)
- l user – login as this user at the remote end
- f – background the process
- L 192.168.57.200:8000 – listen on port 8000 on the given IP address (rather than the more usual localhost address)
- 127.0.0.1:8118 tornode – and forward the traffic to localhost port 8118 on the remote machine called tornode

Of course “tornode” must be running ssh on a port reachable by the proxy. Again, I use iptables on tornode to limit ssh connections to my fixed IP address – don’t want random bad guys knocking on the door.

Now on tornode I have polipo listening on port 8118 on localhost. I used to use privoxy for this, but I have found polipo to be much faster, and speed matters when you are using tor. My polipo configuration forwards its traffic to the tor socks listener on localhost 9050. I also disabled the local polipo cache (diskCacheRoot = “”) because leaving it enabled means that the cache (by default /var/cache/polipo) directory will contain a copy of your browsed destinations in an easily identifable form – not smart if you really want your browsing to be anonymous (besides, my wife deserves as much privacy as do I).

The final bit of configuration needed is simple. Set your chosen browser to use the proxy on port 8000 on address 192.168.57.200. Since I use firefox for most of my browsing, I simply use opera for tor and I have that browser stripped to its basics and locked down as much as possible. Using tor is then simply a matter of firing up opera in place of firefox. This means that I always know when I am using tor or not (and just to reassure myself, the opera homepage is the torcheck page).

You can’t be too careful.

scroogle is having a problem

Sunday, July 4th, 2010

I posted a note about scroogle back in January. Scroogle offered an SSL interface to the google engine, and, moreover, didn’t lumber its users with google cookies and sundry other irritations. Since then, however, google themselves have started to offer an SSL interface and, coincidentally, scroogle seem to have started to have some problems.

If you visit the scroogle SSL interface, you get a redirect to a notice which explains why some changes made at google mean that scroogle can no longer work properly. Scroogle managed to get a workaround in place for a few days, but it seems that another google change has finally killed that too unless google can be convinced to help out – unlikely in my view. The scroogle redirect page (dated 1 July 2010) has the following line from Daniel Brandt:

“Thank you for your support during these past five years. Check back in a week or so; if we don’t hear from Google by next week, I think we can all assume that Google would rather have no Scroogle, and no privacy for searchers.”

That in itself is bad enough, but as a separate new posting explains, scroogle now seems to be the target of a botnet aimed at swamping its servers. As Brandt goes on to say:

“Google has a few hundred thousand servers, while Scroogle has six. They can put up with sites that spread malware, but our bandwidth is limited. Even if Google relents and the output=ie interface returns, this Scroogle malware problem could still be increasing at that point. Eventually it alone might shut down Scroogle.”

Sad. I hate to see the little guy lose out.