Before You Click Submit: A Privacy-Request Form Sent Our Test Email to HubSpot
Explore the research
FreePolicyTools Research · 14 October 2026 · Original case study and pilot findings
We entered an invented email address into Dealroom's privacy-request form and left the request unsubmitted. The browser nevertheless sent that exact address to an external HubSpot endpoint. We reproduced the observation with four different synthetic addresses, including after rejecting analytics cookies and on a newly loaded page in the same browser profile.
The destination was an email-checking endpoint. The evidence supports a narrow conclusion: typing into this privacy-request form could trigger external email validation before the request was submitted. It does not establish advertising use, a sale of data, an unlawful disclosure, or successful deletion of anyone's information.
This distinction matters. A privacy request can pass through a software supplier for an ordinary operational reason, while still crossing a boundary the person filling out the form may not notice. The Submit button is not necessarily the first point at which a form communicates an entered value to a server.
Original research screenshot. The address and names are invented test markers. The LinkedIn field remains empty, and no request was submitted. The screenshot shows the interface; the network records below provide the transmission evidence.
What we directly observed
The inspected Dealroom privacy-request page offered ways to request access, correction, removal, and other privacy actions. Its embedded form loaded HubSpot's form library. During four measured field-entry sequences, the browser issued a POST to:
https://forms.hsforms.com/emailcheck/v1/json-ext
The body contained the synthetic email address entered in that sequence. All four requests had an observed HTTP 200 response. The address was not merely present in a local text box or inferred from a loaded script: it appeared in the outbound request body.
The connection used HTTPS. Seeing the value inside browser instrumentation does not mean it travelled over the internet without transport encryption. Likewise, HTTP 200 does not tell us that the address passed validation or was retained in a customer record.
| Observation | Request time, Nairobi (UTC+03:00) | Browser condition | Observed result |
|---|---|---|---|
| R1 | 14:08:08 | Cookie notice left untouched; request type initially unselected | Exact synthetic email in POST; HTTP 200 |
| R2 | 14:12:50 | Removal request type selected; same document and profile | New synthetic email in POST; HTTP 200 |
| R3 | 14:15:12 | Reject clicked on analytics-cookie notice | New synthetic email in POST; HTTP 200 |
| R4 | 14:20:06 | Newly loaded document, same profile and previous rejection; no cookie notice visible | New synthetic email in POST; HTTP 200 |
These are four repetitions within one browser profile on one day, not four independent people or four fresh-browser experiments. R4 gives us a new-document replication, while retaining the shared-profile limitation.
For the final replication, the request body was:
fpt-dealroom-r4-new-document-20261014@example.com
We used addresses under an illustrative domain maintained by IANA. No customer's real email address, identity document, phone number, or account credentials were entered into the privacy forms.
Why we classify this as apparent validation
Three pieces of evidence point toward form validation: the page loaded a HubSpot form library, the observed destination's path identified an email-check operation, and HubSpot's own forms documentation describes checks on addresses entered in its default email field. Those checks include address formatting, blocked domains, and domain records.
That is a supported interpretation, rather than a view into HubSpot's internal processing. We did not obtain server logs, inspect downstream storage, or determine whether any other system later used the value.
The finding therefore should not be described as an advertising leak simply because HubSpot also provides marketing software. The function of the observed endpoint matters. Nor did we observe the selected deletion-request category being included in this particular email-check payload: the verified payload was the email address.
The result still illustrates a useful privacy distinction. A person can abandon an unsubmitted form after an entered identifier has already been sent for validation. In that situation, not clicking Submit prevents the final action but does not undo an earlier network request.
What rejecting cookies did—and did not—demonstrate
The page's small notice described analytics cookies and offered acceptance or rejection. In R3 we clicked Reject before entering a new email marker. The email-check request still appeared. In R4 the notice was absent on the newly loaded page, and another new marker was sent.
An earlier original screenshot preserves the notice and its Reject control. The refusal observation is separately timestamped in the dataset.
This does not establish that the site ignored the scope of its cookie choice. Refusing analytics cookies and disabling all functional form processing are different operations. An email-validation request may be part of the form's operation; deciding its legal basis or whether its disclosure is adequate would require a separate assessment.
Our demonstrated result is that the tested rejection action did not prevent this particular email-check transmission. We did not establish a general failure of cookie rejection, and we did not run a controlled comparison of independent consenting and refusing visitors.
The wider pilot: ten company routes, six with field entry
We began with a purposive sample of ten official privacy routes discovered through recorded searches. This was a feasibility pilot, not a random sample of major websites. Some routes were public forms; others led to an account, a residence gate, or an inaccessible page.
Six company surfaces received synthetic field entry. Across those surfaces we retained 13 limited-coverage observations, with four additional exploratory rounds excluded. Excluded rounds remain in the downloadable data rather than disappearing from the research record.
| Company | What we could examine | Result within this study's scope |
|---|---|---|
| Dealroom | Public privacy form; four included observations | Exact synthetic email POST observed in all four repetitions, to apparent HubSpot validation |
| Plaid | Public identity fields; deletion option inspected; three included observations | No marker detected in the available stream; overall disclosure outcome indeterminate |
| SGS | Public privacy form; one included observation after verified cookie refusal | No marker detected in the available stream; earlier overlay-present rounds excluded |
| Cvent | Requester fields on a controller-oriented form; two included observations | No marker detected in the available stream; authorization and data-subject details left incomplete |
| Secret Shopper | Public request form; two included observations | No marker detected in the available stream; identity verification and CAPTCHA left incomplete |
| Adobe | First identity step on a general privacy-question route; one included observation | No marker detected in the available stream; validation-code action and later steps not tested |
| Cisco | Public form embedded from a different site | Inspected, but field entry excluded because cross-site child-target coverage was unvalidated |
| Walmart | Residence-selection stage | No synthetic field entry; we did not claim a supported residency to proceed |
| Expedia | Selected Singapore help-center privacy article | Human/bot challenge; no field entry or challenge solving |
| Spotify | Official account-closure route | Redirected to login; no login fields completed |
The rows without a detected marker are not passes, certifications, or findings that those companies collect nothing. They describe what was observable in these specific incomplete workflows. A count of loaded domains would not repair the missing visibility.
For example, the Walmart request route displayed residence choices for Canada, Mexico, and the United States. We stopped at that stage instead of using a VPN location as a substitute for a statement about residency. The Spotify closure route led to a login screen; we did not test an authenticated account.
Original screenshot of the observed gate. Its presence does not establish whether other request routes are available or whether the company must accept a particular request.
Adobe's privacy contact page linked to a form with Qualtrics branding. The measured page requested identifying fields and offered to send a validation code. We entered test fields but did not trigger that code. This was the beginning of a generic privacy inquiry, not a completed erasure procedure.
How we tested the collector before trusting the results
Our local fixture sent known synthetic values to a server under our control. This provided a receipt log independent of the browser's network stream. A successful control required the expected value to be visible in the expected request, not merely a script-loading event.
| Control | What the browser collector showed |
|---|---|
| Email in a query string | Observed |
| Email in a JSON POST body | Observed |
| Base64-encoded marker | Observed |
| SHA-256 marker | Observed |
| Cross-origin POST initiated by the main document | Observed |
| Cross-origin iframe on the same site, using another local port | Observed |
| Masked payload and an untransmitted negative-control field | Consistent with the known fixture behavior |
| Worker-generated POST | Server received it; browser stream missed it |
| Departure beacon | Server received it; browser stream missed it |
| Fresh-session isolation | Failed: tabs shared cookies |
The worker and departure controls are decisive limitations. They show why an empty network trace cannot certify that no data left the browser. Cross-site out-of-process frame coverage also remained unvalidated, and the available child-target attachment command was unsupported.
These gaps do not make the four captured email POSTs disappear. Positive evidence of an exact marker has a different evidentiary status from absence in an incomplete stream. They do prevent us from calculating a defensible market-wide leak rate or ranking other forms as safe.
Methods and exclusions
Research took place on 14 October 2026 using the built-in browser. We observed the selected pages, preserved screenshots and interface text, and instrumented available network requests. After loading-related problems, replacement runs began capture on a stable document. No browser cookies were cleared to manufacture a fresh-visitor claim.
The field-entry action used normal locator-based fill operations followed by Tab to leave the email field. It did not simulate a full human typing cadence. The first sequential-typing attempt on Plaid timed out, and that trace was excluded because its capture was also truncated. Later rounds used distinct markers and documented conditions.
Each included observation retained at least 60 seconds after the field-entry action; actual windows ranged from about one minute to more than two minutes. We did not compare request volumes as if these unequal windows were identical. Earlier completion records were checkpoints; the analysis uses the final record for each company and round.
Three early SGS rounds had a cookie modal covering the form during automation-based field entry. We retained them as exploratory records and excluded them from the included observations. The replacement followed an explicit rejection and verified disappearance of that dialog. Selecting a removal category on a form did not submit it, and required declarations remained unchecked.
The analysis searches the synthetic email, its specified URL/base64 encodings, and its SHA-256 representation in available request data. Where binary POST entries were present, it also inspected decodable gzip/zlib payloads. It does not cover every possible transformation, application-layer encryption, fragmented value, or inaccessible browser target. Names visible in screenshots are synthetic context; the primary matched identifier is the email marker.
No experimental Proton route was activated. An independent public-IP check in the browser was blocked, so no verified country comparison is claimed. Local network inventory alone cannot prove the browser's public exit location. Changing VPN locations would not have repaired the collector's visibility gaps.
We did not submit deletion requests, solve CAPTCHAs, log into customer accounts, test actual deletion, or contact providers. This article is based on public interfaces and our own synthetic-marker evidence. The dataset retains exclusions and distinguishes apparent form validation from unmeasured downstream uses.
What this adds to existing research
Pre-submission collection is already a documented research topic. The 2022 Leaky Forms study examined email and password collection at scale. Earlier SOUPS research on deletion and opt-out choices investigated how people find and exercise privacy controls.
Our contribution is narrower: a dated, reproducible privacy-form example, with four exact-marker transmissions and an explicit account of the collector's failures. We do not claim to be the first to discover this behavior or to have uncovered a new vulnerability.
The planned 40-company comparison was not completed. Expanding an instrument with demonstrated false negatives would have produced a larger-looking dataset without stronger negative evidence. We therefore retained the approved research question and narrowed the article to the positive case we could substantiate.
Practical implications
For people filling out forms, the useful lesson is that leaving a form unsubmitted does not necessarily mean entered information stayed on the device. A form may communicate with a validation service while you are still deciding what to do. A cookie refusal is not a universal off switch for all form communication.
For website operators, privacy-request pages deserve their own data-flow review. Map each recipient and the event that triggers a request. Where feasible, validate syntax locally and defer remote checks until they are needed. Distinguish necessary processors from advertising and analytics, and explain material processing at the point where information is requested. These are design considerations; this study does not establish a legal duty or a violation.
For researchers, test what your collector misses before publishing a clean bill of health. A receiver-side fixture, unique markers, recorded failures, and an explicit boundary between observations and inferences provide more useful evidence than a generic tracker count.
Questions readers may ask
Did HubSpot receive a real person's information?
We used only synthetic addresses and names. The browser issued the exact-address POSTs and observed HTTP 200 responses. We did not inspect internal server handling or retention.
Was the address sent to advertisers?
We did not establish that. The observed destination and vendor documentation support an apparent form-validation classification. A provider's other products do not prove the purpose of this request.
Does this mean rejecting cookies failed?
It means the observed rejection did not prevent the specific validation request in our test. The notice concerned analytics cookies, and the study does not establish that all functional form requests were supposed to stop.
Were the other tested forms leak-free?
That conclusion is unavailable. Our controls demonstrated missed worker and departure traffic, and the workflows were incomplete. An absent detectable marker is not proof of absent collection.
Can this be reproduced?
The public package contains the protocol, sample, sanitized request evidence, results, fixture, and analysis code. Reproduction requires a collector whose capabilities and gaps are documented, new synthetic markers, and current inspection of the public form. Later versions of the sites may behave differently.
Data, citation and research status
Use the accompanying JSON dataset, CSV results, transmission records, and fixture-validation report to inspect the calculations. The original full captures are retained privately because request URLs and session records may contain identifiers unrelated to the synthetic markers. Public evidence omits those values.
Suggested citation: FreePolicyTools. Before You Click Submit: A Privacy-Request Form Sent Our Test Email to HubSpot. Research conducted 14 October 2026. Add the article's actual canonical URL when published; none is assigned in this local draft.
This is an original case-study manuscript supported by a completed feasibility pilot. It is not the originally proposed full prevalence study, an independent compliance audit, or a no-leak certification. Providers have not been contacted, and the manuscript has not been published externally.