Bug 141237 - Documentation -- effectiveness of security restrictions on export to PDF document
Summary: Documentation -- effectiveness of security restrictions on export to PDF docu...
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Documentation (show other bugs)
Version:
(earliest affected)
7.1.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Olivier Hallot
URL:
Whiteboard: target:7.2.0
Keywords:
Depends on:
Blocks: HelpGaps-NewFeatures PDF-Export
  Show dependency treegraph
 
Reported: 2021-03-24 17:10 UTC by ricky.tigg
Modified: 2021-04-27 17:36 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Security options set (52.82 KB, image/png)
2021-03-24 17:11 UTC, ricky.tigg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ricky.tigg 2021-03-24 17:10:29 UTC
Description:
Security restrictions not applied while exporting to PDF document.

Steps to Reproduce:
Select Export as | Export as PDF; at Security tab.
Password applied to Permission: set; Printing and Changes: Not permitted; Copying of content: Not enabled.

Actual Results:
I am able to print the document and copy content and paste it into other document – even with a watermark applied.

Expected Results:
Restrictions to be applied while exporting to PDF document.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.1.1.2; Build ID: 10(Build:2); CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI: en-US: Calc: threaded
Comment 1 ricky.tigg 2021-03-24 17:11:57 UTC
Created attachment 170718 [details]
Security options set
Comment 2 Jean-Baptiste Faure 2021-04-14 21:53:54 UTC
Which PDF reader are you using ?

Perhaps your PDF reader is configured to not obey this kind of restriction. For example Okular, when configured to obey to DRM restrictions, does not allow to copy selected text if that is not permitted by the PDF.
So, for me, restrictions are set, but the PDF reader can do what it want.

Status set to NEEDINFO, please set it back to UNCONFIRMED once requested
information is provided.

Best regards. JBF
Comment 3 ricky.tigg 2021-04-15 06:02:36 UTC
Omitted to mention in the report indeed; environment: Gnome 40.0; PDF-reader: evince-40.1-1.fc34.x86_64. No particular setting allowing bypass of those restrictions in dconf-editor (/org/gnome/evince/).
Comment 4 Jean-Baptiste Faure 2021-04-15 07:47:10 UTC
(In reply to ricky.tigg from comment #3)
> Omitted to mention in the report indeed; environment: Gnome 40.0;
> PDF-reader: evince-40.1-1.fc34.x86_64. No particular setting allowing bypass
> of those restrictions in dconf-editor (/org/gnome/evince/).

Thank you. I suggest you to try with Okular. You will see that the "problem" is on the PDF reader side.

If my guess is correct, perhaps should we add a warning in the PDF export dialog about the effectiveness of these restrictions. So added needsUXEval keyword.

Best regards. JBF
Comment 5 Heiko Tietze 2021-04-15 11:25:54 UTC
(In reply to Jean-Baptiste Faure from comment #4)
> ... perhaps should we add a warning in the PDF export
> dialog about the effectiveness of these restrictions.

Would be good to mention in the help and perhaps in the tooltip but not the dialog itself. If your assumption is correct.
Comment 6 ricky.tigg 2021-04-15 14:55:10 UTC
On Fedora 34; Tested with: atril v.1.24.1, okular v.20.12.2 | Reproducible.

On Windows 10; Tested with: Adobe Reader DC 2019.008.20071; Source: still PDF file created on Fedora | Not reproducible; as expected 'Copy' and 'Print' options cannot be selected.
Comment 7 Jean-Baptiste Faure 2021-04-15 16:29:57 UTC
(In reply to ricky.tigg from comment #6)
> On Fedora 34; Tested with: atril v.1.24.1, okular v.20.12.2 | Reproducible.

Did you configure Okular to obey to DRM restrictions ?

Best regards. JBF
Comment 8 ricky.tigg 2021-04-16 07:42:56 UTC
Each PDF reader's settings are all as defaults. Then Okular's option 'Obey DRM limitations' is enabled. Let's keep it accurate; there are "restrictions" not "limitations". Here is the Okular starting:

$ okular <...>.pdf 
QSocketNotifier: Can only be used with threads started with QThread

Nevertheless that property should not be a relevant criteria regards to the present issue since the presence of Writer's option 'Set passwords...' | 'Set permission password', to be kept relevant, has to lock the PDF document's settings in order to enforce their appliance when submitted to PDF readers.
Comment 9 Jean-Baptiste Faure 2021-04-16 20:39:32 UTC
(In reply to ricky.tigg from comment #8)
> Each PDF reader's settings are all as defaults. Then Okular's option 'Obey
> DRM limitations' is enabled. Let's keep it accurate; there are
> "restrictions" not "limitations". Here is the Okular starting:
> 
> $ okular <...>.pdf 
> QSocketNotifier: Can only be used with threads started with QThread
> 
> Nevertheless that property should not be a relevant criteria regards to the
> present issue since the presence of Writer's option 'Set passwords...' |
> 'Set permission password', to be kept relevant, has to lock the PDF
> document's settings in order to enforce their appliance when submitted to
> PDF readers.

I disagree. My understanding of the PDF format is that there no mean to enforce a PDF reader to obey these restrictions.
From https://en.wikipedia.org/wiki/PDF#Encryption_and_signatures :
> PDF files may also contain embedded DRM restrictions that provide further 
> controls that limit copying, editing or printing. These restrictions depend on 
> the reader software to obey them, so the security they provide is limited.

So for me there is no bug on LibreOffice side as it sets these DRM restrictions. It s up to the PDF reader to obey them. Or not.

Best regards. JBF
Comment 10 Heiko Tietze 2021-04-20 14:47:00 UTC
NAB but documentation issue. Forwarding...
Comment 11 Heiko Tietze 2021-04-26 08:03:33 UTC
*** Bug 141884 has been marked as a duplicate of this bug. ***
Comment 12 V Stuart Foote 2021-04-26 13:00:29 UTC
This is really a dupe of bug 95424 which was => WF, as is bug 141884

But remains open for documentation o LibreOffice's handling of PDF "privacy"
Comment 13 Commit Notification 2021-04-27 11:01:07 UTC
Olivier Hallot committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/7d55112c83309001d9f68f6f92959911312258dc

tdf#141237 Make clear that security depends or PDF reader
Comment 14 ricky.tigg 2021-04-27 12:53:49 UTC
Above commit | "You can enter an optional password that allows the person viewing the PDF to edit and/or print the document."

A Jean-Baptiste Faure; that was all what was needed. Are you looking now where your reaction leads to? One of yours ended up deliberately with a piece of counter truth which from a commit was even made despite it had been dully reporters to those very developers that no knowledge of that password or any other paswword was even needed by a person viewing the PDF document in order to allow editing the document, copying its content or printing the document.
Comment 15 V Stuart Foote 2021-04-27 14:01:20 UTC
(In reply to ricky.tigg from comment #14)

No that was the previous content. The addition just made to the documentation for this issue:

"The restrictions that limit copying, editing or printing depend on the reader software to obey them, so the security they provide is limited."

Which is valid. The Open password and the Permissions password both function in a fully PDF 1.5 compliant program--e.g. current Adobe Reader or Acrobat DC releases. Google Chrome's PDF parser also complies.
Comment 16 ricky.tigg 2021-04-27 15:22:11 UTC
Above commit | "The restrictions that limit copying, editing or printing depend on the reader software to obey them, so the security they provide is limited."

While the sentence it replaces was a plain countertruth, this one now excels as an example of waffle. 

Is it then so unusual nowadays to speak without hiding, trying to embellish or diminish the truth? Such an attitude sets the ground for more reports to come with regards to this topic.

Here is a text that would bring a full comprehension of the context and its immediate consequences. Do you perceive the difference between your text and mine?

"The requirements of passwords set for opening document and setting document permissions are only observed by a PDF reader fully 1.5 compliant program such as current Adobe Reader, Acrobat DC releases and Google Chrome's PDF parser. Then despite the use of passwords, in others PDF readers those restrictions may have no effect."
Comment 17 V Stuart Foote 2021-04-27 16:32:44 UTC
(In reply to ricky.tigg from comment #16)

> 
> "The requirements of passwords set for opening document and setting document
> permissions are only observed by a PDF reader fully 1.5 compliant program
> such as current Adobe Reader, Acrobat DC releases and Google Chrome's PDF
> parser. Then despite the use of passwords, in others PDF readers those
> restrictions may have no effect."

Sure, regards help for the PDF Options  "Set password..." dialog [1], something more descriptive like that might be helpful.

@Olivier?

Also, is the correct help link being picked up from the PDF options dialog? Seems to be misdirected.

=-ref-=
[1] https://help.libreoffice.org/7.2/en-US/text/shared/01/ref_pdf_export_security.html
Comment 18 Olivier Hallot 2021-04-27 17:36:30 UTC
Yes we can.

But I'll remove trademarked names. Suggestion:

"The requirements of passwords set for opening document and setting document permissions are only observed by a PDF reader version 1.5 compliant program. Then despite the use of passwords, in others PDF readers those restrictions may have no effect."