Remove clipboard-write permission

[saschanaz]

Closes #163

For normative changes, the following tasks have been completed:

• Modified Web platform tests (link to pull request) (Already marked as tentative, no need to change)

Implementation commitment:

• WebKit Clipboard permissions permissions#175 (comment)
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko Remove clipboard-write permissions#246 (comment)

---

Preview | Diff

[marcoscaceres]

Just a couple of nits. Otherwise looks good to me.

[snianu]

Curious, why are we removing the clipboard permissions from the spec? Chromium browsers support this and we have no plans on removing it. In fact we will be extending this to pickling APIs so I don't see why this should be removed from the spec? There are concepts in the spec that is only applicable to Apple platforms (presentation style, multiple clipboard items etc) and we have no plans on supporting those in the future, and yet we still added to the spec so I don't see any rationale as to why we are removing something that is currently supported by two browsers (Edge and Chrome). Consider this a formal objection from Microsoft. @BoCupp-Microsoft FYI. @mkruisselbrink @a-sully to chime in from Google.

[annevk]

It's being removed because it was removed from the Permissions specification, per a previous discussion: w3c/permissions#175.

Also, Chrome and Edge do not count as two implementers per any usual definition of that word. That seems rather disingenuous.

As for Apple platform specific features, are those not different in that multiple browsers could support them, but they would only have an effect on Apple platforms? If there's no support from multiple implementers though perhaps those features need to be reconsidered indeed. Best discussed in its own issue.

[snianu]

Also, Chrome and Edge do not count as two implementers per any usual definition of that word

I'm not sure where you pulled that definition from, but we have complete control over what gets shipped in Edge regardless of the Blink API shipping process. As an example, we have shipped Pickling API in Edge and we are still waiting on the approval from the Blink API owners to ship in Chromium (which may or may not be approved), but considering that there is a strong developer support from Office products, Adobe, Figma, Google products etc, I'm hoping that it will get approved.

Removing this from the spec makes us non-compliant, and considering the fact that we are the ones maintaining this spec(#158), I don't think we would be in favor of this change. If this is the direction Mozilla and Apple want to take, then you are right when you said that "It's a failure of the standards committee".

[annevk]

What typically counts as an implementation for the purposes of standards is a fully independent implementation. A single implementation that two products ship parts of with different shipping priorities is just not it, I'm sorry.

Also, it's already been removed from the specification (Permissions). It's just that the dangling reference to it hasn't been removed yet.

[snianu]

What typically counts as an implementation for the purposes of standards is a fully independent implementation

Can you please be a little more specific? What exactly is the formal definition of a "fully independent implementation"? Blink is a fork from Webkit so it's not exactly independent(according to what you trying to imply in your arguments).

[annevk]

Right and for parts where they would use the same code to implement something that would not count.

[snianu]

well, I'm not gonna get into the philosophical arguments about what "same code" even means, but I'm adding the agenda label to this PR so we can discuss with the Editing WG before making any changes to the spec that is in the Editing WG charter.

[marcoscaceres]

As a neutral observer here, a different way of framing this is that two implementers are objecting to its inclusion. For that reason this probably should not have landed in the original spec. It may be worth investigating how this landed in the spec in the first place, and wether sufficient review/feedback was gathered in that original pull request (in alignment with the W3C Process, and with respect to consensus building).

[css-meeting-bot]

The Web Editing Working Group just discussed Checking on the blocked clipboard-write permission?.

The full IRC log of that discussion

<Travis> Topic: Checking on the blocked clipboard-write permission?
<Travis> github: https://github.com//pull/164
<Travis> BoCupp: I think the interested party is not here though...
<Travis> .. should probabaly ping Mozilla.
<Travis> .. Problem: we use clipboard read/write permission so that they can be granted to iframes.
<Travis> .. iframe's can't even do it without delegated authority.
<Travis> .. Office programs are hosted in different hosts and run in iframes. So we wanted to remove this.
<Travis> .. the objection was that firefox/safari were aligned on not wanting that.
<Travis> .. Seems like Apple has a trusted UI context menu. A second click is needed.
<Travis> .. Firefox has not shipped the API yet... I was wondering what Firefox' model is/will be. How would they solve the delegated authority issue?
<Travis> .. Will the adopt the Apple approach? Will the not have a permission? Have they even faced the issue yet?
<Travis> .. want to leave the issue as-is in hope of getting alignment on the current behavior? That's why we've left it blocked.
<Travis> johanneswilm: Remind us why you need an iframe?
<Travis> BoCupp: Yes, Microsoft Sharepoint is a shell that allows browsing of documents... when a doc is opened, Sharepoint loads a cross-origin iframe with the "word" logic to display it.
<Travis> .. Office app architecture is designed to be hosted in cross-origin iframes.
<Travis> .. Also, navigator.clipboard.read does not need to happen in context of a paste event. It may require a user gesture.
<Travis> .. We don't want the user to get prompted from some random iframe unless that authority has been delegated.
<Travis> Travis: user only sees the address bar url.. iframe prompt would look like it came from that url. Confusing to the user.
<Travis> BoCupp: I don't think there's an action to take today other than a followup later.

[css-meeting-bot]

The Web Editing Working Group just discussed Remove clipboard write permission?.

The full IRC log of that discussion

<Travis> Topic: Remove clipboard write permission?
<Travis> github: https://github.com//pull/164
<Travis> Anupam: I think we need Bo for this.
<Travis> Annevk: +1

[css-meeting-bot]

The Web Editing Working Group just discussed Remove cliboard-write permission.

The full IRC log of that discussion

<Travis> topic: Remove cliboard-write permission
<Travis> github: https://github.com//pull/164
<Travis> johanneswilm: this is blocked...
<Travis> .. action last time--BoCup will communicate...
<Travis> BoCupp: Hmm, haven't reached out to them yet.
<Travis> .. (it's coming back to me now)

[artem1982]

It was marked as Pri1 bug on chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=1334203

[garykac]

FWIW, the current spec fails to build because bikeshed can no longer find a definition for 'permission task source'.

We need to either:
(a) Keep the permission steps in the algorithm, but update it to remove the reference to this term
(b) Remove all the permission steps
(c) <something else>?

Doing (a) seems problematic since it wouldn't really be a complete algorithmic description.

My preference would be for the spec to be updated to allow, but not require, an implementation to gate access to this feature based on a permission or user gesture or whatever.

Is that an acceptable middle ground?

[marcoscaceres]

this is related to w3c/permissions#407 ... I think there is some guidance there.