Can I revoke app permissions?

General
#1

It seems when I install an app the permissions are all or nothing for the native apps. For Android I still get pop ups.

I use App Opps to put apps on a leash in Android, but not sure it will work in SFOS. I installed it and Shizuku, the partner app it needs. For a non rooted Android it says to plug into a computer and type " adb shell sh/storage/emulated/0/Android/data/moe.shizuku.priveleged.api/start.sh" which I am guessing is NOT the correct command or path with SFOS. Haven’t tried it yet.

Is there a way to selectively revoke app permissions for native apps? I searched around and did not find anything that answered my question.

Xperia 10iii, version 4.4.0.72

1 Like
#2

Crap, i’m sure this had been asked before, and i answered.
But i too cannot find it.

But basically:
A) Why would you want to? Sailfish apps are well-behaved.
B) It is a PITA to develop around and would work really poorly sometimes (think app crashing).

Edit: aha, it was where the author took the thread off-topic and i followed even if i probably shouldn’t have

So if anyone wonders why it is important to stay on topic, this is a prime example. And i should feel bad.

#3

@attah I am sure it was asked before as well. LOL, but it is only my 1st week with SFOS.

a) location mainly, even though it is toggled off unless I am using a map. Plus it seems apps are requesting permissions they shouldn’t need( nope, can’t name one, just seems like it ). It seems that a privacy OS would make it highly customizable. When I starting using app opps I was surprised by the permissions apps were using but not asking for.

b) fair enough! I am “just a user” as it was put on a JingPad Forum ( I can just see him looking down his nose as he typed it :rofl: ).

Thank you for the link. Interesting read. Sounds as if I may just be worrying about an Android issue that isn’t really an issue w SFOS.

So far I absolutely love SFOS. I actually left the android phone at home today for the 1st time.

#4

I think you cant
you can uninstall the app

if an.app.requests something during install you can not refuse it, just cancel

the apps that require all right, were not yet migrated to request only what they need.

my 5 cents

#5

Location off is location off, so why mess with revocation?

Beyond those few stragglers that declare none and get the full basic set, i’d be very curious if there were any.

Spoiler alert: Sailfish OS not a “privacy OS”, it is just a sane OS that does only what you want and stays out of your way.
(This is opinion obviously, Jolla marketing may see it differently)
I still find it somewhat funny (and sad) that not doing sketchy stuff somehow becomes a feature.
It used to be called common decency, not “privacy focus”.

So indeed, i’d say this is an issue does not apply to Sailfish OS.

1 Like
#6

Thanks for all the input. I won’t worry about it and will enjoy using the OS.

#7

Because sooner of later, they won’t be, either by active malice, or simply inadvertently. A lot of Android apps are malware not because the authors wrote it, but simply because they are including common frameworks that invade privacy. I can’t see why the same won’t happen to SFOS.

I was surprised that under setting->apps you can’t change the permissions. Seems very odd, unless it is still on the to-do list for Jolla.
I was looking because my own app defaults to permissions for everything.

3 Likes
#8

For the 9 years so far that has not been an issue, so i’m not so sure.

I’m not so sure such things will ever exist here (so far they don’t).
But assuming they may, i’d argue that at least if the author adds in permissions for that crap they are complicit and should be treated accordingly.

It is not at all odd to me that it is not done yet, because it probably can’t be done well.
To be sane it would have to work like Android where they are requested at first use of the respective permissions. I’m not so sure FireJail can change permissions at runtime, and i can’t imagine any way to implicitly ask for a permission. So especially then, and in the light of that it shouldn’t be needed, we are better off not having it.

I still maintain that we are much much better off calling out and shunning any ill-behaved apps than inventing coping mechanisms. I might me selfish, but i definitely want the whole community upset with such apps (should they ever appear!), and absence of a coping mechanism certainly would help with that.

Then go declare some!

3 Likes
#9

Which has a lot to do with the monetary gains to be made in the Google play / advertising cosmos. We don’t have that :slight_smile:

Otherwise, adding more granular controls to apps via preference could certainly be done, but that involves risks to the functioning of apps until all developers are on board. It means developers, in this case mostly volunteers who don’t earn anything with apps having to do extra work if ‘location’ is not available because a user has trust issues.

For my part, my apps and those I maintain are all open and can easily be audited. That’s my gold standard. I’ll trust apps, generally, where I have access to the source. I don’t necessarily trust Google’s mechanisms because they are based on centralized mechanisms in a behemoth of such dimensions it’s certain to have issues. Even if, in principle, Apple and Google exert a disciplining influence, you have to put your faith in closed shops and closed practices.

2 Likes
#10

The best - or at least the most thought out - mobile operating system I have ever used was BlackBerry 10. That including its permission mechanism. Permissions could be selectively granted upon installation or first use, then selectively revoked, then selectively granted again, at any time. And it worked really well.

1 Like
#11

As a Canadian, you do temp me to make obvious cheap observations about the superiority of Canadian culture :wink:

2 Likes