We should have a Digital Struggles Semi-Plenary to put it all together.
Infrastructure (physical layer)
Mobilisation for Server Defense
Adressing the fracture between users and admins.
Visibility of Server Struggles
How can we connect geek fights with other struggles in the wider movement?
Alternative community-driven internet access providers
While providing internet access for local communities has mostly been a matter of providing a low-cost solution by sharing access and costs in the past decades, it is now again becoming a neccessity, but for different reasons. European data retention laws allow governments to snoop on who connects to whom, and to retrieve this information from your local Internet access provider, which makes it difficult to work around this information being gathered.
This creates a new need for founding local internet access providers. The data retention legislation allows small (less than 1000 users) and non-commercial internet access providers to operate without a need for providing direct 24/7 access to an expensive black box for the snooping activities of the governments. Also, shared accounts and wireless LANs may allow for making it impossible to legally circumvent identification of single internet users. We can also learn from the past and from existing projects here. Reports on how community driven access providing has worked in the past and is working now will be of help in working around issues others have already encountered and overcome.
Reforming local internet access communities is a very important counter measure to the growing surveillance activities of organizations which think you are guilty until proven otherwise.
System administration / core services (system layer)
A security policy for internet service providers (Alster)
A risk assessment will be the first step of analyzing the risks radical tech collectives and activist ISPs have to cope with currently and will have to do so in the intermediate and medium term future. The goal of this workshop should be to create a list of security measures every ISP should take toabide to to provide a long lasting service, which allows both providing and using secure and anonymized online services in a way which will not cause long lasting harm on any of both involved sides (service users and providers), and which involves a realistic amount of financing.
How should servers and dial-in lines be maintained, which security measures should be in place? How can a fail-safe system be designed which will allow us to sleep well even with increasing repression? Is it ok to force users into explicitly using encrypted services even when it means they may not be able to use their most loved toys (as those lack support for this very service)?
The new threat model (Alster)
Impact of data retention and counter measures What exactly is the impact of the new data retention legislation? What is going to change for people in europe? What similar law is there in other locations in the world? How have people organized there to minimize the negative impact it causes? What kind of repression becomes possible by this new legislation? How do we need to react to it? What counter emasures are there?
Solidarity Protocols (Txopi)
We could try to design some kind of protocols to help servers to each other and react to machine seizures and other kind of attacks. This protocols could be preventive (emergency mailing lists at other server, ...) and reactive (fast mirroring agreement between two servers if external help is needed, ...).
Servers Global Action Ring (Txopi)
Just a funny name to call a list of autonomous servers that would want to coordinate with the others and act globally when one server of the ring is at risk of seizure and situations like that.
R*Plan (ale, Blicero)
Decentralised server layout built by Autistici/Inventati.
Tools and applications (application layer)
Indymedia history project (Clara)
We can post our own articles about what is happening right now, but who is writing our own history? More and more often some of us are asked to write articles for some book, and there is a book in the making but nearly all of that are written in a traditional form: one or a few authors write for an editor. On the other hand there are some first ideas about an "Indymedia history" site (for the UK by Yossarian, http://tachanka.mine.nu:300) or about wiki pages (by toya). A discussion and maybe some practical work on it - Clara
Indymedia as service to a movement
Where stands Indymedia in a time where everybody can just set up a blog in 5 minutes? How do we move forward from here? Can an IMC be a service during a big event (like the legal team, the street medics and the kitchens) and something else during the other 360 days of a year?
Indymedia CMS 2.0 (Elijah, bonzai)
There's some discussion about stopping to use specific CMSs developed for Indymedia: http://techmeet.sarava.org/English/Notes, http://cats.revolt.org/cats-vii/indymedia/ and some work on plone/zone. Maybe somebody can give an update on it (as well as on the new radar), and some discussion what different (types of) indymedia voluteers consider necessary to have and/or improve - mentioned in mails of bonzai, elijah and alex
Dispatch system (Clara)
What are the requirements that we as users need of a dispatch system? What are typical situations? I would like to get together with some people how have done dispatch and define a list of criteria and to write up a few case to give to those people who want to write a dispatch system as a better basis to develop them.
Servers, contracts and who signs them (ionnek)
What kind models have been developed to set up servers? Who signs the contract with the internet service provider? Who gives their name: an indivual, an existing or non-existing group? What are the legal advantages and disadvantage? And what can Indymedia learn from the experience of other groups on this issue? What can Indymedia (and its network of supporters) do to support a global infrastructure of 'left servers'? - based on ideas from Ionnek
Tagging and tracking
What are experiences with RSS feeds? Are they used? How can one access postings on the same topic on different Indymedia sites (and maybe also on other sites). As experiences from biotech.indymedia show: rss feeds don't really work here.
Dispatch system (Clara)
What are the requirements that we as users need of a dispatch system? What are typical situations? I would like to get together with some people how have done dispatch and define a list of criteria and to write up a few case to give to those people who want to write a dispatch system as a better basis to develop them. - Clara
Meet & Greet
Can we get all people together who are somewhat connected with Indymedia for a "real life chat"? Getting together to connect names and faces, sometime in the beginning of the meeting, informal with some drinks.
Bring your pgp key, or make one while you are there.
Metche (Lunar + Ricola)
A configuration monitor to ease collective administration. Metche is both a pratical tool to monitor the changes made to your system and an organisational method for collective administration. How to put into question the "root = 1 übergeek" paradigm?
DNS Autonomy (maxigas)
As many of you may now, the Chamber of Commerce of the United States of America holds the final rights to determine the contents of the root zone file. The root zone file defines the available TLSs (Top Level Domains) like .net or .fr. One can easily imagine what enormous power is that.
There is an international process to change that situation. The United Nations held a two part conference entitled World Summit on Information Society (2003 Geneva and 2006 Tunis) which kick-started the transformation of Internet Governance structures. After a field-report on the DNS front we could asses the relevance and significance of the WSIS/IG process to our work and existence in hyperspace.
An activist online security policy (Alster, Loquito)
How should activists behave online, what should they do, what not? Which policies should we always keep in mind? Which software should we use, which should we avoid? Can we work out a general security policy which may serve as a daily reference for online activists, a general document which names the dangers and explains how they can be worked around, lightweight enough to bring it to your the internet cafe? (Alster)
I'd like to lead an discussion on general activist internet security, both on personal computers, and when travelling/using internet cafes. I use some tools and was researching a few more programs to prepare for this, but would also love to hear more ideas and practices from other people (especially about WiFi). My view is that this would be a discussion among generally technically minded people. My main goal would to get a comprehensive set of information that we (me and hopefully a few more volunteers) could compile into a pamphlet on internet security for activists that could be distributed at the general PGA gathering. (Loquito)
Block device encryption for the masses
The process of encrypting firmly installed hard drives as well as portable storage devices such as USB HDDs and pen sticks is a neccessary prerequisite to create and maintain a (partially) repression safe working environment. As many activists as possible should be using encrypted partitions and file systems. Unfortunately, this is not yet the case for many activists, because it is not easy to set up encrypted file systems in a usable and secure way. It is, however, possible. With the advent of DMCrypt and LUKS encryption it is much easier to create well-manageable encrypted devices. However, knowledge on how this is actually done is still not very well distributed. The most practical question an activist will ask is probably this: "How can I easily transform my current disk drive / partition / file system into an encrypted one?" Is there a definitive answer to this? Can a user oriented, user friendly pictured guide be worked out which will allow an activist with mediocre tech skills to apply these changes to her system herself? Can this be translated? How can this be made a lovable tool (GUI allowing management + showing encryption strength, encrypted tux icon...)?
Each of these topics should be prepared by one person/group and should at least cover the following aspects: * Overview * Protocol * Usability * Abilities and Limits (functionality, compatibility, laws) * Pros and Cons
The following is an incomplete list of potential topics in this category: * TOR * Freenet * Darknets * Mixminion
In addition, a global overview and comparison and evaluation of these anonymization methods should be prepared. This may also include a longer discussion to work out different perceptions of what is most suited for different needs.
Secure communication without loss of privacy
The issues caused by SSL certificates and how to deal with them - To retrieve a valid SSL certificate, you need to register with a valid Certificate Agency. Certificate Agencies (CA) require that you provide information which makes you personally identifyable, both to the organization running the agency as well as to the world through public certificates they create for you. This undermines any attempt to protect the privacy of the server maintainer(s) by means of anonymization.
Self-signed certificates can work around this problem, but they are not trustable, as this system relies on the fact that the validity of the identity of the server maintainer is ensured. Is there an alternative solution which can be easily implemented on both server and client side, or can a compromise for the existing Public Key Infrastructure (PKI) been found?
How do we work together in the real life? Whom do we trust and whom don't we trust and what are the criteria for this? How do we develop such lines of trust? How can this workflow be transferred to the 'online world'?
Would a CA which is run commonly by alternative projects, which uses nicknames instead of real names work? How could be made so that the certificates it generates have some value, i.e. how can it be made so that it is reliable that the person they are made for are actually the ones who run the sites they are used on?
An activist online security policy
How should activists behave online, what should they do, what not? Which policies should we always keep in mind? Which software should we use, which should we avoid? Can we work out a general security policy which may serve as a daily reference for online activists, a general document which names the dangers and explains how they can be worked around, lightweight enough to bring it to your the internet cafe?
Alster Indymedia.de, Tachanka! Hamburg, Germany
Clara Indymedia.nl Neitherlands
`Alster <email@example.com>`_ Hamburg, Germany Indymedia.de, Tachanka!
I'm a politcally and technically interested and active guy living in Hamburg, Germany. I'm aged around 30.
I'm slightly involved with IMC Germany, the local Indymedia center in Germy (there is only one currently, which may change in the future). I take part in some Indymedia tech working groups such as
- Listwork, the working group maintaing lists.indymedia.org mailing
lists, and indymedia.org email address forwarders (aliases), as well as the underlying mail server.
- IRCd, the working group running the irc.indymedia.org IRC server(s)
and possibly other real time communication tools
- IMC Docs, the working group which used to maintain the Indymedia Wiki
at docs.indymedia.org (currently hosted in a backup location with no write acccess) and hopefully will do so again if the server ever gets fixed
- IMC Security, the working group which discusses Indymedia related
security topics which cannot be publically discussed (on a low traffic mailing list) and collectively creates and maintains documentation on how to secure and harden tech infrastructure (http://docs.indymedia.org/view/Sysadmin/ImcSecurityDocs).
Some more info on me and my involvement with Indymedia is available at
Not too long ago I also helped starting up a new radical tech collective named Tachanka! (www.tachanka.org). Unfortunately, this hasn't gotten very far since, as we're continuously fighting with the server hardware.
I'm very much looking forward to meeting and possibly getting to know some of you personally in Dijon!