Not even two weeks since IMC pass and we have the first citation of our RilAnalyzer paper! However, the paper has quite a few inaccuracies. I will not try to enumerate all the inaccuracies (one could easily do that by looking at our paper and comparing), but will outline a few.
Edit: edited to clear up some of the misunderstandings between myself and the authors of the citing paper
Note: the post is a personal opinion of Andrius Aucinas (http://www.cl.cam.ac.uk/~aa535/) and not that of the University of Cambridge or Telefonica Research. I did not mean it to be anonymous in the first place and I did not accuse the authors of plagiarism.
- “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 wrong: "RILAnalyzer, which enables to accurately gather and correlate control plane and user plane events on Android handsets. Currently the tool is sup- ported on rooted Android devices with only Intel/Infineon XGold chipsets. Our tool does not have such dependencies.†In addition it implies that their system did not require rooted Android devices (an important limitation of our work), which as far as I know could not be true on any standard Android device.
- “We propose an entirely mobile based framework†– not sure how a phone connected to a PC is entirely mobile
- Based on the above point, claiming that the mechanism is on-the-phone is inaccurate: "we propose for Android smartphones an on-the- phone mechanism to detect background applications that due to bad design (given the network’s settings) or their malicious nature (exploiting the network’s settings) lead to above mentioned inefficiencies."
- "Recent works, [9], [6], have analyzed such applications. How- ever, they focus on energy efficiency and perceived end user experience, and not on measuring an application’s impact on the network’s signaling load and energy consumed, for communicating a unit of data.†- inaccurate citation of RilAnalyzer - it focuses on energy and signalling rather than perceived end user experience, just not for communicating a unit of data
- "We adopt a novel approach to find and record the actual RRC state of the device at any given instant. Secret codes are used to open Android hidden menus [8]. The secret codes are manufacturer specific numeric/symbolic sequences, which can be dialed from the device to access hidden menus, run diagnostic tests, and reset parameters of the device.â€Â  - the approach is somewhat novel, however described in our work and in my opinion needs proper attribution as well
My feeling is that it was not difficult to cite our work more accurately, which might have also helped to clear up some of inaccuracies of their own work. I think so especially because they have been in touch with us since the end of August, received source code of our system on the 8th September (published on github) and received our assistance in running it. Furthermore, camera-ready version of our paper which appeared in IMC’13 (October 23 - 25) was also published online from 21st August.
November 6th, 2013 - 14:37
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.
November 6th, 2013 - 18:00
I suggest burning both papers!