Bonum Certa Men Certa

Supplying Techrights With Leaked Material

tl;dr We prefer not to know who is sending the material

What Was New York Times Reporter James Risen’s Seven-Year Legal Battle Really for?
Reference: What Was New York Times Reporter James Risen’s Seven-Year Legal Battle Really for?



Summary: An updated advice or guidance for sending documents and/or information to us without getting caught by prying eyes, not even if we are legally threatened by an out-of-control institution that bends the law

THE number of leaked documents that we have received from EPO insiders is very high and we prefer not to comment about the number of leakers/sources. Last year, upon request, we published some tips for submitting leaks to us.

Some people requested further clarifications and some people have suggested improvements to the article since it was first published, as better options became available (not that our advice was altogether bad, just suboptimal or deficient). "Please help," one person wrote to us. "I saw your article "How to Securely Provide Techrights With Information, Documents". Could you please clarify the following in a future article?"

"We never got caught publishing anything fake, which means we have a 100% accuracy record, as far as source material goes."The main amendments suggested to us were the sorts of sites/services to use for increased anonymity/privacy/security. These sites, as one might expect, are not well known or even mainstream. Some people wish to send images, some send plain text, some send rich text, and some send documents, scans of documents, or photographs (if not screenshots) of documents. We generally think that photographs of things are less likely to leave legible watermarks (like kerning signatures) and the same goes for plain text, so it's probably safe to reduce everything down to images and plain text. We prefer not to know where these are coming from, even if we can manually remove personally-identifying metadata. It makes both us and our sources safer when neither side has identity information. Put bluntly, we typically prefer not to know where material comes from; we just need to know that it's verifiable (given context and/or accompanying explanation) and then we can cross-check to ensure its authenticity. We never got caught publishing anything fake, which means we have a 100% accuracy record, as far as source material goes. We do check everything carefully before publication. We don't wish to get tricked into publishing fake material as that would be self-discrediting and it's a commonly-used tactic for muddying the water or poisoning the well.

"I am unsure whether it is safe to send you a .pdf document," a person told us anonymously, "including text only."

We don't really need the original PDFs if there is enough to verify by; PDFs are of a clunky format type that tends to migrate with it all sorts of signatures and it drips metadata. If people can upload an image somewhere on the Web (preferably not through service such as Google's, as they have a poor record on anonymity) and then send us a link, that ought to be enough. Remailers can be used to send us anonymous messages (or links) and we can typically cope with the input without having to even reply to the source.

"We do check everything carefully before publication.""Anonmgur does no longer exist," we were told, "but Anonmgur now refers to anonimag.es as an alternative. I've tried anonimag.es, several times, but it does not work properly."

We got into some discussions last year about which image and text 'bins' are best or safest for preserving anonymity (even at the face of legal threats, which are rendered useless if logs are purged permanently). If we recommend one particular service (there are many), it will enable the surveillance lackeys at EPO to latch onto particular domains, so we prefer not to suggest just one particular service. Diversity breeds safety here.

"Thanks for updating or amending your article "How to Securely Provide Techrights With Information, Documents" so that thing become clearer for me and others," we were told, but we decided to lay things out again, rather than modify the previous article (we rarely edit old articles, except just hours after publication).

"If we recommend one particular service (there are many), it will enable the surveillance lackeys at EPO to latch onto particular domains, so we prefer not to suggest just one particular service."To date, the most damaging EPO leak was probably this one. It generated a lot of media coverage and caused a great stir among EPO stakeholders, who rightly felt like they had been discriminated against.

Today or last night Research and Markets published details about an upcoming one-day seminar with tips for EPO applications and another for advanced drafting. We could not help joking about it because in today's EPO it seems like anyone can just pay under the table or lobby for preferential treatment. We are certain that many examiners have come across examples of that and we hope for more leaks to that effect.

"Like any publication out there, we strive to have impact, as do our sources."Regarding the timing of disclosure, it's not always immediate (upon receiving material) because we need to verify authenticity, we need to wait for relevant development/news, and sometimes there are two connected stories that we investigate at the same time and they can be fused together. Like any publication out there, we strive to have impact, as do our sources. So if we don't release something promptly, then there is probably a reason behind it. We rarely post teasers (quite rarely we do, for a change) because the element of surprise enables us to catch the EPO's management, for example, unprepared and unable to properly respond, distract, or undermine publication (as attempted in the past).

Recent Techrights' Posts

Corporate Media: Blame the People Who Enter the Abandoned IBM Buildings, Not IBM for Abandoning Workers in Pursuit of IT Sweatshops
When the media spreads falsehoods stocks can go up (a lot higher), but at whose expense and how long for?
SUEPO Munich Report on the Recent EPO Demonstration and Rolling Strikes That Continue to Grow
"increasing registrations for the 'rolling strikes' running until autumn"
Gemini Links 11/07/2026: Old Computer challenge, Poems, Antenna, and More
Links for the day
 
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Saturday, July 11, 2026
IRC logs for Saturday, July 11, 2026
Blogs May be Making a Comeback (They're Not Fediverse, They Are Joined by RSS Feeds)
Don't fake expansion where none existed
ChromeOS and GNU/Linux in the United Kingdom Reach 11%
the UK shows signs of digital maturity
Canonical is Selling Microsoft, It Pays The Register MS to Sell Microsoft
It's all about money to them. And they call this journalism.
When Red Hat's HR Becomes the Same as IBM's HR (Bluewashing)
Red Hat keeps sacking very experienced engineers and adding temporary interns
GNU/Linux Growing in East Asia
Assuming this is more or less accurate, we could use a plausible explanation
Over a Week After Microsoft Discontinued Some XBox Models It Apparently Exits Some Markets Altogether
We seem to be witnessing the end of XBox
Links 11/07/2026: "Trademark wars of Influencer Culture", Xinuos Uses Copyrights Versus UNIX
Links for the day
North America: GNU/Linux Measured at 10%
To better understand what contributes to the gains
Following Corrections and Adjustments statCounter Sees GNU/Linux at 7.1%, an All-Time High
There is a lot of layoffs at Microsoft this month
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Friday, July 10, 2026
IRC logs for Friday, July 10, 2026
Links 11/07/2026: Wednesday-Saturday News Catch-up
Links for the day
Prioritising High-Importance News
In order to fully catch up with news we'll not publish many new articles until next week
The Register MS: "AI" More Than 80 Times in One Article. But It's Not an Article, It's Sponsored Keyword-stuffed Page.
The Register MS is being paid to actively promoted this scheme
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Thursday, July 09, 2026
IRC logs for Thursday, July 09, 2026
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Wednesday, July 08, 2026
IRC logs for Wednesday, July 08, 2026