[SCRIPT][1.6+][WHATSAPP][14/11/08] Disable sending read-receipts for WhatsApp msgs

[Bexton]

Shell script to disable read receipts for all your incoming Whatsapp messages

Even "better": Others won't see whether you've already read their message(s) or not. However, you will still be able to see the read receipts of others!

################################################################################
#
# Shell script to disable read receipts for all incoming Whatsapp messages.
#
#                    [ ANDROID AND ROOT ONLY ! ]
#
# Author: Stephan Schmitz <eyecatchup@gmail.com> 
# Source: https://gist.github.com/eyecatchup/9af90363732801b131bf
# Last Updated: 09. Nov 2014
#
# ABOUT
#
# You don't like that everyone in your Whatsapp contact list is now able to see
# whether you've already read their latest message(s) or not? Then feel free to
# use the following "work-around" that I found to disable sending read receipts
# globally. Once patched, whenever you get new messages, the senders will never
# see the 2 check marks in blue. They'll just stay gray, just like it was until
# recently. Well, almost. Because you'll still be able to see whether your chat
# partners have already read the messages you sent to them. ;)
#
# DESCRIPTION
#
# In early Nov. 2014, Whatsapp added a new "feature" - read receipts. It means, 
# your chat partners will get a visual feedback (2 blue check marks) as soon as 
# you've read their message(s). 
#
# Unfortunately, Whatsapp's dev team forgot to implement a corresponding privacy 
# setting for users to be able to turn off this feature. However, fortunately, I
# found it was fairly simple to disable the feature, since it is set in a public
# XML file in Whatsapp's app data directory.
#
# This script shall serve as a convenient wrapper for those Android users who do
# not live in userland - as well as for the lazy ones.
# 
# PRE-REQUIREMENT
# 
# Basically, all it needs is a working `sed` commandline utily in path. 
# If you should not have "Busybox" installed yet, choose one of the available 
# "Busybox" installer apps from Google Play Store and let it install busybox.
#
# USAGE
#
# - Save this script to your phone's sdcard as disable_whatsapp_read_receipts.sh
# - Open a terminal session on your device 
#   E.g. https://play.google.com/store/apps/details?id=jackpal.androidterm
# - In the console, login as root (type su, hit enter) and type: 
#   sh /sdcard/disable_whatsapp_read_receipts.sh  
#   (adjust the path, if required, to fit your's!)
# - Hit the enter button. Done. (Whatsapp will restart afterwards)
# 
# If you get any error message a) make sure the /data partition is mounted /w rw
# permissions and b), if the permission for restarting WA is denied, 1st try to 
# uncomment the last line of this script (append hash char "#" (without quotes)) 
# and run the again. Otherwise, consult me for help here:
# http://xdaforums.com/android/development/script-disable-whatsapp-read-receipts-t2933467
#
# IMPORTANT NOTE 
#
# The last successful test for this was run at 09. Nov. 2014 and on the Whatsapp
# Android version 2.11.399 and 2.11.432 only. Even though it should work for all 
# Android versions, it was not tested. Also, Whatsapp might change their current
# implementation any time soon. So this work-around might stop working any time 
# soon too. Keep that in mind!
#
################################################################################

Download

NOTE: This script requires the "sed" command line utily (ie "busybox") installed on the system, which pre-requires a rooted device!

NOTE: The gist requires an update, which I'll post tomorrow. For further details and a manual workaround see my post here: http://xdaforums.com/showpost.php?p=56640205&postcount=9
External link to gist.github.com (see the inline comments for further instructions): http://goo.gl/EiOvO0

Download, run, done. Enjoy. Whatever.

PS: For those who understand German, here're some screenshots of testing this " hack". As you can see, my chat partners can't see the read status. http://imgur.com/a/kzQs3

 

[smartxdev]

Nice trick!
However, I've noticed that the preferences .XML files are reset to the original values once the application relaunches. So, basically, the changes do not stick.
Any workaround on this?

 

[Bexton]

Nice trick!
However, I've noticed that the preferences .XML files are reset to the original values once the application relaunches. So, basically, the changes do not stick.
Any workaround on this?

That's kind of odd, since the script explictly restarts the Whatsapp package *after* applying the changes to the prefs xml. Which then, in turn, should result in no result at all (assuming a restart rewrites the xml), right!? But it does work. Now, the first question would be how you define restart (activity (re)launch, package force && start)?

Update: Just checked it and you're right. If I use the -S option on the am start call (to force stop Whatsapp before (re)starting the activity), running script has no effect at all - since the XML is being recreated. And that also means, that the change will gets lost with every device reboot.

The easiest solution I see here, to have a "permanent" effect, to wrap the script in a plain simple app and attach it an onboot service. (Also, looking at #4, some further checks should be added.) If Whatsapp will leave this current implementation of defining whether to send read receipts or not, I'll invest the time into an app version, I think. (Just don't want to have too much hustle with it. So want to wait whether it's worth to spend more time on this.) Thoughts?

 

[Dj Mauro]

hi, i have this problem:

can you fix it?

 

[smartxdev]

hi, i have this problem:
can you fix it?

I had permission error too.
In the terminal, try to first run "su" command (without the quotation marks), it will obtain root permissions for the terminal.
Then run the actual command. That solved the permission error for me.

That's kind of odd, since the script explictly restarts the Whatsapp package *after* applying the changes to the prefs xml. Which then, in turn, should result in no result at all (assuming a restart rewrites the xml), right!? But it does work. Now, the first question would be how you define restart (activity (re)launch, package force && start)?

Actually it never worked for me (I mean, script ran successfully, but i have no success in disabling the "read recipient" when i tested it).

Then, I tried to do it manually:
- make a backup copy of the target file (/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml)
- and then set: "read_receipts" to value="0" in the original file
- save it
- and when i open whatsapp app again, the XML file is restored to the older values, and the "backup" copy gets erased.

And for the "restart" question, i tried the following:
1 - swipe the app away from the recents, make XML modifications, and relaunch
2 - kill the app, make XML modifications, and run it again

I also tried to set XML file permissions to read-only, but it still was replaced by original config. once i opened the app.

-----

I was thinking about another workaround:
Since the read receipt (and delivery too) is usually done by transmitting a small message by the application, back to the sender, once the conversation window is opened.
It may be possible to just block this outgoing communication on your side by XPrivacy.
But, i have yet to hunt down the specific permission/address to block, without crippling the app..

 

[Bexton]

hi, i have this problem:
snip
can you fix it?

As a quick fix, this should work for you:
1.) Add the following line above the line with the sed command:

mount -o rw,remount /data

2.) Change the last line of the script to the following (if it still compains replace the user id value in the command with that from the error message. and if it still complains, it might even work when you just comment out the line):

echo `am start --user -2 -n com.whatsapp/com.whatsapp.Conversation`

3.) Back in the console again, login as root (su, enter) and run the script.

Let me know if it worked.

As said in my update to post #3, I'll probably add some automatisms for such issues soon.

 

[hova1888]

Bexton Tnx !

 

[Ather]

how about an xposed module?

 

[Bexton]

I had permission error too.
In the terminal, try to first run "su" command (without the quotation marks), it will obtain root permissions for the terminal.
Then run the actual command. That solved the permission error for me.

Yeah, recognized already that I completely forgot to mention that at all (to run the script as root). I updated the inline instructions accordingly.

Actually it never worked for me (I mean, script ran successfully, but i have no success in disabling the "read recipient" when i tested it).

Then, I tried to do it manually:
- make a backup copy of the target file (/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml)
- and then set: "read_receipts" to value="0" in the original file
- save it
- and when i open whatsapp app again, the XML file is restored to the older values, and the "backup" copy gets erased.

And for the "restart" question, i tried the following:
1 - swipe the app away from the recents, make XML modifications, and relaunch
2 - kill the app, make XML modifications, and run it again

I also tried to set XML file permissions to read-only, but it still was replaced by original config. once i opened the app.

Sheesh. Okay, I think I got what's wrong here.

As far as I understood, you didn't even got to the point where the file

/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml

stored the modified value, correct?

When I was looking at your manual procedure I recognized a small but probably crucial difference! Let's have a look at it. My initial, manual approach was:
# Login as root

bexton@pc> [B]adb shell[/B]
shell@phone:/ $ [B]su[/B]

# Copy the original prefs xml file to /sdcard/.
# NOTE: We use cp as root user, but with the --preserve switch to copy a file owned by Whatapp's OS user.

root@phone:/  # [B]cp -p /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml /sdcard/[/B]

# So, at this point, the copied file /sdcard/com.whatsapp_preferences.xml is still owned by Whatapp's OS user.

# Now, my last 2 steps were to modify the read-receipts settings value in /sdcard/com.whatsapp_preferences.xml and copy back the modified file to its original location, which I did as follows:

root@phone:/  # [B]sed -i'.bak' 's/^.*\bread_receipts\b.*$/    <long name="read_receipts" value="0" \/>/g' /sdcard/com.whatsapp_preferences.xml[/B]
root@phone:/  # [B]cp -p /sdcard/com.whatsapp_preferences.xml /data/data/com.whatsapp/shared_prefs/[/B]

So all together, this was:

bexton@pc> [B]adb shell[/B]
shell@phone:/ $ [B]su[/B]
root@phone:/  # [B]cp -p /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml /sdcard/[/B]
root@phone:/  # [B]sed -i'.bak' 's/^.*\bread_receipts\b.*$/    <long name="read_receipts" value="0" \/>/g' /sdcard/com.whatsapp_preferences.xml[/B]
root@phone:/  # [B]cp -fp /sdcard/com.whatsapp_preferences.xml /data/data/com.whatsapp/shared_prefs/[/B]

So what happened with the last 2 commands that made it work for me, but breaks in the script version?

The core problem here is, as I just learned, that GNU sed's -i extension does not actually edit files in place (--in-place is a misnomer, in my opinion); it creates a temp file, deletes the original file, then renames the temp to the name of the original. The result is a new file - much possibly with a different owner.

So in my manual procedure, the result of the sed command worked fine except for the fact that it changed ownership on all the files it went through. The only problem is that these files (or at least the backup file) were owned by the root user - the user I run the command as. However, then I used the -f switch (to force overwrite) and the -p switch (to preserve permission, ownership and timestamps) to copy back the prefs file from /sdcard/ back to its original location in the Whatsapp data folder. That means, as a result, in the Whatsapp data folder there was a) no new file from another user (the backup file) and b) the modified prefs xml file still had its original ownership information. Basically, this kind of "fixed" sed's -i mode behaviour on the prefs file plus didn't created a new file in Whatsapp's data folder.

The last step to solve the puzzle is fairly simple. I just tried the procedure manually - as defined upthread - with all my friends' phones. Thus, I didn't noticed the sed behaviour. Plus, the friend Iinitially wrote the script for didn't told me that it wasn't working for him.

Anyway. Let's finally come to how to fix.

A quick look into the sed manual unveils that -c switch should do the trick:

-c, --copy

use copy instead of rename when shuffling files in -i mode
(avoids change of input file ownership)

Unfortunately, this switch is not enabled in all the busybox sed's for Android. Also, this would still leave us with a new file in Whatsapp's data directory. Even if all ownership information of existing files can be preserved, we should also not create any files in the folder that are not known to the Whatsapp app.

So basically my manual approach is the way to go:
a) Save the backup of the original prefs file somewhere on /sdcard/
b) Preserve ownership and permissions for /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml

NOTE: Even if you got the value in the prefs xml saved to "0" and with no changes to ownership and permissions, you still need to restart any running Whatsapp process. Otherwise the change will have no effect! And, rebooting the device, resets the prefs xml file!

I'll post an updated version later. Until then, probably the easiest way to test this, is the manual way using a text editor app on your device.

- Open any text editor app with root capabilities (I used https://play.google.com/store/apps/details?id=com.maskyn.fileeditor )
- From the menu choose "Open file", navigate to /data/data/com.whatsapp/shared_prefs/ and open the file com.whatsapp_preferences.xml
- Find the line that reads <long name="read_receipts" value="SOMENUMBER" /> (SOMENUMBER is a placeholder, of course)
- Replace SOMENUMBER with 0 (zero), so the line reads <long name="read_receipts" value="0" />
- Save the file
- Now, close Whatsapp from the recent apps view and restart it.




- You can verify the change by running the following command (as root) from a terminal on your phone:

cat /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml |grep read

- You can verify the ownership and permissions by running the following command (as root) from a terminal on your phone:

ls -l /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml

I was thinking about another workaround:
Since the read receipt (and delivery too) is usually done by transmitting a small message by the application, back to the sender, once the conversation window is opened.
It may be possible to just block this outgoing communication on your side by XPrivacy.
But, i have yet to hunt down the specific permission/address to block, without crippling the app..

Sure, feel free to share any suggestions!

 

[Bexton]

how about an xposed module?

I guess that'd be possible too. Just that I never looked into it yet.

 

[smartxdev]

Thanks, @Bexton for your detailed explanation.
Manual editing by Turbo Editor did the work for me.
I tested it, and the blue check marks were indeed blocked.
And btw, Turbo Editor has a nice "recent files" list on the startup, so reediting of the parameter on restart should be simple and easy.
Then, i did Restart (full restart to the device), and.... ...it still holds!
The parameter in the XML is unchanged and read notifications are still blocked

So, it made me wonder, why it didn't work for me before? I used ES Text Editor to edit the XML, it was fine, but then i made a backup copy somewhere inside the /data/data/com.whatsapp/ folder. And I think that "foreign" file caused full rewrite of the xml files by the app.

I hope it may hold permanently, but, we'll see..

 

[Th3Zer0]

Ahoy everyone!
We're 2 students from the University of Milan who created a repository [https://github.com/phosphore/whatsapp-blue/wiki]
for an Android app with the aim of getting rid of those blue ticks. We're currently
considering and testing out all the possible solutions including the modification
of com.whatsapp_preferences.xml (as found by @Bexton) or the filtering of the TCP
packet responsible for the read receipt.

Although using Bexton's method greatly simplifies the solution, it is just a
temporary workaround before Whatsapp fixes it.
Having a proxy filtering the requests should be a permanent solution. We are
reverse engineering FunXMPP (WA proprietary protocol) to find that particular request.

We're open to contribution!

 

[Bexton]

So, it made me wonder, why it didn't work for me before? I used ES Text Editor to edit the XML, it was fine, but then i made a backup copy somewhere inside the /data/data/com.whatsapp/ folder. And I think that "foreign" file caused full rewrite of the xml files by the app.

I hope it may hold permanently, but, we'll see..

Some editors use a similar internal workflow as GNU's sed in -i mode and without the c switch. Resulting in "corrupted" files (in the sense of ownership & contex)..

Ahoy everyone!
We're 2 students from the University of Milan who created a repository [https://github.com/phosphore/whatsapp-blue/wiki]
for an Android app with the aim of getting rid of those blue ticks. We're currently
considering and testing out all the possible solutions including the modification
of com.whatsapp_preferences.xml (as found by @Bexton) or the filtering of the TCP
packet responsible for the read receipt.

Although using Bexton's method greatly simplifies the solution, it is just a
temporary workaround before Whatsapp fixes it.
Having a proxy filtering the requests should be a permanent solution. We are
reverse engineering FunXMPP (WA proprietary protocol) to find that particular request.

We're open to contribution!

Could you hook up via email? I'm working on an app as well and currently considering the possibilities. Maybe it's worth sharing thought.. Please send to eyecatchup+xda@gmail.com, thanks!

 

[Bexton]

This is why I waited before investing more time into it, hehe. So, time to relax for everyone. Here is news:

Whatsapp will soon get the ability to turn off the blue checkmark read indicator, according to an alleged Beta tester of the application.

Original tweet: https://twitter.com/0xmaciln/status/530294585072025600
Via: http://www.myce.com/news/whatsapp-w...ble-privacy-sensitive-blue-check-marks-73438/

Looks like this thread will be obsolete very soon.

 

[smartxdev]

Whatsapp will soon get the ability to turn off the blue checkmark read indicator, according to an alleged Beta tester of the application.

Original tweet: https://twitter.com/0xmaciln/status/530294585072025600
Via: http://www.myce.com/news/whatsapp-wi...k-marks-73438/
Looks like this thread will be obsolete very soon.

Nice!
I think whatsapp(facebook?) expected this to come, they already had some bad experience with the "last seen" issue some time ago.
And it is already implemented as a simple switch inside XML prefs...

 

[Bexton]

Looks like this thread will be obsolete very soon.

Hm, maybe I was wrong and it will not become obsolete. Maybe I will still build an app for it. Why? I found more news on the matter, that pointed out a major difference to me.

The same person who confirmed the additon of the on/off toggle for the read receipts, Ihlan Pektas, actually blogged about the feature already a few days ago. The essential information given in his blog post here (in German language) for me is, that he says that early alpha builds already have an implementation for it, and when you disable sending your read status (so that others can't see if you've read a msg), you will, in return, NOT be able to see the read status of your chat partners! (What makes perfectly sense, becausee it's the same way they do it for the "last seen" status.)

That being said, I think there'll be interest in an alternative. An alternative that is capable of disable sending one's own read status, while still being able to see the read status for one's own msgs, sent to others?!

Well, we'll see. (But the party ain't over yet.. )

 

[hocgwai]

Thanks Bexton. Tried your manual method with ES File Explorer, without making a backup, and it works. Even survives a full reboot.

 

[smartxdev]

That being said, I think there'll be interest in an alternative. An alternative that is capable of disable sending one's own read status, while still being able to see the read status for one's own msgs, sent to others?!

Well, we'll see. (But the party ain't over yet.. )

I see your point, but to make this happen, we need to look at another approach. Because, now we disable it by the pretty obvious flag in the pref. file, and once they release a "feature" it will be probably the same flag that will cause you not the deliver read receipts either.

The thing is, that in fact I barely use whatsapp, for various reasons. I'm here to help some non-techie friends of mine.
Anyways, I use Open WhisperSystems' TextSecure mostly (less polished and fewer features, but free, opensource, and actually secure).
So, a short while ago, they've introduced "delivery receipts". And for some reason, only I was able to get others' delivery receipts, but when others send me messages, they didn't receive a delivery receipt from me. (That's basically what we are trying to do here, just with read receipts)
At first, I was sure there is some bug in this. But then it turned out that I tuned XPrivacy too tight on restrictions, and this new feature could not get through and send the delivery notice. (unfortunately I don't remember what exactly the troublesome restriction was)

That's why i first thought about XPrivacy for this case as well.
Logically, the mechanism here might be the same, and once we find out what activity or address to block it will do the trick without letting the app itself know about it.

And it seems like @Th3Zer0 guys have the same direction in mind.
Bottom line: sounds like a good idea to find out how to "cheat" those things, and maybe build Xposed module/app on it

 

[chongc1996]

This seems to be the equivalent of downgrading whatsapp, letting you see blue ticks but other's cant see
It seems that it disables the part where you can highlight your own message and see who has seen the message though.

Working on 2.11.432.

Whatsapp just enabled a new feature a la Telegram where you can see who's typing in a group.

 

[smartxdev]

Contradictory to my previous report, I'm noticing that over time the "read_receipts" parameter keep reverting to a original value. What's weird though is that i was unable to pinpoint when it actually happening, since it happens without any kind of full phone restart in between.
Have you (@Bexton?) any insight on it?

And by the way, as I was talking about the sadly unpopular, but security-wise superior TextSecure, this post came out: Open Whisper Systems partners with WhatsApp.
Sounds promising, but it still remains to be seen how it all gets implemented and how much of a metadata leakage will be going on, since it is very unlikely that a proprietary and closed source SW company as WhatsApp will kill their business value (which is an insight on near 700M users' data) just like that.