Posted on
by

One of the hardest things I’ve found during my ongoing process of PRISM breaking my life, was securing my communication with others, especially via email.

Interestingly, this has very little to do with technical reasons; Email encryption is a faff, true, but there has been a lot of work to smooth over the rough edges (and it’s certainly not a big ask for technical people like myself). There are OpenPGP plugins for most clients these days, and technologies like S/MIME are universally supported and almost completely transparent in every day use.

The main problem is that nobody else seems bothered, even technical people, so my tactic here is really just to keep going on about this like a broken record…

Even if you think you have got “Nothing to hide…” (the canonical example of a bullshit argument if ever there was one), you should be encrypting your communication.

Consider that ECHELON, the forerunner of PRISM, has been used for industrial espionage in order to give American companies a competitive advantage, if your business has an American competitor (or Chinese or Russian or French for that matter), do you really want them knowing about the deals you’re working on?

Or to put it all more succinctly; when you send a letter, why do you put it in an envelope?

Of course, if the person you’re emailing is using Gmail or Hotmail you’re doubly screwed, so perhaps it’d be better to give up on email altogether… and to some extent I have, and now do much of my communication via IM, certainly if it’s anything confidential.

Skype, we know now is monitored, so that’s out, as to is Google Talk, however both can be secured by using a technology like OTR, which is much less of a UX nightmare providing you use a talk client rather than Google web interface. I’ve at least had some success in getting people to secure their chats, but there’s still a long way to go.

As an aside, it is relatively trivial to run Jabber on your own server and communicate with other users on other servers (like google talk) entirely transparently. This doesn’t do much to secure your communication unless both sides of the communication have done this, but running your own stuff is all for the good, and hey, it means you’re not a whoever@gmail!

Onwards…

Posted on
by

The other day I sketched out some notes on how friend/follow and subscribe might work in a distributed social network such as Idno (I have since hacked together some plugins based on those notes).

So, I thought I’d sketch up some thoughts on how private and friend only posts might work in a distributed social network:

Outline specification

  • On account creation (or if there isn’t a key present) a key pair is generated, this key pair is used to identify a user’s profile to that user’s friends.
    • I’m not sure exactly what kind of key this should be at this point, although I’m leaning towards a PGP key pair, although OpenSSL has its merits (of course, there is no reason why we can’t use multiple technologies).
    • We’ll probably have to have the private key stored on the server for the purposes of signing, although there’s no reason why these have to be your main keys.
  • When Alice follows Bob, as described in my previous post, they both pull the public keys from each other’s profile as part of that exchange, which have been marked up using Microformats 2. Any keys found are saved against the record of that user.
    • For security, we probably want to do some sort of key validation here; perhaps key fingerprint, or perhaps better some web of trust based on mutual friends…
    • How key revocation might work is an open question, but I think the easiest way might be for Alice to send another subscription request to Bob, and have that re-trigger this process, rather than (as happens at the moment), returning an error that Alice is already subscribed to Bob.
  • When Bob writes a friends only post he lists Alice’s profile UUID in a list of people who can view the post, then ping’s Alice’s endpoint.
  • When Alice visits Bob, or Alice’s site visits Bob’s permalink, it identifies itself by signing the request using her key. If the signature is valid and belongs to a key for a user for which Bob has allowed access to the permalink, the data is displayed, otherwise a HTTP 403 code is returned.

Just some rough thoughts for now, let me know your thoughts!

Posted on
by

The ability to follow your friends, and receive notifications when they post new activity, is a vital part of what makes a social network – well – social.

With a distributed social platform like idno, this presents a bit of a problem.

In a previous post, I mooted a specification that would allow for distributed friend/follow/notification on Idno, and any indieweb platform that chooses to support the protocol.

Since it’s always a good thing to have a reference implementation for these things, I put together a couple of plugins that implement the spec. The first, Subscribe, provides the basic engine – the protocol endpoint, together with a subscriber and subscription list page. The second, SubscriptionNotification, provides a visual notification mechanism, via a popup label, and a summary page.

This is highly experimental, and is subject to change as we flesh out the mechanism, but I think it’s a good start.

» Subscribe plugin…
» SubscriptionNotification plugin…