Should explicitly break down claims by integrity vs availability vs confidentiality.

[erights]

From a recent post on cap-talk:

For each type of protection we may ask "at what granularity"? We can partition most (not all) security concerns into

• integrity -- loosely, only authorized actions happen
• availability -- loosely, authorized actions continue to happen
• confidentiality -- loosely, only authorized secrets are learned.

The browser's same origin policy defends only integrity. Because code from mutually suspicious origins share an event loop, they are fully vulnerable to each other regarding availability. Among things sharing an event loop, and infinite loop by one blocks all. Finally, browsers don't claim to defend confidentiality against side channels and covert channels.

SES, operating within the browser's event loop, cannot do anything about availability and is not in a position to try. However, JavaScript in a non-browser environment like a Node server is in a position to try to defend availability to an important and practical degree. [...] we need to revise the mobile code example to explain the availability cost in making remote eval available. I was clearer about that in the earlier Concurrency Strawman section Open Vat where the permission to access that remote eval power was explicit and clear. [...]

SES makes a contribution to the less valuable side of the confidentiality issue: SES helps suppress reading non-overt channels under very restrictive conditions -- where no timing channels are granted -- but does not prevent signaling on these channels. Preventing signaling would be more valuable, but no one has any practical idea how to do that by any means.

(The text that follows on cap-talk about integrity is already reflected well in the main SES document.)

[benjamingr]

I don't understand the cap-talk terms particularly well, but I think the goal of this proposal should only be to deal with integrity - that's the problem being solved and it's a big problem anyway.

It does help with availability - since denying availability hurts integrity anyway - assuming we figure out the issue with scheduling (hooking into the job queue).

[erights]

How does denying availability hurt integrity? (This may be more of a pedantic terminology and definition issue than a substantive one.)

In any case, I agree that this proposal's strength is only in integrity. The job queue issue is an availability issue, but a weak one since there's no availability defense among things sharing an event loop anyway. The determinism issue does help confidentiality issue, but only for computations that do not need anything, like timing sensitivity, that would enable them to read a non-overt channel.

[benjamingr]

How does denying availability hurt integrity? (This may be more of a pedantic terminology and definition issue than a substantive one.)

I forgot why I said that here - I don't see why denying availability would hurt integrity at all unless availability is part of what makes an action authorized - but that's really a stretch.