feat(ses): ArrayBuffer.prototype.transferToImmutable#2400
Merged
Conversation
erights
force-pushed
the
markm-to-immutable-2
branch
from
August 7, 2024 18:43
c1d8ab4 to
f531bc8
Compare
erights
force-pushed
the
markm-to-immutable-3
branch
from
August 7, 2024 18:46
4390c1c to
86d38ba
Compare
erights
force-pushed
the
markm-to-immutable-2
branch
from
August 13, 2024 17:44
f531bc8 to
262bcf0
Compare
erights
force-pushed
the
markm-to-immutable-3
branch
from
August 16, 2024 21:54
86d38ba to
c9c9300
Compare
erights
force-pushed
the
markm-to-immutable-3
branch
2 times, most recently
from
September 7, 2024 20:31
19de016 to
5972da3
Compare
erights
force-pushed
the
markm-to-immutable-3
branch
from
October 14, 2024 19:30
5972da3 to
1e582fb
Compare
erights
force-pushed
the
markm-to-immutable-3
branch
from
October 29, 2024 00:01
1e582fb to
b32ab45
Compare
erights
force-pushed
the
markm-to-immutable-3
branch
from
November 17, 2024 00:50
b32ab45 to
544a213
Compare
erights
force-pushed
the
markm-to-immutable-3
branch
2 times, most recently
from
January 15, 2025 23:18
d0f1cd5 to
bc99d9e
Compare
erights
force-pushed
the
markm-to-immutable-3
branch
from
February 17, 2025 03:22
bc99d9e to
0509bcc
Compare
This was referenced Feb 17, 2025
erights
force-pushed
the
markm-to-immutable-3
branch
from
April 30, 2025 02:51
0509bcc to
07017b0
Compare
erights
marked this pull request as ready for review
April 30, 2025 03:01
erights
force-pushed
the
markm-to-immutable-3
branch
from
May 1, 2025 21:30
e2fd1ff to
75ea396
Compare
gibson042
approved these changes
May 1, 2025
gibson042
left a comment
Member
There was a problem hiding this comment.
Officially approving this PR, but it's also implicitly covered by #1538 (review) .
7 tasks
boneskull
pushed a commit
that referenced
this pull request
Jun 4, 2025
Closes: #XXXX Refs: #XXXX ## Description Now that the Immutable ArrayBuffer proposal is at 2.7 and looks likely to proceed to 3, and then on to 4 and the official language, we are now allowing ourselves to build on the shim to emulate it already being in the language. In this PR ses imports the shim (not just the ponyfill) and then permits it's additions as harmless for ses users. ### Security Considerations We carefully designed the proposal to maintain our high security standards. Likewise, in our shim, an Immutable ArrayBuffer encapsulates a normal mutable ArrayBuffer. But it is careful not to mutate it or to let it escape. The shim is low fidelity in terms of what it must practically omit --- TypedArrays and DavaView backed by Immutable ArrayBuffers. But these omissions do not raise security hazards, only compat hazards. ### Scaling Considerations Because Immutable ArrayBuffers obviate the need for defensive copying and support safe zero-copy sharing, it will help scalability. - [ ] When on XS, we should somehow arrange to use its high-speed high-fidelity highly tested Immutable ArrayBuffer implementation. We should also figure out our migration strategy as other engines of interest ship their own standards compliant implementations. All these steps will help scaling immensely. But it is unclear how to handle the transition. ### Documentation Considerations Mostly, we can just point at the docs for Immutable ArrayBuffer itself, currently in the proposal and soon in the JS standard. ### Testing Considerations The XS native Immutable ArrayBuffer implementation is also highly tested by the test262 tests in the PR they submitted, which will also test other native implementations. - [ ] Our shim is not highly tested. We should somehow test it against the relevant subset of those submitted test262 tests. ### Compatibility Considerations The shim is low fidelity in terms of what it omits from the standard. The shim is also low fidelity in that it cannot hide an internal shim implementation artifact, the hidden prototype that all and only Immutable ArrayBuffers share. A correct implementation of the proposal will have no such extra prototype object. ### Upgrade Considerations - [x] Update `NEWS.md` for user-facing changes. --------- Co-authored-by: LeoTM <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes: #XXXX
Refs: #XXXX
Description
Now that the Immutable ArrayBuffer proposal is at 2.7 and looks likely to proceed to 3, and then on to 4 and the official language, we are now allowing ourselves to build on the shim to emulate it already being in the language. In this PR ses imports the shim (not just the ponyfill) and then permits it's additions as harmless for ses users.
Security Considerations
We carefully designed the proposal to maintain our high security standards. Likewise, in our shim, an Immutable ArrayBuffer encapsulates a normal mutable ArrayBuffer. But it is careful not to mutate it or to let it escape. The shim is low fidelity in terms of what it must practically omit --- TypedArrays and DavaView backed by Immutable ArrayBuffers. But these omissions do not raise security hazards, only compat hazards.
Scaling Considerations
Because Immutable ArrayBuffers obviate the need for defensive copying and support safe zero-copy sharing, it will help scalability.
Documentation Considerations
Mostly, we can just point at the docs for Immutable ArrayBuffer itself, currently in the proposal and soon in the JS standard.
Testing Considerations
The XS native Immutable ArrayBuffer implementation is also highly tested by the test262 tests in the PR they submitted, which will also test other native implementations.
Compatibility Considerations
The shim is low fidelity in terms of what it omits from the standard. The shim is also low fidelity in that it cannot hide an internal shim implementation artifact, the hidden prototype that all and only Immutable ArrayBuffers share. A correct implementation of the proposal will have no such extra prototype object.
Upgrade Considerations
NEWS.mdfor user-facing changes.