The LiveJournal Security model
Dec. 22nd, 2003 02:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
xthreadLive journal is a wacky beast.
They're trying to do the right thing,
really they are. But its wacky nonetheless.
Ok, so the basic model is that there are two security levels -
'public' and 'friends.' Things you post publicly, randoms
can look at, things you post privately only friends can look
at. Randoms can still tell that you've been posting, though,
because the calendar/archive view just does a database
query and reports how many posts you've made on a given
day, not how many posts you've made that the person asking
the question can see. (This is actually a common database
error, because its expensive to do the right thing computationally).
Anyway, so now let's say that you want to add the 'rilly sekrit
stuph' group, for, well, really secret stuff. So they made an
extension to the 'friends only' portion of the model to allow
you to set up a subgroup of friends, and lock individual
messages to that subgroup. However, if a reader is a
member of the subgroup, they can't tell which messages are
set to 'friends only' and which messages are set to 'subgroup
only.' In fact, they may not know that they are even a member
of a subgroup, and they can't tell who else is and is not also
a member of the subgroup. This is Not Ideal, from
the standpoint of trying to keep people from accidently creating
serious social lossage and distress. How is somebody supposed
to know that shouldn't discuss something in public if they have
no way of telling that its private? Argh!
And the comments control model is also badly broken.
And this is without even looking at the client::server db spec.
I don't even want to think about what sins I'd find if I looked
at it. But at least they're trying to do the right thing...
They're trying to do the right thing,
really they are. But its wacky nonetheless.
Ok, so the basic model is that there are two security levels -
'public' and 'friends.' Things you post publicly, randoms
can look at, things you post privately only friends can look
at. Randoms can still tell that you've been posting, though,
because the calendar/archive view just does a database
query and reports how many posts you've made on a given
day, not how many posts you've made that the person asking
the question can see. (This is actually a common database
error, because its expensive to do the right thing computationally).
Anyway, so now let's say that you want to add the 'rilly sekrit
stuph' group, for, well, really secret stuff. So they made an
extension to the 'friends only' portion of the model to allow
you to set up a subgroup of friends, and lock individual
messages to that subgroup. However, if a reader is a
member of the subgroup, they can't tell which messages are
set to 'friends only' and which messages are set to 'subgroup
only.' In fact, they may not know that they are even a member
of a subgroup, and they can't tell who else is and is not also
a member of the subgroup. This is Not Ideal, from
the standpoint of trying to keep people from accidently creating
serious social lossage and distress. How is somebody supposed
to know that shouldn't discuss something in public if they have
no way of telling that its private? Argh!
And the comments control model is also badly broken.
And this is without even looking at the client::server db spec.
I don't even want to think about what sins I'd find if I looked
at it. But at least they're trying to do the right thing...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-12-22 02:48 pm (UTC)systems that have worked.
Putting the filter name in the subject line is useful.
Z
P.S.: I knew about the "number of posts visible even if the post
isn't" thing. %-}
no subject
Date: 2003-12-22 02:50 pm (UTC)to: [descriptor of group]
no subject
Date: 2003-12-22 03:03 pm (UTC)The solution seems straightforward...
Date: 2003-12-22 03:03 pm (UTC)Additionally, it should be fairly simple for LJ folks to program that heading along with mood and music.
Re: The solution seems straightforward...
Date: 2003-12-22 03:06 pm (UTC)Re: The solution seems straightforward...
Date: 2003-12-22 03:16 pm (UTC)or not you (another reader) are in the rilly sekrit stuph
group?
Re: The solution seems straightforward...
Date: 2003-12-22 03:33 pm (UTC)Re: The solution seems straightforward...
Date: 2003-12-22 03:48 pm (UTC)synchronicity
Date: 2003-12-22 03:05 pm (UTC)Wacky.
no subject
Date: 2003-12-27 03:08 pm (UTC)do not know what the Right Thing is. LJ is a classic example
of mission/feature creep; so good at what it did as a basic
function that people try to use it as something quite different
without even knowing that that's what they are doing.
It started out as a blog system. The basic model of blog systems is that
the journallist publishes content and everyone who is interested pulls it.
Feedback comments get added as a nicety.
Then folks want to comment on comments.
Suddenly it's a messaging system that was never designed to be one.
Given the me-to-the-world model of content, groups and security were more
designed around helping people find more content they were interested in
as opposed to preventing them from seeing content that's out there.
This system was not designed with the idea of privacy, its goal is the opposite:
tell the whole world something.
I'm fine with blogs as such, but when they do a sh*tty job of pretending to be
messaging systems and most of my friends insist on using them as such, it kinda
bugs me. No structure tags in the content, so that given an LJ page, you cannot reliably
determine the author or subject programmatically, no message-id's, most posts without subjects or summaries, no comments in the rss feed, no way to read comments via the API unless you have posting privs to the journal, no references or crossposting, no backups, no way to reference other LJ sites (ie, no lj://site/user/post kind of system), rendering controls structured around colors instead of content (I can make posts any color I want, but can't read them in forward time order). No decent editing of comments; how do I set a margin and fill this paragraph?
If the authors had known what they were doing, the whole thing would have an actual
messaging system backend (imap, nntp, etc). Instead of using already debugged and
very fast infrastructure with APIs and ACLs already done, the LJ folks have spent
huge amounts of time inventing an inferior wheel. They could have gotton further
with less sweat by making a pretty style rendering layer and web gui on top of an
exisiting messaging technology, but since they didn't quite realize that that was
where they were headed when they started, they've ended up with a handcrafted perl and
sql pile of kludges and a userbase so large making any changes is a bitch.
LJ is obviously very good at certain things, or they wouldn't have, what, over a million
users, but if anyone was to start over today, the guts would look a whole lot different.