Your footage goes up from your browser straight into your own
folder, we work on it, and the finished package comes back to the same folder.
Our servers never hold the middle of a 400 GB multicam recording. Below is
exactly what we would ask each provider for, because
the promise we make about your files is only
worth what the permissions behind it actually are.
Google
First
One consent covers three things: signing in, Drive, and your YouTube channel. It is the shortest path to a working round trip.
Exactly what we would ask for
Sign inopenid email profileConfirms who you are. Nothing else.
Drive, one folder onlydrive.appdata or a single folder you pickWe can read and write inside the folder you choose, and cannot see the rest of your Drive.
YouTube, private onlyyoutube.uploadUploads the finished episode as private. It is never made public by us.
What we never do
We never ask for the whole Drive account.
We never read, move or delete anything outside the folder you pick.
We never make anything public. Publishing is your finger on the button.
Not connected yet. No client ID yet. Google also wants the Drive and YouTube APIs enabled on a project that has passed app verification for those scopes, which is a review, not a setting.
Microsoft
Third
The route to OneDrive, for anyone whose footage already lives there.
Exactly what we would ask for
Sign inopenid email profileConfirms who you are.
OneDrive, app folder onlyFiles.ReadWrite.AppFolderA dedicated app folder. Microsoft grants this scope against a folder it creates for us, not against your whole OneDrive.
What we never do
We never ask for Files.ReadWrite.All.
We never see your OneDrive outside the app folder.
Not connected yet. No client ID yet. Microsoft app registration also needs a redirect URI and a publisher to be named.
Dropbox
Fourth
Worth doing, last. Smallest overlap with the other three.
Exactly what we would ask for
Sign inaccount_info.readConfirms who you are.
Dropbox, app folder onlyfiles.content.write + files.content.readAn app folder scoped by Dropbox itself, not by us asking nicely.
What we never do
We never ask for full Dropbox access.
We never keep a copy after the hold expires.
Not connected yet. No client ID yet.
GitHub
Later
Sign-in only, and only because some customers already have one. It holds no video, so it is not a storage route.
Exactly what we would ask for
Sign inread:user user:emailConfirms who you are.
What we never do
We never ask for repo access.
We never ask for write access to anything.
Not connected yet. No client ID yet. Lowest value of the four, and the first thing to cut.
What happens to your files, in order
This is the whole round trip. There is no step where your
multicam raw sits on a disk of ours longer than the hold window.
1
Your browser writes straight to your folderNot through us. A 400 GB multicam drop never lands on our disk and never crosses our bandwidth, which is the whole reason this page exists.
2
We pull it over the LAN to work onAn internal network hop, not an upload to a stranger's server. The manifest is hashed on arrival, so what you sent is provably what got worked on.
3
We edit it and hand you the packageLongform, clips, captions, thumbnails, metadata — into the same folder, once. One push, not a sync loop.
4
Seven days, then it is goneA hold window so a re-run is possible without re-uploading. Seven days is the default and it is configurable per order.
5
Then hard delete, everywhereOur working copy and our hold. Deletion is a deletion, not a move to an archive. Export-or-delete is the default outcome, and it is the only one we offer.
No connection exists yet. There is no client ID for any provider, so
there is no consent screen to send you to and no token stored anywhere. The
buttons above record which provider you want and say so rather than opening
something that is not there.
Your browser is not yet uploading direct-to-cloud either. Today a file still
travels through our portal. That is a known gap, not a design choice, and it is
the next thing being built.