Saturday, February 02, 2013

Sharing a credential store for a family (or small business) - and the end of the personal database

I have managed family credentials and web site data in a FileMaker database since 1996 [1]. That database now holds over 1600 records, of which at least 1200 are historical (dead accounts, obsolete urls). The historical items don't get in the way as much as one might think, and I kind of like this mini-history of the net.

This repository has survived many technology transitions. Over the past 10 years it has more-or-less synchronized with credential stores running on PalmOS and iOS. At some times I've used FileMaker sharing (web publishing and the IP based fmnet: protocol) to allow my wife to access and edit both of our credentials too. (I am too boring to have any secrets, and it's critically important that she have credential access if I'm unavailable -- as in dead.)

Alas, all things must come to an end. FileMaker and its half-baked replacement "Bento" are both dying. Filemaker Go, which I'd like to use on my iPhone, doesn't support true synchronization. Bento is supposed to have some synchronization capabilities with iOS clients, and there's some form of encryption on the desktop version, but I don't know of anyone using this product. Bento feels stillborn.

So while I could probably cobble together a solution using some combination of FileMaker licenses ($180+ each) and or FM 12 web sharing (Mountain Lion broke FM 11 web sharing [2]) -- but then I'm investing in a dead technology niche.

There are other issues with the way I use this credential store. I've been maintaining it in FileMaker and exporting to 1Password for iPhone access, but that means my iPhone repository is read-only. The update loop is slow; sometimes I don't have credentials on hand.

It's time to move.

After consultation with appnetizens there appear to be 3 solutions:

  1. Use 1Password with Dropbox. (I'm still on iPassword 2, but it works similarly. I don't mind upgrading anyway.)
  2. Use some other Cloud solution, such as shared Google Doc or Spreadsheet, Simplenote, etc.
  3. Use 1Password on her iPhone only (see below). [1Password 2 only - see update.]

The first two require the Cloud. I don't like that - for several reasons [3].

That leaves option 3, and that only works because 1Password runs constantly on my always-active account and 1Password on the desktop can support multiple iOS clients. It's not perfect as it gives her credential access only via her iPhone; but since we do use Google Sync that's less of a problem than it might be [4].

I think we'll try option 3, which implies I'm going to treat 1Passwords as the "source of truth" and slowly archive my last FileMaker database -- and then FileMaker itself.

RIP old friend.

Update:

Well, that's interesting. Technology transitions are rarely smooth. It's not clear that there is a non-Dropbox solution any more. I think I'll keep Filemaker on life-support a bit longer.
 
Incidentally, There's something disturbing about how 1Password syncs. Watching the behavior it's almost as though it replays every transaction that's every occurred on 1Password desktop; implying it still keeps fully deleted credentials. When I updated the cache 10,000 records were processed for 1,500 credentials. Looking at my backup history the agilebits keychain file is growing at a rate consistent with retention of deleted credentials. I think the only way really clean it out is to delete the keychain and start anew.

--

[1] FileMaker is a survivor from the pre-net era of software, when geeks used personal databases for address books, recipes, PDF based document management, record and CD collections,  archives of thousands of stapled paper medical journal article archive indexing with pre-web "Grateful Med" MEDLINE metadata (Grateful Med), club memberships, and much more. With a relatively large user base FileMaker was then quite affordable.

I will now interrupt this post to admit that review of those web 1.0 pages, and particularly the data store transformations of the past 8 years, has given me a dose of old-guy future shock. When I started researching this topic I didn't realize I was also writing an obituary for the personal database!

It has been one hell of a ride from my 1990s FileMaker article file to Google and the Strata conference I'll be attending in Santa Clara this month.

[2] I tried reenabling Apache on ML using a freeware pref pane. Apache ran, but FM web sharing still didn't work. Looking at the FM 12 writeup I think it barely works even there.

[3] Example: An encrypted database store is forgotten in the cloud. Six years from now, when Dropbox's assets have been acquired by the Russian mafia, 2012 encryption is trivially broken. I don't want this store public even in 2019. Not to mention the LastPass breach.

[4] So why do I allow that form of Cloud use? Good question.

3 comments:

  1. Read-only 1Password access works in every modern browser too. You could host your 1Password keychain on your own server (maybe a local server at home) and grant access to your wife.

    I have mostly given up on cloud worries as long as my data is somehow encrypted. There is simply no other easy way to sync data between various machines for offline access. It is annoying enough that iOS apps like 1Password cannot sync automatically in the background, i.e., it is still up to the user to maintain a +/- up-to-date sync state on all devices.

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. 'd forgotten about the web access model, though practically speaking I'll have to go Cloud to use it.

    Via ADN I learned that Dropbox supports Google Auth. That makes me trust Dropbox option more than iCloud.

    Still left with the fear that abandoned data gets hacked once 2013 encryption is obsolete (2018?) -- or that 1Password encryption is not perfectly done (terribly hard to do it seems).

    Agree that all other sync options seem to have been abandoned. (OmniGroup carries on though!)

    Good point about the iOS background sync limitation. Apple is not helping us (as usual).

    ReplyDelete