Inspired by the recent talk about user interaction, I feel like there is
one thing I want to understand.
So with a Promise you move the execution to a later time. Is it possible
here for a malicious page to delay an action to much, much later and
then do that clipboard operation on data that was not available at the
time of the clipboard operation the user initiated?
If so, could that have security implications?
Could there even be more than one ongoing clipboard operation at a time?
/Daniel
On 2021-10-21 17:20, Domenic Denicola wrote:
On Thu, Oct 21, 2021 at 5:21 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
LGTM1 to ship conditional that y'all continue to work on PR #158
<https://github.com/w3c/clipboard-apis/pull/158> specifically, and
clarifying the spec's processing model in general.
On Thursday, October 21, 2021 at 2:04:53 AM UTC+2 snianu wrote:
Gentle ping as the branch cutoff date for 97 is pretty close.
While I agree that the issues related to clipboard API spec
need to be addressed, I don’t think this feature needs to be
blocked on that. It’s not a breaking change i.e. sites can
continue to use Blobs if they want to(although I don’t think
any developer would want to have different codepaths for Apple
and Chromium browsers)
FWIW, I got curious RE why that *should* work, and did some digging.
It seems like the bindings methods that accept a `Promise<T>`
input value call `NativeValueTraits<IDLPromise>
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/native_value_traits_impl.h;l=775?q=ArgumentValue&ss=chromium%2Fchromium%2Fsrc>`
on that value, which casts
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/script_promise.cc;drc=ac35167cc1cf9c40778c1e1d8855fd90a90f0fbf;l=291>
the value foo into a `Promise.resolve(foo)`, if it wasn't a
Promise already.
The same seems to work in WebKit as well. Do you know if this
bindings behavior is specified?
It is: https://webidl.spec.whatwg.org/#es-promise
Also, can you add tests for both input cases as part of your CLs
for this?
, and Apple has already shipped this feature. Please let me
know in case of any concerns.
-Anupam
*From:* Anupam Snigdha
*Sent:* Thursday, October 7, 2021 9:53 AM
*To:* 'Yoav Weiss' <yoavwe...@chromium.org>
*Cc:* ann...@annevk.nl; blink-dev@chromium.org;
m...@chromium.org; Bo Cupp <pc...@microsoft.com>
*Subject:* RE: [EXTERNAL] Re: [blink-dev] Intent to Implement
and Ship: Add support for Promise to Blobs in clipboard item
Yep, I’ll address the feedback from Anne and mbrodesser (from
Mozilla).
Thanks for all your help Anne and Yoav!
*From:* Yoav Weiss <yoavwe...@chromium.org>
*Sent:* Thursday, October 7, 2021 12:03 AM
*To:* Anupam Snigdha <sni...@microsoft.com>
*Cc:* ann...@annevk.nl; blink-dev@chromium.org;
m...@chromium.org; Bo Cupp <pc...@microsoft.com>
*Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Implement
and Ship: Add support for Promise to Blobs in clipboard item
On Tue, Oct 5, 2021 at 4:02 AM Anupam Snigdha
<sni...@microsoft.com> wrote:
Here is a WIP PR to address the spec issue:
https://github.com/w3c/clipboard-apis/pull/158
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fpull%2F158&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187674892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I%2Byq6TluT%2FvAEsIdktzvyZdjjPo7TpER2cKREBGWXIU%3D&reserved=0>.
Can you address feedback from Anne on the PR?
*From:* Anupam Snigdha
*Sent:* Monday, October 4, 2021 10:45 AM
*To:* 'Yoav Weiss' <yoavwe...@chromium.org>; Anne van
Kesteren <ann...@annevk.nl>
*Cc:* blink-dev <blink-dev@chromium.org>; Marijn
Kruisselbrink <m...@chromium.org>; Bo Cupp
<pc...@microsoft.com>
*Subject:* RE: [EXTERNAL] Re: [blink-dev] Intent to
Implement and Ship: Add support for Promise to Blobs in
clipboard item
For #1: I don’t think we would want to diverge from the
spec. There is a reason why we have promises to Blobs and
not just Blobs in the ClipboardItem because, well, not
having promises defeats the purpose of having an async
API. Also waiting for the Blob data synchronously without
triggering the clipboard write operation leads to problems
like this
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1014310%23c15&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187684884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iddzqlsIiKiAtqUdEVzIjBylct%2B%2FpJvj%2BMzNxpFUCOM%3D&reserved=0>
and performance issues in sites like Excel Online where
the copy payload is in MBs.
That makes sense.
For #2: This might sound more of a rant so apologies in
advance.
I agree with Anne that the spec is not really clear at all
on the specifics of the async clipboard API and some of
the terminologies used in the algorithms.
However, making changes to the spec or even clarifying the
language after an API has been shipped, is really hard, as
we need to get consensus from all browser vendors.
I tried to clarify what “sanitization” means just for the
HTML format
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fissues%2F150%23issuecomment-909405090&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187684884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=afRGpVd6zwD8RiSoxTnjy6mNgbGIk8iA%2F%2B6AMiCO%2BI8%3D&reserved=0>
and Apple opposed to this change
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fissues%2F150%23issuecomment-922211803&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187694894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NfBuFjZ5mKP84MIG2AxKo8P6EmeKC5cQE6Lm%2B4cWdN0%3D&reserved=0>.
That's unfortunate :/
Perhaps I can add a non-normative note which would at
least give some clarity on the sanitization process, but
that would probably require UA specific non normative
notes which defeats the purpose of standardization.
I also tried to make changes to address Mozilla’s concern
about mandatory data types supported by async clipboard
APIs: https://github.com/w3c/clipboard-apis/pull/155
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fpull%2F155&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187694894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mrNE%2BCIsRJWBmnbUjpeQqhZ5SJeFYI9bhskywXzCuEQ%3D&reserved=0>,
but this PR has been sitting for almost a month now and
I’m not able to make any progress.
FWIW, it seemed to have made some progress initially and then
stalled. Pinging it may make sense.
In order to make progress on spec changes, we decided to
have a discussion with the Editing WG members and submit
changes to the spec if no one objects to it. Currently the
Editing WG has representatives from Apple and MS who
regularly attend the monthly status meetings. So my
question is, if we get an approval from the WG, then does
that meet the minimum bar to make spec changes?
That's for the Editing WG to decide. Looking at its charter
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2021%2F06%2Fweb-editing-wg-charter.html&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187704873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RmxqkOrUDQgu8CirPmk7wDKXAswir75DWOC7fEpX%2F98%3D&reserved=0>,
it seems the chairs may be able to help move things along
(e.g. by bringing decisions to a vote, if no consensus is
reached).
Anyways, I’m working on updating the spec to at least
define the Clipboard interface IDL, but since Apple and
Chromium browsers have already shipped this API, I don’t
think it’s possible to make any significant changes to
the APIs without breaking at least one of the browsers.
This change addresses the discrepancy between the
ClipboardItem IDL as defined in the spec(also implemented
by Apple) and what is implemented in Chromium. This is not
a breaking change so I think the risk is minimal here.
*From:* Yoav Weiss <yoavwe...@chromium.org>
*Sent:* Friday, October 1, 2021 4:15 AM
*To:* Anne van Kesteren <ann...@annevk.nl>
*Cc:* Anupam Snigdha <sni...@microsoft.com>; blink-dev
<blink-dev@chromium.org>; Marijn Kruisselbrink
<m...@chromium.org>; Bo Cupp <pc...@microsoft.com>
*Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to
Implement and Ship: Add support for Promise to Blobs in
clipboard item
On Fri, Oct 1, 2021 at 12:46 PM Anne van Kesteren
<ann...@annevk.nl> wrote:
On Fri, Oct 1, 2021 at 12:35 PM Yoav Weiss
<yoavwe...@chromium.org> wrote:
> Thanks Anne and Thomas for the cross-browser context.
>
> Anupam - looking at the issue Anne posted, it seems
Firefox explicitly did not implement this.
> I think it'd be interesting to get their opinions as
to why, and whether we should align with the current
WebKit behavior or the current Chromium one.
>
> Anne - do y'all want to chime in here, or would a
standards position issue be the best venue?
There is an existing issue:
https://github.com/mozilla/standards-positions/issues/89
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F89&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187704873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JHn9GNzlxbveQ94XVyAstVhxM2AGn5CvNTgT7Wg0Eyw%3D&reserved=0>.
The problem
we are having in evaluating all this is that there
isn't really any
specification to speak of, as I tried to point out.
One can take
guesses as to what the expected behavior is likely to
be, but that is
very far from ideal and normally not even close to
acceptable, right?
That's fair.
From my perspective, the ideal outcome here would be:
1) Getting agreement on this specific issue that's
currently causing developer pain, and moving forward in
that direction.
2) Properly specifying the correct behavior for the rest
of the broader API, in ways that would enable
interoperable implementations (and reduce developer pain
in the future).
It seems like (2) requires Someone™ to take on the work of
gathering the different unspecified behaviors, opening an
issue to discuss each one, reaching agreement on them and
pushing to align existing implementations.
Maybe we can decouple (1) and (2), but I'd like to see we
have a concrete plan for (2) before we do that.
Anupam - who would be best positioned to take on that work?
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7a237c30-9d53-4181-9c5d-1954d2bf6a0cn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7a237c30-9d53-4181-9c5d-1954d2bf6a0cn%40chromium.org?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-e-Y3%3DSn_LQ7qCLKahrg8WaOfoi4LR1TGMN4%3D5-Dn7kQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-e-Y3%3DSn_LQ7qCLKahrg8WaOfoi4LR1TGMN4%3D5-Dn7kQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4c7d0610-b7de-b0d0-91d1-4943f1e4a6c2%40gmail.com.
