Security by architecture, not policy alone
Oyster is a class action settlement app for the U.S. and Canada: automated discovery and breach watch, queue every claim you qualify for, autofill official administrator forms in the app (finish on the real site in about 30 seconds), and store reusable details in a local on-device vault—with optional on-device Gmail discovery for notices, receipts, and proof—no subscription, no cut of your settlement, no bank account required for that path.
The security story is structural: local vault, inspectable code, and evidence you can download—not just comforting words. Deep dive on email: Gmail discovery.
Unlike a "trust us in the fine print" product, the design goal is to reduce what must sit on servers: sensitive claim state stays on your hardware first.
Quick answer
Is Oyster safe to use for class action claim filing?
Oyster is designed as a local-first utility: claim discovery outputs, claim IDs, and reusable filing details are not supposed to live in a centralized Oyster claims database for bulk resale. The model combines local storage, an open repository for inspection, and public materials that reference a 100/100 MobSF static score on a shipped Android build. That is architecture plus published evidence—it is not a guarantee about every possible attack or future build.
Where does Oyster store my claim IDs and filing details?
In the product story on this site, the Secrets Vault and similar filing state are built to stay on your device with AES-256-oriented platform storage—not mirrored into a shared claim warehouse operated by Oyster for advertising-style profiling.
What verifiable security evidence is published for the Oyster app?
A public MobSF summary on this site (first 3 pages of the scan for app-release, grade A, 100/100 score, Oyster 1.0.3, com.anonymous.claimlynative, April 25, 2026), the public GitHub repository for source review, and build/hash context in that excerpt. A score applies to the analyzed binary and date—always read the excerpt and your own threat model.
We can't leak what we don't centralize
100% local vault storage
Your Secrets Vault is designed to live exclusively on your device and to use AES-256 platform-backed secure storage rather than a centralized Oyster claims database.
No central claim vault
Oyster's architecture is designed so that your claim IDs, inbox-derived discovery outputs, and reusable filing details are not mirrored into a shared backend datastore.
Open-source receipts
Transparency is part of the security model. The code is public on GitHub so the community can inspect whether the local-only and privacy claims match the actual implementation.
How funding model ties to security
If revenue requires profiling users, the product will eventually want more data. Oyster is open source and built as a public utility so the incentives line up with claimants, not advertisers.
Open source, not pay-to-file
The app is open source. Filing is free; paying is never required. Optional contributions help pay for development and infrastructure instead of selling user data or taking a cut of your check.
Resource-backed discovery
Deeper discovery tooling, inbox scanning, and breach-style checks have real cost. Voluntary funding helps build those features without making personal claim data the product.
No cut of the settlement
The public product story is that you keep the full settlement—no 40% middleman take just because the filing path was hard.
Local-only matching
The logic that identifies a likely settlement is designed to run on your phone rather than in a cloud that profiles every user.
Technical evidence
MobSF score
MobSF static analysis of app-release_2_.apk: App Security Score 100/100 (LOW RISK), grade A. Scanned as Oyster 1.0.3 (com.anonymous.claimlynative) on April 25, 2026. Public site shows the first 3 pages only.
View MobSF summary (3 pages)Open-source audit path
The public repository is available for direct inspection and code review.
View GitHub repositoryBuild integrity
Web repo revision (public): 531fa17. MobSF file hashes are listed inside the report PDF (SHA-256 of the scanned APK).
Mobile security posture
The architecture is aimed at MASVS-style goals such as protecting local storage, minimizing token exposure, and reducing sensitive server-side state.
Public summary — first 3 pages only. Full report is not published on this site.
Loading MobSF preview…
Oyster is built as a public utility: the architecture is supposed to keep core claim data local, the code is open to inspection, and the mission is for claimants to keep the full settlement—not fund us with a cut of the check.
Why contribute?
Oyster is an open-source utility, not a data-mining corporation. It is not designed to monetize your shopping habits, your inbox, or a percentage of your check. You never have to pay to file.
Keeping discovery current
Open source means the architecture is public. When people choose to contribute, that helps pay for work on local discovery and breach-style matching—never a fee to file.
No payout cut
The model is: no cut of your settlement. Voluntary gifts do not turn into a “finder’s fee” on your check.
How the utility stays private
Local inbox "grepping"
When Gmail is connected locally, Oyster's discovery flow is designed to search for settlement phrases, notices, and claim signals inside the device context rather than uploading raw email content to Oyster servers.
Anonymous breach queries
Breach-style checks are described in the privacy policy as using anonymized hashing so the raw email address is not exposed as a plaintext query during discovery.
The "no-phone-home" policy
Once a claim signal is found, the useful output is meant to stay in your local vault. The app is not supposed to report your discovered claims back to Oyster as a monetizable event stream.
Set it and forget it. Automated. Private. Free.
Automated class action filing—official forms in-app, set it and forget it, open source, $0.
Claims tied to your email
Check what Oyster can already match and what may be worth watching.