What is Panic Sync?
Panic Sync is a web-based service that is designed to sync configuration in your Panic apps between your devices (whether they be iPhones, iPads, or Macs). The data synced varies between our apps, but most often it is your Servers and Keys.
We have put a large amount of effort into making Panic Sync reliable, secure, and easy. We take user experience very seriously, and Panic Sync is built from the beginning with our users in mind.
However, users sometimes have questions about the service, so this will attempt to answer the most common questions.
How Secure Is My Data?
The short answer: Your data is end-to-end encrypted with Panic Sync (meaning it’s encrypted on your device before being pushed to our service, and decrypted only on your other devices). We use industry-standard methods for cryptography and we don’t roll our own encryption. The Panic Sync service itself has been code-reviewed by a reputable third-party company named ^Lift.
The long answer:
Your data is encrypted on a per-attribute basis. For a server bookmark in Transmit, for example, all fields such as the username, password, and hostname are encrypted.
Encryption is performed using AES and a pair of 256-bit symmetric keys, built and used as follows:
When you create your account:
- We create a pair of 256-bit master keys (one for encryption, one for HMAC verification) based on high-entropic data from
/dev/random. - We take your account password and stretch it using the PBKDF2 algorithm with a high level of algorithmic rounds (we increase the round count periodically for new users and password changes based on industry recommendation).
- This stretched data (the derived keys) are then used to encrypt and sign your master key. The encrypted master keys are stored within Panic Sync’s server-side database. The original master keys and your derived keys are not stored.
When you log in on a device:
- After authenticating your account, the server delivers your encrypted master keys to the device.
- The device performs the same PBKDF2 derivation on your password to generate your derived keys, and decrypt the master keys. The master keys are then stored within the device’s Keychain (on both macOS and iOS). We never store your account password on the device (only using it during login).
- The master keys will be used by the application from that point forward to encrypt, decrypt, and verify data.
When data moves from your device to Panic Sync:
- The data is encrypted on a per-attribute basis (each field individually) using the first master key stored in the device’s keychain.
- The ciphertext is then signed using the second master key (using HMAC).
- The signed ciphertext is transmitted to the Panic Sync servers and stored within its database.
When data moves from Panic Sync to your device:
- The signed ciphertext is retrieved from the database and transmitted to the device.
- The device verifies the signature using the second master key.
- The ciphertext is then decrypted using the first master key, and the resulting data is applied to the app.
Ultimately, neither the server or your devices store your account password or its derived keys. The server only receives your password during login attempts, and only generates the derived keys when your account is created, password changed, or password reset.
After authentication, apps are issued an OAuth-style token that is used for access to the Panic Sync API. This means that your account email and password are not sent with every API request, only for authentication. You can invalidate any of these app-specific tokens from the Panic Sync user website (which will revoke the app’s access).
Ultimately what this means is that the security of our encryption is partially dependent on your account password. The stronger your password, the stronger the encryption will be against a brute-force attack. We take user security very seriously, and will always try and be up-front and honest when your data is involved. For more information about what we do to protect your data in our apps, see our Privacy Page
Why Not Use iCloud (or Dropbox, et al.)?
iCloud (and the like) are designed to sync file-based data like your documents. This works great when you need to sync a Pages document or a PDF.
However, if you make changes on more than once device before the first pushes its changes, then you will often be faced with a merge conflict. Services like iCloud and Dropbox have no built-in logic to resolve merge conflicts automatically. Instead, you are prompted in Pages, Preview, or Finder to choose one version of the document or the other (sometimes losing conflicting edits in the process).
Our users are likely to make changes to their servers and keys from multiple devices as part of their daily routine. For the best experience, we want complex merges to take place automatically for you without presenting UI. It’s not always the case that we can, but with Panic Sync we can most often take care of merges without your direction (and without having to choose between versions).
Next, when you change a file in iCloud or Dropbox, the service often pushes the entire file back to their server because it cannot pick out only the bits and pieces that have changed. Some might say “why not split your data into multiple files?” This is problematic due to the non-deterministic nature of these services. There is no guarantee all of the files will be delivered by the service at the same time (there might be 30 seconds, even minutes in between for poor connections).
Panic Sync is designed to push and pull only the information that has changed between your device and the server, and to do so in an atomic fashion. This ensures we don’t leave your devices in a half-synced state or have to inform you that your data “will arrive at some point when we get the call back from iCloud.”
Third, debugging. All of our device-side code is highly-tuned to be fast, reliable, and secure. However, with services like iCloud and Dropbox, the server-side of the equation is somewhat of a black box. We don’t get logs or diagnostic information if the fault is somewhere on the server (even if it’s our fault). If a user sends us a bug report saying “Transmit is not pulling the changes I made on my MacBook”, we are often left asking the user complex and unnecessary questions because we don’t have enough information as to why the data hasn’t yet made it to the other end.
With Panic Sync, we control and coordinate both sides of the equation. We can see server logs and error reports to get a much clearer picture when things might go wrong. We are also not restricted by a third-party service when there is downtime, or stuck waiting on support tickets when we have questions or need assistance.
Why not use CloudKit?
CloudKit is Apple’s solution to the “iCloud is really only good for files” problem. However, when we built Panic Sync it had not yet been announced (not until a full year after). Even further, it was originally restricted to apps that were distributed in Apple’s App Stores. We have customers who buy our Mac apps from us directly, so relying on CloudKit in this way was not an option. (Apple has recently lifted this restriction on CloudKit, however.)
The CloudKit service still falls more or less into the debugging black-box that we are not as comfortable with, however. Since the release of Panic Sync, we have enjoyed a much easier support and diagnostic dialogue with users who experience issues than we have with third-party services we relied on in the past.
Why Does Prompt Not Sync With Your Other Apps?
Prompt is currently somewhat of a special case. Transmit and Nova work with several types of servers (from SFTP to Amazon S3). Prompt only supports one type: SSH (which is mostly equivalent to SFTP).
If we were to sync your servers between Prompt and the other apps, one of two things could be expected: Either only your SSH/SFTP servers sync, or all of your servers sync, and Prompt grays out the ones with which it cannot do anything.
This is further complicated by Server Folders. You can organize your servers in all of our apps into folders for easy grouping. If Prompt only syncs SSH/SFTP servers, then a folder with mixed-type servers in Transmit would potentially only show a subset in the folder in Prompt. If the folder contains no SFTP servers, it would appear empty in Prompt, or might not appear at all (which is confusing). Additionally, reordering items becomes very complicated if you can’t see hidden items in Prompt and the order that should result when pushed to Transmit is not apparent or obvious to the user.
Many common edge cases like this have caused us to think and rethink about how we would want Prompt to join the mix with Transmit and Nova. We are open to the idea, but it might take a bit more work for us to figure out exactly how we want this to behave.