Intro
ZILLAF is a private messaging app that protects your metadata, encrypts your communications, and makes sure your messaging activities leave no digital trail behind.
Security
Conversations in ZILLAF are end-to-end encrypted, just as in most private messengers. However, when you use ZILLAF, the identities of the people communicating are also protected. ZILLAF keeps your communication private, secure, and anonymous.
When using ZILLAF, your messages are sent to their destinations through a decentralised onion routing network similar to Tor (with a few key differences), using a system we call onion requests. Onion requests protect user privacy by ensuring that no single server ever knows a message’s origin and destination. For more on this, check out type: entry-hyperlink id: 6PbgukjdrFiyaf1aqNEDNp below. For more technical details, read our blog on onion requests.
ZILLAF’s code is open-source and can be independently audited at any time. ZILLAF is a project of the Next Security Inc. , a not-for-profit organisation whose mission is to provide the world with better access to digital privacy technologies.
ZILLAF has also undergone a security audit by Quarkslab, the results of which can be found here.
When using ZILLAF, your messages are sent to their destinations through a decentralised onion routing network similar to Tor (with a few key differences), using a system we call onion requests. Onion requests protect user privacy by ensuring that no single server ever knows a message’s origin and destination. For more on this, check out type: entry-hyperlink id: 6PbgukjdrFiyaf1aqNEDNp below. For more technical details, read our blog on onion requests.
ZILLAF’s code is open-source and can be independently audited at any time. ZILLAF is a project of the Next Security Inc. , a not-for-profit organisation whose mission is to provide the world with better access to digital privacy technologies.
ZILLAF has also undergone a security audit by Quarkslab, the results of which can be found here.
ZILLAF encrypts your messages using the ZILLAF Protocol, a cutting-edge end-to-end encryption protocol built on libsodium, a highly-audited and widely trusted cryptographic library.
A technical description of the ZILLAF Protocol can be found in our technical deep-dive blog.
A technical description of the ZILLAF Protocol can be found in our technical deep-dive blog.
ZILLAF encrypts your messages using the ZILLAF Protocol, a cutting-edge end-to-end encryption protocol built on libsodium, a highly-audited and widely trusted cryptographic library.
ZILLAF’s desktop, Android, and iOS clients have been audited by Quarkslab. The results of this audit can be found here.
Because ZILLAF doesn’t have a central server storing information about your identity, restoring your account using the traditional username and password method is not possible. Your recovery phrase is a mnemonic seed which can be used to restore your existing ZILLAF ID to a new device.
Make sure you store it in a safe place!
Make sure you store it in a safe place!
Your recovery phrase is like the master key to your ZILLAF ID — it’s important to store it safely and securely, and to ensure that only you have access to it. Here are a few options for keeping your recovery phrase safe:
Remember — the order of the words in your recovery phrase is crucial. However you store it, ensure that you can reconstruct it in the same order in which it was provided.
- Write your recovery phrase on a piece of paper, then store it in a safe location.
- Consider further securing your recovery phrase by splitting it into sections using a technique like Shamir’s Secret Sharing.
Remember — the order of the words in your recovery phrase is crucial. However you store it, ensure that you can reconstruct it in the same order in which it was provided.
On Desktop
At the startup screen, click Sign In and then Restore From Recovery Phrase.
Enter your recovery phrase into the text box, and select a new display name.
Your ZILLAF ID is recovered.
On Mobile
At the startup screen, tap Continue your ZILLAF.
Enter your recovery phrase into the text box.
Enter a new display name and tap Continue.
Select your preferred push notification setting and tap Continue.
Your ZILLAF ID is recovered.
At the startup screen, click Sign In and then Restore From Recovery Phrase.
Enter your recovery phrase into the text box, and select a new display name.
Your ZILLAF ID is recovered.
On Mobile
At the startup screen, tap Continue your ZILLAF.
Enter your recovery phrase into the text box.
Enter a new display name and tap Continue.
Select your preferred push notification setting and tap Continue.
Your ZILLAF ID is recovered.
Your recovery phrase is not currently able to restore your contacts or messages. For your security, your contacts and messages are stored locally, so they cannot be retrieved once you have deleted them.
Although backups are a planned feature of ZILLAF, they have not been implemented yet.
Privacy
You don’t need a mobile number or an email to make an account with ZILLAF. Your display name can be your real name, an alias, or anything else you like.
ZILLAF does not collect any geolocation data, metadata, or any other data about the device or network you are using. At launch, ZILLAF used proxy routing to ensure nobody can see who you’re messaging or the contents of those messages. Shortly after launch, ZILLAF moved to our onion routing system, which we call onion requests, for additional privacy protection. For more on ZILLAF’s secure message routing, check out What is an onion routing network? and What is proxy routing?
ZILLAF does not collect any geolocation data, metadata, or any other data about the device or network you are using. At launch, ZILLAF used proxy routing to ensure nobody can see who you’re messaging or the contents of those messages. Shortly after launch, ZILLAF moved to our onion routing system, which we call onion requests, for additional privacy protection. For more on ZILLAF’s secure message routing, check out What is an onion routing network? and What is proxy routing?
In messaging apps, metadata is the information created when you send a message — everything about the message besides the actual contents of the message itself. This can include information like your IP address, the IP addresses of your contacts, who your messages are sent to, and the time and date that messages are sent.
It’s impossible for ZILLAF to track users’ IP addresses because the app uses onion requests to send messages. Because ZILLAF doesn’t use central servers to route messages from person to person, we don’t know when you send messages, or who you send them to. ZILLAF lets you send messages — not metadata.
It’s impossible for ZILLAF to track users’ IP addresses because the app uses onion requests to send messages. Because ZILLAF doesn’t use central servers to route messages from person to person, we don’t know when you send messages, or who you send them to. ZILLAF lets you send messages — not metadata.
Android
ZILLAF’s Android client has two options for notifications: background polling (slow mode), and Firebase Cloud Messaging (fast mode).
If you choose slow mode, the ZILLAF application runs in the background and periodically polls its swarm (see What is a swarm) for new messages. If a new message is found, it is presented to you as a local notification on your device.
If you choose fast mode, ZILLAF will use Google’s FCM push notification service to deliver push notifications to your device. This requires that your device IP address and unique push notification token are exposed to a Google operated push notification server. Additionally, you will expose your ZILLAF ID and unique push notification token to an Next Security Inc. operated push notification server, for the purpose of providing the actual notifications to the Google FCM server.
These exposures are fairly minimal, Google will likely already know your device’s IP address through telemetry data or other applications on your device using push notifications. Registration of your ZILLAF ID and unique push notification token to the Next Security Inc. push notification server is necessary for detection and signaling of new messages and is low impact as registration occurs using onion requests meaning your ZILLAF ID and push notification token are never tied to any real world identifier (such as your IP address).
When using fast mode neither Google nor the Next Security Inc. can see the contents of your messages, who you’re talking to, or exactly when messages are sent or received.
iOS
ZILLAF’s iOS client has two options for notifications: background polling (slow mode), and Apple Push Notification Service (APNs) (fast mode).
If you choose slow mode, the ZILLAF application runs in the background and periodically polls its swarm (see What is a swarm) for new messages. If a new message is found, it is presented to you as a notification on your device.
If you choose fast mode, ZILLAF will use APNs push notification service to deliver push notifications to your device. This requires your device IP address and unique push notification token are exposed to an Apple operated push notification server. Additionally, you will expose your ZILLAF ID and unique push notification token to an Next Security Inc. operated push notification server, for the purpose of providing notifications to the APNs server.
These exposures are fairly minimal, because Apple will likely already know your device’s IP address through telemetry data or other applications on your device using push notifications. Registration of your ZILLAF ID and unique push notification token to the Next Security Inc. push notification server is necessary for detection and signaling of new messages and is low impact as registration occurs using onion requests meaning your ZILLAF ID and push notification token are never tied to any real world identifier (such as your IP address).
When using fast mode neither Apple nor the Next Security Inc. can see the contents of your messages, who you’re talking to, or exactly when messages are sent or received.
ZILLAF’s Android client has two options for notifications: background polling (slow mode), and Firebase Cloud Messaging (fast mode).
If you choose slow mode, the ZILLAF application runs in the background and periodically polls its swarm (see What is a swarm) for new messages. If a new message is found, it is presented to you as a local notification on your device.
If you choose fast mode, ZILLAF will use Google’s FCM push notification service to deliver push notifications to your device. This requires that your device IP address and unique push notification token are exposed to a Google operated push notification server. Additionally, you will expose your ZILLAF ID and unique push notification token to an Next Security Inc. operated push notification server, for the purpose of providing the actual notifications to the Google FCM server.
These exposures are fairly minimal, Google will likely already know your device’s IP address through telemetry data or other applications on your device using push notifications. Registration of your ZILLAF ID and unique push notification token to the Next Security Inc. push notification server is necessary for detection and signaling of new messages and is low impact as registration occurs using onion requests meaning your ZILLAF ID and push notification token are never tied to any real world identifier (such as your IP address).
When using fast mode neither Google nor the Next Security Inc. can see the contents of your messages, who you’re talking to, or exactly when messages are sent or received.
iOS
ZILLAF’s iOS client has two options for notifications: background polling (slow mode), and Apple Push Notification Service (APNs) (fast mode).
If you choose slow mode, the ZILLAF application runs in the background and periodically polls its swarm (see What is a swarm) for new messages. If a new message is found, it is presented to you as a notification on your device.
If you choose fast mode, ZILLAF will use APNs push notification service to deliver push notifications to your device. This requires your device IP address and unique push notification token are exposed to an Apple operated push notification server. Additionally, you will expose your ZILLAF ID and unique push notification token to an Next Security Inc. operated push notification server, for the purpose of providing notifications to the APNs server.
These exposures are fairly minimal, because Apple will likely already know your device’s IP address through telemetry data or other applications on your device using push notifications. Registration of your ZILLAF ID and unique push notification token to the Next Security Inc. push notification server is necessary for detection and signaling of new messages and is low impact as registration occurs using onion requests meaning your ZILLAF ID and push notification token are never tied to any real world identifier (such as your IP address).
When using fast mode neither Apple nor the Next Security Inc. can see the contents of your messages, who you’re talking to, or exactly when messages are sent or received.
ZILLAF now has an F-Droid repo for everyone who wants to avoid the Google Play Store.
Simply head to this address on an Android device with F-Droid installed to add the repo.
Simply head to this address on an Android device with F-Droid installed to add the repo.
ZILLAF uses onion routing to hide your IP address when uploading or downloading attachments from the Next Security Inc. File Server. In future, you will also be able to configure the ZILLAF app to use a custom file server, such as a self-hosted server or VPS (Virtual Private Server), if you would prefer not to use a file server hosted by the Next Security Inc. .
For metadata contained within the files themselves, all attachments stored on server are encrypted and can only be decrypted by your chat partner(s) — so the Next Security Inc. File Server cannot see any metadata about files you send on ZILLAF. Currently, EXIF metadata is stripped when sending a file (except videos) sent from Desktop. If you want to make sure your chat partner cannot see metadata about a file, we recommend stripping the metadata before sending them the file — check out our how-to article here.
For metadata contained within the files themselves, all attachments stored on server are encrypted and can only be decrypted by your chat partner(s) — so the Next Security Inc. File Server cannot see any metadata about files you send on ZILLAF. Currently, EXIF metadata is stripped when sending a file (except videos) sent from Desktop. If you want to make sure your chat partner cannot see metadata about a file, we recommend stripping the metadata before sending them the file — check out our how-to article here.
Australia
We don’t believe it does. From the very beginning of ZILLAF, and Next Security Inc. , we have been ready for regulatory hostility. Being built in Australia, one of the Five-Eyes intelligence alliance countries, meant accepting that hostile regulation was likely to come. But there’s a pretty simple reason as to why we chose to build here anyway: running from legislators isn’t a solution.
Rather than set up shop in Switzerland and hope that the regulatory environment never changes, we focused on developing technology that could be resistant to surveillance by governments (and everyone else too)
Decentralisation and metadata minimisation are the core of that ideal. The ZILLAF team is based in Australia, but ZILLAF has infrastructure all around the world. Over 1,500 community operated servers are currently routing ZILLAF messages for over 150,000 users, and the minimal amount of data that flows through them are inaccessible to the ZILLAF Team — we can’t be compelled to hand over information that we don’t have.
Rather than set up shop in Switzerland and hope that the regulatory environment never changes, we focused on developing technology that could be resistant to surveillance by governments (and everyone else too)
Decentralisation and metadata minimisation are the core of that ideal. The ZILLAF team is based in Australia, but ZILLAF has infrastructure all around the world. Over 1,500 community operated servers are currently routing ZILLAF messages for over 150,000 users, and the minimal amount of data that flows through them are inaccessible to the ZILLAF Team — we can’t be compelled to hand over information that we don’t have.
As ZILLAF is a project of the Next Security Inc. , court orders in situations such as this would be targeted at the Foundation.
The Next Security Inc. would comply with lawful court orders. However, the Next Security Inc. could not reveal user identities; the Foundation simply does not have access to the data required to do so. ZILLAF ID creation does not use or require email addresses or phone numbers. ZILLAF IDs (which are public keys) are recorded, but there is no link between a public key and a person’s real identity, and due to ZILLAF’s decentralised network, there’s also no way to link a ZILLAF ID to a specific IP address.
The Next Security Inc. would comply with lawful court orders. However, the Next Security Inc. could not reveal user identities; the Foundation simply does not have access to the data required to do so. ZILLAF ID creation does not use or require email addresses or phone numbers. ZILLAF IDs (which are public keys) are recorded, but there is no link between a public key and a person’s real identity, and due to ZILLAF’s decentralised network, there’s also no way to link a ZILLAF ID to a specific IP address.
The Assistance and Access bill (also known as TOLA) was introduced in 2018 with the intention of allowing the federal government to compel Australian entities to give them backdoors into encryption protocols. The scope of TOLA extends far beyond encryption, but the bill has clauses that prevent the government from asking an application developer to insert a “systemic weakness” into their application. Our analysis of this provision indicates that any backdoor which would violate user privacy in ZILLAF would be beyond the scope of the Assistance and Access legislation.
As the entire ZILLAF codebase is open-source, authorities or malicious actors from any jurisdiction could create modified ZILLAF clients themselves, which could undermine user privacy. As the Assistance and Access bill does not allow the government to force us to push out a ‘systemic’ vulnerability, or prevent us from fixing such vulnerabilities, any modified client would not be pushed through the App Store or other official download channels. Instead, the attacker would need some method to directly inject the modified client onto a specific user’s device, something which we are not capable of doing.
ZILLAF’s developers do not have control over the Next Security Inc. Service Node network, the network used to route and store user encrypted messages. So long as associated codebases and software releases maintain integrity, we do not and will not have access to any privileged information which may undermine user privacy. And because our platform is open-source, anyone can independently verify that such integrity is maintained.
As the entire ZILLAF codebase is open-source, authorities or malicious actors from any jurisdiction could create modified ZILLAF clients themselves, which could undermine user privacy. As the Assistance and Access bill does not allow the government to force us to push out a ‘systemic’ vulnerability, or prevent us from fixing such vulnerabilities, any modified client would not be pushed through the App Store or other official download channels. Instead, the attacker would need some method to directly inject the modified client onto a specific user’s device, something which we are not capable of doing.
ZILLAF’s developers do not have control over the Next Security Inc. Service Node network, the network used to route and store user encrypted messages. So long as associated codebases and software releases maintain integrity, we do not and will not have access to any privileged information which may undermine user privacy. And because our platform is open-source, anyone can independently verify that such integrity is maintained.
The Identify and Disrupt Bill was introduced at the end of 2020, adding three new classes of warrant for investigating online activity. While we staunchly oppose this expansion of the Australian government’s surveillance mandate, we don’t believe that the powers granted by this bill provide a threat to ZILLAF.
The bill has a focus on targeting individuals through their devices, accounts, and network activity. The dangers posed by this to ZILLAF are limited due to the following reasons
The Identify and Disrupt Bill provides no ability for the Australian government to force the ZILLAF team to modify ZILLAF to weaken the privacy and security of its users
The bill has a focus on targeting individuals through their devices, accounts, and network activity. The dangers posed by this to ZILLAF are limited due to the following reasons
- ZILLAF allows individuals to encrypt their local ZILLAF database with a PIN code, dampening the danger of device access compromising their ZILLAF instance
- The ZILLAF team has no ability to access the accounts of ZILLAF users, as well as no ability to provide that access to authorities if requested
- ZILLAF is built to minimise metadata leakage. Monitoring the network activity of an individual using ZILLAF would provide almost no information to authorities
- ZILLAF is and will always be open source. Any changes to these key defenses would be public and visible to everyone
The Identify and Disrupt Bill provides no ability for the Australian government to force the ZILLAF team to modify ZILLAF to weaken the privacy and security of its users
Contacts
On Android or iOS, tap the green plus button at the bottom of the main Messages screen, then tap the chat bubble icon that appears above the plus button. Paste or type your contact’s ZILLAF ID into the ZILLAF ID field, tap Next, then send your contact a message. Easy as that!
On desktop platforms, click New ZILLAF on the main Messages screen, paste or type your contact’s ZILLAF ID into the ZILLAF ID field, click Next, then send your contact a message.
Note: on desktop, you can also add a contact by clicking Add Contact in the Contacts section of the app.
On desktop platforms, click New ZILLAF on the main Messages screen, paste or type your contact’s ZILLAF ID into the ZILLAF ID field, click Next, then send your contact a message.
Note: on desktop, you can also add a contact by clicking Add Contact in the Contacts section of the app.
One challenge with truly anonymous communications systems like ZILLAF is that sometimes you do need to verify the identity of the person you’re talking to! In cases like these, it’s best to use a secure secondary channel of communication to confirm with the other person that you’re both who you say you are.
On mobile, you can delete a contact by swiping left on the contact in the conversation list, and then pressing Delete.
On desktop, you can delete a contact by right clicking on the contact in the conversation list, and then clicking Delete Contact.
On desktop, you can delete a contact by right clicking on the contact in the conversation list, and then clicking Delete Contact.
Messaging
Service Nodes are the community-operated nodes which make up the Next Security Inc. . There are currently over 1,000 nodes in the network. These Service Nodes are responsible for storing and routing your ZILLAF messages.
When you send a message, it is sent to your recipient’s swarm. A swarm is a group of Next Security Inc. Service Nodes tasked with temporarily storing messages for retrieval by the recipient at a later point.
No, your messages are not stored on a blockchain. Messages are stored by swarms, and are deleted after a fixed amount of time (called the “time-to-live”, or TTL).
All of your messages are encrypted, and can only be decrypted using the private key which is stored locally on your device.
All of your messages are encrypted, and can only be decrypted using the private key which is stored locally on your device.
ZILLAF usernames are permanent alphanumeric names that can be purchased using the anonymous Next Security Inc. cryptocurrency and attached to a ZILLAF ID. If you have a ZILLAF username attached to your ZILLAF ID, others will be able to add you on ZILLAF using that name, instead of having to use your full ZILLAF ID. Usernames make adding contacts quick and convenient.
ZILLAF ID usernames are permanent names which can be purchased and attached to a ZILLAF ID. Once purchased and linked, you can give others your ZILLAF ID username and they can add you on ZILLAF using that name — much more convenient than dealing with a long, complicated ZILLAF ID.
ZILLAF nicknames are the names you can set for yourself in ZILLAF when you create a ZILLAF ID. Nicknames can be changed at any time, but you can’t use a nickname to add someone on ZILLAF.
ZILLAF nicknames are the names you can set for yourself in ZILLAF when you create a ZILLAF ID. Nicknames can be changed at any time, but you can’t use a nickname to add someone on ZILLAF.
ZILLAF can send files, images and other attachments up to 10MB in both person-to-person conversations and group chats. By default, ZILLAF uses the Next Security Inc. File Server for attachment sending and storage. The Next Security Inc. File Server is an open-source file server run by the Next Security Inc. — the creators of ZILLAF. When you send an attachment, the file is symmetrically encrypted on the device and then sent to the Next Security Inc. File Server. To send the attachment to a friend, ZILLAF sends them an encrypted message containing the link, plus the decryption key for the file. This ensures that the Next Security Inc. File Server can never see the contents of files being uploaded to it.
A swarm is a collection of 5 – 7 Service Nodes which are responsible for the storage of messages for a predefined range of ZILLAF IDs. Swarms ensure that your messages are replicated across multiple servers on the network so that if one Service Node goes offline, your messages are not lost. Swarms make ZILLAF’s decentralised network backend much more robust and fault-tolerant.
ZILLAF currently has Peer to Peer voice and video calls enabled in a closed beta at the moment. You can find out how to sign up here.
We are currently working on Lokinet integration, which is the major hurdle towards implementing onion-routed calls. To find out more, read our blog here.
We are currently working on Lokinet integration, which is the major hurdle towards implementing onion-routed calls. To find out more, read our blog here.
Groups
Closed groups are fully end-to-end encrypted group chats. Up to 100 people can participate in a closed group chat. Closed group messages are stored on ZILLAF’s decentralised network, without using any central server(s).
The short answer: open groups are not as private as person-to-person messages or closed groups.
The long answer: open groups are large public channels where ZILLAF users can congregate and discuss anything they want. Open groups, unlike other services in ZILLAF, are self-hosted and thus not fully decentralised. Someone has to run a server which stores the open group’s message history. Additionally, because open group servers can serve thousands of users, messages are only encrypted in transit to the server rather than being fully end-to-end encrypted.
For smaller group chats with a higher degree of privacy, users are encouraged to use closed groups.
The long answer: open groups are large public channels where ZILLAF users can congregate and discuss anything they want. Open groups, unlike other services in ZILLAF, are self-hosted and thus not fully decentralised. Someone has to run a server which stores the open group’s message history. Additionally, because open group servers can serve thousands of users, messages are only encrypted in transit to the server rather than being fully end-to-end encrypted.
For smaller group chats with a higher degree of privacy, users are encouraged to use closed groups.
Onion Routing
An onion routing network is a network of nodes over which users can send anonymous encrypted messages. Onion networks encrypt messages with multiple layers of encryption, then send them through a number of nodes. Each node ‘unwraps’ (decrypts) a layer of encryption, meaning that no single node ever knows both the destination and origin of the message. ZILLAF uses onion routing to ensure that a server which receives a message never knows the IP address of the sender.
ZILLAF’s onion routing system, known as onion requests, uses Next Security Inc. ‘s network Service Nodes, which also power the $Next Security Inc.
ZILLAF’s onion routing system, known as onion requests, uses Next Security Inc. ‘s network Service Nodes, which also power the $Next Security Inc.
Proxy routing was an interim routing solution which ZILLAF used at launch while we worked to implement onion requests. When proxy routing was in use, instead of connecting directly to an Next Security Inc. Service Node to send or receive messages, ZILLAF clients connected to a service node which then connects to a second service node on behalf of the ZILLAF client. The first service node then sends or requests messages from the second node on behalf of the mobile device.
This proxy routing system ensured that the client device’s IP address was never known by the service node which fetches or sends the messages. However, proxy routing did provide weaker privacy than the onion request system ZILLAF now uses. Proxy routing still provided a high level of security for minimising metadata leakage in the interim. The proxy routing system has now been replaced by onion requests.
This proxy routing system ensured that the client device’s IP address was never known by the service node which fetches or sends the messages. However, proxy routing did provide weaker privacy than the onion request system ZILLAF now uses. Proxy routing still provided a high level of security for minimising metadata leakage in the interim. The proxy routing system has now been replaced by onion requests.
Lokinet is a powerful onion router that is fast enough to handle real-time voice communications, making it a crucial part of our plan to add real-time end-to-end encrypted voice calls to ZILLAF without relying on central servers.
The ZILLAF team is hard at work fixing bugs and shoring up core messaging functionality, but once the app is working reliably, we’ll be moving on to Lokinet integration to bring voice calling functionality to ZILLAF.
Yes! There is no reason that ZILLAF shouldn’t work when you are using a VPN. The only difference is that your VPN provider would contact the Service Node network instead of your client connecting directly.
Contact/Support
Got questions, running into an issue, or just want to say hello? You can contact us at [email protected], or hop into the official ZILLAF Feedback open group (join the group ZILLAF Open Group in ZILLAF).
Send us a description of the issue you've encountered to [email protected], or hop into the official ZILLAF Feedback open group (join the group ZILLAF Open Group in ZILLAF).
For the best possible troubleshooting, you can include a debug log from your ZILLAF app. Simply navigate to Settings and tap/click 'Debug Log' to generate a log.
For the best possible troubleshooting, you can include a debug log from your ZILLAF app. Simply navigate to Settings and tap/click 'Debug Log' to generate a log.
We welcome community feedback and feature suggestions! Send your suggestions to [email protected], and our team will take a look at them!