Previous Entry Share Next Entry
Coarse-grained security (seeking opinions)
jducoeur wrote in querki_project
[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?

  • 1
I think that's a good default list. Most places I've been have similar lists.

I was thinking about the roles, and thought you might want to have a designer level. It's a level I've run into needing quite a bit in my job, above contributor but not at an admin level.

Is "Hidden" really going to be at all common? Isn't Querki all about collaboration? From a marketing PoV, telling people (as the first option on the list, no less) that they can completely hide a Space is going to hurt Querki's virality. Contrariwise, someone like Cory Doctorow or Bruce Schneier would probably praise that option being up-front as a good piece of helping mold the public to think about security.

I think it's important to have the option of Hidden -- I *don't* expect it to be terribly common, but from what I've seen, I suspect that 5% of people will *really* care about it. And in an age where people are starting to wake up to privacy and security issues, I would prefer to be leading that trend rather than trailing it.

But good point about it being on top -- I suspect that the list should probably be in the reverse order, and Hidden almost certainly isn't the default. That said, though, I'm not sure offhand whether the default should be Public or Private. Hmm: that's another question to consider...

I'm not sure you want to allow "comments and Things, subject to moderation" by non-members in your public space. I think a more useful model is "anyone can read this, but if they want to submit anything, they need to be a member." You may want the wide open model you describe, too, but I think that should be a discrete setup option. Perhaps Publicly Visible vs Publicly Open.

Possible, yes -- I go back and forth on that one. I agree that it's not obvious, but in general it seems like the default for the web is that, if there are comments, anyone can submit a comment. Less obvious for contributing Things, but most of the examples around the Web suggest that that's usually expected.

Worth thinking about, though. It might be a separate checkbox, or something...

I think you should default to Private, especially if Private defaults to having an "ask to join" function, but it's been established that I have a great deal of personal paranoia. I think someone missing that setting and ending up in Public when they meant to be in Private is far more likely to cause long-term damage to the user than the other way around, and if you have two options that are about equivalent to each other, the one that causes less long-term damage to someone who screws it up should be the default.

I think I'd also add a "just me" option to that default list, in the same way LJ has one for posts. However silly one might find it to keep truly personal stuff in the cloud of something designed around community, people apparently *do*.

I've considered the latter, but thing is, "Just Me" is in every respect exactly the same as Hidden -- since nobody else knows it exists, and nobody can join unless you explicitly invite them, it *is* Just Me unless I choose to invite somebody. (That might want to be spelled-out in the description of that option.)

I think the correct answer to "what should the über-default be" is that there shouldn't be one, at least not for a general purpose site. It should be a question that you are explicitly asked during account creation. If Querki is being used to create a more targeted site, the administrator should be able to choose the default privacy setting to suit the goals of the site.

Here I'm going to disagree: for a mass-market tool, I am firmly of the belief that there is *always* an uber-default, and that we're lying to ourselves if we claim otherwise -- if nothing else, which option goes on top of the list is going to significantly influence peoples' decision-making. Not making a decision *is* still usually making a decision. (And simply saying, "it is the user's choice" is a common engineer's fallacy that doesn't match UX reality.)

Querki's hard-and-fast rule is therefore that the system should *always* have reasonable defaults for every decision. In the long run (once we're past the techie-dominated early-adopter stage), the majority of users will have far less idea about what to choose than the designers, and many will not *want* to have to think about it.

So I'd rather be honest about the fact that we can't (and shouldn't) duck this responsibility, make the best choices we can see, and test those decision as early as possible. (Rather than flailing around and getting lots of decisions wrong in the heat of the moment, the way, eg, Facebook has historically done.)

  • 1

Log in

No account? Create an account