Methodology
How OfflistMe prepares reviewable data broker opt-out drafts, the user flow, the legal frameworks it documents, the broker coverage process, update cadence, and explicit limitations. Written for journalists, researchers, and cautious users.
Summary
OfflistMe is a self-service tool that generates pre-filled opt-out requests for 1000+cataloged workflows and lets users send them from their own inbox. We are not an authorized agent; we do not act on users' behalf; and the draft workflow does not upload an ID to a broker through OfflistMe. The request's legal basis depends on the user, provider, jurisdiction, request, and applicable exceptions. Our role is to reduce research and clerical work; actual effort varies by workflow.
End-to-End User Flow
User arrives and selects target brokers
Select the platforms you want to opt out of. Request drafting is local-first: the personal details used in a draft are not sent to OfflistMe as an opt-out profile. Checkout is a separate flow for payment and access records.
Opt-out emails and portal links are generated
For each cataloged workflow in our 1000+ coverage label, we prepare pre-written opt-out request templates that may identify a relevant legal provision (CCPA §1798.105, VCDPA, CPA, GDPR, or another route) and direct self-service opt-out links where recorded.
User receives a sendable request set
Each broker's request arrives as (a) a pre-addressed email the user can send from their own inbox, or (b) a direct deep-link to the broker's self-service opt-out form, pre-populated where the broker's form supports it.
User sends each request
The user, not OfflistMe, sends the email or submits the form. This is a deliberate design choice. It means the request arrives at the broker from the user's own identity, while the details used to compose the opt-out draft remain local and are not sent to OfflistMe as an opt-out profile. Checkout is a separate payment and access flow.
Broker responds directly to the user
A provider may send a confirmation, verification request, or rejection through its own channel, such as an inbox or portal. We do not receive broker responses through the request-drafting flow. Where a complaint or escalation route exists, users can consult the relevant regulator's current instructions; this page is not a legal-escalation service.
Legal Framework
Many templates identify a potential legal basis, but a citation is not a legal conclusion. The user is the requester; a covered controller must evaluate a valid request only when the cited law applies and subject to its scope, verification, exceptions, and response rules. These are representative frameworks we document:
CCPA § 1798.105 (California)
The CCPA provides a deletion right for covered requests, subject to scope, verification, exceptions, and applicable response rules. The statutory right is not a universal rule for every broker or resident.
Primary source ↗California Delete Act (SB 362)
SB 362 created the CPPA's centralized Delete Request and Opt-Out Platform (DROP) for the covered California process. Use the current CPPA instructions for eligibility, matching, timing, and exceptions; DROP is a separate government route, not a universal broker deadline.
Primary source ↗VCDPA (Virginia)
Virginia Consumer Data Protection Act. Covered controllers generally respond within 45 days, with a possible additional 45 days when the statute permits and notice is provided. Our Virginia templates cite the current consumer-rights section, §59.1-577.
Primary source ↗CPA (Colorado)
Colorado Privacy Act. Right to delete and a 45-day response period, with a possible additional 45 days when reasonably necessary and noticed. Our Colorado templates cite CPA §6-1-1306(1)(d).
Primary source ↗GDPR Article 17 (EU/UK)
The GDPR provides an erasure right for covered processing, subject to lawful exceptions. Controllers generally respond without undue delay and normally within one month, with possible extensions and limits; the UK GDPR has its own current guidance.
Primary source ↗Other US state laws
Connecticut, Utah, Texas, Oregon, Montana, Delaware, and other state laws have different definitions, thresholds, response periods, exemptions, and remedies. Check the current statute and regulator guidance for the request at issue.
Why We Are Not an "Authorized Agent"
Under CCPA §1798.135, a consumer may appoint a third party as an "authorized agent" subject to the law and the business's verification process. Service models and document requirements differ, so review the current provider notice rather than inferring how a named service handles every broker.
OfflistMe deliberately does not operate as an authorized agent. Instead, each request is sent by the user directly. The reasons:
- The user controls verification. Sending directly can avoid an agent-authorization step, but the provider may still request matching information or other verification.
- We never handle users' IDs. No government ID upload. No DL scans. No passport photos.
- The user retains direct control. The user keeps the sending record and provider response. Any legal remedy depends on the applicable law and facts; this workflow is not a promise of a claim or outcome.
- We do not store an opt-out profile. Because OfflistMe does not send on the user's behalf, the details used to compose the opt-out draft stay in the browser instead of being received as a service-side request profile. Payment and access records are separate.
For a longer discussion of this design choice, see The 'Authorized Agent' Loophole.
Broker Coverage & Update Cadence
How the broker list is maintained
Our 1000+ catalog entries are assembled from official registries where available, provider research, and review of consumer-facing request routes. The catalog is an editorial workflow index, not a complete census of brokers or proof that a provider currently holds a particular record.
What "1000+ workflows" means
We count a cataloged consumer-facing destination as one workflow. A parent company may operate multiple products or routes, and the count can therefore differ from another service's methodology. A catalog count is not a claim about the number of unique companies, records, or successful removals.
Update cadence
Broker opt-out pages change. Forms break. URLs get redirected. Each catalog record carries a source-check date, route status, and—when available—a next verification date. Our review queues prioritize stale or failed checks; a record is not treated as current merely because its domain or email still exists.
Areas we treat separately
- Credit bureaus (Equifax, Experian, TransUnion). These have specialized consumer-report and privacy processes under federal and state law; a people-search workflow is not a substitute. Related provider routes may be documented separately.
- B2B and marketing-data vendors. Vendors such as ZoomInfo and Apollo.io may use different request formats and product scopes; selected routes are documented separately.
- Government public records. Voter rolls, property records, and court filings are source material rather than ordinary broker listings. We cover ways to address downstream exposure, not a universal method for changing every official record.
- Search engines. Google and Bing have separate result-removal or refresh processes. We document those routes but do not submit them automatically.
How We Handle User Data
The short version: The opt-out drafting flow is designed not to send the draft's name, address, or request contents to OfflistMe as a service-side opt-out profile. Separate payment, access, analytics, operational, and support processing is described in the Privacy Policy. We do not share opt-out requests with brokers on the user's behalf.
- No account required. The tool works without sign-up. Users who do purchase a plan have a minimal billing record (email, payment reference) retained per standard accounting requirements.
- Template generation is client-side where possible. Name/address inputs are processed in-browser when the broker template does not require server-side logic.
- No ID upload in the opt-out drafting flow. OfflistMe does not ask users to upload government ID through this flow. If a specific provider requires ID verification, that verification happens directly between the user and the provider, not through OfflistMe.
- No broker response tracking. Because requests go from the user's own inbox, OfflistMe does not receive broker replies through the request-drafting flow. This means we can't tell you a removal "succeeded"; keep your own sent messages and confirmations.
- Public privacy policy. Full details at offlist.me/privacy.
Known Limitations
We flag these up-front because they affect the decision of whether OfflistMe is right for you.
No automated re-removal
Providers may receive new data, change matching, or republish information from upstream sources. Reappearance timing is not universal. Subscription services may offer monitoring or re-submission under their current plans; OfflistMe does not automatically re-submit, so users must review and send follow-up requests when appropriate.
Cannot guarantee outcomes
No data-removal service can promise that every provider will remove every record. A provider may deny, ignore, or qualify a request; data can also be changed or republished by upstream sources. We prepare the request and identify a possible legal basis; any escalation depends on the applicable law, facts, and responsible regulator or court. Follow the provider's current response window when one is stated; otherwise, set a documented reminder and verify the exact source record before sending a follow-up.
US-optimized, globally usable
Our catalog has broader coverage for US and EU/UK workflows, while other jurisdictions may require more provider- or country-specific review. Canada, Australia, India, and other regions have their own scope, commencement, verification, and exception rules; users may need current local guidance.
Some brokers require direct ID verification
Some providers or request types may require additional identity or record matching directly from the user. OfflistMe's templates direct users to the provider's current verification flow rather than attempting to proxy it.
Effectiveness depends on user action
Because the user sends each request, a user who generates the opt-out set but never actually sends them sees no benefit. This is a trade-off for the privacy-preserving design (us not acting as agent = us not auto-sending). We provide a send-tracker so users can check off each request.
How to Verify Any of This Independently
We encourage journalists and researchers to test claims rather than take them at face value.
- Audit the opt-out templates. We are happy to share the full template set for any broker on request. Email support@offlist.me.
- Test the flow. Use the free tier to inspect the generated email before sending. The draft details remain in your browser and are not sent to OfflistMe as an opt-out profile.
- Check our privacy policy. offlist.me/privacy. Look for what is stored and for how long.
- Check the broker list. offlist.me/directory. Spot-check 10 random brokers against their stated opt-out pages.
- Check the legal citations. Where a template identifies a statute, open the current law and confirm that the citation and its scope fit your request.
Press & Research Inquiries
For journalist interviews, data requests, or methodology questions: support@offlist.me.
For a full press kit (founder bio, logos, screenshots, statistics): see the press page.
We do not pay for placements, do not run affiliate arrangements with reviewers, and do not gate information behind NDAs. Everything on this page is on the record.