if you record a video with sound, then the FB app has to have permission to record your audio.
I can’t tell if you’re trying to explain how it currently works (which I know very well, thanks) or asserting that the current behavior is necessary in order to record with sound.
It really doesn’t have to be as it is. The OS can provide a record-video API, complete with a user-controlled kill switch and an activity indicator, and the app can call it. The app doesn’t need direct access to the microphone to allow the user to create a file with sound.
Edit to clarify: I’m not saying that the “permission” doesn’t work as advertised. I’m saying that recording an audio file doesn’t have to require a permission system as coarse and disempowering to users as it is today. I guess the people clicking the downvote button misunderstood.
I think this is more a teleological argument he is making and I agree. We’ve become numb to these permission warnings. Oh this app needs access to my camera because I need to take a photo of something once at registration. Why can’t it link to my default trusted photo app and that app can send a one time transfer to it? I hardly question these permissions anymore since many apps need permissions for rare one off functions. The only thing I deny every single time is my contact list.
I don’t give anything mic or camera access on iOS. It’s really not an inconvenience, and anything that demands it is something I don’t want on my phone anyways.
I don’t know what you mean. Existing behavior does not provide the control or visibility that I described.
One important difference is that the “permissions” in the screen shot are effectively all-or-nothing: if you don’t agree to all of them, then you don’t get to install the app. They’re not permissions so much as demands.
(Some OS do have settings that will let you turn them off individually after installation, but this is not universally available, is often buried in an advanced configuration panel, leaves a window of time where they are still allowed, and in some cases have been known to cause apps to crash. Things are improving on this front with new OS versions, but doing so in microscopic steps that move at a glacial pace.)
If your app touches the camera and mic, it will show up on that screen that it does so. “Using the API” (which is just how the OS works) doesn’t prevent it from appearing on that screen, especially when you’re doing so for the purpose of putting video and audio in posts.
All of those things are implemented in modern Android. Well, almost.
Whenever the app wants to use microphone an OS popup asks you if you want to give the app permission to use the feature. The options are “when using app”, “only this time” (it will give the app one-time-use access to the mic) and “never”. If you click the 1st or 3rd options, you wouldn’t see the popup again and you’ll have to change the permission from settings. If you choose the 2nd option, you can manually choose to give permission each time it’s requested.
This is impossible? The OS can either let the app use the mic or not, it can’t tell what the app is doing with the mic. Unless you mean give a one-time permission this time, but not in the future, then we covered that in previous point.
Android always shows a green indicator on screen (upper right corner) when any app is using the microphone or camera API. Well, almost always, some system apps might not trigger it. But if you want to see which app is using mic/camera you can tap the indicator.
All of those things are implemented in modern Android.
No, they are not all implemented on any version of Android that I’ve seen. I don’t know about iOS.
Well, almost.
Right. We don’t need just a few pieces of what I listed. We need them all.
an OS popup asks you if you want to give the app permission to use the feature.
That’s not a bad interface, but it doesn’t address what I wrote: Individual control.
Why should email address, sexual orientation, and home address be lumped all together into a single permission? Lumping installed apps and search history together isn’t much better. Why should a music player, which obviously needs access to music files, be also granted access to biometric data like voice recordings?
This is impossible? The OS can either let the app use the mic or not,
Of course it’s possible. The OS can record the file and then hand it off to the app. No microphone access required.
Android always shows a green indicator on screen (upper right corner) when any app is using the microphone
That alone is better than nothing, but not enough. How is a user to know if something was captured when the screen was off?
These things are indeed improving as new versions come out, but at a glacial pace. Heck, it was ages before Android stopped letting apps spy on each other’s log messages. It’s now at version 15 and still doesn’t have basic controls like restricting network access.
When I said “well almost” I meant the impossible case in the second point. Otherwise, everything is implemented as a I listed. What kind of Android do you use that you haven’t seen these features? This granular permission system has been the standard since Android 11.
In iOS it’s implemented in a very similar manner, but I don’t use it as often to describe it in as much detail as with Android.
The OS can create the file and then hand it off to the app.
That is also implemented, but is a separate API, storage access. You’re free to upload any file you like if the app requests it. You can create the file with any voice recorder of your choosing. Although I can’t imagine a scenario where Facebook would request a voice clip. When it’s requesting the mic it’s usually for live audio, like calls.
How is a user to know if something was captured when the screen was off?
It’s true, if you gave the app permission to use mic whenever the app is running, it can in theory quietly use mic in the background. If you start a call and lock the screen, the call will continue in the background. Not sure if there are any safety measures implemented for that. But if the case was of a routine sneaky mic spying, it will become obvious fast, due to battery drain and network usage.
still don’t have basic controls like restricting network access
There are some network controls, like restricting background data usage (depending on Android version/implementation). But yes, there’s still no granular network permission system, you have to manually go into setting to turn on restrictions. Thought to fair, there isn’t a consumer OS out there that lets you easily restrict network access to a certain app, even on desktop (correct me if I’m wrong). And I can see why, it would be counterproductive for vast majority of users to manually give network access to each app they install, when the whole point if the device is to have apps that have network access.
I appreciate that you’re articulating your thoughts pretty well without resorting to the adversarial nonsense I’ve received elsewhere in this thread, so thanks for that.
It’s still clear that I haven’t been understood, but I’m exhausted from trying. (Again, mostly not from you, so please don’t take it personally.) Time for me to put lemmy away for the day, I think. Take care.
I can’t tell if you’re trying to explain how it currently works (which I know very well, thanks) or asserting that the current behavior is necessary in order to record with sound.
It really doesn’t have to be as it is. The OS can provide a record-video API, complete with a user-controlled kill switch and an activity indicator, and the app can call it. The app doesn’t need direct access to the microphone to allow the user to create a file with sound.
Edit to clarify: I’m not saying that the “permission” doesn’t work as advertised. I’m saying that recording an audio file doesn’t have to require a permission system as coarse and disempowering to users as it is today. I guess the people clicking the downvote button misunderstood.
Pretty sure that qualifies for that permission.
But the whole point of doing so is to use it in the app, and you for sure can’t do that without the permission.
I think this is more a teleological argument he is making and I agree. We’ve become numb to these permission warnings. Oh this app needs access to my camera because I need to take a photo of something once at registration. Why can’t it link to my default trusted photo app and that app can send a one time transfer to it? I hardly question these permissions anymore since many apps need permissions for rare one off functions. The only thing I deny every single time is my contact list.
I will thank you
about a million words from now
I don’t give anything mic or camera access on iOS. It’s really not an inconvenience, and anything that demands it is something I don’t want on my phone anyways.
I don’t know what you mean. Existing behavior does not provide the control or visibility that I described.
One important difference is that the “permissions” in the screen shot are effectively all-or-nothing: if you don’t agree to all of them, then you don’t get to install the app. They’re not permissions so much as demands.
(Some OS do have settings that will let you turn them off individually after installation, but this is not universally available, is often buried in an advanced configuration panel, leaves a window of time where they are still allowed, and in some cases have been known to cause apps to crash. Things are improving on this front with new OS versions, but doing so in microscopic steps that move at a glacial pace.)
If your app touches the camera and mic, it will show up on that screen that it does so. “Using the API” (which is just how the OS works) doesn’t prevent it from appearing on that screen, especially when you’re doing so for the purpose of putting video and audio in posts.
Showing up on that screen is no substitute for what is actually needed:
All of those things are implemented in modern Android. Well, almost.
No, they are not all implemented on any version of Android that I’ve seen. I don’t know about iOS.
Right. We don’t need just a few pieces of what I listed. We need them all.
That’s not a bad interface, but it doesn’t address what I wrote: Individual control.
Why should email address, sexual orientation, and home address be lumped all together into a single permission? Lumping installed apps and search history together isn’t much better. Why should a music player, which obviously needs access to music files, be also granted access to biometric data like voice recordings?
Of course it’s possible. The OS can record the file and then hand it off to the app. No microphone access required.
That alone is better than nothing, but not enough. How is a user to know if something was captured when the screen was off?
These things are indeed improving as new versions come out, but at a glacial pace. Heck, it was ages before Android stopped letting apps spy on each other’s log messages. It’s now at version 15 and still doesn’t have basic controls like restricting network access.
When I said “well almost” I meant the impossible case in the second point. Otherwise, everything is implemented as a I listed. What kind of Android do you use that you haven’t seen these features? This granular permission system has been the standard since Android 11.
In iOS it’s implemented in a very similar manner, but I don’t use it as often to describe it in as much detail as with Android.
That is also implemented, but is a separate API, storage access. You’re free to upload any file you like if the app requests it. You can create the file with any voice recorder of your choosing. Although I can’t imagine a scenario where Facebook would request a voice clip. When it’s requesting the mic it’s usually for live audio, like calls.
It’s true, if you gave the app permission to use mic whenever the app is running, it can in theory quietly use mic in the background. If you start a call and lock the screen, the call will continue in the background. Not sure if there are any safety measures implemented for that. But if the case was of a routine sneaky mic spying, it will become obvious fast, due to battery drain and network usage.
There are some network controls, like restricting background data usage (depending on Android version/implementation). But yes, there’s still no granular network permission system, you have to manually go into setting to turn on restrictions. Thought to fair, there isn’t a consumer OS out there that lets you easily restrict network access to a certain app, even on desktop (correct me if I’m wrong). And I can see why, it would be counterproductive for vast majority of users to manually give network access to each app they install, when the whole point if the device is to have apps that have network access.
I appreciate that you’re articulating your thoughts pretty well without resorting to the adversarial nonsense I’ve received elsewhere in this thread, so thanks for that.
It’s still clear that I haven’t been understood, but I’m exhausted from trying. (Again, mostly not from you, so please don’t take it personally.) Time for me to put lemmy away for the day, I think. Take care.
I downvoted because of the snark in first paragraph.
No snark intended. Do you run into that so often that you’ve come to expect it?
Intention vs. Impact, look it up.
I downvoted because of the snark in first paragraph.
Ooh, I spy more snark!
Yeah watch me not deny it tho; I intended for it to be snarky and anticipated this impact.
That rudely condescending comment lends nothing useful to the discussion, and has just earned my only downvote of the day. Enjoy. Bye.