20 years ago tomorrow, the website for the first IMC (Independent Media Centre) went live at www.indymedia.org, providing a globally accessible platform for independent media coverage of the protests against a WTO summit in the US city of Seattle. Appearing even before the creation of Wikipedia and its MediaWiki software, Indymedia.org was a pioneering example of the then-novel concept of the web as a read/write medium - where anyone could contribute using basic cut’n'paste skills - rather than just a collection of read-only pages made by geeks. Seven years before the founding of Wikileaks, the open-publishing newswire on indymedia.org was one of the earliest forerunners of “citizen journalism” platforms. It can also be seen as one of the earliest experiments in both the practices and technologies of “social media”, producing among other innovations, the technology that gave birth to Titter.

That drive to empower people to create and share was reflected in a commitment to using software that was open source (a newly coined term at the time for Free Software, or as I tend to call it free code) and this became one of the core Principles of Unity for the emerging IMC network. Indymedia.org started out running on a patchwork of webserver software known as Active, originally strapped together by a collective of hackers in Australia, for a local cluster of activist news and event announcement sites. As more IMCs started up to run open-publishing activist news sites for their city or country, this bleeding edge software was gradually replaced by a variety of CMS (Content Management Systems) written specifically for Indymedia, before these were in turn replaced by more general purpose free code CMS like Drupal.

I could into much more detail on all of this from an insiders perspective, and in some ways this would be the ideal time to finish writing up a detailed retrospective article I’ve been planning about the Indymedia network and my time as a founding volunteer for the Aotearoa IMC (which ironically seems to be down today - maybe because it’s already N30 there?). However, I’m currently busy preparing for a long international trip, home to Aotearoa to see family and friends, and then back to China via the FOSS Asia Summit in Singapore. Besides, I’m already seeing plenty of articles being published to mark the 20 year anniversary, so I think I’ll keep my powder dry, read a bunch of them, and focus my piece on any aspects of the Indymedia story that don’t get as much attention or fanfare as I think they deserve.

It has to be said that at 20, the Indymedia network is a shadow of its former self. Many of the sites that served the news gathering of local IMCs, as well as most of the servers that provided collaboration tools for global networking, are long shuttered and gathering digital dust. I haven’t been actively involved in the Aotearoa IMC I co-founded since about 2007, and although the site continued to operate (at least until very recently), I stopped publishing there altogether when the newswire became a flood of seemingly unmoderated noise, dominated by a handful of chronic spammers. But there are signs that a phoenix could rise from the ashes. Indymedia.org, which had until recently been frozen in time since 2013, now bears as promise that “Indymedia.org is being rebuilt”, along with links to a bunch of 20 year anniversary articles.

As with the CMS, so many of the technologies Indymedia activists wanted and needed during the first few years of the network have now been developed to greater maturity by open source communities.

When activists started publishing their videos on YouTube to get them to a larger audience, and to reduce the strain that streaming large media files placed on Indymedia servers, Indymedia geeks dreamed of having a decentralized, free code tool like PeerTube. One that can be used to run video-publishing sites that are independent, but federated into a larger network. Where videos can be found and viewed across the whole federation, not only on the one where it’s first published. Where sites can mirror each others’ videos to route around attempts at censorship. Where users contribute a little bit of their own bandwidth to help the servers if a video goes viral, avoiding the lose-lose scenario where every time you get a video out to a large audience you lose money, or risk having servers go down and sites go offline. Where video channels can be followed and videos commented on by users on other federated platforms like Mastodon. 

But technology was never at the core of Indymedia. The sites we ran were more than blog farms, they were always understood as  a means to a larger end. When we said “don’t hate the media, become the media”, Indymedia activists were articulating a vision of democratized media that could have a democratizing effect on a rapidly globalizing human world, one whose politics and everyday life was becoming increasingly ruled by corporations.

As the public - and especially activists - become increasingly aware of the downsides of Surveillance Capitalism, we have a unique opportunity to remind them of this vision. It’s also worth reflecting on the Achilles Heel of the Indymedia project; it’s lack of a sustainable economic base, and the resulting dependence on donations and volunteer time to keep its growing infrastructure running. For the grander vision that animated Indymedia to be realized, sharing economic solidarity strategies like forming Platform Cooperatives will be just as important as promoting the potential of decentralized technologies like PeerTube and other fediverse tools like PixelFed and Mastodon, perhaps even more important.

Here’s the report for our fourth voice chat testing session. So far we’ve been publishing these reports on write.as, which theoretically allows them to be seen from the fediverse, although I haven’t yet figured out how that’s supposed to work. One of our members has set up a Hubzilla group, which we intend to start using for organizing ourselves and publishing our reports in a way that will be easier to find and search through. More details once I’ve figured out how to join and use it myself ;)

Despite growing the number of people lurking in the Matrix room, we only managed to get two of us together for this test. Three people is enough to determine whether an app can do group chat at all, but to really stress test group chat functionality, we need groups of 5 to7 people, if not more. Hopefully we can get some larger groups together for testing sessions after the holiday season is over, and folks aren’t so busy.

Sunday 9 November, 2019, 12:00 UTC

Candidate: Linphone

Previous Session: Test Session #3

Comments by: @strypey@mastodon.nzoss.nz

VOICE (VOICE Organized Investigation of Chat Engines) is an informal app testing group, trialing free code apps to see how well they handle voice chat, especially with groups. We aim to have a group chat testing session at least once a month, usually during the weekend, although other times can be set up if anyone is keen. We currently use a Matrix room to confirm the timing of testing sessions, as well as for discussion about available apps and related topics: #voicechat:matrix.org

For our fourth testing session we had only two testers, one in Europe, and one in China. Both testing with desktop GNU/Linux and an Android/Linux mobile device. We had decided to test Linphone, which began as a desktop voice calling app for GNU/Linux (thus the name; Lin[ux]phone) that works by connecting to a SIP server. As the project evolved, it has developed mobile versions, added video chat, and more recently text-based instant messaging too, all using the SIP protocol.

As far as I understand how SIP works, we would have been able to chat to each other using accounts on different SIP servers. But for the purposes of this test, we used SIP accounts provided by linphone.org, to ensure that unusual compatibility issues between Linphone and a third-party server didn’t prejudice the results of the test. Because only two testers were available, we weren’t able to test group chat, so this report focuses on the overall UX and the performance of the one-to-one group chat.

The first thing that became very clear is that the GNU/Linux version of Linphone doesn’t get the same level of developer priority as the other versions. I have been unable to get GNU/Linux Linphone to connect to linphone.org at all. Whatever I tried, it would say it couldn’t open the port it was trying to connect through. In my case, that may have been because I was using an outdated 3.6.1 release, installed from the Trisquel 8.0 repos (based on Ubuntu 16.04). But Naughtylus was also unable to get Linphone working on GNU/Linux, using the 3.12 version available on Nix. In the end, he resorted to using WINE to run the Windows version (4.1.1, using Qt 5.9.0 and “Core” 3.12.0).

After I gave up trying to get the GNU/Linux app connecting, I switched to the Android app, which I installed from F-Droid. I had an odd issue where it wouldn’t install the latest version (4.0.1), so I installed the last version before that, hoping I could then upgrade. Nope. A few days later I refreshed my F-Droid app (long story) and was able to upgrade, no idea why it wouldn’t work before that. Anyway, for this test, I was using Linphone 3.3.2 for Android.

I found the Linphone app to be very demanding of permissions that I’m not sure it needed. It’s totally understandable that it asked for access to the microphone when I actually started a call. But as soon as I opened the app it wanted permission to use my camera, and asked twice. As soon as I tried to add Naugtylus as a contact so I could try calling him, the app wanted permission to access the device’s default contacts app. This is the first chat app I’ve installed from F-Droid that seems unable to handle its own contacts without demanding contacts permissions.

So I got Naughtylus to call me instead. We were able to have a sustained voice chat for more than half an hour at a time, with me on Android, and him calling from both the Android version of Linphone and the Windows version running in WINE. I’d be curious to test Linphone again with a group, after we’ve done some investigation on how to get the latest versions installed and working, and maybe set up SIP accounts on different servers, so we can test SIP federation.

Overall, I’d rate my first voice chat experience on Linphone as about equivalent to using Jami or Tox. On all three, audio quality and call reliability is pretty good, but the UX has room for improvement. I wouldn’t recommend any of them to a non-geek average user at this point in time. But in the case of the Linphone team, that probably wouldn’t cause many tears, as it seems like their main target users are businesses paying for support contracts.

Filed November 27th, 2019 under free software, open source

 There’s been a lot of wailing and gnashing of teeth over the last few months, about how to deal with an infamous, far right social network site. Before I say anything else, I want to make it clear that my politics have been staunchly leftist and anti-racist since my childhood. I find the politics of the site in question appalling, and I have no intention of promoting their toxic brand, even when criticizing them, so I will refer to it here as Cess.pit.

 A little background. As my three regular readers will know, I’m an excitable champion of the federated social web, the fediverse to its fedizens. Unlike users in centralized platforms like FaceBook or Titter, users of the fediverse join an “instance” - a server running web software compatible with fediverse protocols like ActivityPub - but they can follow and communicate with users on other instances, run by completely different people. A few months ago, Cess.pit moved its users to a fork of Mastodon, one of the most popular of the various software projects that use ActivityPub, potentially allowing them to recruit from and harass users on other instances.

 The admins of many instances responded to news of this by adding cess.pit to their blocklists. This isn’t unusual. The servers that host our email use blocklists all the time against mailservers that send lots of spam or virus attachments. I believe that the power to block users and instances ultimately belongs in the hands of the users of social network software, but given the current state of federated network software, I’m fine with instance blocks. So long as they’re being used by admins to prevent things like spamming, flooding, and harassment, for the benefit of their users, not to police who their users can communicate with, for ideological reasons those users may not agree with.

  I think it’s worth pointing out that treating all Cess.pit users as if they were all committed fascist organizers does have downsides. A lot of young or politically naive people wander into online spaces like Cess.pit without really understanding how deep those particular rabbit holes go, and these are the “prospects” the actual fascists hope to indoctrinate and recruit. If Cess.pit is federated with at least some instances that aren’t full of fascists and sympathizers, prospects will be much more likely to get access to other perspectives, making it more likely that they will broaden their minds, realize who they’re hanging out with, and get out. If the only people users on Cess.pit can talk to is each other, chances are that actual fascists will find indoctrination and recruitment much easier.

 The other thing that happened is that the developers of Tusky, one of the mobile apps that can be used to connect to instances of Mastodon (and other fediverse software that uses the same system for communication between apps and servers), decided to add a blocklist to their code and add Cess.pit to it. I wasn’t the only person who was sympathetic to their reasons for doing this, but concerned about the possible unintended consequences. Let’s unpack that a bit.

 Let’s say a Bad Actor wants to shut down queer leftist GroupX and stop them communicating online. They publicly smear them as “terrorists” or “spreading kiddy porn” or whatever, and start approaching hosting platforms and software developers, demanding they take action to stop GroupX using their tools.

 Let’s say they approach Mozilla about building anti-GroupX blocks into Firefox, during the time when Brendon Eich was CEO. Brendan is going to say “no”. Because even though he’s right-leaning and may well disagree strongly with the politics of GroupX (which is why he was forced out of the CEO role at Mozilla), there is a longstanding principle in internet tech that we don’t implement political blocks at the level of code and network protocols. Those are decisions to be made autonomously by users (network or “bottom up” decision-making), not centrally by engineers or system administrators (pyramid or “top-down” decision-making).

 The principle does mean, in theory, that free code developed by leftist anarchists could end up getting used in some way by fascists. But unless you empower the state to maintain a register of fascists and stop them using the net at all, it’s unavoidable that they are indirectly using all sorts of free code, developed by people from all sorts of backgrounds, who have all sorts of reasons to be horrified by the idea of fascists using their code.

 When you stop and think about it though, its obvious that the opposite is going to happen much more often. Radical leftists do not develop the majority of free code software. Every day we are directly and indirectly using all sorts of free code, developed by people from all sorts of backgrounds, who have all sorts of reasons to be horrified by the idea of us using their code. But they don’t try to stop us, for the same reason I believe Brendan Eich would have said “no” in the hypothetical example above. They understand that the whole purpose of defending software freedoms is to prevent powerful groups from using their monopoly on the money and infrastructure that funds most software development, to enforce their politics on its users.

 So what happens when developers start implementing political blocks at the code level, as Tusky did? Do the ends justify the means?

 In the short term, even if every fediverse app followed the Tusky example, life becomes mildly inconvenient for the Cess.pit folks, who can just start distributing their own forks of their preferred apps from their own websites. In fact, they’ve now set up their own app store. No real harm been done to their operations. But in the long term, it starts to normalize the idea that its OK to use the roles of developer, engineer, or hosting provider, to police other people’s politics.

 Imagine if all the technical folks who disagree with radical left views started doing the same things to us, that some of us have done to the users of Cess.pit. Imagine centrist liberal CEOs at Mozilla, Goggle, Apple, and Microsoft, building blocklists of radical left websites and media outlets into Firefox, Chrome, Safari, and Edge. Imagine we had to develop all our own software and host all our own infrastructure, and try to convince other users to only use fringe apps and hosting platforms that don’t have built in censorship of our politics. This is incredibly threatening to the radical left - far more threatening than Cess.pit itself.

 This is why a lot of people in the ethical tech community disagreed with the Tusky dev’s decisions, even though we respected their right to make it, while the developers of other apps decided instead to respect the longstanding principle of political neutrality discussed above. This is why many of us were horrified when developers who chose not to hardcode blocks into their apps became the target of coercion by some radical leftists, like those who tried to get Fedilab removed from app stores by claiming its developers “explicitly chose to enable hatred and violence through their app”.

 These smear campaigns and false accusations are appalling in themselves, exactly the tactics of the Bad Actors I described above. But even worse, to the degree that they are successful in the short term, they risk massive damage to the prospects of the radical left in the longer term, for reasons described above. They also do massive damage to the sense of goodwill and common cause that convinces people who could earn massive salaries in the corporate tech industry, to spend their spare time - or take more precarious jobs - to write free code that benefits all human beings. Including radical leftists.

… and yes, sometimes including fascists. But for the reasons discussed above, I think the benefits of that far outweigh the costs.

Filed November 20th, 2019 under open social networks, free software, open source

Update 2019-11-29: I did some live-posting from Netizen21 on the fediverse, as net connection and battery life allowed.

——————————

I had the pleasure recently of being invited to attend Netizen 21: Beyond Personal Account, the fourth annual conference of The Institute of Network Society, based at the Chinese Academy of the Arts in Hangzhou, China. It starts this Friday, 22 November, and winds up on the evening of Sunday 24, after three days of what looks to be a fantastic program of talks, panel discussions, and workshops. Hangzhou is a beautiful city, and while I probably won’t get much time for soaking in the sites this time, It’s a pleasure to be visiting.

I’ve managed to get to a couple of conferences since relocating to live in China - Open 2018 in London and the Platform Cooperative Consortium annual conference in Hong Kong - but this is the first one I’ve attended on the mainland itself. I’m embarrassed to say that due to the challenges and culture shock of adjusting to life in a new country where I don’t speak the lingua franca, I still haven’t organized myself to write anything about the previous conferences. So given that all three of these conferences have a lot of common threads weaving through them (pun intended), especially the growing interest in platform cooperatives, I will take copious notes over the weekend, aiming to write up a piece that covers all three. Third time lucky?

Filed November 19th, 2019 under News

Here’s the testing report for the third VOICE scheduled chat testing session.

 Saturday 20 Oct, 2019, 8:00 UTC

Candidates: Wire, Tox 

Previous Sessions: Test Session #1 (Riot), Test Session #2 (Jami) 

Comments by: @strypey@mastodon.nzoss.nz 

VOICE (VOICE Organized Investigation of Chat Engines) is an informal app testing group, trialing free code apps to see how well they handle voice chat, especially with groups. We aim to have a group chat testing session at least once a month, usually during the weekend. Our next session is scheduled for Sunday 2 November, starting at 12:00 UTC. We currently use a  Matrix chat room to confirm the timing of testing sessions, as well as for discussion about available apps and related topics: #voicechat:matrix.org

For our third group test, we had three testers, two on GNU/Linux, and one on Android/Linux. One in China and two in Europe.

Wire group chat

Wire is a centralized (client/server) system, like Signal or Mumble. One of the testers on GNU/Linux stress-tested the Wire client (Electron) by running a number of other internet services at the same time, including Riot (Electron), a Tox client, Jami client, and BitTorrent client. The other GNU/Linux tester tried both the Electron client and the web client in Firefox. The Android/Linux tester tried both the native app and the web client in a Chrome fork called Bromite.

Although our original goal for the session was to test Tox, two of our testers happened to be trying out a one-to-one voice chat using Wire when the session began, so we decided to give that a quick test first. But we quickly discovered that in Wire you can’t invite a third person into a one-to-one chat.

You first have to create a text chat group, then start a voice call from inside that group, using the usual phone button. Once a voice call is initiated this way, any user who is a member of that chat group can join the call at any time, by clicking a green ‘join’ button. The first time we tried this we ended up with one tester being able to hear the other two, but those two were not able to hear each other. On subsequent tests it worked fine, so it may have been a “race condition” bug, perhaps caused by the stress-testing mentioned above.

The sound quality and consistency of the voice call was pretty good, but overall it didn’t seem any better than Jami. Again, this may have been because of the stress-testing. We could hear each other fine most of the time, even when we started to speak over each other, but the sound did occasionally glitch out, creating situations where one tester could hear the others but not be heard. Wire voice chat has excellent echo cancellation. It’s one of the few free code voice chat apps I’ve been able to use comfortably without headphones. But this may also contribute to a loss of audio quality in group chats.

Tox chat

Tox is a distributed (peer-to-peer) chat system, like Jami. But unlike Jami, Tox is a protocol and a core library (Toxcore), implemented in a number of independently developed clients. One of our testers tried qTox on GNU/Linux, one using TRIfa on Android/Linux, and the third tested with both, using different accounts.

After a bit of tinkering, we came to the conclusion that TRIfa doesn’t to support group chat at all. On qTox, there’s a button for creating a text chat group, and it seems like that’s necessary to create a group voice chat. Sadly, our Android/Linux tester didn’t have a net connected desktop system available, so we weren’t able to get more than two people into a text chat group, or test a group voice chat.

That said, one-to-one text chat performed better in both the Tox clients we tested than in Jami, the messages arriving more reliably, and providing a smoother overall UX. It will be interesting to see how group text chat compares to this, when we get a chance to test it. Two of us had previously tested a one-to-one voice call between qTox and TRIfa, including a period of video chat, and were impressed with the call quality. Since we couldn’t get all three test participants into a group, we ended up testing a one-to-one call between two qTox clients for more than 1 ½ hours, with only two or three minor glitches.

This bodes well for group voice chat over Tox, but next time we try to test that, we need to make sure all the participants have at least one client that supports both group text chat and voice chat.

Next session and future plans

Our next testing session is scheduled for this Sunday, 3 November, at 12:00 UTC. Check in with us on Matrix if you’d like to participate. For those who don’t use Matrix, we’d love to have our chat room bridged to a Jabber MUC or an IRC channel if someone can help us set that up. We’re also looking at setting up a presence on a Friendica or Hubzilla instance, where we can post these “official” testing reports, and maybe host a wiki, calendar, and other services related to the testing group’s activities.

Filed October 29th, 2019 under Uncategorized

Just a short message to let folks know I’m back in the studio. If anyone dropped in over the past few days, you will have noticed we had some issues with our hosts CoActivate. Touch wood, these seem to have been resolved.

Filed October 22nd, 2019 under News

I’m going to be taking the rest of the month off, and since Disintermedia remains a one-man-band, that means it will be dormant until then. When I return, I need to give some serious thought to the future of the project.

When I originally registered the domain name, I was intending to build an organization of kiwis interested in tech politics. That didn’t work out, so it’s ended up being a tech politics blog and research wiki written and curated by lonely old me. The team behind CoActivate have been fantastic hosts for more than a decade, but mucking about with my used Androids has revealed just how far behind the times the platform is falling. CoActivate projects are hard to read on a mobile device, and pretty much impossible to edit or interact with, so unless and until we can bring the platform up to date, continuing to host Disintermedia means being unavailable to the majority of potential readers.

The other major change that’s happened over the last few years is that I’ve got more and more involved in the development of the fediverse, The growing federated social media network that includes projects like Mastodon and PeerTube. The fediverse also includes a number of federated blogging tools like Plume, write.as, and WriteFreely, which allow people to follow blogs and comment on them from within their preferred social media app. A good example is We Distribute, a blog about federated networks, which uses the Pterotype plug-in for Wordpress, Without an update to the software under the hood of CoActivate, the only way I can make Disintermedia blog posts available on the fediverse is posting links using my Mastodon account, hosted by the NZOSS.

I’ve thought a lot about moving to self-hosting a blog, wiki, and other services for Disintermedia (perhaps email and Jabber too). Maybe using a self-hosting tools like YUNOhost or FreedomBone. I know it would involve some serious upskilling, and probably some headaches and unexpected outages, “best laid plans of mice and men” and all that. On the other hand, it would also give me a lot more practical knowledge about the software I research and blog about and allow me to make more informed suggestions about what software to use for the needs to different communities.

Another thing I’ve seriously considered is just closing the doors. Maybe merging the work I do with Disintermedia into a larger organisation, like the Free Software Foundation, or the Peer-to-Peer Foundation. Or even completely rethinking how I’m using all the unpaid time I put into Disintermedia and the movements I research and write about under this umbrella. If anyone has any feedback or suggestions on these possibilities, and I’d really appreciate you sharing them

Filed August 8th, 2019 under open social networks, News

Here’s the testing report for VOICE testing session #2. TL;DR we tested with three people and had a pretty good voice chat, although figuring out how to get group chat going took a bit of experimentation. Thanks to Naughtylus (@Naughtylus@fosstodon.org) for the write-up.

As I mentioned in the report on the first testing session, VOICE (VOICE Organized Investigation of Chat Engines) is an informal app testing group, trialing free code apps to see how well they handle voice chat, especially with groups. We aim to have a group chat testing session at least once a month, on a Sunday, starting at 8:00 UTC, with the first Sunday of the month as the default. We are currently using a Matrix chat room to confirm the timing of testing sessions, as well as for discussion about available apps and related topics: #voicechat:matrix.org

VOICE Scheduled Testing Session #2

Sunday 21 July, 8:00 UTC

Candidate: Jami (previously known as GNU Ring)

Previous Session: Test Session #1

Comments by: @Naughtylus@fosstodon.org

For this second instance of our scheduled test sessions, we tried the distributed text, voice, and video chat app Jami. Jami is part of the GNU project, was previously known as Ring, and used SIP technology for voice and video calls. As of late, though, Savoir-faire Linux has begun shifting the technology stack of the app from centralised (using servers) to distributed (using peer-to-peer technologies), and rebranding it as Jami. The app currently features one-to-one text, video, and audio chat, as well as audio and video conferencing (but not text as of yet). Everything is encrypted by default (there’s not even an option to turn it off) and the only servers used are the bootstrap nodes for the DHT and those used to lookup users from their username, but both are configurable.

So we set out to test the audio conference feature, we would have liked to try the video as well, but one of us was staying at a hotel and didn’t have the bandwidth for it. While an audio call is simple enough to place in Jami (there are big buttons where you’d expect them), an audio conference (with more than two participants) is an other beast entirely. If @AmarOk@mastodon.social (one of the Jami devs) hadn’t asserted the feature was implemented I’m not sure we would have found it.

To set up a conference in Jami, first call one of the intended participants, then once the call is established, call a second one. That will put the first call on hold. At this point you have two ongoing calls, if you resume the first one, you’ll be able to hear and speak to the two other participants, but they won’t hear each other. That’s not what we want, so what you actually have to do, is drag and drop the first call onto the second one (or the other way around, we still haven’t figured that one yet). Now your UI should show two ongoing calls, but everyone is able to hear each other. On their end, though, their UI should display only an ongoing call with you, which prompts me to think your node is actually acting as relay and there is no direct connection between the other two participants.

In this experiment the longest conversation we’ve sustained was 22min long, with a 5min monologue with no noticeable delay and very few skips in audio, so an overall quality on par with what we previously tested with Jitsi in Riot. It should also be noted that some of us were 22 000 km apart from each other and that the major source of instability in the audio was the poor hotel wifi.

We also tried to mess around with the UI to see if and how we could break it, and it really wasn’t that difficult. First, if you’re hosting the call (that is if you’re the one that did the drag and drop voodoo), you can’t mute your audio, clicking mute on any of the two ongoing calls updates the UI but doesn’t do anything. (I’m not sure if that’s intentional, but I suspect it has to do with the host acting as a relay and piping the audio of the other participants. So muting would in effect mute them as well.) Second, putting any of the calls on hold when you’re hosting flat out breaks the whole conference, you can’t resume anything after that. Just don’t do it.

There was only three of us, so this is about the extent of what we were able to test, and I’m curious to see how it plays out with more participants.

So overall, impressive quality for a peer-to-peer solution, but the UI/UX could use some improvement.

Filed August 2nd, 2019 under Uncategorized

A lot of people in privacy advocacy circles have been tut-tutting about the trackers that were identified in Purism’s Librem Chat software, a distribution (modified version) of the source code developed by New Vector for the Riot chat app. According to the Purism folks, they inherited these trackers from the Riot source code and while they failed to completely remove them from that version, newer versions have succeeded and are tracker free.

Some folks seem to think that this situation looks bad for Purism. Initially, there was the claim that they’d been caught not really caring about privacy, despite their marketing to the contrary. Then, when it was revealed that Purism hadn’t added the trackers themselves, they were accused of failing in their duty of care, by putting their brand name on a piece of software without noticing the trackers in it. No doubt, as the news filters out that they did notice them, but failed to remove every trace of them completely, the claim will change to one of incompetence.

But is that really fair? Another way of telling the story is that Purism put in significant effort to clean up free code produced by another company, resulting in a more privacy respecting chat app for users. One they don’t even charge for, because they make their money from selling hardware and running online services that they charge a subscription for (including the Librem Chat service that their distribution of Riot connects to by default). OK, they didn’t get it right the first time, nobody is perfect, but they were upfront about the problem and got it fixed.

Even if they hadn’t thoroughly audited the code, that’s not always considered necessary. Does every GNU/Linux distribution check every line of the Linux kernel before releasing it with their name on it? Some of them might (eg the ones that use the deblobbed Linux-libre fork of the kernel), but mostly the Linux kernel team are trusted to know what they’re doing. The same goes for a lot of other core components of GNU/Linux.

There was a time when the amount of source code being released under free licenses was so small, and the people using it so geeky, that a lot of it did get checked quite thoroughly before being used, let alone reused in other software. Generally, it felt safe to trust that the potential for dodgy stuff in free code to be discovered, and its creators publicly shamed, was enough to discourage anyone from putting it in there. With so much free code now being released by random people on the net, this is no longer a safe assumption, even when it comes to established open source communities and companies. But still, we generally give well established open source communities, like the Riot team, the same benefit of the doubt. As a user called Shilu put it in a discussion on the PrivacyTools.io forum:

“[It] seems bizarre that Riot would include these trackers by default.”

The other problem is the massive pressure on people developing software to ship it yesterday. One of the many consequences of this, as software gets more complicated and more modular, is more reuse of code by importing modules or plug-ins, and especially updates to them, without checking anything but their license and maybe who maintains them. So as with the trackers from Riot, stuff slips though, and sometimes with much more serious consequences.

Source code being available makes this less likely, and easier to identify and fix, but it can’t and doesn’t stop it completely. As with the Amazon Lens debacle, we also need to make sure that someone other than the author and their collaborators reads the code, carefully examining what the software does, and talks publicly about any problems they see with it (after a responsible delay to give the authors a chance to fix the problem). This is precisely why the four freedoms laid out in the Free Software Definition are important, and why laws that make some aspects of studying technology illegal, like the “anti-circumvention” provisions of the US DMCA (Digital Millennium Copyright Act), are so backwards and need to be thrown out.

Filed July 10th, 2019 under free software, open source

Back in 2016, I wrote a blog piece about modular mobile devices. Sadly, pretty much all of the projects I mentioned at the time got canned. Those that survive tend to be the least modular, like the Fairphone, which is repairable, but but not modular in the sense that Project ARA was intended to be. When I attended the 2018 Platform Cooperative conference in Hong Kong, there was a lot of talk about ways of making computer hardware more available to smaller companies, allowing them to develop their own devices. I still like the idea of allowing the end user to pop components in and out of their devides like lego blocks, for all the reasons I mentioned in that 2016 piece. Maybe cooperatively owned device makers could be the way to make it happen?

In the meantime, if there’s anyone out there looking for an open hardware project, here’s a mobile device design you’d have at least one customer for. The basic idea is a tablet mainly used for offline media consumption - reading books, listening to podcasts - but can also be used for casual communication, when there is a WiFi connection available. All components would ideally use chipsets that can run with only free code software.

Hardware:

  • E-Ink touchscreen, the size of a small-to-medium tablet
  • replaceable SDcard for the OS
  • separate SDcard expansion slot for added storage
  • full size USB port (or smaller port with dongle) for connecting USB sticks/drives
  • WiFi (with hardware switch)
  • Bluetooth for wireless headphones, keyboards etc and for file transfer (with hardware switch)
  • standard headphone jack
  • camera and microphone for communications (with hardware switches)

Software

  • Free code touchscreen OS that is compatible with the e-ink screen and can run F-Droid and Android apps (Replicant OS?)
Filed June 29th, 2019 under open hardware, Makers
Next Page »
  • Annual Events

  • Digital Freedom Foundation
  • LibrePlanet
  • Aotearoa

  • Aotearoa Indymedia
  • BallaNZ
  • Creative Commons Aotearoa/ NZ
  • Creative Freedom Foundation
  • DigitalNZ
  • Enspiral
  • Fair Deal Coalition
  • GreenStage
  • InternetNZ
  • Island Bay World Service
  • Living Economies
  • Localise
  • Loomio
  • Matrix FM
  • Nicky Hagar
  • No Right Turn
  • NZ Council for Civil Liberties
  • NZ Makers
  • NZ Makers Map
  • NZ Māori Internet Society
  • NZ Open Source Awards
  • NZCommons
  • OASIS
  • Open Government Ninjas of NZ
  • Open Source Society of NZ
  • Open Standards NZ
  • Open Ur Eyes
  • Pacific Media Centre
  • Permaculture in NZ
  • PledgeMe
  • Radio Chomsky
  • Regulation
  • Scoop
  • Tech Liberty
  • Timebank Aotearoa
  • Transition Towns Aotearoa/ NZ
  • Uncensored Magazine
  • Waatea News
  • Waikato Linux Users Group
  • What If
  • Wiki NZ
  • Zenbu
  • archives

  • ArchiveTeam
  • Critical Commons
  • Ibiblio
  • Internet Archive Community Software Collection
  • Open Archives Initiative
  • Blogroll

  • Abject
  • Access Now
  • Ars Technica
  • BadScience
  • Banjo - RoboBlog
  • Boing Boing
  • Born out of Binary
  • Centre for Media and Democracy
  • Choke Point Project
  • Copyrighteous
  • Create Digital Music
  • Creative Commons International
  • Cryptogon
  • Digital Standards Organisations
  • Disinfo
  • E-Democracy
  • Electronic Privacy Information Center
  • Ever Vigilant
  • Freedom Box Foundation
  • Freedom of the Press Foundation
  • Gaming On Linux
  • Global Indymedia
  • Gondwanaland (Mike Linksvayer)
  • Institute for the Future of the Book
  • Institute of Network Cultures
  • Internet Governance Project
  • InternetNZ
  • Island Bay World Service
  • Iterating Towards Openness
  • Knowledge Ecology International
  • LinkedListCorruption
  • Linuxed - Exploring Linux Distros
  • Localise
  • Moved by Freedom - Powered By Standards
  • Nanowares
  • New Zealand Māori Internet Society
  • Nicky Hagar
  • No Right Turn
  • NZ Council for Civil Liberties
  • NZCommons
  • O'Reilly Radar
  • OASIS
  • OERu Technology Blog
  • Open Educational Resources Foundation
  • Open Knowledge Foundation
  • Open Rights Group
  • Open Social Web
  • Open Source Conscious Intelligence Network
  • Open Source Food
  • Open Stand
  • Open Ur Eyes
  • OpenCollective
  • OpenDotDotDot
  • OpenSource.com
  • Permaculture in NZ
  • Plumi
  • Public Interest Journalism Foundation
  • Punk Rock Permaculture
  • Question Copyright
  • Replicant (OS)
  • Rob Meyers
  • Schneier on Security
  • Scoop
  • Shareable
  • Slashdot
  • Software Freedom Law Centre
  • Software in the Public Interest
  • SourceMap
  • Sustento Institute
  • Tech Liberty
  • TechRights
  • The Tin Hat
  • Tinkering Down Under
  • TorrentFreak
  • TransitionMovement
  • Translation Project
  • Trisquel GNU/ Linux
  • United Diversity
  • Waatea News
  • We Speak for Freedom
  • Why Your Boss is Programmed To Be a Dictator
  • code bank

  • Allura
  • BitBucket
  • FusionForge
  • GITHub
  • GITLab
  • Gogs
  • Internet Archive Community Software Collection
  • LaunchPad
  • NotABug
  • Savannah
  • Software Freedom Conservancy
  • Software Heritage
  • Sourceforge
  • community economics

  • Commons Transition
  • Fruit Tree Planting Foundation
  • In Our Back Yards
  • Institute for Local Self-Reliance
  • Libre-Living
  • Living Economies
  • Sensorica
  • Sustainable Economy Law Centre
  • Timebank Aotearoa
  • TransitionMovement
  • cooperative

  • Loomio
  • Snowdrift Coop
  • crowdfunding

  • ArtistShare
  • BountySource
  • Causes
  • CauseVox
  • Crowdfunder
  • Crowdjustice
  • Crowdrise
  • Crowdsupply
  • Flattr
  • Fundit.buzz
  • GiveaLittle
  • Goteo
  • In Our Back Yards
  • KickStarter
  • KissKissBankBank
  • Liberapay
  • Mighty Cause
  • OpenGift
  • Patreon
  • PledgeMe
  • PledgeMusic
  • Pozible
  • Snowdrift Coop
  • StartSomeGood
  • Taproot Foundation
  • The Working World
  • Tidelift
  • Events

  • IndieWebCamp
  • free code

  • April
  • Black Duck Open Hub
  • DistroWatch
  • Ever Vigilant
  • F-Droid
  • Free Software Directory (GNU FDL 1.3 or later)
  • Free Software Support Network
  • Free Software Support Network
  • Free Your Android
  • FreshCode
  • Gogs
  • Gun.io
  • Internet Archive Community Software Collection
  • LILA
  • LinuxTracker
  • NotABug
  • OERu Technology Blog
  • Peers Community
  • Plumi
  • PublicLab
  • Replicant (OS)
  • Software Heritage
  • Urchn Studios
  • Free Media

  • Communes Collective
  • Copyrighteous
  • Create Digital Music
  • Definition of Free Cultural Works
  • Dyne Foundation
  • FLOSSManuals
  • Free Culture Foundation
  • Ibiblio
  • Librivox
  • LILA
  • Open Video Conference
  • Show Me Do
  • Translation Project
  • Urchn Studios
  • WikiLeaks
  • freelancing

  • BountySource
  • Gun.io
  • independent media

  • Aotearoa Indymedia
  • BallaNZ
  • EngageMedia
  • Freedom of the Press Foundation
  • LILA
  • Matrix FM
  • Pacific Media Centre
  • Public Interest Journalism Foundation
  • Radio Chomsky
  • Radio Heritage Foundation
  • Uncensored Magazine
  • Waatea News
  • libre gaming

  • Gaming On Linux
  • Makers

  • GreenStage
  • Libre-Living
  • Mediamatic
  • NZ Makers
  • NZ Makers Map
  • Open ROV
  • Renewable PCs
  • Rob Meyers
  • Sensorica
  • maps

  • GeoForAll
  • GeoNames
  • Green Map System
  • Map Tools
  • Open Geospatial Foundation
  • Open Street Map
  • open governance

  • Crowdfunding
  • D-Cent
  • Deep Democracy Institute International
  • E-Democracy
  • Fight for the Future
  • Holacracy
  • Internet Governance Project
  • Kettering Foundation
  • Knowledge Sharing Toolkit (CC-BY-SA 3.0)
  • Open Government Ninjas of NZ
  • Open Policy Network
  • Open Space World (CC-BY-SA 2.5)
  • Open Stand
  • Open Standards NZ
  • Participedia
  • Sunlight Foundation
  • Transition Towns Aotearoa/ NZ
  • What If
  • WikiLeaks
  • open hardware

  • H-Node
  • Makey Makey
  • Meeblip Open Source Bass Synth
  • Open Hardware Summit
  • Open ROV
  • Open Source Hardware Association
  • Orgs

  • Access Now
  • Apache Foundation
  • April
  • Autistici/Inventati
  • Collaborative Knowledge Foundation
  • Commons Transition
  • Communes Collective
  • Computer Professionals for Social Responsibility
  • Creative Commons Aotearoa/ NZ
  • Creative Freedom Foundation
  • Critical Commons
  • D-Cent
  • Deep Democracy Institute International
  • Digital Due Process coalition
  • Digital Freedom Foundation
  • Digital Standards Organisations
  • DigitalNZ
  • Dyne Foundation
  • E-Democracy
  • Electronic Frontiers Foundation
  • Electronic Privacy Information Center
  • Fair Tracing Project
  • Fight for the Future
  • Foundation for Peer-to-Peer Alternatives
  • Free Culture Foundation
  • Free Network Foundation
  • Free Software Foundation
  • Free Software Support Network
  • Free Software Support Network
  • Freedom of the Press Foundation
  • Guifi
  • Ibiblio
  • Identity Commons
  • Institute for Local Self-Reliance
  • Internet Engineering Taskforce
  • Internet Governance Project
  • ISA Commons
  • Kettering Foundation
  • LEAP Encryption Access Project
  • LILA
  • Living Economies
  • Loomio
  • May First/ People Link
  • Mediamatic
  • NZ Māori Internet Society
  • NZ Open Source Awards
  • Open Architecture Network
  • Open Archives Initiative
  • Open Geospatial Foundation
  • Open Policy Network
  • Open Source Hardware Association
  • Open Source Society of NZ
  • Open Web Foundation
  • OpenADR Alliance
  • OpenCorporates
  • Outreachy
  • Participatory Culture Foundation
  • Peers Community
  • Permaculture in NZ
  • Privacy International
  • Public Citizen
  • Public Interest Journalism Foundation
  • Public Knowledge
  • Public Patent Foundation
  • Question Copyright
  • Radio Heritage Foundation
  • ReDecentralize
  • Reform Government Surveillance
  • Regulation
  • Rhizome
  • RiseUp
  • Science Commons
  • Software Carpentry Foundation
  • Software Freedom Conservancy
  • Sunlight Foundation
  • Sustainable Economy Law Centre
  • Taproot Foundation
  • Transition Towns Aotearoa/ NZ
  • Waikato Linux Users Group
  • Wiki NZ
  • World Wide Web Consortium (WC3)
  • Xiph.org
  • XMPP Standards Foundation
  • Peer2Peer

  • BitCoin
  • FreeCoin
  • Permaculture

  • Appropedia (CC-BY-SA 3.0)
  • Fruit Tree Planting Foundation
  • Future Scenarios
  • OrganicDesign
  • Permaculture in NZ
  • TransitionMovement
  • We Speak for Freedom
  • Privacy

  • Access Now
  • Digital Due Process coalition
  • Ever Vigilant
  • Fight for the Future
  • International Principles on the Application of Human Rights to Communications Surveillance
  • LEAP Encryption Access Project
  • OASIS
  • Privacy International
  • Reform Government Surveillance
  • What If
  • protocols and licensing

  • Definition of Free Cultural Works
  • Digital Standards Organisations
  • Greenlots
  • ISA Commons
  • Open Archives Initiative
  • Open Stand
  • Open Standards NZ
  • Open Web Foundation
  • OpenADR Alliance
  • Regular Events

  • Libre Graphics Meeting
  • Open Hardware Summit
  • science and datasets

  • AllTrials
  • Collaborative Knowledge Foundation
  • DigitalNZ
  • Fair Tracing Project
  • ISA Commons
  • Open Geospatial Foundation
  • Open Hand Project
  • SourceMap
  • Wiki NZ
  • Zooniverse
  • Tools

  • Autistici/Inventati
  • BitCoin
  • Black Duck Open Hub
  • CoActivate
  • Crowdfunding
  • DistroWatch
  • Dyne Foundation
  • F-Droid
  • FLOSSManuals
  • Fork the Cookbook
  • FreeCoin
  • GITHub
  • GNU Operating System
  • GreenStage
  • H-Node
  • How To Escape the GoogleMax Panopticon
  • Knowledge Sharing Toolkit (CC-BY-SA 3.0)
  • LEAP Encryption Access Project
  • LinuxTracker
  • Loomio
  • Map Tools
  • May First/ People Link
  • Meeblip Open Source Bass Synth
  • Monolith
  • Open Hand Project
  • Open Source Ecology
  • Open Space World (CC-BY-SA 2.5)
  • Open Street Map
  • OpenCorporates
  • OpenMailBox
  • Participatory Culture Foundation
  • Plumi
  • Renewable PCs
  • Replicant (OS)
  • RiseUp
  • Savannah
  • Show Me Do
  • Sourceforge
  • SourceMap
  • TransforMap
  • Translation Project
  • Web Platform
  • Zenbu
  • Transition

  • Green Map System
  • Health After Oil
  • Localise
  • OrganicDesign
  • Wiki

  • Appropedia (CC-BY-SA 3.0)
  • Foundation for Peer-to-Peer Alternatives
  • Instructables
  • LibrePlanet
  • Open (Government) NZ
  • Participedia
  • SourceWatch
  • WikiEducator
  • wireless mesh

  • Guifi
  • workplace democracy

  • Enspiral
  • The Working World