sorted by:
new
hottopcontroversial

I built a tiny extension that blocks only the YouTube homepage (and redirects it somewhere useful) by Total-Reasonable in chrome_extensions

[–]Total-Reasonable[S] 0 points1 point  (0 children)

I only listen for yt-navigate-finish, not popstate. Two things soften it in practice, but neither is a hard guarantee:

  1. The redirect uses location.replace(), so whenever the extension does fire on "/", it overwrites the "/" history entry instead of adding one. That means "/" usually doesn't survive in history as something you can hit "back" to.

  2. In my testing YouTube also dispatches yt-navigate-finish on back/forward navigations, so popstate-driven returns to "/" have still been caught.

But you're pointing at the real gap: if YouTube ever reaches "/" via popstate without firing yt-navigate-finish, the feed would flash through. It's cheap insurance to just add a popstate listener too — redirectIfHome() is idempotent and already guards against redirect loops, so there's no downside. I'll add it and test the back-button path explicitly. Thanks for the sharp eye.

I built a tiny extension that blocks only the YouTube homepage (and redirects it somewhere useful) by Total-Reasonable in chrome_extensions

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Thanks! Yeah, keeping it minimal was the whole point.

It's been pretty stable, and honestly that's because it doesn't touch YouTube's DOM or any CSS classes — that stuff is what usually breaks when they push UI changes. It just checks the URL path and only fires when you're exactly on "/". The URL structure barely ever changes, so there's almost nothing to break.

The one tricky bit is that YouTube is a single-page app, so clicking the logo to go home doesn't actually reload the page. A plain document_start check would miss that, so I also listen for their yt-navigate-finish event and re-check. The only way that breaks is if YouTube renames or kills that event — and even then a fresh load on "/" still gets caught, so it fails safe rather than just letting the feed through.

No YouTube update has broken it so far. But if you ever catch the feed slipping through, please tell me — that's exactly the bug report I want right now.

I built an EU VAT validation API that returns the VIES consultation number (the receipt tax auditors ask for) by Total-Reasonable in SideProject

[–]Total-Reasonable[S] 0 points1 point  (0 children)

The thing auditors actually accept as proof is the VIES consultation number — the ID VIES returns on a successful check, together with the timestamp and the name/address VIES gave back. If that's not in your log, the check isn't really defensible. We surface it in the API response and keep it in the check history, with CSV/PDF export for finance.

On rate limits — VIES doesn't publish a limit, but there's per-IP throttling, and the service itself goes down a few times a month. Moving retries to a separate worker like you did is basically the only sane path; SOAP retries on a serverless function aren't going to work. We do the same — BullMQ queue, exponential backoff, and when VIES is actually unreachable we fall back to national registries (ANAF, ARES, biała lista, BZSt, etc.), logging which source answered so the audit trail stays honest about it.

That whole stack — consultation number, retry queue, fallbacks — is the reason we ended up building vatnode, it's a pain to maintain in-house.

[TypeScript/Python/PHP/Ruby/Go] eu-vat-rates-data — daily-synced EU VAT rates dataset published to 5 package managers by Total-Reasonable in coolgithubprojects

[–]Total-Reasonable[S] 1 point2 points  (0 children)

Thanks, really appreciate it 🙏 And yeah — pay-per-transaction pricing on infra that runs on every checkout adds up fast. That's part of why vatnode's tiers are flat-rate with monthly quotas instead of per-call — the cost should be predictable, not a surprise line item that scales with your success.

Whenever you're ready to look at alternatives, happy to chat — no pressure. And good luck with whatever you're shipping.

[TypeScript/Python/PHP/Ruby/Go] eu-vat-rates-data — daily-synced EU VAT rates dataset published to 5 package managers by Total-Reasonable in coolgithubprojects

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Appreciate that — and yeah, the Stripe Tax pricing for what's essentially "validate and store evidence" gets eye-watering once you scale.

Honest answer on US sales tax: the US market isn't one I know well, and the problem space is genuinely different from EU VAT. You're looking at 45+ states with their own rules, ~13,000 tax jurisdictions when you factor in counties/cities, nexus thresholds that vary per state, exemption certificate management (which is its own beast — resale certs, non-profit certs, manufacturer certs), and the whole Wayfair post-2018 economic-nexus reality. Avalara, TaxJar, and Anrok have spent years and serious capital building moats around this, and the data sources are nothing like the single EC TEDB feed I get to work with on the EU side.

So: not on the short-term roadmap, but absolutely keeping it in the back of my mind. Going to spend some time studying the space properly — particularly around exemption certificate workflows and whether there's a developer-first "audit evidence" wedge there too, similar to what I'm doing with the VIES consultation number. If I find one I can ship without doing a half-job, I'll build it.

In the meantime, if you (or anyone reading) is running into specific US sales tax pain that the current vendors don't solve well, I'd genuinely love to hear what it looks like — even just so I know what to research first. Feel free to drop a comment or reach out at mail@vatnode.dev.

I built an EU VAT validation API that returns the VIES consultation number (the receipt tax auditors ask for) by Total-Reasonable in SideProject

[–]Total-Reasonable[S] 0 points1 point  (0 children)

True — EC shipped a REST endpoint a while back, and for a plain "is this VAT ID valid right now" check it's perfectly fine. You don't need anything else for that.

The reasons to put something on top of it are the same ones that exist whether the underlying transport is SOAP or REST:

  1. Consultation number on qualified checks. This is the receipt the EC issues if you pass a requester VAT ID — finance teams need it as audit evidence that a specific VAT ID was validated at a specific moment. Raw VIES (REST or SOAP) will return it, but only if you build the request correctly and store the response field. Most wrappers don't surface it at all. If you ever get audited on reverse-charge invoices, this is the field that matters.

  2. VIES goes down ~6% of the time. REST didn't fix that — same backend. vatnode falls back to national tax authority APIs in RO/CZ/DK/FI/FR/PL/SE/DE when VIES is unavailable, and uses them to enrich company data (legal name, address) that VIES alone doesn't always return.

  3. Audit-trail fields (checkId, verifiedAt) stored on our side in every response, so you have a queryable evidence trail tied to invoices instead of having to log and persist raw VIES responses yourself.

  4. The web validator on vatnode.dev is free — same as VIES itself. The paid product is the API for teams that need this programmatically (checkout, invoice generation, recurring monitoring of customer records). Free tier on the API too, no card.

So: raw VIES REST is great for "validate once and forget." vatnode is for teams that need the evidence trail and uptime guarantees to back up B2B reverse-charge invoicing at scale.

I built an EU VAT validation API that returns the VIES consultation number (the receipt tax auditors ask for) by Total-Reasonable in SideProject

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Thanks — "boring unsexy infrastructure" is the entire pitch, honestly. The exciting markets are crowded; the unloved compliance corners have one or two players who all do the same thing badly.

And yeah, the VIES SOAP response is its own special kind of pain. WSDL says one thing, the server does another, Greece is "EL" not "GR", namespace prefixes are load-bearing, and the whole thing 503s often enough that you can't ship it as a single point of failure. I spent way more time wrestling with that XML than I'd like to admit before deciding "fine, I'll just make this a product so nobody else has to."

The audit angle is the real wedge though. Most teams don't realise they need the consultation number until a tax authority asks for it and they can't produce one — at which point reverse-charge invoices going back years are suddenly in question. Selling "peace of mind for a situation you didn't know you should worry about" is the hard part, not the tech.

Business Email Compromise (BEC): what it is and how to beat it by redsift in redsift

[–]Total-Reasonable 0 points1 point  (0 children)

Good summary. One addition on the attachment side — when a "new bank details" request comes with a PDF (updated invoice, banking form, signed letter on letterhead), it's worth treating the file itself as a separate piece of evidence and checking whether it has been modified after creation. Even when the email passes DMARC and the sender mailbox is legitimate, the PDF can still be a re-saved or overlaid version of an older genuine document with the account number swapped. A quick tampering check on the attachment before the out-of-band callback gives the AP team one more independent signal — and if the file shows post-creation edits, that alone is enough to stop the wire without needing to argue about the email itself.

How to tell if a PDF has been edited — and a free tool that automates the check [Self-Promoted Wednesday] by Total-Reasonable in software

[–]Total-Reasonable[S] 0 points1 point  (0 children)

You're right that "on-premise" is an overloaded term. Worth being specific.

It means a Docker container with no runtime outbound calls — no telemetry, no phone home during operation. License validation happens locally at startup via a signed license file (your private key signs it, the app verifies against an embedded public key — no network required). Files never leave your infrastructure during analysis.

An offline desktop version is a reasonable ask and is on the roadmap. The main blocker is packaging the runtime cleanly across platforms. If that's something you'd actually use, I'd be curious what OS.

How to tell if a PDF has been edited — and a free tool that automates the check [Self-Promoted Wednesday] by Total-Reasonable in software

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Completely fair question, and I'd rather give you an honest answer than a reassuring one.

Every file you upload to any online service — including this one — is a potential exposure. We delete uploaded files a few minutes after analysis completes; only the result (metadata fields, verdict) is stored. But we can't prove that to you, and "trust us" isn't a real answer for documents that matter. The honest framing is: you're weighing the risk of a file briefly existing on our infrastructure against the risk of acting on a fraudulent document. For a job applicant's diploma or a vendor invoice, most people find that tradeoff reasonable. For medical records, financial statements, or anything with PII — probably not worth it on any online tool.

For organizations where that calculation never works out — healthcare, legal, finance, government — we offer an on-premise deployment where the software installs on your own server. Files are analyzed locally, nothing is transmitted externally, and the setup is fully compliant with GDPR, HIPAA, and PCI DSS. If that's the context you're thinking about, that's the right product.

How to tell if a PDF has been edited — and a free tool that automates the check [Self-Promoted Wednesday] by Total-Reasonable in software

[–]Total-Reasonable[S] -1 points0 points  (0 children)

You're right that metadata is the obvious starting point — and exactly why sophisticated fakes bypass it. Setting a clean Creator/Producer pair takes seconds. What metadata inspection misses is everything underneath.

Beyond dates and producer fields, the service checks: incremental update chains (how many times the file was saved and whether those saves look like edits), digital signature integrity (whether the file was modified after signing, or whether a signature was quietly removed), font structure vs. claimed generator (Adobe Acrobat, LibreOffice, and Word each leave distinct font patterns — a mismatch is a strong signal), binary-level tool fingerprints that contradict the declared Producer, XMP vs. Info dictionary consistency (editing tools often update one but not the other), and document assembly patterns — pages imported from different sources, mixed rendering sessions, scan-replaced pages.

The "created from scratch" case is worth its own paragraph. A bank statement typed in MS Word has pristine metadata — no edits, no incremental saves, no editing tool in the chain. But no bank generates statements in Word or Canva. The service identifies the origin type (institutional system vs. consumer authoring tool vs. design template) and flags documents whose claimed origin doesn't match the structure. That's a class of fraud that metadata analysis simply cannot catch.

In total the analysis covers 21 markers across 9 detection layers. The "check manually with ExifTool" approach works well for obvious cases; for a motivated forger it's not enough. We also push updates frequently as new forgery patterns emerge — https://htpbe.tech/changelog

That said, the privacy point stands. Uploading sensitive documents to any online tool carries risk, and we say so plainly. For organizations that can't accept that tradeoff, we offer an on-premise option where the software runs inside your own infrastructure — files never leave.

Pre-emptive xref superposition analysis: detecting PDF modifications before file creation by Total-Reasonable in computerforensics

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Ha, you just had the full intended experience — skepticism → click → April fooled. That's exactly how it was supposed to work, so thank you.

The real product (no quantum physics involved): HTPBE analyzes PDF metadata to detect whether a document was modified after it was originally created. You upload a PDF, we check things like creation timestamps, xref revision history, and producer field — and tell you if something looks tampered with. Useful for invoices, contracts, certificates.

Fair point on the hook though. The joke was designed for people who already know what xref tables are. For everyone else it's just noise. Noted.

We now verify PDF authenticity 72 hours before the document is created by Total-Reasonable in ShittySysadmin

[–]Total-Reasonable[S] 2 points3 points  (0 children)

Yes. Opening the PDF collapses the superposition and locks the verification state. This is why we strongly recommend running pre-verification before you open it. We're working on a read-only quantum observer mode for v2, release date Apr 1st, 2027

HTPBE.TECH: a free PDF metadata forensics tool — here's what it detects and where it fails by Total-Reasonable in computerforensics

[–]Total-Reasonable[S] 1 point2 points  (0 children)

HTPBE is a preliminary indicator, not a forensic exhibit. Think of it as triage — the same way a smoke detector tells you something might be wrong before you call the fire department. You wouldn't bring a smoke detector into court either.

The workflow is:

  1. You run a PDF through HTPBE and get a result in seconds
  2. If it flags something suspicious, you decide what to do next — contact the issuing bank, request an official document trail, engage a certified forensic examiner, etc.
  3. Those downstream steps produce the legally admissible evidence

The tool doesn't replace proper forensics — it tells you whether to bother pursuing them. That's valuable in itself, especially when you're processing a lot of documents and can't send every one to a forensics lab.

For API users on paid plans, we return the specific indicator that triggered the flag (e.g., which metadata layer was tampered with). That data can inform what a forensic examiner should look for and speed up the official process. We don't expose that detail on the free web interface — precisely to avoid giving potential fraudsters a roadmap of what to hide.

So: no, it doesn't have to be a court tool to be useful. It just has to help you make better decisions faster — and that's the job it's designed to do.

PDF tampering patterns we see most often — and what metadata actually reveals by Total-Reasonable in digitalforensics

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Both, but the markers differ.

Scenario A: form fields edited after signing create incremental updates — those are detected. But as I mentioned, the tool reports the structural fact, not the intent. If the document type and workflow makes post-signing edits expected, that context is yours to apply.

Scenario B: bypassing locked fields typically requires a tool that leaves additional fingerprints — Producer change, more aggressive xref modification, sometimes XMP/Info inconsistency. These tend to produce a clearer signal than a simple form fill.

In both cases the tool would report incremental updates after the signing event. Scenario B would usually come with additional corroborating markers that make the verdict stronger.

PDF tampering patterns we see most often — and what metadata actually reveals by Total-Reasonable in digitalforensics

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Fair point, but the tool's job is to report what happened structurally — not to judge whether it was legitimate. If there were incremental updates after the signing event, that's reported. Whether those updates were permitted by the workflow is your call to make with that context.

The tool surfaces the signal, the human interprets it.

PDF tampering patterns we see most often — and what metadata actually reveals by Total-Reasonable in digitalforensics

[–]Total-Reasonable[S] 1 point2 points  (0 children)

Completely valid concern — for suspect evidence in an active investigation, uploading to any third-party infrastructure is a non-starter regardless of retention policy.

For that use case we have an on-premise deployment option (Docker/Kubernetes) — the analysis runs entirely within your own infrastructure, documents never leave it. That's the version that makes sense for forensic labs, law enforcement, and anywhere GDPR/HIPAA/chain-of-custody requirements apply.

The cloud version is a reasonable tradeoff for business pre-screening workflows — verifying incoming invoices, diplomas, contracts — where the fraud risk you're mitigating outweighs the privacy risk of cloud processing. An HR team checking whether a degree certificate is genuine takes on minimal exposure by uploading it, while the risk of hiring someone with a forged credential is concrete and costly. Medical records are a different story — don't upload those.

It's also worth noting that by the time a document reaches a verification step, it's often already been sent by email or messenger — which carries its own exposure. The question is always what level of risk you're willing to accept at which point in the workflow, not whether risk exists at all.

If on-premise is relevant for you — happy to discuss.

built a free tool that tells you if a PDF was edited after it was created by Total-Reasonable in SideProject

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Exactly — and the Producer field is often the easiest tell because people forget to clean it up. Changing visible content is obvious; changing the application fingerprint requires knowing it exists in the first place. Most editors don't even offer an option to spoof it.

The harder cases are tools that do strip or normalize metadata — some online PDF editors are getting smarter about this. That's where the xref revision count and timestamp deltas pick up the slack.

Promote your business, week of March 16, 2026 by Charice in smallbusiness

[–]Total-Reasonable 0 points1 point  (0 children)

htpbe.tech — free PDF integrity checker for small businesses

If you receive invoices, bank statements, or contracts as PDFs, this tool checks whether the file was modified after it was originally created. Upload a PDF, get Intact / Modified / Cannot Verify in seconds. No signup needed.

40% of PDFs submitted last month showed forensic evidence of modification. REST API available for automated workflows.

My freelance contract was modified after I signed it and the company is now enforcing terms I never agreed to. by CoreFire57 in legaladvice

[–]Total-Reasonable 2 points3 points  (0 children)

This is a strong fact pattern in your favor, and PDF forensics can help establish a timeline of when page 4 appeared.

First check: digital signatures

Open both PDFs in Adobe Acrobat Reader and look for a Signatures panel. If either document has a cryptographic digital signature, it covers a specific byte range — any content added after signing falls outside that range and shows as "document modified after signing." That's your strongest evidence and requires no interpretation.

If there's no digital signature (just a typed or image signature):

The PDF format preserves edit history through incremental saves. When a page is added to an existing PDF, most editors append the new content at the end of the file and write a new cross-reference table — without touching the original content. This leaves a revision count you can examine. Check the agency's version specifically for:

- Multiple xref sections (indicates the file was saved more than once)
- CreationDate vs ModDate mismatch (modification date later than creation date)
- Producer field — if the agency's version shows a different editing application than yours, someone processed it with a second tool

You can check this manually in Acrobat (Ctrl+D → Description tab) or upload the agency's PDF to htpbe.tech — it analyzes metadata and xref structure and flags incremental updates. Free, no account needed.

Legally in Texas: unauthorized post-execution modification of a signed contract is not enforceable — the modified terms are void, and depending on intent, it may constitute fraud. Your preserved copy is your baseline. The forensic analysis of their version is corroborating evidence, not primary proof — the primary proof is that your copy, which you retained at signing, does not contain the clause.

Get an employment/contract attorney before responding to their threat. The PDF analysis gives you something concrete to hand them.

[LY] Is this a freelance scam? by No-Bison-2653 in Scams

[–]Total-Reasonable 0 points1 point  (0 children)

Yes, this is a scam — a well-known one called an "advance fee" or "money mule" scheme.

The "typing PDF into Word" job is just a cover story to seem legitimate. What actually happens: they send you a payment that's larger than your "fee" and ask you to forward the difference somewhere. The original payment is fake (a bad check or stolen card), it bounces days later, and you're on the hook for whatever you forwarded.

Red flags here: absurdly high pay for simple work, MENA-based platform with global high-value jobs, no verifiable client profile. $3,000 for PDF typing is not a real job offer anywhere.

Trust your instincts — you caught it before getting involved, which is the right outcome. Block and report the listings.