October is Cyber Security Awareness Month in Canada. This year’s theme, “Your best defence is you,” is a reminder that good decisions start with clear information.
A privacy promise is only useful if you know where it stops. Here are the main limits of ours, each right beside what it qualifies. Our Privacy Statement, linked at the end, describes what we process and why.
In short
We don’t hold the keys to your passwords, identity details, contacts, or the sealed content of your messages. Among other things, we can read what phone service requires, what passes through us before it’s sealed, the pictures our illegal-content check holds back, some messages kept from the private beta, the attachments on your support requests, your billing information, and what some options send us when you turn them on. The details follow.
What we can’t read
WIGGWIGG does not hold the keys needed to read zero-knowledge-encrypted passwords, identity details, contacts, and message content. “Zero-knowledge” here means the keys that decrypt that data are not in our hands.
For messages, that guarantee covers what we store, not the moment they pass through us. It also assumes the code that encrypts your data is authentic: someone who took control of how the web app is delivered could change the code served in a later session.
That protection has a defined scope. It does not cover:
- the operational data needed for phone routing, billing, and optional features that require processing on our servers;
- the content of your texts and picture messages while it passes through our servers, before it is sealed;
- the illegal-content check we run on picture messages, and the copy we keep when there is a match.
Before the seal: your calls and texts in transit
Calls, texts, and voicemail travel over the public phone networks. That leg isn’t end-to-end encrypted and stays visible to carriers, as it does for any phone service connected to the public network.
A text you send or receive passes through our servers in the clear, because we have to hand it to the carrier or receive it from them. Automated checks may run while it passes through, and we seal it when we store it. Our encryption therefore protects messages once they are stored; it is not end-to-end. For a conversation that needs to stay end-to-end encrypted, use a messaging service built for it.
What else we can read
Some data stays readable to us because the service needs it to work:
- When, and for how long. We keep a record of each call and text: when it happened and, for a call, how long it lasted. We see both numbers while we route it. The fact that a call or text happened is not sealed.
- The other person’s number. In your text history, that number is sealed with the message; in your call history, it is sealed when we find a usable key (see below). Alongside your texts and the numbers you call, though, we keep a keyed lookup index, a scrambled version of the number computed with a key we hold. We can therefore recover those numbers by trying every possible phone number, and check any given number directly.
- Your greetings and automatic replies. We can read the text and audio of your voicemail greeting, of the announcement played to you when you answer, and of the prompt your callers hear, along with the intros your callers record, because they have to be played during the call. We can also read the text of your automatic replies, because our server sends them on your behalf.
- Picture messages at our provider. For up to 30 days, we keep the link that lets us re-fetch a picture from our telephony provider. While that link exists, we can retrieve the picture.
- Your support requests. The subject, body, and attachment filenames are sealed to you and to a support key, so we can answer you. The contents of an attachment are encrypted at rest but stay readable by our servers, so we can help you.
- Your emergency address. So that 911 dispatchers know where to send help, your device sends us the address in readable form once, when you register it. We validate it and pass it to our provider, who keeps it to route emergency calls. The copy we keep is then zero-knowledge encrypted. A missing address does not stop a 911 call from connecting.
Picture messages
Picture messages are checked against known-illegal-image databases before they are stored. The fingerprint is computed on our own servers, and only that fingerprint is sent to the detectors; no detector ever receives the picture. When a picture is clean, we keep neither the image nor its fingerprint, only a verdict row erased within 90 days. The check covers images: we never fingerprint message text.
There are two kinds of match. For material confirmed illegal, the law obliges us to preserve a copy and report it, and the picture goes with our report to the RCMP unit that receives these files, the National Child Exploitation Crime Centre in Ottawa. That report goes to a Canadian authority.
For a picture the Canadian detector flags as harmful to children without placing it in its confirmed-illegal category, we block and preserve it the same way. That category is not a finding that the picture is legal: it is kept deliberately cautious so it holds across many countries, and the Canadian definition is broader. Nothing is reported automatically and no law required us to keep it, so that is our decision. If a review concludes the material is criminal in Canada, we report it.
Either copy is kept with no end date, we can view it, account deletion does not remove it, and the authorities can obtain it with a warrant. All of this applies as much to a picture someone sends you as to one you send. Running the check is also our decision: no law requires it.
Your communications and your account key
For communications protected at rest by our current sealing method, we encrypt the content under a one-time key, then seal that key to your account’s communication public key. The matching private key is itself encrypted on the client side (this is called wrapping) and becomes available to supported WIGGWIGG apps after you sign in and unlock. It is tied to your account, not to a device: every device you unlock reads the same history.
That protection has three limits to know about.
- Private-beta data. Some communications retained from the private beta still use our older server-side encryption: we can read them at rest, and they are not covered by the protection described here. Signing in and unlocking in the web app starts a limited background process that re-seals up to 50 eligible texts at a time; signing in on mobile does not start it. That process does not re-seal private-beta voicemail, legacy call-log numbers, picture-message attachments, or older retained versions of those files. Those copies stay readable by our servers until a later process or separate maintenance.
- Notifications on iOS. After the device’s first unlock, the iOS notification extension can access a copy of your account’s communication key, even while the vault or the device is locked and even when previews are hidden. That key can open your sealed account history, not only a preview. The copy stays on the device and is not uploaded to us. Android uses a separate key limited to notification previews.
- Fallbacks that keep a call going. Voicemail is sealed to your account key when we find a usable key, but it stays readable by our servers while Listen-by-phone is on or if the account has no usable key. The other person’s number in a call log is also sealed when we find a usable key; without a usable key, or if key lookup fails, we encrypt it under the server key so the live call is not interrupted. These fallbacks protect availability, not zero knowledge.
Contact recognition, an option
Contact recognition on calls stays off until you turn it on yourself. While it is on, your device computes, for each of your contacts’ numbers, a keyed fingerprint (a scrambled version of the number) and sends it to us, so we can recognize an incoming call or text from someone you know.
Because we hold that key, we can try every possible phone number and so recover your contacts’ numbers while the option is on. Each contact’s name, email, notes, and photo stay encrypted on your device and unreadable to us. As soon as you turn the option off, we erase every fingerprint from our live systems and can no longer recognize your contacts on new calls or texts; routine encrypted backups age out within about a month.
The devices that receive your calls
After you accept the current Privacy Statement, we automatically register up to 10 active browsers or mobile devices per account when you sign in and unlock your data, so they can receive your calls. The random recognition code stays on the device that created it; we receive it only transiently, without logging or storing it, then keep a keyed fingerprint scoped to your account.
While the registration is live, we can read:
- the link to your account and a random internal ID;
- whether it is a browser or a mobile device, and the number it’s listed under in your account;
- the associated phone numbers;
- its state, and its registration, readiness, and activity dates;
- for each phone number, whether all your devices ring or only the ones you chose, and which ones.
The name you give a device is encrypted on the device and unreadable to us. Removing a device stops new calls to it immediately. Once cleanup is confirmed with our provider, we erase those details and keep only the account link, an opaque ID, the keyed fingerprint, and the revoked status, until the account is deleted.
Unwanted calls
For now, our automated spam checks on incoming calls and messages only warn; they do not reject anything. The most specific personal rule you have set decides whether a call or message is rejected.
To look up a number’s carrier, we send that number in the clear to our telephony provider. For 90 days, we keep a keyed pseudonymous fingerprint of it with the carrier name and line type. Because we hold the key, we can compare possible numbers against that fingerprint. The link to the account that triggered the lookup is cleared within two days at most. Reports you contribute to the community are also keyed pseudonymous fingerprints, and they stay linked to your account.
Performance telemetry
Ordinary performance telemetry is off by default. If you turn it on, it sends measurements and error reports to our observability server, without cookies or an account identifier. On mobile, a random code groups the traces from one launch without being tied to the account.
Two exceptions reach us even when the setting is off: the browser’s content-security-policy reports, and certain mobile error reports (for example, startup failures and uncaught errors). Those mobile reports contain no account identifier or form values, but they can contain personal information if the error itself includes some.
Billing
For billing and taxes, we keep amounts, dates, taxes, payment-method type, and the product billed, along with the country and province, territory, or state you selected and your confirmation that this is where you live. That tax information is encrypted separately from your vault and stays readable to us. It does not include your vault contents or your communications.
After an account is deleted
When an account is deleted, after a 30-day grace period during which you can cancel by signing back in, all personal data is permanently deleted, except:
- invoices and necessary tax records, kept for the period the law requires, generally six years after the end of the last relevant year;
- the verdict of content checks that flagged something, and the preserved copy for either match class, only the confirmed-illegal class being legally compelled;
- for the security of the service, security audit logs, kept up to seven years.
What no third party has verified yet
Our whitepaper is self-attested; an independent audit is planned. WIGGWIGG’s cryptographic core is published under the MIT licence; the rest of the application is currently closed source.
What you can set yourself
- Contact recognition stays off until you turn it on, and you can turn it off at any time.
- If you don’t use Listen-by-phone, leave it off on each number: new voicemail is then sealed to your account key, if the account has a usable one. Turning it off does not re-seal voicemail you already received.
- Remove devices you no longer use from your account.
- If you were in the private beta, sign in and unlock your data in the web app to start re-sealing your older eligible texts.
Going further
- The Security Whitepaper explains how the encryption works in detail.
- The Privacy Statement describes the information we process, and why.