Well, it’s official. Conroy and the DBCDE (hey, that could be the name of a band!) have released the results of the much-debated Clean Feed.
From the pretty performance graphs in the report, the filter doesn’t appear to be performing too badly. Implemented correctly, this filter could be put to use without a major impact on performance. However, that’s missing the point!
The point being that with the filter in place, it is basically equivalent to being wiretapped all day every day. Wiretapping in itself is not bad — it is sometimes plays an important role in solving crimes, or thwarting conspiracies. However, all wiretapping to date requires prior evidence of criminal activity, and a warrant is needed to perform it.
This “clean feed” is effectively wiretapping without a warrant. In other words, treating the general public like criminals. Guilty until proven innocent.
Once you establish that, how well the filter performs is a moot point. Admittedly, it is entirely possible BGP will be used so that only certain websites will be run through the filter (i.e. selective proxy). However, there is no guarantee that this technique will be used, and it is only a technical difference — the legislation to implement would be exactly the same. So the government could effectively change at will to monitoring all web traffic.
One quote I found interesting from the report:
Telstra reported that heavy traffic sites could overload its trial filtering solution if included in the filtering blacklist. This is also the case for all filters presented in the pilot.
So basically they are admitting the filter will be vulnerable to denial-of-service attacks. This could be exploited by criminals around the world with access to large botnets. Not only that, but a large amount of personal information is still transmitted over HTTP. Though unencrypted, the links between me and the website I am exchanging with are largely trusted. However, putting a filter in the middle that is explicitly designed to read the information suddenly makes the situation far scarier.
I also found no mention of IPv6 in the report. Because the trial has been reported to depend heavily on proprietary software, no mention of IPv6 is made, and of which it is common knowledge that proprietary software is more often than not lagging behind in cutting edge technologies, it is entirely likely that the filter will: (a) possibly hinder IPv6 adoption by ISPs, (b) cut off access to IPv6–enabled sites, or (c) be ineffective at blocking sites that are accessible via IPv6.


Good point re: IPv6.
IPv6 includes an encryption layer in the network stack. For all practical purposes it can be seen as being the same as IPSEC in IPv4. To be IPv6 compliant, a vendor MUST include this layer so as IPv6 is adopted, IPSEC VPNs become much more common and deep packet inspection stops working altogether (unless you know the encryption keys). There doesn’t even need to be much user intervention to enable the encryption as IPv6 also supports what is known as “opportunistic encryption” where the endpoints will automatically encrypt if they have the shared keys.
Another nail in Mr Conjob’s coffin…