Think this is a general toast, imagine each other Android distro adding their own, you want F-Droid to keep track of them all and have lists what to show on which one? I disagree

Think this is a general toast

What do you mean?

imagine each other Android distro adding their own

I don't think this is a concern. I don't really know much about this space, but my understanding is that Android based operating systems generally don't add new permissions. Please do educate me though, if you can (which I assume).

To me it seems that it's clearly not in the interest of the F-Droid project that EVERY PERSON using F-Droid on GrapheneOS is shown a toast about an unexpected permission (that isn't actually unexpected), EVERY TIME they update or install an app.

What do you mean?

It means, that the next time this is encountered, the Client will show a toast instead of freaking out that the app permissions list is one but on install the permission list is... something else.

Last time the GOS head was here, they were upset about how F-Droid even shows permissions in app details, they were up in arms about it not being perfect and correct. Now they... inject a permission? Mmmkay

Android based operating systems generally don't add new permissions

But yet GOS added one, so... "others" might choose to add some as well, or choose to import this change (like they do with other features), you want the Client to NOT show this on GOS but show on "others" or never show or?

The interest of F-Droid is to work well on all Android distros, not to push contributors to maintain never ending lists of exceptions and special quirks that are never up to date as each distro moves its own goalpost w/o ever considering F-Droid or the rest of the ecosystem.

How likely is the potential maintenance burden? How likely is it for Android based operating systems to add permissions?

My impression is that it's very unlikely.

The interest of F-Droid is to work well on all Android distros

It's not going to work well on GrapheneOS if you decide to show the toast.

not to push contributors to maintain never ending lists of exceptions and special quirks that are never up to date as each distro moves its own goalpost w/o ever considering F-Droid or the rest of the ecosystem.

This doesn't seem like an accurate description, to me.

I expect that there's going to be a ton of people, irritated by the toast, spending time trying to figure out what's going on, posting on forums and in comments and stuff, and, and and. I expect so much irritation, time and energy spent on this. All of which could be prevented, I assume, very easily.

Sincerely, what do you expect?

It's not going to work well on GrapheneOS if you decide to show the toast.

How does that actually impede anything? Did F-Droid Client stop working? Did apps stop updating?

Ok. I'd say showing the toast is "not working well", but we don't have to agree on that.

I, of course, still expect this:

I expect that there's going to be a ton of people, irritated by the toast, spending time trying to figure out what's going on, posting on forums and in comments and stuff, and, and and. I expect so much irritation, time and energy spent on this.

I'd really appreciate it if you could answer my questions.

@leoheitmannruiz

I expect that there's going to be a ton of people, irritated by the toast, spending time trying to figure out what's going on, posting on forums and in comments and stuff, and, and and. I expect so much irritation, time and energy spent on this. All of which could be prevented, I assume, very easily.

this is not a question

The ones in my previous comment: #2914 (comment 2277167673)

ping @licaon-kter

I've already answered to all the text that ends up with ?

There's basically nothing to add when the other party can't never be faulted... else we get twitter posts throwing dirt at F-Droid and fanbois penning blog posts on privacy guides about how F-Droid keeps Android unsafe.

I don't feel like you've answered these:

How likely is the potential maintenance burden? How likely is it for Android based operating systems to add permissions? Sincerely, what do you expect?

There's basically nothing to add when the other party can't never be faulted... else we get twitter posts throwing dirt at F-Droid and fanbois penning blog posts on privacy guides about how F-Droid keeps Android unsafe.

I'm not sure what your point is.

I'm not sure what your point is.

Really? #2914 (comment 2277180807)

I don't feel like you've answered these:

See "But yet GOS" in #2914 (comment 2277116789)

I expect that there's going to be a ton of people, irritated by the toast, spending time trying to figure out what's going on, posting on forums and in comments and stuff, and, and and. I expect so much irritation, time and energy spent on this.

you mean people would inquire why their Android distro injects/grants random permissions to random apps? That can't be a bad thing, right?

my first though was "I'd like to know if, my random XDA ROM for my non-premium Google device unsupported by the big security fellows, does something bad" /nojoke

@licaon-kter POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

You've repeatedly made inaccurate technical claims about GrapheneOS and our team. That includes supporting and spreading fabricated stories targeting me with harassment.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

If you remove this response or make further inaccurate claims about us, we'll post another public response and will contact multiple organizations about the ongoing misinformation and libel from F-Droid developers.

Another option to fix this would be on the side that injects a custom permission. Just don't report this permission if F-Droid asks for it.

I'm afraid that practically this isn't an option. It seems as if the GrapheneOS project is interested in minimizing usage of F-Droid.

Always have been

@grote @leoheitmannruiz @licaon-kter POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

You've repeatedly made inaccurate technical claims about GrapheneOS and our team. That includes supporting and spreading fabricated stories targeting me with harassment.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

If you remove this response or make further inaccurate claims about us, we'll post another public response and will contact multiple organizations about the ongoing misinformation and libel from F-Droid developers.

you mean people would inquire why their Android distro injects/grants random permissions to random apps? That can't be a bad thing, right?

I very much believe that this is a bad thing.

I believe that, at the end of the day, GrapheneOS is highly unlikely to change anything in this regard and people using F-Droid on GrapheneOS are going to have a bad time.

I don't feel like you've answered this questions:

How likely is the potential maintenance burden? How likely is it for Android based operating systems to add permissions?

Just to make sure, what is the reason you're not interested in adding a conditional? Is it the potential maintenance burden or (or perhaps a combination, of course) more of a "this is on GrapheneOS, we shouldn't have to spend resources on this".

I feel like this is fairly important and I very much want to avoid the current behavior getting into the next stable release, people complaining and you (the project) deciding to hide the toast after all. So, I'd really like to hear some more opinions on this (also I'm just very curious what you think :)

If two more people or so say, "no, @leoheitmannruiz, you're silly and wrong" then I can happily leave this be. Not so much currently :/ Hope you understand.

CC: @eighthave @uniqx @jspricke (not sure who else, also I'm not sure if it's fine to ping, so I'll leave it at this)

How likely is the potential maintenance burden? How likely is it for Android based operating systems to add permissions?

I already said "But yet GOS added one, so... 'others' might choose to add some as well, or choose to import this change (like they do with other features), you want the Client to NOT show this on GOS but show on 'others' or never show or?" did you miss it?

Just to make sure, what is the reason you're not interested in adding a conditional? Is it the potential maintenance burden or (or perhaps a combination, of course) more of a "this is on GrapheneOS, we shouldn't have to spend resources on this".

why do you keep insisting it's a "GOS" thing exactly? It's a "random distro thing" for me. Random distro decides to inject permissions for apps... Please answer my question above: should F-Droid signal something when EXTRA permissions that differ from the app manifest are added by the distro or not?

If the answer is YES, the next question is: yes for all distros or only for those that are not named GOS?

If the answer is NO, the next question is: can this be a security issue?

did you miss it?

I did not. Sorry, I should have elaborated on my question.

I think I was interested in some more qualifiers, more than just "they might".

why do you keep insisting it's a "GOS" thing exactly?

Because it currently it is.

It's a "random distro thing" for me. Random distro decides to inject permissions for apps...

But of course you're right in that this is fundamentally not a GrapheneOS specific issue.

should F-Droid signal something when EXTRA permissions that differ from the app manifest are added by the distro or not?

Which one of the following are you asking (or are you asking another question)?

1. Should F-Droid signal something when the OS reports different permissions than the index?
   • I don't have a strong opinion, but probably it makes sense.
2. Should F-Droid signal something when the OS reports different permissions than the index because it adds a custom permissions (as in the case of GrapheneOS with android.permission.OTHER_SENSORS)?
   • I think, no, as the permissions discrepancy is expected.

@licaon-kter @leoheitmannruiz POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

You've repeatedly made inaccurate technical claims about GrapheneOS and our team. That includes supporting and spreading fabricated stories targeting me with harassment.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

If you remove this response or make further inaccurate claims about us, we'll post another public response and will contact multiple organizations about the ongoing misinformation and libel from F-Droid developers.

Also note that F-Droid doesn't know if the permission gets injected by the ROM, or if the repository lied about the real app permissions. I think it is better to warn the user if we find extra permissions. A toast is hardly a big inconvenience for users.

We already have to implement so many workarounds for all sorts of Android OEM specific issues that one less is always good.

Also note that F-Droid doesn't know if the permission gets injected by the ROM, or if the repository lied about the real app permissions.

Is this a concern though in this case? That is, if fdroidclient were to simply check IF (os == grapheneos) AND (unexpected_permission == android.permission.OTHER_SENSORS) THEN hide_toast.

GrapheneOS grants apps the OTHER_SENSORS permission by default. Whether they asked for it or not.

A toast is hardly a big inconvenience for users.

You might be right, of course, though I certainly disagree. Reminds me of https://xkcd.com/2501/

I've read a few comments on the issue trackers along the lines of admin#469 (comment 1756945463)

I feel pretty confident that it should very much be in the interest of the F-Droid project to not show (especially) these people a toast about an unexpected permission that isn't unexpected.

We already have to implement so many workarounds for all sorts of Android OEM specific issues that one less is always good.

I understand. I just feel like this small "workaround" is surely worth it.

I think, no, as the permissions discrepancy is expected.

IF (os == grapheneos)

why do you ask about extra contributors burden when you clearly understand whats needed?

expected means that we know, did GOS announce this to all the impacted parties? No? Did we randomly find out as users complained? Interesting... didn't you say it's better that users don't complain and open issues? This should go both ways...

oh look... some distro added a new one, let's add an exception, but it's only for Android 14, they changed their mind for 15, let's add another OR, and it's not for all the devices because some don't have thing so let's grep for device identifier and...and and...

they were all small workarounds until they piled up

@grote @licaon-kter POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

You've repeatedly made inaccurate technical claims about GrapheneOS and our team. That includes supporting and spreading fabricated stories targeting me with harassment.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

If you remove this response or make further inaccurate claims about us, we'll post another public response and will contact multiple organizations about the ongoing misinformation and libel from F-Droid developers.

Did it become an issue after a F-Droid client version bump or a GrapheneOS version bump? As far as I remember, this permission has been there for years on GrapheneOS systems, and F-Droid client didn't complain?

I see two issues with the report being in a snackbar:

• Depending on the translation used, accessibility settings or size of the device, you will not be able to read the most important part of the message. I only found out today by chance what was the issue I was encountering because the "OTHER_SENSORS" part was cut on my side. The minimum fix for this would be to write it the other way around: "android.permission.OTHER_SENSORS: App has unexpected permission"
• The message just disappears after 2~3 seconds, but doesn't tell the user what it implies, and what to do, and just install the app anyway. In that case, it's the same as not reporting anything IMO.

If you believe this report is important and should stay around, I believe it would be more meaningful to show a dialog box with "App has unexpected permission(s): [list of unexpected permissions]. [Learn more (Link to a Wiki article or something, with more details such as explaining that some OS add permissions, like GrapheneOS with android.permission.OTHER_SENSORS)]. [Two buttons: Cancel / Continue anyway]"

At least, this would solve this issue:

I expect that there's going to be a ton of people, irritated by the toast, spending time trying to figure out what's going on, posting on forums and in comments and stuff, and, and and. I expect so much irritation, time and energy spent on this.

Because in the current state, we just don't understand what's going on… Not just GrapheneOS users, any user experiencing this snackbar.

I believe it would be more meaningful to show a dialog box

Problem is that the install process happens async and we only learn about the permission mismatch after we downloaded the APK by which the user may have left our UI. The Toast isn't the best we can do, but it was the easiest to fix the issue where apps on Graphene would not install at all because of the mismatch.

I believe it would be more meaningful to show a dialog box

please don't wow, that would be terribly annoying

I believe it would be more meaningful to show a dialog box

please don't wow, that would be terribly annoying

I agree, but I thought it was something important to you (like some kind of security warning). But I seem to understand from the following message that it's rather intended for installation failures cases.

The Toast isn't the best we can do, but it was the easiest to fix the issue where apps on Graphene would not install at all because of the mismatch.

I don't experience the issue. I have both a toast and a successful install.

What about pushing a notification error instead of a toast, and only when the install actually failed?

A notification that would look like this:

• Title: Installation failed
• Subtitle: android.permission.OTHER_SENSORS: App has unexpected permission
• Action buttons: Learn more (link to Wiki article)

At the same time, put it in a distinct notification channel, so that user can easily hide them if they are annoyed by it.

What do you think?

It seems you have perhaps misunderstood.

Not too long ago, F-Droid didn't automatically update apps on GrapheneOS because of the permission mismatch mentioned in this issue. My understanding is that it was decided to automatically update apps despite the permission mismatch, but to show a toast.

For the full context, see #2828 (closed) and the issues and merge requests mentioned therein.

I don't experience the issue.

install June 2024 QPR and F-Droid Client 1.20, per #2828 (closed) yes

Also, the issue was that "users got an install dialogue" not anything more critical

@grote @licaon-kter POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

You've repeatedly made inaccurate technical claims about GrapheneOS and our team. That includes supporting and spreading fabricated stories targeting me with harassment.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

If you remove this response or make further inaccurate claims about us, we'll post another public response and will contact multiple organizations about the ongoing misinformation and libel from F-Droid developers.

@thestinger I get tons of email notifications about this or a very similar posting from you.

If you edit your post, please make sure that you not delete and re-submit it. It spams my mailbox.

(Otherwise I am neutral to the "dispute" since I am a bystander, and I am affected by the main issue which is reported in this thread.)

Regards!

@dreieckli You posted a positive reaction to someone linking harassment content based on fabricated stories from a content creator who is openly a Kiwi Farms user:

#2914 (comment 2443518499)

@thestinger I don't know what a Kiwi Farm is, and I do not have the capacity to dig into it.

And please stop tagging me here; I am not interested in any stuff here about people liking or disliking other projects, regardless of (dis)credibility.

@dreieckli

I don't know what a Kiwi Farm is, and I do not have the capacity to dig into it.

If you don't have the capacity to dig into it, you shouldn't express support for someone linking content aggressively targeting me.

And please stop tagging me here; I am not interested in any stuff here about people liking or disliking other projects, regardless of (dis)credibility.

You posted a reaction in support of someone who posted a link to harassment content based on libel. If you want to be neutral, you can and should undo that. You aren't a bystander and aren't neutral because you actively involved yourself in supporting attacks.

Sounds to me like the GrapheneOS devs didn't fully consider the ramifications of adding a new permission, and that their implementation has issues. It sounds like they are somehow injecting that permission. Android has a system to allow new permissions to be defined and used, and F-Droid works with that. Seems like GrapheneOS should use that as well.

@eighthave POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

You've repeatedly made inaccurate technical claims about GrapheneOS and our team. That includes supporting and spreading fabricated stories targeting me with harassment.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

If you remove this response or make further inaccurate claims about us, we'll post another public response.

@eighthave I agree that GrapheneOS should. But that doesn't mean that one can't offer a one-liner in the meantime and get back to business because there indeed are more important things then a toast. I mean, yes, one can, if one has the time and energy, discuss with the GrapheneOS people this issue, but one doesn't have to and can invest the time and energy in other things, especially as it sounds as if discussions like these haven't been very fruitful in the past.

The place to discuss GrapheneOS bugs is on their trackers. We're not users, and have already enough on our plate.

The toast itself is no GrapheneOS bug, even though the trouble with the toast exists due to a decision by those people.

Concerning the thing with the users: I am a user of both GrapheneOS and F-Droid. And I like both pieces of software for various reasons and I want them to work fine with each other and not annoy me. I see the solution to this very specific problem as an easy win, you may disagree with me.

The bug seems to be that GrapheneOS didn't implement adding new custom permission properly.

@eighthave POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

You've repeatedly made inaccurate technical claims about GrapheneOS and our team. That includes supporting and spreading fabricated stories targeting me with harassment.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

If you remove this response or make further inaccurate claims about us, we'll post another public response and will contact multiple organizations about the ongoing misinformation and libel from F-Droid developers.

I have the same after an f-droid update. On crDroid 7.6-build of Android 11 on a "markw"-device (which I can't update, but originally the issue was not here and appeared only with an f-droid update).

you get a toast @dreieckli ? that's the issue? pics?

you get a toast @dreieckli ? that's the issue?

I wanted to add to this that it is not limited to GrapheneOS. The initial post mentions a GrapheneOS relation specifically.

pics?

It goes away too quickly that I can take a screenshot.

Anyway, from how I understand the comments here, it is already known what we are talking about.

So your crdroid 7.6 Android 11 injects the same permission as Graphene Android 14+ ?

The toast says exactly the same "android.permission.OTHER_SENSORS" ? @dreieckli

@dreieckli are you practically capable of capturing the toast in a screen recording? I feel like that might be helpful.

If you do, please consider opening a separate issue.

The toast says exactly the same "android.permission.OTHER_SENSORS" ? @dreieckli

Yes, I was internet-searching for exact that string and so got here.

are you practically capable of capturing the toast in a screen recording? I feel like that might be helpful.

Since you think this is helpful, I did some effort to do so.
Here, as a video (showing Android version at the beginning, too):

---

F-Droid-installation_unexpected-permission.screenrecording

---

Does this help?

If you do, please consider opening a separate issue

Why and where? As I have learned in the discussion in this issue this is nothing to blame F-Droid for, so I do not see that this even should be a separate issue in the F-Droid tracker. And crDroid development has moved further to more modern Android versions, so nothing to be done there, too, since I do not have the latest crDroid.

Regards!

Since you think this is helpful, I did some effort to do so.

Thanks!

Why and where?

Parts of this issue are GrapheneOS specific, which is why I feel like it probably makes sense to try to keep it that way.

As I have learned in the discussion in this issue this is nothing to blame F-Droid for, so I do not see that this even should be a separate issue in the F-Droid tracker.

Personally, I'm definitely not sure that the issue you are experiencing is due to the same cause as the one for which this issue was created. I feel like it might make sense to investigate it a little.

As I have learned in the discussion in this issue this is nothing to blame F-Droid for, so I do not see that this even should be a separate issue in the F-Droid tracker.

Personally, I'm definitely not sure that the issue you are experiencing is due to the same cause as the one for which this issue was created. I feel like it might make sense to investigate it a little.

So the maintainers/ admins here (@licaon-kter? @grote? I don't know if they are admins here) should decide. I do not dare to open an issue and be put off of doing things wrongly.

If I get an official statement that this should be a separate issue in the f-droid issue tracker, I would make it. Otherwise not.

Regards!

@licaon-kter POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

You've repeatedly made inaccurate technical claims about GrapheneOS and our team. That includes supporting and spreading fabricated stories targeting me with harassment.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

If you remove this response or make further inaccurate claims about us, we'll post another public response and will contact multiple organizations about the ongoing misinformation and libel from F-Droid developers.

I'd like to know what action I am supposed to take from this Toast?

I completely accept that this is GrapheneOS's fault (and I'll raise an issue with them) - but the notification is coming from F-Droid. You've given me this information, but I don't know what I can do with it.

What is the intended outcome of showing me this message?

Being informed in the outcome. You are informed now.

But I am not informed. When I saw the notification, I was confused. The only information I could find was this GitLab issue - which isn't very user friendly.

I still don't really understand what the problem is. I also have no idea how to fix it. I don't know what the risks are of continuing to use either F-Droid or GrapheneOS.

If anything, I feel less informed than I did before I saw the Toast.

I still don't really understand what the problem is

a new permission was added to the application on install, one that was not asked by the application

I also have no idea how to fix it.

use an Android distro that does not inject permissions, if you don't want to see that

I don't know what the risks are of continuing to use either F-Droid

F-Droid just notified you of what your distro does, what "risk" is related to F-Droid exactly?

I don't know if you're officially affiliated with F-Droid, but your attitude is really off-putting.

There are a bunch of people here saying that they find the wording of this prompt confusing. Rather than accept that it could be improved, you seem to ignore their concerns or are just plain rude to them.

I stumbled across this thread because the new Toast confused me. I'm leaving this thread because it is clear that F-Droid doesn't want to listen to user feedback.

The toast means that the app has one or more permissions than are declared in the repository index. This can also happen if a repository lies about the permissions that apps have, so users should get informed. F-Droid can't distinguish between OS injected permissions or permissions that are simply missing from the repo. Feel free to suggest a better wording for this.

Hi Torsten. What action do you want the user to take here? I don't know what the wording should be - because I don't understand what the problem is.

I guess if an app secretly add GPS and Microphone permissions, I should uninstall it. But given that Android asks me before enabling those permissions, is it a problem?

At the very least, could you put an icon on the Toast so that users know where it has come from?

I'm reluctant to get further involved in this discussion given the previous responses to other concerned users, so I'll mute any further notifications from this thread.

@edent

but your attitude is really off-putting.

not sure where you can see my attitude exactly and how is attaching an attitude to my text helping here

You can suggest a better text: https://gitlab.com/fdroid/fdroidclient/-/blob/master/app/src/main/res/values/strings.xml#L461 to convey what happend

But given that Android asks me before enabling those permissions, is it a problem?

Did it ask you when it injected an extra android.permission.OTHER_SENSORS ? Can you deny it?

so I'll mute any further notifications from this thread.

Feel free to suggest a better wording for this.

Drafting from my limited understanding from what is happening here and from what F-Droid's intention of this message is, what about something like

"Non-declared extra permission [permission-name] in App [app-name]. Either app wants more than declared, or automatically added by the operating system."

?

If F-Droid cannot discern if the extra permission comes from the App or from the OS, then what about allowing to mute that for a specific permission in F-Droid advanced settings?

Regards!

unfortunately the toast is really small, and gets cut off

unfortunately the toast is really small, and gets cut off

If it is intended to be a warning the user should be aware of, it should not be a toast but a notification or a dialogue, because the toast is shown only shortly and thus is easy to get missed if the user does not continuously look at the screen.

If it is not a warning the user should be aware of it could also be just not displayed at all.

I agree with @dreieckli here. We should think why is that information displayed to the user in the first place? Does it warn about some possible security tempering, or something else important?

• If the information is of no consequence, and would not influence user actions, it should not be displayed at all, but just logged in logcat with debug priority.

• If however that information is important, then it really should be more permanent (and include a explanation, perhaps with a link to a web page explaining the issue in more details) and ask user how to proceed (i.e. continue with install or cancel). Because, without extra information, users won't be able to make an informed decision. And if that dialog would be popping up all the time on GrapheneOS, there are (at least) two extra ways to handle that:

  • just add a note in a dialog that this compatibility-breaking "feature" of GrapheneOS is expected (although GOS lead probably won't like it (and nobody really needs more drama there).
  • add an option in advanced preferences where users can disable those notifications (and link to it from the dialog, describing security implications of such action).

If however that information is important, then it really should be more permanent

We considered this, but due to lack of time we implemented the Toast first as it was the lowest hanging fruit. Pull requests are welcome for surface permissions mismatches in a better way.

just add a note in a dialog that this compatibility-breaking "feature" of GrapheneOS is expected

We can't do this as there may be other reasons for the actual permissions to mismatch what is in the index.

add an option in advanced preferences where users can disable those notifications

I prefer not adding toggles for all kinds of details. The UI should work for everyone out of the box. If this would be a system notification, the system would provide a toggle though.

@mnalis The video you're spreading consists nearly entirely of fabricated claims and spin with the clear purpose of targeting me with harassment. The creator of the video is openly a Kiwi Farms user who posted this content shortly after I was repeatedly swatted due to harassment the creator of this video was already supporting on a consistent basis. You've repeatedly targeted me with libel and harassment, and you've made the mistake of doing it under your real name. If you think that nothing is going to be done about it and that you won't face any consequences for it, you couldn't be more wrong.

@edent @licaon-kter @grote @mnalis POST_NOTIFICATIONS is a standard Android permission added in Android 13. It gets added for all legacy apps targeting API levels below 33 since it didn't exist. There were multiple previous additions and splits of permissions with the same standard Android infrastructure. GrapheneOS uses exactly the same infrastructure for our Sensors (OTHER_SENSORS) permission.

You were wrong to blame this on GrapheneOS and use it as an opportunity to spread misinformation about GrapheneOS. We even previously worked around this F-Droid bug on our end despite it impacting stock Android.

We've publicly responded to the highly inaccurate claims and attacks on GrapheneOS you've made here:

https://discuss.grapheneos.org/d/23666-response-to-misinformation-about-our-sensors-permission-from-f-droid

The video you're spreading consists nearly entirely of fabricated claims and spin

@thestinger I don't think so. The video seems very well documented and explained to me. So:

• If you don't want your continuous abhorrent behaviors to be shared, I would recommend you should stop behaving like that.
• If you dispute that video factual accuracy, many people would like to know: please post a response video answer (claim by claim) what parts you didn't actually write (or how you've been misinterpreted), and provide same level as evidence as Louis did, instead of generically claiming "those are almost all lies", which is clearly incorrect. I've personally checked a lot of references in that video (which were publicly posted by you on multiple platforms, so everybody can verify for themselves too) and those seem accurate proof of your hostile behaviour. Until such time as you provide proofs to the contrary, I'll continue believing that the rest of the Louis's claims in that video (e.g. your abhorrent private conversations with him) are true too.
• If you claim that that video engages in illegal activities, provide evidence to Youtube to take it down, instead of harassing people who commented on it.

Anyway, as I told you before, I'm not interested in more drama regarding your problematic behaviors, nor your proof-less accusations nor your attempts to restrict free speech. I'd love if you would reform (or at least let someone else be your voice to the other communities and prevent yourself from doing that and damaging GOS reputations greatly), but I've lost most hope by now. But it would help the GrapheneOS project greatly if you would reallocate your time from social interactions (which you seem to be very bad at, IMHO) to writing code (where you're admittedly quite good).

I've even deleted GrapheneOS and stopped using any of its forums as you requested of me before. Would you please also stop stalking, contacting and mentioning me on other platforms any further?

If you think that nothing is going to be done about it

I do hope that something is going the be done about it, see bullet points above, sorted by the order of importance. Anyway, I'm not going to read nor reply to any of your further comments.

If you (mistakenly) think you have any legal claims against me, let your lawyer contact me instead and I'll sort it out with them.

---

(hopefully there will be some useful technical discussion resulting in F-droid getting better; but I'm unsubscribing to reduce further offtopic)

@mnalis

The video seems very well documented and explained to me.

The video consists entirely of blatant fabrications and spin with the clear goal of directing harassment towards me. A huge portion of the video is self-evidently dishonest and contradicted by what is shown including the emails leaked by Rossmann. Rossmann has made similar attacks on Linus Tech Tips including similar baseless claims of them being delusional with similar assignment of a diagnosis to them. He has similar to numerous other people. He appeals to what he knows are Kiwi Farms tropes and tries to portray the people he attacks as being crazy and doing/saying things they haven't. It is not only someone he has done to myself and GrapheneOS.

Even the title and whole basis of Rossmann's video was a lie. It was disproven by Rossmann's own community. It has been proven from Rossmann's own videos that he continued using GrapheneOS on a phone with his daily driver apps and accounts signed in. He continued using GrapheneOS for many months afterwards. His claim of deleting was proven to be a lie, as were his justifications for the video based on supposedly being scared of us and continuing to us it. There's almost nothing in the video that's not blatantly dishonest lies and spin.

The video is also structured as support for previous harassment content Rossmann was supporting. The community members of Techlore and CalyxOS repeatedly engaged in violence towards including severe swatting attacks. If you want proof of the swatting attacks, you can get it from the Toronto police department. The initial swatting attack involved around 20 to 30 officers including Toronto's counterterrorism task force armed with handguns and rifles. They blocked off the whole street, filled the street and park behind the house and had guns and bright lights pointed towards us while screaming instructions. They went through the house and cleared it looking for someone who had committed multiple murders and who they had been told had weapons they were going to use to try to kill them. They were looking for bodies and weapons. It was not an authorized search but rather clearing what they believed was a multiple shooting murder situation. This was attempted murder both of myself and my family. Rossmann participated in creating the circumstances which led to this. You're participating in it yourself, and you share responsibility for the harassment you convince others to do through your own libel and harassment.

• If you don't want your continuous abhorrent behaviors to be shared, I would recommend you should stop behaving like that.

It's your serial libel and fabrications aimed at causing harm to me which is abhorrent. We have not yet publicly documented your harassment, but we will.

• If you dispute that video factual accuracy, many people would like to know: please post a response video answer (claim by claim) what parts you didn't actually write (or how you've been misinterpreted), and provide same level as evidence as Louis did, instead of generically claiming "those are almost all lies", which is clearly incorrect. I've personally checked a lot of references in that video (which were publicly posted by you on multiple platforms, so everybody can verify for themselves too) and those seem accurate proof of your hostile behaviour. Until such time as you provide proofs to the contrary, I'll continue believing that the rest of the Louis's claims in that video (e.g. your abhorrent private conversations with him) are true too.

The video consists almost entirely of fabrications and spin. We have made that very claim and we've debunked many partos if it already. Rossmann's video provides clear cut evidence of his own harassment. It shows him trolling me in a direct message to get a reaction for a live stream shortly after I was repeatedly swatted in a severe way by a Techlore community member who supports CalyxOS and wanted to have me killed. Rossmann repeatedly supported that ongoing harassment including on multiple occasions in public. Rossmann was completely aware the swatting attacks by someone else are what was referred to as attempted murder and that he wasn't being accused of it. He engaged in blatant spin and dishonest claims throughout the videos to misrepresent what was said. He pretends to be unaware of things he clearly knew and misrepresents the whole situation and what happened. He lies about what is said in that conversation and elsewhere. He posted a series of emails which also do not match his false claims.

The video leaked private conversations and private information such as the fact that I'm on the autism spectrum. He wrongly portrayed me as delusion and insane. He did all of this as part of aiming to direct harassment towards me and involve Kiwi Farms.

Rossmann justified it by claiming to be scared we were going to do something to him, which never happened. He continued using the OS for many months, which has been proven based on his own videos. We didn't post an article or video attacking him, and all I had said we would do is respond to his multiple public jabs towards me in his live streams, videos and elsewhere. He made the video as preemptive retaliation for believing we were going to respond to his existing attacks on us.

Rossmann is an active Kiwi Farms user who is regularly in public contact with serial harassers on the site and repeatedly brings up his attacks on us. He's actively using them as his personal army to direct harassment towards myself and the rest of the GrapheneOS team. You're personally supporting a Kiwi Farms member's attacks on us and harassment by Kiwi Farms. You engage in the same form of lies and tropes misrepresenting people as insane and lying about what they have said and done. You're engaging in absolutely vile harassment and libel towards me on a regular basis.

• If you claim that that video engages in illegal activities, provide evidence to Youtube to take it down, instead of harassing people who commented on it.

The video is libel and so are your comments here and elsewhere. Taking legal action is an extreme measure requiring a lot of time and resources on both sides. If Rossmann and others like yourself continue engaging in libel and harassment, legal action will be part of how we respond to it.

Anyway, as I told you before, I'm not interested in more drama regarding your problematic behaviors, nor your proof-less accusations nor your attempts to restrict free speech. I'd love if you would reform (or at least let someone else be your voice to the other communities and prevent yourself from doing that and damaging GOS reputations greatly), but I've lost most hope by now. But it would help the GrapheneOS project greatly if you would reallocate your time from social interactions (which you seem to be very bad at, IMHO) to writing code (where you're admittedly quite good).

You claim to not be interested in drama and yet here you are actively engaging in libel and harassment towards me. I was not involved in this thread prior to you coming here to make false claims about me and post harassment material which is objectively from a Kiwi Farms user engaging in serial harassment. It's you who is engaging in libel and harassment. We've archived it and there will be consequences for your obsessive harassment and libel towards me. The fact that we haven't yet publicly documented what you're doing doesn't mean we aren't going to do that. You continue making attacks trying to harm myself and the GrapheneOS project. We have not done anything to harm you in retaliation at this point. We haven't made a thread about, we haven't filed a lawsuit against you and we haven't publicly documented your involvement in this. Do not expect it to remain that way when you continue doing it.

I've even deleted GrapheneOS and stopped using any of its forums as you requested of me before. Would you please also stop stalking, contacting and mentioning me on other platforms any further?

You're engaged in a ludicrous level of DARVO tactics. You're actively engaging in stalking and harassment towards me alongside Kiwi Farms users. You're posting claims and content from Kiwi Farms users, a stalking and harassment site. If you continue libel and harassment towards me, it will not only be met with a direct response. We've archived numerous cases of you engaging in libel and harassment including this thread. If you continue doing it, we'll be publicly responding to it across platforms. We'll post a thread addressing your harassment on our forum, Mastodon, Bluesky and X. You will be widely known for doing it. Do not expect that you can continue pushing lies about me across platforms in an attempt to harm me without us publicly documenting accurate details about your involvement. Posting factual information about what you're doing is not libel and you won't be able to do anything to get us to remove it. It will show up in the top searches for your name. It will show up when you apply for a job. It will show up if someone you start dating decides to look up your name. That is exactly what you have participated in doing to me with blatant fabrications about me, so you have no grounds to claim about the future consequences for you.

I do hope that something is going the be done about it, see bullet points above, sorted by the order of importance. Anyway, I'm not going to read nor reply to any of your further comments.

We've reported you for libel and harassment to GitLab. We have previous contact with GitLab management and will be reaching out to them about it next. If you don't retract and remove your libel and harassment, we'll be publicly responding to it within the coming weeks. If you don't stop, you can also expect a libel lawsuit. We can raise all the money we need to cover years of legal fees. It won't cost us a penny.

If you (mistakenly) think you have any legal claims against me, let your lawyer contact me instead and I'll sort it out with them.

If we decide to take legal action from you, you'll receive information on a lawsuit filed against you. There's no reason for our lawyer to contact you beyond serving you with those documents. You may think a libel lawsuit against you has no merit, but that doesn't change the fact that we can file a libel lawsuit against you. GrapheneOS Foundation operates internationally and you've caused damages to us internationally.

Interesting enough, on a test device with Android 14 crDroid, I get this for the POST_NOTIFICATIONS permission.

That's a new permission introduced in Android 13. It is automatically granted to all eligible apps, so legacy apps still works.

See here: https://developer.android.com/develop/ui/views/notifications/notification-permission

I recommend opening a new issue.

And the issue would be the same as this one ? Except the different text?

It has nothing to do with GrapheneOS, it is a standard android permission. So no need to mention it.

The solution to the issue, however, should be similar to this one.

Fixed issue title

This ticket is specifically about android.permission.OTHER_SENSORS and not other permissions causing a similar toast.

An issue with POST_NOTIFICATIONS is tracked in #3049

@grote This is a long term bug caused by F-Droid having incorrect check for the granted permissions. F-Droid wrongly assumes there are no permissions granted which weren't requested, which is not how the standard Android permission model works. The check does not have any value and is incorrect. There are multiple other cases beyond the POST_NOTIFICATIONS permission and hard-wiring workarounds for each of them is incorrect. It's incompatible with the stock OS in multiple existing cases, future versions of the stock OS and other operating systems based on AOSP which are adding new permissions.

Hard-wiring workarounds for cases you discover outside of GrapheneOS while not doing the same for GrapheneOS makes it clear the goal is hurting GrapheneOS. Purposely doing something to annoy GrapheneOS users because of your grudge against us is malware tier behavior.

You work for Calyx Institute as a paid contractor, an organization which has been involved in ongoing attacks on our project for years. The lead developer of CalyxOS is a former CopperheadOS employee directly involved in the failed takeover attempt on GrapheneOS. It's highly unethical and abusive for people involved with both Copperhead and Calyx to be making decisions which cause harm to GrapheneOS through F-Droid. It's something people and organizations supporting F-Droid can be informed about.

This is a long term bug caused by F-Droid having incorrect check for the granted permissions. F-Droid wrongly assumes there are no permissions granted which weren't requested

Could you please explain this in more detail?

I haven't implemented the check, but the way I understand it, its purpose is to ensure that the metadata about requested permissions (as it is also shown to the user) matches the permissions the app is actually requesting. This is not about granted permissions. The check happens before installing APK.

Previously, F-Droid even denied the installation. I changed the behavior to only warn about extra permissions.

There are multiple other cases beyond the POST_NOTIFICATIONS permission and hard-wiring workarounds for each of them is incorrect.

What would be correct instead?

F-Droid's way of determining which permissions an app requests is incorrect because it's unaware of added and split permissions or other ways more can be added. Special casing specific added and split permissions is incorrect. It's incompatible with future Android releases and other operating systems based on AOSP choosing to add new permissions in the standard way. What GrapheneOS is doing is based on standard Android infrastructure and is done with the same code handling POST_NOTIFICATIONS and other standard permissions which have been added. F-Droid cannot know which permissions will be added and split in the future. Writing code which breaks with future Android versions is wrong, so it's wrong with the stock OS too even if you special case everything they do with this infrastructure.

Aside from that, F-Droid's display of requested permissions is wrong. It conflates requesting the ability to request a permission with actually requesting it and being granted a permission at install time. Android has moved on from an install-time based permission model to runtime permissions, special access permissions, the battery optimization mode and case-by-case requests for access. Displaying those as if they get granted at install time is wrong. The descriptions of the various permissions are also largely wrong since Android doesn't intend it as a user-facing thing and only displays it via a semi-hidden menu. That semi-hidden menu at least groups the ones which are runtime permissions, but doesn't deal with special access permissions, battery mode, etc.

As an example of how this is wrong and QUERY_ALL_PACKAGES is not required to query all packages. F-Droid misleads users into believing apps without it can't do that. Misleading users about what can and can't be done is a privacy and security flaw. It's implicitly claiming apps without those things listed can't do them, yet they can. The descriptions are wrong and the whole approach is wrong. Doing it right would be possible, but complicated, since the permission model varies quite a bit across major Android versions, OEM forks and other AOSP-based operating systems.

What GrapheneOS is doing is not incorrect and not non-standard. It works correctly with any app able to handle the same thing being done in the future Android versions. What's incorrect is writing code which breaks on Android 17 or 18 because they added another permission. It's dependence on an implementation detail that's explicitly not portable and regularly breaks with the stock OS when new API levels come around.

Special casing each way the stock OS uses it in practice will still be broken on future Android versions, and being willing to do that while explicitly refusing to do it for GrapheneOS seems deliberately spiteful to us. How else are we meant to interpret it? The way GrapheneOS has been attacked with inaccurate claims throughout this thread including even blaming us for this F-Droid bug also contributes to that being our understanding of what's happening.

I am un-following this discussion because it floods my inbox.

@thestinger, maybe you can give a positive example to the question "What would be correct instead?", instead of only writing what is not a right approach?

Regards!

@thestinger

How else are we meant to interpret it?

As a sign that your approach to interpersonal conflict isn't working. I'm just a casual F-Droid user, and I can't meaningfully evaluate most of your claims, but accusing F-Droid of "malware-level behavior" is insane, and seriously undermines your credibility. I don't particularly like how the F-Droid team has handled this bug, and I have no reason to doubt your technical analysis, but if this is how you respond to disagreement, then I don't blame F-Droid for not wanting to work with you.

@dreieckli

The sole purpose of the check is to verify if F-Droid's code for figuring out the requested permissions it shows users is correct. That code isn't correct and therefore there are multiple cases where this check triggers, showing users a warning. What the warning should actually say is that a bug has been detected in F-Droid's requested permission display code which should be reported to F-Droid. It should not claim that there is something wrong with the OS for using Android's standard infrastructure for adding or splitting permissions, which Android regularly does itself. POST_NOTIFICATIONS is not the only case of this. It's only of several cases, and some of those are quite subtle. Future Android versions will continue using it. Android-based operating systems can use it too, and it's compatible with apps for the same reason future Android versions using it is compatible.

F-Droid is depending on explicitly implementation defined behavior happening a certain way despite it not happening that way even on a stock Android OS. Hard-wiring all the implementation details about how current Android uses this is still wrong. Hard-wiring a workaround for GrapheneOS is still wrong, but at least we wouldn't be getting the special treatment of not working around the symptoms of a bug which they're willing to work around elsewhere.

This wouldn't have been handled the same way if it was CalyxOS or LineageOS adding a Sensors permission with the standard Android package manager feature for adding permissions. We get special treatment. Our users reporting issues here can expect it to be used to attack GrapheneOS and not resolved.

Revolut added code specifically to ban GrapheneOS and we worked around it. We've done the same with other apps including recent Google injected code ("Automatic protection"). We can handle this the same way.

@gnoutchd Warning people about a privacy/security feature being present and trying to make them believe this is a bug in the OS is the type of behavior seen from malware. This not a bug in GrapheneOS. We do it correctly using the standard Android infrastructure for this. Adding permissions which are automatically added to apps is allowed and apps must be compatible with it or they break on future Android versions. Every time Android adds a new permission this way or splits a permission, it will trigger the same warning. What we're doing is wrong and F-Droid's incompatibility with it is a bug in F-Droid. That's clear based on examples like POST_NOTIFICATIONS using the same infrastructure. F-Droid fixing this in a way that avoids it happening for the stock OS in the future would also fix it for GrapheneOS.

F-Droid developers including 3 of the ones participating in this thread have a history of attacks on the GrapheneOS project, myself and our team. That includes participating in the takeover attempt on GrapheneOS in 2018 followed participating in multiple subsequent attacks on us. It includes support for Kiwi Farms users harassing us. Several F-Droid developers are paid by an organization which was involved in that takeover attempt. It makes perfect sense that F-Droid would be special casing the way GrapheneOS and our users are treated in that context. CalyxOS supporters were the ones who targeted me with multiple swatting attacks. That reflects on the Calyx project because they led their users to that point inaccurately portraying us the way they did and supporting others doing it.

Deliberately performing an incorrect check with no value to users and added special cased workarounds for the symptoms that causes elsewhere but not GrapheneOS is little different from Revolut banning GrapheneOS based on us previously having ro.build.user=grapheneos and ro.build.host=grapheneos system properties. It is special casing GrapheneOS, where GrapheneOS and our users get uniquely poor treatment.

It shouldn't be necessary to inject code into apps to get them working properly due to app bugs or GrapheneOS being specifically singled out for deliberate incompatibility. We could do that but don't want to do it. If we're going to do it, we'll probably do more while we're at it.

@thestinger I am not using GrapheneOS and I got this message. That is why I was here originally.

I don't know what "Revolut" is.

I am not interested in discussions about a war between GrapheneOS and others.

By the way: I want to use GrapheneOS for it's permission management and other features, but I don't since it is not easily available for targets that do not support secure boot chain. (I do explicitly not want to assure myself against "device gets in the hand of bad actors" or "operating system is insecure", I only want to have it easy to control apps, and otherwise want a hacking-friendly device.)

Regards!

@dreieckli

I am not using GrapheneOS and I got this message. That is why I was here originally.

It's a bug in F-Droid which isn't specific to GrapheneOS. It occurs most often for GrapheneOS users due to us using the standard Android infrastructure for adding permissions to add a Sensors permission for all sensors not covered by standard permissions. It makes sense that you've run into it elsewhere. Despite what has been claimed in this thread, it is not a GrapheneOS issue.

I am not interested in discussions about a war between GrapheneOS and others.

The whole topic of this thread is the F-Droid team pretending an F-Droid bug isn't real because it mainly impacts GrapheneOS users and was reported by one as part of their war on our project since 2018.

not easily available for targets that do not support secure boot chain

That's not why other devices aren't supported. The hardware security requirements are listed at https://grapheneos.org/faq#future-devices. Firmware/driver updates are the most important reason for using Pixels along with important hardware security features including hardware memory tagging and the secure element features. Verified boot is just one part of that and not the most important. There are other devices with verified boot for an alternate OS but they don't meet the rest of the requirements.

device gets in the hand of bad actors

Verified boot is not only to defend against physical attacks such as data extraction from a device in the After First Unlock state. It's also to protect against persistent compromise.

I only want to have it easy to control apps

Our privacy features such as Contact Scopes, Storage Scopes and many others including the Sensors permission triggering the F-Droid bug this thread was made about are one part of GrapheneOS. Privacy relies on security. A device missing basic Android privacy and security patches like most Android devices and alternate operating systems is unable to provide decent protection of privacy. Apps regularly abuse privacy flaws fixed in newer releases of Android which are not backported to older releases. Other devices and alternate operating systems do not even ship the backports consistently. Regularly only the AOSP backports like most alternate operating systems is not providing the full patches. Leaving serious known vulnerabilities wide open isn't acceptable on a system aiming to provide good privacy. It's why we focus so heavily on migrating quickly to each new stable release and shipping all the security patches (not only AOSP ones) quickly prior to that if it can't be done nearly immediately.

F-Droid's way of determining which permissions an app requests is incorrect because it's unaware of added and split permissions or other ways more can be added.

By split permission, do you mean those that other APK split could be adding? If so, in my research, so far I always found all permissions reflected in the base APK. Do you have examples where that isn't the case? In any case, for this topic, it doesn't matter much as F-Droid isn't supporting splits.

By added permissions, do you mean those custom OSs may be adding?

Special casing specific added and split permissions is incorrect. It's incompatible with future Android releases and other operating systems based on AOSP choosing to add new permissions in the standard way. [...] F-Droid cannot know which permissions will be added and split in the future. Writing code which breaks with future Android versions is wrong

It does work fine with AOSP though, because they only introduce new permissions based on targetSdk and there are clear rules for it which so far have worked fine for F-Droid.

For POST_NOTIFICATIONS for example, they only add this permission if the app targets SDK 32 or below. Do you have an example where this doesn't work (other than a ROM introducing non-SDK permissions?)

Android has moved on from an install-time based permission model to runtime permissions, special access permissions, the battery optimization mode and case-by-case requests for access. Displaying those as if they get granted at install time is wrong. The descriptions of the various permissions are also largely wrong since Android doesn't intend it as a user-facing thing and only displays it via a semi-hidden menu. That semi-hidden menu at least groups the ones which are runtime permissions, but doesn't deal with special access permissions, battery mode, etc.

I fully agree with the issue that special access permissions, battery mode, etc. aren't covered. Also, permission descriptions used by F-Droid predate the runtime permission model, so those probably can be improved. Merge requests are welcome.

As for not showing requested permissions at all, this is certainly worth a thought. However, there's still many pre-granted permissions which users may want to know about. AFAIK that's the only reason to still show and care about permission lists at all.

What's incorrect is writing code which breaks on Android 17 or 18 because they added another permission.

Yes for me that's a strong argument for not dealing with permission lists and it may outweigh the benefit of showing pre-granted permissions to the user.

By split permission, do you mean those that other APK split could be adding? If so, in my research, so far I always found all permissions reflected in the base APK. Do you have examples where that isn't the case? In any case, for this topic, it doesn't matter much as F-Droid isn't supporting splits.

Android split some permissions into multiple permissions. An app at an older target API level has them split.

It also adds permissions where all apps with an older API level get them added automatically, which is what happened with POST_NOTIFICATIONS for API 33. Our Sensors (OTHER_SENSORS) permission is nearly the same overall approach as POST_NOTIFICATIONS and similar past permissions added by Android. It's a permission which didn't exist before so it gets added as requested to all apps. We have a notification when apps use it while denied and a toggle for users to make it disabled at install time. There isn't much else to it. Any app able to handle stuff like POST_NOTIFICATIONS being added can handle the Sensors toggle. Sensors return zeroed data when disabled and no events, which is not even code added by GrapheneOS but rather how their standard sensor permissions including Body Sensors work.

It does work fine with AOSP though, because they only introduce new permissions based on targetSdk and there are clear rules for it which so far have worked fine for F-Droid.

GrapheneOS is adding it in a similar way to in development Android versions add it where they consider the API level to be an arbitrary high number. There are no rules beyond apps with a target API level below the permission API level having it added. Ours works the same way.

For POST_NOTIFICATIONS for example, they only add this permission if the app targets SDK 32 or below. Do you have an example where this doesn't work (other than a ROM introducing non-SDK permissions?)

This and future added permissions cause F-Droid to give a warning, just like with OTHER_SENSORS. There are also the past cases of added and split permissions.

We aren't the only ones who have added permissions to AOSP in a similar way. Multiple other operating systems also use our OTHER_SENSORS permission code. DivestOS was the most well known before it died.

I fully agree with the issue that special access permissions, battery mode, etc. aren't covered. Also, permission descriptions used by F-Droid predate the runtime permission model, so those probably can be improved. Merge requests are welcome.

As for not showing requested permissions at all, this is certainly worth a thought. However, there's still many pre-granted permissions which users may want to know about. AFAIK that's the only reason to still show and care about permission lists at all.

Not really for modern Android. The ones which are not granted via runtime permissions, special access permissions, non-Restricted battery mode or case-by-case requests do not have a working privacy model in Android. INTERNET is essentially the only one where they could have directly turned it into a toggle, which we do as our Network permission but that pretends the Network is down when enabled (does not run scheduled jobs, APIs report network down or thrown IO exceptions as if there's no interface/route, etc.).

QUERY_ALL_PACKAGES is an example where people wrongly thinks it means something but apps can just declare a / query (even some open source apps did this) or a query for a launcher activity which matches all Play Store apps. They can also detect apps other ways and just can't query their package info. This is an example where users think the absence mean apps can't see which apps are installed, but yet they can, and it's not clear how a / query is any better. There are a bunch of them like this. There are also a bunch where users don't realize there is a toggle or case-by-case request for it. The most common is people not realizing not having the background-related permission requests don't really stop an app running in the background but Restricted battery mode does defer them running until an app starts them (FCM is a common API apps can still get themselves started without any collusion). The way this stuff is presented to users in Android's "All permissions" is wrong but it's at least grouping the runtime permission ones, although not the rest with toggles. The descriptions are also wrong. Then there are the non-OS-defined ones.

F-Droid has access to the APKs and has parsed them to determine this info. It's verifying the APKs after downloading it and installing it. At what point can the APKs possibly change and request permissions F-Droid isn't aware are requested? The OS parsed package metadata having added permissions is a standard thing and it doesn't seem possible to handle that properly beyond not doing that check or at least ignoring permissions outside of a list of all known OS permissions so added ones like POST_NOTIFICATIONS and OTHER_SENSORS are ignored. Permissions can be split too, where one request becomes multiple since apps no longer have to always request them as 1 thing. They did this a bit in early Android releases and can again. This is all a standard thing in the package manager code.

@grote 2 months ago, one of your contributors has linked to harassment content from a Kiwi Farms user which consists of outrageously blatant fabrications and spin:

#2914 (comment 2443518499)

If F-Droid isn't going stop participating in harassment, then perhaps the organizations providing funding to F-Droid are willing to do something about it.

No way bro @thestinger thinks Louis Rossmann is a kiwi farms user

For context:

• Kiwi Farms is a toxic online forum for trolling: https://en.wikipedia.org/wiki/Kiwi_Farms
• Daniel is still unhappy that Louis Rossmann made a video exposing his extreme behavior: https://www.youtube.com/watch?v=4To-F6W1NT0
• Another video Daniel does not want you to see: https://www.youtube.com/watch?v=Dx7CZ-2Bajg

@thestinger Please provide evidence that Louis Rossman is a kiwi farms user, otherwise your "behavior" here will simply be informative, and unfortunate.

@IUseFedoraBTW https://kiwifarms.st/members/larossmann.132201/

By the way, the Kiwifarms thread on Daniel/GrapheneOS, where people repeatedly tell him to kill himself was made by a self-proclaimed fan of Louis, a few days after his video. To my knowledge, Louis has never condemned that, or acknowledged that the thread was created as a direct follow-up to his video.

It's not funny, it's sad.

@IUseFedoraBTW Louis Rossmann is a Kiwi Farms user who posted this video targeting me with harassment following multiple swatting attacks aimed at trying to have me killed. Rossmann was already actively supporting harassment towards me prior to this video being posted, including publicly supporting it on multiple occasions. Rossmann's video is entirely based on fabrications and spin, including the title itself being a lie claiming he stopped using GrapheneOS when he actually continued using it for many months and failed to hide that in his videos. He was well aware of the swatting attacks and that I had referred to other people trying to have me killed, which he had contributed to by supporting harassment. You've also linked more harassment content based on egregiously fabricated stories and spin which was made with collaboration from people involved in Copperhead including people who are active here.

@grote Do you plan on doing anything about F-Droid project and community members engaging in blatant harassment, or is participating in it still official F-Droid policy?