Bug 103807 - Can drag/remove object, can copy text on Secured PDF
Summary: Can drag/remove object, can copy text on Secured PDF
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf
: 114497 (view as bug list)
Depends on:
Blocks: PDF-Import-Draw
  Show dependency treegraph
 
Reported: 2016-11-09 11:23 UTC by baffclan
Modified: 2017-12-27 21:22 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample PDF (15.97 KB, application/pdf)
2016-11-09 11:23 UTC, baffclan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description baffclan 2016-11-09 11:23:37 UTC
Created attachment 128614 [details]
Sample PDF

Can drag/remove object, can copy text on Secured PDF

Steps to Reproduce:
1. Open a attachment(PDF file) as Draw


Actual Results:
2. Can drag/remove object, can copy text

Expected Results:
2. Cannot drag/remove object, cannot copy/edit text


In PDF-Viewer and PDF-XChange Editor, you will not be able to copy or edit.
In Acrobat Reader DC, you will not be able to copy.

LibreOffice should be based on specifications of the PDF.


---
Reproduce with 5.2.3.3, 5.3.0.0.alpha1+.
OS: Windows 7 Pro x64

Version: 5.2.3.3 (x64)
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
Locale: ja-JP (ja_JP); Calc: group

Version: 5.3.0.0.alpha1+ (x64)
Build ID: 055be3f4be764e445064effabf06de9d1ed819f7
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-11-07_13:03:37
Locale: ja-JP (ja_JP); Calc: group
Comment 1 Cor Nouws 2016-11-13 07:40:28 UTC
Hi baffclan,

PDF import in Draw does not open protected.
From what I understood, a 'protected' PDF file can't be edited in one product, but can in another. So maybe it's rather bind to the product then to the file format?

Ciao - Cor
Comment 2 baffclan 2016-11-13 11:52:46 UTC
Cor Nouws,
Thank you for your reply.

The author cannot distribute it with confidence when I can edit a protected PDF in Draw.
Many people will not be able to use Secured PDF.
Comment 3 Buovjaga 2016-11-17 21:34:38 UTC
(In reply to baffclan from comment #2)
> Cor Nouws,
> Thank you for your reply.
> 
> The author cannot distribute it with confidence when I can edit a protected
> PDF in Draw.
> Many people will not be able to use Secured PDF.

They can be unlocked with PDFUnlock online anyways.
Comment 4 V Stuart Foote 2016-11-18 00:06:12 UTC
"LibreOffice should be based on specifications of the PDF."

Do not see that as a valid concern, and it is not clear it is our ethical responsibility to implement as our handling of PDF import is via poppler/cairo.

We do not open a PDF for editing--we filter parse its contents via poppler for use in our standard object formats. Little removed from scanning and OCR of the PDF.

Imported via filter I do not believe we are under any obligation to retain the limitations of the original PDF--as we are not editing it!

When we export back to a new PDF, we may then impose security (via signature), but the original PDF remains unchanged.

LibreOffice is _not_ a PDF editor
Comment 5 baffclan 2016-12-01 10:22:11 UTC
I doubt this INVALID.

Mozilla has similar problem.
They recognized a bug, and are trying to fix.

See https://bugzilla.mozilla.org/show_bug.cgi?id=792816
Comment 6 V Stuart Foote 2016-12-01 16:09:37 UTC
Miklos, David, Michael(s) -- before I reject this "enhancement" out of hand, any perspective from the development side. 

Beyond requiring a PDF password if set, with our new insert PDF as svm image or the "legacy" open PDF filter do we have any obligation to honor the encryption dictionary settings and Adobe security handler for any /P values if set?

Once we have filter imported a PDF for use (as Image or as Draw objects) seems counter productive to then try to limit what we do with the the result internally.

I'm sure it could be done but personally I don't see this as necessary or desirable. But is it something we are obliged to do? Again, I don't think so.
Comment 7 Heiko Tietze 2016-12-18 10:07:05 UTC
(In reply to V Stuart Foote from comment #6)
> Miklos, David, Michael(s) -- before I reject this "enhancement" out of hand,
> any perspective from the development side. 

Apparently not. Closing now.
Comment 8 V Stuart Foote 2017-12-16 16:09:18 UTC
*** Bug 114497 has been marked as a duplicate of this bug. ***
Comment 9 Telesto 2017-12-16 22:55:58 UTC
The decision is made a long time ago, and i'm not having any preference. However I want to point out the inconsistency that Libreoffice supports setting permissions for PDF's.
Why support something you don't honour yourself?
Comment 10 Cor Nouws 2017-12-27 21:22:49 UTC
(In reply to Telesto from comment #9)
> The decision is made a long time ago, and i'm not having any preference.
> However I want to point out the inconsistency that Libreoffice supports
> setting permissions for PDF's.
> Why support something you don't honour yourself?

something as 'protect' between quotes, and explanation in the Help, as is done with 'protection' of cells/sheets in a spreadsheet?