Skip to content
WLOC Cloud

Cloud model · Evidence · Restore

From browser request to a restorable iOS test.

WLOC Cloud separates browser control from device execution. Every operation has an authorized owner, a bounded target, an honest sync state, and a visible route back to normal behavior.

Start free diagnosticInspect the system model

Tokyo Tower · 180 seconds · No card required

WLOC Cloud system modelIllustrative · not live status
  1. 01
    Browser intentDeclare the test
  2. 02
    Control planeAuthorize and scope
  3. 03
    Device coordinationSerialize one device
  4. 04
    Execution and confirmationApply, observe, confirm

WLOC-observedGateway target synced

Tester-confirmedDevice and target-app result

The browser bundle never receives Gateway credentials. Profile bytes transit only during an explicit one-time, no-store download. A synced target remains separate from device and target-app confirmation.
  • Browser never connects directly to the Gateway
  • Profile XML and EAP passwords are not persisted by the control plane
  • Target synced is not labeled device online
  • Restore controls remain available in every account state

Product architecture

Four layers. One bounded operation.

Each layer owns a different responsibility. Passing one layer never silently upgrades the evidence produced by the next.

  1. 01Browser intent

    Declare the test

    Sign in, accept the Authorized Testing Policy, select an authorized device, and request one bounded target.

    Control requests go to the API Worker. Gateway credentials are never shipped in the client bundle; Profile bytes appear only in an explicit one-time, no-store download response.

  2. 02Control plane

    Authorize and scope

    The API Worker verifies the session, current policy, workspace membership, entitlement, and mutation safety before any device operation.

    D1 is the business source of truth. Tenant and resource scope are checked together instead of fetching first and authorizing later.

  3. 03Device coordination

    Serialize one device

    A per-device coordinator serializes provision, apply, restore, revoke, and status sync, then schedules the absolute restore deadline.

    Restore is priority work. A disabled browser button is never treated as concurrency control.

  4. 04Execution and confirmation

    Apply, observe, confirm

    The Gateway handles the Profile and location execution path for the authorized iPhone. WLOC records the evidence it can observe; the tester checks the device and target app.

    Gateway acceptance is not device-online telemetry, and it is not universal target-app confirmation.

The real sequence

Seven steps, including iOS Settings.

WLOC does not compress Profile installation, VPN connection, and device confirmation into an instant-action claim.

  1. 01

    Sign in

    Open the dashboard and verify your email.

  2. 02

    Accept the policy

    Read and accept the current acceptable-use policy.

  3. 03

    Create a workspace

    Name a workspace for authorized testing.

  4. 04

    Register a device

    Add an iPhone you own or are authorized to test.

  5. 05

    Install the Profile

    Download the configuration profile on the device and install it in Settings.

  6. 06

    Connect VPN

    Connect in iOS Settings. WLOC can confirm Target synced; you still confirm the result on the device.

  7. 07

    Run a diagnostic

    Apply the Tokyo Tower diagnostic and confirm the result yourself.

Evidence semantics

Trust the label, not the color.

WLOC separates control-plane evidence, Gateway observation, and the tester's device check. A green status never stands in for the whole chain.

target_synced

Gateway target synced

Supports
The Gateway accepted and stored the requested test target for the scoped device operation.
Does not establish
It does not prove that the iPhone is online or that the target app adopted the result.
awaiting_confirmation

Awaiting confirmation

Supports
The control-plane operation has evidence, while the device or target-app result still needs a human check.
Does not establish
It is not automatically a failed test and must not be upgraded to a green success state.
restore_submitted

Restore submitted

Supports
The Restore request was accepted for processing.
Does not establish
It does not prove tunnel termination or that normal location is already visible on the device.
manual_confirmation

Device and app checked

Supports
The tester records what the authorized device and target app actually show after apply or restore.
Does not establish
One observed result does not establish compatibility for every app, device, network, or iOS version.

WLOC security boundary

Built around what we refuse to store or overclaim.

These are first-party product contracts, not certification badges. Each one is backed by a concrete system boundary or recovery rule.

Narrow browser boundary

Secrets stay server-side

The browser bundle receives no Gateway bearer token, Access credential, EAP password, or server-side secret. Profile bytes transit only during an explicit one-time, no-store download to the authorized device.

Review the security boundary

Minimized persistence

Credentials use a one-time stream

Profile content and the EAP password pass only through Gateway and the one-time response stream. WLOC does not retain them in D1, KV, R2, Durable Objects, Queues, product analytics, structured application logs, browser-side storage, or fixtures.

Read the Profile guide

Recovery contract

Restore is an evidence loop

Restore, Revoke, and Emergency Stop remain reachable under unpaid, refunded, frozen, restricted, and pending-deletion states. Gateway readback and final device confirmation remain separate.

See the recovery contract

Research evidence · Source scope

A source chain with explicit limits.

These sources explain different layers of the system model. None certifies WLOC, turns a private path into a public Apple API, or guarantees that every app will adopt the same result.

  1. Current Apple documentation

    Location Services combine multiple signals

    Apple documents cellular, Wi-Fi, GPS, and Bluetooth as inputs to Location Services, with access controlled per app.

    Supports
    Why WLOC claims one bounded network-location path and requires target-app confirmation.
    Does not establish
    Apple endorsement, WLOC compatibility, or a guarantee about the final Core Location result.
    Read Apple Location Services

  2. Historical primary source · 2010

    A historical location-service data-flow model

    Apple's archived response to U.S. Representatives Markey and Barton described the Wi-Fi and cellular location flow used at that time.

    Supports
    Historical context for a device using known network landmarks in its location model.
    Does not establish
    A current private-protocol specification or a 2026 behavior guarantee.
    Read the archived Apple response

  3. Peer-reviewed research · IEEE S&P 2024

    Wi-Fi positioning as an observed research system

    Rye and Levin analyze BSSIDs as positioning landmarks, Apple WPS behavior, and the privacy risks of large-scale querying.

    Supports
    The WPS research model and the need for narrow, responsible handling of location data.
    Does not establish
    That WLOC Cloud was reviewed by IEEE or that its implementation works on every device.
    Read the research paper

  4. Independent reverse engineering · public code

    One independently reproduced response path

    The public apple-corelocation-experiments repository documents /clls/wloc, protobuf framing, and one observed result after rerouting a WPS response.

    Supports
    A reproducible third-party experiment and a traceable observed screen result.
    Does not establish
    An Apple specification, a WLOC Cloud screen, or universal compatibility across apps and iOS versions.
    View the experiment and code
Independent experimentNot a WLOC screen
Apple Maps result from an independent WPS response-rewrite experiment, with a blue location marker east of Japan
Independent experiment result from acheong08/apple-corelocation-experiments. It is not a WLOC App or Cloud screen and does not prove that every app accepts the same result.
View the original experiment

Straight answers

Cloud model FAQ

The most important limits, without hiding implementation reality behind marketing shorthand.

Does WLOC Cloud change the iPhone GPS hardware?

No. WLOC Cloud works with a bounded network-location response path. It does not write to the GPS receiver or globally override Core Location.

Does target synced mean the iPhone is online?

No. Target synced means the Gateway accepted and stored the requested target. Device reachability and the target-app result are separate observations.

Where do the Profile and EAP credentials go?

They pass through the Gateway and an explicit one-time, no-store download response. WLOC does not retain them in browser-side storage, D1, KV, R2, Durable Objects, queues, structured application logs, analytics, or fixtures.

How does WLOC verify Restore?

Restore starts with a Gateway command and pass-through readback. WLOC reports that separately from the tester's final check of the device and target app; it never turns a submitted command into an automatic device-restored claim.

Why can two apps still show different results?

iOS may combine GPS, Wi-Fi, cellular, and Bluetooth, while each app controls permission, cache, account, server, and risk logic. WLOC only claims the layer it can prepare and observe.

Start with a public location

Finish every test with Restore.

Run the fixed Tokyo Tower diagnostic, inspect each evidence layer, then complete the recovery check on the authorized device.

Start free diagnosticReview security

180 seconds · No card required