On 2/28/19 9:52 AM, Dean Rasheed wrote:
> Does self-censoring mean that they might still throw an error for some
> inputs, but that error won't reveal any information about the input
> values? That's not entirely consistent with my understanding of the
> definition of leakproof
That's the question I was also preparing to ask ... I understood the
definition to exclude even the possibility that some inputs could
produce errors.
> amount of information leakage would be OK. So maybe we could have
> "strictly leakproof" functions that never throw errors and "weakly
> leakproof" functions (needs a better name) that can throw errors, as
> long as those errors don't include data values. Then we could allow
> strict and weak security barriers on a per-table basis
Interesting idea. I wonder if the set { strictly, weakly } would be
better viewed as a user-definable set (a site might define "leakproof
wrt HIPAA", "leakproof wrt FERPA", etc.), and then configure which
combination of leakproof properties must apply where.
OTOH, I'd have to wonder about the feasibility of auditing code for
leakproofness at that kind of granularity.
Regards,
-Chap
