Delivery reports for PUSHed messages?

[peti]

SMS messages support the notion of a delivery report that allows me to see when a message was actually delivered to the recipient. I miss that feature for PUSHed messages, though. It seems there is no way to request a delivery report?

[donjoe0]

I agree this would be nice to have, but only if each recipient has the option to turn it off. The way it's currently implemented on Facebook and in WhatsApp etc. violates users' privacy.

[lablans]

Yep, people are of different opinion regarding this matter.

Best would be to be able to turn this on/off as a recipient.

[L3st3r]

+1 That's a nice feature when it's optional.

[fd0]

It would be very nice to have such a feature, this could mitigate #970 ...

[generalmanager]

+1 if they can be disabled

[ncruces]

Don't really agree that a delivery report violates receiver privacy. Even email has "non delivery reports" (bounces). Other apps implement read receipts, which is something else entirely.

[donjoe0]

E-mail (non-)delivery reports only tell the sender if the recipient's mail server got the e-mail, not if the recipient's terminal device got it. When you get a receipt confirmation (the second check mark) in WhatsApp you know at least that your message's recipient has just enabled their phone's data connection, which is like snooping into their lives from a distance - users who don't want you to know what they're doing with their mobile device should have the option to disable the sending of such confirmations from their device.

[bogeyman]

+1 and a first time run wizard asking you, if you want to disable this by default

[L3st3r]

We should pay attention not to overload the wizard too much. It is already pretty extensive compared to other messenger apps and other proposed issues for this wizard are in my opinion more important (like the default behaviour for SMS/PUSH #697).
Therefore I would suggest to enable this by default and add an option for disabling in the settings. That's also how Threema handles it.
We could of course also choose an opt-in approach, but I think the average user switching from apps like Whatsapp or Facebook will expect this feature and most users don't want to dig into the settings.

[bogeyman]

L3st3r +1 :)

[generalmanager]

I'm with @L3st3r on this one - our setup procedure is already very complex in comparison to W**sApp and others and we should not turn off a features the vast majority of the users expect. We may automatically turn it off in the higher settings of #838 for privacy reasons but not give it it's own wizard.

[donjoe0]

Except it's a "feature" that violates other users' privacy and if TextSecure is going to differentiate itself on the market by being a more security-aware application then it should have security features turned on by default and privacy violations turned off by default. You don't always need to imitate all the bad habits of other applications just to make your app more popular.

[generalmanager]

@donjoe0 please read #838 on that point.
It's a proposal to let the user choose the privacy/convenience level he needs on first start and choose sane default settings based on this choice. This would be a good example to turn off in the higher privacy settings.

[donjoe0]

Good. That proposal seems to agree with mine in suggesting that the privacy options shouldn't just be off by default and that WhatsApp behavior shouldn't just be imitated blindly.

[L3st3r]

I also don't like the idea of leaking information about the user by default, but TextSecure can only protect your privacy when many of your contacts use it too. A very secure app only used by privacy-aware people won't really help, because you would still have to use other messengers to communicate with most of your contacts.
That's why I prefer to provide a user-friendly app, that offers all aspects of a messenger the average user expects by default. Nevertheless, TextSecure stays by far the most secure and privacy-orientated messenger app.

Of course, the choice between security levels in the wizard would help choosing default options for the user based on his/her expectations. But we should also try to find a solution for this issue independent of #838, because we hadn't many opinions over there.

edit: @donjoe0: I don't want to imitate the behaviour of WhatsApp or any other app. I want to give anyone the opportunity to make his own choices regarding privacy and security, but in my opinion the default behaviour should reflect the expectations of the average user.

[generalmanager]

@donjoe0 Of course not, but TS should be very usable for the average user, otherwise all the geeks have no one to talk to ;-)
I'd be happy if you proposed any ideas for privacy features that should be on by default and privacy-degrading convenience features that should be off by default for those who care in #838.

@L3st3r Yeah but I think that's mainly because of the flood of new tickets, not because of the quality of the proposal (and if somebody doesn't like it, he is welcome to rip it apart if he has a better idea). Most conversations are only about one specific issue, with requests to make it optional. When the flood goes back a bit and all the dupli- and triplicates are gone, it'll come up again ;-)

[donjoe0]

Yeah, I don't agree that these things should be discussed separately, #838 seems like the correct and user-friendly way to go and I will definitely think about a wizard proposal of my own for that thread (which is the 11th most commented of all 400+ issues open at this time, so I wouldn't call it that unpopular either, BTW).

[thenktor]

I don't know why a delivery report would hurt any user's privacy. It's not the same like a "message seen" report, which in fact is a privacy problem.

AFAIK WhatsApp does nothing else. Threema has delivery reports always on and "message seen" reports as an option.

[peti]

@thenktor, #957 (comment) explains why delivery reports leak information about the recipient. It's a useful feature, but it has to be possible to disable it for those who don't want it.

[thenktor]

Well, OK. But to be honest I think that's no problem. You also cannot disable the SMS delivery report, so if I want to know if your smartphone is logged in to the network I can just send a SMS or even simplier: give you a call.
I have no problem if someone wants to disable this option because he feels better then, but it should still be enabled by default.

[phrag]

+1 for optional feature with a warning / info message explaining feature

[donjoe0]

"if I want to know if your smartphone is logged in to the network I can just send a SMS or even simplier: give you a call."

It's not simpler because 1. it costs you more to do it and 2. you have to make up some reason to send me an SMS or to call me when all you wanted was to check what I was doing with my device. It turns into an act of communication and that has completely different social expectations tied to it, in that case we're no longer simply talking about a passive invasion of privacy or automated leak of personal activity information.

[generalmanager]

In addition to the reasons @donjoe0 gave, the whole SMS functionality could and should be turned off for this and other privacy endangering properties like the impossibility to hide metadata from your provider (which is probably your opressive government, or controlled by it, if you happen to be an activist).
You can read more about this and other problems (and why they matter) in #838.

Your reasoning sounds a lot like "SMS is broken, intransparent and bad for privacy, lets do the same for the data connection.".

[d7415]

I'd suggest the other direction. So long as there's an indication of a bad message if decryption fails, the recipient can ask for a repeat. Waiting until after decryption leaks more information (is TextSecure unlocked? Has the recipient unlocked TextSecure to read the message?) and adds a delay. With normal SMS a report is available almost instantly, but provides no information about whether the message has been read.

Basic delivery confirms receipt, then the recipient can choose when to read it.

[doits]

I didn't think of textsecure being locked ... that would indeed be not good for privacy to wait after unlocking it for a delivery report.

So it should really work like SMS delivery reports: no indication whether it was decrypted successfully or not, just transferred and received successfully (this could be send solely by the server to the sender after delivering a message to the receiver).

If decryption fails at the receiver's side, he has the option to notify the sender (but that should not be done automatically, since then I could send bad message on purpose to see when the user unlocks textsecure). In this case the message could be retransmitted (automatically?), but that is a different story of "what to do with broken messages" and should be discussed elsewhere.

So for this PR my vote now is to implement it just like SMS delivery reports. Then the symbols for the delivery report could be the same with no problem, too.

[generalmanager]

I'm also firmly against the "message was decrypted" report, because this is the perfect way to bust someone. It's trivial to find out if they use local encryption at all and then it's also possible to tell when exactly they unlocked the container and also how long it takes until TS autmatically locks the container again. I think it's rather obvious why that is a bad idea.

[thenktor]

@doits : "So for this PR my vote now is to implement it just like SMS delivery reports. Then the symbols for the delivery report could be the same with no problem, too."
I agree 👍
I'm also against "message decrypted" reports. If decryption fails on the receiver side, the receiver usually would ask himself what was sent.

[ghost]

Are read receipts ever coming then?

[FLYingG0D]

I support this option. I had an issue when trying to communicate with my friend. One of us has some security software blocking the data connection, so the other would not get the messages. It took quite a while to figure it out. It would really have been nice to be able to see if the message made it from my phone to the server at least. Even better if I know that it made it to the other end.

I think that if you believe that the notification of successful receive on the other end is too much of a violation of privacy, then at lease please make it report if the message was properly passed off to the server. So at least you know that your connection to the push servers is good.

(Note: You get the confirmations from SMS messages, which this app handles. So, why not? Also, if they don't like it, they can use SMS instead of Push)

[agrajaghh]

You can already see if the message got delivered to the server. Its changing color from light blue to blue.
But as far as I know the delivery receipts are coming, don't ask for an ETA ;)

[Hellmy]

I suggest a solved mark with version 2.22!?

[ximex]

@Hellmy yes this issue should be fixed in the current version

[janvlug]

Version 2.22? Google Play Store states 2.2.0. Can I see the version in TextSecure itself?
Where can I see the delivery receipts? I did not manage to find them.

[d7415]

@janvlug Current version is 2.2.0 and has delivery reports. So long as you and the recipient have the latest version, you'll get the little ticked message icon in your PUSH messages as you would in SMS.

[agrajaghh]

2.2.0 is the newest version. You'll see little message bubbles with green checkmarks when your message arrived / you received the delivery report. Perhaps your chatpartner doesn't have 2.2.0 yet?
edit: d7415 was faster...

[donjoe0]

"So long as you and the recipient have the latest version, you'll get the little ticked message icon in your PUSH messages as you would in SMS."

That sounds like it's not optional, which would make it just as bad as WhatsApp, privacy-wise. If the functionality works like you said I prefer to avoid updating the app until optionality is added.

[agrajaghh]

@donjoe0 The relivery receips just indicates that the message arrived, it doesn't indicate that the message was read...

[janvlug]

I verified with someone with the latest version (2.2.0) and indeed: it works.

[jeremymasters]

Since the title is delivery reports, that should cover this.

[meteficha]

Even though this issue has a long comment list, nobody said this yet: THANK YOU for implementing this feature, you guys rock! 👍

[donjoe0]

@agrajaghh That has already been discussed up-thread.

So after several people agreed that this functionality should be optional the issue gets Closed based on a non-optional WhatsApp-like implementation?

[d7415]

@donjoe0 The issue title is "Delivery reports for PUSHed messages?". That's been implemented. I'd suggest that the option to turn it off would be better handled by a new issue to avoid confusion.

[donjoe0]

@d7415 There would've been no confusion in implementing an issue according to the details discussed in its comments thread. The confusion will appear now when I create a new issue for which all the explanations exist in a different issue's thread. But anyway.

[ghost]

So where are we on read receipts? The fact that they are not even optional default-off is kind of completely unacceptable in 2016

[agrajaghh]

@LoveKC94 please use the mailing list for discussions not the github issues. Thanks! (btw, you'll already find lot of messages about it in the archive)

[ghost]

@agrajaghh my apologies, countless searching brought me only to this thread and other closed ones because it was already discussed here. None of these threads have really given a concrete answer or good reason on it. Could you tell me how to get to this mailing list? (BTW, don't know if it matters but I do consider this an issue with the app. Lacking common and useful functionality is definitely an issue)

[agrajaghh]

It's linked in the Readme: https://github.com/WhisperSystems/Signal-Android/blob/master/README.md#contributing-ideas

[ghost]

Thank you for being polite about my idiocy haha. Can't believe I did not check there.