• mox@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    2 months ago

    Pretty sure that qualifies for that permission.

    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.)

    • conciselyverbose@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      22
      ·
      2 months ago

      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.

      • mox@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        7
        ·
        edit-2
        2 months ago

        If your app touches the camera and mic, it will show up on that screen that it does so.

        Showing up on that screen is no substitute for what is actually needed:

        • Individual control (an easy and obvious way to allow or deny each thing separately)
        • Minimal access (a way to create a sound file without giving Facebook access to an open mic)
        • Visibility (a clear indication by the OS when Facebook is capturing or has captured data)