A paste is not one copy. It is several copies you cannot pull back.
People treat redaction as courtesy: swap a full number for asterisks so the message looks professional. The damage starts after the paste. The ticket store keeps the body. The chat service keeps the message. Error monitoring scrapes the stack. Session replay records the box. An outsourced queue exports another file. Changing a few characters on your screen does not change copies already written. A later “edit the ticket” pass only edits the current row. Search history, mail notices, and downstream analytics often still hold the original.
The OWASP Logging Cheat Sheet writes this as an engineering constraint, not a style tip. It lists data that should be excluded, masked, sanitized, hashed, or encrypted before it lands in a log: sensitive personal data and some identifiers (health information, government IDs), authentication passwords, access tokens, cryptographic keys and other master secrets, bank accounts, and payment-card holder data. Inside a company, tickets and group chats often act as informal logs: easy to search, looser permissions than production, longer retention. Pasting a customer’s words wholesale is how you invent a record OWASP says you should not keep.
HTTPS only protects the hop against eavesdropping. It does not wipe plaintext you already handed to the next system. The previous note made the same point for query strings: they land in history, Referer, and access logs. A number in a paragraph is the same class of exposure. The carrier is a sentence instead of a URL. The question before you share is not “is this ticket tool secure.” It is “does this paragraph contain a field that should never leave this tab.”
Rules match a shape and a check digit. They do not read the sentence.
Rule-based redaction is a narrow job. A regular expression finds a candidate. A validator drops hits that fail a public check. A priority list resolves overlaps. The scanner does not know that “Jordan Lee” is a person or that “leave it with the concierge on Oak Avenue” is an address. It knows whether eleven digits look like a mainland China mobile, whether eighteen digits pass a citizen-ID check, whether sixteen digits pass the Luhn test used on cards.
That is a different path from “send the ticket to a model and rewrite the PII.” An outbound model scan hands the source text to another processor. A gateway redactor does the same. A rule scan can stay in the current tab: the input never leaves the browser, and the output is a masked copy. The cost is coverage. IDs outside the list, homemade token prefixes, and digits broken by spaces will miss.
A check digit lowers false positives. It does not prove “this person exists.” An 18-digit Chinese citizen ID computes the last character with GB 11643-1999 / ISO 7064 MOD 11-2: multiply the first 17 digits by the weights 7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2; take the sum modulo 11; map the remainder onto the table 10X98765432. Remainder 2 yields X, which stands for 10. A pass means “this string looks well-formed.” It does not mean a civil registry holds that person. Cards use the Luhn algorithm from ISO/IEC 7812: from the right, double every other digit, subtract 9 when the result is greater than 9, and accept the number only if the total is divisible by 10. Most 16-digit strings you type at random fail Luhn. A rule should not treat them as cards.
Six field types: what a rule can name, and what the mask looks like
The fields a rule can name reliably are the ones with a public format plus a second check. The table follows the order those fields usually appear in outbound text. The mask shapes assume “smart” masking: keep a little of the head or tail, replace the middle with asterisks. Switch to a full mask when even the leftover digits should disappear.
| Type | What the rule roughly accepts | Typical smart mask |
|---|---|---|
| Phone | Mainland 11-digit 1[3-9], + international forms, common North American punctuation |
138****8000, or a country code plus the last four |
| National ID | Checksummed 18-digit citizen IDs, US SSN shape, UK NINO shape | Keep the first three and last four; asterisks in between |
| Bank card | 13–19 digits that pass Luhn; avoid treating a citizen ID as a card | Last four only |
Local part, @, domain |
Keep the first local character; keep the domain | |
| API key | Tokens with a public prefix such as ghp_, AKIA, sk_live_, xoxb- |
Keep the prefix and last four, or Bearer *** |
| IP | Valid IPv4, plus common IPv6 spellings | 203.0.*.*, or the first two IPv6 groups plus asterisks |
Phone rules have to accept both a continuous 11-digit run and numbers broken by spaces, parentheses, or hyphens. A mainland mobile that starts with 1[3-9] and runs 11 digits is a public numbering shape, not an operator’s private table. International numbers are grabbed by the usual E.164 look: a leading + and 7 to 15 digits after it. Strings that are too short, or that sit inside a longer digit run, should be dropped, or order numbers and tracking IDs get treated as phones.
For national IDs, an 18-digit Chinese number also needs a non-zero region code, a birth year in the 1900s or 2000s, and a real calendar month and day. A US Social Security number written AAA-GG-SSSS has official exclusions: area 000, 666, or a leading 9; group 00; serial 0000. A UK National Insurance number is two letters, six digits, and a final A–D, and it excludes prefixes such as BG and GB. Those tests raise confidence that the string looks like an ID. They are not proof that the person exists.
On cards, the payment industry splits “how many digits may appear on a screen” from “how you truncate a stored PAN.” The PCI Security Standards Council, in its note on 8-digit BINs, restates a common display cap that brands still accept: first six and last four. A role that only needs the last four for a callback should see only the last four. Sharing a ticket is not card acquiring. Defaulting to last-four is the safer outbound habit. That is not a PCI certification claim. It only says that pasting all 16 digits into chat already exceeds the usual display limit.
An email mask that hides only the local part and keeps the full domain still tells the recipient which company the person works at. Key rules depend on public prefixes: GitHub classic personal access tokens use ghp_ plus 36 characters; fine-grained tokens use github_pat_. AWS IAM access-key IDs often start with AKIA plus 16 characters. Stripe live secret keys use sk_live_. Those prefixes exist so SDKs and scanners can recognize them—which is also why a rule can catch them. A homemade token with no stable prefix, or a string split as “g h p underscore…”, is ordinary text to the scanner.
IPs are grabbed by dotted-decimal ranges (each octet 0–255) so a version string like 1.2.3 is less likely to match. Demos and canaries should use documentation ranges, not production addresses. RFC 5737 reserves 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 and says they must not appear in public routing. Email demos should use example.com, from the reserved names in RFC 2606, not a real company.
A national ID and a card can claim the same digit run
An 18-digit citizen ID is all digits (the last character may be X). If someone feeds a numeric ID to the card rule, Luhn will occasionally pass. When both rules sit on one paragraph, you need a priority, or the same span is masked twice—or masked into the wrong shape.
A stable order is: national ID before keys, keys before phones, phones before emails, emails before cards, cards before IPs. The reasons are specific. ID first, so an 18-digit identity number is not swallowed as a card. A key prefix is more distinctive than “digits that look like a phone.” Digits inside an email should not be sliced again by the phone rule. IP is the widest net, so it runs last and is less likely to eat version strings or dotted numbers in an order ID. On overlap, keep the higher-priority hit, or the longer one.
If you turn “National ID” off and leave “Bank card” on, the opposite should happen: that digit run may be treated as a card. That is expected when you debug a rule. It is not the default share policy. Default is all six types on, then a human pass for names and addresses the rules will not touch.
Do not demo with a real customer, coworker, or your own ID, card, or key. For phones, use a published test shape. For cards, use a documented test PAN such as 4111111111111111. If you must exercise an ID checksum, invent an impossible birth date, compute the last character yourself, and discard the string when you are done.
Asterisks are not anonymisation, and they are not finished pseudonymisation
The GDPR draws a hard line that masking does not cross. Recital 26 says the regulation does not apply to anonymous information: information that does not relate to an identified or identifiable natural person, or personal data rendered anonymous so the person is no longer identifiable. It also says you must consider all means reasonably likely to be used to identify someone, including those the controller or a third party might use. Article 4(5) defines pseudonymisation as processing personal data so it can no longer be attributed to a specific person without additional information, and that additional information must be kept separately under technical and organisational measures. The UK ICO is blunt: pseudonymised data remains personal data. Recital 26 says so. Asterisks in the middle of a number are not named in the statute as a completed control.
Smart masking leaves a checkable tail on purpose: last four of a phone, last four of a card, the email domain, the key prefix. If the ticket also has a name, a street, or an internal customer ID, those four digits are often enough to push the person from “identifiable” back to “identified.” That is, at best, a step toward pseudonymisation. It is not anonymisation. A full mask replaces the hit with the same number of asterisks, which removes one join. It still leaves length, position, and the surrounding sentence. The sentence may still say “please call the account holder back” or “ID scan is in the attachment.”
So “we ran the rules” cannot be written as “this paragraph can enter a public knowledge base” or “this satisfies a certification.” The tool page does not claim GDPR or other compliance marks. The accurate sentence is: known shapes were replaced with a mask; unknown shapes were not touched; whether a specific person is still identifiable is a judgment you make from context.
What the rules miss is often the sentence that causes the incident
A miss list is more useful than a hit list. First: direct identifiers with no stable digit shape—given names, street addresses, employers, clinical notes, a child’s school. There is no public “national name table” a regex can query, and cloud name-taggers still mislabel ordinary words. Second: rewritten secrets: “one three eight zero zero one three eight zero zero zero,” full-width digits, a particle or a zero-width character inserted in the middle, a screenshot instead of text. A regex sees the current code-point sequence. It does not hear the number a person spoke.
Third: secrets with no public prefix. A database URL, a three-part JWT, a homemade token=, a session cookie from chat or an internal app—none of those sit on the short ghp_ / AKIA list. Fourth: attachments and rich text: a Word header, a hidden spreadsheet column, a phone in a mail signature, a layer inside a PDF. Rules only scan the plain text you pasted into the box. Fifth: semantic secrets: an unpublished contract amount, a vulnerability write-up, a complaint in the customer’s own words. Those are not PII shapes. Forwarding them still causes harm.
There is also the “hit, but the wrong hit.” Order numbers, parcel IDs, and desk extensions sometimes look like phones. A document version 10.20.30.40 looks like IPv4. Check digits and “not a digit on either side” filters remove some of those. They do not remove all of them. That is why a result pane should name hit types and counts, not only return a starred paragraph. You are checking whether the type is right, not whether there are enough asterisks.
Check it here: a canary in the box, then a Network search
“Local redaction, nothing uploaded” cannot prove itself as a slogan. Four things you can see in one sitting: which types were named, whether the mask shape is right, whether a sentence you meant to leave alone is still there, and whether the source text left as business data.
Build a canary that contains no real identity. For a North American phone, use a fiction-reserved form such as 202-555-0100. For a mainland mobile shape, 13800138000 is a published dummy used in ads and docs—do not swap in your own number. Email: canary@example.com. IP: 203.0.113.10. Card: 4111111111111111. Key: a disposable token with a public prefix, for example ghp_ plus 36 characters you invent and then treat as burned. Do not use anyone’s real national ID. If you need to exercise a checksum, pick an impossible birth date (1 January 1900), compute the last character, and label the paragraph “fictional.”
Embed the canary in an ordinary ticket: “User canary@example.com cannot sign in. Call back 202-555-0100 or 13800138000. Source IP 203.0.113.10. Test card 4111111111111111. Token ghp_…. Ship to 123 Main Street, Springfield.” After the run, email, phones, IP, card, and token should appear in the hit counts and become masks as in the table. “123 Main Street, Springfield” should survive unchanged. That is the rule boundary, not a bug. If the street is also masked, you are not on a pure rule set, or the rules were widened, and you should inspect false positives separately.
Then open DevTools Network, enable Preserve log, and search for unique canary strings: 13800138000, canary@example.com, or the full fake token. They should not appear on an XHR or Fetch request line, query, or body, and they should not appear in analytics query or body either. A static script filename that contains “privacy” or “redact” is expected. Source text leaving as a business field is a fail.
- Write a ticket from a fictional phone, an example.com email, an RFC 5737 address, a test PAN, and a prefixed fake token. Leave one street address in plain English on purpose.
- After the run, check hit types: the five number-or-account fields should be named; the street should still be in the result.
- Search Network for the canary source. Any business request that hits is the input leaving this tab.
The proof is narrow. In this one run, known shapes became masks, the address sentence was left alone, and the source text did not leave this tab as an observed HTTP field. It does not prove an extension never read the box. It does not prove a real ticket will not miss. After you change browsers or toggle a rule, run the canary again.
The shortest sentence you can send a coworker: rules first catch formatted fields; names and streets are a human pass; leftover tails plus context can still identify a person; a whole secret should not be “washed” by redaction and then dropped into a channel—change how you send it.
Practice the boundary on a redaction page that opens with no account
If you want a page that puts type toggles and hit counts in the open, start from MakePwd Privacy Cleaner’s Data Redaction mode. It opens with no account and no sign-in. Scan and mask run in the current tab. Per the product notes, source text is not sent as a request and is not written to analytics. The six checkable types are the ones above: phone, national ID, bank card, email, API key, and IP. Smart masking is the default; you can switch to a full mask. One paste is capped at 512 KB. The page states the limits in plain language: it cannot recognize every ID format, it cannot prove the text meets a compliance regime, and important outbound mail still needs a human pass.
Practice only with canaries. After a run, look at three places at once: the hit-type counts, whether the street in the result was left alone, and whether Network contains the source. Counts answer “did it name the right types.” The street answers “where does the rule stop.” Network answers “did it upload.” When all three pass, you can tell a coworker: I masked these types, I know the address is still there, and I searched the canary on the wire.
Tracking parameters on a URL are a separate job. If the ticket also pasted a full URL that still has utm_source or fbclid, strip the query by key first, then handle numbers in the body. The steps are in What tracking data you send when you paste a UTM link into chat. If after redaction you still have a secret that must arrive intact, send it once with Burn-Link and keep the key in the URL # fragment. For a whole file, encrypt it locally in File Encryption Box to .lock / .enc (one file, at most 5 GB) and then use a drive or mail. None of those steps requires an account.
FAQ
After the asterisks, is this still personal data?
Usually yes. GDPR Recital 26 puts only anonymous information outside the regulation: data that does not relate to an identified or identifiable person. Article 4(5) defines pseudonymisation as processing that still needs separately held additional information to attribute the record. A phone that keeps the last four digits, or an email that keeps the domain, plus ticket context, can still be joined back. Rule-based masking at best moves toward pseudonymisation. It is not anonymisation.
Can rule-based redaction replace a human review?
No. Rules match shapes and check digits, not meaning. Names, street addresses, spoken digits, screenshots, and rewritten tokens can slip through. Recheck important outbound text yourself. The tool page does not claim GDPR or other compliance certification.
Does redaction upload the source text?
Per the product notes, scan and mask run in the current tab. Source text is not sent as a request body and is not written to analytics. You can search Network for a fictional canary to check this one run. That does not prove an extension never read the box.
How should I send a secret that redaction cannot finish?
Use rules for scattered phones and ID numbers. For a whole passphrase, unpublished material, or a key that must arrive intact, send it once with Burn-Link and keep the key in the URL # fragment. For a whole file, encrypt it locally in File Encryption Box to .lock or .enc and then use mail or a drive.
Three things to remember before the next share
First: paste is copy. The ticket, the chat, the monitor, and the export each keep a row. Editing the current page does not reclaim text that already left. Second: rules only catch formatted, checkable fields. Names, streets, spoken digits, and homemade tokens are a human pass, and leftover tails plus context can still identify a person. Third: check three places—hit types, the sentence you meant to leave, and a Network search for the canary.
If the next question is whether a full URL’s query should travel with the share, read What tracking data you send when you paste a UTM link into chat. If you need to prove plaintext never left this tab as business data, read How to verify browser encryption: prove plaintext never left. This note only draws a line you can write into a conclusion: what rule-based redaction can do to a ticket body, and what you must not claim it did.