1Password Dropbox Migration to "App Folder" Sandbox

full_access_to_app_folder.md

I don't think AgileBits Inc. is so small nor Dropbox Inc. so big that they couldn't cooperate to smooth the migration from full access to app sandbox.

The highlights:

• requires some backend favors from Dropbox Inc.
• supports old clients for a long time during the transition
• allows for keychain location migration to begin immediately

Potential Migration Strategy

In rough chronological order, with much able to be done in parallel.

1Password Inc. deprecates user chosen keychain location used in conjunction with Dropbox syncing. The preferred location will become Dropbox/Apps/1Password/1Password.agilekeychain and upon deprecation of user custom location will be the only supported location.

Dropbox Inc. deploys changes to the Core API:

• these are special exceptions for the Dropbox app named "1Password" (technically the corresponding app key of the 1Password app) only
• the app, once sandboxed, will still retain access to /1/files/dropbox/.ws.agile.1Password.settings. That will be the only resource under the dropbox root that will continue to work; all other requests must be made under the sandbox root, e.g. /1/files/sandbox/1Password.agilekeychain
• prior to sandboxing, calls under the sandbox root succeed and resolve to Dropbox/Apps/1Password (currently these would fails with 403 error for a non-sandbox app)
• together these form a new permission -- call it App Folder Migration -- that is the union of Full Access and App Folder permissions including the existence of sandbox folder at Dropbox/Apps/1Password.
• optionally, Dropbox Inc. will support "merging" any existing Dropbox/Apps/1Password user folder; this decouples keychain location migration from deployment of these Core API changes and allows migrations to begin much sooner

Dropbox Inc. deploys "behind the curtain" changes:

• effectively /dropbox/.ws.agile.1Password.settings and /sandbox/.ws.agile.1Password.settings become the same resource, analogous to filesystem hard links
• changes made to /dropbox/.ws.agile.1Password.settings or Dropbox/.ws.agile.1Password.settings are automatically reflected in their sandbox counterpart and vice versa
• only .ws.agile.1Password.settings has this behavior; the 1Password keychain doesn't share this behavior

1Password Inc. releases updated clients. New mobile clients only request resources under the sandbox root; including the settings file at /sandbox/.ws.agile.1Password.settings which will exist there if it exists at all.

Dropbox's selective sync makes new desktop clients more complicated:

• use Dropbox/Apps/1Password/.ws.agile.1Password.settings if it exists
• otherwise, if Dropbox/.ws.agile.1Password.setting exists, request that user changes selective sync to include Dropbox/Apps/1Password (or inform them and change it for them)
• otherwise, existing workflow for when client can't find settings file

Mobile client:

• read contents of /sandbox/.ws.agile.1Password.settings
• if path is Apps/1Password/1Password.agilekeychain proceed to sync with /sandbox/1Password.agilekeychain
• otherwise, inform and migrate the keychain location

Moving the keychain is the one exception where mobile clients use the dropbox root. For example, the 99% case of moving from the old, standard location to the sandbox:

POST https://api.dropbox.com/1/fileops/move

root=dropbox&
from_path=1Password.agilekeychain&
to_path=Apps/1Password/1Password.agilekeychain

Time passes, Dropbox Inc. changes 1Password app permissions from App Folder Migration to App Folder.

Sync behavior:
                migrated    old
                keychain    location
 
desktop (new)   ok          partial
desktop (old)   ok          partial
 mobile (new)   ok          broken
 mobile (old)   fails       fails

• desktop clients with old keychain location: can only sync with other desktop clients
• new mobile clients with old keychain location: keychain no longer accessible and cannot be migrated via API; client can detect this situation and direct user to manual migration
• only new desktop clients can migrate old keychain location automatically
• old mobile clients: fail attempting to fetch /1/files/dropbox/.ws.agile.1Password.settings
• likelyhood of divergent keychain locations for old and new clients reduced via linked .ws.agile.1Password.settings

More time passes, Dropbox Inc. removes all special support for 1Password including the linked behavior of Dropbox/.ws.agile.1Password.settings and Dropbox/Apps/1Password/.ws.agile.1Password.settings.

Sync behavior:
                migrated    old
                keychain    keychain
 
desktop (new)   ok          partial
desktop (old)   partial     partial
 mobile (new)   ok          broken
 mobile (old)   fails       fails

• desktop clients with old keychain location: can only sync with other desktop clients
• new mobile clients with old keychains: direct user to manual migration
• only new desktop clients can migrate old keychain location automatically
• old mobile clients still fail
• divergent keychain locations for old desktop clients and new mobile clients more likely; only new desktop client can detect this

Effort and Timing

Neither a trivial nor a tremendous amount of work. Everything is backwards compatible up to the point when 1Password is reduced to just App Folder permission. Given a commitment by Dropbox Inc. to make the proposed changes, 1Password could begin the campaign to have users relocate their 1Password keychain to Dropbox/Apps/1Password as soon as App Folder Migration permission is deployed (or sooner if Dropbox Inc. also commits to merging pre-existing Dropbox/Apps/1Password folders).

1Password is certainly not the only app using full access for mostly historical reasons. The strategy I present can be used by other apps to migrate from full access to sandbox. If so, then the initial effort by Dropbox Inc. for 1Password's migration can be somewhat amortized over subsequent app migrations.

Effort does effect timing, but more than that, 1Password must allow time for users to migrate. This clock really only starts ticking once 1Password commits to this course of action; somewhat analogous to why it takes a long time for web browser bugs to leave the ecosystem. In short, even if they announced this plan today, your 1Password OAuth token will have Full Access for a long time to come. Barring a high profile data loss or data theft event, my guess is 18 months from a blog post announcemnt to a sandboxed 1Password OAuth app.

Why it matters

A screenshot demonstrating that full access is "not unusual at all" is a bit disingenuous given the evolution of app syncing via Dropbox. Of the 9 apps listed in the screenshot: 3 are 1Password clients; 1 is an app now owned by Dropbox Inc. (Mailbox); 2 should be sandboxed (ShopShop, Podcaster for iPhone); 2 are text editors (Elements, Plaintext) that look like they could be sandboxed based on their advertised workflows; leaving 1 app (DropDAV) that truly requires full access.

1Password has jeopardized our Dropbox OAuth token once already. This isn't about "trust[ing] us not to abuse file system access." It about not-trusting the attacker who gets their hands on my 1Password OAuth token.

I echo an earlier sentiment when I say that it seems incongruous for a company that specializes in securing our information to have an (apparent) low priority for this. Especially considering the amount of effort involved and inherent amount of calendar time that must elapse after a public committment to move to a sandboxed Dropbox app.