Comments on: https://www.syslog.cl.cam.ac.uk/2013/11/05/1694/ The Cambridge Systems Research Blog Wed, 06 Nov 2013 18:00:00 +0000 hourly 1 https://wordpress.org/?v=6.2.2 By: The_burning_monkey https://www.syslog.cl.cam.ac.uk/2013/11/05/1694/comment-page-1/#comment-270 Wed, 06 Nov 2013 18:00:00 +0000 http://www.syslog.cl.cam.ac.uk/?p=1694#comment-270 I suggest burning both papers!

]]> By: Sanjit Kaul https://www.syslog.cl.cam.ac.uk/2013/11/05/1694/comment-page-1/#comment-269 Wed, 06 Nov 2013 14:37:00 +0000 http://www.syslog.cl.cam.ac.uk/?p=1694#comment-269 repeated and slightly rephrased work. I will not try to detail all the ways in which the paper is either inaccurate, a replica of our work or just wrong (one could easily do that by looking at our paper (http://rilanalyzer.smart-e.org/rilanalyzer.pdf)), but will outline a few of the top bits. SKK> You are accusing us of plagiarizing your work. That is a very serious accusation. If you are so convinced we should escalate your concerns to an independent body. “Unlike the existing tools, our tool neither requires any special hardware [9]” – [9] being our paper – ours only requires “special hardware” in much the same way as their system does – will explain below “For detecting the state continuously, the phone is connected to a PC via the Android Debug Bridge. The secret code *#0011# (Samsung specific) is dialed to display the RRC states, which are saved at regular intervals using Android logcat.“ – Secret codes are hardware-specific, and this is precisely the reason our system has not been ported to support every existing device. Furthermore, the limitation is not so much due to particular handsets, but rather the chipsets they use, so the approach works with any device using the same chipset and in that way requires special hardware hence the more specific statement is plain wrong. SKK> You may be correct. The limitation may not be due to particular handsets. We could run the code only on different Samsung phones and not on HTC and other makes we tried. Also, we were guided to this approach by AT&T developer support. “We propose an entirely mobile based framework” – not sure how a phone connected to a PC is entirely mobile SKK> I agree that the statement is ambiguous. The point we were making was that the categorizing of applications did not require the network to play any role. “The packet information obtained from the snier and the state information from the state logger is then merged on the basis of timestamps.” – yep, exactly our approach SKK> Again, you are claiming plagiarism. I have already mentioned that the codes were brought to our notice by AT&T dev. Using libpcap and merging based on timestamps seem like the most obvious things to try. Not sure why you think that these ideas came to us from your work. Funnily, they use almost exactly the same application set and usage scenarios SKK> Almost exactly the same? Thank goodness that you use the word almost. Your set of applications are Gmail, Google GCM, Facebook, Whatsapp, Skype, Twitter, AccuWeather. Our set contains Viber, WhatsApp, Line, WeChat, Gmail, and Skype. We were mostly interested in background activity of applications of popular VoIP/chat kind. Hence the set. The only application that does not fit the bill is Gmail. It was selected as it is very popular. Our analysis and its target is also very different. Even more interestingly, they have been in touch with us since we have released the code of our system open source – we have helped them to get the system running, so they are very well aware of how it works and might be “borrowing” more than a few ideas from it… SKK> Very convenient. You find it rather easy to accuse without any evidence what so ever. If there is someone who helped us, it was AT&T dev. They did it through the codes. We came to know of your tool through Vijay Erramilli when he visited us on August 29, 2013. One of your co-authors must know Vijay. You can ask him about his visit. SKK> Finally, as I have stated earlier, you are accusing us of plagiarism. I cannot see the funny side to your accusation. Unless you can help me find one, we need to get this resolved sooner than later via an independent body. I am guessing that you understand the seriousness of your accusation.]]> Dear aa535,

SKK> Good that you tag your post as a rant because that is what it is, a rather lazy rant. Please find my comments inline.

Not even two weeks since IMC pass and we have the first citation
(https://repository.iiitd.edu.in/jspui/bitstream/123456789/111/1/IIITD-
TR-2013-003.pdf) of our RilAnalyzer paper! Sadly, it is an example
(https://repository.iiitd.edu.in/jspui/bitstream/123456789/111/1/IIITD-
TR-2013-003.pdf) of publishing others’ repeated and slightly
rephrased work. I will not try to detail all the ways in which the
paper is either inaccurate, a replica of our work or just wrong (one
could easily do that by looking at our paper
(http://rilanalyzer.smart-e.org/rilanalyzer.pdf)), but will outline a
few of the top bits.

SKK> You are accusing us of plagiarizing your work. That is a very serious accusation. If you are so convinced we should escalate your concerns to an independent body.

“Unlike the existing tools, our tool neither requires any special hardware [9]” – [9] being our paper
– ours only requires “special hardware” in much the same way as their system does – will
explain below
“For detecting the state continuously, the phone is connected to a PC via the Android Debug Bridge.
The secret code *#0011# (Samsung specific) is dialed to display the RRC states, which are saved at
regular intervals using Android logcat.“ – Secret codes are hardware-specific, and this is precisely
the reason our system has not been ported to support every existing device. Furthermore, the
limitation is not so much due to particular handsets, but rather the chipsets they use, so the
approach works with any device using the same chipset and in that way requires special hardware
hence the more specific statement is plain wrong.

SKK> You may be correct. The limitation may not be due to particular handsets. We could run the code only on different Samsung phones and not on HTC and other makes we tried. Also, we were guided to this approach by AT&T developer support.

“We propose an entirely mobile based framework” – not sure how a phone connected to a PC is
entirely mobile

SKK> I agree that the statement is ambiguous. The point we were making was that the categorizing of applications did not require the network to play any role.

“The packet information obtained from the snier and the state information from the state logger is
then merged on the basis of timestamps.” – yep, exactly our approach

SKK> Again, you are claiming plagiarism. I have already mentioned that the codes were brought to our notice by AT&T dev. Using libpcap and merging based on timestamps seem like the most obvious things to try. Not sure why you think that these ideas came to us from your work.

Funnily, they use almost exactly the same application set and usage scenarios

SKK> Almost exactly the same? Thank goodness that you use the word almost. Your set of applications are Gmail, Google GCM, Facebook, Whatsapp, Skype, Twitter, AccuWeather. Our set contains Viber, WhatsApp, Line, WeChat, Gmail, and Skype. We were mostly interested in background activity of applications of popular VoIP/chat kind. Hence the set. The only application that does not fit the bill is Gmail. It was selected as it is very popular. Our analysis and its target is also very different.

Even more interestingly, they have been in touch with us since we have released the code of our system
open source – we have helped them to get the system running, so they are very well aware of how it
works and might be “borrowing” more than a few ideas from it…

SKK> Very convenient. You find it rather easy to accuse without any evidence what so ever. If there is someone who helped us, it was AT&T dev. They did it through the codes. We came to know of your tool through Vijay Erramilli when he visited us on August 29, 2013. One of your co-authors must know Vijay. You can ask him about his visit.

SKK> Finally, as I have stated earlier, you are accusing us of plagiarism. I cannot see the funny side to your accusation. Unless you can help me find one, we need to get this resolved sooner than later via an independent body. I am guessing that you understand the seriousness of your accusation.

]]>