Yeah, I think it’s just the way the blog post was written. When I was reading it I saw the first few paragraphs was basically “here’s how to do Cron with it”, and then everything after that was “here’s a bunch of other features it has that cron doesn’t and how to use those”
I don’t think that’s the wrong way to write this kind of article, but I could see it feeling overwhelming on a skim, because it may feel like you need to read the whole thing in order to get anything working. But actually only the start was necessary, and the rest was tasty feature pitch.










Yeah, like other people covered, it’s unfortunate but also very important. It’s easy to tie “visible wifi networks” to “surprisingly precise location on globe” in many places, so the permission is named for the worst case scenario. Yes, the app might just be looking for a wifi, but it also could use that same information to locate you, so it’s the location permission. Sensible.
If they wanted to support just this one feature without requiring a location permission, they could maybe have an API that is “are you currently connected to this opaque token” API where the app can ask “am I connected” and is just told “yes” or “no”. That’s probably safe enough. And then I could register the app with my wifi without the app even knowing what my Wifi is, it just gets a unique but random string.
The same is true of bluetooth. If I can list nearby bluetooth, I can see that speaker and this TV and guess location. But there could be an API that hides that, there just isn’t currently