What happens to a profile left unused
I kept a folder of thirty profiles for most of a year and thought about it as inventory. Aged accounts, exported cleanly, named properly, sitting there for whenever I needed them.
When I finally worked through all thirty, nineteen were unusable. Nothing dramatic happened on the way in. The accounts inside had been locked, emptied or quietly limited months earlier, and I had never noticed because I had never looked.
The folder was immaculate right up to the moment I checked what was in it.
Four clocks you are not watching
A saved profile stays exactly as you left it. That is the entire reason it exists, and it is also the whole problem. The profile holds still while at least four things around it keep moving, and not one of them sends you a notification.
Two of those clocks live inside the profile. The other two live on the far side of the connection, where you have no visibility at all.
The engine gets old in public
Chromium ships a major version about every four weeks. Six months in storage is six or seven versions the rest of the world walked through without you.
The reflex in this category is to worry about being rare. Unusual screen size, unusual font set, a canvas hash that hardly anyone shares. A dormant profile fails the same test from the other end. It is not exotic, it is stale, and the bucket of people still running a build from last November is a small bucket to be standing in.
Nobody has to be clever about this. Sorting traffic by reported version is close to free, and it produces an answer without anyone needing to suspect you first.
There is a second half that has nothing to do with detection. An engine that has not been patched since you last opened it carries published holes, and some of those are exactly the ones that leak the real machine underneath your spoofing. The mechanics of what an update actually moves are their own subject and I have written them up separately. What matters here is that the gap widens whether or not you ever launch the tool.
The session inside it is usually finished
This is the clock people are most surprised by.
Cookies carry an expiry. A lot of the ones that keep you signed in are set for thirty or ninety days, so half a year clears them without anybody deciding anything.
The expiry is the gentle version. The record that actually authorises you lives on the server, and the site can drop it whenever it wants. A password change in the account drops it. A security event drops it. Routine housekeeping drops it on a schedule nobody publishes.
So a profile can hold a cookie that has not expired and is attached to nothing. Your browser thinks it has a session. The other end has no memory of it.
Refresh tokens age worse, because most implementations rotate them. A token that has missed every rotation for six months is not going to be honoured.
Why a profile scrubbed empty reads as strange rather than clean is a separate piece. This is the opposite failure: storage that survived perfectly while the far end quietly stopped agreeing with it.
The address moved on without asking
I can speak to this one from the selling side, because the addresses are mine.
A mobile line does not hold a single address. It takes a new one on most reconnects, which is normal carrier behaviour and half the reason people pay for mobile lines instead of something static.
The bigger issue is churn. A port that a customer stops paying for gets cleaned and handed to the next customer, usually inside a few days. The SIM goes back in the pool at around ten dollars a month and somebody else’s traffic starts leaving through it. Whatever your dormant profile still points at is not yours and has not been for a while.
Why a browser and a connection disagreeing draws the confident responses rather than the gentle ones is covered in its own piece on matching a profile to its network. The version that catches people out here is quieter than a country mismatch. The exit is still in the right city. It is a different network, a different registered organisation, a different block, and the account has never once appeared from there in its life.
The baseline moved too
The three clocks above describe the profile decaying. The fourth is the thing doing the judging, and it changed shape while you were away.
Login flows get rebuilt. Consent screens appear. A device check runs that was not running last year. The set of things a page measures on first load only ever grows.
And the model doing the scoring gets retrained on this year’s traffic, not on traffic from the month you last logged in. I have written before about why a fresh profile behaves differently on its second session, and this is that argument stretched over half a year. A profile is always measured against a moving baseline. A dormant one is measured against a baseline it has never encountered.
The silence is a signal by itself
Here is the part I think gets underrated, and it has nothing to do with fingerprints.
An account that goes quiet for eight months and then comes back is a pattern in its own right. It needs no leaking resolver and no bad canvas hash to be worth a second look.
Every platform of any size already tracks this for its own reasons. Dormant, churned, resurrected: those are product metrics, they sit in somebody’s growth dashboard, and a returning user belongs to a named cohort long before anyone on the abuse side goes near the record.
Then consider what a long silence followed by sudden activity usually means in a market where aged accounts are bought and sold. An account that did nothing for most of a year and wakes up doing new things has the shape of an account that changed hands.
That is the inference worth worrying about, well ahead of the version number. It also explains something that confused me for a long time, which is why a technically clean return session still gets challenged. The challenge is aimed at the account. It wants evidence that the same person is still holding it, and the browser is a side question at that point.
The update question has no clean answer
So do you bring a dormant profile up to date before using it, or leave it exactly as it was.
Leave it and the profile stays consistent with its own history, which is the whole purpose of consistency, but it turns up on an engine hardly anyone runs.
Update it and it rejoins the crowd, while changing its user agent, its client hints, its JavaScript surface and a pile of rendering details in the same session where a returning account was already interesting. Two events land together: the return, and the transformation.
I do not think there is a correct answer available. There is an order of operations, and a judgement about what the account is worth.
The order I use
Start with the value question, which is not technical. If the account is close to worthless, just open it. A throwaway is the cheapest information you will ever buy and it should be spent before anything else.
Check whether the account’s history already contains a version step. An account carried through updates before is one where another update is in character. An account that has reported the same build for its entire life is a stranger case, and moving it is a larger jump than the calendar makes it look.
Then separate the events instead of stacking them. For me that means updating first on a quiet day with the profile never touching the platform, then sorting and verifying the network, then one deliberately boring session where I ask the account for nothing, then a week of leaving it alone.
The argument against my order is decent and I cannot beat it. Plenty of operators update last, reasoning that the first session back should resemble the last session that worked as closely as possible, and let the engine catch up once the account has settled. I think they have the risks the wrong way round. I have nothing that proves it.
What the audit changed
I now open everything I intend to keep on a rhythm, and delete the rest instead of curating it.
A profile I genuinely will not open for six months is a profile I should not be storing. Nineteen tidy folders full of dead accounts is what careful storage without periodic checking produces, and I had been calling it a reserve.
Which is the position I will defend. A profile you have not touched in six months is one you are hoping still works. Calling it an asset you are preserving gives it a status it has not earned, because hoping is the one state you cannot inspect from the outside.
What I cannot see
None of this is measured. I have no window into anybody’s risk engine and neither does the vendor selling you the browser.
The dormancy argument in particular is inference. I am reasoning from how platforms describe their own users across to what their abuse teams probably do with the same buckets, and those are not necessarily the same team or the same data.
The practical obstacle to testing it is that a dormant profile changes four things the moment it wakes up. Version, session, network, behaviour. I have never managed to move one without the other three arriving alongside it, so when a return session goes badly I cannot tell you which clock ran out.
Full reviews and the tools I actually keep installed are at Anti-Detect Review.
Get new guides and videos first — join the Telegram channel.