Interesting Links for 14-08-2014

[andrewducker]

• What's behind the battle over breast-cancer drugs between NICE and Roche?
  (tags: breasts cancer drugs nhs uk )
• The UK government is looking forward to turning off the copper telecoms networks
  (tags: uk telecoms broadband networking )
• Robin Williams' daughter leaves social media after receiving abuse
  (tags: abuse death OhForFucksSake )
• An American

Comments

Re: Centralised messaging

[andrewducker]

It is a shame, because I'd love it to work well.

I spent a while trying to work out how to do decentralised Livejournal-esque blogging, complete with things like friends-groups locking, and a friends list.

I can see how you could encrypt things and then give keys to people, but I can't see any way to revoke their access to pages I've already posted and have been shared with them, or to make them open to new people who come along.

Either you have to have individual keys for each person who wants to read them (and encrypt in such a way that any of the keys works) - but then handing out a new key on an old entry is hard. Or you can have a single key that gives access to a friends-group, but then you can't tell if that key has been passed along.

You could have your friend present their key to your personal server that then hands out the individual key for each entry - which gives a certain amount of security, but is no use against someone who then caches all the keys so that they aren't locked out when you remove their access.

I keep thinking there ought to be a solution to this, but for the life of me I can't quite see it. Decentralisation and controlled security may just be mutually exclusive to some degree.

(Which is a good thing, in the case of things like DRM)

Re: Centralised messaging

[fanf]

One option for revocation is to periodically roll the keys and re-encrypt the posts (which is analogous to the way DNSSEC does it).

It is worth keeping in mind that you can easily go overboard with the crypto stunts, since a reader can always cache their own copy of the article. So you can have a fixed symmetric key per article which gets periodically re-encrypted for each reader, using that reader's short-term revokable key. Re-encrypting the per-article keys is easier than re-encrypting whole articles.

I think that's enough for now because I am supposed to be having fun at worldcon, not crypto narging in your comments :-)

Re: Centralised messaging

[andrewducker]

I can't go to Loncon - I demand that you entertain me instead!

Seriously though, I agree both that it would be far too easy to go overboard, and that you should be off having fun :->

Re: Centralised messaging

[notlosers]

Seems to me that it's a key per user. Here's how we're doing it: https://www.marcus-povey.co.uk/2014/05/29/friend-only-posts-and-openpgp-sign-in-on-a-distributed-social-network/

So effectively it comes down to key discovery, an integrated reader, and signed requests to other peoples' site feeds. The feed is dynamically generated, so you only see items as part of the feed if the user you've authenticated as with your signed request has the right to see them.

Interactions are handled via something simple like micropub and webmentions (see http://indiewebcamp.com), and spam actually becomes easier to deal with, because suddenly you can use your first and n-level social graph as a core metric.

Known's got an integrated feed reader coming by August 25, fwiw.

Re: Centralised messaging

[steer]

There are quite a few p2p social networks in the lit. It was quite trendy about five years ago but they never catch on. One way to do it is to have group and individual access limitations. For individuals you encrypt n copies for the n people you want to access using their public keys. This is not so bad if the item is text. You might be able to save space on larger items by encrypting a decryption key. For group auth you send out a key to the users in that group (encrypted with their public key).

There is a removal of permissions problem but really you are highlighting that removal of permissions is bad security in any document system (you are relying on being lucky that the person removed did not see already).