Data Center Activists Cannot Collect Resident Data On Trust-Me Security

BadPD source-check, May 26, 2026: Brockovich Data Center Reporting is not just publishing an anti-data-center map. It is asking residents to hand over names, phone numbers, addresses, email addresses, location details, issue narratives, data-center owner details, and optional photos. That turns a campaign site into a resident-data intake system. Once you build one of those, you do not get to run on vibes.

BadPD is pro-American compute buildout and pro-resident accountability at the same time. We have been clear about the data-center standard: build the compute, but do not dump cheap-public-water risk, free-grid-ride shortcuts, hidden ratepayer costs, diesel backup problems, noise, land-use surprises, and subsidy math onto residents. That standard applies to data-center companies. It also applies to the activists asking those same residents to become sources.

This is the harder point: the same people demanding receipts from data centers now have to produce receipts for their own data stewardship. If you ask the public to report powerful companies and local infrastructure fights, you have to protect the people who trust you. You cannot demand transparency from hyperscalers while giving residents a “trust me” intake form.

BadPD is not claiming a confirmed breach. We did not access private submissions, attempt login, probe hidden systems, bypass any control, test the form with private data, or do anything that would cross from source-checking into intrusion. This article is based on public pages, public headers, user-supplied SSL checker screenshots, and passive review. The allegation is narrower and still serious: the visible controls and disclosures do not match the sensitivity of the data being requested.

The Intake Problem

The live Brockovich Data Center Reporting page frames itself as a community awareness initiative for AI data centers and invites residents to report issues. The visible form asks for a full name, phone number, address, email address, data-center location, owner or company if known, whether the facility is operating or under construction, a description of the issue, other concerns, and optional photos. The page says up to five images can be selected and describes common image formats and a per-photo size limit.

That is not a lightweight tip box. It is a dossier pipeline. A resident reporting a data-center dispute could be identifying their home, their neighborhood, their family exposure, a nearby employer, a local government conflict, or a company they fear. A photo can add faces, license plates, house numbers, GPS metadata, timestamps, camera model data, and route patterns. A narrative can identify medical concerns, water pressure problems, business losses, disability accommodations, property disputes, workplace retaliation risk, or political conflict inside a small town.

That does not mean the form should never exist. Residents need ways to document harm. It means the form has to be treated like sensitive intake, not a newsletter signup. The more righteous the mission sounds, the more important the controls become, because people lower their guard when they think they are helping a cause.

What The Site Says

The Brockovich privacy page says the project collects information people voluntarily submit, including contact details, report details, photos, and technical logs. It also warns that photos can include metadata such as GPS, time, date, and device information. That warning is important and accurate. It is also an admission that photo upload is not harmless.

The policy says names, addresses, and contact details are treated as private by default and says the site does not sell personal information. Good. But “not selling” is not the same thing as a complete stewardship plan. The policy also discusses service providers, analytics, storage, and sharing. The terms say submitted content may be used to document, map, report, advocate, educate, and contact the submitter. They also say submissions may be shared with journalists, researchers, advocacy partners, legal advisors, or public agencies, while the site says it will not publicly display a person’s name, email, phone, or home address without express permission.

That language may be normal for advocacy work, but it means residents need clear answers before submitting: Who sees the raw intake? Who has administrator access? Is multi-factor authentication required? Are photos stripped of metadata before storage or only before publication? Are files scanned? Are sensitive fields encrypted at rest? How long does the third-party processor keep them? How does a resident delete a submission? What happens if a volunteer leaves the project? What happens if a journalist or advocacy partner receives a copy?

The privacy page also names a third-party form processor. The page source reviewed by BadPD pointed the report form to a Formspree endpoint. That does not automatically mean anything malicious. Formspree is a real form service. But processor naming has to be exact when a site asks for resident contact details and photos. If the public privacy page names one processor while the live form sends to another, the fix is simple: update the notice, publish the data flow, and tell residents where their information is actually going.

The SSL Receipt

The user-supplied SSL checker screenshots reviewed by BadPD showed the domain brockovichdatacenter.com flagged as not trusted, with missing chain certificate indicators and a missing root indicator. The screenshot also showed a GoDaddy-issued certificate for the domain and its www host, valid from April 23, 2026, to November 7, 2026.

BadPD then did a passive follow-up check on May 26. A local OpenSSL check to the same host verified successfully, negotiated TLS 1.2, and identified a GoDaddy certificate for brockovichdatacenter.com. That matters because the public should not turn one checker screenshot into an overbroad claim that every browser everywhere sees the certificate as broken. We are not publishing that claim.

The actual accountability point is worse for the operator in a different way: a public checker can show trust-chain warnings while the site is asking for personal data, and the operator still has to care. If one client validates and another says chain components are missing, the right response is not to shrug. It is to fix chain delivery, retest across common SSL checkers, and publish a short note that the certificate chain has been corrected.

When a resident is being asked to upload photos and contact information, the burden is on the collector to eliminate confusing trust signals. A technical person can reconcile SSL chain behavior, root-store differences, intermediate-certificate delivery, and checker quirks. Ordinary residents should not have to.

The Bigger Header Problem

BadPD also checked the public response headers. On May 26, the HTTPS homepage returned HTTP/1.1 200 OK. The plain HTTP version also returned HTTP/1.1 200 OK rather than redirecting to HTTPS. The observed HTTPS response did not include Strict-Transport-Security, and the response did not show common hardening headers such as a content security policy or X-Content-Type-Options.

None of that is a breach by itself. But it is exactly the kind of basic posture gap that should be cleaned up before collecting sensitive public complaints. If HTTP remains live, a user or link can reach the non-secure version. If HSTS is absent, browsers are not being told to remember HTTPS for the domain after a valid secure visit. If common response headers are absent, the site has not taken simple steps that many security programs treat as baseline hygiene.

Again, this is not a call for illegal testing. The site’s terms prohibit unauthorized probing, and BadPD agrees: do not attack the site, do not spam the form, do not try to access submissions, and do not treat a public-interest concern as permission to break the law. The point is that the public-facing evidence is already enough to demand fixes.

Why This Matters To Residents

People who report infrastructure harms are often in vulnerable positions. They may live near the project. They may work for a contractor or supplier. They may be arguing with a local board. They may have a child with health needs, a well-water issue, a property-value concern, or a landlord problem. They may be using a personal phone, a personal email account, or a photo taken from their driveway. If their information is mishandled, the fallout lands on them.

That is why “we are the good side” is not a security control. Activist projects are not exempt from breach risk, volunteer account compromise, email forwarding mistakes, misconfigured form dashboards, overbroad sharing, weak retention, or accidental publication. In some cases, activist sites carry more risk because they are built quickly, staffed loosely, and trusted emotionally.

BadPD is not interested in a protected-class conspiracy lane, and this is not an identity attack on activists. This is role accountability. If you collect resident reports, you have a duty. If you collect photos, you have a duty. If you ask people to name local companies and locations, you have a duty. If you plan to share submissions with journalists, researchers, advocacy partners, legal advisors, or public agencies, you have a duty to tell people the real path before they submit.

The Data-Center Frame Still Matters

This does not let data-center developers off the hook. BadPD still wants the same receipts from data-center projects: bring-your-own-power plans, grid-support commitments, transparent interconnection costs, no stranded ratepayer costs, water-source disclosures, waterless or closed-loop cooling where feasible, leak detection, coolant details, backup generation emissions, noise controls, local benefit math, tax-incentive clawbacks, and documented resident protections.

But the resident-protection principle cuts both ways. If a data-center company should not push risk onto the public, an anti-data-center campaign should not push privacy risk onto residents. The mission cannot be “protect communities” on the front end and “figure out security later” on the back end.

That is especially true because this campaign is not collecting abstract survey responses. It is collecting potential evidence in fights involving energy, water, property, industry, local government, and powerful companies. Some of those reports could become news leads. Some could become legal leads. Some could involve personal health, minors, disability, or private property. The intake system has to be built for the most sensitive plausible submission, not the least sensitive one.

Confirmed, Alleged, Pending, Disputed

Confirmed: the Brockovich Data Center Reporting site is public and invites residents to report AI data-center concerns. The public form asks for contact details, address/location information, issue narratives, data-center information, and optional photos. The privacy page acknowledges collection of contact information, report details, photos, technical logs, and photo metadata risk. The terms describe a license to use submissions and possible sharing with journalists, researchers, advocacy groups, legal advisors, or public agencies. The reviewed page source pointed the form to a third-party processor. Public response headers observed by BadPD showed HTTP available without redirect and did not show HSTS.

User-supplied and independently contextualized: SSL checker screenshots supplied to BadPD showed brockovichdatacenter.com flagged as not trusted with missing chain and root indicators. BadPD’s passive OpenSSL check on May 26 verified the certificate successfully from this environment, so the responsible statement is not “the certificate is universally broken.” The responsible statement is that public trust signals are inconsistent and the operator should resolve them before asking residents for sensitive material.

Pending: who controls the form dashboard, whether MFA is enforced, whether raw submissions are encrypted beyond the third-party provider’s standard controls, whether photos are stripped of metadata before storage or only before public use, whether uploaded files are scanned, whether submissions are copied to email inboxes, whether there is a deletion workflow, whether the processor named in the privacy page matches the live form path, whether HSTS and forced HTTPS have been enabled since this review, and whether any independent security review exists.

Not confirmed: BadPD has no evidence of an actual breach, no evidence that resident submissions have leaked, and no evidence that a hostile actor accessed private reports. Anyone claiming a leak needs receipts. Anyone with proof of a real exposure should preserve evidence lawfully and report it through responsible channels, not dump private resident data online.

What Brockovich Data Center Reporting Should Do Now

First, pause or clearly warn before new personal submissions until the basics are fixed. That does not require shutting down the map or deleting public education content. It means the sensitive intake function should meet a higher standard than a static awareness page.

Second, force HTTP to HTTPS and then enable HSTS once the certificate chain is clean and verified across common public checkers. The site should not leave residents guessing whether they reached the secure version. It should also publish a short changelog: date fixed, checker results, and what was changed.

Third, align the privacy notice with the actual data flow. If the form is handled by Formspree, say Formspree. If it has changed to another processor, say that. If submissions are emailed, say who receives them by role, not just by sentiment. If files are stored in a provider dashboard, say how long. If copies go to journalists or advocacy partners, explain when and with what redactions.

Fourth, reduce collection. A full name, phone number, address, email address, issue narrative, and photos should not all be the default path for every report. Give residents a low-risk tip option. Make phone and exact address optional unless needed. Allow anonymous or pseudonymous first contact. Ask for sensitive details only when a human follow-up actually requires them.

Fifth, treat photos like evidence. Strip EXIF metadata before long-term storage or tell users plainly that the project cannot do that yet. Warn people not to upload photos with faces, children, license plates, house numbers, medical details, private property interiors, or employer-identifying material unless they understand the risk. Publish whether original files are retained after any redaction.

Sixth, publish the access controls. Residents do not need a diagram that helps attackers, but they deserve to know that administrator accounts use MFA, that access is limited by role, that volunteers cannot casually browse raw submissions, that old accounts are removed, that exports are controlled, and that there is an incident plan if the form account or email inbox is compromised.

Seventh, add a responsible contact path for security concerns. A simple security contact, a security.txt file, or a clearly monitored mailbox would give people a lawful place to report public issues without touching private data. The terms already tell people not to probe. Fine. Then provide a safe reporting lane for what can be seen without probing.

BadPD Bottom Line

Brockovich Data Center Reporting is demanding accountability from an industry that absolutely needs accountability. That does not excuse the campaign from its own obligations. The moral weight of a cause does not secure a form. The righteousness of a message does not strip metadata from photos. The existence of bad data-center practices does not make resident privacy an afterthought.

If activists want to collect evidence from communities, they need to build like stewards, not like marketers. If they cannot do that immediately, they should stop collecting sensitive resident data until they can. Put the map online. Publish research. Criticize bad water deals. Expose free-grid-ride shortcuts. Demand bring-your-own-power. But do not ask residents to hand over names, phones, addresses, narratives, and photos through an intake path that still has basic unanswered security questions.

Data-center companies need power and water receipts. Activists collecting resident data need privacy and security receipts. BadPD demands both.

Source Trail

• Brockovich Data Center Reporting homepage and resident report form (Accessed May 26, 2026) – Primary site receipt for the AI data-center map, resident reporting pitch, fields requesting contact details, address/location details, data-center details, issue narrative, and optional photo uploads.
• Brockovich Data Center Reporting privacy policy (Effective January 1, 2026; last updated April 2026; accessed May 26, 2026) – Primary policy receipt describing collection of names, email addresses, phone numbers, mailing addresses, issue details, photos, technical logs, analytics, service providers, retention, and photo metadata concerns.
• Brockovich Data Center Reporting terms of service (Effective January 1, 2026; last updated April 2026; accessed May 26, 2026) – Primary terms receipt describing eligibility, user responsibilities, license to use submissions, possible sharing with journalists/researchers/advocacy groups, and prohibition on unauthorized probing.
• Fix I.T. Phill: SSL and privacy basics before submitting data-center complaint details (May 26, 2026) – Technical companion receipt preserving the SSLChecker screenshots, OpenSSL follow-up, HSTS/security-header guidance, upload metadata concerns, and non-exploit safety framing.
• FTC: Protecting Personal Information, A Guide for Business (Accessed May 26, 2026) – Federal baseline guidance: know what data is collected, keep only what is needed, protect it, dispose of what is no longer needed, and plan for incidents.
• FTC: Start With Security, A Guide for Business (Accessed May 26, 2026) – Federal guidance on security-by-design, access controls, secure transmission, service-provider oversight, and vulnerability response.
• OWASP: Transport Layer Security Cheat Sheet (Accessed May 26, 2026) – Application-security baseline for TLS configuration, certificate trust, protocol choices, and secure transport controls.
• OWASP: HTTP Strict Transport Security Cheat Sheet (Accessed May 26, 2026) – Security-header guidance for enforcing HTTPS after a domain has a stable, valid TLS configuration.
• OWASP: Secure Headers Project (Accessed May 26, 2026) – Reference lane for common response headers such as HSTS, content security policy, and content-type protections.
• OWASP: File Upload Cheat Sheet (Accessed May 26, 2026) – Reference lane for safer handling of user-submitted photos and other upload surfaces.
• Formspree security information (Accessed May 26, 2026) – Third-party form service security receipt; relevant because the reviewed page source pointed the report form to a Formspree action endpoint.
• Formspree help: file uploads (Accessed May 26, 2026) – Third-party upload receipt for how uploaded files may be handled in the form workflow.