Hacker News new | past | comments | ask | show | jobs | submit login

Reading through the linked docs, this API seems to specifically be for apps created by owners of WiFi hotspots to help users connect to those hotspots (https://developer.apple.com/documentation/networkextension/h...).

> NEHotspotHelper allows your app to participate in the process of authenticating with hotspot networks, that is, Wi-Fi networks where the user must interact with the network to gain access to the wider Internet.

> NEHotspotHelper is only useful for hotspot integration. There are both technical and business restrictions that prevent it from being used for other tasks, such as accessory integration or Wi-Fi based location. Before using NEHotspotHelper, you must first be granted a special entitlement (com.apple.developer.networking.HotspotHelper) by Apple.

Which makes sense, but then why exactly are apps like WeChat and Alipay granted this entitlement?




I don't know about Alipay, but afaict WeChat needs this feature for WeChat Wifi, which lets users connect to internet hotspots from their WeChat accounts https://mp.weixin.qq.com/s?__biz=MzI1NjA0NzQzOQ==&mid=265026...


I’m sure that’s valid but I’ve worked for mobile app companies and can guarantee features like this are added just to get the entitlement.


Ah now I see - to get all the entitlements they create a super-app that happens to use those things.

Then they can spy on us for our main use case


Seems like Apple should give users the ability to download an app while rejecting an entitlement.


You can. iOS apps have to request individual permissions - I'm not sure about the specific level of granularity here, but you can deny location access while still letting the rest of the app run, and the app has to be able to deal with it.


No, you can reject permissions, but not entitlements.

Entitlements are granted (statically, per developer certificate or maybe app ID, not sure) by Apple, permissions are (optionally) granted by users at runtime.

The only way to not have an app making use of an API gated by (only) an entitlement is to never install it.

Of course there could be permissions that are gated behind entitlements, but in this case it seems to be only an entitlement.


And even then, an app can block usage until you allow a permission; ie Snapchat doesn’t need the camera permission to allow you to chat but will block usage of the app until you enable it.


Snapchat has allowed you to chat without camera permission for years on Android. It's still required on iOS?


As I understand it, this SSID feature does not require location services permissions.


It's not a new idea but I would love to see Apple implement a way to serve eg. a fake, empty contact list for an app that refuses to enable a feature unless you allow contact list permissions.


I at least partially blame Apple for this too.

I personally use several different terminal/Unix emulator/SSH client apps on iOS that request the "background location" permission solely because there is no actual "background execution" API.


That's a design decision. Apple doesn't trust developers in general not to abuse this background API. They expect lots of aid requesting it, unknowledgeable users granting it without thinking much, and iPhones getting a crappy reputation for battery performance as a result.

I dislike this decision (taking a choice away from the user) but from a business point of view it makes sense.


The complexities and capabilities in the Chinese(well, most asia) mobile market are remarkable.

I always find it funny when people boast about how great certain things are in the US without ever have traveled to HK, Singapore, Tokyo, Beijing etc...

Most people dont realize just how entangled mobile life is in Asia, way more than in the US.


Centralized superapps seem incredibly dangerous to privacy, given that the limited mobile privacy models are designed around per-app permissions.

   1. Create app that does 1 thing
   2. Add more features to app
   3. Abuse superset of permissions
   4. Gov leans on app owner
   5. Gov abuses superset of permissions


No, I more than 100% agree, I am just staing that most people just dont realize just how deeply entangled the mobile is to Asian life. I wasn't praising it, I am horrified, but also in awe by it.


I'm pretty sure most people are very aware that most of east Asia never saw massive PC adoption and so their internet developed in a very mobile-centric way. This hasn't been surprising for a long time?


I'm not sure I agree.

I mean, back when the west had WAP there were articles saying NTT DoCoMo had much more advanced phone technology, sure.

But in terms of making it into the cultural consciousness - you don't see ubiquitous asia-specific mobile super-apps in cultural exports like 'Squid Game' or 'Spy X Family' (admittedly a lot of cultural exports aren't set in the present day)


I think if you're in China the centralized superapp is the least of your worries, privacy-wise. I agree that this is probably part of why these things will never really take off in the US though (no matter what Elon wants to wish for).


It is not the least of your worries, it is the abusive system working as intended. It is policy of the Chinese state to ingratiate itself into every aspect of its citizens' lives to exert control.

The fact the State is wholly evil in other ways does not lessen the worry; it multiplies it.


Is that inherently greater than not being connected or using super apps? Also, I didn't know Tokyo or japan in general were also into the "big app" concept. Japan in general didn't seem that "connected" relatively speaking back in 2017-18 but maybe stuff has changed in the past couple of years.


I think I'm missing some context: ex. there's O(many) apps that offer hotspot connections in the US as well. And my understanding is there's a privacy concern, which I think would be exacerbated by a super-app like WeChat adding this.

What's the great certain things of all that?


Even if only genuine hotspot apps got the entitlement, it is not a user-friendly privacy-first design. Such API use should trigger a user-visible permission dialog before apps get background-notified and user should be able to select the one of "allow-once, allow while using, allow-in-background, never" and the app activity should show up in app privacy reports.


Not sure I agree - in fact pretty sure I don’t. Having lots of permission dialogs just trains users to mindlessly click yes on everything, because they just want to do the thing, not think about how the sausage is made.


So just don't have them, and don't let them think about it?


I'm saying that a default of "ask every single time" is not good. For anyone.


Because the Chinese market is too important. For wechat you can maybe argue that it's a "super app" and probably also can be used to connect to wifi hotspots, but for alipay I fail to come up with an explanation..


Alipay is also pretty much an everything app (it also has its own ecosystem of mini-apps built on Alipay's platform). Except for the social aspect, it's nearly interchangeable with WeChat.


Ah I see. It's been a while thanks to the pandemic that I've been there, and even then preferred just doing wechat so I dont have to deal with even more stuff. At least for regular payment almost all places accepted both options.


You can buy hotspot access with Alipay (scan QR code -> connect), presumably thats why.


The sensible move would really be to break up these "everything" apps. Sure WeChat may have a wifi service, but if it is being used by 0.01% of the user base then why is everyone else forced to approve the permissions? Creating a separate "WeChat Wifi Connector" takes zero extra effort on their part.


You don't have to break up the app, just require user opt in to enable the feature for the app.


>API seems to specifically be for apps created by owners of WiFi hotspots to help users connect to those hotspots.

VPN apps also seem to use it: https://github.com/pia-foss/mobile-ios/blob/4618b55161ec5b8b...


Apparently the entitlement is not required in a few other conditions, listed here [1] by Apple:

    1. application is using CoreLocation API and has user's authorization to access precise location. [This seems harmless – the app already gets the precise location anyway here.]

    2. application has used NEHotspotConfiguration API to configure the current Wi-Fi network. [This seems to be the scope of the article!]

    3. application has active VPN configurations installed. [This one is quite surprising to me!]

    4. application has active NEDNSSettingsManager configuration installed. [No idea what this is exactly, but it seems similar to the VPN one.]
[1] https://developer.apple.com/forums/thread/679038


Its a more basic question to me, why do these apps need a special entitlement? Couldn't they ask users for permissions like any other app, presumably with a good reason to go along with it since location is needed for some features?


Apple wants to gatekeep the feature for "legitimate" uses. If it was just another permission, random flashlight apps (as the joke goes) would ask for the permission and _n_% of people would just blindly accept it. Then, of course, Apple would get blamed for allowing random flashlight apps to track people's location. Of course this could all be done via the regular app review process, but Apple seems to have decided on a few permissions they want to keep super locked down (CarPlay is another, to avoid blame for when someone crashes while using some CarPlay app).


These "super apps" get special treatment everywhere.

Many phone manufacturers even automatically grant certain permissions when these apps are installed (the list is sometimes hard-coded into the system), since there are people who do not understand what is "permission", and they blame the phone manufacturer for not being able to use WeChat/Alipay.


This is functionally a Location Services feature, so the user should grant location permissions to use this.

I am not sure how it works in practice.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: