[NickHoff]

Some of the permissions this app requires:

    read your contacts
    modify your contacts
    access approximate location only in the foreground
    send and view SMS messages
    receive text messages (SMS)
    receive text messages (MMS)
    read your text messages (SMS or MMS)
    take pictures and videos

[crabbone]

I would expect, probably, even more. The permission model of Android is worthless, if you actually want to use it as your desktop replacement. I.e. if you want to own it rather then rent it (and be told by the manufacturer / reseller what you may or may not do).

For example, I use Termux app on my Android (which gives me access to the terminal version of Emacs, without the GTK stuff). In order for the terminal to be practically useful, it needs very broad permissions. The permissions you listed come as a side effect of the bad underlying permissions model. It's not like Emacs is going to send SMS, it's just because that service in Android will get exposed if you need something more general, like access to the file system that isn't restricted to the directory where you program is installed.

[Ajedi32]

This is... pretty much entirely false. You don't need SMS permissions to get access to the filesystem. Also, SMS access (like most sensitive permissions in modern Android) is disabled by default when you install the app, so GP's list is just a list of permissions Emacs can theoretically request, not permissions it actually has on install. (Not sure what functionality Emacs has that requires SMS access, but I'm guessing there is some optional feature that lets you send texts or something.)

Generally these days when Android apps request permissions they don't need it's because they're either old or poorly written; not because Android doesn't have more granular APIs available. For example, applications requesting full file system access when all they need is the ability to read and write to a user-selected file (which requires absolutely zero permissions now thanks to the documents provider API) is a personal pet peeve of mine. Ditto for services that ask for permission to run continuously in the background when they could just use WorkManager or similar, or IOT apps that ask for location permissions when they could be using the Nearby Connections API.

[charcircuit]

>The permission model of Android is worthless, if you actually want to use it as your desktop replacement. I.e. if you want to own it rather then rent it (and be told by the manufacturer / reseller what you may or may not do).

You make no sense. The permission model is what makes these operating systems so secure. It's not worthless as it significantly hurts the capabilities of malware. If your definition of owning a device is that you should be able to install an app that can steal all of your login information to every other app you have then you are alone with that definition. People don't want to have to care about security when installing random apps.

[LoganDark]

> If your definition of owning a device is that you should be able to install an app that can steal all of your login information to every other app you have then you are alone with that definition.

(not GP) This is false, I should be able to install an app that can steal all of my login information to every other app I have. I want the freedom to do stupid things with my device but also the freedom to avoid doing stupid things with my device. It's why you're informed of such permissions and allowed to accept them rather than just being prevented from installing any app that wants them.

Note that I love sandboxing and safe/isolated APIs, it's just that, more often than not, OSes literally can't include any escape hatches or else, no matter how complex they are, normal people will get tricked into activating them.

[crabbone]

Oh, but there are plenty of things on Android that you simply cannot do. They aren't expressed as permissions at all. And there's a lot of things that you can do, but that will void your warranty, or will make the process so painful and complicated that you will regret even thinking about it.

They created a permission system with a powerless users in mind. Their model user is the one who doesn't want to own the device, it's the useful idiot who rents the device and swipes on ads. This user needs to be showed ads by "partners" and because it's too financially taxing to approve "partners" individually, there's a system with some heuristics in place that makes sure that the diligent ads consumer doesn't rebel or doesn't get side-tracked by "partners" breaching provider's trust.

I describe their model user as "idiot" because it's an idiom in the language. I don't mean the user is generally stupid, rather that the user is not knowledgeable and not wanting to gain any knowledge in a very convenient (for the provider) way. Someone who may be duped into doing things against their own best interest.

But, yes, if you don't want to match that profile, you will be offended by that kind of attitude from the provider.

---

And, more on the reasons why Android's permission system sucks: it's, again, built at the wrong level. This is very often the case with software: it's usually much easier to build things at higher level, but that also gives worse results. It built this way to make the development on the part of the provider cheaper. It covers the needs of their model user, the one which potentially generates the most profits for them. They have never meant or wanted to make a system that's most useful for any potential users. It just needs to be barely useful to turn profits.

[charcircuit]

I think you are failing to understand 2 things.

1. Users will be tricked into giving permissions to apps. There isn't a reason why apps should be able to while in the background before you've even opened them be constantly listening to your mic and then uploading the audio and your location 24/7. That's simply something that Google has chosen to not be something apps should be able to do. And that's okay. It keeps 100% of the users secured against these malicious app.

2. The users are not the only stakeholders. The app developers are too. It's Google's job to make a platform that takes in the needs of both the app developers and the users to create the platform that gives users the most value possible. This is where things like DRM come in. One could say that you are taking power away from the user my creating secure layers that can't be recorded or screenshoted, but on the other hand you are giving content owners more assurance that your platform is safe for them to distribute their content on. This is a compromise between the needs of the user and the needs of the app developer. It's about giving the users the most value possible instead of the most control possible. This is the main reason why Android is the most popular consumer oriented Linux distro. Desktop Linux distros prioritize giving users control over security and user value and it turns out that is not the way to get mass market appeal os it remains niche.

[LoganDark]

> Oh, but there are plenty of things on Android that you simply cannot do. They aren't expressed as permissions at all.

Yeah, see what I said about escape hatches above.

> But, yes, if you don't want to match that profile, you will be offended by that kind of attitude from the provider.

> It covers the needs of their model user, the one which potentially generates the most profits for them. They have never meant or wanted to make a system that's most useful for any potential users. It just needs to be barely useful to turn profits.

Agreed~

[crabbone]

You know what operating system is the most secure? The one that's turned off...

Yeah, maybe you can spin Android as being more secure (than what?) But it's also useless. It's like with the rifle, if it's always in "safe" it's very secure... but useless as a rifle as you cannot fire it.

[hulitu]

> The permission model is what makes these operating systems so secure

My definition of security is that programs have access on a need to know basis. Especially to my files. On Android is all or nothing.

[charcircuit]

That's not true. Android apps start by only having access to an app specific directory. In order for it to gain access a file or directory outside of that it needs to be selected by the user explicitly. There are also directories like the download directory which apps can't read from. For more information look up "Scoped Storage"

[warkdarrior]

One can write a perfectly good text editor without requiring contacts or location permission.

[crabbone]

Very few Emacs users need a "perfectly good text editor". This is not why anyone uses Emacs.

For me, personally, Emacs is a terminal emulator, interface to Git, MUA, file manager, organizer and planner, a gateway for configuring various aspects of the system I'm using... I even use it to run alsamixer, because it's easier for me to control sound volume this way.

Oh, and an interface to govmomi / aws-cli / az with a bunch of custom code written around those tools. Openstack pending.

And any Emacs user you ask will have a bunch of other uses... Some other things I've done / or played around in the past include: Wiki server, cooperative editing (with Rudel, probably dysfunctional by now), binary files editing (well, I still do every now and then), Web browsing, IRC (and Jabber way, way back)...

[dotancohen]

And none of those use cases require contacts or location permission.

You could argue that a general-purpose planner might, but that's not what Emacs is, nor do I believe that it supports parsing contacts in the format provided by the Android APIs.

[Wildgoose]

Some people use emacs as an email client - that is probably why it may require permission to access Contacts.

[crabbone]

Again, read the top post: it's not the Emacs' problem. It's the problem of how permissions are structured. Talk to your overlords at Google and tell them that their permissions system is bad. It's them who are guilty of making a bad permissions system, not the useful software that has to deal with the fallout of their bad design.

[blep_]

I am the one emacs user who uses it as a text editor and nothing else.

[hulitu]

You know what they say: Emacs is a nice operating system, but a lousy text editor :)

[cykros]

Emacs, though, is a great operating system, which just sadly doesn't ship with a decent text editor. Don't worry though, you can install the eVil plugin, and get what is essentially Vim running inside of it.

[jraph]

> perfectly good text editor

This is a very restricted description of Emacs though.

Emacs happens to provide a text editor ;-)

[beepbooptheory]

For me, really finally understanding this point about Emacs was nothing short of enlightenment.

[juxtapose]

You don't give permissions to an arbitrary Android app because you don't trust it, whereas GNU Emacs can be fully trusted, (unless you run untrusted Emacs Lisp code, ofc). I even tend to think it requires too few permissions, e.g. it cannot initiate phone calls.

If you don't trust the F-droid build, you can always build it from the sources.

[david_allison]

In Android, it's not possible to request a permission unless it's defined in the manifest, and a large number of permissions are granted without a permissions dialog.

This leads to a situation where app developers must unconditionally obtain permissions, even if they're only used on a certain code path.

[codery]

None of the above permissions are asked by the app, go to settings > apps > emacs > permissions, by default app hasn't requested a single permission!!

All the permissions are set to FALSE. They are there, if any package you install needs that permission, it will be asked to allow such.