Process for the new UK server

There are plans to get a new publishing server to host Indymedia Mir production sites for ImcUk, Biotech, Euskal Herria and others.

This page is somewhere to sort out the process for managing this server, process, legal and associated issues.

The current plan has been to have a contract between the NL 'Friends of Indymedia' and Calyx (for more info see the UkHostingComparisons#Calyx page and also the notes and logs from a IRC meeting with Calyx: MirServerMeeting20041203) and a group of liasions made up from IMCs hosted on the server and this plan currently hinges on the 'Friends of Indymedia' supporting this idea...

However, thus far, there has not been any communication from 'Friends of Indymedia' so imc-uk is now starting to look (again!) at the possibility of hosting at the Seattle Community Colocation Project, which is associated with the riseup krew. They have previosly offered to help with maintaining this for us. hence, a proposal has been made (and seconded!) that the uk colocates in seattle. Tech (hardware) issues are to be sorted out on imc-uk-tech and on the UkRiseupServer wiki page.

For background and related information see UkHostingComparisons (ISPs), UkDatabaseServerBreakdown (money), UkCrypto#Hardware and UkLegalConstitution for an extensive discussion about providing a 'legal buffer' between IMC and the authorities and also the imc-uk-process and imc-uk-tech archives from December 2004.

Liasion Structure

First ideas...

This was posted to imc-uk-legal and then forwarded to imc-uk-tech and imc-uk-process:

The events of the last years like the Ahimsa-seizure, the request by the Dutch police to get an IP number, but also cat at lyst decision not to host imc brisbane anymore show that there are much more things that can come up besides keeping the machine running in good order. It also shows that in such cases the additional work and responsibilities can suddenly just fall back on one or a few persons. Like jebba who has to deal with all the legal stuff around ahimsa, because he's the only one who signed the contract, or the sysadmins from cat at lyst who had to decide who of the fighting parties should have the passwords.

I think we need to develop new structures to avoid that, and to spread work and responsibilities on more shoulders.

For the day-to-day running, I think the sysadmins should have all the power to make the decisions they find necessary, and especially when they act as "technical support" for another IMC it should be their decision to host these sites on the server.

Besides that, I think it would be good to have a group with a liason from each IMC that is hosted on the site. This liasons can be contact for any legal matters, any decisions that need to be taken for example if the police wants a copy of files, but also for example if access for individuals needs to be restricted. On the other hand these liasons are also obliged to inform others if they are in any problem that might compromise the server. It should thereby also be clear if any additional projects are hosted on the site, so that we don't suddenly hear that there's also somebody's complete mail archive on the server (to quote a recent event).

If the role, responsibility and intention of such a group is written down, it probably also has some legal standing, so that we don't come into a situation like now where people think that IMC-UK can't say anything about Ahimsa, because Jebba signed the contract.

About the question who should or could sign such a contract: In the Netherlands, there is a foundation called "Friends of Indymedia" that was set up 3 years ago as owner of the indymedia.nl domain when it was not possible for private persons to own .nl domains. It only consists out of the legal minimum of 3 people. It should be possible that the liasons of IMCs join this foundation.

"Friends of Indymedia" might sign such a contract, if there are clear agreements about the responsibilities. This goes especially for finances, as well as for legal issues like an agreement that a liason of the IMC in question contacts a lawyer if necessary etc. (Sorry if i keep on coming back to lawyers, but it currently puts a lot of extra work on those inviduals who have to deal with them.)

Practical questions

Who decides about

... hard and software of the server, updates, safety etc? the techies who actually admin the server, in communication with the local collectives, for example to avoid work on the server on times that are crucial for local IMCs, or if safety measures like logging might contradict local policies.

... which IMCs or other Indymedia 'services' are hosted on the server? the techies in consensus, especially if they work with a new collective, but new sites etc should be announced to the local collectives

... access to the server? the techies for access to the server, the local collectives for access to the admin interface.

.. excluding individuals or sites from the server? a set of rules should be developed as a guideline to withdraw access to the server for individuals or to stop hosting a local site, like the need to work in accordance with the Indymedia PoU, not to compromise the server, not to volunteer personal data uness consensed upon, not to threaten other users and admins etc. (for this it might be good to take experiences into account from cat/imc brisbane, arc/berkman, perth/manila, ansti/germany...). decisions about individuals should be taken together with the local collective, those about whole collectives by techies and local collectives together. this does not need to result in fixed rules, but at least in some guidelines that avoid unilateral decisions

Who carries responsibility for

... the content and editorial policy of a local collective? the local collective - therefore it's necessary to have a liason and a contact for each local IMC (including a postal adress to forward any letters), and a from of formal commitment of each IMC to keep contact info updated (and changed in case the liasons are away for longer time) adn the commitment to take up all legal communication etc without delay, so that it does not end up with the signatory of the contract. This needs to work out so that authorities will accept direct communication with any local collective.

... informing the techies and other IMC about possible (legal) problems? each IMC has to inform the techies and other local collectives immediately if any request by the police or other authorities comes up about IP numbers etc, or anything else that might compromise the server, might make it subject to external logging etc... that's what we need a list of liasons for

... dealing with cops, lawyers etc? the IMC in question. The signatory can give contact info of each IMC to authorities if needed, instead of taking calls, letters or lawyer visits themselves. It is the responsibility of each IMC to deal with problems themselves instead relying on the signatory as last tracable person. IMC who are not willing to do that, will have to find another server.

IMCs

Several IMCs which use Mir have committed to being hosted on this server:

And some are considering it:

  • Poland

Email Lists

It might make sense to have a couple of email lists dedicated to the server, one a process list for the liasions from each IMC hosted on the box and one a tech list for the people doing systems administration on the box.

The process list would probably be low volume, both these lists might have closed archives, the process one so that legal issues can be discussed and the tech one so that stuff relating to attacks on the box can be discussed without attackers being able to follow what is being done...

It is common for legal lists (imc-legal and imc-uk-legal for example) to have closed archives and also for server specific lists to have closed archives (kosmos-sysad and ahimsa-tech lists for example), any tech stuff that doesn't need to be on a closed list should be done on imc-tech, imc-uk-tech or mir-coders.

On the other hand there is a imc-calyx list that has been set up with close archives and there is a closed imc-mir-admins list and everybody is already on a lot of lists already...


-- ClarA - 16 Dec: added practical questions

-- MayleR - 07 Dec 2004
-- GarconDuMonde - 06 Feb 2005 - update to include info on seattle colo</br />
Topic revision: r11 - 25 Dec 2005, WietsE
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