These are some of the frequently asked question we get:
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.
|Web hosting, file and data storage||Google Cloud Privacy Notice|
|Stripe||Payment processing||Stripe Privacy Center|
|Mailchimp||Marketing emails||Mailchimp GDPR|
|Mailgun||Transactional emails||Mailgun GDPR Compliance and EU Data Protection|
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:
ATS requires all of these things, and then provides extended security checks:
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
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.
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.
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.
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, this means that anyone who has the xml will be able to access the media.
Which versions of the media are linked to depends on whether or not you are uploading original media files to Edit Board and transcoding into a ProRes mezzanine format. This is something you configure when creating a new board. There are three possible workflows with Final Cut:
Edit Board will add links to the proxy files from the cloud and they will be downloaded automatically.
It will also add links to the original media files, assuming them to be in a local folder called "Media" in the same folder as the fcpxml file. If you create this folder and add the original files yourself they will be found by Final Cut Pro.
Alternatively you can put the original files anywhere locally and manually ask Final Cut Pro to relink to them.
Edit Board will add links to both the proxy and the original files from the cloud and they will be downloaded automatically by Final Cut Pro.
Edit Board will add links to both the proxy and the transcoded ProRes files from the cloud and they will be downloaded automatically by Final Cut Pro.
Edit Board can export a board and its sub pages as a composition in AAF format.
For this to work you have to be uploading your original media files to Edit Board and transcoding them into a DNxHD mezzanine format (DNxHR not supported yet), this is something you configure when creating a new board.
As Edit Board has generated the DHxHD files itself it knows all the mob IDs allowing edits created in Edit Board to import seamlessly into the edit suite.
You can easily sync down the transcoded DNxHD files in post production using the macOS version of Edit Board.
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 refered 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