how cloud phone services isolate one user's session from another
cloud phone session isolation is the question nobody asks the sales rep but everybody should. when your session ends, what happens to your data, your accounts, your network history, and your installed apps before the next user logs into that same phone. if the answer is “we wipe it” but you cannot tell what wipe means, you have a problem.
this is not paranoia. it is risk management. you are putting accounts, payment apps, and sometimes personal credentials onto a device. if any trace of that survives into the next tenant’s session, you have leaked data. if the network identity from your session bleeds into theirs, you have leaked operational signal too.
cloudf.one runs a device-per-tenant model with a deterministic factory wipe between users. that combination is a different shape from how most container-based cloud Android services work, and it solves a class of problems those services struggle with.
device-per-tenant vs container-per-tenant
there are two basic patterns in this market.
container-per-tenant is the cheaper, denser option. one physical x86 server hosts many virtualized Android instances. each user gets a container that looks like a phone, but the underlying machine is shared with hundreds or thousands of other users at the same time. between users, the provider stops your container and starts a fresh one for the next user. the underlying host runs continuously. the kernel is shared. the storage layer often deduplicates between containers. the network stack is shared with rules separating tenants.
device-per-tenant is what cloudf.one runs. one physical Samsung handset is assigned to one tenant for the duration of their rental. when the rental ends, the device gets a full factory reset before being assigned to anyone else. it is closer to a hotel room than a hot desk. you check in, you have the whole room, you check out, and the room is fully cleaned before the next guest.
both can work. they have very different failure modes.
what isolation actually has to cover
regardless of which pattern, real isolation has to cover four areas.
storage. anything you wrote to disk during your session has to be gone before the next user touches the device. that includes obvious data like installed apps and saved files, but also less obvious data like browser cache, app private storage, push notification tokens, ADB authorized keys, and Wi-Fi credentials.
network state. your IP, your DNS history, your WebRTC candidates, and any network identity you accumulated during the session. if any of this leaks into the next session, you have given the platform a way to link the two sessions together.
device identity. IMEI, serial number, ad ID, instance ID, build fingerprint. these should either reset or, when the hardware identifier is fixed (like a real IMEI), the rest of the software identifiers should be reset and the device assigned to a fresh persona.
attestation state. SafetyNet, Play Integrity, app-specific attestation tokens. if these survive a tenant change, your account-level signals get crossed with a previous user’s. that is bad for both of you.
why factory reset is the strong primitive
a real factory reset on a Samsung handset is a destructive operation. it wipes the userdata partition, regenerates the encryption keys for that partition, drops all installed apps, clears all app data, removes all Google accounts, clears Wi-Fi credentials, and forces re-enrollment with Google services on next boot. every persistent identifier tied to the userdata partition is gone.
this is the same operation a retail user does when they sell their phone. it is built into Android and audited by Google as part of device certification. you do not have to trust the cloud provider’s custom wipe script. you trust the OS-level wipe primitive that the entire Android ecosystem depends on.
cloudf.one uses this primitive between every tenant. when your rental ends, the device gets a real factory reset. on next boot, it is back to a known clean state and ready for the next user to set it up fresh.
data wipe verification
a factory reset is only useful if you can verify it actually happened. on cloudf.one, three checks are part of the handover.
the device boots into setup wizard, the same screen a brand new phone shows out of the box. that is observable proof that userdata was wiped, because setup wizard only runs on a fresh userdata partition.
the Google account state is empty. if any account is still bound, the wipe failed. this is checked before the device is offered to a new tenant.
the device identifiers that should reset have reset. ad ID is regenerated. instance ID is fresh. app-specific tokens are gone because the apps that issued them are gone.
if any of these checks fail, the device is taken out of rotation and re-wiped or re-imaged before being offered again. that is a different process from “we ran the wipe script and assume it worked”.
network isolation between tenants
storage is half the story. network isolation is the other half.
each cloudf.one phone has its own dedicated SG mobile modem and SIM card. that means your IP for a session is the IP assigned by your modem. when the device is handed off to the next tenant, that tenant either gets a different modem entirely, or gets a fresh PPP session on the same modem, which means a new public IP from the carrier.
between tenants, there is no shared egress path. your network namespace is torn down at session end. the next tenant gets a fresh namespace pointed at a fresh modem session. nothing from your network history can cross. for the deeper view of how this prevents leakage during a single session, see how cloudf.one prevents IP leakage.
contrast that with container-per-tenant services that share a single uplink across many containers. even with strict firewall rules, side channels like timing, packet shaping, and shared NAT state can give attackers tools to correlate sessions. those attacks are not theoretical and have been demonstrated on multi-tenant networks.
why container-based services struggle here
container-per-tenant is genuinely cheaper. that is why so many providers chose it. the costs only show up when you push the isolation hard.
shared kernel means a kernel-level escape from one container can read another container’s memory. these vulnerabilities show up regularly in shared Linux infrastructure. Android-on-x86 emulators inherit them.
deduplicated storage means two containers with similar setups may share underlying disk blocks. if your storage layer has any leak between cleared blocks and reallocated blocks, you can occasionally see remnants from a previous container. this has been demonstrated in cloud research papers.
shared device identifiers. some emulator stacks reuse the same IMEI, MAC, or serial across many container resets, especially under default configuration. if you log in to an account, log out, and a different tenant logs in to the same emulator instance an hour later, the platform on the other end can correlate the two sessions through the shared identifier.
attestation drift. Play Integrity is sensitive to environment shape. emulators that try to pass attestation through tweaks tend to drift in and out of “BASIC” or “NONE” verdicts as Google updates its checks. on real hardware, attestation is stable.
these are not arguments that container-per-tenant is unusable. they are arguments that the isolation guarantees are weaker than they look on the marketing page, and that the failure modes are exactly the kind that hurt account-sensitive workflows.
what device-per-tenant gives up
honest tradeoffs matter.
device-per-tenant is more expensive per unit. you are paying for one phone, one SIM, one rack slot, and one wipe-and-prep cycle every time the device changes hands. there is no path to make that as cheap as a container.
device-per-tenant has lower density. one server can host many containers. one rack can host a fixed number of phones. capacity scales linearly with hardware spend.
device-per-tenant has slower onboarding for short sessions. a factory reset and re-enrollment takes a few minutes between users. a container can start in seconds.
if your workflow tolerates weaker isolation in exchange for lower cost, container-per-tenant is a real option. if your workflow does not, device-per-tenant is the answer that holds up.
if you are sharing access with teammates within your own rental window, the team-level pattern is in how to share a cloud phone with your team. that is a different question from cross-tenant isolation, but the same trust thinking applies.
the practical takeaway
ask three questions before you commit to a cloud phone service.
is each phone assigned to one tenant at a time, or is it shared. if shared, ask exactly how isolation is enforced.
what wipe operation runs between tenants. is it a factory reset, a container restart, or a partial reset. is it verified.
are network egress and device identifiers reset between tenants. if not, you have correlation surface across tenants regardless of storage isolation.
cloudf.one’s answer to all three is built into how the service is structured, not into a custom wipe script you have to take on faith.
frequently asked questions
what is session isolation on a cloud phone?
session isolation is the set of guarantees that one tenant’s data, network identity, and device state cannot cross over into the next tenant’s session on the same phone. it covers storage wipe, network reset, and identifier regeneration.
does cloudf.one factory reset between users?
yes. each Samsung handset gets a real Android factory reset between tenants, with verification that setup wizard re-runs on next boot.
can the next user see my apps or data on a cloud phone?
not on cloudf.one. the userdata partition is wiped and re-encrypted between tenants, so apps, files, accounts, and stored credentials are gone before the device is reassigned.
is container-based cloud Android less secure?
it has weaker isolation guarantees in practice. shared kernel, shared storage, and shared egress create correlation surface that device-per-tenant designs avoid. for low-stakes work it is fine. for account-sensitive work it can leak.
what about my IP — does it carry over to the next user?
no. each tenant uses a dedicated SG mobile modem and SIM. between tenants the modem session is fresh, so the public IP is fresh too. there is no shared egress to leak through.
can I verify the wipe happened?
yes. setup wizard re-running, no bound Google account, and regenerated ad ID and instance ID are all observable on the next boot. cloudf.one runs these checks before reissuing a device.