FreePolicyTools · Original research

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

6captured email POSTs

10privacy routes inspected

7fresh-context follow-up visits

Explore the research

FreePolicyTools Research · 14 October 2026 · Original case study, pilot findings and validated capture follow-up

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 first reproduced the observation with four different synthetic addresses in a shared profile, including after rejecting analytics cookies. A follow-up with a validated capture proxy reproduced it twice more in fresh browser contexts, once after rejection. That makes six exact-email POSTs across the original study and follow-up, all with HTTP 200 responses.

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 in the original study

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.

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. The follow-up adds two fresh contexts, with an untouched notice and explicit rejection respectively, but does not establish a general failure of cookie rejection or a randomized causal comparison.

The original 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.

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.

Why the original collector required repair

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.

The original worker and departure controls exposed 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.

Those original gaps do not make the four captured email POSTs disappear. They prevented negative conclusions from those traces. We subsequently repaired and validated the tested capture mechanisms as described below. A purposive, incomplete-workflow pilot still cannot establish a market-wide rate or rank websites as safe.

Follow-up: repairing the blind spots and repeating the visits

We moved to a dedicated temporary Chrome research browser, leaving the original browser profile untouched. Each visit received a new browser context with zero initial cookies. Browser-context network events ran alongside a loopback-only HTTPS capture proxy that continued recording after a page disappeared. This changed the research environment; the new visits are reported separately from the original study.

The receiver-side fixture tested both HTTP and HTTPS. It generated ordinary query/POST requests, base64 and SHA-256 values, dedicated-worker and service-worker POSTs, a cross-site frame confirmed as a separate iframe target, and departure beacons on navigation and tab closure. The proxy captured all 17 probe requests in each final fixture round, matching the receiver's paths and payload bytes. The context-level event collector captured 15: it still missed both departure beacons. We therefore retained the proxy as the departure evidence source.

The negative-control marker never appeared in either capture. Cookies, localStorage and sessionStorage seeded in one context were absent in a new context. These checks repair the specific demonstrated blind spots; they do not test every possible encoding, browser API or transport.

Eight field-entry visits were retained, with the first Plaid visit treated as exploratory because its cookie banner obscured the fields in the saved screenshot. Seven visits are included; the replacement Plaid visit follows saved No choices for functional and advertising collection and verified disappearance of the preferences dialog. We typed synthetic markers character by character, blurred the fields, observed at least 60 seconds after the last action, and kept recording during navigation away and for five seconds afterward. No request was submitted.

The two additional Dealroom requests were observed at 14:54:37 and 14:54:38 Nairobi on 14 October 2026. Browser events independently matched both emails, while the proxy paired each POST with its own HTTP 200 response. Their bodies contained the new markers, not just a reused address from the earlier profile. No synthetic name marker was detected in the follow-up captures.

Exact original screenshot from the fresh-context refusal visit. Required LinkedIn remains blank. The screenshot documents interface state; the request evidence is in the follow-up dataset.

Exact original screenshot. Validated cross-site-frame capture made this previously excluded field-entry sequence measurable. Request category, country and account/service choices were left incomplete.

The stronger wording for the five non-positive follow-up visits is “no detectable transmission in the tested entry and departure windows,” rather than an outcome unresolved solely because of the old worker/frame/departure collector gaps. SGS could not be repeated because access was denied; Walmart and Expedia presented bot barriers, and Spotify retained its account-based route. Their missing measurements remain unresolved.

All outcomes are bounded by incomplete workflows and the detector. Unknown transformations, application-layer encryption, untested transports, later steps, and provider-side processing remain outside scope. Headless Chrome and a local HTTPS proxy may also change site behavior. This is not a statement that the five sites collect nothing or that their full request journeys are leak-free.

Methods and exclusions

The original phase took place on 14 October 2026 using the built-in browser; the same-day follow-up used isolated Chrome contexts and the validated local proxy. 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 original 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 original 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 original analysis searches the synthetic email, its specified URL/base64 encodings, and its SHA-256 representation in available request data. The follow-up adds SHA-1/MD5, available Brotli bodies, the unique email local part, and raw synthetic-name checks. 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. The follow-up repairs capture using isolated sessions and an independent proxy; it makes no geographic comparison.

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 six exact-marker transmissions across two phases, documented collector failures, and a validated repair followed by seven fresh-context visits. We do not claim to be the first to discover this behavior or to have uncovered a new vulnerability.

The planned 40-company comparison remains incomplete. We first narrowed the article when the instrument failed controls, then repaired the demonstrated gaps and repeated accessible pilot surfaces. That extension strengthens the pilot; it does not supply a representative sample or a market-wide prevalence estimate.

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. The follow-up repairs the tested worker, frame, departure and isolation gaps and finds no detectable email transmission in five new visits. It covers specific incomplete workflows and time windows, not every transport, transformation, later step or downstream use.

Can this be reproduced?

The public follow-up package contains both phases' sanitized results, the capture amendment, fixtures, collector, request evidence 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 and a validated capture follow-up. 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.