Optional automatic same origin iframes Sentry support using Snow ❄️

[weizman]

Hi Sentry people (love your work!)

Snow ❄️

In MetaMask 🦊 we are developing a JS security shim called Snow ❄️.

Snow exposes the simplest API to hook a callback to the event of new realms creation.
In other words, you can provide Snow a callback, and it will be invoked with the creation of every new iframe in the page:

SNOW(win => console.log('new iframe detected:', win));

Proposal

I think Snow integration into Sentry can be useful, you can for example support a new option passed on to Sentry.init() called APPLY_SENTRY_TO_ALL_REALMS_AUTOMATICALLY=false that when is set to true passes the init logic as a callback to Snow which will automatically invoke for all new iframes in the page.

By doing so, Sentry's logic of capturing, transporting, etc will apply not only to the top main realm but to inner iframes as well automatically with zero effort.

Demo

To make sense of my proposal, I took The original Sentry Demo, built it and isolated it to a separate repo without changing anything about it.

On top of that I proposed a demonstration PR to show the needed modifications for Sentry to successfully integrate Snow - hopes it'll make more sense weizman/sentry-snow-integration-demo#1

Discussion

I'd like your opinion on this, would be cool to see Snow being relevant somehow to this project (Snow is licensed as MIT)

[AbhiPrasad]

Hey @weizman, thanks for writing in! This seems super interesting.

I don't think we'll be merging in an option to change the top level Sentry.init, but we can definitely consider adding this to our docs or including this on our blog.

How does this work with micro-frontends? This is a big concern for us at Sentry, and if we can make this work with that, maybe we recommend using Snow as the recommended approach.

[weizman]

Hi @AbhiPrasad, I'm thrilled you see it that way!

I trust you obviously on the best approach here as you know the architecture of the project best and I don't (at all), I just hope the demo and the idea helped me demonstrate my vision for integrating the two projects.

Can you elaborate on the question? Hopefully I understand it correctly:

Snow's major priniciple is making sure it causes zero impact to the appliaction it runs with. Snow is tested to successfully run on Firefox, Safari and all Chromium based browsers. Snow is also tested against most major websites in the world including facebook, instagram, youtube, tiktok, github, netflix, twitter, etc to ensure those continue to work with Snow just as they do without it.

I (clearly) don't understand the architecture of Sentry, but I'm pretty sure that in order to integrate Snow, Sentry would have to be able to internally work with an alternating global object instead of hardcoded defaulting into the top global object (kinda like my demonstration), otherwise Snow wouldn't be able to impact the process:

// current sentry arch
Sentry.init = function() {
  fetch = function() {
    // sentry hook
  }
};

// useless since sentry doesn't work with realm as an argument
SNOW( win => Sentry.init() ); 

// desired sentry arch
Sentry.init = function(win) {
  win.fetch = function() {
    // sentry hook
  }
};

// useful since sentry now works with realm as an argument
SNOW( win => Sentry.init(win) ); 

So if I see it correctly, updating docs and recommending Snow might not be enough?

Another approach to this might also be to leave Sentry code as-is but to use Snow to evaluate a new separate Sentry instance for each new realm, but this seems an infrior option because:

1. It really depends on how Sentry is currently loaded by the consumer into the top main realm
2. Doesn't seem ideal to have separate Sentry instances for separate realms instead of a single instance to rule all realms (because Sentry is a monitor tool per web app rather than per realm, right?)

Would love your feedback on this 🙏

[AbhiPrasad]

Thank you for all the detail!!

Another approach to this might also be to leave Sentry code as-is but to use Snow to evaluate a new separate Sentry instance for each new realm

Ideally what we could do is generate a new Sentry hub for each realm, but share the same client.

// Global scope
Sentry.init({})

// realm scope
SNOW(win => {
  // inherit from global hub, but isolate errors/breadcrumbs to this SNOW (so windows don't leak into each other).
  const oldHub = getCurrentHub();
  win.__SENTRY__ = win.__SENTRY__ || {
    extensions: {},
    hub: undefined,
  };
  const client = oldHub.getClient();
  const scope = oldHub.getScope();
  setHubOnCarrier(win, new Hub(client, Scope.clone(scope)));
}); 

[weizman]

Oh nice! And is that enough to work? Would that promise tracking of inner realms by Sentry?
What else needs to be done to move this forward?

[AbhiPrasad]

Ideally we can expose this abstraction so that users can essentially configure hub propagation mechanisms (which is is the class we use at sentry to control our data), but this requires some more architectural work in the SDK.

We're going to re-visit this in the future, but there's not much we can do at the moment unfortunately.

Would that promise tracking of inner realms by Sentry?

The above code should make it so that that every realm gets tracked (have not fully tested though), and that they stay isolated from each other (data does not leak between them).

[weizman]

Cool, thanks!
So are there any relevant places/docs I can suggest PRs against to offer using Snow optionally?
Would that be helpful?

[AbhiPrasad]

I don't think there's a good place for this at the moment unfortunately - but this does sound very useful. Maybe you can look to writing a blog post or something similar?