FreePolicyTools · Original research

Before You Click Submit: A Privacy-Request Form Sent Our Test Email to HubSpot

4captured email POSTs
10privacy routes inspected
13limited-coverage observations
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.

Dealroom privacy-request form containing a synthetic email in the new-document replication

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.

Dealroom form before the explicit refusal, showing its cookie notice and synthetic fields

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.

Pilot scope: ten routes inspected, six with field entry and four without a measured field-entry sequence

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.

Walmart privacy-request route showing the residence-selection stage

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.

Adobe's initial privacy-contact step containing synthetic identity fields

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.