Conceptual ses-frame Implementation for browsers

Distributed SES
#1

Based on discussions form our last Tuesday meeting in January (pre TC39) where we considered feasible ways to securely bootstrap SES realms in the browser, I started refining the requirements for a conceptual implementation in this document: https://www.smotaal.io/experimental/modules/ses-frame

I’d like to share this with the group for insights and to invite anyone interested in joining in on the efforts to connect. I think a concept that avoids the complexities and risks of having any code (privileged or otherwise) actively intercepting every single network request is both theoretically valid and feasible for conforming browsers, avoid unnecessary experimental features (ie aside from iframe.csp(…)).

Edit: Fixed link glitch

1 Like
#2

@Chip: In Thursday’s you expressed some concerns relating to the underlying premise of a CSP-based design. I’d like to open a channel to learn more about these concerns and how we can leverage them towards refining a design that does not violate SES requirements nor leave an SES encapsulated application open to external vulnerabilities associated with browsers in general.

#3

This is a great goal, I would be very impressed if browsers implemented it, but even with a constrained-iframe type, users would still be prone to the security of the parent site, DNS attacks, CA/mitm attacks, and whatever surveillance that site wanted to incorporate.

I somewhat think this kind of goal might merit a new browser. For example, I’m imagining if Beaker Browser added a very tight/granular ocap layer around a user’s own sites, we could start building websites that were constrained from the start, but easy to extend permissions from.

1 Like
#4

This goes a little further than an idea we considered before ses-frame and relied on browser extensions.

Exploring those domains is still on the table and can be a parallel efforts with a lot of overlap.

1 Like