The personal devices (and apps) we carry around have the ability to collect lots of data from and about us. Some of this data is useful for personal productivity, while some borders on the verge of over-collection and possible privacy intrusion. The question then becomes: How much data can an app or device collect that is just enough to satisfy a particular purpose while still protecting privacy?

This paper describes a mobile cloud framework that attempts to prevent data over-collection in smart cities. It starts by describing what a smart city is, the central position the smartphone plays, plus the risks of data over-collection therein. It defines data over-collection as a particular device collecting “users’ data more than its original function while within [its] permission scope.” The authors lament that a reason over-collection exists is that “mobile phone operating systems only provide coarse-grained [binary (yes/no)] permissions” to regulate an app’s access to private information. They posit that a finer-grained graduated permission regime may mitigate the occurrence of data over-collection.

The paper makes us realize two strands of work in the area: (a) the more common passive method that includes monitoring and detecting the occurrence of over-collection signals, and (b) a proactive preventive method, which the authors advocate to be better. Their proposed solution is in the proactive domain. The paper describes many of the risks faced by users of apps that request and grant access to users’ locations, photos, address books, and calendars. Such risks include stalking, burglary, espionage, and murder.

The architecture starts with a definition of system models, which include the quantifications of security level (SL) for an app, the permission model (PM) of a datum, and a security risk (SR) model. The models equate SL to be proportional to the energy consumption (EC) of an app, and the PM to be proportional to SL. The SR of an app is given as the SL plus some probability of the app acting on a datum causing a security hazard. These models are then used to explain the mechanism of their mobile cloud framework. They show this framework to be effective in reducing over-collection.

The models as described are useful for their architecture. On closer scrutiny, they need to be retired and/or amended considerably. They define SR as a value set to “the potential harm to ... security when some risk happens.” It is not stated who sets this value--the user, the system, or something else. The authors set SL to be proportional to EC, meaning that an app with a high EC may be given a high SL. The reason for this is not stated. The permission model, Eq. 3, constructed for an app is the SL plus a data rate. This is surprising since the authors state that the degree of choice as offered to users when an app asks for permission is the major culprit in over-collection, and this choice mechanism failed to make it into any of the models. A few errors are also noticed in the models; lack of space does not permit elucidation.

This paper describes a different way to provide data privacy in smart cities. The models used as bases need reformation before the architecture can be credible. This paper can be read in order to glean a different view of avoiding data over-collection, but the reader needs to be aware that the equations need to be amended before being credible.