Tech-Coops at 35c3: Report and talk

Building on the first tech-coops meetup in 2017 at the 34c3 and the connections made there, even more activity around tech-coops took place at the 35c3, the annual conference of the German Chaos Computer Club which took place in Leipzig, Germany from the 27th to the 30th December 2018.

IT Kollektiv from Germany organized a tech-coops assembly inside the Komona space, that brought together a broad range of people from different places and projects.

With two meetups and a talk on tech-coops we had the chance to spread the idea of tech-coops and build new connections.

Meetups

Two tech-coops meetups took place. The first one at the 27th December and the second one at the 29th December. The second meetup was split into two groups: One discussion further international relations and exchange and a group for persons that were interested in the idea of tech coops.

Some questions that were discussed:

  • What is a tech-coop? Progressive coops vs. traditional coops.
  • How to work together internationally in the future? How to stay in contact.
  • Pros and Cons of working for NGOs.
  • How to get a coop started.
  • How to find clients?
  • Unions and political alignment.
  • Selection of software and refusal of clients for ethical reasons.

Talk: Tech-Coops: No masters, no slave

On third day we held a talk on tech-coops and the history and development of IT-Kollektiv. The talk was held inside the Komona space. Around 40 people attended and we had a good and inspiring discussion after the talk.

You can see and download the slides of the talk here.

[pdf-embedder url=“https://it-kollektiv.com/wp-content/uploads/2019/01/35c3-talk-tech-coops.pdf“ title=“35c3 talk tech coops“ toolbarfixed=“on“]

Download

Future

The tech-coops assembly and our participation at 35c3 was another big step forward for furthering connections on an international level and bringing the idea of tech-coops into more communities. Building on this we want to be back at the 36c3 and if possible this years camp with a tech-coops assembly with a stronger shared ownership of the different coops and networks.

Next steps discussed for staying in touch and working on international connections:

  • Create a digital zine about tech-coops that can be used as a place to exchange ideas and experiences.
  • Use the CoTech community disource “International Solidarity” section for communication.
  • Organize a video call

We want to thank our friends from CoTech and everyone involved with Komona for making all of this possible.

https://wiki.coops.tech/wiki/Tech_Co-ops_Assembly_35C3
https://events.ccc.de/congress/2018/wiki/index.php/Session:Tech-Coops_Meetup
https://events.ccc.de/congress/2018/wiki/index.php/Assembly:IT-Kollektiv
https://talks.komona.org/35c3/talk/FZVFSF/

 

Tech-Coops/IT-Kollektiv Assembly at 35c3

At the 35C3 we (IT-Kollektiv and friends) will again organize a tech-coops assembly inside the Komona cluster. We have our own dome with enough space for hacking and socializing, just come around.
Where to find us: Hall 2, Level 0, Komona, to the right of the Komona Workshop 4 area (c3nav)
How to contact us: The best way to contact us (besides just coming to our assembly) is via Twitter

Events

  • 27th, 20h: Tech-Coops Meetup @IT-Kollektiv/tech-coops assembly. A space for tech-coops and people that are interested in tech-coops to get to know each other and socialize. Last years meetup was a big success and we hope you can make it.
  • 29th, 17h: Talk: „Tech-Coops: No masters, no slaves“  @ Komona Zelt #workshops #handson. We talk about the how and why of worker owned tech co-ops and how IT-Kollektiv connects various collectives to create a more resilient and more resourceful network. After the talk there’ll be QA and an open discussion.
  • 29th, 18:30h: Tech-Coops Meetup: We want to meet again to discuss next steps and plans for after congress. You are also welcome to join if you haven’t been to the first meetup.

Solidarity with linksunten.indymedia.org

On the 25th of August the well known, German language open posting news website linksunten.indymedia.org was declared illegal by the German state. On the same day raids took place in Freiburg to seize computers, money and various technical equipment. The events were covered by a media disinformation campaign calling linksunten a „means of organization of militant criminals“, quoting unlawful posts by anonymous users and presenting weapons found in the raids, which in reality turned out to be a bunch of kitchen and construction equipment.

We feel the need to emphasize our solidarity with the autonomous media collective linksunten and the indymedia network as a whole, as well as all unrelated projects and individuals harmed by the raids.

There is a lot of talk about so called “spaces without law”, where the state presents itself as angel of salvation spilling their law like medicine in every corner of society and by doing so solving all of its problems. But the problems of society – injustice, repression and violence – are central results of this law. While it is e.g. unlawful to gather in the streets without permission, it is lawful to exploit employees and renters, it is lawful to speculate on food, it is lawful for the cops to beat down citizens, it is lawful to trade weapons, it is lawful to fund foreign militias, it is lawful to invade remote territory.

This is why we support spaces without the law of the state in cyberspace and on the streets. Lawless spaces are seldom spaces of violence and survival of the fittest. They are organized by communities forming their own norms, perspectives, and discourse. Social change will never be achieved through legal institutions, but by organizing solidary free or open spaces to challenge national rule.

Wrong signal (Das falsche Signal [engl])

In recent months, privacy and civil rights activists have increasingly recommended the use of Signal [1], an instant messenger app developed by Open Whisper Systems (OWS). After Donald Trump’s victory in the US presidential election in particular, many tweets recommended using hard disk encryption and the ostensibly secure messenger app Signal while discouraging the use of competitor apps Threema and Telegram. On the German news portal linksunten (part of indymedia, frequented by left activists) an article of the same tenor appeared. [2] We believe this discussion took a wrong turn at one point. Furthermore, we see a risk of unnecessarily increasing exposure of activists and organizations to repression. For this reason we wish to contribute to the debate with the following article.

We do not want to diminish the incredible service OWS has done for the instant messaging world. The Signal protocol (formally known as Axolotl) combines cryptographically secure communication with ease of use. [3] The latter in particular is something which other means of secure communication like PGP have so far failed to provide to any comparable degree, effectively preventing non-technically-inclined people to participate in cryptographically secured communication without security trade-offs.

The Signal protocol implements Perfect Forward Secrecy, encrypted off-line messaging, and file transfers, which are features expected by users today, but which have not been provided in this combination by other open source technologies like the aforementioned PGP or Off the Record (OTR) messaging. And OWS did not just provide an open source library, but also the Signal client as a reference implementation. By doing so they put pressure on other messaging client vendors to implement encryption – today many instant messaging apps are employing the Signal protocol under the hood, the most prominent example being WhatsApp – and to publish their source code.

Signal’s web page suggests professionalism and transports the message ‚Install our software and your communication will be easy & secure. There is nothing more you will need to know.‘ Users of IT systems should be critical of any kind of universal security claim. There is no perfect security just as there is no universal cure for all diseases in the world. When thinking about secure communication, it is crucial to ask oneself what kind of security is desired over all.

There are many things users can and maybe should be concerned about: Hackers, providers, promoters, crooks, spooks, shareholders or maybe the person on the next seat in the bus. Do they want to prevent their data from being used for other purposes than communication itself? Maybe they want their messages to be tamper-evident, or perhaps they want plausible deniability or immunity against eavesdropping? What is the use of end-to-end encryption when there could be a key logger or a rootkit on their device, transmitting everything they do to a remote entity?
Encouraging users to believe in a general sense that Signal makes their communication safe, will tend to promote a false sense of once-and-for-all security (regardless of the indisputable and substantial increase in end-to-end encryption). It is very important to remember that even though encryption will increase security, some information should not be stored in IT systems at all – and especially not if they are provided by a third party.

However this is no argument against the use of the Signal messenger or protocol itself. We instead want to think about the problems created or supported by OWS‘ promise of security.

Signal uses servers controlled by OWS. Other organizations could conceivably operate their own servers because OWS open sources the software, but because OWS strictly opposes federation (meaning the interconnection of independently operated servers which the XMPP protocol (jabber) or e-mail allows), only the users connected to the OWS-run server can communicate with each other. There is no way to communicate with users of hypothetical, independent servers running the Signal software but not under control of OWS. So in the end users are forced to turn over their data to a single third party, OWS in this case, risking later changes in the terms of service, intervention by the state and analysis of their metadata. Because Signal uses phone numbers to identify users, metadata is abundantly available here. If a government does not approve of the use of Signal, it can simply block a single server farm, solving the problem for the state actor, and resulting in total loss of service to the users. This is no hypothetical scenario. For example in Turkey the government is notorious for blocking web services like Twitter, YouTube or Facebook. And when looking at the recent development in the ‚democratic west‘, we realize this problem will not be limited to Turkey or China.

As we mentioned before, Signal relies on using phone numbers as a user’s unique identifier. Phone numbers are usually not anonymous, even when using burner phones or throwaway SIM cards, they always give away more information than necessary. And using phone location and call logs it is only a matter of time before users are de-anonymized. In Germany, several cases of state oppression in connection to §129 StGB (Establishment of a criminal organization) have shown that knowing who knows whom is often enough for de-anonymization and conviction. In Signal, metadata is encrypted using transport layer security (SSL) but this still requires trust in both OWS as well as the trust center as issuing entity of the encryption certificates. Another possible threat is a client compromised by government entities, revealing at least the contact list.

A third attack vector would be what German prosecutors call Quellen-TKÜ (source wiretapping) where unknown to many users state entities can legally have platform providers like Google remotely and covertly install software on mobile devices, or even slipstreaming surveillance payload into computers via known exploits. [4] Android is also notorious for countless exploits and security vulnerabilities. These problems are not just known by OWS, they are amplified by them. Signal is unique among messengers with an emphasis on security in that it relies on the Google Cloud Messaging (GCM) platform used to distribute push notifications to the client devices. GCM unfortunately requires use of Google Play Services.

The community reacted to this by developing a version that does not rely on GCM, however, OWS refused to merge the changes into the Signal code. When the project was forked, they prevented the newly established LibreSignal project [5] from connecting to Signal’s servers and prohibited the use of the term “Signal” in their name. [6] The reason for this decision can only be speculated upon.

The final point of criticism is that OWS distributes the Signal app exclusively via Google Play while actively preventing the distribution of independent builds. Even though the source code is open and available for everyone, we still have to deal with binaries built by OWS and handled by Google. The threat of potentially malicious acts by the package maintainer or distributor will remain unless independent distribution channels are allowed, enabling users to choose whom to trust.

The distribution channel policy of OWS outlined above may allow conclusions regarding the political positions of OWS, which are partially disjunct from other parts of the open source community. It seems like OWS is trying to establish a brand using the Snowden hype after his NSA surveillance revelations and to stage themselves as heroes and protectors of citizens rights. The community’s demands for decentralized web services controlled by the users themselves, or by designated professionals elected by the users, seems like a burden to them.

OWS does not primarily enter into cooperations with other open source projects, but rather corporate players like Google, who want to employ the Signal cryptography in their proprietary products, for example the new messenger app Allo. Pervasive security is not the main aim but rather a means to enter the privacy-aware niche market in order to prevent users from switching out of their ecosystem. This allows corporate players to keep monitoring users and to harvest their metadata, a primary asset. So now we have high-level encryption of the messages between the sender and the recipient, but little protection of the mobile platform clients, and no protection of the metadata. On top of this, we have centralization of communication infrastructure, allowing authorities to extort cooperation from the providers by threat of law such as the U.S. Patriot Act, or even to literally pull the plug when convenient.

The success of OWS can also be attributed to elitist and bureaucratic positions in the open source community. The standardization of XMPP is slow, and has not yet specified a single preferred native encryption standard. Workarounds like OTR were developed outside of the protocol and fail to satisfy the users in many situations. Open source projects like the Pidgin instant messenger refused to implement and include OTR in the standard distribution of their software. Often there seems to be a lack of enthusiasm when it comes to building graphical user interfaces with a great user experience for the ’noobs‘ – or else to writing and maintaining documentation. In this elitist world view, the user is seen as the developer’s opponent and embodies the necessary, unpredictable evil in the protocol stack; the layer 8 [7] problem.

It is not the case that there is no alternative to Signal when it comes to comfortable and secure communication with individuals and groups, as well as image transfer. The Signal protocol was recently ported to XMPP (jabber) and the standardization process is pending, following the XEP (XMPP Extension Protocol) process. The drafted protocol is called OMEMO and combines the advantages of jabber and Signal. Even though the XEP Process will still take some time, the protocol is stable and can already be used today. On Android devices, users have the ‚Conversations‘ client [8], which offers an experience comparable to Signal, and on the desktop there is a plugin for ‚Gajim‘ [9, 10] under active development, which still has room for user experience improvements. Using one of the readily available tutorials, it is possible today to get started on Linux and Windows. iOS users will have to wait some time due to license issues.

When using the software, users should be aware that these technologies were developed outside of the corporate sphere and without industrial cooperation. It is advisable to adjust expectations accordingly. Overcriticising would be like complaining about a missing elevator in the neighbor-operated community center around the corner because the subsidized opera house has had one for years. When in doubt, users should ask a friend for help with setting things up. Grassroots solidarity can never be replaced by technology or elitist attitudes of lone crypto-heroism.

[1] security tips for protesters (EFF, 16.11.2016) https://www.eff.org/deeplinks/2016/11/digital-security-tips-for-protesters

[2] Empfehlung für Signal: „Zur Benutzung ’sicherer‘ Messenger“ (indymedia, 4.11.2016) https://linksunten.indymedia.org/de/node/195943

[3] Kryptoverfahren (Heise, 24.11.2016) https://www.heise.de/newsticker/meldung/Entwickler-dokumentieren-Krypto-Verfahren-des-Messengers-Signal-3501150.html

[4] Update Section in Legal Information of Play Services https://play.google.com/about/play-terms.html

[5] Kommentar Moxie Marlinspike (17.06.) https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-226646872

[6] Kommentar Moxie Marlinspike zur Verwendung des Namens in LibreSignal (5.5.) https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165 

[7] https://en.wikipedia.org/wiki/Layer_8

[8] Android XMPP Messenger App Converstions https://conversations.im/

[9] Cross-Plattform XMPP Client Gajim https://gajim.org/

[10] OMEMO Plugin für Gajim https://github.com/omemo/gajim-omemo