Intent to Prototype and Ship: Feature Policy integration for Clipboard API
Darwin Huang
Contact emails
Summary
Implement feature policy (aka permission policy) flags for the Clipboard API. The flag names will be ‘clipboard-read’ and ‘clipboard-write’, to be consistent with the Clipboard API permissions, as feature policy is now merged with permissions and renamed to permissions policy.
This addresses an oversight in the existing implementation that makes the new Clipboard API inaccessible from within iframe contexts, complicating a long-term plan to migrate from (un-gated) `document.execCommand("copy")` to the more explicit and safe Clipboard API. This also improves security for the Clipboard API, by allowing sites to delegate use of this API in iframes.
Explainer
Spec
https://www.w3.org/TR/clipboard-apis/#clipboard-permissions and https://github.com/w3c/clipboard-apis/pull/120. As Feature Policy is renamed/merged to Permissions Policy, the existing permissions “clipboard-read” and “clipboard-write” should also be implemented in Feature Policy / Permissions Policy. This is covered more in the explainer spec history section.
TAG review process skipped as this was a fairly minor change.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://smart-flicker-baroness.glitch.me/
Risks
Interoperability and Compatibility
Interoperability risk: Other browsers are less interested in the feature policy name, as derived from the permission name (context in explainer), so it’s possible that they may not implement this same feature policy integration soon.
Compatibility risk: Sites that don’t enable feature policy would be broken. They’re already broken now, as mentioned in the explainer, so this intent allows them to migrate to our preferred API for copy/paste operations. This API is used by at least 3553 (in Feb 2020) sites. Read is used on .0002% of page loads, and Write is used on .0001% of page loads.
Signals from other implementations (Gecko, WebKit):
Gecko: Defer, as Firefox would prefer to use one unified permission.
Webkit: Negative, as blocked on disagreements with the matching permission name.
Web Developers: Strongly positive, as they’d like to be able to use this feature. Publicly interested parties include bwater.com, hearthsim, and code-server, though there are other interested parties who have privately notified us about this issue.
Ergonomics
This feature is an extension of and restriction for the Clipboard API. There are no anticipated ergonomics concerns, as no other web platform features should closely rely on this.
Activation
It should be fairly easy for developers to use this feature, by adding a allow="clipboard-read" or allow="clipboard-write" onto <iframe>s they’d like to provide clipboard access to.
Security
Feature policy is important in order to secure the clipboard, and avoid unexpected use on unapproved iframes. Therefore, implementing this is important to protect the security of the user.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes. Tests are included in https://crrev.com/c/2164248, under //third_party/blink/web_tests/external/wpt.
Entry on the feature dashboard
https://www.chromestatus.com/feature/5767075295395840
Yoav Weiss
Contact emails
Summary
Implement feature policy (aka permission policy) flags for the Clipboard API. The flag names will be ‘clipboard-read’ and ‘clipboard-write’, to be consistent with the Clipboard API permissions, as feature policy is now merged with permissions and renamed to permissions policy.
This addresses an oversight in the existing implementation that makes the new Clipboard API inaccessible from within iframe contexts, complicating a long-term plan to migrate from (un-gated) `document.execCommand("copy")` to the more explicit and safe Clipboard API. This also improves security for the Clipboard API, by allowing sites to delegate use of this API in iframes.
Explainer
Spec
https://www.w3.org/TR/clipboard-apis/#clipboard-permissions and https://github.com/w3c/clipboard-apis/pull/120. As Feature Policy is renamed/merged to Permissions Policy, the existing permissions “clipboard-read” and “clipboard-write” should also be implemented in Feature Policy / Permissions Policy. This is covered more in the explainer spec history section.
TAG review process skipped as this was a fairly minor change.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://smart-flicker-baroness.glitch.me/
Risks
Interoperability and Compatibility
Interoperability risk: Other browsers are less interested in the feature policy name, as derived from the permission name (context in explainer), so it’s possible that they may not implement this same feature policy integration soon.
Compatibility risk: Sites that don’t enable feature policy would be broken. They’re already broken now, as mentioned in the explainer, so this intent allows them to migrate to our preferred API for copy/paste operations.
Web Developers: Strongly positive, as they’d like to be able to use this feature. Publicly interested parties include bwater.com, hearthsim, and code-server, though there are other interested parties who have privately notified us about this issue.
Ergonomics
This feature is an extension of and restriction for the Clipboard API. There are no anticipated ergonomics concerns, as no other web platform features should closely rely on this.
Activation
It should be fairly easy for developers to use this feature, by adding a allow="clipboard-read" or allow="clipboard-write" onto <iframe>s they’d like to provide clipboard access to.
Security
Feature policy is important in order to secure the clipboard, and avoid unexpected use on unapproved iframes. Therefore, implementing this is important to protect the security of the user.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes. Tests are included in https://crrev.com/c/2164248, under //third_party/blink/web_tests/external/wpt.
Entry on the feature dashboard
https://www.chromestatus.com/feature/5767075295395840
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37257cdb-3afb-419d-82b8-8b52b3c68072o%40chromium.org.
Darwin Huang
Will the API be supported under both the Feature-Policy and Permission-Policy headers?
How far out is support for Permission-Policy?
--
Web Developers: Strongly positive, as they’d like to be able to use this feature. Publicly interested parties include bwater.com, hearthsim, and code-server, though there are other interested parties who have privately notified us about this issue.
Ergonomics
This feature is an extension of and restriction for the Clipboard API. There are no anticipated ergonomics concerns, as no other web platform features should closely rely on this.
Activation
It should be fairly easy for developers to use this feature, by adding a allow="clipboard-read" or allow="clipboard-write" onto <iframe>s they’d like to provide clipboard access to.
Security
Feature policy is important in order to secure the clipboard, and avoid unexpected use on unapproved iframes. Therefore, implementing this is important to protect the security of the user.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes. Tests are included in https://crrev.com/c/2164248, under //third_party/blink/web_tests/external/wpt.
Entry on the feature dashboard
https://www.chromestatus.com/feature/5767075295395840
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37257cdb-3afb-419d-82b8-8b52b3c68072o%40chromium.org.
Yoav Weiss
Daniel Bratell
LGTM2
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEj-rQiicFZCBc_kTXJ__dRVC50%3Djx786QcFcg7ej26LbQ%40mail.gmail.com.
