-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question on permissions #307
Comments
Hey Sorry not too sure I follow regarding the DEPENDENCY INFO BLOCK stuff Regarding permissions We need either the Location or Nearby permission in order to use WiFi direct APIs. Newer versions of Android do not need location and only request Nearby, old versions where Nearby does not exist request location. Without location I am unable to use WiFi direct which powers the hotspot Access point. Location/nearby permission is not used for anything else, except these absolutely essential WiFi direct permissions. |
I gladly help filling the gaps if you let me know what you're missing there. In our point of view, it has two issues: it's a binary blob injected that cannot be verified (so it's proprietary, essentially making the app "not fully F/LOSS") – and it can be abused to inject "PUA" (to put it friendly and not saying "malware" straight out) without breaking the signing. So it's proprietary and risky. Which is why I suggested to keep it out of the APK. If you prefer, you can keep it in the AAB you upload to PlayStore, as Google does have the means to verify it (after all, that blob is encrypted with their key). In that case, simply skip the
Thanks for confirming! I just needed to be sure before I add that to the app's "green list" – which I'e done now: android.permission.ACCESS_FINE_LOCATION: needed on lower Android versions in order to use WiFi direct APIs
android.permission.ACCESS_COARSE_LOCATION: needed on lower Android versions in order to use WiFi direct APIs
android.permission.NEARBY_WIFI_DEVICES: needed on higher Android versions in order to use WiFi direct APIs So this is how it will look now in the app details: If you want to, descriptions can be added to the other permissions as well. Just let me know then. |
Thanks! I will create and publish to github a new flavor which will set those two flags to false. Google play builds will still keep them on to play nice with big G, but that shouldn't end up being a concern for the fdroid repo. |
Version 43 is in pre-release on GitHub, which was built as a flavor with those flags off. Once I am approved on the Google store side I will mark 43 released, hopefully this will play nicely with the repo as well. Thanks! |
Thanks! I've just checked: the IoD updater will ignore pre-releases for your app (can be enabled, usually for packages intended to have their test/beta versions here in the repo while e.g. having F-Droid.org shipping stables only). So Version 43 should be fetched once you mark it released. Should Google complain about the missing blob (I haven't yet heard from such a case), you could keep it inside the AABs (which is what you upload to Play) while still leaving it out of the APK (which IoD takes). Luckily, each has its own switch. |
With the new release of 43, this should be pulled in by your updater. Thanks for your contribution to the project! |
The scanner here reported for your last release:
Could you please clarify what those permissions are needed for? The
DEPENDENCY_INFO_BLOCK
can be easily avoided by a tiny adjustment to yourbuild.gradle
btw:For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.
Thanks in advance for your help!
The text was updated successfully, but these errors were encountered: