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
{{ message }}
This repository has been archived by the owner on Jul 3, 2019. It is now read-only.
Right now, we create an instance of the avm2 for each SWF embedded in a page. This costs a lot of memory and increases the startup time by a considerable amount.
Instead, we should change avm2 to allow for multitenancy. This entails at least the following work-items:
implement SecurityDomain fully enough to enable the existence of separate instances of AS3 classes, be they built-in or application-specific.
switch the currently active SecurityDomain before executing code for a specific player instance.
coming up with a plan for dealing with Object.prototype and Array.prototype, which we can't meaningfully prevent client code from accessing.
figuring out how to deal with workers.
For 3., @mbebenita, @jeffdyer and me were of the opinion that freezing the prototypes after initializing the Shumway sandbox should work. There might be some Flash content that relies on being able to write to them, but it should hopefully be very rare.
For 4., I can imagine either having a worker pool that's shared amongst instances, or creating a worker per instance, as we currently do. Given that the workers contain much less code than the main-threat avm2, this would probably not be too bad.
The text was updated successfully, but these errors were encountered:
Right now, we create an instance of the avm2 for each SWF embedded in a page. This costs a lot of memory and increases the startup time by a considerable amount.
Instead, we should change avm2 to allow for multitenancy. This entails at least the following work-items:
SecurityDomain
fully enough to enable the existence of separate instances of AS3 classes, be they built-in or application-specific.SecurityDomain
before executing code for a specific player instance.Object.prototype
andArray.prototype
, which we can't meaningfully prevent client code from accessing.For 3., @mbebenita, @jeffdyer and me were of the opinion that freezing the prototypes after initializing the Shumway sandbox should work. There might be some Flash content that relies on being able to write to them, but it should hopefully be very rare.
For 4., I can imagine either having a worker pool that's shared amongst instances, or creating a worker per instance, as we currently do. Given that the workers contain much less code than the main-threat avm2, this would probably not be too bad.
The text was updated successfully, but these errors were encountered: