Previous Entry Share Next Entry
Heads up / sanity check: will be tightening definitions of Can Read soonish
querki
jducoeur wrote in querki_project
This should be purely more-correct, but it's arguably a breaking change, so I wanted to warn folks in advance, and get a quick sounding.

I just opened a bug for something that has been bothering me for a while. The summary is that Read security is far too ad-hoc at the moment: it is basically relying on the endpoint display code to check the security, and I now understand the system well enough to be very clear that that's unworkable. It's already leaking information in various ways -- most obviously, that even if you can't read a Thing, you can still see it in listings. Worse, there is basically no sanity-checking of being able to process those Things in QL expressions, so it is trivially easy to leak information from Things that are notionally private. (Querki Explorer already leaks all over the place -- that's why only Members are allowed to use it.)

My plan is a radical rethink, probably sometime in the next month, to move Can Read enforcement from the "business logic" layer all the way down to the "database" layer. Basically, when you work with a Space, what you will actually see will be a stripped-down version, with the Things you aren't allowed to see removed from it. This will basically be the inverse of the way we handle User Values -- at more or less the same time that we enhance the Space to include your User Values, we will strip away the Things you can't read.

This basically swings in the opposite direction security-wise -- it tightens things to a near extreme. Most importantly, it means that initially there won't be a way to expose information that the reader can't see: a QL expression that shows many Things for the Owner might show only a few, or none, to the general public, even when you're just trying to show a summary. The philosophy there is that our typical end user is *not* going to be an expert, and will probably have at best the most rudimentary understanding of security, so we're going to have to protect them from themselves.

In order to allow the savvier user to build summary pages and reports that involve more data than the reader could otherwise see, we'll need a follow-on feature that allows the author of a Thing to say, "allow the readers to view this Thing as if they were me". This seems like the sanest way to handle security widening. It arguably allows a malicious Member to expose information to the Public that they couldn't otherwise see -- but the Member could do that in other ways anyway. It's a slight hassle, but that is kind of the point: if you're going to violate security, you should have to think about it a little.

(Eventually we might need a more-refined version that allows the author to set the read security to a *subset* of their own rights, specifically so that the Owner can say, "treat this Thing as if the reader were a Member", but that is persnickety enough that I'm honestly unsure anyone's ever going to care.)

Opinions? Does this plan seem reasonable? I believe it fixes several current gaping holes in Read security, and will allow me to implement a lot of features that I've been avoiding because they would add more such holes...
Tags:

?

Log in

No account? Create an account