This is a locked PDF that forbids copying.
This is a standard feature of PDF honored by Chrome so the behavior is correct.
The only enhancement Chrome could provide is an indication of this protection being present.

Deleted: secure.png 24.5 KB

	secure.png 24.5 KB View Download

Interesting.  Preview (macos system viewer) reports that it is encrypted but different permissions.

Deleted: Screen Shot 2018-05-23 at 11.38.04 .png 204 KB

	Screen Shot 2018-05-23 at 11.38.04 .png 204 KB View Download

There is a 5 year old firefox bug for this (copying works fine in firefox's pdf viewer).
Apple Preview also allows copying text, couldn't find anything about whether apple considers this a bug.

Often my use-case is copying and pasting a paragraph of text from a PDF into google translate...or copying and pasting a URL that wasn't properly hyperlinked in order to open a webpage.  I would consider both of these "accessibility" type features (my handicap being that I don't speak the native document language and can't read it without assistance).

I get that people want to protect their documents and the spec does allow for copy protection (although I read that the flag for accessibility copy protection goes away with PDF 2.0 because this should ALWAYS be allowed).  

Personally I think the permissions standard is a bit silly today since anyone that wants to can work around the restrictions...ie it doesn't prevent pirates from pirating "protected" PDFs and for the average user it is just a terrible user experience.  I am guessing that the spirit of the copy permission was to protect from people literally copying/pirating content and not to prevent people from accessing the content.  Not sure how many people would copy and paste text out of a PDF document into their own document and then re-apply a bunch of formatting and release it themselves...   I think many content authors don't think through the user experience either.  Protection sounds good so they do it even if it doesn't make sense or has negative side effects for users. For example, the example document I linked is a simple form that has to be mailed/faxed...it will either have the correct info when it arrives or it won't.  Nothing prevents a user from creating their own look-a-like (but slightly different) form and faxing it it.  Pretty sure the encryption is lose over post/fax.  ;)

But whether the standard makes sense, what the original intentions were and whether they still make sense today is obviously out of scope for chrome development.

I agree with you that chrome appears to be following the standard and all the other PDF reading applications on my machine don't.  Given that this standard doesn't seem to be widely followed and that when enforced it creates a very negative user experience (why can't I copy?!)...it would definitely be nice if there was some obvious indicators that copying isn't allowed by the document when a user tries to copy.

An alternative approach/interpretation might be to see copying small amounts of text (no images/formatting or full documents) as part of the accessibility permission. 

I can reproduce this issue. On the example PDF in this bug, text cannot be
cut-and-pasted. On other PDF documents it works fine.

Yes, I agree the PDF permission bits are a bit silly. Our PDF Viewer honors them though, just like Acrobat Reader. This is not the first bug report about this issue, so we will stand by our previous decision to leave things as they are. If Acrobat's behavior changes in the future, we can certainly revisit the issue then.

I can't speak for other PDF viewers and their behaviors.

For UI to show permissions, that would fall under bug 652427.

Thanks for the update.  Can you point me at any documentation around what accessibility features/apis/hooks chromium's PDF viewer provides?  The extract permission is given on these documents and I believe several of my use cases fall under use for accessibility purposes.  Looking for alternatives to just disabling the PDF plugin.

In the PDF Viewer, we do take the "copy for accessibility" bit into account, per spec. See PERMISSION_COPY_ACCESSIBLE in [1]. The PDF linked to from this bug report has that bit flipped to on.

Presumably screen readers that work with Chrome can "read" the text. I don't use them frequently enough to recommend one. Maybe try ChromeVox for starters?

[1] https://chromium.googlesource.com/chromium/src/+/524e60fb/pdf/pdfium/pdfium_engine.cc