Blog - Unity Behind Diversity

Searching for beauty in the dissonance

Tagged: snowy

Four Criteria for Free Network Services

I’m increasingly critical of network services — software that you use on someone else’s server to do your own computing. We rely on computers more and more for our work, social lives, civic engagement, health, education and leisure, and more and more that means relying on networking services rather than our own personal computers. There are serious trade-offs to living as a tenant online, rather than a property owner. I’ve been reconsidering the network services I use and rely on, especially in the shift to mobile computing.

The work of Autonomo.us has heavily influenced my thinking. Also of note is Stallman’s essay on software as a service (though he does more to identify the problems than recommend solutions). I essentially agree with the Franklin Street Statement from Autonomo.us. As a user of network services, I’ve narrowed it down to four major criteria to look for when deciding whether to trust a service on freedom and autonomy.

  1. Free (libre) software
  2. Control over data
  3. Privacy / Encryption
  4. Distributed Systems

Note: This is more of a working list than an attempt at a formal definition. For example, I’m not sure that #3 and #4 should be required, even though I believe they are important. Feedback is welcome.

1. Free (libre) software

Free (libre) or open source software licenses designed for network services, like the GNU AGPL, help guarantee the software will respect users’ freedoms. The arguments for software freedom have been addressed at length elsewhere, but the freedom to run the software yourself is particularly relevant here since, unlike desktop software, you often have the choice of letting someone else run the software for you. Even if you don’t run the software on your own server, having the freedom to do so ensures that you can still run the service in the event that the service provider shuts down — a frequent concern with proprietary web startups after acquisition or failure. And, even if you can’t run the software yourself, with all four freedoms, chances are someone else will. The broader case for software freedom is made at length elsewhere.

Network services should respect users’ freedoms. LibreProjects.net has a good list of free web services and alternatives.

2. Control over data

If users want to leave a service provider, can they take their data with them? Open standards are important. Open standards allow other software to read and understand your data. Open standards also allow you to mix the software you use on the client and server or across multiple devices more easily. Not only does this make migration more realistic, but it makes transitions smoother.

Google’s network services aren’t often free (libre) software, but Google does have a strong commitment to open standards and making your data easily available. I’ve used many Google services from non-Google clients: Gmail from Thunderbird, Evolution and Modest; Google Calendar from Lightning, Evolution, and my N900; Google Reader from Liferea and grr; Google Talk from Empathy, Pidgin, and my N900, etc. I’ve been able to switch my client-side software before changing the back-end. This makes it possible to transition to new services gradually, in smaller steps, with less disruption.

Facebook has a download feature, but it’s slow, and it just chucks all of your data into a giant zip file rather than putting it into formats that other software or services could understand. Facebook has also actively blocked services that export your data to other providers. Your data is available for download, but not in a very useful way.

Migrations are not always planned. On your own server, you have the master key. With a service provider, if you lose access to your account because it’s cracked or cancelled suddenly, will you also lose access to your data? Or will you have an up-to-date copy locally? Open standards often help make it possible to keep a local copy up-to-date, but this isn’t always the default way we use these services. A synchronization service will typically maintain a complete local copy of your data, but services intended to be accessed through the web often require additional client-side set up
on the user’s part to make this happen (e.g. using Thunderbird or OfflineIMAP to keep a local copy of your Gmail email, or using Google Sync to keep a local copy of your calendar and contacts). Or, the services may only offer data dumps as backup. Does a service let you keep a complete local copy of your data easily in your everyday usage? Even if you primarily use the web interface, setting up a desktop client for regular use can help maintain a local copy of your data without having to consciously download backups.

Lastly, public data that is intended to be shared should be available under a free and open licence. Identi.ca uses CC BY for public user data. Libre.fm focuses on freely licensed music. This gives control over public content to the community, rather than just the service provider.

Network services should let users control their data, using open standards to give users control of their personal data and free licences to give the community control over public data. Despite having a very mixed record on other criteria, Google is a good example of open standards done right. Free (libre) and open source tools are also usually good with open standards. Identi.ca is a good example of licensing public data freely.

3. Privacy / Encryption

My concern with privacy isn’t so much what a service provider’s policies are, but who has access to the data in the first place.

With the launch of Google+, I’ve been quite relieved that I’ve moved a lot of my important data out of Google over the past few years. It’s one thing for Google to have my email or my social graph or my documents, but the volume of data that would be in one place using all of Google’s services is astounding. Google is generally a well-meaning company, but I wouldn’t want any single organization to have everything that Google might have: my email (love letters, job applications…), address book (contacts and their private information), documents (budget, resume, business plans), calendar (activities, habits, regular whereabouts), RSS feeds (passions, interests, and political, intellectual, religious leanings), instant messaging (chat logs with friends, lovers, co-workers), my social graph (strong ties, relationships), my phone calls (the ability to recognize my voice from Google Talk or Google Voice), my photos (facial recognition and identification of my family, friends, colleagues) — nevermind all of the revealing personal information contained in web searches! There are lots of questions regarding each type of data and whether or not you’d want to trust it with someone else, but the aggregation of all of it into a single account is a more noticably bad idea. It’s a recipe for disaster in the event of a privacy leak or breach, oppressive government actions, a supeona, the loss or revocation of your account, etc.

Furthermore, some things I simply don’t want on someone else’s computer ever. I’ve felt comfortable trusting service providers like Google with my email in the past, but I’ve never been comfortable trusting them with my entire address book — that’s not just my data, but other people’s private information too. Similarly, I would never want my personal journal on someone else’s computer — that’s just too private.

However, Mozilla does a fantastic job of handling private data. With Mozilla Weave (i.e. Firefox Sync), not only is it free (libre) software that you can run on your own server, but your data is encrypted on the server. A user has two passwords — one to authenticate with the server, another to encrypt the data locally. Since encryption happens locally, the server only sees the encrypted data and never sees your second password. Mozilla doesn’t even ask for the information to decrypt your Firefox Sync data. You can use their server to sync your data across computers, but it’s only ever decrypted on your computers, not the server. If you use Mozilla’s server instead of your own, Mozilla still won’t have access to your data.

I wish more services providers would do this. I understand it doesn’t work for services that are meant to be accessed directly on the server through the web, but at least for synchronization services it seems like a privacy no-brainer. Funambol, for example, is a great libre software data synchronization server for mobile devices, but I don’t think their gratis service at my.funambol.com encrypts your data. I suppose they have a web interface on their server, but I’d rather run my own Funambol server in the absence of Weave-style encryption, whereas I don’t mind using Mozilla’s Firefox Sync service at all.

Encryption of data in transit is another concern. Does a network service or web application offer encrypted methods of communication? Or is your private data being transmitted out in the open? Gmail now offers HTTPS by default. Facebook and Twitter offer an “Always use HTTPS” setting. The EFF has developed a Firefox add-on that uses HTTPS wherever possible. I’ve started using basic StartSSL Class 1 certificates, which are available at no cost to individuals, in order to encrypt traffic on my home servers.

A good network service should take privacy seriously, and offer encryption wherever possible. I’m not sure that this should be a requirement for a free network service, but it’s an important consideration before using a service hosted by somebody else. However, a service that may fail to adequately protect your privacy as a hosted service could still provide an acceptable self-hosted solution.

4. Distributed Systems

Email is a common example of a distributed set of protocols. If Bob uses Hotmail and Sally uses Gmail, they can still communicate with each other. Telephony provides another example; Bell customers can phone Rogers customers, and vice versa. This is the ideal — choosing a service provider independently from the people with whom you want to communicate. Distributed systems strengthen the Internet, creating fewer points of failure or censorship, more opportunities for expression and innovation, more freedom and autonomy for users. This isn’t always relevant for network tools or synchronization services aimed at individuals or small groups compared to social network services and communications tools.

Most online social networking services are walled gardens. Facebook users can only talk to other Facebook users, MySpace users can only talk to other MySpace users, etc. In this environment, social pressure has negative effects on freedom and autonomy. You might not feel comfortable using Facebook, but if that’s where your social circles are active, you’re faced with the choice of being left out or using a service provider with which you’re uncomfortable.

Google Talk makes it clear that it doesn’t have to be this way. Rather than developing their own proprietary walled garden instant messaging service, Google used the open standard XMPP (aka Jabber) for its chat service. With XMPP, you can chat with people on other servers. I have a Jabber account on my own server (and there are dozens of public Jabber servers), and I can still talk with (or call) people on Gmail Chat. I’ve left Google Talk, but I’m not cut off from Google Talk users. Compare that to Skype, which has so far relied on a proprietary VoIP protocol that only lets Skype users call other Skype users (short of bridging to traditional telephony).

In the social networking space, there are efforts like GNU Social/StatusNet and Diaspora to develop distributed solutions. StatusNet has already had some success implementing an open standard for distributed status updates. I’m curious whether Google+ might advance the cause of distributed social networking services (even slightly), given Google’s commitment to distributed systems and open standards elsewhere, and their development of new standards like OpenSocial.

Social network services should be distributed, allowing users to communicate across service providers. Email, traditional telephony, XMPP/Google Talk and GNU Social/Diaspora are all good examples of this. I’m not sure that this should be a strict requirement for a free network service, but the freedom to run the software on your own server is pretty useless for some social applications if you can’t communicate with people on other servers.

Conclusion

Identi.ca, the flagship StatusNet site, is a perfect example of a free network service. It’s free software (AGPL), implements open standards and documented APIs for accessing your data, they’ve pioneered an open standard for distributed networking, and public updates are licensed freely. I’m happy to use Identi.ca.

Mozilla’s Firefox Sync is a good example of a free network synchronization service. Data is encrypted, it’s free software that can be run on another server, and bookmarks are stored locally in a format that other applications can read. I’m comfortable using Mozilla’s service for Firefox Sync.

AGPL network sync services like Funambol and Snowy are also libre services (free software, open standards or documented formats), but in the absence of Mozilla-style encryption, I’d prefer to run them on my own server. The FreedomBox Foundation has been working on an easy way to run libre services from a home server, and make them available to others. I currently use a combination of always-on GNU/Linux home computers available remotely and some dedicated servers that I manage. Even without your own server, you can use free (or more freedom-friendly) hosted services like riseup.net for email, jabber.org or others for instant messaging, my.funambol.com for mobile sync, Mozilla Firefox Sync for bookmarks and browser data, Identi.ca over Twitter, Voip.ms (SIP) over Skype, Libre.fm over Last.fm, etc. If you’re looking to try out some of the self-hosted services, I do have Snowy, Funambol, and Tiny Tiny RSS running on my home server — contact me if you’d like an account to try them out.

The process of disentangling from proprietary network services can take some time, but it’s well worth it for the sake of freedom and autonomy, even when it may be challenging in the short-run. If you can’t leave a proprietary service right away, recognizing where it fails to meet these criteria can help you take some important steps in the meantime.

Creative Commons Attribution-ShareAlike 4.0 International Permalink | Comments (8)

HOWTO: Sync Notes Between Tomboy and Conboy with Snowy [UPDATED]

Updated: I’ve updated this guide to detail a proper sync with Snowy, rather than the old Unison hack (below), since Conboy now supports more than just Ubuntu One, and an experimental version Snowy is operational.

I’ve been a regular user of the fantastic Tomboy note-taking application since I replaced my Palm Pilot with a Nokia N900. With Conboy, a Tomboy client for Maemo, and Snowy, a web application for Tomboy notes, it seems like the perfect platform for uniting personal notes across the desktop, mobile and web (except for one drawback: Tomboy itself is a Mono application…). Initially, I used a hack with Unison to synchronize Tomboy files manually between my N900 and laptop, but I recently moved to proper, albeit still experimental, syncronization through my own Snowy server.

Installing Snowy

Snowy is a Djano-based, AGPL web service for Tomboy notes, currently under heavy development (and still labelled as experimental). I installed Snowy on my own Ubuntu web server using the official installation guides. I went with mod_wsgi, though I have Django running via mod_python on another server.

Installation was very straightforward. Just a few notes:

  • The debugmail step in the INSTALL file within the Snowy source directory didn’t seem to work for me, but I’m not too concerned about email yet. I’m just running this for me and my family. I’ll likely revisit this later.
  • Between the time that I followed the INSTALL steps and when I went to first sync from Tomboy, I had decided to switch the installation to a slightly different URL. I couldn’t figure out why the sync didn’t work, but it turns out I still had the old URL in the Django Sites table. Just a silly mistake on my part.
  • When you log in to your new Snowy server, in the current version, it isn’t obvious where to click to see your notes. You can click on your avatar in the top-right corner, or simply add /<username> to the end of your Snowy URL (e.g. my username is balleyne, so http://<my-snowy-url>/balleyne brings me to my notes

Tomboy

Tomboy comes packaged with the web sync plugin in recent versions of Ubuntu.

  1. Backup your notes!
  2. Log into Snowy in your default web browser.
  3. Open Tomboy, and go to Edit > Preferences > Syncronization
  4. Select Tomboy Web as the Service, and put in the root URL of your Snowy installation as the server.
  5. Follow the instructions to authenticate, save your settings (I set Tomboy to automatically sync every 60 minutes), and synchronize!

Conboy

Conboy focused on supporting the proprietary Ubuntu One web service first, but it now supports synchronization to any Tomboy web service (though the feature is labelled Beta). The only problem I had setting this up was a strange error about a missing api-ref and local time, but it turns out Conboy just didn’t want a trailing slash in the URL (seems like the trailing slash prevented proper authentication at the sync stage).

  1. Backup your notes!
  2. Log into Snowy in your default Maemo web browser.
  3. Open Conboy, and go to Settings in the main application menu.
  4. Enter your Snowy URL — without a trailing slash — as the Synchronization URL
  5. Click Authenticate and follow the instructions.
  6. Synchronize!

Conclusion

I’m super happy that the Tomboy / Conboy / Snowy combination is now ready to use, but do pay attention to the beta nature of Conboy sync, and the experimental nature of Snowy — make sure to backup your notes regularly to avoid any data loss.

I’m happy to be a guinea pig myself.

Old Way: Sync Notes Between Tomboy and Conboy With Unison

Disclaimer: this is a hack from someone who doesn’t know Tomboy well. It worked for me, but YMMV. And I have backups. And, mostly importantly… why aren’t you using Snowy now instead?. The instructions below should be treated as a hack preserved for historical purposes.

I wanted a way to sync Tomboy on my Ubuntu desktop with Conboy on my Nokia N900, but Conboy only syncs to Ubuntu One—a proprietary web service. Snowy synchronization support is supposed to be on the way, but Snowy itself is still under heavy development, so this might be a great option in the near future, but not today.

A comment on maemo.org made me think that rsync over ssh was a possibility, and a quick rsync showed this to work (as far as I can tell). The trick is being able to sync changes back and forth; rsync can’t handle updates to both the source and destination—it’s unidirectional.

Hence, Unison—a bidirectional synchronization utility. In case it’s useful to anyone else, this is how I’ve setup Unison to sync notes between Tomboy and Conboy.

Step 0: Some things you should know

First, I want to be clear that this is a temporary hack while I wait for proper synchronization support through Conboy with Snowy.

Prerequisites: I already have OpenSSH running on my server, and I have key-based ssh access configured from both my laptop and N900. Unison syncs remotely over SSH.

What this does: It allows me to synchronize notes and changes to notes from my N900 to my laptop, and potentially to any number of other computers.

What this doesn’t do: Unison has support for handling conflicts, but it’s not the least bit Tomboy-aware. A proper Tomboy sync might give you the option of renaming a note that has been changed in more than one place, but with Unison, you’ll be looking at diffs and merges of cryptically named XML files. So, I don’t recommend relying on Unison to sort out conflicts. I plan to sync often, backup often, and avoid conflicts as much as possible. This is for advanced users.

Tomboy Concerns: I’m using Tomboy, but actually quite uncomfortable with the risk, since it depends on Mono. I’ve considered switching to Gnote, but haven’t yet because I’m concerned about losing data/synchronization compatibility. But, this solution might work for Gnote too, and I may well s/Tomboy/Gnote/g in the near future.

Step 1: Desktop

1A: Install Unison

Unison is cross-platform and available for a variety of operating systems

I have Ubuntu on both my laptop and server right now, and I’m syncing through that server (instead of directly to my N900, which would be another option).

In Ubuntu, you can install unison with the command:
sudo apt-get install unison

Or, if you want a GUI:
sudo apt-get install unison-gtk

1B: Create a Unison profile for Tomboy

I created a file called ~/.unison/notes.prf with the following text:
# Unison preferences file
root = /home/balleyne/.local/share/tomboy/
root = ssh://alleyne.to/.local/share/tomboy/

I decided to sync my notes with the Tomboy directory on my server, which is also a workstation.

Now, I can synchronize the notes on my laptop with my server by running the command:
unison notes

1C: Enable NoteDirectoryWatcher Add-in for Tomboy

Tomboy doesn’t automatically look for changes to notes on the file system unless you enable the NoteDirectoryWatcher Add-in: Edit > Preferences > Add-Ins > Tools > Note Directory Watcher > Enable. This way, Tomboy will accept any changes you get from the Unison sync.

Step 2: Mobile

2A: Installing Unison in Maemo 5

To compile Unison, you need the OCaml compiler. To compile OCaml, you need the gcc compiler. I began the process of compiling compilers, but then realized that there were some unison .debs available already:

These were compiled for an older version of Maemo, but the command line version seems to be working fine for me in Maemo 5. Note, that if you use the GUI, it’s standard GTK, not a Maemo port, so you might need the stylus to use it.

To install, I ran the following commands:
$ sudo gainroot
# wget http://www.bundyo.org/maemo/unison/unison_2.27.57-2_armel.deb
# dpkg -i unison_2.27.57-2_armel.deb

2B: Create a Unison profile for Conboy

Similar to step 1B, I created a file at ~/.unison/notes.prf:
# Unison preferences file
root = /home/user/.conboy
root = ssh://alleyne.to/.local/share/tomboy

Now, I can sync my mobile computer with the server by running the command:
unison notes

And there was much rejoicing.

Conclusion

With Unison configured, I now have a basic, low-level sync between Tomboy and Conboy. I’m getting into the habit of syncing every time I change anything, to avoid conflicts. This should tie me over until a Conboy Snowy sync is available.

Creative Commons Attribution-ShareAlike 4.0 International Permalink | Comments (5)