1918027 - While inside Google Docs copying another text while a scan is ongoing will scan that text as well

Status: REOPENED

(Firefox :: Data Loss Prevention, defect)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: dlp_copy_0.gif

Found in

• 131.0b4

Affected versions

• 132.0a1 (2024-09-10)
• 131.0b4

Tested platforms

• Affected platforms: Windows 11, Windows 10
• Unaffected platforms:macOS 12, Ubuntu 22

Preconditoins

• Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
• Create a distribution folder inside the Firefox folder and paste the policies-1.json to it and then rename it to policies.json
• Run the DLP agent in CMD using: .\content_analysis_sdk_agent.exe --user --toblock=.\d{3}-?\d{2}-?\d{4}. --towarn=.warn. --delays=10

Steps to reproduce

1. Open Google Docs.
2. Copy a random text from another application and paste it inside Google Docs.
3. While the scan is ongoing copy another text inside the clipboard (e.g 123456789)

Expected result

• Only the first text is scanned.

Actual result

• The text from step 3 is scanned as well.

Regression range

• Reproducible with Firefox 131.0b4. We will see if there is a regression.

Additional notes

• Attached a screen recording.

Comment 1

[Greg Stoll :gstoll]

This is an unfortunate consequence of bug 1915351. Google Docs reads from the clipboard twice, and so if the clipboard contents change during the first scan it will scan the second contents. (most of the time we can skip the second DLP scan since the content is the same; the DLP result gets cached in the cache we added in bug 1912384)

Comment 2

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: 1918027.gif

Hello Greg! It seems that this issue now reproduces on Wikipedia and Gdocs after bug 1915351. With Firefox 132.0 I cannot reproduce the issue on the Wikipedia page, only on Gdocs.

Should we reopen this issue or file another one? Attached a screen recording (Note that I used Ctrl + C / Ctrl + V keyboard shortcut in the recording). Thank you!

Comment 3

[Greg Stoll :gstoll]

Hi - since this bug was just covering this issue I'll just go ahead and reopen it. Thanks!

Comment 4

[Greg Stoll :gstoll]

Very rough plan: keep track of the "paste number" for a given paste operation and use the same DataTransfer object for all Content Analysis-related operations in that paste.

Comment 5

[Greg Stoll :gstoll]

Note that this is tricky because JS code inside a paste event is allowed to change the clipboard contents, and after that the new contents should be pasted into the element. Sigh.

Comment 6

[Greg Stoll :gstoll]

Attachment: Bug 1918027 part 1 - expose GetNativeSequenceNumber from nsIClipboard r=edgar

Comment 7

[Greg Stoll :gstoll]

Attachment: Bug 1918027 part 2 - expose ClipboardGetNativeSequenceNumber from PContent r=edgar

Comment 8

[Greg Stoll :gstoll]

Attachment: Bug 1918027 part 2 - add ability for DataTransfer to bypass content analysis r=edgar,#dlp-reviewers!

Also fixes a problem with DataTransfer::Clone() where it wasn't propagating
the mClipboardDataSnapshot.

Comment 9

[Greg Stoll :gstoll]

Attachment: Bug 1918027 part 3 - share DataTransfer between clipboard event and calls to HandlePaste() r=edgar,#dlp-reviewers

This handles a race condition so if the user copies new data to the clipboard
while Content Analysis is ongoing, the original data will be used in the
paste action.

Comment 10

[Greg Stoll :gstoll]

Attachment: Bug 1918027 part 4 - add tests r=edgar,#dlp-reviewers

Comment 11

[Greg Stoll :gstoll]

Attachment: Bug 1918027 part 5 - fix assert in unrelated test r=edgar

text/x-moz-url data is supposed to have a newline and a description

• see this assertion on Windows: https://searchfox.org/mozilla-central/rev/f2df1ff64cb876e10c72ce7eed1fc9eac3f877bb/widget/windows/nsDataObj.cpp#1891-1893

This causes asserts in the test when run on Windows but it still passes,
which made me waste a bit of time investigating.