https - hopefully not too stupid a question

[Peter Fairbrother]

Francis Davey wrote:
> 2012/6/18 Andrew Cormack <Andrew.Cormack at ja.net>:
>> Hmmm. For example if I wrote a webmail server where sending a mail involved a packet whose content looked like
>> "<message>This is an e-mail message</message><to>Andrew at ja.net</to><subject>test message</subject>"
>> Then you have to read every byte of that message (most of which are content) in order to find the traffic data buried within it.
>>
> 
> It is not "traffic data comprised in or attached to a communication
> (whether by the sender or otherwise) for the purposes of any postal
> service or telecommunication system by means of which it is being or
> may be transmitted" (RIPA s2(5)). That is, although it might give
> information about who is the intended addressee, it is not there for
> the purposes of the telecommunication system that is transmitting it.
> 
> Obviously if you set up an internal mail system that read email
> messages and extracted that sort of information from inside and then
> re-routed them, then s2(5) would exclude from the definition of
> "interception" on your network conduct on your network which looked
> inside the emails.
> 
> In other words, the 2(5) use of "traffic data" is relative to the
> system where interception might otherwise be taking place.


Sadly, no.

If "they" are looking at traffic between you and facebook, and that 
traffic might contain some content which might get passed on to another 
facebook user via facebook, then the possible actions of Facebook as a 
telecomms system are enough to trigger 2(5) (and therefore the looking 
is not interception), even though they are looking at traffic between 
you and facebook.

And even if there is no actual "hidden message".

It's not just the traffic between you and facebook, it's also the 
possible use of the facebook system. If a "hidden message" *might* be 
sent on via facebook, that's enough

The relevant part is: "comprised in or attached to a communication 
(whether by the sender or otherwise) for the purposes of any postal 
service or telecommunication system by means of which it is being *or 
may be* transmitted"


Also sadly, you can't parse RIPA 2(5)(a):

"(a)any conduct that takes place .. for the purposes of any postal 
service or telecommunication system by means of which it is being or may 
be transmitted;"

which would be a lot better (and which would make a lot more sense).


But there's more, and perhaps worse. 1(4) of the draft Act, which says 
"Nothing in this Part authorises any conduct consisting in the 
interception of communications .." only covers part 1 - and not part 2, 
where all the filtering stuff is.

Belt n' braces, anyone?

> 
> Remark;  The bill re-uses RIPA's definition of "interception".
> 
>> I'd been assuming that pulling traffic data out of the inside of a packet would be interception because it would inevitably "make available" the rest of the inside of packet, thus satisfying the requirement of "interception" in 2(2).
>>
>> But you're suggesting that 2(5)(b) might trump that, so that "making available" *is* OK, if it is necessary to *find* the traffic data. From a privacy point of view, that sounds depressingly plausible.
>>
> 
> Only if its traffic data for the purposes of 2(5)(a) which will only
> be the case if the telecommunications system is using that data. That
> is a bit circular I realise, but it means that it won't be permissible
> to try to obtain everything that is traffic data but only traffic data
> used by the system.


No.

I'm very certain about this, I have spent a loooong time analysing RIPA 
2(5).

-- Peter Fairbrother