Newzbin2: Did BT shoot itself in the foot - and will Irish ISPs do the same?

Yesterday's decision in Twentieth Century Fox v. BT (PDF) introduces mandatory web blocking for the first time in the UK and unsurprisingly has already received a great deal of attention (BBC|Guardian|IPKat).

Lilian Edwards has provided a comprehensive legal analysis, while Richard Clayton tackles the technical implications of the judgment, so I won't attempt to duplicate their work. But a separate blog post might be useful on one point which has received less attention - the significance of the fact that BT had already voluntarily adopted a system - Cleanfeed - to block child abuse images.

In 2004 - when BT initially adopted Cleanfeed - it was even then obvious that there was a risk of function creep and in particular that copyright holders would seek to use the system. In a briefing to LINX at the time (link now broken), however, BT appeared to believe that it was unlikely to be sued and could mitigate this risk by discontinuing the use of Cleanfeed if scope creep became a reality. According to the then Director of Internet Services for BT Retail: "if the pressure to extend the scope of Cleanfeed became too great [BT] would simply cancel the project" and "BT is unlikely to be the defendent of choice for a copyright holder or other party attempting to hold an ISP legally responsible for Internet traffic".

Yesterday's ruling has shown the limits of this reasoning. Once Cleanfeed provided a proof of concept then function creep was inevitable and the idea that BT could unilaterally turn off the blocking system unrealistic. Instead, it painted a target on its back. According to a representative for the movie industry "BT was chosen because it's the largest and already has the technology in place, through its Cleanfeed system, to block the site".

The use of Cleanfeed also prevented BT from asserting two defences that might otherwise have applied - that there was no clear legal basis for imposing a blocking system and that their obligations would be unclear. Instead, according to the High Court:

the order sought by the Studios is clear and precise; it merely requires BT to implement an existing technical solution which BT already employs for a different purpose; implementing that solution is accepted by BT to be technically feasible; the cost is not suggested by BT to be excessive. (para. 177)

In light of this, therefore, it's hard not to conclude that BT shot itself in the foot by adopting a blocking system which could easily be repurposed for the benefit of Hollywood.

"No good deed goes unpunished" - this case proves the truth of this statement, and will undermine other voluntary initiatives to block child pornography by showing how easily those initiatives can be coopted by the movie industry or music industry. There's also a lesson here for Irish ISPs who are coming under police pressure to introduce similar blocking systems. Will they now do so, knowing that these systems will make them a happy hunting ground for the content companies, defamation plaintiffs, and others who may wish to block access to the web in Ireland?

Irish mobile phone companies act on voicemail hacking - but why the delay and have they gone far enough?

Yesterday's Irish Times has a story detailing what Irish mobile providers are doing about voicemail security, in light of the UK phone-hacking scandal. There is more detail on the Data Protection Commissioner's website, which indicates that the DPC has abandoned earlier plans to make remote access to voicemail a user option. Instead, according to the DPC:

[The networks] have now all put in place or have committed to put in place in the coming days additional measures to assist their customers to protect the data on their phones. It is now important that the public follow the advice of their mobile provider and where they have not already done so take steps to either secure their voicemail and phones generally or improve upon the measures they may have already taken. At the end of this process it will no longer be possible to access a person’s voicemail using a default password.

The state of play is now as follows:

Meteor and eMobile
No default security PIN is applied and every customer is required to choose their own secure PIN when enabling voicemail. In an effort to encourage customers to take proactive steps to secure their voicemail service they have enhanced the information contained on both websites (www.eMobile.ie or www.meteor.ie) with additional details and guidance on how to secure voicemail services. Additionally, an educational SMS will be sent to all voicemail users in the coming days. Customers can strengthen their password today by dialing 171 (both Meteor and eMobile) and follow the instructions.

O2
O2 has commenced a programme of communications with customers to advise on how they can keep access to their voicemail secure at all times. The communications will include text messages to customers and a pre-recorded advisory when customers dial in to their voicemail service to retrieve messages. O2 has also updated its website with a range of security tips, available at www.o2.ie in the "Can we help you today?" section on the homepage. Customers can change their password today by dialling 173 from their handset and follow the instructions.

Three
Three is communicating to its customers the importance of securing their voice mail with a unique PIN known only to the customer. The communications will include text messages to customers with advice on setting up a voicemail PIN. There will also be an Online Help & Support update to the section on Voicemail to advise customers on the level of security they should use when setting up their PIN. Customers can change their password today by dialling 171 (in Ireland) or +353 83 333 3171 from abroad from their handset and follow the instructions.

Vodafone
From tomorrow Vodafone Ireland customers will hear information when they dial 171 on how they can change their voicemail password at any time. Voicemail and password information is also available today on Vodafone.ie. Vodafone will continue to inform its customers in the coming weeks on new enhanced security options available to its customers. Customers can change their password today by dialling 173 from their handset and follow the instructions.

At first glance this might seem like a step forward, but it leaves many questions unanswered.

First - why has it taken the Irish networks so long to act? Wrongful access to voicemail messages was well known long before now - and I blogged about it here back in 2006. There is simply no excuse for the delay that most networks have shown.

Second - will the networks continue to issue new phones with default voicemail passcodes? Credit must go to Meteor/eMobile who don't do so, but it isn't clear from the DPC's statement - "At the end of this process it will no longer be possible to access a person’s voicemail using a default password" - whether the other networks will be required to abandon their ongoing use of default passcodes. If not, however, then it's hard to see how they would not be in breach of Regulation 4 of the new ePrivacy Regulations, which provides that:

(1) With respect to network security and, in particular, the requirements of paragraph (2), an undertaking providing a publicly available electronic communications network or service shall take appropriate technical and organisational measures to safeguard the security of its services, if necessary, in conjunction with undertakings upon whose networks such services are transmitted. These measures shall ensure the level of security appropriate to the risk
presented having regard to the state of the art and the cost of their implementation.
(2) Without prejudice to the Data Protection Acts, the measures referred to in paragraph (1) shall at least—
(a) ensure that personal data can be accessed only by authorised personnel for legally authorised purposes,
(b) protect personal data stored or transmitted against accidental or unlawful destruction, accidental loss or alteration, and unauthorised or unlawful storage, processing, access or disclosure, and
(c) ensure the implementation of a security policy with respect to the processing of personal data.

(Daragh O'Brien has more on the ePrivacy Regulations and their impact on voicemail hacking.)

Third - have the Irish networks taken steps to secure against other methods of voicemail hacking such as Caller ID spoofing? This is a well known problem in the US and at least some European countries - as Brian Krebs puts it:

For years, it has been a poorly-kept secret that some of the world’s largest wireless providers rely on caller ID information to verify that a call to check voicemail is made from the account holder’s mobile phone. Unfortunately, this means that... your messages may be vulnerable to snooping by anyone who has access to caller ID "spoofing" technology. Several companies offer caller ID spoofing services, and the tools needed to start your own spoofing operation are freely available online.

The recent statement from the DPC doesn't address this particular attack, and the track record of most Irish networks doesn't fill me with confidence that they are on top of this issue either.

The Internet of Elsewhere

I've just finished reading a review copy of Cyrus Farivar's impressive new book The Internet of Elsewhere. Like many books, it traces the development and mass takeup of the internet - unlike most, however, it is not US-centric and instead gives equal space to case studies from four countries: South Korea, Senegal, Estonia and Iran. In doing so, it provides a wealth of detail for many developments (the 2003 Iranian crackdown on bloggers, the Seoul "Dog Poop Girl", the Estonian takeup of wifi) which are often cited but seldom put into their wider social context. The author makes a particular point of describing the factors such as demographics, literacy and cost which have driven the use of the internet in each country - or, in the case of Senegal, have kept much of the population offline. A particular highlight for anyone interested in civil liberties online is the description of Iranian control of the internet, which goes back to early measures in 2000 and describes the various state tactics since then which have resulted in many prominent bloggers being forced to leave the country. The book also succeeds in being an easy read - while it is well researched and sourced it is also journalistic in its tone and describes each country through the stories of individuals. I would recommend this to anyone with an interest in the takeup of the internet and the social changes it prompts.

Virtual execution of documents under Irish law

There's been quite a bit written about the electronic signature of contracts, and under Irish law there are specific statutory rules in place under Part 2 of the Electronic Commerce Act 2000 which allow such signatures to be used. Curiously, however, there's been much less attention paid to a more traditional form of "virtual signing" - where one or more parties to a transaction are not physically present at the meeting where a particular document is executed.

In these situations the practice had developed of either executing signature pages in advance or signing a document remotely and subsequently distributing signature pages by fax or email. This practice, however, hit a road bump with the decision of the High Court of England and Wales in Mercury Tax Group v. HMRC which held that a signature given in respect of an incomplete draft deed could not be transferred to an amended final deed, as s. 1(3) of the Law of Property (Miscellaneous Provisions) Act 1989 requires that "the signature and attestation must form part of the same physical document... which constitutes the deed".

Although obiter, this finding had obvious wider implications for virtual signatures generally in any situation where statutory requirements for signatures must be met. Consequently, it was followed by a practice note from the Law Society of England and Wales (January 2010) and now by a practice note from the Law Society of Ireland (June 2011, PDF, pp. 52-53).

The whole Law Society guidance note is very useful and must be read, but it helpfully summarises the options as follows:

Option	Steps	Documents
Option 1 (return the entire PDF/ Word document and a PDF of the signed signature page)	• Once the documents have been agreed, final execution versions are emailed to the parties and/or their lawyers. • For convenience, a separate extracted signature page may also be attached to the email, but this is not necessary. • Each authorised signatory prints and signs the signature page. If appropriate, the signing may need to take place in the presence of a witness.  • The signature page is then scanned and returned by email together with the whole document previously emailed to the signatory. (For a deed, make it clear when delivery is to occur.) • See suggested wording for covering email (panel, p53)	Option 1 may be used for any document or deed, i.e. including: • A deed, • A real estate contract, • A guarantee (whether a deed or in simple contract form), • A simple contract.
Option 2 (return the entire PDF/ Word document and a PDF of the signed signature page)	• Once the documents have been agreed, final execution versions are emailed to the parties and/or their lawyers. • For convenience, a separate extracted signature page may also be attached to the email, but this is not necessary.  • Each authorised signatory prints and signs the signature page. • The signature page is then scanned and returned by email, together with authority for it to be attached to the final approved version of the document. (The degree of formality required for this authority will depend on the circumstances.)	Option 2 may be used for: • A guarantee (in simple contract form only), • A simple contract  • A real estate contract. Option 2 may not be used for a deed (of any type).
Option 3 (return the entire PDF/ Word document and a PDF of the signed signature page)	• Once the documents have been agreed, final execution versions are emailed to the parties and/or their lawyers. • For convenience, a separate extracted signature page may also be attached to the email, but this is not necessary.  • Each authorised signatory prints and signs the signature page. • The signature page is then scanned and returned by email, together with authority for it to be attached to the final approved version of the document. (The degree of formality required for this authority will depend on the circumstances.)	Option 3 may be used for: • A guarantee (in simple contract form only), • A simple contract, • A real estate contract. Option 3 may not be used for a deed (of any type).

There is also an important caveat that for registration purposes "wet ink" versions of all signatures may be required - if so, the guidance note points out that appropriate undertakings must be included that these will be provided following execution.