# On Transparency and Accountability of Smart Assistants in Smart Cities
## 6 Discussion
For example, one recently published work [44] proposes a risk evaluation model for Android apps that calculates a threat score for the app based on its requested permissions. It calculates the different types of threat scores, including privacy, systems, and financial threat scores. All these scores are based on the requested permissions. For example, for calculating privacy threat score, it assigns limited threat to permissions such as ACCESS_COARSE_LOCATION, a significant threat to permissions with serious privacy consequences (e.g., WRITE_SOCIAL_STREAM), the relevant threat to permissions such as ACCESS_FINE_LOCATION, and the maximum threat to permissions which may have an effect on the privacy of device and its user. System and financial threats are also calculated using different permissions. If we use this model to evaluate the risks of GA, it will generate entirely inaccurate threat scores. The same is true for other risk evaluation models using app permissions or API usage. The same goes for tools such as MalPat [56] and DASAPA [83], and the approaches proposed in [84; 85]. This is an alarming situation and seeks immediate attention from the research community and regulatory bodies. Further, GDPR requires that the implementation of privacy controls should be technology-neutral. However, the results of our research show that, in the case of GA, both its permission requirements and its underlying implementation turn it into a black box for end-users and experts, affecting its risk assessment and validation and, therefore, accountability. We understand that, despite the limited AI features of GA, the current set of Android permissions did not serve its operational requirements, which led Google to use more powerful permission. This demonstrates that current Android permissions will not serve the privacy protection and security needs of Android users in the smart city. This offers new challenges for privacy protection tools in Android. We propose that other privacy protection mechanisms should also be evaluated to verify whether they serve the needs of technologies that will prevail in smart cities. Overall, we believe that smart assistants will assume important roles in the lives of smart city inhabitants. Many other smart city products with similar capabilities will emerge, and transparency in their data collection behaviors will be a trait needed for ensuring the privacy protection of smart city citizens [27]. This research shows how deviation from de facto app design and permission use in GA introduced transparency and validation issues affecting the privacy protection of smart city citizens and the accountability of this smart assistant. We understand Google's ability to make such drastic changes is associated with its role in controlling Android that allows it to do things that no other stakeholders can do. Previous instances confirm this tendency. For example, Google can collect user data while bypassing the apparent security and privacy architecture in Android [86]. Google is also known to influence Android phone manufacturers for including its browser app in their devices for its advantage [12]. There are also cases in which Google denied providing timely fixes after learning vulnerabilities in the Android security mechanism [87]. Therefore, we understand that the security and privacy of smart city products and citizens cannot be left to the entities whose interests conflict with those of data subjects, especially when they are known to have an urge to change the current privacy architecture [9; 88]. Congruent with the recommendations of [PERSON] et al. [34], we suggest that product developers in the smart city should be made accountable for issues such as a lack of transparency in their products. Further, [PERSON] and [PERSON] [33] identified the need to establish standard specifications for smart city infrastructure at a broader level. Notably, product level standards and specifications are mostly missing.