one-to-many messaging
Tom Thomson
ukcrypto at chiark.greenend.org.uk
Mon, 14 Apr 2008 18:20:04 +0100
Sgriobh Roland Perry
>
> >Even in cases where the port number does determine a machine, it is
> >extremely unusual for the provider of the public telecommunications
> >system to need to look at it
>
> You don't believe the rumours that some ISPs attempt to restrict the
> passage of VoIP and P2P? [I agree that I assume the simplistic methods
> of doing that rely upon port number].
> --
Yes, of course I believe those things happen.
An ISP decides to look at port numbers to recognize VoIP traffic, and
make sure it performs badly (because he would have made more money from
a voice call, not because VoIP puts any significant strain on
bandwidth). Unless the ISP can produce a good argument that delaying,
throttling, and/or discarding VoIP traffic is necessary for the purpose
of getting other data delivered effectively (so that he's doing it for
the purposes of the public communications system) that must be illegal
interception, and if he can make out that case then it's legal
interception - because here the port number isn't being used for
routing, so it isn't traffic data. Much the same way as span and virus
filtering of email is legal interception (the ISP in the filterer is
doing the same sort of thing with the complete message as you are saying
the ISP may do with the port number - does that make the complete
message traffic data in your book? If not, why does it make the port
number traffic data?).
Same goes for P2P - but here the ISP may find it easier to make the case
that it's legal interception.
The "is the port number traffic data" question is about whether the port
number is used by the public telecommunications system to determine the
DTE to which the communication is addressed - I reckon that choosing
between different apparatus beyond the DTE is going on outside the
public telecommunications system, so even where that happens (it will
for most internet traffic, I imagine) that doesn't make the port number
traffic data.
I agree with what you said elsewhere, that the traffic-data versus
content split is very unclear - not only in RIPA, but also in many minds
and in many other contexts, because I remember laughing really hard when
I saw (many years ago, now) that the URL up to the first single slash
was considered by many to be traffic data (that did include the port
number) because of course (a) the URL as typed is not transmitted, so
that description is not useful within the public telecommunication
system (if I encrypted all the request-header fields in the transmitting
DTE and decrypted them in the receiving DTE nothing in the system would
be impaired except the system's ability to intercept the content) and
(b) there is nothing special about the Host request-header, the
Authorization request-header, the location request-header, and the
Referer (who stole the "r"?) request-header (or indeed any of the other
request-headers) that would allow one to see some of them as having a
different status from the others yet two of those used to tend to fit
within the definition and two didn't (three don't with modern browsers -
would that have meant that the authorization request-header used to be
traffic-data but no longer is?).
M.