Justin du Coeur (jducoeur) wrote in querki_project,
Justin du Coeur
jducoeur
querki_project

Coarse-grained security (seeking opinions)

[Thinking out loud here -- comments highly encouraged.]

Setting aside the question of "user levels" that we discussed last week (I'm going to put that project on pause, to give me time to read and think about About Face), here's a more immediate question that I *would* really like to deal with this month: what are the default "simple" configurations for a Space?

The thing is, Querki has very fine-grained security -- I'm trying to build a serious tool here, and that means that sophisticated users *should* be able to control the workings of their Spaces quite precisely. But the implication of that is that there already a *bunch* of different permissions, and the list is growing rapidly. The vast majority of users never want to look at *any* of those fine-grained permissions; even power users like myself probably only want to tweak and tune them occasionally. Nobody wants to have to set a dozen different permissions before they start using a Space.

(This isn't an idle question: setting up the security is probably the single biggest impediment to bootstrapping a Querki Space at this point, and even I am tending to forget things.)

So my plan is to wrap those fine-grained permissions under a few very coarse-grained models, that describe the intended usage of this Space. That is, you will first say roughly what this Space is for, which will set all of the permissions to sensible defaults for that usage, and then you can tweak the details from there. The objective is to define a few standard models that are good enough to use without *any* tweaking at least 90% of the time.

So the question is, what should those models be? In looking at it, there seem to be two dimensions -- who can see this Space, and what do typical Members get to do?

The first question seems to be "how visible is this Space?", with these options:
  • Hidden -- this Space is not publicly listed anywhere. There is no mechanism to ask to join -- I have to invite people into it. By default, all Things are marked as readable only by Members. Basically, if you haven't been invited, you get no evidence that this Space exists.

  • Private -- this Space is visible on my public profile. (Once such a mechanism exists.) People can ask to join. But by default, all Things are marked as readable only by Members. This is similar to a private Facebook group: people can see that it exists, but they need permission before they can read anything in it.

  • Public -- this Space is visible, and people can ask to join. By default, all Things are publicly readable. Non-members can submit comments and Things, subject to moderation.
Is that actually the right list? It feels too short, but seems to match the sharing options that I see in most modern cloud tools.

ETA: and for that matter, which of the above should be the default? I don't think Hidden should be, but I could see either Public or Private as the default selection. (Ultimately, there should be a user preference for "My new Spaces should default to Public/Private", but there's still the question of what the uber-default is. I'm not sure.)

The other question is essentially "which Role is the default for Members?", based on the standard roles we previously discussed -- Commentator, Contributor, Manager, etc. (I don't consider that list final yet, but I think we hashed out the questions there nicely. And yes, you'll eventually be able to define Space-specific Roles with custom permissions, but that's an advanced feature, and probably a little further off.)

Thoughts? Do these seem like the right general categories? Can we get away with just these two questions, and have that be good enough for most cases?
Tags: security
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 8 comments