[export] Fields are exported unsafely

[logic]

Field export appears to be a naive <NAMEn>: <VALUEn>\n export (each pair on a separate line, separated by colon-space, no escaping done of name or value data), and the field type (0/text, 1/hidden, 2/boolean) is lost in the export.

For safety, Name and Value should be escaped such that the separator can be located unambiguously. As well, the field type should be included.

Rather than doubling down on hand-rolled serialization, perhaps it would be simpler to export the entire field list as a JSON blob (letting the CSV export handle quoting/escaping as needed) that strictly matches the original data structure (but with Name and Value unencrypted)?

[kspearrin]

It would be simpler to make the whole thing JSON, but part of the point of it being a CSV file is that people can use a spreadsheet program like excel to build and modify their dataset. Obviously there are edge cases where this could be a problem but I am not sure of a better alternative for hierarchical data in CSV.

[logic]

Right, I'm definitely not advocating for switching the core format (it's obviously more useful if people can use ordinary tools that they'll have access to day-to-day to work without the output); only that, as currently specified, the data in bitwarden is exported in a manner that can't be re-imported unambiguously (field and record separators need escaping, which picking an off-the-shelf serialization format would resolve, even just an embedded CSV 😉) and without losing data (field types are lost; also, #148), making this somewhat less useful as a backup for users.

(The real problem is trying to represent an arbitrarily open-ended data structure in a single fixed-width table like this in a way that's actually useful. I'm sure this worked really well before the introduction of fields. 😉)

But perhaps this is a good argument for discussing what an export format whose purpose is backup/restore (rather than "user interaction") might look like?

[kspearrin]

@logic If this didn't need to be human consumable we would definitely use JSON. Perhaps the answer here is we just need to offer a JSON formatter import/export.

[kspearrin]

This is also the reason we don't offer cards/identities in the export at this time. There are just too many fields to represent in CSV format.

[brantaxt]

I'm transitioning from a small password storage system called "Pocket" that was recently discontinued. I was transferring everything to bitwarden when I encountered the import/export issues. Here is the solution that Pocket used for the "too many fields" issue in the .csv format. I'm not a javascript programmer, so I can't recommend implementation, but perhaps this can give an idea of something that works.

The first two columns were "Type" and "Name" which were mandatory for all "Types". Following these, it was "field name 1", "field entry 1", "field name 2", "field entry 2".... etc.
For example in regards to bitwarden:
all type "logins" would have:
"login", "[login name]","Username","[username info],"Password", "[password info]", "Note","[note info]", ... "[Custom Field 1]", "[Custom Field 1 info]", etc....
and "cards" would have:
"card","[card name]","Card Number","[card number]","Exp Month","[exp month]", etc....

I realize that this would make the csv larger, you would have to remove the heading line, and all data values would be made into strings, but it is at least a solution I see that would be general enough for every possible change between password managers out there.

Pocket did it this way because they also allowed the user's to create custom "Types" with custom fields. I think the large customize-ability led to this format.

I hope this information is useful at least as reference.

[bradyjoh]

@kspearrin Too many fields to represent in CSV format? What do you consider too many? At least in my professional experience, we frequently see CSV files with 50-70 columns and sometimes more.

I also don't see anything preventing dozens of custom fields being added for Login items. Is there a restriction on it?

Happy to talk more about this if you want.

[kspearrin]

A JSON export is now available with all info safely serialized, which should resolve this issue.