call +44 20 7096 1079
May 09, 2011 | Jim Killock

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.

 

google plusdeliciousdiggfacebookgooglelinkedinstumbleupontwitteremail


Comments (13)

  1. sigma:
    May 09, 2011 at 11:12 PM

    Jim, are your mistaken? How do you equate

    "C BrightFeed’s collecting of URLs
    19. There is another aspect to the BrightFeed system that applies to all TalkTalk customers,whether they have opted-in or not. The mechanism which utilises the URLs from HTTP requests on port 80 is active for every customer, and all URLs will be passed to the database system, even when the customer has not opted in the BrightFeed blocking mechanism."

    with a default of off? It clearly isn't.

    1. K9:
      May 10, 2011 at 02:09 AM

      http://www.talktalkmembers.com/forums/showthread.php?t=46287&page=85
      Here Mhanco states that according to your statement the TalkTalk process is illegal. can you please clarify. Is it illegal or not. Awaiting your reply.
      Paul

      1. Jim Killock:
        May 10, 2011 at 09:22 AM

        We say: “on thin ice” and that opt-in could avoid this.

    2. Jim Killock:
      May 10, 2011 at 09:15 AM

      Thanks, Sigma, you're right to ask this question. TalkTalk's statement that the system was opt-in misled me as I put this up yesterday. We still don't have clarity as to whether the underlying system is opted out or not. We will be seeking this.

  2. fineandandy:
    May 10, 2011 at 03:02 AM

    The K9 chap is a bit of an emotional beast. I shan't be reading all his TalkTalk thread but the MHanco point is considering the interception question.

    Rather like BT and Phorm Webwise? Not consented so probably illegal because of the incapability to depend on the s3(3) defense.

    It is interesting to see him/her, a community moderator (?) panic and launch into the poster's challenge. It does not look like the mod has read your blog and the supporting texts if he/she has to ask for clarity.

    Excellent piece of work as usual ORG.

    1. K9:
      May 10, 2011 at 03:41 AM

      To be honest, I did not "jump" on anyone, just asked for clarification that someone used this blog as a legal statement. So still will wait on the ORG response rather than a personal assination

      1. Jim Killock:
        May 10, 2011 at 09:12 AM

        I've modified this article above. We don't yet know if URL checking is opted out, or merely the user software. Hope that's useful

        1. Keith:
          May 10, 2011 at 09:54 AM

          http://www.talktalk.co.uk/products/virus-alerts/

          "7. Will only the customers who sign up to Virus Alerts have the websites they visit scanned?

          Virus Alerts scans all the websites you visit and is completely anonymous. You just need to opt-in to Virus Alerts if you want warnings to pop up while you browse. If you activate Virus Alerts, you can switch it off at any time afterwards."

          http://www.out-law.com/default.aspx?page=11360

          "Once it is launched, every website accessed from our network will still be scanned," said the spokesman. "There is no opt in or out to that – we own the network and choose to scan URLs and sites so we can protect our customers."

          The scanning is 'opt-nothing'

          It is just the alerts than can be opted-in or opted-out of. The extraction of URLs from communication data is permanently on. They do not need this data to perform their primary role as an ISP. They do not necessarily need to obtain such data in this manner to provide a 'value added service' and furthermore if a customer is not making use of that 'value added service' I fail to understand why they should be permitted to use that customers communication data in such a manner without permission from both the customer and the website being visited.

  3. Keith:
    May 10, 2011 at 04:10 AM

    As an ISP it is TalkTalks role to route traffic provided as packets. In order to route those packets all they need is the source and destination IP addresses from any particular packet. The URL is not traffic data under any definition that would require TalkTalk to have sight of it in order to fulfil their role as an ISP. It is used at and by the endpoint target system to determine what resource is being requested and return it.

    Consider that when you click on any particular URL your browser will perform a DNS look up on the TLD associated with that URL. The DNS system will return the IP address. Your browser will construct a packet with that destination IP address in the headers and in the packet it will place a GET request for the URL. The packet is then sent to TalkTalk for delivery. TalkTalk only need the destination IP in order to route the packet. The destination IP is the traffic/routing data. The URL is not it is communications data.

    Note that TalkTalk would at most gain sight of TLD as a result of the DNS lookup request if the user is making use of TalkTalks DNS system. Otherwise they might perform a reverse DNS look up on the IP address in the packet header.

    In order to 'discover' and/or reconstruct any particular URL TalkTalk have to intercept and perform Deep Packet Inspection on the full communications stream.

    Having obtained the initial resource, perhaps a webpage in HTML, your browser constructs that page as described and it will make similar DNS lookups and requests for any resources used to construct the page which are not located at the original source as well as from the original source itself. Again these will be packets with an IP address in the header and the URL in the packet itself. By their nature such requests may be split across multiple packets and those packets need not necessarily comprise information solely related to URLs forcing TalkTalk to intercept and perform DPI on the full communications stream.

    Once again.. It is TalkTalks job to route packets. In order to route packets all they need is header data to determine the destination IP. They do not need sight of the URLs. In order to gain sight of those URLs they have to intercept and perform Deep Packet Inspection on the entire communications stream.

    In my view the following statement is disingenuous rubbish..

    "When a TalkTalk customer decides to access a website URL using TalkTalk’s network, the network will route the customer to that URL. It is important to stress that it is TalkTalk’s network that routes the customer to the chosen URL. There is no manual intervention by TalkTalk employees, for example by seeing which URL has been requested and then routing the customer accordingly. TalkTalk’s network through its many circuits, devices, systems and electrical components, is a closed network (“Closed Network”). It is the Closed Network that is made aware of the chosen URL and it is the Closed Network that routes the customer to the website URL."

    TalkTalk does not 'route customers to URLs' they 'route packets to destination IP addresses'. End of story.

    1. Ewan:
      May 10, 2011 at 10:12 AM

      Keith, while I think you're generally technically right about this HTTP inspection service, it's been a long time since an ISP has done nothing but "route traffic provided as packets".

      ISPs provide all sorts of add-on services above and beyond dumb routing - email, web hosting, voice over IP, TV on demand, anti-virus protection, etc.

      To simply say that "they 'route packets to destination IP addresses'. End of story." simply isn't the case for a lot of the services that a modern ISP provides.

      Whether deep packet inspection (it used to be called a transparent proxy, but that's not very dramatic) is the right thing for an ISP to be doing is a valid question, but don't forget ISPs do a lot more than just route packets like Demon and Pipex did in the early 90s.

      1. Keith:
        May 10, 2011 at 01:42 PM

        Hi Ewan

        No doubt. However I was referring to TalkTalks attempt to obfuscate the difference between traffic and communications data in an effort to suggest what they are doing is compliant under RIPA.

        They do not 'route customers to URLs' they 'route packets to destination IP addresses'. End of story.

      2. JD:
        May 10, 2011 at 08:57 PM

        Ewan
        Transparent proxies are exactly what they seem to be they route traffic whilst just cacheing the data to spread the the ISP's load, however what we are talking about here are "Intercepting Proxies" that manipulate the data stream(with or without the use of DPI). :(

  4. Jim Killock:
    May 10, 2011 at 11:28 AM

    Hi Ewan, you are right, which is why RIPA envisages certain types of interception for network purposes. The question is whether looking at URLs in general without consent amounts to interception, or whether there is a RIPA justification. We are not convinced there is a RIPA justification.



This thread has been closed from taking new comments.