You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of today, it is a conscious decision to disable some native behaviour in the browser when it is (1) posing a security concern to Snow and (2) is a behaviour that is unused legitimately in the wild.
This is something we'll continue to do, but it's also contradicting our will to make Snow a perfect shim, meaning it shouldn't harm web apps normal behaviour whatsoever.
Therefore, it is time to allow some level of configuration for Snow.
At the very least, a way to tell Snow to either "block activities that might pose danger to Snow" or "keep Snow protection, but not at the cost of disabling browser native behaviour", so that security focused vendors could take the risk, while observability focused vendors could opt out of that risk and stick to most realm creation cases instead of all (e.g. what happened at highlight/highlight#3934)
The text was updated successfully, but these errors were encountered:
This is great. How did you think to implement that? something like SNOW(cb, { mode: 'lax' }), or SNOW(cb, {ALLOW_SRCDOC_WITH_CSP: true}) (etc, for each potentially breaking behavior)?
Great question. Currently, it's one of the two. I'm wondering if to split it to either:
lax or strict - where lax is "snow gives up on anything that breaks standard JS behaviour" and strict is "snow does whatever it takes to stay as protected as possible";
deeper resolution - where each JS behaviour breaking protection is flagged and the user can enable/disable each one separately
maybe support both?
This requires some thinking, am very open to opinions on this.
Now that #133 is about to be merged, this issue gets a different spin.
We might want Snow to accept "unsafes" with which the user can request to unsafely allow actions that Snow currently throws on.
In other words, allow each error Snow throws to be silent by configuration, for those who are willing to give up on security in sake of support and adoption.
I'll leave this issue open, and if anyone wants this to happen, speak up 🙏
weizman
changed the title
Split Snow to lax and strict modes
Support "unsafes" - unsafely configure Snow to allow non-secure operations
Aug 2, 2023
UPDATE: see #110 (comment)
As of today, it is a conscious decision to disable some native behaviour in the browser when it is (1) posing a security concern to Snow and (2) is a behaviour that is unused legitimately in the wild.
This is something we'll continue to do, but it's also contradicting our will to make Snow a perfect shim, meaning it shouldn't harm web apps normal behaviour whatsoever.
Therefore, it is time to allow some level of configuration for Snow.
At the very least, a way to tell Snow to either "block activities that might pose danger to Snow" or "keep Snow protection, but not at the cost of disabling browser native behaviour", so that security focused vendors could take the risk, while observability focused vendors could opt out of that risk and stick to most realm creation cases instead of all (e.g. what happened at highlight/highlight#3934)
The text was updated successfully, but these errors were encountered: