Security

"Create any Thing" menu pick doesn't respect fine-grained permissions:

A Space should be able to get the Email for a User: This is particularly useful for lightweight "survey" use cases, where we are passing out shared links, folks are signing up for Querki and then entering themselves into the survey. It's a bit of a UX bug that they wind up typing their email address into both Querki and the Space itself.

Edit button should be disabled if I can't edit: Look at this page when not logged in. You can still click the "Edit" button, and it still shows something, but the results are mysteriously empty. The button should be disabled, probably with hover text to indicate why.

From Security, I should be able to get to Invitations: When trying to set up a Space, I want to set up the Security early on. While doing that, I'm likely to want to invite people when I find they aren't already here. This should have a direct link.

I should be able to debug the Permissions for a given Person or Role: Chad suggests: "start working on a simple drop in piece of QL that generates some permissions reports so owners can debug what's going on with the overlapping sets of permissions at the different levels."

I should be able to define a Space as Hidden: Currently, we decide whether a user can access a Space at all by checking their Read access to the Space Root. (In ClientApi.requestInfo.) This really should be a separate flag, at the system DB level, which says whether non-members can even see the existence of this Space.

I should be able to delete a Custom Role: Once a Role is created, there is currently no good way to remove it. That should be fixed.

I should be able to disambiguate my Members: See details, but the tl;dr is that it's hard to tell which member is which.

I should be able to easily manage the membership of a Role: This includes having a single UI where I can type in the handles of members and add them, in a nice easy operation.

I should be able to edit Things that I create: The current security model has a hole: if I have Create privs, but not Edit, then I create a Thing and immediately can't do anything with it!

I should be able to make a Shared Invitation that only grants access to a specific Thing: The current Shared Invitation mechanism grants access to the entire Space. In some use cases (eg, LARP Casting Questionnaires) it would be better to limit that to a single Thing.

I should be able to programmatically set permissions: That is, I want to be able to give a QL expression for something like Who Can Read. A Respectful Calm demonstrates this need vividly, where I've hacked in a relatively subtle version of this with the I Can Read Game flag, but doing it in user code isn't remotely as secure as doing it in-engine.

I should be able to restrict editing to the Person who created a Thing: This is coming up in several use cases: I have a "directory" Space where people can create Things, and only those creators (and the Editors) can then edit them.

I should be able to see a list of Persons with this Role:

I should be able to show a "how to join" message on private Spaces: That is, say I have a Space like the Carolingian Site Book. This is private, readable only by members, but if a non-member comes along, I want to be able to show a message saying how to request to join.

I should be able to view Things with lower permissions than I actually have: In other words, "As the Owner of the Space, I should be able to look at Things as if I were a member of the Public".

I should get (at least) a warning if I make Instances more readable than their Models: Currently, using the fine-grained Security system it's entirely straightforward to make a Model Owner-only, while allowing others to do things to its Instances. That mostly doesn't work.

I should receive feedback about the quality of my password when I sign up: As many systems do, we should probably provide a visual indication of how "good" the password is.

Introduce Passkey support: Add Passkey support for logging into Querki

It should be possible for one Permission to delegate to another: That is, I should be able to define Permission A as "anybody who has Permission B".

Mouse cursor for custom roles isn't a hand:

Need to track down and eliminate all uses of SHA1: We're using SHA1 under the hood in a couple of places. These need to go away.

Optimize the Read permission recalculation when a Space changes: This is currently wildly inefficient, and while I try to avoid premature optimization it seems likely to become a disaster for the Arisia Volunteers Space: with hundreds of people frequently modifying a Space with tens of thousands of records, it's likely to bog down.

Querki should prevent users from using excessively-common passwords: Nothing too radical here: we should find a good list of the most common, say, thousand passwords, and simply forbid those when you sign up or change your password.

Querki should rate-limit login attempts: At the moment, we're not doing anything to track login attempts. That's a security hole: a determined attacker could spew lots of login guesses, to try and crack someone's password. If a user has a weak password, this makes it too easy for someone to crack it.

Rationalize the Permissions in the standard list: This needs a bit of thought, but the list shown in, eg, Edit Role is pretty ad hoc. We might need to, eg, distinguish between Standard and Advanced Permissions.

Revamp the Admin Security Model: The current approach for Admin is better than nothing, but largely sucks. It should be almost entirely rebuilt.

Role selection buttons have poor affordances: We display Role(s) with cutesy-poo buttons that look nice. But they lack any affordances telling you that you can change them.

Strangely intertwined permissions in the Playtest Space:

The Design Permission probably doesn't make sense any more: This needs sanity-checking.

The Owner of the Space should be display as such in Sharing: Mild usability bug: currently, the Owner usually shows up as Basic Member Role. It should really display as "Owner" by default, to reflect reality.

The Role tab should include the built-in Roles: This is probably a good place to put the description of what each Role means.

The Sharing Page should say what each Role means: Currently, the selection of Roles, during invitation, is a bit opaque.

There should be a Can Manage Sharing permission, separate from Can Manage Security: Currently, both the Sharing and Security pages hang off of Who Can Manage Security. But conceptually they're separate -- Can Manage Security is about defining the Space, and Can Manage Sharing is about invitations, roles, and deciding who gets to do what.

There should be a Can Write Active QL permission: Now that we have side-effecting QL functions (_changeProperties, _notify, etc), it is now way too easy to create social-engineering attacks. We need to lock this down, probably by locking down who is allowed to write QL expressions.

We need to cope properly with invitee trying to sign up for Querki a second time: At the moment, if you receive an invite to a Space, sign up for Querki, then later click on the invite and sign up again, I believe we will crash (correctly) in createUser(). We should detect and handle this earlier.

When I create a Space, I can't immediately see the Security menu item: Don't know why, but I observed this as the case when Anna created a Space.

When I set a custom Permission on an Instance's Security Page, it shows up in the Instance Editor: That is, if I add a Person or Role to a custom Who Can Edit, then Who Can Edit shows up in the Instance Editor. It shouldn't -- this should only be in Security.

Who Can Read buttons on Edit Space Info page seem to work inconsistently: When I press the "Everybody" or "Members Only" buttons on Edit Space, I frequently wind up in an inconsistent state.

Who Can Read on Edit Space doesn't affect Instances!!!: Go into Edit Space. Set the Who Can Read to "Members". The Space Root is now hidden -- but if you happen to have internal URLs, they are Public!!!

Who Can Read: Public isn't working right?: Noticed by Chad: this page -- the Public Blurb for A Respectful Calm -- isn't actually Anonymous-readable. That probably means something is badly broken in security, and needs to be fixed ASAP.

_notify() requires better security: As currently constructed, anybody who can write QL can send notifications, which is deeply Not Okay.

As a Manager, I should be able to use the Show Thing command: This is powerful and useful enough that non-Admins should be allowed to use it. But it should require extremely high levels of permissions, because it gives so much insight into the Space.

Can't set Who Can Read on a Space: Almost certainly a side-effect of turning it off for Properties last week.

Direct assignment of Who can Edit / Create to Members not working?: I created the Querki Knowledgebase, set Who Can Edit and Create to "Members", and invited Aaron. He got errors when trying to save.

I should be able to define a group that can create and edit only specific Models: The existing mechanisms don't work for this: the Editor and Contributor Roles are too powerful, and you can't assign a Role in Who Can Edit Children.

I should be able to define multiple Shared Invites for a given Role: The current approach is arguably broken, since once you revoke an Invite, you can never use that Role for invites again.

I should be able to define the Space-wide Permissions for a Role:

I should be able to Edit a Role:

I should be able to Edit anything I Create: This is just plain necessary if we are ever going to allow Who Can Create to work without Who Can Edit -- since "Create" just creates an empty Thing, I need to then be able to edit it.

I should be able to hide the "exploratory" aspects within my Space: Requested by Eric, who wants to really control how people wander around in his Spirit Island FAQ. Seems reasonable.

I should be able to set Space-wide permissions for a Role: This was always the purpose of Roles; it is silly that there isn't yet a UI to actually do it for Custom Roles.

If an Exception is thrown during Permission Checking, we get an RSOD: That is, if I am not the owner of the Space, and for some reason the attempt to filter out what I can read throws an Exception, I can't load the Space at all.

If I try to look at a Space I can't read, I hang on "Loading...": Encountered by Roza -- part one of a two-part bug, I believe.

Illegal password error message displays the password in plaintext: Reported by Conor: the system rejected his password, and showed it on the screen. That clearly needs to be fixed.

It should be much easier to manage security: Time to implement a proper UI for this.

QL Functions can run indefinitely: Currently, it is fairly easy to write a QL expression that runs for Way Too Long -- far longer than the Gateway will allow. It's probably possible to write an infinite loop, although we try to avoid that. That's not okay.

Querki should be all-HTTPS: At this point, the technically-sophisticated users increasingly expect it, and it's hard to say that the system has good security without it. So we should just bite the bullet and do it.

Setting a Permission on a child model also sets that permission on the parent model: Eric hit this one in the field. It is deeply weird, but repro's easily.

Space Security Defaults should be separate from the Space Root's own security:

Space Security's Instance Read setting doesn't appear to work right: This is potentially a serious security issue, so investigate soon.

There should be a permission for assigning Custom Roles: This is needed for Arisia: Staff Services should be able to designate people as "Staff", and that should be a Custom Role since it has UI implications.

Users can change a Thing to a Model that they aren't allowed to Create: Observed by Eric: Change Model isn't properly protecting the target Model.

When I change a member's Role, their Read visibility isn't reflected correctly: This is in the new Space-evolution code; this bug should not make it into the live system.

When I create a Role, I should stay on the Roles tab:

When removing a bunch of guests at once, only the first one actually gets removed: Observed by Eric when trying to do a mass removal. Might be particular to guests?

When you reinvite someone to your Space, you wind up with multiple entries in the Sharing Page: Not sure what's going on, but it's visible in my New MySQL Space.

Who Can Manipulate Apps shouldn't be Public-usable: Just a dumb oversight.