firstpartysimulator.org is a domain the Electronic Frontier Foundation runs for its Cover Your Tracks test. Partway through the test the browser is sent to firstpartysimulator.net, then there, then back to coveryourtracks.eff.org, because the test needs several different "ordinary websites" to see whether a tracker can follow you between them. If one of those hops hangs, the test never finishes, and nothing on screen says why.
We learned that from our own test runner, which had been reporting the hang as "the test was still running".
What is firstpartysimulator.org for?
Cover Your Tracks, formerly Panopticlick, checks two things: how unique your fingerprint is, and whether your browser stops trackers. The second half cannot be measured on one site. A tracker is only a tracker if it recognises you on a second site, so the test plays both roles itself.
The EFF publishes the source, and its example configuration names every domain. Three are first-party stand-ins, in this order: coveryourtracks.eff.org, firstpartysimulator.net and firstpartysimulator.org. Three are the third parties embedded in each of them: trackersimulator.org as an ad server, eviltracker.net as a tracker and do-not-tracker.org, a tracker that publishes a Do Not Track policy. The route that walks the chain is called /kcarter:
coveryourtracks.eff.org/kcarter
-> firstpartysimulator.net/kcarter
-> firstpartysimulator.org/kcarter
-> firstpartysimulator.org/kcarter?try2=true
-> coveryourtracks.eff.org/results
Each page loads the three trackers. At the end the test counts how many loads of each tracker got through, and a tracker that got through on every page saw you on every site.
The fourth step loads the last first-party page a second time. The comment in the source says why: a second load is needed because of a change in how Privacy Badger checks for a site's Do Not Track policy, and it links the Privacy Badger issue that describes it.
Every profile is drawn from one real computer, not from separate listsIn Mosaic: Machines that exist. GPU, screen, CPU and fonts from one real device. 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.
How it works: Machines that exist
The address in our timeout message
Mosaic has a detection-test runner that opens public detectors inside a real profile and reads their verdicts. Cover Your Tracks is one of them. Its landing page runs nothing until you press "Test your browser", so the row has a start block that clicks the button by its visible label, then waits.
For a long time that wait was a fixed sleep, actionSettleMs: 75000, sitting under a comment that recorded the test had "finished inside 110s on this connection". The budget was known to be short on the day it was written, and the row came back unread — the test was still running when the page was read.
The repair was to poll for the result instead of sleeping: start.actionReady, a condition checked until it is true, with the old figure turned into a deadline. With it the row went to pass — 18.28 bits of entropy, fingerprint unique, ready at 34 seconds.
On the run after that change, the new timeout diagnostic printed where the tab actually was:
the tab is at https://firstpartysimulator.org/kcarter?try2=true (loading, visible, 0 chars)
That is the fourth hop of the chain, the second Privacy Badger load, and the domain was serving nothing. "Still running" had been hiding a stalled navigation to another host for as long as the row had existed. A longer sleep would never have fixed it, and a pass on another run would not have explained it.
The ready check matched prose first
The first actionReady we wrote looked for the words "bits of identifying information" with no number. It fired at 42 seconds against the results page's own "How to read your report" section, text the page draws before any measurement lands. Requiring a number before "bits" fixed it, and it is the same pattern the extractor already used to read the score. The ready check and the extractor read one fact the same way.
By our own count, that is the fifth time our code has matched a word in a detector's prose instead of its verdict. The randomized fingerprint post covers what the 18.28 bits mean for a profile. The wider habit of running a stock browser as the control next to a profile is in automating fingerprint tests.
If your own test hangs there
Check what can stop a request to firstpartysimulator.org or firstpartysimulator.net. A content blocker, a DNS filter or a proxy can refuse either one, or the EFF's server may be slow at that moment. Open the domain on its own in a new tab: if it does not load there, the test was never going to finish. A detector that hangs is a different problem from one that answers badly, which we wrote up separately in a fingerprint demo that will not load.
