search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
327 stars 55 forks source link

Capability Delegation #655

Closed mustaqahmed closed 2 years ago

mustaqahmed commented 3 years ago

Ya ya yawm TAG!

I'm requesting a TAG review of Capability Delegation.

"Capability delegation" means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it trusts. The focus here is a dynamic delegation mechanism which exposes the capability to the target frame in a time-constrained manner (unlike <iframe allow=...> attribute which is not time-constrained).

Further details:

You should also know that our previous TAG request to delegate user activation raised valid concerns about being too generic, so we limited the scope of delegation here to a particular API. More details can be found in this section in the design doc.

We'd prefer the TAG provide feedback as: 🐛 open issues in our GitHub repo for each point of feedback

mustaqahmed commented 3 years ago

We are hoping to start a Chrome Origin Trial with Stripe as a partner by the end of August. We would really appreciate a feedback here to prepare for that, even if it is just a preliminary feedback. Thanks!

hadleybeeman commented 3 years ago

Hi @mustaqahmed. We are looking at this in our TAG breakout.

We were wondering: Can advertisers ask top-level sites to give them this permission, and get more control than they have now? We already have the potential for a similar issue when advertisers ask the top-level site to run their ad script, but would your proposed API make the situation more confusing for users?

flackr commented 3 years ago

Hi @hadleybeeman. It's true that advertisers could now ask top-level sites to delegate them a capability instead of just requiring their ad script to run (which gives them arbitrary permissions). However, the ability of top-level sites to delegate the capability is ephemeral both in when it can be done and how long it can be used.

  1. It can only be done when the top-level site has user activation (e.g. click). This means the ad-frame could not expect to have the capability at any arbitrary time which would make it difficult to enforce (i.e. the ad-frame wouldn't know whether it doesn't have the capability because the host site didn't grant it, or because the host site didn't get an activation for it yet).
  2. The capability itself is very short-lived. When granted the ad-frame can only use it for a very short window of time.

Additionally, the specific capability is explicitly granted so it is easier to audit than ad-script.

torgo commented 3 years ago

Hi @mustaqahmed @flackr we're discussing in this week's TAG breakouts. is there anything further on multi-implementer support? I note a link to the Mozilla Standards Position and the feedback seems like positive engagement...

mustaqahmed commented 3 years ago

We are not aware of any implementation plan by other browsers, but we're actively involved in working through the design with Mozilla (see the issues in our repository).

We would appreciate any feedback/comment from TAG, even if they are preliminary.

atanassov commented 2 years ago

The general capability is useful and in its current form it establishes a clean control pattern into the main document. One nit that stood out for me is that through the current list of feature-identifiers you can get access to device sensors (camera, geolocation etc.), provided the users has given access already. Can you confirm that is true and if so, can you amend the security&privacy section to state that?

atanassov commented 2 years ago

Under further review and reading through the entire list of standardized features, we are concerned about making all features available for delegation. More specifically, if a top level document is granted camera, usb, web-share etc. permission, it shouldn't be able to delegate without additional user consent.

Our recommendation is to specify an allow subset of features, namely payments and fullscreen (from what I can tell are current use cases) and be explicit about it in your spec.

mustaqahmed commented 2 years ago

Under further review and reading through the entire list of standardized features, we are concerned about making all features available for delegation. More specifically, if a top level document is granted camera, usb, web-share etc. permission, it shouldn't be able to delegate without additional user consent.

That's a valid point, thanks for highlighting this.

This proposal is not meant to cover the delegation of "all features". Instead, it just defines an interface for delegation, which can used by individual feature-owners in future if they decide to make the feature available for delegation.

To further emphasize this perspective, our monkey-patch to Payment Request spec (developed in consultation with that spec's owners) is just one specific example we added for sake of the completeness the Capability Delegation proposal. Without such a concrete example, it is impossible to convey the details of delegation.

Each individual feature-owner would run a separate review process when proposing a change to corresponding feature's spec in future. For example, if the camera spec-owners decide to allow delegating this feature in future, they would need to define the delegated behavior of this feature. Such a definition would require a detailed spec change on their side, hence would call for a feature-specific review.

Our recommendation is to specify an allow subset of features, namely payments and fullscreen (from what I can tell are current use cases) and be explicit about it in your spec.

That's a great recommendation, thanks. It seems we can easily incorporate this "allowed subset" idea by conveying the success/failure status of the postMessage() call that initiates a delegation. For example, we can throw an exception if developers try to delegate a capability not available for delegation.

I will start updating the proposal in a few days and ping this thread when done. In the meantime, if anyone finds any problems with this, please let me know.

domenic commented 2 years ago

Under further review and reading through the entire list of standardized features, we are concerned about making all features available for delegation. More specifically, if a top level document is granted camera, usb, web-share etc. permission, it shouldn't be able to delegate without additional user consent.

Can you say more as to why?

Currently, if an outer page wants to delegate a capability an inner page, they can do so through hacky ad-hoc protocols: i.e., just proxy the API over postMessage(). For example, if a subframe wants camera permission, it would do something like window.top.postMessage("give me camera", "*") and the top page would have an event handler like

window.onmessage = e => {
  if (e.data === "give me camera") {
    requestCameraPermissionInThisTopFrame();
    const cameraData = getCameraData();
    e.source.postMessage({ cameraData }, "*");
    // perhaps repeat every 16 ms if they want video
  }
};

To my eye, capability delegation just provides a standardized mechanism for doing this, without requiring manual coding. So it seems like it should be usable for any API.

If this is not true, and I've misunderstood the explainer, then that'd be helpful information for the explainer to include :).

annevk commented 2 years ago

I'm also confused now and I agree with @domenic that all of this is already possible if the parties cooperate (which sending a message implies; though it should be stricter on origins, filed https://github.com/WICG/capability-delegation/issues/17 on that). Here's what I thought the idea was:

  1. Permissions Policy is used to delegate the permission, but it doesn't delegate the user activation. The user would still have to click in the frame if the API required user activation.
  2. Capability Delegation is used to delegate the permission and user activation.

There's no need that I can see for 2 to be restricted to a subset of APIs and I think we should make it work for all the things that require user activation today and are part of Permissions Policy. (And we should make the specification architecture reflect that better as it currently requires a lot of language for each individual API that can be better abstracted.)

shhnjk commented 2 years ago

I logically don't understand why we are in model where we have to pass permission from top frame to child frame, if child frame is the one who actually want to use the permission.

If this spec is trying to solve the user activation, why can't we just tie user activation with API usage? For example, parent frame wants to delegate user activation for payment, it'll postMessage like:

button1.onclick = () => win1.postMessage("msg", {activate: "payment"});

And then child frame will be able to consume user activation only for Payment Request API.

  1. Permissions Policy is used to delegate the permission, but it doesn't delegate the user activation. The user would still have to click in the frame if the API required user activation.

Permission Policy is not used to delegate permissions. Permission Policy allows a site to declare which permissions are allowed to be requested/used. Permission Delegation is a browser implementation and it's not a Web Standard.

annevk commented 2 years ago

The status of the delegated permission can be "prompt", in which case the user would indeed be asked first. Or it might be granted automatically, as is the case with fullscreen. It depends.

atanassov commented 2 years ago

@cynthia and I reviewed the proposal one more time during our Madripoor vf2f. @mustaqahmed, thank you for acknowledging my feedback about specifying an allow list of standard features, instead of the current normative spec text which implies all standard features.

With these proposed spec changes we are happy to close the review. Thank you for working with us and being receptive to our feedback. We look forward to see more progress done with the WHATWG. Good luck.