Open Bug 1777448 Opened 2 years ago Updated 1 years ago

Avoid showing the "Paste" button for `navigator.clipboard.read*()` when the user's privacy isn't affected

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, enhancement)

enhancement

Tracking

()

People

(Reporter: mbrodesser-Igalia, Assigned: edgar)

References

(Blocks 3 open bugs)

Details

Includes not showing the "Paste" button when copy-pasting within the same document/origin; see the "Security and Privacy" section of https://webkit.org/blog/10855/.

Depends on: 1773707
Blocks: 1770358
No longer depends on: 1770358

Currently, we show the paste contextmenu to grand user permission every time when the page tries to read clipboard data programmatically via async clipboard API, but sometimes it might be annoyed if the user only copy/paste data within the same origin, for example editing a Google Doc. Webkit has implemented two mechanisms to improve the user experience.

  • If the user is explicitly triggering a paste during the gesture (for instance, using a keyboard shortcut on macOS such as ⌘V or pasting using the “Paste” action on the callout bar on iOS), WebKit will allow the page to programmatically read the contents of the clipboard.
  • Programmatic clipboard access is also automatically granted in the case where the contents of the system clipboard were written by a page with the same security origin.

We would like to implement the similar behavior, too. i.e.

  • Allow the page to programmatically read clipboard in paste event handler.
  • Allow the page to programmatically read clipboard if the clipboard data is from the same origin. (data from external application will be treated as from different origin)

And here are some rough plan to implement the same-origin checks,

  • In Cocoa widget, there is a clipboard cache mechanism, we cache the nsITransferable that is written to system clipboard by gecko. And if the system clipboard isn't changed by other application, we return the data stored in cached nsITransferable for the subsequent clipboard access from gecko. I plan to build the same-origin checks on the top of it.
  • Apply other platforms to same clipboard cache mechanism which requires a refactoring on nsBaseClipboard (bug 1773707).
  • Storing the principle that trigger the system clipboard writing in nsITransferable::requestingOrigin,
  • When reading clipboard data programmatically,
    1. If there is no valid data in clipboard cache, show the paste contextmenu to grand user permission.
    2. Otherwise, check the principle stored in the cache with the requesting principle.
      2.1. if they are different origin, show the paste contextmenu to grand user permission.
      2.2. Otherwise, automatically grant the permission.
Blocks: 1809106
Assignee: nobody → echen
You need to log in before you can comment on or make changes to this bug.