Draft IMC Mayday Statement on Police Posts

There are some important issues that need clarifying in response to the SchNews INTER-NETCU article about police posts to the UK Indymedia web site.

The publication of the SchNews article was followed with the publication of a feature article Advocating Domestic Extremism - Cops on Indymedia - An Expos\xE9 by Birmingham Indymedia, an article listing the posts, Full list of Gateway 303 and 202 posts to IMC UK and also Gateway 303: Police Disinformation on UK Indymedia by Sheffield Indymedia. Articles about the matter on other Indymedia sites include the Nottingham Indymedia statement on recent events, the IMC London Statement on the recent Schnews Article, the Bristol Indymedia's position on IP logging and a global feature article, UK Police Agent Provocateurs Exposed.

(1) We make a distinction between an IP filter and an IP address logger. Broadly speaking, the latter indiscriminately captures all IP addresses and stores them in some way (either in memory or on a hard disk) for some period of time which could be indefinite. The former simply waits for a post to come from one that has already been identified and flags it up for moderator attention, while non-filtered IP addresses are ignored.

(2) We also make a distinction between content management system (CMS) and a website. A CMS is a piece of software used to manage the content of a website by its users and administrators. A website is such a piece of software configured for use on a particular server.

(3) The below does not apply to websites outside of the UK, regardless of their content management system.

[Suggest: The context of the following remarks is restricted to websites within the UK, regardless of their content management system.]

(4) In the UK, the Mir CMS is deployed for the website used by the following UK collectives: UK, Birmingham, Cambridge, Liverpool, Oxford, Sheffield, and South Coast. It was previously used by the following UK collectives: Scotland, London and Nottingham, who now use different CMS's located on different servers.

(5) The following existing UK collectives do not use the Mir CMS (referred to here as non-Mir): Bristol / South West, London, Northern, Nottingham and Scotland.

(6) The collectives that run the non-Mir websites state that their CMS's are not configured to log or filter IP addresses.

(7) Simple changes to the CMS configurations of some of these websites would give them the capability to filter/log IP addresses. For others additional simple modifications to the CMS software and/or the configuration of the web servers used would be required.

(8) In the past collectives such as Bristol and London have used these features but have since stated that they have disabled them.

(10) The UK Mir site, as configured, has the capability to both filter/log IP addresses (and therefore so must the server it runs on).

(11) The UK Mir site is not configured to log IP addresses of site visitors (i.e. people not posting to the website).

(12) The UK Mir site uses an IP filter all the time to flag posts made on the website. This filter can be controlled from the Mir admin interface and can be accessed by all Indymedia UK Mir admins. It filters 'posts' to the website from IP addresses which have been manually and independently added via the web interface.

(12) The UK Mir site can log the IP addresses of people posting to the website. The IP addresses are temporarily stored in memory and are not written to disk. Whilst they are stored in memory they can be viewed by any Indymedia UK Mir admins using an interface in the UK Mir site admin interface. When the IP logger is turned on a notification is shown in the Mir admin interface. All admins that are logged in can see all other admins that are logged in. We believe the collective scrutiny of the anti-abuse features has ensured that it has not been abused.

(13) The above IP logger is rarely used and then only for short periods of time. It has not been used so far in 2011. (other usage stats?)

(14) The IP logger is used by admins to prevent spam and other attacks that would have proven problematic for the site.

(15) The IP logger was not used in determining which posts came from gateway 202/303. These posts were flagged by the IP filter after the IPs were manually added by an admin after being passed to us by another website.

(16) This feature doesn't allow admins to retroactively see IP addresses of comments or articles already posted before the logger is turned on, even if they were obtained previously using the logger. Only ones that might be posted in the future when and if the logger is turned on by an admin will be accessible in the interface.

(17) This use of the IP logger as described above has been a subject of considerable discussion within the moderator community for some time, with a wide variety of opinions being expressed. The process was/is ongoing.

(18) It is important to re-iterate, that there has not been a systematic monitoring or logging of the IP addresses of posters (and there has been no logging of the IP addresses of site visitors).

(19) In general it would not be difficult for a suitably experienced computer user who has root access to any server or CMS software to modify the configuration or software so that it can log or filter IP addresses and do so un-detected by any other user/admin of the server or the CMS. Accordingly we think site users need to understand that there is a small risk, despite the assurances of some collectives to the contrary, that their IP address is logged when visiting any site which claims not to log IP addresses. This might be for malicious purposes or even just to satisfy the curiousity of persons with root access to the servers.

(20) All these issues concerning Indymedia websites very much apart from the real possibility that visitors to Indymedia sites are having their IP addresses logged outside of our servers. In our opinion the possibility this is happening continues to increase and is now much higher than it was 10 years ago.

(21) We believe on balance, based on current trends in internet security and monitoring and the level of trust users can and should take place in the admins of Indymedia websites, that we should emphasise the need for users of our sites to take steps to protect their anonymity and privacy. We provide some limited guidance on how to do this below and we will continue to strive to make site users aware of the current status of [FINISHED MID-SENTENCE?]

(22) We support the 2005 proposal for a 11th Principle of Unity:
All imc's shall be committed to protecting the privacy and anonymity of their users. The logging of internet protocol (IP) information about users shall be kept to the minimum necessary to maintain control over the server (i.e. in the event of an attack). In the event that logging is necessary, details of the logging shall be made publicly accessible, including duration of logging, what information was stored, and actions taken as result of the logging. Collectives are encouraged to have a public policy on IP logging.

An example of such a policy can be found here:

http://lists.cat.org.au/pipermail/imc-sydney/2005-July/002826.html

In the event of a server seizure, imc's shall make a report to imc-communication, detailing as much as possible what information was stored on the server at the time of the seizure.
Topic revision: r8 - 07 Feb 2011, ChrisC
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback