Hacker News Reader

Comment by atourgates | Hacker News Reader

I'm an Alaska (relatively) frequent flyer. That airline offers a free "messaging" plan, that lets you send and receive messages on apps like iMessage, Facebook Messenger and Whatsapp. Though, it somehow prevents images/attachments from coming through on those platforms.

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.

View on HN

Hi fellow Alaska frequent flier.

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.

> There's this iOS app called Flightly

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.

Ha! I've used a high-end GPS to see my location and other fun facts in flight. I learned to keep it in my pocket as despite my attempts to explain it was only a receiver, I was told by the flight attendant to "PUT IT AWAY." Not being one to push back as to be removed for that flight, I did just that.

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.

FAs can be really strange about that kind of stuff, not just out of ignorance.

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

There has been a lot of debate in the aviation maintenance community regarding the legality of attaching gopros etc. to aircraft with suction cups. Someone eventually wrote to the FAA chief counsel and asked.

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

> installation of external mounts

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

I would guess that the flight attendant is doing their job. They do not have the authority or expertise to risk the airplane based on their own analysis, or based on some random passenger's explanation. The clearly correct solution is to remove the device and then there is no risk to the plane. I expect they are strictly required to respond that way and have no leeway.

Had this happen to me with some duct tape and a malfunctioning strobing light next to me on a red-eye. I'm an aircraft builder but she didn't want to hear my explanation about how TSOs and the FARs work. I just waited until they stopped paying attention.

Probably just didn't want kid spit on the window.

I used to do that also.

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

I still sneak in an HT to listen to VHF/UHF ham radio and airband. One flight, we were experiencing moderate turbulence and didn't get our drinks/snacks. The captain announced "we're asking for clearance to help us get to a smoother altitude..." meanwhile did nothing of the sort on the actual radio. Lol.

They use text for communication, too.

This reminds me of the old tools that tunnel more or less whatever over DNS. I.e. behind the scenes, the tool would look up "base64encodedpacket.domainyoucontrol.example.com", and it would respond with encoded data going the other way. This is because captive portal WiFi often permitted DNS to pass through unimpeded, for various reasons.

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.

Also Internet over ICMP, for when captive portals used to let those through.

I’ve always wondered why I get slack and email notifications when I’m on a Southwest flight with free messaging without paying for wifi. You’ve finally solved my mystery!

Push notifications have background notifications that are used to update apps while they aren't loaded. We used them update our catalog/home screen on shopping app, its makes the app feel much more responsive when they open the app and content instantly appears instead of waiting for some API calls.

https://developer.apple.com/documentation/usernotifications/...

I had an idea to use Facebook messanger as a proxy. Specifically to use the cheap messaging plan on a cruise ship for real internet access. My home computer would be a gateway that monitors fb and fetches/returns websites. I never even tried because it just sounds like a violation of multiple ToSes. Not to mention message size limitations, throttling, my fb messages being pages of encoded text, etc.

I feel like it would need to work like Opera mini to maybe be usable. Even then interactions would be uncomfortably slow.

https://en.m.wikipedia.org/wiki/Opera_Mini

Check out https://github.com/aleixrodriala/wa-tunnel tunnel over whatsapp

Really hoping someone implements this, it’s the funniest project idea I’ve seen in a while :)

This reminds me of a web browser years ago that would use MMS to transfer web pages to the user without using internet service. This was in the early days. I think it was a Java app for the Motorola razor IIRC

It works not because Alaska wants to give you notifications for your messages, but because iMessage literally is transported over APNS.

Does that work on Android? I've never seen a non-authorized notification in a Chat or Mail app on a flight.

so why would I use this Flightly app? seems it delivers messages all the same?

I used to work at WhatsApp (until the end of 2019) on many things, including special pricing (aka zero rating); we did not work with airlines, and would not have participated in a project where messages and attachments where treated differently.

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.

> WA chat is not HTTPS (or even TLS)

If you don’t mind, could you expend on this? Are there specific reasons to not be using TLS?

We didn't use TLS at Netflix either, and instead used our own encryption protocol that ran on top of HTTP. We could do this because we controlled the clients too.

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.

Yeah, at WA we didn't have too much of a problem with trust store issues; although we did do extensive testing when we switched CAs. We did have to deal with the end of SHA1 certs though, I think we were able to get all of our clients to use sha2, but some of the platform browsers couldn't; and then we had to fiddle with our TLS server to send sha2 certs to some clients and sha1 certs to others.

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.

Our solution for the same problem was to just have different subdomains for each cert signer (and make sure we ship the right base URL for each manufacturer's app), so we didn't need to do any clever device-sniffing at the SSL termination point. I think rolling our own encryption sounds much scarier, but equally we weren't running at Netflix scale.

This discussion is another great example of why HTTP without TLS can be just fine, even desirable.

> Every device has its own built in trust store, and especially on devices like TVs and DVD players, they couldn't be updated.

Was creating your own certificate authority and pinning it in the app not an option?

Bringing your own trust store to system https libraries is not often supported. Especially when you get into kinds of embedded environments Netflix supports. You also might not have the capability to bring your own TLS library either. If it's a limited environment, you might only get reasonable performance if you use the system ciphers, and they may not be exposed as primitives, and x.509 parsing takes up a lot of code space in the likely event that you've got limitations there too.

In most environments you have to use the built in libraries for network connectivity, so you have to use their trust stores. Also space is very limited for the client, so you can't just put everything into it.

I should probably refer you to the encryption whitepaper [1], but the basics are that Chat uses the Noise Protocol rather than TLS. All things being equal, the security properties are about equivalent, however all things aren't equal. The Noise handshake is smaller than the TLS handshake, and Noise doesn't have extraneous features WhatsApp doesn't use. Additionally, at the time of Noise adoption, TLS lacked a means for 0-RTT data (now available with TLS 1.3 Early Data), which meant using TLS would have added at least one round trip; possibly two, depending on which TLS library used. [2] You can use TLS without x.509, but it's not very common; avoiding x.509 was a definite plus.

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.

Thanks for the answer, I didn’t expect that much details!

It's based on the Noise Protocol Framework in the outermost layer, which encrypts a compressed XMPP stream. The end-to-end encryption is done within various XMPP message payloads using the Signal Protocol, which encrypts message data serialized using Protocol Buffers, with different formats depending on the message type (text, image, video, sticker, etc).

I've also wondered why Grindr but not Tinder works on the "messaging only" plan. Someone at Alaska must have had fun with that one.

Flightaware.com also works, presumably because Alaska uses Flightaware for its tracking map.

Grindr is a logistics app, Tinder is entertainment :p

> Flightaware.com also works

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've been wondering the same.

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)

Probably 10-15 years ago when wifi on airlines was still pretty brand new I remember a fun hack for free Internet that involved Google Translate.

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.

I'll probably show my age, but around 15 years ago I was in high school and they blocked most websites as well. This "hack" using Google Translate was how some of us got around the blocklist for many things. It was nice because it didn't involve having to install anything special or try to change configurations that were probably monitored by library/school admin.

You could probably have used googels cache to read arbitrary pages as well.

This hack often works today to get around paywalls.

You could try iodine, which is an IP-over-DNS tunnel. This should work unless the gateway has very restrictive rules on where DNS traffic can go.

https://github.com/yarrick/iodine

Most captive portals have gotten wise to this trick and block large DNS requests.

Yeah I recently found this out. It never really did work that well, I did manage to telnet into an SMTP server and manually send an email but for anything else it struggled.

I wonder if TCP over ICMP would work better.

How does that fly (pun intended) with regards to net neutrality?

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.

When the rules were still active, net neutrality did not apply to coffee shops, airlines, etc.

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

In the US (I believe) Net Neutrality basically died. Even before that, it was allowed to zero-rate categories of apps (like messaging). That might be coming back now that the FCC has 5 commissioners again and can reinstate Net Neutrality.

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.

This is the situation where net neutrality falls over because there's very often more demand, even at 1.5Mbps for a stream, than an airplane's link can provide.

On an airplane in particular, you can set the limit lower for everything, and that doesn't violate neutrality.

So many people seem to think that Net Neutrality disallowed _any_ kind of network management, when it simply disallowed service provider level preference. You can, under net neutrality, throttle _all_ video content, if you want to, you just can't only throttle YouTube and not Netflix (for example.

Airlines, coffee shops and similar entities providing Internet as an ancillary service were not subject to these rules when they were in effect.

The rules primarily target ISPs selling directly to customers.

It also fails for mobile data and large crowds. Try checking your email at a concert.

I always enable my 5G when I get into big crowds and it usually fixes that problem, assuming service is available.

I usually keep it off otherwise though because average bandwidth tends to be better on LTE in my experience.

Other people have suggested it's done by limiting the size of the data transmitted to make the connection only useful to text messages, possibly resetting the connection regularly. If so, it would in fact comply with both the principles of net neutrality and any laws I know of. You could create matsemann's text service as long as it also used small amounts of data it guessed could only be used for text.

Is net neutrality even law anymore? T-Mobile has had Binge on for a long time, which zero-rates certain video streaming services. And part of that was even under the old net neutrality laws.

Binge On doesn't fall under strict net neutrality, but they are at least publicly open to all lawful and licensed content audio/video providers, and the technical requirements are not very high. I don't know what the actual onboarding process is like, but they've got a lot of providers signed up...

https://www.t-mobile.com/tv-streaming/binge-on/apps-list.htm... doesn't list all that many providers if we're talking about all video streaming services worldwide. I notice a large one under the gaming category missing, Twitch.

I think they've got to be licensed for US customers, or T-Mobile USA isn't going to include them. Twitch does seem to be a notable missing provider; Amazon video is on the program though, so maybe there's some technical or product thing on Twitch's side.

Even US-only. Broadcast networks category is especially slim. They've anticipated this kind of scrutiny and claim no money is exchanged, but idk. Someone should try adding a random obscure service.

No, but the now Democratic majority at the FCC is currently actively trying to bring it back.

Net neutrality is the law in California, but T-Mobile says Binge On is ok because any video streaming service can participate for free. It sounds reasonable to me and apparently the California regulators are fine with it.

I'm fine with it, but that also clearly violates net neutrality, so it doesn't seem to be the law here.

Here's the California law: https://en.wikipedia.org/wiki/California_Internet_Consumer_P.... T-Mobile Binge On is zero-rating. T-Mobile's claim is that they aren't getting paid for it, and that any video provider can participate, so they aren't only zero-rating "some content in a category". It sounds like that second part isn't true, so they are probably violating the law but nobody is being harmed so nobody has sued.

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.

Some states implemented their own versions of net neutrality.

Gotta disable in-flight messaging while flying over certain states ;)

I'd suspect it kills TCP connections once a threshold of data has been transferred, and the threshold is enough to let text through but not enough for attachments.

Good luck doing that against Telegram. It would simply reconnect and resume the download where it left off.

So so surprised that nobody has found out the hack for free wifi on alaska flights. (At risk of losing awesome free wifi)

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.

United wifi is similar. I've found that notifications work for most things, including my Home Assistant instance—they must all use the same Apple push service.

I noticed the same on Alaska flying last weekend.

As soon as I activated the "Free Messaging" service, I got a bunch of notifications from my Apple Home and Google Nest devices.

Yes, APNs (Apple Push Notification service) has to be allowed for notifications to come through from messaging apps and the network operator can’t tell whether it’s an allowed messaging app or any other kind of notification.

The scale of Apple’s notification service must be pretty large. Granted, most notifications don’t have strong SLA guarantees but I don’t remember it having any downtime either.

They don't really make guarantees about the reliability of push notifications (IIRC), so it's unlikely you'd see anything about downtime unless it was sustained for some time.

On iOS all notifications have to use Apple's Push service.

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.

>On iOS all notifications have to use Apple's Push service.

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?

Well, apps can only "run in the background" for up to 10 minutes.

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.

Yea but those mean the app has to be running. The main advantage of Apple's Push is that the app can be put to sleep and only wake up when you tap a notification.

https://news.ycombinator.com/item?id=33568994

some options:

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

Many years ago, when hotels first started having and charging for WiFi connections, I wrote a simple little tunnel using the DNS port back to my server. Since the hotels didn't block that port or even bother to check what traffic was going over it, it worked like a charm.

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.

Reminds me of using VPNs in hotels in China some years ago. Traffic would work for a few minutes and then the Great Firewall kicks in, fingerprints the traffic as VPN and the IP address and the MAC gets blocked. I'd rotate the endpoint and the MAC address and get a few more minutes, rinse and repeat.

I think I had to use Shadowsocks or something at the end to completely bypass it.

Shadowsocks(-libev) is great. I use it in the USA with Comcast to prevent their MITM attacks on HTTP connections.

Could always send base64 data strings!

I've come across wifi zones which allow normal web browsing, WhatsApp messaging (including pictures), but not WhatsApp calls. I saw it first in Hollyhead Port while waiting for a ferry. WhatsApp threw up an error message saying that calls were disallowed by the wifi network.

Time to implement IP over FB Messenger

Absolutely. And I'll just put this here for anyone who's looking for inspiration:

https://www.rfc-editor.org/rfc/rfc2549

I always assumed they have a whitelist of iMessage/Whatsapp/whatever IP addresses. It doesn't seem to work for all messaging apps in general.

I don’t think they have any sophisticated solution for sniffing traffic. It’s most likely simple firewall + deals with Apple/Meta. Many airlines offer basic Wi-Fi for messages nowadays, so it’s very likely that big tech developed solution for it (especially, as they have initiative to do that, so their apps can work).

I can't seem to find it, but there was a blog post on HN a while back about how someone set up a proxy to browse Wikipedia by sending and receiving WhatsApp messages. I'm sure you could extend that to be a web proxy.

Hussein Nasser covered this. His videos are great.

How Airline WIFI allows Texting but not Media in WhatsApp/iMessage

https://www.youtube.com/watch?v=AYSxxO2yZp8

On my recent United flight, where they had the same policy I was sending image messages to friends through Signal. But it was rather slow, so my best guess is rate limiting.

IP-over-Facebook. So that's what the world has come to ...

Google Voice always works for me too FYI.

Do they allow Telegram?

If so, that would be the easiest, Telegram has a really good bot API.

Many do but some don't. I wrote an HTTP Proxy for Telegram and it works fine for those situations but is very slow. I prefer using an NNCP proxy I wrote because the protocol doesn't have online liveness requirements.

SNI or IP lists.

Reply on news.ycombinator.com