Home

Podfeet Podcasts

Security Bits logo - a green padlock with the words Security Bits to the right and in tiny letters below ithat it says 10101010 indicating a digital lock

Security Bits — 9 November 2025

  • by Bart Busschots

    • Feedback & Followups

    Deep Dive — Apps Asking for Network Access?

    I want to start with some important context for this entire discussion.

    When Apple launched the iPhone, it was initially completely locked down, with no apps at all, and even when it did add 3rd-party apps a year later, those apps were extremely locked down. Apps were trapped in individual sandboxes and could interact with just a few OS services, and there was no way for apps to interact with each other. Over time, Apple expanded the functionality available to apps, but they never released them from their sandbox. Instead, Apple provided proverbial gates to the available features that were protected by one or two locks:

    1. App Entitlements granted by Apple during App Store Review
    2. User permission prompts

    Apple’s original focus was on just app entitlements — if you wrote an app and you wanted to access the user’s contacts, you requested that entitlement in your app store submission, providing a justification for the entitlement. Apple’s reviewers would then judge whether that was a reasonable thing for your app to do. And then grant your app the entitlement if they deem it appropriate. Your app could then just read users’ contacts.

    These simple app entitlements succeeded in stopping egregious abuses, like flashlight apps hoovering up all your contacts and selling them, but they provide no visibility to us users, let alone control!

    Entitlements have not gone away; they are still a big part of an app submission, but a lot of entitlements no longer grant apps direct permissions, but instead grant permission to ask the user for access via an ever-growing collection of standard OS prompts.

    Flashlight apps that ask for the contacts entitlement still get stopped before even going live on the app store via the entitlements process, but even apps that do get the contacts don’t actually get that access until the user approves it.

    Over time, Apple has been delegating more and more control to users, even adding fine-grained options like granting access to just some photos or to different levels of precision for location access.

    Meanwhile, the Mac app started off with completely unsandboxed apps, basically free to do whatever they wished. When Apple added the Mac App Store, they also added optional app sandboxing to the Mac using the same entitlements model pioneered on the iPhone. Over time, app sandboxing went from optional to suggested to all but mandatory, and the number of entitlements switching from direct access to permission to ask for access grew to align ever more closely with iOS/iPad OS. Today, Mac apps have more entitlements available to them, but every app that just runs (without the user needing to open the settings app to add an exception) is sandboxed, and the Mac now shares many of the same permission prompts users see on their iPhones and iPads.

    The LAN Permission

    As of iOS/iPadOS 14, the entitlement apps need to access devices on your local network (LAN) has joined the ever-growing lists of indirect entitlements, i.e., permission to ask for permission rather than direct permission.

    Here’s an example from Apple’s iOS support article about these prompts:

    A screenshot showing the iOs prompt which clearly names the app requesting the permission and shows a description of why the permission is needed below the title
    iOS Permissions Request with App Name and Why

    Apple added the same prompt to the Mac in macOS Sequoia, though the support article is much sparser. I can only assume it works the same way (as is the norm these days).

    This request causes confusion, especially from people who are technically savvy but not developers or networking specialists. In other words, it confuses many NosillaCastaways! My theory is that when you understand enough about how the internet works to realise that every app connecting to the internet must be making use of your LAN to get to and from the internet, you assume that means the apps must have access to the LAN anyway. But that’s a false assumption.

    Developers familiar with the networking APIs provided to apps by OSes, and network engineers familiar with how TCP/IP network connections work under the hood, are not confused because they understand the difference between endpoints and transit points when it comes to network connections. Every network connection has two endpoints, but passes through arbitrarily many transit points. Network connections transiting through the LAN can’t access devices on the LAN because the packets are like people on a train between stations — they move across rails they can’t see and have no control over where they go or how they get there!

    When apps ask an OS to establish a network connection for them, they have to provide the desired remote endpoint (the local device is the other endpoint), and the OS is free to apply some rules before returning a connection object or an error object. That means Apple can provide two entirely different entitlements for internet connections and LAN connections, which is exactly what they do.

    These prompts are asking for more than just permission to connect to a specific endpoint on the LAN; they are asking for permission to scan the LAN for possible endpoints to connect to! This is vital from a usability perspective, because without the ability to probe the network and discover devices, users would need to provide local private IP addresses to connect to devices, and that’s utterly impractical — they change all the time thanks to DHCP, and what regular person would even know where to begin to find those addresses‽

    How Do We Answer?

    OK, so now we know what the prompts are and what they mean. How should we answer?

    As with every prompt, that depends … — if there was a clear universal answer, there would be no prompt! Apple are asking because for some people in some situations, some apps should be given permission, and for other people in other situations, permission should be denied.

    Not very helpful, but it’s important to understand that you are being asked to make a judgment, and there is no universally correct answer; you actually need to stop and think. Sorry!

    We are being asked to trade off risks in exchange for functionality, so that’s the right structure for the remainder of this discussion.

    Why Might I Want to Allow Access?

    Firstly, Apple allows apps requesting this permission to describe why they need it in the smaller text on the permission prompt. The most important questions are always “does that even make sense?”, followed by “do I actually want the functionality described?”. If you can’t answer “yes” to the first, and at least “maybe” to the second, just say no!

    As Apple describes in their support document, rejecting the permission is no big deal:

    If you don’t want to allow access, or if it’s not clear to you why the app needs access, you can tap Don’t Allow. The app can still use the internet or interact with the local network using a system service, such as AirPrint, AirPlay, AirDrop or HomeKit.

    Notice that Apple’s own LAN services are explicitly excluded, and that gives us a clue as to why we might want to grant this permission — third-party alternatives to those services do need this permission to discover and connect to other devices on your LAN!

    This is by no means an exhaustive list, but here are some legitimate uses for this permission:

    • 3rd-party AirPlay alternatives like:
      • Google’s Chromecast
      • Samsung’s Smart View
      • Networked speakers that don’t use AirPlay as their communication protocol
      • Console game streaming protocols like Xbox Console Streaming or PlayStation Remote Play
    • Accessing content on home media servers like Plex or Emby
    • Accessing IoT (Internet of Things) devices that connect to your LAN but don’t communicate over the HomeKit or Matter protocols.
    • Accessing printers using protocols other than AirPrint
    • Accessing files shared on the LAN from PCs or NAS devices
    • Games with multi-player features that can work over the LAN
    • Apps with support for remote control via hardware devices or companion apps like hardware clickers or smartphone companion apps for PowerPoint.

    I think Chromecast explains a lot of these requests, certainly on iOS, because streaming to smart TVs other than the AppleTV is definitely something a lot of apps like to support these days.

    What are the Risks?

    We have many reasons we may want to grant access. Why might we push back?

    In a word — privacy!

    The devices you choose to connect to your home network say a lot about you, so they can really help advertising companies expand their profiles of you. They could see you have HP printers, Dell laptops, Samsung TVs, a home weather station, a 3D printer, a smart fridge from Electrolux, and so on and so forth.

    The Bottom Line

    Don’t stress too much about this one. If you deny access, most apps will work fine, with the obvious exception of apps whose sole purpose is to be companions to LAN devices, of course. You can also change your mind at any time in the security and privacy section of the relevant settings app for your OS.

    The risks are small, so I don’t think you should lose too much sleep over these requests. If you trust the developer, it seems reasonable to trust their apps 🙂

    Personally, when I’m not sure if the functionality will or will not be useful to me, I tend to just grant that access, especially if the app itself has earned my trust in some way (long-time user/customer, reputable developer, recommended by someone I trust …).

    ❗ Action Alerts

    Worthy Warnings

    Notable News

    Palate Cleansers

    • From Bart:
      • 🇬🇧 The nation that famously voted to name a state-of-the-art arctic exploration vessel Boaty McBoatface redeems itself — naming the nation’s newest leaf-clearing train (leaves on train lines cause major delays when they’re not cleared before being crushed to a banana-peel-like mush) ctrl Alt Deleaf — www.networkrailmediacentre.co.uk/…
      • 🎧 The BBC’s excellent Lazarus Heist Podcast is back, in a new form:
      • A special episode on North Korea’s biggest cybercrime success: The Lazarus Heist Special: The biggest heist yet — overcast.fm/…
      • The podcast is back for a third series with a new name and a new focus — from North Korean state-sponsored hackers, to Russia’s biggest cybercrime group: Cyber Hack Podcast — www.bbc.co.uk/…

    Legend

    When the textual description of a link is part of the link, it is the title of the page being linked to, when the text describing a link is not part of the link, it is a description written by Bart.

    Emoji Meaning
    🎧 A link to audio content, probably a podcast.
    ❗ A call to action.
    flag The story is particularly relevant to people living in a specific country, or, the organisation the story is about is affiliated with the government of a specific country.
    📊 A link to graphical content, probably a chart, graph, or diagram.
    🧯 A story that has been over-hyped in the media, or, “no need to light your hair on fire” 🙂
    💵 A link to an article behind a paywall.
    📌 A pinned story, i.e. one to keep an eye on that’s likely to develop into something significant in the future.
    🎩 A tip of the hat to thank a member of the community for bringing the story to our attention.
    🎦 A link to video content.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Scroll to top