As we make progress towards
<jessie-frame> some questions and long-term considerations start cropping out that are worthy of discussion and feedback.
I want to try to use threaded comments (ie reply to specific comments) to avoid creating too many posts.
a. Avoid needless rewrite
- Pre-parsing a resource consumed by the target is at least inefficient if not problematic.
- Yet, when application-specific parsing/rewrites are sound, they need to be done right. (ie
- Rewrites, specifically for inter-resource linking, are (in my opinion) the only potentially sound form of rewrite for statically served content — doing it server-side (ie for dumb clients) is a practice that has far outgrow any historical necessity, soundness, validity, and cost — proper facilities for this client-side is the main canvas to work towards making progress in this problem space.
b. Avoid needless intercepts
- Declarative CSP should be the only device needed to properly secure content.
- Yet, Containment via Server/Worker can be mandated by application, for anything but being a man-in-the-middle tasked with guesstimation (at best) work of screening CSP-aversive fetches (which we only start by doing anyways, until we don’t need to).
- Interceptions for requests that are meant to be possible by application (ie CORS) should both be safely intercepted and guarded against rouge interceptions — historically that was server/network/OS — the irony of our approach is that as it succeeds in intercepting requests for needless containment effect, it uncovers the dark side of Service Workers that may require more attention down the road.
c. Avoid needless obstruction
- Work towards an Unobstructed Containment model, where intended restrictions are affected without unintended ones (obstructions).
- Limiting the complexity of the containment mechanism is the best way to minimize unintended obstructions especially in cases where the mechanism could become stale, ineffective or unstable.
- Clarity of intent for imposed restrictions makes it possible to limit the complexity of the containment mechanism where common intents can lead to either battle-tested (de-facto) implementations or Web specifications where warranted — at the very least, it makes it more likely that new API’s will be designed with more awareness of and a more justifiable burden of ensuring their proper alignment with opt-in restrictions of clear and conceivable intents.