Properly address valid questions about permission misunderstandings #519
Comments
They aren't requesting the location permission. They request permission to use Google Play's contact tracing API. Google Play needs Location access in order to use Bluetooth in a way that can be used to track location. Play Services implements a privacy preserving API for the app, but Play Services needs access to sensitive Bluetooth data revealing location information. |
|
Of course, they could explain this before requesting it. They aren't in control of the dialogs once they trigger it, since the point of permission prompts and prompts to enable features like that is that the app isn't trusted. Otherwise, the app could just lie about what the options are going to do... so it doesn't work that way. |
|
@thestinger You are right, technically they only request Bluetooth functionality, but to the end user it all appears the same. And yes, that's why we need public explanations why the app is to be trusted explicitly in this case. Otherwise it's understandable that some people get suspicious if the app does something unexpected. I think the core problem is that it's coming unexpectedly. If people have been told and had a chance to read about it, they won't complain. But suddenly they see something suspicious. My point is that we need to inform the end user. At every point in the journey where the question could arise. My description may not be technically 100% correct, but there is a valid problem there. Otherwise people wouldn't create 6 issues and leave lots of 1 star reviews and multiple questions on Twitter. Sure we can't alter the dialogs, but you can explain before the dialog pops up. And you can have a clear explanation in FAQs, in the app text description etc. In a way, it's a good thing that this is the biggest criticism right now on social media, it's pretty minor, but still, it could be dealt with better. |
No, they don't request Bluetooth functionality, and they never trigger a Location permission prompt. The app never asks for or receives the Location permission. They request the contact tracing API (Notification Exposure API) from Play Services. If the user already uses location, that's it. If they don't have location support enabled in the OS, they have to enable that for Play Services, which is what the next prompt is asking. It's not a Location permission prompt. Look at what it asks. It's for enabling OS location support. Only apps with the Location permission granted can actually access location information with that enabled. |
Yeah, they could do that. However, it seems the standard dialogs are not clearly worded enough despite their attempt to explain it well. It impacts anything using the contact tracing API. |
|
Seems the issue is people are seeing the 2nd prompt (which happens when Location isn't enabled in the OS - it's not a permission prompt) and they're interpreting it as a Location permission request by the app, which isn't what it is. It's a request to enable Location support for the OS. Play Services is what needs to be able to do location tracking (engaging in the contact tracing protocol implies access to sensitive location information). The app itself doesn't implement the contact tracing protocol so it doesn't need Bluetooth access itself. If the app did it itself, then yeah, it'd need the Location permission and Location enabled in the OS. Play Services does it for the app, so it just needs Location enabled in the OS - for Play Services, not use by the app. |
|
@thestinger Thanks for your thoughts! Hope this is finally not ignored by SAP. I haven't seen the requests myself. But in the app permissions it's listing: "pair with bluetooth devices" which to me sounds like exactly what Bluetooth access is. With Bluetooth, location can be determined, hence the need to ask for location permission. |
|
Pairing with a Bluetooth device doesn't require Location: https://developer.android.com/guide/topics/connectivity/companion-device-pairing. Arbitrary scanning / broadcasting data requires it. You can see the prompts in https://github.com/corona-warn-app/cwa-app-android/issues/262. Look at the 2nd prompt. That's not a Location permission prompt but rather a request to enable Location in the OS. |
i.e. what contact tracing requires Play Services implements it for the app though, so it's Play Services that needs it. The 3rd prompt being shown there is an unfortunate case of promoting an optional feature that isn't at all related or useful for this use case. Seems like that might be a bug in Play Services since it's apparently requested every time, when it's meant to be something requested once. |
|
There's nothing that the CWA team can do. The message about enabling location and bluetooth is coming from google play services!
As you see it's caused by Google Play Services, not the app. |
|
The app could explain it to users in advance (Play Services needs Location to be able to implement the contact tracing API). The 2nd dialog could definitely be clearer but the app can't change any of that, all it could do is provide an explanation in advance. |
The location permission is required by Play Services and Play Services also needs location information ENABLED to work. This is an issue that Google on its own put on their own APIs. To fix this, they would need to change the underlying operating system to implement contact tracing directly in kernel/lower level. As of Android fragmentation, they decided to deliver it with play services. As playservices has the "location" permission already it won't ask for it. But for bluetooth scanning to actually work, the location services have to be ENABLED and there's no workaround possible, not even for Google. On iOS they delivered an update of operating system (easy for them), so contract tracing works out of box without any permissions. The funny thing: On iOS it also works without Bluetooth enabled! The reason for the location services enabled is the following: As listening for bluetooth beacons allows to guess location (similar to WLAN scanning that also allows to determine a position based on BSSIDs), when disabling location services in Android, the OS bluetooth APIs only return a "fake beacon". After that all your contacts are the same static placeholder ID. |
|
It's a matter of communication not technical implementation. Somewhere in the FAQ the prompt needs to be explained, so people who don't know the technical details understand why the prompt appears on their devices, although the app claims it doesn't track location. The people on Github and other developers know the reason, but the general public does not. so arguing about who is to blame for the misleading prompt is completly off-topic. You can't prevent the prompt, thats fine, but you need to explain why it appears. Not here, but somewhere users can easily find and understand, written in laymans terms. |
|
@thestinger and @EikeStein are right. We all know WHY permission is asked, but this is not the point of this issue. @uschindler is missing the point. I'm not asking to "fix/remove permission requests" but to EXPLAIN so that the wider public has no reason to be suspicious and complain, give 1 star reviews, file bug reports. |
For what it's worth, this is explained in the privacy policy that you accept before the notification is shown. Showing another warning or even an extra screen to notify users of this seems like an overkill to me. From my experience, the more text you add, the less users read. |
|
@ByteHamster Ok so just accept that thousands if not millions of people wont install the app, because 1 star reviews and doubts about location gathering get spread? |
|
@ByteHamster And what I'm asking for isn't necessarly text IN the app, but anywhere accessibly from a reputable source that can be linked to. That'd be a start. Because right now, how do I explain it to someone? Do I link to a Github discussion where one SAP guy quickly explains it badly in technalese? |
My comment maybe missing the point regarding to clarify the why, but nevertheless it allows more technically open people to understand the "why". Some person implementing the user interface should take the information posted by me and use it to explain it to end user. That's a hard task. I had the same discussions also in other medical applications. One famous one is the Freestyle Libre App that receives warnings via Bluetooth BLE from an body-attached glucose meter. If you disable locations there, you can fall into low sugar and die, so people have to enable location. The discussions about this and one-star comments in play store of the Freestyle Librelink app are the result, so I agree, better communication is really needed. But Aluhutträger and Verschwörungstheoretiker can never be stopped. You can only mark those comments in play store as not appropriate. |
I agree that this would certainly be good to have. Still, I do not think that a website or even a warning message in the app can significantly reduce 1 star reviews or doubts being spread. Maybe I am just disillusioned and in this case, users actually read and think before posting 1 star reviews. (I hope that this does not sound rude. Not all users are like that) |
Of course you always have idiots who will just 1 star review anyway, but when you look at the reviews right now, many don't understand what's up with that and think they were mislead, which I think is valid conclusion, given the prompts and the announcements beforehand. For something so important like this, just saying "1 star reviewers just don't understand" is too little IMO. @uschindler you made absolutly valid points, sorry if my reply came of rude in that way. Was just trying to highlight the core problem and wanted to prevent the discussion from drifting too much into the technical aspects as the many technical issues have been closed already. |
|
Well, we've had a pretty extensive discussion about these topics already and it seems to continue here. The relevant information how Android behaves has already been exchanged and it has also been accepted that we do not use GPS in the Corona-Warn-App. So the remaining open point is communication about the "why this popup?". As mentioned in #262 we decided to not add additional information dialogues in the app right now. This *right now is pretty important as it doesn't imply that we won't do anything about this in the near future, i.e. in other versions of the app. We simply needed to get the app through the door in time and as always in software development, you need to make compromises and mitigate them. We already added a respective section to the FAQ on our website https://www.coronawarn.app/en/faq/, quote:
Please apologize that we closed the other issues simply as duplicates. This statement should have been written earlier, but as you know humans make mistakes and have quite some things to do on a release day. That doesn't mean that I'm the only responsible here. Handling them was simply one part of the my duties this morning. Many others are also online and there to help and explain. Thank you very much in advance for understanding that! We will keep this issue open until a proper wording is introduced in the app. However, I would simply ask you to also acknowledge our communication and not launch half-truths or similar things, in this forum, on Twitter or anywhere else. As you wrote, @corneliusroemer, you are a "well-intentioned advocate" and I would really appreciate if you worked together with us to find a really good solution. And this is really required, because in the end people still need to trust us (if they don't look into the code) if we write on the screen and in our FAQ that GPS is not used. So it really needs to be well-written and presented - and will probably still not avoid negative feedback as it was also mentioned here in this issue, e.g. by @uschindler. Thanks again for the lively discussion and for the feedback! Mit freundlichen Grüßen/Best regards, |
|
@SebastianWolf-SAP thanks for the follow-up, just a housekeeping suggestion: it's quite standard practice on GitHub to just keep issues open even if they cannot make it to v1.0 release. If you keep possibility of including some further prompts / explanations in the future, then #262 should be just kept open. If you need a tool to classify issues which have to be worked on right now (for v1.0 release) then using labels is quite convenient. This is the way it is done in DP-3T / Google repositories related to contact tracing (and in millions of other repositories on GitHub). This would prevent eruption of related issues and would help to lower the temperature of discussion. |
SebastianWolf-SAP
added
enhancement
|
Thanks for the hints, @kbobrowski We are actually already using labels and as said, we will keep this issue open also as a courtesy to the community, to reflect the recent discussions and also our statement on suboptimal communication this morning. Mit freundlichen Grüßen/Best regards, |
|
@SebastianWolf-SAP thanks for the reply and letting us know what the plan is going foreward with this is! |
|
@SebastianWolf-SAP Thanks, apology accepted and likewise sorry for getting a bit heated. You're doing a good job. We're just working for the best for everyone. That's why we care if people are confused and leave 1 star reviews that could be avoided. It's important that the app keeps being improved now that it's out. The job isn't over yet, somehow what your CTO says sounded a bit like that. As @kbobrowski mentioned, it'd be helpful if you label issues that aren't going to be fixed immediately and keep them open somehow so that we all know you haven't forgotten about it. Then people will also be more likely to simply comment on this issue rather than open a new one. The FAQ added is good, thanks. We can now link to it whenever the need arises. Could you please add deeplinkability to the FAQs so that we can link to particular answers when answering questions on social media? I'll open a separate request on the website. By the way, the website issue list lacks "enhancement" and "feature requests" labels. |
Also erst einmal bitte unterscheiden zwischen GPS und Standort. GPS ist ein Bestandteil von Standort. Es gibt drei Optionen, die aktiviert werden können.
Also die App braucht die Daten nicht, aber ich muss Google die Daten geben, damit die App läuft oder ich verbrate in hoher Geschwindigkeit den Akku. Persönlich frage ich mich, ob das semantische Augenwischerei ist. Man hätte das zum Beispiel dem Spiegel bei seiner Anfrage schon mal erklären können. Oder wissen das die Appentwickler schlichtweg nicht, dass die App nur läuft, wenn Daten an Google übermittelt werden oder man seinen Akku leersaugt. |
|
Bitte auch in der Appstore/Playstore-App-Beschreibung also VOR INSTALLATION (und nicht nur in der Webseiten-FAQ) genau beschreiben warum alle Permissions benötigt werden. Die Trollkommentare im Playstore könnten sonst Leute von der Installation abhalten. bspw. auch, dass Kamera nur für QR-Code benötigt wird... |
Another remaining question is whether the exposure detection works or not with GPS switched off. Because (at least on my Moto G6 phone) the app still says "Risiko-Bewertung aktiv" even when I switch GPS off (but leave Bluetooth activated). |
|
Also, regarding onboarding, I can highly recommend the way the Italian app does the implementation. They use graphics and don't overwhelm with text. This is maybe a German mishabit. To have long legal texts. You can also copy and paste a lot of their good FAQ. It's open source. We can use it. The issues are the same. If anyone wants to do some good, check it out and copy it over. It doesn't take long and is a good deed. https://play.google.com/store/apps/details?id=it.ministerodellasalute.immuni I'm a bit surprised that no one did more of a benchmark of other countries apps in the run up. Immuni has been out for a long time, using the Exposure API, so many many things learned over there could be applied here. I would have even gone so far as to invite one of their PM's for a call and give their thoughts and recommendations. Btw, this could still be done. I'm sure they're happy to discuss! It's also on GitHub. |
|
@KaiRoesner your question is being discussed here: #491 @corneliusroemer I also like Immuni app, they got a lot of things right, including handling location / bluetooth permissions and on-boarding. Also find these walls of text overwhelming, perhaps it's a good idea to open separate issue about this (maybe it's a legal requirement though) |
|
Explanatory texts were indeed one requirement for accessibility... |
|
@SebastianWolf-SAP , I understand that accessibility is important, but this system has already heavily violated accessibility (only people with smartphones can use it, and only from specific providers like Samsung / Apple, this also excludes some Huawei owners). But I understand this since the goal is just to prevent second wave of the virus and possibly eradicate it - we should focus 100% on pragmatism. I almost never agree with "der Zweck heiligt die Mittel", but this situation seem to be an exception. |
|
@SebastianWolf-SAP what do you mean by explanatory text was a requirement? You were forced to put 1000 words legalese there? Fine, whatever. Everyone just scrolls past anyway. Doesn't stop you from having one screen with nice pictures that explain permissions like Immuni does. Check it out! @kbobrowski Yes please, make an issue for better (visual) communication of things that people are misunderstanding. And reference Immuni, ideally with screenshot/pictures of their way of doing things. Best practice |
|
@corneliusroemer if you want to open issue about it go ahead, I try to limit myself only to opening issues related to the fields I have some expertise in - Location prompts have close connection to how Android internally handles Location permissions so I felt competent to raise this, but as for how users react to walls of texts and what impact it will have on adoption - I can only speculate ;) I have not read these legal texts neither and just scrolled past it. I already reference Immuni regarding handling permissions in #491 |
|
I wrongly posted my question here: https://github.com/corona-warn-app/cwa-app-android/issues/262#issuecomment-645015568 but that issue is closed. My final question is: Am I correct that I am forced to enable location services in order to use CWA and I have to take the risk that other apps track my location? If that is true, I think this is hardly acceptable! |
|
You are forced to enable location services. But you are free to deny location tracking to all apps in your Android settings, that way neither the Corona app nor any other app has access to your GPS location, despite the location services being enabled. That is not something that the developers of the Corona app can change. |
But if you disable GPS, you have to allow data transmisson to google: See #572 |
I don't consider this as viable. And I don't want to be tracked by Google continously, so I'll use CWA only in public transport and crowded areas, but that is not what I had expected from the app. BTW: Even without enabled location service, the app claims that "RISIKO-ERMITTLUNG AKTIV", which I think is absolutely confusing. Update: this is handled as separate issue #491 |
|
You need it enabled for the OS and the permission enabled for Play Services. As stated by others you can deny it for everything else. Make sure you haven't opted into Location history in your Google account, and also disable Web & app activity history via https://myactivity.google.com/myactivity. That way, Google won't record your location on their servers. If you enable the Location permission for your browser, make sure it's not enabled for any sites within the browser you don't want to give it to. Also, turn off their service for providing enhanced location information, since it works by sending nearby Wi-Fi APs, Bluetooth devices and cellular towers to their server to retrieve location information from them. It's disabled by default and requires opt-in (it's the third prompt in the OP). |
|
Also, GPS is at all not required to do location tracking. Location is largely based on the non-GPS methods because if you aren't outside with a clear view of the sky at a large angle, it's difficult to get a GPS lock. When an app requests location, there isn't generally time to get an actual GPS lock. It only comes into the picture when an app is continuously using location like a map / navigation app, and there's time to get a GPS lock. Being worried about GPS specifically is worrying about the wrong thing. You should be concerned about location in general and the permission says Location rather than GPS for a reason. GPS is not what actually provides location when an app occasionally makes a quick query for it. |
|
I work on GrapheneOS, where we don't bundle Play Services, and users are often confused by the fact that they only have GPS available. They're used to getting a location nearly instantly, not waiting around for a minute to get a GPS lock and having it generally not work inside or even outside when between high rise buildings. Location relies a lot less on GPS in practice than you think it does. The device's hardware-based location almost always uses cell tower triangulation separately from Google's enhanced service. |
|
In discussions like this it would be beneficial to distinguish more clearly between Google Play Services and Global Positioning System :) |
|
When I say GPS, I never mean Google Play Services. It would be better to say GNSS because phones use more than GPS. For example, a Pixel 3 supports GPS, GLONASS, GALILEO and BeiDou. Regional regulations determine which ones it uses and to what extent, but it would rarely only use GPS. Triangulation based on cell towers is also partly implemented via the hardware implementation. It's not specifically a Google service. See https://en.wikipedia.org/wiki/Assisted_GPS. It's really best to just talk about Location tracking in terms of privacy. Cell phone tower triangulation combined with the Wi-Fi + Bluetooth service Google provides is what actually provides location in response to most quick queries. GPS takes too long to start working. Scanning nearby Bluetooth devices is a way to do location tracking, which is why Location has to be enabled in the OS. It's abstracted for end users because they shouldn't have to think about all this stuff, just whether Location detection is enabled and which apps have access to it via the Location permission. I don't think it makes sense to be specifically concerned about GPS but rather location information in general. |
|
@corneliusroemer is 100% right. Telekom/SAP was specifically brought to the table with Google/Apple because it supposedly had more bargaining power than a small start-up. What we saw is that nothing was negotiated, Telekom/SAP agreed to implement the Google/Apple solution without amendments. It is clear that Google knew this and must have communicated it to Telekom/SAP. And it surely looks like that SAP knew about this as well, but instead of addressing the FLAW it tried to cover it up, by closing issues prematurely and having newspapers write that "everything is fine". This is not how you win trust for an App where as many people as possible need to opt-in. Technically all is clear for Android: We KNOW that BLE broadcasting needs GPS (coarse location) to function. We know that Android did it this way to PREVENT location tracking. We know that CWA does not require GPS and does not track location via BLE. We know that CWA does not work without Google Play Services (Exposure API) which REQUIRES GPS to function. Bottom line: CWA enables Google Play Services to track you. It's a win-win-win Google:
There's no way out of this mess for Android, other than using an App which does not rely on Google Play Services (which has its own downsides). Governments have lost (no data, which is good), Google has won (location data + more, not good). Citizens get a small benefit for the small price of 20 million + sharing data with Google (we see the pattern). Issue can be closed IMHO. |
|
I recommend reading the technical posts I made about it above. The Location toggles (global and per-app permission) are for location access in general, not GPS in particular. The implementation doesn't depend on GPS at all. I don't know where you're getting that. Location needs to be enabled because the BLE functionality can be used to track location, not because GPS is needed. Location does not mean GPS specifically. It means location. |
|
Play Services has the Location permission by default. The screenshots in the OP do not show any request for the Location permission by Play Services but rather a request enable Location in the OS so that it's possible for apps with the permission including Play Services to make use of it. Whether this is done by Play Services or another app, Location will need to be turned on in order to use Bluetooth like this. Bluetooth pairing doesn't require Location, but this kind of scanning / broadcasting can be used for location tracking and requires it. It doesn't depend on GPS. It isn't because of something to do with GPS. It's because it can itself be used for location tracking, and that's essentially what is happening, just with an approach that goes out of the way to preserve as much privacy as possible. Engaging in the protocol does have privacy implications, but it's designed around minimizing that.
That's not true. It needs permissions just like anything else. It is a privileged app bundled with the OS which is still constrained by the permission system. It being a 'privileged' app means that the OS is explicitly granting it special permissions not available for third party apps, such as being able to install and uninstall apps in the background. These are still permissions that the OS has control over and chooses to grant to it so it can function. Also, users should be encouraged to avoid opting into the location history feature, to disable it if they already opted into it and also to opt out of app & activity tracking along with disabling the location features elsewhere. Play Services having local access to location is distinct from it sending that to a service, which it doesn't do if that's disabled. The reason there is just a single Location permission (set to one of 3 states: never, in foreground or always) and global toggle is because from a user perspective, it doesn't matter how an app obtains your location whether it's Bluetooth, Wi-Fi, cellular or GNSS (GPS is one of the available implementations of GNSS). The toggle controls whether location can be detected, not just one form of it. The Bluetooth access needed to implement the exposure notification API could be used for non-privacy-preserving fine-grained location tracking. It's up to the app (Play Services in this case) to implement it properly. If they had built into a monthly release of AOSP and the next major release, they could have just kept it as a separate permission and hidden that it depends on technology that could be used to track location. However, then it wouldn't be available yet on most devices that aren't Pixels, and would take years to become available to the majority of users. Shipping it in an app (Play Services) makes it available for the vast majority of people (who have Play Services) but it can't bypass the permission system. The whole issue is that it can't hide what it's doing and bypass the permission system, but you're trying to make it seem like the problem is the opposite? Doesn't make much sense. |
|
Thanks @thestinger for your reply. I'm with you on that and see that I should have phrased differently to avoid confusion. It just happens that on most Android platforms coarse location (global location "on") activates GPS location and "high accuracy" (fine location) toggles WiFi and Bluetooth additionally as means of localization. And it surely DOES matter to the user HOW the location is obtained, because with GPS (without "high accuracy") far less information is exposed to applications. "It's up to the app (Play Services in this case) to implement it properly." - This "In Google we Trust" mantra is a common theme. SAP built an App around the Exposure API and doesn't take any responsibility beyond that. That's fine, because there's nothing SAP could do at this point anyway. "That's not true. It needs permissions just like anything else. It is a privileged app bundled with the OS which is still constrained by the permission system. .. These are still permissions that the OS has control over and chooses to grant to it so it can function." You are correct that OS has control over its permissions, but you did not mention that by default Play Services is given EVERY permission available on the device. Also you did not mention that the "Location" permission cannot be denied: whenever (global) location is turned on Play Services automatically will be given the location permission (observe it yourself). It doesn't behave like an App, because Apps can be uninstalled (which Play Services can't). It a program / background service running on system / kernel level and in my opinion acts like a malware packed piece of middleman software. Unless you have access to its source code there's no way of telling what this program actually does (that's why many nerd like me choose LineageOS.). If you and other devs don't have concerns over any of the above said I don't know what else to say.. But again, there's nothing one could do other than open communication and clarification on Google's service terms. "Also, users should be encouraged to avoid opting into the location history feature, to disable it if they already opted into it and also to opt out of app & activity tracking along with disabling the location features elsewhere." I really suggest you put that Google marketing brochure aside. Here's an article detailing an investigation by AP which showed how "turning off your Location History only stops Google from creating a timeline of your location that you can view". Also if you followed the testimony of Google's CEO before U.S. congress you have caught how Google couldn't even answer basic answers like "whether Google can track his phone as it moves around the room". Unless you can direct me to a passage in the Google privacy terms which state that Google Play Services only provides data to other Apps and data at no point is intercepted/gathered by Google I'm not going to bother explaining my 70 years old grandmother how to "pause" Google activity logging (which will achieve nothing in the end, other that YOU can't see the location history). "If they had built into a monthly release of AOSP and the next major release, they could have just kept it as a separate permission and hidden that it depends on technology that could be used to track location." I see that and that's why I said that there's no solution to this. AOSP is wonderful and it's a good thing that location is kept separate and not hidden like in Apple's case (where not even Bluetooth is required). But it's a bad thing that AOSP gets "extended" with additional closed-source software to deliver "better services" "for free" - free services that can't be removed without breaking the system (leaving only the option of using other builds like LineageOS). TLDR; In the end no one will doubt that have gotten a masterpiece of a solution. The cost also seems quite low, public demands have been quickly satisfied. The genius really lies in the details. Please don't take any of what I said as an offense. I think SAP devs and contributors are doing their best job possible. This isn't really an issue because most users running Android have been sharing their location knowingly or unknowingly anyway. And after all, upon launching CWA the user is informed that location may be read by other applications. It's a free choice, take it or leave it. However, opting-out of location sharing isn't as simple as restricting permissions and disabling activity tracking - this should be laid out in GREATEST depths, openly and transparently without scaring users! IMHO this is within the responsibility of contractors, government and press office. Those who choose to truly opt-out by using a different Android build like LineageOS, for now at least, won't be able to use CWA. |
|
Thank you all for the lively discussion. In the meantime, the location permission aspect will be looked into by the team (https://github.com/corona-warn-app/cwa-backlog/issues/17) and we hopefully find a better solution in one of the upcoming versions. |
|
Here's an interesting article discussing what I said earlier about the power imbalance between states and tech giants like Google https://www.nytimes.com/2020/07/20/technology/google-covid-tracker-app.html. Many countries pushed Google to clarify permissions, Germany unfortunately expressed no concerns - not surprising seeing SAP does not see any issues with sharing location data. One quote from the article which perfectly describes the situation: “With this app, you’re invited, by the government strongly appealing to your sense of responsibility and morality, to give away your live location to entities that are getting a profit out of it, in order to protect public health,” said Massimo Zannoni, an electronic engineer in Zurich. And here's another article detailing how scientists found out that Google Play Services sends all available device data, including IP address and location, to Google servers every 20 minutes: https://www.deutschlandfunk.de/corona-warn-app-play-services-uebermitteln-daten-an-google.684.de.html?dram:article_id=481253. And because CWA relies on Play Services and location you're essentially feeding Google with data including location (obvious). |
|
And those articles "only" point out google can collect LOC data, but on top ALL other installed apps 3rd party that have the location data permission on, now can track the users permanently. Before installing the CWA app (or using Google BLE tracing protocols generally) one could give LOC permission to all 3rd party apps, BUT deactivate GPS permanently in settingsmenu until one really needed the help of apps in certain locations. Then turn on the GPS in settingsmenu, use the one 3rd party app you need (and send all LOC data for that short amount of time to all other 3rd party apps) and after that turn GPS off for good again. Two finger slides, two buttons pushed - that's all. Now with CWA on, if you are privacy aware, you have to manually deactivate LOC permission on ALL 3rd party apps (then GPS data is - as it seems "only" collected by google), but if like to use the location benefits of a 3rd party app in a certain situation, you have to again manually activate LOC permission on that 3rd party app deep in apps-menu and deactivate it manually afterwards in same menu. That is really annoying and will push the user to leave it activated for good and finally send all your LOC data permanetly to all 3rd party apps. |
|
You can find the study analyzing privacy of each COVID app and data shared with Google Play Services here: https://www.scss.tcd.ie/Doug.Leith/pubs/contact_tracing_app_traffic.pdf. This is not a new issue, Google has been known to collect user data as part of their business model. However, what is new and troubling, also according to the researchers, is that governments are actively encouraging their entire population to install these apps, effectively feeding Google with huge amounts of more data. What's fatal about this is that some government and the corporations involved seem to be entirely unaware (or pretend to be unaware) that they're encouraging corporate spying on their population. Quote from the paper: "That said, given that many governments are encouraging entire populations to use these apps it is necessary that the detail of their operation be visible to enable properly informed choices by users and potential users of these apps." Even though Google has now provided a documentation for the back-end it's just an example code and everything related to Play Services is completely missing. In my opinion a solution where contact tracing is implemented in Google Play Services should never have been accepted. SAP should force Google, together with other companies, to isolate the Exposure Notifications API from Google Play Services. That however would require SAP stop ignoring the problem and stop re-framing it to a communication problem. My guess is: since tax payers bought "Die Katze im Sack" nothing will happen. Concerns should have been addressed months ago, now it's just a matter of time until these tracing apps go obsolete (as can be seen by declining ratings). |
I, and certainly many other members of the interested public, are frustrated by your heavy handed approach regarding the question of misunderstood permission requirements related to the (falsely) closed issue #262 and all other issues that have been closed with reference to it #473 #476 #488 #493 #497
The fact of the matter is: A significant proportion of the population (including people with Github accounts who are in the top echelons of tech literacy) are confused about the fact that the app requires location/gps permissions.
Yes, we know that you don't track our location. But people are still confused if you say one thing and request something else. You have to explain that this is because technically you could determine the location, which is why Android requires permission, but that you don't do so and tha there's no other way to use BLE because BLE intrinsically can be used for tracking.
Just saying that you knew this would come up and ignoring it isn't enough. It raises the question why you didn't prepare a good explanation that is easily understood and linkable.
On social media, there are hundreds of well-intentioned advocates like me trying to assuage concerns. But we can only do so much. We need your help with good FAQs, resources etc. By just closing issues without solving the underlying problem you're not helping anyone.
List of issues referencing 262
@SebastianWolf-SAP, this is directly for you and your boss. You are doing an impossible job. You seem to be the only one bug triaging. Please, please, get someone else to help you. Right now this is a job for 5 people not one. It will help making sure the app gets used by as many people as possible. It's your responsibility to ask for help.
The text was updated successfully, but these errors were encountered: