Stepping back: what are the constraints/requirements?

[domenic]

As previous issues in this tracker plus other offline discussions have revealed, my hypotheses as to what would be implementable are not very good. As such the API currently in the README is not a great representation of what we're trying to accomplish here, as it mixes up the problem space with the solution space.

Here's my first draft of goals and non-goals that should help make things clearer for anyone, like myself, who wants to rethink the solution space.

Goals

• Work in both window and worker contexts (probably worklet too)
• Span built-in JS (ECMAScript spec) and web (Web IDL) ecosystems
• Give the ability to do the original operation for:
  • Static methods (Array.isArray; URL.createObjectURL)
  • "Namespace" methods (JSON.parse; CSS.supports)
  • Prototype getters/setters (ArrayBuffer.prototype.byteLength; DOMTokenList.prototype.value)
  • Prototype methods (Promise.prototype.then; Event.prototype.preventDefault)
  • Global getters/setters (window.opener)
  • Global methods (createImageBitmap; encodeURIComponent)
  • Constructors (Promise; Event)
• For constructors or other "create a new object" methods, return instances from the correct realm (see current readme's "Same values" section)
  • E.g. not just constructors, but also document.createElement, window.createImageBitmap, node.childNodes, etc.... this is made worse by the web platform not having a uniform answer for what realm is chosen, see https://github.com/heycam/webidl/issues/135 and also https://github.com/heycam/webidl/issues/135#issuecomment-411109348
• Usage does not make refactoring prototype chains over time more likely to break the web (see current readme's "Instance based design rationale" section)
• Be relatively efficient (at least in theory, with sufficiently smart implementations):
  • Invoking original operations should not be much slower than invoking things "normally"
  • Pages that use this API should not be worse in memory usage than pages that don't, ideally, or at least should pay only proportional to their use

Non-goals

• API is easy to use for humans. Primarily we would anticipate this being used by tools that convert idiomatic code into robust get-originals-using code.
• Getting the original value/doing the original operation for:
  • Static or global constants (NaN, Infinity, Range.START_TO_END, ...; see #9)
  • Magic data properties (Array's length)
  • Data properties in general (array[0], error.message)
  • Things which don't have a global name (e.g. the original %TypedArray% constructor; see #15)
  • Things which do not use any internal slots/brand checks and can thus be emulated in user code (see #8)

It is also a non-goal to support a way of stashing and retrieving the originals for user-supplied objects, although that would be vaguely nice if it falls out naturally from the design we end up with. (Related: https://github.com/drufball/layered-apis/issues/32)

[ljharb]

Things which do not use any internal slots/brand checks and can thus be emulated in user code

we can discuss in #8, but i feel like this is the one part i'm confused about. The goal of "Usage does not make refactoring prototype chains over time more likely to break the web" is entirely unrelated to the existence of brand checks in the underlying implementations - it seems like that goal requires also covering builtin things that can be implemented in user code.

[domenic]

I agree it's unrelated.

[ljharb]

So doesn't that non-goal implicitly thus become a goal?

[domenic]

No, they're unrelated, so that goal has no impact on the non-goal.

[ljharb]

… ok so that's still the part i'm confused about. In order to achieve the goal of "Usage does not make refactoring prototype chains over time more likely to break the web", wouldn't "originals" need to be available for all prototype methods, not just ones with brand checks, since the web will (and already does) rely on builtin methods irrespective of whether they perform brand checks or not?

[domenic]

I'd suggest taking this discussion to another issue. In particular I'd suggest starting with code that would be written using a version of get-originals which does not work on e.g. Array.prototype.map (per the non-goal) but which would somehow cause the web to break.

[mikesamuel]

+@koto

Goals should include not undoing the work of polyfills like https://github.com/WICG/trusted-types which need to patch setters and some getters on element prototypes to gate access to browser builtins.

The pattern of trusting early running code to set up bounds for late running code is a well-established one, and breaking this would make it harder for security engineers to do their jobs.

[koto]

+1 to what mikesamuel@ said. For runtime-enforced security, it's necessary to be able to constrain later running code, and the features as described here would make that impossible.

[domenic]

Let me suggest constraining your discussions to other threads, so we can use this for the design goals of the proposal authors. I'll collapse a number of comments here.