What is the expected interaction of [SecureContext] with mixins?

[bzbarsky]

Consider this IDL:

[SecureContext]
interface A {};
[NoInterfaceObject]
interface B {
  void foo();
}
A implements B;

Is the foo method available on A objects in non-secure contexts? Per the current spec text, I'm pretty sure it is, right? That's probably OK, but may be worth an example in the spec.

@mikewest

[tobie]

My reading of the spec is that A objects won't be exposed at all in non-secure contexts, so foo() can't be exposed on something that itself isn't. @mikewest, this was the intent, right?

[bzbarsky]

[SecureContext] on an interface controls whether that constructor is visible on the global and whether the methods are visible on the prototype. It does NOT control whether the objects are available at all, as far as I can tell.

Now arguable it's a specification bug to have a method that returns such an object in a non-secure context. But nothing prevents someone from writing such a spec, really...

[tobie]

So in the #433, I'm voluntarily conservative with mixin's exposure sets. That is, mixin members inherit the host interface's "exposure set" unless they (or the mixin or partial mixin they're defined on) have an "own exposure set", in which case the mixin member's "exposure set" is the intersection of the two.

It seems we should do the same for [SecureContext].

That is, if they're included in a host interface which is itself annotated with [SecureContext], then none of the mixin members should be exposed, regardless of whether or not the mixin itself, or any of its members has a [SecureContext] extended attribute.

[annevk]

It does NOT control whether the objects are available at all, as far as I can tell.

That seems like a bug of sorts in IDL? I would expect it to work like [Exposed] (and also inherit in the same way as that does).

[bzbarsky]

[Exposed] doesn't enforce that either, afaict.

Specifically, this is currently valid IDL, I believe:

[Exposed=Worker]
interface Foo {};

[Exposed=Window]
interface Bar {
  readonly attribute Foo foo;
};

or at least I see nothing in https://heycam.github.io/webidl/#Exposed that would prevent it.

That said, at least Gecko's binding generator includes checks not present in the IDL spec. Given the above input, it fails IDL validation with:

error: Attribute returns a type that is not exposed everywhere where the attribute is exposed

basically to keep people from doing stupid stuff. It might make sense to add that sort of check to IDL, of course.

That said, there is no way to prevent this solely via IDL. Consider this example:

[Exposed=Worker]
interface Foo {};

[Exposed=Window]
interface Bar {
  readonly attribute object foo;  // Prose says to return a Foo instance
};

[tobie]

Yeah, it's the same problem for [Exposed].

Seems like this belongs we could check this in the bindings, no? Add a check to see if the returned type is exposed in steps 2.1.6 and 2.1.7 of https://heycam.github.io/webidl/#dfn-create-operation-function and similarly for step 1.1.4 of https://heycam.github.io/webidl/#dfn-attribute-getter.

[bzbarsky]

I am pretty opposed to any dynamic checks here. I would be ok with static IDL-validity checks (that would not catch the "object" case, granted).

[tobie]

Created a separate issue to handle objects implementing non-exposed interfaces to just float around (#449).

---

Going back to your initial question: "What is the expected interaction of [SecureContext] with mixins?"

Here's my proposal: If a mixin is included in an interface which is itself annotated with [SecureContext], then none of the mixin members should be exposed, regardless of whether or not the mixin itself, or any of its members has a [SecureContext] extended attribute.

As noted in #118 (comment), this is also what I'm proposing to do with [Exposed] and matches the existing behavior or partials (I'm generally treating mixins as named partials).

Would that work for you, @bzbarsky?

[bzbarsky]

then none of the mixin members should be exposed

In a non-secure context, right? That seems reasonable to me.

[tobie]

In a non-secure context, right?

Yes.