Show HN: PDFs that are readable by human eyes only (humaneyesonly.com)
Hi, OP here. A friend was involved in a custody battle and was afraid his ex was going to leak all of his discovery documents on the internet and he asked if there was something I could do to make it harder for bots/crawlers to find sensitive information. Originally I was going to turn all of his docs to image based PDFs, but those get large fast and are easy to OCR.
So I found a post musing about altering fonts/glyphs so that it looks like english, but the actual character being seen by the pdf reader is a non-english character. As such, when you try to OCR these files, it doesn't see any images and can't convert it.
I figured it had some potential uses and maybe you fine folks can identify other use cases. I'll be monitoring this post most of the day.
131 comments
[ 3.4 ms ] story [ 179 ms ] threadAnd as it is, it does not prevent "OCR", only copy-paste.
if the generator crafted a new font every time, never used the same codepoint twice, and kept the font separate from the document (pre-shared by being installed on the intended receiver's machine) then it'd be uncrackable!
I'm 1000% sure there are gurus who could whip up a script to overcome this. But its kind of one of those things where you don't have to outrun the bear, you have to outrun your friend running next to you. It makes your sensitive documents just that much less likely to be scanned/found.
This seems like quite the oversight to me...
If you’re a divorce attorney who used this to convert documents in response to a discovery request, and the opposing side had a valid reason for needing the unobfuscated text, then you’re probably going to end up having a nice conversation with the judge about acceptable formats.
Sending compressed TIFFs would probably be just as good. A bit larger file sizes, but it would be just as effective as stopping automated scraping of text. Also, less likely to piss off a judge. Any opposing firm that would be sophisticated enough to automate scrapping the text from a normal PDF would be able to OCR these files just as easily.
Or maybe you have a second site that sells the decoder, so you get to sell to both sides. Not a bad business model, if you can work it.
... And most attorneys simply print documents. Once the PDF is on paper, OCR-ing it back into text is just one scanner away.
Retrieving text from images is literally the definition of OCR.
You don't need any scripts, just Acrobat itself (or any comparable PDF viewer) can do this. Export the PDF to images, make a new PDF out of the images, scan the text, done.
Example (took your example and did just that with it, now everything can be copied & pasted as normal text): https://filebin.net/qse2e0oaqkl1hjof/ocred.pdf
In general, if it LOOKS like text, SOMETHING can OCR it. That's the whole point of OCR. If you want to try to block OCR, you need something like CAPTCHAs, and that's getting less and less effective every day. In fact many are already more easily solved by computers than humans.
1) As many people pointed out, this doesn't prevent OCR, it just prevents copying strings (e.g. with crawlers). 2) Majority of OCR doesn't deal with PDFs produced from a text source but either from a) jpg-scans of documents b) pdfs produced from those jpg-scans. 3) The first thing I tried, was OCR with my iPhone and it obviously worked. As someone else said, there're solutions that let you batch process many documents.
Don't get me wrong, your stuff works for what you designed it to. However, it provides <false sense of security> by <falsely> claiming that it prevents OCR; which in turn, can lead to more harm[1].
[1] - e.g., it may convince people to share stuff that they wouldn't otherwise.
Security through obscurity is stupid:
All you need is ghostscript and tesseract. Both are an apt-get away.Any image you open in Safari, Preview, etc. (official Apple programs) will be OCR'd automatically, allowing you to extract the text with copy+paste. I think it works with PDFs, but I haven't tested it.
https://support.apple.com/guide/preview/interact-with-text-i...
There is no form of OCR this is resistant to, simply the change the description to be accurate and remove references to being OCR resistant as this is false.
https://github.com/ocrmypdf/OCRmyPDF
> Resistant to Optical Character Recognition (OCR), most laypeople will need to print+rescan to OCR
If print+rescan (or equivalently, screen-grab+OCR) works, which it will, then it's hardly OCR-resistant!
The only thing this "blocks" is text extraction from the PDF with things like copy/paste or pdftotext/html/whatever conversion tools, which will "see" the codepoints used rather than the glyph images.
What this blocks is not OCR but casual copy & pasting (and search engine indexing)
The various legal teams involved are unlikely to ever be the wiser. Or will they?
Won't this print out a pile of gibberish? Hard copies are rather important in the courts. Somebody is going to complain about what was provided in that case.
If that happens, I suspect he'd have a very strong case to win custody...
But, if the judge didn’t care and it made your friend feel better, who am I to judge? But this isn’t a great protection scheme… it just adds a few extra technical hurdles that are easy to get around.
That isn't true. Acrobat might skip parts of the PDF that it thinks are already text/glyphs, but it's trivial to get around that by either using other OCR software or just printing the PDF to a raster image first. Example: https://filebin.net/qse2e0oaqkl1hjof/ocred.pdf
Still, though, for the purposes of obscuring these from bots/crawlers... a lot better than nothing!
What your eyes see is identical to what the computer sees. They are both giberrish. Also the email is giberrish.
What am I missing here?
This is what I am getting on the browser.
edit: Saw you said you use an old phone. Found those fonts are in woff format. Older Android phones don't have support for it.
Name: Satoshi Nakamoto
DOB: 1982-06-05
SSN: 958-20-3141
Cell Phone: 514-867-5309
The problem with DRM is not that someone is trying to control what happens to a string of bits, it's that it props up an institution which is harmful.
Being able to selectively defeat copy paste is an additional option that additionally empowers users.
I don't anticipate this tool being used very widely. If it became the default, I would have a problem with it for the reasons you highlight, among others.
Saying this is tantamount to DRM misunderstands what the problem is and what empowerment means. Actions taken by those in positions of power and those who are not aren't morally equivalent. This sort of thinking is damaging to any effort to empower users.
There are easier ways to do this, such as encrypting the PDF. It is trivially easy to password protect a PDF as well [0], it is even a part of the PDF spec. It isn't ironclad, but it will defeat Gmail's indexer.
[0]: https://digify.com/blog/protect-pdf-with-password/
Operational Procedures for Planning and Conducting Cybersecurity Incident and Vulnerability Response Activities in FCEB Information Systems
Publication: November 2021
Cybersecurity and Infrastructure Security Agency
DISCLAIMER: This document is marked TLP:WHITE. Disclosure is not limited. Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyrght rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol, see
---
Converting the first page of the sample PDF file to a tiff file using ghost script and running tesseract OCR without any special filters.
>Resistant to Optical Character Recognition (OCR), most laypeople will need to print+rescan to OCR
This is not OCR resistant, I used the same two liner I used to get my textbooks scanned at university 20 years ago.
Words mean things, if what you did can't stand up to 20 year old technology then it's basically useless. Remove the claim that it resists OCR and just called it copy/paste proof and unsearchable.
What you're resisting here is the ability for other applications scrape the already text-format text.
This seems like a nicely clever way to trip up non-targeted scrapers which might attempt to OCR any images they encounter, but which will ignore what looks like random gibberish codepoints. It doesn't eliminate the ability to index this data but I can see how it might greatly reduce it.
Obviously you could still convert these PDFs to an image and OCR them, but that's not the thing being defended against here.
You're supposed to provide mapping tables for text extraction but they are optional.
This fails pretty bad for security because you can detect the glyphs themselves in the font tables and provide a mapping yourself
Unfortunately OP, I don't think your solution even works for your intended use case; Google already does OCR (actual OCR, not just parsing text) in Images. I use it in Gmail quite often. Regardless the implementation is quite neat and will surely thwart less advanced indexers.
switch between apps and pick the app with the text but don't jump back into the app yet, select text and you can immediately copy the text out.
It's yielding the visible text, so most be OCR'ing the image (works offline too).
When i copy direct from the example on the web page, in the non-OCR method, that does give the messed up text, but not when done the way above.
" Phone: 514-867-5309" was copied out easily (can't be bothered to go back get the Cell bit i was just inaccurate copying, I'm sure it works!)
A more accurate (and helpful!) description of the problem you're solving is that this disrupts text parsers. That is, any program that just reads this in as text won't see the "real" letters (unless it's been pre-programmed with a specific reverser, etc.) and thus will frustrate, say, text search.
Which, on that note, I notice elsewhere you mention this being a solution applied to document submission in legal proceedings. In that case, the assumption might be that one side wishes to run text searches and assume its compatible with that. In that case, this could be viewed as non-compliance with a judge's orders, so FYI.
Bullshit
1. Screenshot
2. OCR
3. Profit
If you make a sensitive document unindexable (assuming this works), then effectively no one can find it.
The intent here is not to restrict the document to sighted users but to hide the document from everyone, which includes sighted and blind users searching for keywords. The fact that blind users can't read the text at all without screen grabbing is just a bonus.
It’s probably still not ML-resistant.
In the end I managed to get some text out of it but the end result was still pretty terrible.
INTRODUCTION The Cybersecurity and Infrastructure Security Agency (CISA) is committed to leading the response to cybersecurity incidents and vulnerabilities to safeguard the nation's critical assets. Section 6 of Executive Order 14028 directed DHS, via CISA, to "develop a standard set of operational procedures (playbook) to be used in planning and conducting cybersecurity vulnerability and incident response activity respecting Federal Civilian Executive Branch (FCEB) Information Systems." I Overview This document presents two playbooks: one for incident response and one for vulnerability response. These playbooks provide FCEB agencies with a standard set of procedures to identify, coordinate, remediate, recover, and track successful mitigations from incidents and vulnerabilities affecting FCEB systems, data, and networks. In addition, future iterations of these playbooks may be useful for organizations outside of the FCEB to standardize incident response practices. Working together across all federal government organizations has proven to be an effective model for addressing vulnerabilities and incidents. Building on lessons learned from previous incidents and incorporating industry best practices, CISA intends for these playbooks to evolve the federal government's practices for cybersecurity response through standardizing shared practices that bring together the best people and processes to drive coordinated actions.
Pretty sure this doesn't actually work.
What your service DOES block is casual copying and scraping. But the people who are going to be doing that (search engines and the like) are different from people who need actual protection from OCR (I don't know who that is, but presumably they've identified it as a threat and need to specifically mitigate it, a la CAPTCHAs).
By misrepresenting the actual security/obscurity of your service, you are putting people at risk with a false sense of security that's trivially defeated by anybody with minimal IT experience. It'd be like if Signal promised encryption but actually just implemented ROT13.
Which would you rather hear from, a bunch of devs saying "you're misrepresenting your product, might wanna tweak your marketing" or a bunch of burned users trying to sue you because you misled them into a bad situation?
The Cybersecurity and Infrastructure Security Agency (CISA) is committed to leading the response to cybersecurity incidents and vulnerabilities to safeguard the nation's critical assets. Section 6 of Executive Order 14028 directed DHS, via CISA, to "develop a standard set of operational procedures (playbook) to be used in planning and conducting cybersecurity vulnerability and incident response activity respecting Federal Civilian Executive Branch (FCEB) Information Systems."