Simon Riggs wrote:
> Kevin Grittner <kgrittn@mail.com> wrote:
>
>> I hope we can leave the syntax for this feature open to such
>> specification, even if the initial implementation only supports
>> limiting reads.
>
> Well, I hope the opposite: that we can support simple full security by
> default, while leaving syntax open.
>
> The basic model for this is complete separation of data between
> customers/people. They can't see my data, I can't see theirs. Simple
> privacy. Obvious.
And something we already can handle several different ways.
Inheritance, schemas, etc. Allowing data to be fully secured from
prying eyes on entry, regardless of whether the role allowing the
entry has rights to see the data does not yet have any built-in
support.
> Sure, more complex applications exist, but forcing the simple/common
> usage to adopt triggers because of that is not a sensible way
> forwards. Simple basic functionality, with an option for more advanced
> cases is what we need. Setting a status flag so that the current user
> no longer sees the row is a good example of more complex workflows in
> secure applications, I agree, but its not the common case by any
> means.
>
> When we have these discussions about priority, it seems people think
> this means "don't do it ever". It doesn't, it means do the most
> important things first and then do other stuff later. I always wish to
> do both, but circumstances teach me that hard cutoffs and deadlines
> mean we can't always have everything if debates overrun and decisions
> aren't forthcoming.
Well, it seems we have different views of what is intuitively
obvious here. What you suggest does not look to me to be more
secure (making "full security" a misnomer), simpler, nor more
important. Perhaps we can avoid divisive discussions on which is
more important if we can manage both in the initial implementation.
I guess the usual rule if we can't manage it is that a tie goes to
the author, which is neither you nor I.
-Kevin