Import from SplashID

@sjk - I'm thinking about making a SpashID converter module for my new version of converter script (which is now wallet-module based).

I've looked briefly a the V2 and V3 vld formats, and haven't spent too much time figuring out the differences. Do you know what they are?

@echo - how many different card types do you have, and which ones are the most important. Also, do you have any or many customizations to the fields or custom types?

OK, I see what the differences are. The V3 version of the file contains a few more fields, and fixes some missing labels. I haven't seen the V4 header, but I'll see what I can find.

The VLD (I don't have a V2 labelled menu) export is presumably supposed to be the default name for the latest export version. The other one seems mislabeled. Who knows, but these are pretty silly bugs for the developer to have not caught and fixed. And for some goofy reason, the developer decided to save one cell in the export CSV, so all the data is shifted left one cell, so the text labels above do not align when imported into a spreadsheet. No wonder so many folks have trouble with getting the data correctly imported into another program.

I'll take a look at creating a converter tomorrow.

You'd be able to specify your own custom sections in the converter to handle your custom cards. If you have only a handful of custom cards using your custom types, it probably won't be worth your time to add the custom table entry, but if you have many, it is pretty easy and I can help you define it.

The converter will determine the card's type, and meaning of the fields, entirely by pattern matching the strings you've used for the field names (there is more than can be done here, but this would be beyond simple user customization). If you've named fields in an ambiguous fashion, then the converter won't know one wallet entry from the next. In other words, each card must have at least one field name that uniquely identifies it as belonging to a particular type, and the table of fields for that type will drive the determination of the 1P4 destination category, and how each field is placed into that 1P4 entry (including splitting some of the fields into an entirely different 1P4 entry / category).

Let me know if this sounds useful.

Thanks AgileByte,

The SplashID (for Mac) seems to export using the Mac Roman convention.

This was the perfect hint, and it didn't even occur to me since the Mac Roman encoding was deprecated since OS X's introduction.

Here's the completed converter in action:

You're welcome.

I don't do anything with the attachments, and I haven't spent any time trying to figure out how they are encoded or encrypted. A key is exported, as is the storage location within the exported bundle. Since their documents indicate that the attachments can only be re-imported into another SplashID, I suppose they are encrypted with the wallet's master key. If that's the case, I don't get the reason for that form of export (as it seems redundant since a Backup seems to be a v4.0 vID bundle anyway).

I've updated the archive in my _testing folder, as I've now completed the transition to the new converter module system. Along the way, I completed all the card types for each converter, and added two new converters (SplashID and OS X Keychain), so we now have 9:

Clipperz Ewallet Handysafe Keepass2 Keepassx
Keychain Lastpass Msecure Splashid

These have all been tested on OS X - I still need to retest again on Windows.

I'll take a look at RoboForm next.

"Card" is a term I've used for a long time, probably it initially came from eWallet, a Rolodex, or business card contact. Various password managers use different terminology, and since I'm in the middle of each, I find myself waffling about the best term. Sometimes I use "item", sometimes "card", sometimes "entry". Any advice?

Hold on, I'm checking on both of your issues now...

Hi @Newell,

You're welcome, and I'm glad you've at least imported your records.

As to category switching, it is on AgileBit's List of Good Intentions. The problem appears to be more difficult than users recognize, due to how behaviors and the UI are driven by categories. Categories have specific meanings in 1Password, whereas in other password managers they are essentially free-form tables of data. That said, I recognize your plight. As a user, I've wanted to switch some records in the past as well.

The converters I've written can be customized with relative ease to accommodate most needs, and try to do "the right thing" for source categories, placing them into one or more appropriate target (1Password) categories. I'm wondering which version of converter you used, as the converter supports the following (from the --help usage output, see the supported import and export types below):

$ perl convert_to_1p4.pl splashid --help

Usage: convert_to_1p4.pl <converter> <options> <export_text_file>

converters:
    clipperz ewallet handysafe keepass2 keepassx keychain lastpass msecure safeincloud
    safewallet splashid

options:
    -d or --debug              # enable debug output
    -e or --exptypes <list>    # comma separated list of one or more export types from list below
    -h or --help               # output help and usage text
    -i or --imptypes <list>    # comma separated list of one or more import types from list below
    -o or --outfile <ofile>    # use file named ofile.1pif as the output file
    -v or --verbose            # output operations more verbosely
          --nowatchtower       # do not set creation date for logins to trigger Watchtower checks

supported import types:
    bankacct clothes combinations creditcard email files frequentflyer identification
    insurance membership note phonenumbers prescriptions serialnum server vehicles weblogins
supported export types:
    bankacct creditcard email login membership note server

The mapping of import to export categories is table driven, and the table can be changed, per category and/or per field within a category. If you can describe which aspects you need changed, specifically, we can work together to find something that might better work to your needs.

Converting password manager exports is a moving target, and is a one-shot. I think the AgileBits folks are prioritizing where work is done.