Personal Data Import/Export

@flaburgan I was talking about server to server authentication, not client to server.

Hm, if the new pod is able to know that the user who wants to import data is the one who is connect on the old pod, the problem is solved, isn't it ?

How do you prove to the other pods?

Jonne, I'm not sure we need such rigorous authentication if we're talking about a two-step process, as follows:

1. User exports their entire account data to a local file on their machine.
2. User creates account on new pod and imports account data file to new account.

Only the authenticated user of the original account will be able to export the data from that account, and if they're downloading it to their local machine before uploading it to the new pod, unless they do something stupid, the file won't get into third-party hands.

If we're talking about direct transfer of account data from one pod to another pod, then yes, secure keys will be needed.

@flaburgan i looked into it, and while Persona would be our choice for SSO i don't think it's what we need here. i'm not going to rip out our entire authentication system so we can add one little feature.

@jonneha an alternative idea to this is tokens. say a user downloads their data from podA and wants to migrate to podB. we could embed a token inside the archive in a JSON somewhere, then before an upload happens on podB, the server checks the token (like a checksum) against podA's /user/:id/token endpoint and makes sure they match. if they don't, that archive didn't come from podA and it's an impostor. this allows podB to "make sure" the user in question is actually coming from podA. it proves identity, and IMHO building a system where identity doesn't matter is just opening the floodgates for spam and other social engineering.

i don't think most people are observant enough to notice [email protected] is not the same as [email protected]. Especially with the exact same profile, exact same pic, exact same status updates. It would be less obvious if it was something like [email protected] vs. [email protected]...

@goob again, there's no way to prove that said User is in fact the User from their originating pod. I personally think identity matters, and identity isn't just your login@pod_host.com...

My aim would be a seamless migration, lets say we have bob@podA who friendes alice@podB and wants to move to bob@podC. I'd like to have the contact for bob and alice on podB change without any action from alice. This could be done by sending a "I'm here now!"-kind of message from podC to podB. The only way for podC to prove that he now owns bob@podA is signing that message with bobs existing private key, podB already has bob@podA's public key and can thus verify it and update all records.

@tomscott I think you're missing the point of what I said.

There is currently nothing to stop me from opening an account on a pod under the name Tom Scott, and pretending to be you. However, what I won't be able to do under the scheme I outlined is to import your account data from your existing account to the new fake account I have set up, because I won't have access to the account data. Only you (and, perhaps, your podmin) have access to those data, so only you will be able to create a new account and import the data from your existing account. I suppose a simple key could be added to the data export, which the new pod could then check with the old pod to confirm that this is a genuine export from the old pod.

@jonneha if you think a seamless transfer is feasible, that would be far preferable. It may prove to be the easier way of transferring all the connections with other accounts. The only thing I'd add to what you said is that from a privacy point of view it might be wise to notify Alice (and others) that

'Your contact Bob has moved his account to podC. Click here to confirm that you are happy to continue sharing with him at this new pod, or click here if you wish to stop sharing with Bob'.

Reason being that Alice might feel she can't trust the podmin of podC and doesn't want anything to do with it, nor for any of her postings to be potentially available to that podmin through her sharing with Bob. There may be no logical reason for her to feel this way, but Diaspora seems to be all about being up-front with exactly what's happening with your data, so it would, I think, be good to notify a person's contacts when that person moves pods, just to make people aware of what is happening and allow them to make the choice of whether to continue sharing.

I suppose, when someone starts the process of migrating to another pod, a pop-up could be shown them to notify all their contacts 'Hi, just to let you know I'm moving to podC. This won't affect our contact and you don't need to do anything' so that Bob's contacts know in advance.

@goob i see what you're saying. i think we're on the same page. :)

what do you guys think is easier though, a seamless transfer from pod->pod where we have to test and code every step of the process, or allowing humans to do the downloading and uploading of data, as long as the server(s) maintain the authorization process. i'm thinking the latter would be much easier to implement and just as secure as if we had pods take care of the "whole shebang"

I think the seamless transfer Jonne is talking about is best as an ultimate aim, but suspect there is a lot of coding and checking to do on the way to that. I think a two-step manual export/import could work well as a stop-gap measure, allowing those who really want to do so to migrate pods sooner than later. (I'd like to, as I want to set up my own pod, and this is one of the things which is stopping me.)

If the manual two-step process, perhaps with an authentification key as part of the export package, is easy to implement and can be done soon, I'd say let's implement that as an interim measure, and work on the seamless migration in the longer term.