TalkTalk or StalkStalk plans should be opt-in

TalkTalk today announced their plans for their website malware software, which has been criticised for opening up potential interception issues under RIPA.

We met with TalkTalk and Richard Clayton has produced a technical note on the software. Nick Bohm, below, outlines the potential legal issues. Linked is Talktalk’s legal analysis.

ORG believes an opt-in system should avoid both technical problems and legal breaches.

Clarification Tuesday 10 May: While we welcome today’s announcement that default usage is “off’, we will seek further clarifications on this, especially as to whether users are opted-out of URL checking in the process.

1  The blocking system (RC note #B)

In general this should not infringe or otherwise be objectionable (except perhaps as between an account holder and the other users of the account if there is disagreement about the blocking policy).

There is no reason why an account holder cannot have a service which checks their requests against a database and warns of requests which match the desired criteria. (Indeed the “risk of malware” criterion seems a highly desirable one – as long as the system does not equate all unsigned executables with malware.) Interception should not take place if the sender intends the message to go into the database-checking system, since that makes its operator an intended recipient.

A cautious ISP would want the opt in to include a promise by the opter that he had or would obtain authority from all users to have their URLs checked. Otherwise how can the ISP sensibly assume that all users do intend it to do the checking? So there is a problem where the user doesn’t know what’s going on (soluble, up to a point, and at the price of some annoyance, by a “home page warning” when the browser is started; though that assumes every new user logs in afresh).

2  The malware system (RC note #C)

This system, which is not based on consent (except to the extent if any embodied in the applicable contractual terms), makes copies of all users’ URLs entered via HTTP on port 80, and uses them to visit the relevant site to check it for malware as the basis for deciding which websites to classify as malware hosts (with a view to using them in the blocking system and taking other appropriate action against the spread of malware).

The system will be objectionable to some users. One example is of an unlinked URL provided to the user in confidence for his sole use for some specific purpose. The user will unwittingly have committed a breach of confidence by allowing TT to use the URL.

Another case is of a URL for a site permitting a limited number of visits. The user might be locked out as a result of visits made by the TT system.  (This may depend on the extent to which the TT system strips identifiers from URLs:  TT have not been clear about this, but there is some evidence suggesting that it is minimal.)

These cases show why some users may reasonably object to having the system imposed on them, and why an opt in system should be preferred.

TT’s statement of its view about its legal position suggests that it does not draw a clear distinction between those parts of a URL which constitute traffic data under RIPA and those parts which do not. It therefore seems very probable that TT is intercepting some users’ communications (i.e. those consisting of URLs which include some content in addition to traffic data). Whatever may be contained in TT’s applicable contractual terms, it is hard to see that there can be evidence that all users actually intend to send their URLs to TT for their own use (as distinct from sending them to TT for temporary use limited to what is necessary for fetching the relevant page).

That leaves TT to rely on s3(3). The precise scope of s3(3) is uncertain, of course.  One might ask to what extent TT’s systems must be directly exposed to foreseeable damage in order to justify interception to prevent it; and RIPA does not attempt much of an answer. The most one can say is that “purposes connected with the provision or operation of that service” is a fairly loose test, and that neither the CPS nor the courts are likely to be hostile to those genuinely fighting malware.

Nevertheless, the TT justification is based on protecting the end-user’s machine and the end-user’s data, which casts doubt on whether their purpose is to protect their network, which it would have to be in order for them to rely on s3(3). Moreover it is hard to see how malware they keep out by their system could be shown to have been likely to affect their network, given that their system is only one among a vast number of networks, and the malware could have been aimed anywhere.

These considerations argue that TT will be on thin ice in its reliance on s3(3), and will also be liable to cause real problems for some of its users. TT ought to set up this system too on an opt in basis.