3 ms·

The thing is that due to the synchronization, users post could be synchronized to another site which they are not registered to. Thus, a mechanism must be setu

by rqs 8y ago

The thing is that due to the synchronization, users post could be synchronized to another site which they are not registered to. Thus, a mechanism must be setup to allow users to manage their content on other sites. The mechanism that I currently planed was to use email verification (if (User's email === poster's email): They're the owner of the post), which requires all sync sites knows the email address (as an universal identifier) of the content owner. To me, that means I need to share user's email with other sync parties which may not under my control. Because of that, I think it's sanctimonious to tell user that their email is under protection, I rather letting user be very aware about their email will be publicly displayed. Another reason to publicly display users email is because I don't want to implement private message features (Which require to save private information), so if user's can know each other's email, they could just make content with their emails.

geofft 8y ago
How does this handle people changing their emails? Can you do the same thing with a cryptographic signing key or something, instead? It seems like this could be implemented in a way where I prove control over the signing key (by signing a challenge, for instance), but I don't have to reveal anything about my identity besides "I have access to this key" if I don't want to. (If you're worried about not just servers changing but clients changing, and needing to get the key over, there are protocols for efficiently and securely transferring information between client computers, using a very short password that doesn't need to be kept private after the transaction. magic-wormhole implements this sort of thing.) This may or may not apply to your site, but, in general I don't want other users of a website to be able to PM/email me unless I specifically authorize them to. Requiring that my email is public does not provide me this control. You can do what HN (which doesn't implement PMs) does and let people have an optional public profile, where they can list a way they want to be contacted by other users if they want.
- rqs 8y ago
  > How does this handle people changing their emails? It can, as long as the email change request can be synced as well. It may have some security problem need to be resolved, but I think it can be worked out. > Can you do the same thing with a cryptographic signing key or something, instead? It's actually an better idea. If I can implement something like PGP (With maybe WebAuth), then user only needs to submit their public key. When authentication is needed, server will sends challenge (Message encrypted by user's public key), then user decrypts it with their private key, send the decrypted message back to server for verification. However, I'm still figuring out the whole WebAuth thing, so no decision is made yet. > This may or may not apply to your site, but, in general I don't want other users of a website to be able to PM/email me unless I specifically authorize them to. I actually like to encouraging user to make contact by themselves with their emails, because service email is decentralized and controlled by users (At least they have better control of it than a website). Also, user may left a website but still using their email. However, I know in real world, people don't like to be bothered, so make their email public could be a problem. I guess I need to rethink it a little.

by rqs 8y ago

geofft 8y ago

How does this handle people changing their emails? Can you do the same thing with a cryptographic signing key or something, instead? It seems like this could be implemented in a way where I prove control over the signing key (by signing a challenge, for instance), but I don't have to reveal anything about my identity besides "I have access to this key" if I don't want to. (If you're worried about not just servers changing but clients changing, and needing to get the key over, there are protocols for efficiently and securely transferring information between client computers, using a very short password that doesn't need to be kept private after the transaction. magic-wormhole implements this sort of thing.) This may or may not apply to your site, but, in general I don't want other users of a website to be able to PM/email me unless I specifically authorize them to. Requiring that my email is public does not provide me this control. You can do what HN (which doesn't implement PMs) does and let people have an optional public profile, where they can list a way they want to be contacted by other users if they want.

rqs 8y ago
> How does this handle people changing their emails? It can, as long as the email change request can be synced as well. It may have some security problem need to be resolved, but I think it can be worked out. > Can you do the same thing with a cryptographic signing key or something, instead? It's actually an better idea. If I can implement something like PGP (With maybe WebAuth), then user only needs to submit their public key. When authentication is needed, server will sends challenge (Message encrypted by user's public key), then user decrypts it with their private key, send the decrypted message back to server for verification. However, I'm still figuring out the whole WebAuth thing, so no decision is made yet. > This may or may not apply to your site, but, in general I don't want other users of a website to be able to PM/email me unless I specifically authorize them to. I actually like to encouraging user to make contact by themselves with their emails, because service email is decentralized and controlled by users (At least they have better control of it than a website). Also, user may left a website but still using their email. However, I know in real world, people don't like to be bothered, so make their email public could be a problem. I guess I need to rethink it a little.