Separating the account from other data for a few reasons:
Long-term, the signing activity will be done by a separate function, even a different app.
When backing-up & restoring, dexie-export-import exports the account unencrypted, and I feel the sensitive identifier data needs to be stored externally more securely than the rest of the data. (It's possible to filter out the identity & seed info, but then the table export has 0 elements so an import will erase the data.) This is one of the main reasons I took this action today.
For internal signing, the private data should be exposed as little as possible; this will allow us to open and close the DB separately for the signing activities.
Separating the account from other data for a few reasons:
* Long-term, the signing activity will be done by a separate function, even a different app.
* When backing-up & restoring, dexie-export-import exports the account unencrypted, and I feel the sensitive identifier data needs to be stored externally more securely than the rest of the data. (It's possible to filter out the identity & seed info, but then the table export has 0 elements so an import will erase the data.) This is one of the main reasons I took this action today.
* For internal signing, the private data should be exposed as little as possible; this will allow us to open and close the DB separately for the signing activities.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Separating the account from other data for a few reasons:
Long-term, the signing activity will be done by a separate function, even a different app.
When backing-up & restoring, dexie-export-import exports the account unencrypted, and I feel the sensitive identifier data needs to be stored externally more securely than the rest of the data. (It's possible to filter out the identity & seed info, but then the table export has 0 elements so an import will erase the data.) This is one of the main reasons I took this action today.
For internal signing, the private data should be exposed as little as possible; this will allow us to open and close the DB separately for the signing activities.
Hm... I didn't see a notification that this was merged.