![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
Replying to comments from the emailed notification
The form at the bottom of the comment notification email contains a comment-specific hash, which authorizes the person posting the form as the user the notification was sent to. This is useful for replying if you're not logged in, or if you're logged in to another account (multiple journals, etc). But it also means that if you forward the comment notification email to someone else, they can reply as you for that particular comment.
This came up in Bug 314, after noting that one fix to allow OpenID users to reply to comments from the email had the side effect of removing the existing behavior -- the person posting the comment would have to be currently logged into the same account as the one which received the emailed notification for the comment to be posted.
D says this is a good thing! And I kinda agree, because it's good to close up the security hole. But I'm torn because I also really like the convenience of the existing behavior.
So, throwing ideas out there for how we can handle it:
a.) make it clear that the authorization is tied to the comment form, and that forwarding the notification email with the form to someone else will allow them to reply as you to that comment. Do it on the form itself, either subtly (changing the "post" button to "post as $user"), or by adding some kind of text; document this behavior somewhere people can easily find it.
This is pretty easy to do, but may not be effective, and may cause worry to have warning text.
b.) close the hole by showing an error message if the account you're trying to comment as does not match the account you're logged into.
Also easy to do, but pretty drastic.
c.) close the hole by forcing you to authenticate as the commenting user if it does not match the account you're logged into (More details, from Sophie).
I like this idea because it's not as drastic as option (b), and it looks relatively simple to implement. But it could also get annoying to have to reauthenticate all the time, depending on how often you'd have to switch accounts this way.
d.) provide another way to reply, perhaps by replying to the email directly, instead of using a form. (More details, from me).
I'm in favor of this idea because it solves a few other problems -- means you can always reply from the notification if you have access to an email client but not a browser (phones, DW blocked, composing comment replies offline), or if you're using one of the clients which disallows POST requests (off the top of my head, Thunderbird won't allow this). Also means no need to switch logins in the browser.
But it's the most drastic change to implement, and I don't know how much additional load it would cause to set up something that can receive email, parse it in a timely fashion, and post the comment, plus the time we would need to spend to build something from scratch.
e.) Other ideas?
This came up in Bug 314, after noting that one fix to allow OpenID users to reply to comments from the email had the side effect of removing the existing behavior -- the person posting the comment would have to be currently logged into the same account as the one which received the emailed notification for the comment to be posted.
D says this is a good thing! And I kinda agree, because it's good to close up the security hole. But I'm torn because I also really like the convenience of the existing behavior.
So, throwing ideas out there for how we can handle it:
a.) make it clear that the authorization is tied to the comment form, and that forwarding the notification email with the form to someone else will allow them to reply as you to that comment. Do it on the form itself, either subtly (changing the "post" button to "post as $user"), or by adding some kind of text; document this behavior somewhere people can easily find it.
This is pretty easy to do, but may not be effective, and may cause worry to have warning text.
b.) close the hole by showing an error message if the account you're trying to comment as does not match the account you're logged into.
Also easy to do, but pretty drastic.
c.) close the hole by forcing you to authenticate as the commenting user if it does not match the account you're logged into (More details, from Sophie).
I like this idea because it's not as drastic as option (b), and it looks relatively simple to implement. But it could also get annoying to have to reauthenticate all the time, depending on how often you'd have to switch accounts this way.
d.) provide another way to reply, perhaps by replying to the email directly, instead of using a form. (More details, from me).
I'm in favor of this idea because it solves a few other problems -- means you can always reply from the notification if you have access to an email client but not a browser (phones, DW blocked, composing comment replies offline), or if you're using one of the clients which disallows POST requests (off the top of my head, Thunderbird won't allow this). Also means no need to switch logins in the browser.
But it's the most drastic change to implement, and I don't know how much additional load it would cause to set up something that can receive email, parse it in a timely fashion, and post the comment, plus the time we would need to spend to build something from scratch.
e.) Other ideas?
no subject
Other than that, I've no particular opinion. I still have my comments sent in plain text like Cthulhu intended, so have no clue what desired behaviour would be.
no subject
* Proof that the reply came from replying to the mail, not via a newly-forged email. Replying by email is convenient, but we have to make sure that nobody can forge an email as somebody else.
* The journal name, entry ID and comment ID being replied to.
* Anything else?
Ideas on passing that information:
* We could pass the information as a hash in the subject line. However, this breaks threading in applications that use the subject line for threading, which to my knowledge includes GMail. It also looks a bit ugly, and could trigger spam filters.
* We could pass the information via a specially-formulated Reply-To address which would be parseable to give the info needed. (Note: We should *not* use the From address as a generic Reply-To address as this will mean that users can't add an address to their spam whitelists. That's something that really peeves me about Second Life offline IM notifications.)
* Others?
About the methods used to authenticate the email:
* For security, we should never just have the credentials as a single, standalone hash; this can be copied and used in forged emails very easily. This means that if credential hashing is used, we should *also* hash it with other data, like the entry and comment IDs, which is how it's currently done in the ECP hash. (I would suggest adding journal name to that hash too.)
* We could also use one-time hashes that are randomly generated by LJ for each email. However, doing this would mean both that the user would not be able to reply to the same comment twice from the same email, and also that we would need to expire the hash after a period of time - say, six months. The expirataion thing probably wouldn't be a problem, but I can see the first bit being annoying.
* There is little point in combining both methods, as the problems in the second point would still arise, and there will be no way to interactively ask for a username/password to confirm.
Random other comments:
* We will need to strip signatures and quoted text from the email. The DW code already strips signatures as part of the email posting mechanism, but I don't think it strips quoted text.
* We need to be able to have the capability to parse quoted-printable and/or HTML in case someone replies using that format. (this capability is probably already in email posting)
* Email programs tend to wrap emails to 78 characters a line. In the case where someone replied in plain text (not quoted-printable format or HTML), should we try to reconstruct the original lines or just leave the lines wrapped? (this question is also probably already answered in email posting, too)
Is there anything I've missed here?
(I'm personally still a fan of option (c) in your post; I think re-authenticating is a small price to pay in this case.)
no subject
no subject
Though, IIRC, friends-locked posts won't let one reply via email (but I'd have to double check that).
no subject
It is not a security hole because this feature is entirely by design. Just because it doesn't do what someone expects doesn't mean it is a violation of security or otherwise "bad." Call a fish a fish, don't call it a shark.
a) won't work because users don't read.
d) how will this actually change anything? It's easy to spoof the "From" of an email unless you put some token in the email. And then you're right back where you started: someone forwards it, the receiver spoofs it, and we didn't solve anything.
I prefer B to C, but either would be fine. Except!
Why even bother? This "issue" has been in existence on LJ for years and years and years and ... well, years. And I'm sure it's generated a complaint from time to time, but really? You don't forward emails to your enemies. When you forward a comment mail to a friend, they're not going to do Evil Things In Your Name! (And the only evil they can do is make a comment.)
If you DO forward it to someone who you don't want to have it, then - oh well! You can deal with the fallout from having them say something bad in your name. And then you tell the person they replied to that you're sorry and the problem is solved without spending a ton of development time reimplementing this. :)
no subject
(Which reminds me of the huge fish I ran into the one time I went diving. Big as my torso. I thought it was cute until it opened its mouth and I realized that it could take my whole hand in its mouth if it were so interested. It wasn't. I was scared anyway! Diving master probably laughed at me for days ;-))
I have the vague idea you could handle spoofing the same way emailposts does, but that involves some sort of PIN you need to type into each address, right?
I like (d) because it preemptively solves a lot of minor annoyances for me, but I don't think I like it enough to put in the effort and code to fix the new problems it does solve!
Which is to say, I'd be happy with (c) if we do decide something needs to be done.
For that last bit, could you take a look at Bug 314? I think no one's touching the patch until we're sure whether we want to change the existing behavior or not. I know I, for one, am not going to be able to review+ or review- because I have the feeling there's an administrative decision to be made!
no subject
Default is to force users to authenticate, because it's expected and safe behaviour.
There's an option in account settings that you can select that basically says "send me insecure emails that I can reply in/to; and I understand that if I forward them, someone else can reply as if they're me".
Then I can use my phone to reply to emails, without firing up my browser.
no subject
no subject
no subject
no subject
tgbgqk
(Anonymous) 2009-04-25 12:43 am (UTC)(link)plRLlHHSigMqGIOge
(Anonymous) 2009-04-25 08:34 am (UTC)(link)uLMUsKdeHdbaVBxyK
(Anonymous) 2009-04-26 12:22 am (UTC)(link)