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 ” –  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, , , 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 . 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.