For years, the conversation around web tracking revolved around cookies.
Third-party cookies were blocked. Browsers introduced storage partitioning. Fingerprinting became a bigger privacy concern. Developers adjusted analytics and advertising systems around a web where the old tracking model was becoming harder to use.
But there is another identifier a browser cannot simply delete.
Your email address.
When you type an email address into a login form, newsletter signup, account-registration page, or another website form, you are giving the site something that can identify you far more directly than a random browser cookie.
That is where identity resolution enters the picture.
The term can sound harmless. Websites have always needed to recognize their users. A customer account should remain connected to its purchases. A SaaS application needs to know which account is signed in.
The privacy concern begins when information supplied to one website is quietly passed to a third party that can connect it with information collected somewhere else.
That changes the problem from:
“Can this browser be recognized?”
to:
“Can this person be recognized across different places?”
That distinction is becoming increasingly important for developers and website owners.
Quick Summary
- Identity resolution can connect information about a person across different interactions, devices, or websites.
- A common technique described by WebKit involves third-party infrastructure receiving identifiers such as an email address during login or signup flows.
- The third party can associate that identifier with a persistent tracking ID and build an identity graph from information collected over time.
- This is different from ordinary first-party personalization, where a website uses information to serve the user within its own service.
- Removing third-party cookies does not automatically eliminate every form of cross-site tracking.
- Developers should know which third-party services receive data from forms, authentication flows, analytics scripts, and other user interactions.
- Privacy-conscious implementation starts with data minimization, clear purpose, controlled sharing, and careful third-party auditing.
The browser is not the only place an identity can live
Consider a normal login.
You visit a website and enter:
Email: alex@example.com
Password: ********The website needs the email address. It uses it to locate your account.
Nothing unusual is happening.
Now imagine that another company has infrastructure embedded somewhere in that login or signup flow. That company receives the email address, sends it to its own servers, and associates it with an identifier that can be recognized later.
The identifier no longer depends entirely on the browser’s cookie jar.
It is connected to information the user supplied directly.
That is the important shift.
A browser can restrict storage mechanisms. A website cannot make an email address stop being an email address.
This is why identity resolution is particularly interesting in the post-cookie era.
What identity resolution actually means
At a high level, identity resolution is the process of determining that different pieces of information belong to the same person or entity.
Businesses have legitimate reasons to do this.
A customer might use the same account on a website, mobile application, and support portal. The company may need to connect those interactions so the customer sees the correct account information.
That is not automatically problematic.
The privacy issue becomes much more complicated when a third party performs this matching across different websites or services.
A simplified version might look like this:
Website A
↓
user@example.com
↓
Identity service
↓
Tracking ID A
Website B
↓
user@example.com
↓
Identity service
↓
Tracking ID BThe third party knows that the two interactions relate to the same underlying identifier.
Over time, more information can be associated with that identity.
The result can become an identity graph: a collection of relationships connecting identifiers, devices, websites, interactions, and other data points.
The important word here is relationship.
The privacy concern isn’t simply that a company has an email address.
It is that the email address can become the bridge connecting activity that a user may have expected to remain separate.
Why an email address is different from a cookie
A cookie is usually an identifier created for a browser context.
An email address is something a person may use for years.
That makes it much harder to treat as a disposable tracking token.
Imagine deleting a cookie every few months.
Now imagine changing your primary email address every few months.
Those are very different things.
An email address can also connect activity across devices. You might visit a website on your laptop, sign in on your phone, and later use the same account on a tablet.
The browser environments are different.
The identity may not be.
That is one reason email-based identity matching can be powerful.
It shifts the identifier from the browser toward the person.
Cookies are not the whole privacy story
It is tempting to think of web tracking as a technology ladder:
Third-party cookies
↓
Cookies blocked
↓
Problem solvedThe web is more complicated than that.
Tracking can involve browser storage, URL parameters, redirects, fingerprinting, network requests, embedded resources, and other mechanisms.
Identity resolution adds another category because the identifier can come directly from information supplied by the user.
That does not make every use of an email address tracking.
A website obviously needs an email address if the user creates an account.
The question is what happens after the website receives it.
Does it remain within the service that requested it?
Is it sent to another company?
Why is that company receiving it?
Does that company need it to provide the requested feature?
How long does it retain the information?
Can the information be connected to activity elsewhere?
Those are much more useful questions than simply asking whether a website uses cookies.
First-party personalization is not the same thing
This distinction matters for developers.
Suppose an online store knows that you bought a pair of running shoes from that store.
It can use information from your account to show relevant order history, recommendations, or account settings.
That is first-party use.
The company already knows who you are within its own service.
The privacy concern described by WebKit is different: a third-party identity resolver can sit between multiple first-party datasets and perform matching across them.
That creates a capability that an individual website may not have by itself.
So “identity resolution” should not be treated as a synonym for “user accounts.”
User accounts are a normal part of the web.
The important question is who gets to connect the identity, across which contexts, and for what purpose.
Where developers should look for this
You do not need to understand every advertising technology on the internet to begin auditing a website.
Start with the places where users provide identity-related information.
Login and registration
Look at what happens when a user submits an email address during authentication.
Check the network requests.
Which domains receive data?
Is the information sent only to your authentication system, or does another service receive it as well?
Newsletter forms
Newsletter forms deserve the same attention.
A user may believe they are providing an email address so a particular publication can send them emails.
That does not automatically mean they expect the address to be sent to unrelated tracking infrastructure.
Lead-generation forms
Marketing forms can contain considerably more information than an email address:
Name
Email
Company
Job title
Phone
Company size
LocationThe more fields a form collects, the more important the data flow becomes.
Analytics and advertising scripts
Third-party JavaScript can make network requests without the user seeing those requests directly.
Look at the browser’s Network panel.
Do not only inspect the scripts you intentionally installed. Check what those scripts load and where data travels.
Authentication providers
Third-party login systems have legitimate uses and can improve account security and convenience.
But developers should still understand the data exchange.
“It’s an authentication provider” is not a substitute for knowing what information is transmitted and why.
A practical privacy audit
You can approach this as a normal engineering task.
Pick one important form on your website.
Open the browser’s developer tools.
Submit the form using test data.
Then inspect the network activity.
You are looking for questions such as:
Which requests happen when the form is submitted?
Which domains receive information?
Is the email address present in request data?
Does another script make a request immediately after submission?
Is a user identifier returned?
Does the same third-party service appear on other parts of the site?
You are not trying to prove that a service is malicious.
You are trying to understand your own data flow.
That difference matters.
A third-party service may have a perfectly legitimate technical role. But if your team cannot explain why a user’s identity information is being sent somewhere, that is worth investigating.
Data minimization becomes especially important
A useful privacy principle is simple:
Do not collect or share information merely because you can.
If a service only needs an anonymous event ID to provide analytics, sending a user’s email address may be unnecessary.
If a newsletter provider needs an email address to deliver a newsletter, that does not automatically establish a reason for every other analytics or advertising service to receive it.
Think about the smallest amount of information required for each job.
For example:
Feature: page analytics
Needed:
anonymous event information
Possibly unnecessary:
email address
full name
phone number
account profileThe exact requirements depend on the product and implementation, but the principle is broadly useful.
Less unnecessary data movement means fewer places where identity can be joined with other information.
Consent does not replace good architecture
Consent is important where applicable, but it should not become an excuse for poor data design.
A developer can ask for permission and still send more information than the feature needs.
Privacy is partly a product decision and partly an architecture decision.
If a third-party service never receives an email address in the first place, there is no email address for that service to resolve.
That is stronger than collecting everything and trying to explain it later.
The best privacy controls often happen before the request leaves the website.
What website owners should review now
If you operate a website with login, signup, forms, analytics, or advertising integrations, an identity-resolution review does not need to become a giant compliance project on day one.
Start with an inventory.
Write down:
- Every third-party script
- Every analytics provider
- Every advertising or marketing platform
- Every form-processing service
- Every authentication provider
- Every customer-data integration
- Every domain receiving requests from those services
Then map the data.
User action
↓
Website
↓
Third-party request?
↓
What data is sent?
↓
Why is it needed?
↓
Who receives it?
↓
How long is it retained?That last part is easy to skip.
A data flow is not finished simply because the request succeeded.
You also need to understand what happens to the information afterward.
What developers should avoid
A few implementation habits deserve extra scrutiny.
Passing email addresses into analytics events without a clear need.
An analytics system usually does not need to know the user’s actual email address to tell you that a button was clicked.
Putting personal identifiers into URLs.
URLs can travel through logs, referrers, browser history, analytics systems, and other infrastructure.
Loading third-party scripts everywhere by default.
A script installed for one feature can end up running across the entire site.
Sending complete form objects to multiple services.
A convenient integration can accidentally turn one submission into several copies of the same personal data.
Assuming first-party placement makes a third-party service first party.
Hosting something through your own domain or embedding it into your page does not automatically answer the question of who operates the service or what data it can connect.
Privacy-friendly identity does not mean anonymous websites
There is an important middle ground here.
A website can recognize a logged-in customer without participating in cross-site tracking.
For example, your application might store:
Account ID: 48291and use that identifier internally to retrieve the user’s account.
The user can remain recognized within your service.
That is fundamentally different from giving a third-party identity resolver information that can be matched against activity from unrelated websites.
Privacy does not require every website to forget its users.
It requires websites to be clear about where identity is used, why it is used, and who gets access to it.
The post-cookie era is not an identifier-free web
The decline of third-party cookies did not eliminate the demand for measurement, personalization, attribution, or advertising.
It changed the technical landscape.
That creates an important responsibility for developers.
When one tracking mechanism becomes less effective, replacing it with a less visible mechanism does not automatically make the web more privacy-friendly.
An identifier can move.
It can move from a cookie to a URL.
From a URL to browser characteristics.
From browser characteristics to an account identifier.
From an account identifier to an email address.
The technology changes.
The privacy question remains remarkably consistent:
Can this information be used to connect a person’s activity across contexts without them reasonably understanding or expecting that connection?
That is the question worth asking when evaluating any new tracking architecture.
A better way to think about identity resolution
Identity resolution is not inherently a feature that every website should fear.
Connecting information can be necessary for legitimate products.
The concern begins when identity becomes a hidden bridge between places that users reasonably expect to be separate.
For developers, that makes privacy less about memorizing a list of forbidden technologies and more about understanding data flows.
When someone enters an email address, know where it goes.
When a third-party script runs, know what it can send.
When two datasets are joined, know why they are being joined.
And when a service asks for personal information, ask whether the feature genuinely needs it.
The web may be moving beyond third-party cookies, but it is not moving beyond identifiers.
If anything, the next generation of privacy engineering will depend on understanding identifiers more carefully, not less.
The most useful question for a website owner is therefore not:
“Have we removed third-party cookies?”
It is:
“What can still identify our users, where does that information travel, and who can connect it to something collected somewhere else?”
That is where modern web privacy starts.