# Why Mosaic profiles never claim Edge

> Our Edge profiles sent either a full build in the User-Agent or an empty Sec-CH-UA-Bitness client hint. No real Edge sends either, so we refuse Edge.

Source: https://mosaicbrowser.com/blog/why-not-edge

## Why Mosaic profiles never claim Edge

Our Edge profiles sent either a full build in the User-Agent or an empty Sec-CH-UA-Bitness client hint. No real Edge sends either, so we refuse Edge.

![Chrome versus Edge, each name in its own tile: One switch, two shapes, and Edge could not have both](https://mosaicbrowser.com/covers/why-not-edge.webp)

An Edge profile on our engine could have a correct User-Agent or a correct set of client hints, never both. Without one flag its User-Agent carried the full build number, which no Edge sends. With that flag, `Sec-CH-UA-Bitness` came back empty, which no browser sends. Each is a User-Agent and client hints mismatch a site can read in one request, so Mosaic profiles claim Chrome and asking for Edge is refused.

## The report that started it

Pixelscan marked one Windows profile "Your Browser Fingerprint is inconsistent", with its browser card red and reading `Edge 153.0.8010.37 on Windows`. A second run of the same report read `Edge 153.0.0.0`. One profile, two runs, two browsers: the shape of every bug report that arrives as "sometimes".

We launched the same Edge profile twice and read the headers off a local server:

```
without --user-agent   UA  Edg/153.0.8010.37   Sec-CH-UA-Bitness "64"
with    --user-agent   UA  Edg/153.0.0.0       Sec-CH-UA-Bitness ""

```

Neither row is a real browser. Chromium browsers now reduce the User-Agent to the major version followed by zeros, so an Edge User-Agent never carries the build number `8010.37`. And an empty bitness beside a filled-in `Sec-CH-UA-Arch` is what Chromium sends when it has been handed a User-Agent string it did not build itself and refuses to vouch for the high-entropy hints. So the two choices were a wrong User-Agent or a wrong bitness.

## Why it changed between runs

Mosaic passed `--user-agent` only when a profile's string differed from the engine's own, and it learned the engine's own string from an in-memory cache that is empty every time the app starts. The first profile launched in a session went out without the flag. Every later launch had it. One profile, three launches after a restart:

```
launch 1   Edg/153.0.8010.37
launch 2   Edg/153.0.0.0
launch 3   Edg/153.0.0.0

```

A profile that presents two identities is worse than either one, because a site that has seen it twice holds both. The cache half of this story, and how it affected Chrome profiles too, is told in [one profile wore two identities](https://mosaicbrowser.com/blog/user-agent-launch-order).

Mosaic is a desktop app

Email yourself the link and open it on your computer.

[How it works: Machines that exist](https://mosaicbrowser.com/features/real-fingerprints)

## One switch meaning two things

The root cause sat in our engine patch. `--fingerprint-brand-version` is the only place the engine gets the version for the client-hint lists, and those need the full build, `153.0.8010.37`. Sending the full build is what let FingerprintJS name the browser correctly. But the same value was also pasted, unchanged, onto the end of the User-Agent as the Edge suffix, and that part needs `153.0.0.0`.

The patch already knew the reduced form. It carried `kEdgeUAVersion = "153.0.0.0"` beside `kEdgeDefaultVersion = "153.0.8010.37"`, and used the reduced one only when the switch was absent. We have to send the switch for the hints, so we always took the other path.

Chrome profiles never showed any of this, because Chrome has no suffix. The engine builds a Chrome profile's User-Agent byte for byte from the platform it claims, with no `--user-agent` at all. Three cold launches of a fresh Windows Chrome profile: the User-Agent matched the stored string every time, and `Sec-CH-UA-Bitness` read `"64"` every time.

## What we changed

**Edge is refused.** Before this, 14% of Windows profiles were drawn as Edge. Now none are, and a request that names Edge gets a `400` that quotes both measurements, not a terse list of allowed values. The same refusal sits under the app, the REST API and MCP, because a rule enforced at one door is enforced nowhere. A build check, `check:brand`, holds it from three sides: the generator draws only browsers the engine can be, the shared entry point refuses anything else by name, and the patch that would let Edge back must carry the reduction.

**The patch is fixed for a later engine.** A function now cuts a build number down to `major.0.0.0` before it reaches the suffix, so one switch can feed both shapes. Edge comes back only when an engine built from that patch has been measured sending both right.

**A 500 became a 400.** The first version of the refusal threw a plain error from the fingerprint generator, and the API reported it as an internal error. A sentence written for the caller is a `400`, so both error classes now come from one small module that imports nothing.

![Creating a profile in Mosaic: a checked proxy, and the hardware and locale drawn to match its exit](https://mosaicbrowser.com/shots/profile-editor.png)
*Every profile is drawn as Chrome, at the engine's real version*

## What a claimed browser has to survive

The general rule is the reason we built [our own Chromium](https://mosaicbrowser.com/blog/why-we-built-our-own-chromium) in the first place: every value a page reads has to agree with every other value, from every place it can be read. A brand is a claim in at least four places: the User-Agent, the low-entropy client hints, the full version list and the bitness. Our engine can make all four agree for Chrome. For Edge it could make three, which is a contradiction, and a contradiction is worse than a common answer.

So every profile is drawn as a Chrome, from [hardware records of real machines](https://mosaicbrowser.com/features/real-fingerprints), at the version the engine really is. What a site can read from a browser, and why it adds up to a [browser fingerprint](https://mosaicbrowser.com/glossary/browser-fingerprint), is the background to all of this.

## Questions

### Can I make an Edge profile in Mosaic?

No. Every profile claims Chrome. Asking for Edge by name, in the app, the REST API or MCP, is refused with a 400 that says why, rather than quietly turned into Chrome.

### What is wrong with an Edge User-Agent that carries a full build number?

Under User-Agent reduction, Chromium browsers write the major version and then zeros, so Edge sends Edg/153.0.0.0. A User-Agent reading Edg/153.0.8010.37 matches no Edge release, and a site that compares it against the client hints sees two different browsers.

### Why would Sec-CH-UA-Bitness come back empty?

When Chromium is given a User-Agent string by the --user-agent switch, it stops vouching for the high-entropy client hints it can no longer derive, so bitness and several others come back empty. A real browser never sends an empty bitness beside a filled-in architecture.

### Will Edge come back?

Only after a built engine is measured sending a reduced Edge User-Agent and full client hints together. A patch for it is written; the refusal stays until the measurement says otherwise.

## Related

[A fingerprint that depended on launch order](https://mosaicbrowser.com/blog/user-agent-launch-order): Chrome's --user-agent flag left Sec-CH-UA-Bitness empty, and a cache empty at every app start decided when we sent it. One profile wore two identities.

[Why we built our own Chromium instead of injecting JavaScript](https://mosaicbrowser.com/blog/why-we-built-our-own-chromium): Mosaic changes fingerprint values in C++ inside its own engine. Three measured differences between Chrome and plain Chromium explain why that matters.

[Machines that exist: fingerprints drawn from real hardware](https://mosaicbrowser.com/features/real-fingerprints): Mosaic draws each profile's GPU, screen, CPU, memory and fonts from one real device, so the parts of a fingerprint agree with each other and with the host.

[Browser fingerprint: what a site can read about your machine](https://mosaicbrowser.com/glossary/browser-fingerprint): A browser fingerprint is the set of values a site reads about your browser and computer, which together recognize you without cookies. What goes into one.









## Mosaic, on your own computer

The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number.

Mosaic is a desktop app

Email yourself the link and open it on your computer.
