Some musings on LiveJournal and a decentralized LiveJournal

[spc476]

When I first came across beckyzoole 's call for a content strike on the 21st, I gave some serious thought to moving my once yearly post to LiveJournal up a day, just to be cantakerous.

And the fact that it wasn't exactly clear what the strike was about. Was it for LiveJournal's overlords eliminating ad-free free accounts, or for LiveJournal's overlords

Comments

[marnanel]

I don't think that follows. You start with the assumption

[spc476]

My reply to this.

[novalis]

DRM and access control are different.

DRM involves what happens to bits when they are under a user's control.

Access control involves how they get there to the user.

[spc476]

I don't see much of a difference between “Alice and Bob are allowed to view this-no one else is” and “Alice and Bob are allowed to view but not copy this-no one else is.” Even the definition at Wikipedia allows this:

Digital rights management (DRM) is an umbrella term that refers to access control technologies used by publishers and copyright holders to limit usage of digital media or devices. It may also refer to restrictions associated with specific instances of digital works or devices.

The very act of writing conveys a copyright to the author, so automatically we have copyright holders. Alice writes a post with the intent of only Bob and Carol seeing the post. That's a restriction associazted with a specific instance of a digital work.

Unpleasant as that may seem, I still contend that LiveJournal gives users a form of DRM.

[novalis]

Only DRM can say "Alice and Bob are allowed to view this; no one else is." Other sorts of technologies say, "Alice and Bob are allowed to access this, and once they have copies, the cat is out of the bag." See Schneier: "Digital files cannot be made uncopyable, any more than water can be made not wet." Or Doctorow: "In DRM, the attacker is also the recipient. It’s not Alice and Bob and Carol, it’s just Alice and Bob."

[novalis]

I just realized a more charitable explanation of your comments:

Perhaps you believe that some LJ users either believe or wish that LJ friends-locking worked like magical DRM, in that if you tell your LJ friends that you have herpes, it will never make it back to your non-lj-using boyfriend because doing so would violate the sacred trust of a friends lock. Or, in an actual scenario, that flocking a post after someone has read it will prevent them from quoting it to show the world your views.

But LJ does not and cannot work that way, and people who believe it is likely to do not understand either human nature or software engineering.

Managing decentralized content distribution

[nevesis]

Why not take an approach that has been used for some time - encrypted messages? PGP has been in use in email for some time now. Why stop there? Why not sign and/or encrypt posts? That way, all content is out there, and I like the idea of signing it too, just in case some decentralized server admin decides to do some censorship. But you could also encrypt posts for only a few select users to be able to decrypt. Of course, this means you trust each of them not to lose their key (or even if they were not so careless, divulge the contents of your sekret messages).

The reader software may even be smart enough to block viewing of such encrypted messages to those who do not have access. (You know, as a convenience. They can't read it anyway - why clutter their friends page).

Sure, something like that would take a lot of thought and development - but its a thought. And if we have to move in a new direction, that's when to put thought into development.

Re: Managing decentralized content distribution

[spc476]

The signing bit I like.

The problem though, is this: I have a post that everyone can see, one that only Alice, Bob, Carol and Dave can see, one that only Alice and Bob can see, and one for each of Alice, Bob, Carol and Dave. That's at least seven different keys that need to me managed, with some shared and some individual.

[laurion]

Even if you are correct, and every subscriber has to pull a separate feed, so what? The cost of bandwidth is rapidly approaching zero, and RSS files are simple text files that take minimal amounts of transmit work. No one minds when they have to send an e-mail to six, seven, or thirty-five of their friends, and that's the general load levels you are looking at. Even doing so once an hour (about how often most feedreaders refresh) is likely to be less bandwidth than viewing one youtube video or sending one mp3 or large pdf file attachment