PrivateName leak in decorators

[rbuckton]

The current semantics for the PrivateName Object can result in decorators that leak shared custom PrivateName values, breaking "hard privacy". For example:

// a.js
const sharedPrivateName = new PrivateName("shared");
export function dec(desc) {
  desc.elements.push({ 
    kind: "field", 
    placement: "own", 
    key: sharedPrivateName 
  });
  desc.elements.push({
    kind: "method",
    key: "setPrivateData",
    placement: "prototype",
    descriptor: {
      value: function(data) {
        sharedPrivateName.set(this, data);
      }
    }
  });
  return desc;
}

// b.js
import { dec } from "./a.js";

// apply the decorator, adds `sharedPrivateName` to `C`
@dec
class C {
}

// leak the private name
const desc = { kind: "class", elements: [] };
dec(desc);
const leakedPrivateName = desc.elements[0].key;

// demonstrate leak
const obj = new C();
obj.setPrivateData("private data"); // method attached by decorator

const privateData = leakedPrivateName.get(obj);
privateData; // "private data";

One possible approach to avoid this is to break PrivateName into two parts: a property "mutator" and an opaque "key". For example:

interface PrivateName {
  key;
  get(obj);
  set(obj, value);
}

Then the decorator above could be rewritten:

// a.js
const sharedPrivateName = new PrivateName("shared");
export function dec(desc) {
  desc.elements.push({ 
    kind: "field", 
    placement: "own", 
    key: sharedPrivateName.key // only send opaque key
  });
  desc.elements.push({
    kind: "method",
    key: "setPrivateData",
    placement: "prototype",
    descriptor: {
      value: function(data) {
        sharedPrivateName.set(this, data); // uses mutator
      }
    }
  });
  return desc;
}

While this still results in a key that could be added to any object, it prevents an untrusted third party from reading or writing to that state.

[littledan]

I don't quite understand. PrivateName in decorators is designed in order to leak through decorators that you chose to call. This is the basis for decorators implementing friends/protected. Are you worried about running untrusted decorators?

[bakkot]

@littledan, if I understand the example correctly, the desire is to be able to write a decorator which you will pass to untrusted code such that the decorator can install a particular shared private field (and possibly also methods referring to that field) on classes but which does not give the untrusted code the ability to access that field.

As currently designed, if a decorator installs a shared private field, granting someone the ability to call that decorator also grants them arbitrary access to that private field on any object which has it. In principle, these could be separated, I believe. I haven't thought about whether it's worth doing, but I think that's the problem statement.

[littledan]

Should there be two types of decorators, one of which is untrusted and one of which is trusted, with different syntax? Or should we do protected/friends some other way?

[rbuckton]

I don't think the solution is different kinds of decorators, as that will only complicate matters. I'm proposing separating the identity of the private name from the ability to read and write to it. This doesn't prevent a malicious user from installing the private name on another object using the opaque key, but it does prevent the malicious user from accessing or mutating that private state.

[littledan]

@rbuckton Do you imagine that the decorators in friend.js will be possible with your proposal? I don't really understand how these could be differentiated from leaks with the potential to reach "malicious users". The whole point is to allow accessing or mutating private state.

[rbuckton]

I need to look that over tomorrow, but I think it's still feasible.

[littledan]

Thanks for taking a look.

[rbuckton]

I investigated the "friend class" support in your example and here's what I came up with: https://gist.github.com/rbuckton/52e2078566fe4d8915f0f35c22a2dd10

I also took a look at "protected" state: https://gist.github.com/rbuckton/41bb58736874217880d0894f2a969a14

I don't think @Protected works correctly, as it doesn't allow for overriding and calling the super implementation. While it might be technically feasible to solve this with decorators and indirection, I would be more interested in a future syntax proposal for friend and protected.

[littledan]

I investigated the "friend class" support in your example and here's what I came up with:

You're completely right that this decorator doesn't solve the issue of how to distribute the friend key. I think it's not as bad as "they have to be in the same file", though--I think plenty of user module systems could distribute the key to some places but not every place. It's true that ESM doesn't have any concept of package private, or any other ways to restrict who you export things to, but friends is not the first place this comes up.

I'm a little wary of the imperative mechanism you use in your gist. It could lend itself to strange states where multiple packages are competing to be the first one to get the friendship, and module loading order is a bit complicated, so the top level would somehow indirectly get to choose between then. How do you know the good guy comes first?

Any other ideas, besides "who gets there first", to lock down friend access?

I don't think @Protected works correctly, as it doesn't allow for overriding and calling the super implementation.

Oops, I didn't think about protected super calls! I bet it could be worked out, but I'd have to think about it more.

While it might be technically feasible to solve this with decorators and indirection, I would be more interested in a future syntax proposal for friend and protected.

I'd be really interested in hearing your proposal in more detail here. I'm a little embarrassed--I thought we could solve this problem with decorators, and this was part of how the committee decided to move forward with just private. I definitely think we should work this out before moving too fast on decorators--the current decorator design is based on friends and protected as motivating use cases for certain aspects of their design.

[rbuckton]

I'm a little wary of the imperative mechanism you use in your gist. It could lend itself to strange states where multiple packages are competing to be the first one to get the friendship, and module loading order is a bit complicated, so the top level would somehow indirectly get to choose between then. How do you know the good guy comes first?

In C++, it is the responsibility of a class to declare the friends that are allowed to see its private state, e.g.:

class A {
    friend class B;
private:
    int x;
};

class B {
public: 
    B(A a) {
        a.x = 0;
    }
};

To expand on my example, if you want A to be friends with multiple classes (e.g. B and C), you would have something like getFriendBOfA() and getFriendCOfA(). I agree its not a great solution, but its designed to throw an exception at the module level in the hopes the application crashes rather than continue with someone having untrusted access to the private members of A.

I wrote up my early thoughts for protected, etc. here: #25

[bakkot]

@littledan

Oops, I didn't think about protected super calls! I bet it could be worked out, but I'd have to think about it more.

Is the use case here "base class defines a protected method and and a public method which refers to it, and derived classes can override the protected method so that the inherited public method behaves differently"?

If so, I too am confident you can make that work using the "pair of decorators" approach, although you still wouldn't be able to use super.#m (since it continues to not even match the grammar) - which I think should continue to be the case, personally; given how private fields actually work in JS, there's too much potential for confusion otherwise.

To allow referring to a superclass's protected methods in a subclass which overrides them, one straightforward (and also otherwise useful) solution is to make a version of @inherit which aliases - that is, so you could do something like

class Base {
  @protected m(){
    return 0;
  }
}

class Derived extends Base {
  @inheritFrom('m') #superM;

  constructor() {
    super();
    this.#superM() === 0; // true
  }
}

Then an overriding method can just refer to the aliased method, rather than super.#m. This is maybe not the most clean of designs, at least if you're coming from a language which allows super.m, but on the other hand it works well with the existing mental model and doesn't require any changes to the language.

[littledan]

@rbuckton A difference in C++ is that it lets you forward-declare classes, which isn't available in JS. This allows for mutual friendship.

[allenwb]

This is an concern that I noticed a few weeks ago and mentioned to @erights when we were both at the splash conference.

Note with the current design I can easily imagine somebody writing a trojan decorator that was specifically designed to expose access to some private fields.

I'm keeping this short right now. But I don't think it is necessary (and actually very undesirable) to make PrivateName a new kind to primitive value.

A safer approach, is for private fields that be exposed to decorators as thunks (or unique objects) that are only usable while a specific class definition (or perhaps invocation of a decorator) is being process. Once that definition is finished those values become useless.

I can fill in more details. But the current approach really is not good from a hard private perspective.

[littledan]

Looking forward to the details! It is a little hard for me to picture.