How do we manage personal data? ¶

We have a Privacy Policy which describes how we manage the personal data that we collect.

Who are our sub-processors of personal data? ¶

These are the third party companies that we use services from and are processors/sub-processors of some of the personal data that we hold.

How secure are the network connections we send data through? ¶

All network connections between our iOS, macOS apps and our services fully comply with Apple's App Transport Security policy without exception. This applies to both data exchanged between apps and our services and all uploading and downloading of media files. This means that every connection is encrypted and does at least does the following:

A secure server establishes its identity using an X.509 digital certificate. A connecting client examines this certificate to perform default server trust evaluation, which includes checking that the certificate:

• Has an intact digital signature, showing that the certificate hasn’t been tampered with.
• Isn’t expired.
• Has a name that matches the server’s DNS name.
• Is signed by another valid certificate, which is in turned signed by another, and so on back to a trusted anchor certificate, which must be issued by a Certificate Authority (CA). The anchor certificate must be part of the client operating system, as indicated in Lists of available trusted root certificates in iOS, or be installed on the client by the user or a system administrator.

ATS requires all of these things, and then provides extended security checks:

• The server certificate must be signed with either a Rivest-Shamir-Adleman (RSA) key of at least 2048 bits, or an Elliptic-Curve Cryptography (ECC) key of at least 256 bits.
• The certificate must use the Secure Hash Algorithm 2 (SHA-2) with a digest length, sometimes called a fingerprint, of at least 256 bits (that is, SHA-256 or greater).
• The connection must use Transport Layer Security (TLS) protocol version 1.2 or later.
• Data must be exchanged using either the AES-128 or the AES-256 symmetric cipher.
• The link must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

How securely do we store data? ¶

Storage on iOS devices

On iPhone and iPad devices all application data is encrypted on disk and protected by this encryption if the device is off or the user not logged in. When a user is logged in they can access the data through the application, however there are additional strong protections, such as sandboxing, that help prevent other, malicious, apps accessing the data. One reason that we only support Apple mobile devices is that Apple provides a very high level of integrated OS/hardware security. You can read more about iOS security here: App security overview for iOS and iPadOS

Storage on macOS

The macOS version of Edit Board is not sandboxed, to allow integrations such as watch folders and ffmpeg transcoding. The data and media is not encrypted on disk by the Edit Board application but you can enable the optional OS FileVault facility to encrypt the the hard drive that the data is stored on, this will protect the data in a similar way to the disk encryption in iOS.

Both iOS and masOS versions of Edit Board use Apple's Hardened Runtimes which helps protect against certain potential threats to the running application. Both apps are notarized by Apple.

Storage on our servers

Edit Board uses elements of Google's Cloud Platform to store both data and media files, and both are encrypted at rest.

In our data store each data object and metadata is encrypted with a 256-bit AES, and each encryption key is itself encrypted with a regularly rotated set of master keys.

Similarly all media files are encrypted at rest with a 256-bit AES key. You can read here how Google handles data encryption.

How do we enforce that only permitted users can access data? ¶

We have a tiered, role-based, user permission model which allows admins to set differential permissions at both an organisational and board level. This ensures that users are only granted limited and specific permissions read and update data.

We enforce these role-based permissions in a fine grained way allowing control of read/write/update/delete permissions at the individual data field level in our data store.

We use a strong, slow and secure hashing algorithm to validate passwords, and do not store plain-text passwords anywhere.

We have multiple mitigations in place to protect against particular types of attack on our public servers, if you would like a more detailed explanation of these please get in touch.

Access to media files within Edit Board respects the same role-based permissions. Downloading or streaming media requires that the user has authenticated and authorised permission at the time they access the media. (Exceptions to this are if you explicitly export media for sharing without authentication, eg embedded links in FCP XML or web pages published with an authorised link.)

If permission to access media, at either organisational or board level, is taken away from a user when they next connect to our servers any media that they not longer have permission to view will be automatically deleted from the app's cache on their device.

Which files does exported FCP XML link to? ¶

Edit Board can export a board and its sub pages to Final Cut Pro XML 1.9.

Authenticated links are embedded in the exported xml that allow Final Cut Pro to download media directly from the Edit Board servers.

Depending on whether you want to work locally, on your mac, or use our cloud services there are several possible workflows. You can see details of the different Final Cut workflows here.

How does exported AAF link to media? ¶

Edit Board can export a board and its sub pages as a composition in AAF format. This composition can be imported directly into editing systems that support AAF. You can see details of the different linking options here.

Do we use binary or decimal versions of GB and TB? ¶

We use binary.

There are two different versions of the term gigabyte, a binary one which refers to 1024^3 (1,073,741,824) bytes, and a decimal one which refers to 1000^3 (1,000,000,000) bytes. The binary one is also sometimes referred to as a "gibibyte" and the symbol GiB is used. The symbol "GB" may refer to either the binary or decimal version.

The binary GB is 7% larger than the decimal one.

According to the International System of Quantities "GB" should refer to the decimal version, however the binary one is common in the computing and data industries, including in cloud platforms such as AWS and GCP. We use the binary one as it's the industry standard.

You can read more here on Wikipedia