Privacy · 9 min read
Privacy Checklist for Text Message Analyzer Tools
What to ask before uploading sensitive conversations to any AI or evidence-analysis product.
The short answer
A message export is one of the most sensitive files a person owns. It can contain children’s names and schools, home addresses, medical facts, financial details, intimate relationship history, and communications with a lawyer — usually all in one file, and usually about people who never agreed to be in it. That makes the privacy terms of any tool you upload to a real question rather than boilerplate. Five things are worth confirming before uploading anything. Where the file is stored and for how long. Who can access it, including staff. Whether it is used to train models, and whether an opt-out exists. What deletion actually does, and how quickly. And whether the tool shares data with third parties or analytics services. A privacy page that answers those specifically is doing its job; one that describes them in general terms is not the same thing as a commitment. Vague promises are not enough. Look for clear data categories, retention rules, security practices, and a contact path for access or deletion requests.
The checklist
Does the tool say whether uploaded messages are used to train models? Can you delete a case and related uploads? Does the tool separate raw uploads from generated reports? Does it support redacted review copies? Does it explain whether analysis is server-side or device-side? Does it name subprocessors or analytics tools? Does it avoid claiming zero-knowledge if the server processes message text?
Textimony position
Textimony treats message exports as case material supplied by the user. The product records an intake checksum, keeps cases account-scoped, asks for participant confirmation when needed, and separates software candidates from reviewer decisions. The privacy policy is intentionally direct about current server-side processing and current architecture, because specific controls create more trust than vague claims.
Privacy questions to answer before upload
A privacy review should happen before any message file is uploaded, not after the analysis is complete. The safest workflow starts by identifying whose messages appear in the file, whether minors or third parties are included, whether health, financial, workplace, or attorney communications appear, and whether the uploader has lawful access to the material. The next question is architectural. If a tool performs server-side analysis, the privacy promise should say so directly. A product can still be useful and careful without claiming that the server never sees message text. The problem is overstatement: phrases like zero-knowledge, end-to-end encrypted analysis, or fully local processing should only be used when the system actually works that way.
Source-linked privacy checklist
Confirm whether uploaded conversations are used to train public or shared models. Check whether raw uploads, normalized message tables, generated reports, and exports are stored separately. Look for a deletion path that covers cases, uploads, reports, and derived analysis artifacts. Identify whether analytics, logging, or support tooling can expose message text or case names. Prefer tools that preserve an owner-controlled original and create redacted review copies for sharing. Record the date, account, case, source filename, and purpose before uploading sensitive material. Avoid uploading messages from people who did not consent unless the uploader has a lawful reason to possess and review them.
How to evaluate Textimony
Evaluate Textimony by the controls it actually provides: account-scoped cases, an intake checksum, participant confirmation, visible run status, candidate-versus-reviewer separation, deletion paths, and clear public language about server-side processing. The public promise matters for trust. Textimony organizes owner-provided material into a reviewable workspace so qualified reviewers can inspect the record faster and with fewer loose files.
Should a text message analyzer promise zero-knowledge privacy?
Only if the architecture genuinely prevents the server from reading message text, which for server-side analysis it does not. Claiming zero-knowledge while decrypting uploads to process them is a marketing claim that will not survive scrutiny. The honest and more useful promise is specific: who can access the data, how long it is retained, whether deletion is real, and a commitment that uploads never feed public model training.
What should I remove before sharing a review copy?
Remove what the recipient does not need: home addresses, account and card numbers, identifying details about children, medical facts unrelated to the dispute, and third parties who have nothing to do with it. Apply all of it to a copy and keep the unredacted original preserved separately, since that is what may be needed to authenticate the record later. Log what you removed and why.
Are generated summaries private evidence?
Yes, and they are easy to treat carelessly because they feel like output rather than evidence. A summary, timeline, or label set is derived directly from the messages and can restate the most sensitive material in the file, sometimes more legibly than the original did. Reports, timelines, labels, exports, and manifests all warrant the same handling, storage, and disclosure care as the uploaded source.
Can privacy settings prove admissibility?
No, they are unrelated questions. Privacy controls govern who can access a file and how it is stored and shared. Admissibility turns on whether the evidence is relevant, authenticated, and not excluded by a rule — none of which a storage setting affects. A well-secured file can be inadmissible, and an insecurely handled one can be admitted. Privilege and disclosure obligations are separate again and need legal advice.
Published by
Textimony. Editorial status: Source-linked informational guide. Updated: 2026-07-10.
Sources
FTC Privacy and Security guidance; FTC guide: Protecting Personal Information