So about that! There's this iOS app called Flightly that does a brilliant little hack where the app updates itself in (almost) real time on the "free messaging" plan. The way it works (according to a friend) is that their servers send your phone a push notification every couple of minutes from take-off until landing, containing some serialized info such as lat,long,alt,eta,etc. And then the app immediately swallows the notification and deserializes its content without you ever seeing it. The notification works because in order for Alaska to give you notifications at all for your messaging apps, it needs to give you access to _all_ push notifications as they all get sent over an encrypted connected through Apple's server and it can't pick and choose which apps' notifications it lets through.
I've often wondered if it'd be possible to pipe any sort of internet over notifications but I'm not sure if e.g. inline responses are viable, and also that'd probably be heavy enough usage of push notifications I'm sure it's violate someone's TOS.
This strikes me as HN’s own unique style of toxic positivity.
They’re using push notifications. That’s not amazing engineering work. It’s literally a built-in, supported, documented feature:
“Pushing background updates to your App — Deliver notifications that wake your app and update it in the background.”
https://developer.apple.com/documentation/usernotifications/...
The payload supports custom keys that may contain arbitrary application data.
It’s also the trivial, obvious approach to anyone who asks the question “how can I push data to the application when it’s not running.”
It’s also the trivial, obvious approach to anyone who asks the question “how can I push data to the application when it’s not running.”
No other app has updated its app state based on the content of notifications. Slack/Discord/Teams et al (the ones that aren't allowed on free messaging plans) will show you previously cached messages and then an infinite spinner when you open it. Fastmail/Gmail/Outlook et al will show you existing emails but not load the new ones.
Could other apps do this? Surely. Do they? No.
All it requires is reading the two pages of documentation for this supported feature:
“Pushing background updates to your App — Deliver notifications that wake your app and update it in the background.”
https://developer.apple.com/documentation/usernotifications/...
> No one is asking for a survey of apps that do this. You’re making the claim that it’s far from rare, so you have enough knowledge to make this claim. Share with us the smallest piece of your knowledge by naming one single other app that does this. It’s the least you can do since you’re making the claim. Please, I’m very curious!
I can’t share that information.
It’s a trivial, documented, supported, long-standing API for a common use-case.
It is widely used, as documented, for its intended purpose.
Do you genuinely believe it’s uncommon for applications to leverage this useful, trivial, long-standing platform API for its intended and explicitly documented purpose?
I can’t imagine why you’d believe that, but another commenter already provided the requested single example up-thread.
> I cannot share information about specific applications.
So you don't have an example of an app using such a basic and widespread feature? Ok.
You’re the one with an extraordinary claim here — that applications aren’t using such a basic, documented, widespread feature.
It’s patently silly and I have no idea why you’re so self-assured in your ignorance.
Background notifications can and do carry arbitrary application data, and are used to update the application state in the background.
This is their intended purpose, it’s what they’re documented to do, it’s how Apple intends them to be used, and it’s common application behavior.
This is literally a plainly documented feature of the platform. It’s not clever or unique or unusual — it’s a simple feature that Apple specifically documents.
I cannot even begin to fathom why people are confused about this, and it’s truly mind-boggling that this has required a thread at all.
Slack/Discord/Teams are non-native applications that do not leverage the platform’s support for updating application state via notifications. That does not mean the use of background notifications is unusual or rare. It is not.
Push notifications aren’t some odd “alternative pipe” and conveying data via push notifications is a known and supported use-case.
Your lack of amazement is duly noted, I suggest you don’t waste any more time on it.
That said, I, like others, are indeed impressed for a couple of reasons.
For starters because of the simple fact that they’ve found a novel way to use background notifications to provide users without unrestricted internet access with flight updates.
Contrary to what you imply, and subsequently fail to substantiate, there aren’t many, if any, other apps that use background notifications in such a novel way, certainly not in a way to circumvent restrictions and limitations on data connections.
Moreover, I have never seen background notifications being used to push concrete data to apps. This is because there are severe payload size constraints on notifications, including background notifications.
Typically when background notifications have been used, it simply contains an instruction to download data from a remote server, something that wouldn’t work on a limited connection.
Instead, Flighty uses the minimal payload size to push the actual concrete data used by the app.
Additionally there are some limitations in how often a background notification gets delivered to the tune of a few times per hour, worse yet, delivery of these notification is inconsistent because it’s beyond the app’s control of they get delivered at all.
To account for this, Flighty will use the background notifications to update the data where it can and make estimations in times it cannot not until the next time it can receive an update.
I’d go as far as call that amazing engineering.
You might not and I don’t know your qualms with Flighty, but you’re doing a poor job of convincing people to see it your way.
I have nothing against Flighty, but background notifications are trivial and all apps can and should be using them to solve this type of problem — it’s detrimental to have folks mistakenly operating under the belief that this is complex or unusual.
Sure, the payload size is limited, but it’s not impossibly small, and custom keys with arbitrary payload are explicitly and obviously documented as supported.
Do you work on Flighty? I truly cannot understand where on earth this level of effusiveness for using a simple API — as documented and designed — is coming from. It’s inane.
This nonsense has to stop. Copying a movie, or using the internet on someone else's plan is not piracy is not theft.
Quoting from memory from my old Webster's dictionary which I have owned since I was a student a long time ago:
Theft: The act of taking property and removing it so that the rightful owner is no longer in possession of it.
Piracy: the practice of attacking and robbing ships at sea.
Equating copyright infringement or violation of terms of service with theft or piracy is completely unwarranted messing with definitions of terms that have served their purpose for centuries.
Worse yet, the abuse of these terms in recent times misdirects people's attention away from the underlying flaws: artificial scarcity and the inability to enforce restrictions on use; you can not steal data (unless you steal the physical medium the data is stored on) nor can you pirate a service.
Making unauthorized copies or violating the terms of use of a service may be deemed objectionable but these actions are most certainly neither theft nor piracy.
Just take any adhesive label off of the "clearance" meat at the supermarket, and apply it to the cut you wanted to buy. Instant savings!
There's a significant contextual, moral and ethical difference between "exploring a lock" and "opening it and stealing whatever it's holding from you".
Also, you're another one who apparently needs to read the domain name of this site aloud to yourself again.
How much will you pay me to delete it? I can send you an Ethereum address.
Yeah, you can argue internet isn't a necessity. Neither is the bathroom, you can use a poo bag and a diaper. But we're a civilized society. So we provide bathrooms to anyone that needs them. And internet access.
No food and no water. Most recent data point: April 2023, Standard Economy (not Basic Economy). International, 4.5 hours flight (Germany to Tenerife) (and back). The flight had a LH code, although operated by Eurowings which according to Wikipedia is a wholly owned subsidiary of LH (https://en.wikipedia.org/wiki/Eurowings).
Was quite shocked.
There are budget airlines outside the US that are charging for water (which I think is unethical IMO, since people avoiding drinking water could lead to an increase in medical emergencies).
Look at the domain name of the site you're posting on and read it out loud. FFS dude. LOL
I feel like it would need to work like Opera mini to maybe be usable. Even then interactions would be uncomfortably slow.
I always appreciated the hack, even though I could never bring myself to use it due to the obvious cache pollution problem on the various DNS servers.
I guess it's Flighty (https://apps.apple.com/us/app/flighty-live-flight-tracker/id...)
I love that people are into this. In the days before iPhones, I had "Microsoft Streets and Trips" + a USB GPS unit + Laptop. It was fun having it on a flight and seeing movement data in realtime. It was less fun answering questions from people who thought looking at the GPS data was somehow nefarious.
Streets and Trips was fun on a laptop for long car drives as you could live reroute in the car much like any old app can do these days but seemed somehow magical back then.
My kid liked to suction cup his GoPro to the window to take a time lapse movie of the flight and one FA told him he had to take it off the window because he was, and I quote: "modifying the structure of the aircraft and that's not FAA-approved".
"Another consideration, in the case of this type of equipment, is the applicability of the term "alteration". FAA Order 8110.3 7E, defines an alteration as "a modification of an aircraft from one sound state to another sound state". The use of suction cups, or other temporary methods of attachment (not including permanent mechanical attachments to the aircraft), would not be considered a modification to the aircraft."
https://mypilotpro.com/wp-content/uploads/2020/05/FAA-Camera...
But still, the aircraft is the the airline's property, not yours. If they tell you not do something to it, you don't get a choice in the matter.
That memo is about attaching it externally. Attaching it to an internal window is probably a non-issue.
I once had a security agent ask me to prove a GoPro was a camera because they didn't understand how there could be no screen or viewfinder. It was most frustrating because this was an area where they would have encountered it many times (lots of scuba divers).
Way before cellphones, I'd bring my 2m radio on the plane and make contacts on simplex. That was fun to throw your callsign out and say "aeronautical mobile".
https://developer.apple.com/documentation/usernotifications/...
That said, technically there's two pretty easy ways to do it for WhatsApp traffic, and then there's the way I suspect they're doing it...
a) chat runs on different ips than attachments; always has, most likely always will (other than some transitional HAProxy at the old hosting when nearly everything had been moved to the new hosting).
b) WA chat is not HTTPS (or even TLS) and attachments are. Chat also cycles between different ports, so you could just block port 443 and be good.
c) I actually suspect, based on poking around a little that it's mostly just killing connections that use a lot of data. Maybe in combination with some other things. Being on a plane doesn't really put me in a debug the network kind of mood, so I never got to the bottom of it, but I'd regularly be able to make short connections to my home network while on the messaging plan, at least when this stuff was new. OTOH, I think I recall being able to connect through the WA VPN while on a plane on the messaging plan, but that was when we had a publicly available, but not publicly linked list of IP addresses on our website; I have no doubt that DPI vendors had that list.
If you don’t mind, could you expend on this? Are there specific reasons to not be using TLS?
I wasn't much involved in anything on the chat channel, and I didn't do any implementation work on Noise, but I did some later prototype work with it, and if I recall correctly, it had much simpler framing than TLS as well; although maybe that was mostly TLS options getting me down --- the SNI header has 9 bytes of overhead, 5 of which are lengths, Noise didn't have anything like that as I recall. Do you really two bytes of versioning on every application data packet, like TLS has? I'm not sure you really need a type indicator byte either, context says you're sending a handshake packet initially, and then application data after that, but I'm pretty rusty on this now, so maybe there's a justification.
For users paying for internet by the byte, every byte counts. For users on networks with large delays, every round trip counts. For attachments, it's less critical (if your data access costs were high, you could configure attachments not to load) and that infrastructure was always built around http(s), so while there would have been an efficiency improvement to move that off https, it would be hard to justify the engineering time; especially post the move to FB infrastructure with its CDN that was easily configured for our attachments. OTOH, chat never ran on TLS, so adopting Noise vs adopting TLS was a choice we could consider, and we picked the best solution for us. Unfortunately, it's pretty easy to identify Noise vs TLS --- OTOH, the service IPs are already identifiable, so a little more blending on the protocol level wouldn't help much.
[1] https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...
[2] Also using system TLS libraries is fraught with peril. It's fine, but not super great, for http, but using it for a custom binary protocol is going to be terrible. You'll need to debug all of the edge cases that the system https library doesn't hit, and will then have to craft workarounds that just work, even if you can't reliably identify the underlying versions because Android OEMs do weird stuff.
The why was because of trust store issues. Every device has its own built in trust store, and especially on devices like TVs and DVD players, they couldn't be updated. After looking at all the devices we supported, there was no common certificate signer amongst all of them.
This meant that we would either have to get multiple SSL certs signed by different parties (some of which weren't all that secure) and present the right one depending on your device type, or we could just roll our own over HTTP. So we chose the latter.
Of course, there's not really very useful client identification in the TLS Hello, so you have to kind of guess who needs what. If we had to use different CAs for different clients, it would have gotten a lot harder, because it's not like we could rely on clients filling out SNI either. So then you need to get more ips for each service. I do recall needing to do that a little, but we only needed a single 'legacy' group that was useful for everything that couldn't manage the modern certs.
Was creating your own certificate authority and pinning it in the app not an option?
Flightaware.com also works, presumably because Alaska uses Flightaware for its tracking map.
Unfortunately, I couldn't get it to load on my Alaskan flight a few days ago on the free messaging plan. Maybe they've changed it
I wonder if TCP over ICMP would work better.
I wonder if they just do some rudimentary packet inspection and drop packets above a certain size. My thinking being that short text messages result in very small packets, while large images will result in many large packets. Dropping large packets is most likely OK. I'd need to test this hypothesis by sending a very large text message (resulting in many large packets)
I tried it on a trip to Tokyo and immediately got completely blocked. It took me a few minutes to figure out they'd blacklisted my MAC address. I changed the MAC of that interface and then behaved.
I think I had to use Shadowsocks or something at the end to completely bypass it.
Where I live, some mobile operators gave you "unlimited streaming" in their data plan, but only for certain popular services (spotify, youtube, netflix basically). Since this would make it harder for others to disrupt the big ones, it was quickly forbidden.
However, even with reasonably strict neutrality, this is still possible. Many mobile carriers zero-rated streaming services here, but unlike your operators they'd do it for any streaming service. It was pretty easy for any streaming provider to sign up. They'd basically give the operator the IP ranges they'd be streaming from and the operator would just zero-rate data to those IP ranges (and they'd usually apply bandwidth throttling to around 1.5Mbps so that you'd only get 480-720p video). The key is simply not discriminating between providers within a category.
The rules primarily target ISPs selling directly to customers.
I usually keep it off otherwise though because average bandwidth tends to be better on LTE in my experience.
> 52. Finally, we decline to apply our rules directly to coffee shops, bookstores, airlines, and other entities when they acquire Internet service from a broadband provider to enable their patrons to access the Internet from their establishments (we refer to these entities as “premise operators”). These services are typically offered by the premise operator as an ancillary benefit to patrons ... Although broadband providers that offer such services are subject to open Internet rules, we note that addressing traffic unwanted by a premise operator is a legitimate network management purpose. [0]
It seems like a reasonable distinction: if you're letting someone else use your Internet connection, it's your prerogative to block things that you don't want on your network.
- [0] https://docs.fcc.gov/public/attachments/FCC-10-201A1.pdf (page 31)
I agree that allowing any form of zero-rating is not full net neutrality because it isn't treating all packets the same, but I don't think it's fair to say that therefore there is no net neutrality in California. It's a very strong and effective law and gets like 95% of the way to full "dumb pipe" net neutrality.
- attachments are likely stored in a different part of the infra than raw messages (like on some s3 bucket somewhere), so it's pretty easy to allow the WA/iMessage/Signal/Messenger API while blocking their CDN through dns blocking, ip range blocking, sni inspection, etc.
- they cut the tcp connection once more than e.g. 1MB has been transferred. it would result in slightly degraded user experience (the message tcp stream needs to be periodically reopened), and may not be foolproof is apps are smart and resume the download where it failed instead of from the start
I lean for the first option as it's both the simplest and most foolproof option.
Because the wifi landing pages used Google Analytics, they allowed traffic through from many of the Google domains. You could then go to Google translate and translate the website from English to English and use it as sort of a proxy server to get free Internet.
As soon as I activated the "Free Messaging" service, I got a bunch of notifications from my Apple Home and Google Nest devices.
And the WiFi essentially has to allow the Apple push notification system entirely in order for iMessage to work fully the way people expect.
So it's really a side effect. But yeah for example with the free iMessage connection on Southwest, I can see all the notifications come in on Discord, but of course I cannot connect within the discord app to actually load all those messages. I can only read them as they come in as push notifications.
Have to? Isn't there an option to send 'offline' notification? I mean, coming from the app itself, rather then external callback? With that, app could ommit the official way of using Apple Push service, no?
So sure, an app can generate a notification popup itself, but it's pretty limited as it won't be able to generate a notification after being backgrounded for more than 10 minutes.
And the 10 minutes is also only if the app is designed to extend the duration as long as possible. Normally it would get cut off after 1 minute.
So because of this it seems that in the vast, vast majority of cases apps choose to send their notifications from the Apple Push notification service.
If so, that would be the easiest, Telegram has a really good bot API.
How Airline WIFI allows Texting but not Media in WhatsApp/iMessage
1. Open browser with iOS user agent and ios sized h/w. 2. Click on t-mobile free wifi link 3. Enter _any_ t mobile number you may know.
I've always wondered how this is implemented technically, and if it might be possible to setup some kind of protocol/wrapper to send data that looks like it's being sent over those protocols, but offers access to other parts of the internet.