When my son was younger - maybe 9 or 10 or so, we were on a plane and he was using his phone and I looked over his shoulder and realized he was on the internet... but I hadn't paid for an internet plan. I said, "son, how are you using the internet?" He said, "oh, a kid at school showed me - if you go here" (he opened up the wifi settings where the DHCP assigned IP address is) "and start changing the numbers, eventually the internet will work." Apparently, at the time, on American Airlines, when somebody bought and paid for an internet plan, it gave them an IP address and authorized it to use the internet... if somebody else guessed your IP address (which was pretty easy, it was a 192.168 address) and spoofed it, they could take over your internet connection with no further authorization.
I had to tell him not to do that, but I was kind of proud of him for having the temerity to go for it.
lol, I used to do this all the time at non-free wifi hotspot locations, only I'd start off with a ping sweep of the entire subnet (nmap -sP) in order to get my ARP cache filled with a bunch of potential usable IP/mac addresses on the network. From there, I'd iterate through each one and set the IP & mac address until I found one that would let me through the firewall.
Granted, being a NOC engineer at Wayport (now AT&T WiFi) certainly helped me understand how it all works.
Yes the key to doing this more seamlessly is to spoof both the IP and the MAC so your machines are not constantly fighting with the other person over the ARP table entry.
Its wifi. You both just pick up the same frame when it is broadcast, then it sees two stations (a level below IP) with the same MAC. Most routers just don't care about that. (it's technically a valid edge case that two stations have the same mac address. It should be vanishingly rare in the wild ... but this is a practical example of why it isn't).
I once bought a cheap Bluetooth dongle from China. Its MAC address was 11:11:11:11:11:11
Obviously there are now a lot of bluetooth dongles in the wild with the same MAC address.
If STP[1] is enabled, but that is unlikely since you'd have dropped connections when roaming for the reasons you just gave. Most likely, STP is not enabled on these networks.
A switched port learns the Mac address for packets sent into it. If port 1 sends a packet with Mac a, the switch associates that address (a) to port 1. When another node sends a packet onto another port with the same mac, say on port 2, the switch will move the learned address a to port 2 and remove it from port 1.
When a switch has learned a mac address all traffic destined to that traffic would be immediately switched to that port. If the switch has no record for that specific mac address it floods all ports except the ingress port. This is expensive and means other devices receive traffic that isn't intended for them so they waste time dropping it.
So in networks that have no protections against those attacks then this could very well be a problem if there are multiple access points and the two nodes are on different access points.
Except that this is a normal thing on wireless networks. A station may roam many times within a few minutes, and due to reflections, may even be in more than one place at a time.
> As a general rule, reset (RST) is sent whenever a segment arrives that apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case. There are three groups of states:
> 1. If the connection does not exist (CLOSED), then a reset is sent in response to any incoming segment except another reset. A SYN segment that does not match an existing connection is rejected by this means.
It's possible for a node to be configured not to do this, but this is the default behavior.
"everything works fine" might be overstating a bit, but what happens to packets you weren't expecting when you don't have a connection open for them to go into? They probably get ignored by the network stack.
Worst case scenario, the router/service endpoint sees your connection responses and the other party's strange NACK responses, but I honestly don't know enough about how it works to say "everything works fine"
I'd guess that connectionless protocols will work fine and connected protocols will also work fine. The truth is probably YMMV by protocol, but there is truly no way for the wifi router to detect this is happening or isolate the redundant stations - it's an unencrypted broadcast. The only way this goes sideways is if a connection protocol is engineered to make it go sideways when you try to do that.
I'm pretty sure that any such protocol which succumbs to any unencrypted (or incorrectly keyed) traffic that isn't from the designated counterparty is insecure to begin with. It should be resilient against DoS, so most protocols aren't going to have that vulnerability. Again, I'm guessing, but I'd hope.
I imagine this can only possibly work with unencrypted WiFi.
Still boggles my mind that WiFi clients don't establish an encryption key with the AP and encrypted their traffic even without a shared secret. Yes, that means you can't authenticate the AP, but it would still protect against passive snooping.
Time to consider instead: walk through the plane, look angrily at the other passengers, one at a time, asking: "Do you use 192.168.x.y?". That can solve the problem
If any lawyers or FAA employees are reading this I’m genuinely interested in what, if any, legal implications there would be for running nmap mid flight on an airline. Surely once you have spoofed the MAC address and IP of another passenger to gain unauthorized access to the planes LAN you have committed a crime but what about passively scanning?
I used to do this on airplanes and in hotels. I had more success in hotels, because there was less chance the other person was using it at the time and less chance of getting kicked off.
There was another little hack that I used as a little kid. Remember when airlines would sell or rent special headphones to watch inflight movies? The port was just two holes beside each other and the plug was two tubes. Before a flight, I would stop by one of the fast food places in the terminal and grab a handful of straws (preferably ones with a bendy joint). When I was on the plane I would connect the straws by fitting them into each other to create a long straw. Put one end into the port on and the other into your ear and you got free movies with audio!
Interesting that I have only flown once since 9/11. Almost all of my flying took place in the three decades prior, so the pneumatic headsets are the only ones I remember.
A few years ago I was on a Southwest flight and had OpenVPN running because I forgot to turn it off. I was able to access the Internet through my tunnel without paying for access. I guess at the time they were only port blocking common ports (80, 443, 53 etc) if you didn't pay. They have since closed that hole.
For this same reason you used to be able to send messages via platforms like whatsapp without internet as well! I don't remember the airline I just remember I hadn't paid for internet but I could message and do a few other things but I couldn't browse the internet.
That was probably deliberate. I flew United recently and they advertised free wifi for certain messaging apps, or you could pay to access more apps or the general internet.
I also flew united recently and, in addition to the free messaging access, they also provided free access to the inflight entertainment, in case you wanted to watch it on your device instead of on the screen.
I would have loved to take advantage of this since my wireless earbuds were significantly better than the wired pair I had. Unfortunately, a little pop-up warned me that this was not available on Android 13 devices. I was more than a little annoyed, but also curious as to why this might have been the case.
Here's my hack for United's free messaging. Works on iOS, and makes the flight more useful than before, but not as good as paid internet.
Messaging and Notifications basically follow the same protocol. Even though I usually have notifications disabled, I go and activate it for anything I care about - News, Weather, Slack, Whatsapp (yes I have that silenced). Every single message pops up as a notification. Could be bank alert, Ring alert, homekit alert, whatever ... it just shows. So you can keep tab on things you care about, and if you are really needed, well you can pay and get on the full Wifi. And anyways you can iMessage to communicate if needed.
I had a mosh connection open before I got on my last United flight and was able to use it the whole time. Seemed to me the free messaging/inflight entertainment tier doesn't block arbitrary UDP packets at all.
I flew United recently, and I was able to use the free messaging service for basically everything without any intervention from my part. It's just a tad slow. Not sure if it was intended or not.
There was a report in the early to mid-2000s where someone got iChat AV to work, partly because it was fairly obscure and likely the network engineers didn’t consider blocking it.
KLM and United for sure have free in-flight messaging (at least as of a few days ago, the last time I used them).
It's interesting what does and doesn't go through. e.g. Facebook notifications update, but not the content. I guess that's because they use the same channel as FB Messenger.
The state of "open Wi-Fi" security is actually really sad. I'm not aware of an easy way for the airline to actually do better than this!
I suppose they could use Opportunistic Wireless Encryption [1] and bind session authentication to that (i.e. authenticate a given OWE session, not a given MAC address) if the device supports it, as at least modern Apple devices do? But I have no idea how stable an OWE session is; it would be very inconvenient to have to login again every time my device switches between access points.
In any case, I'm sad that this isn't a solved problem yet, and paid Wi-Fi (as well as securing free Wi-Fi) still requires custom and clunky solutions like unreliable captive portals that need to pass through selective traffic (e.g. for 3DS, for payments, sometimes emails for password reset codes etc and more).
A standardized endpoint and API would also be nice, i.e. something to tell the client whether it's connected, restricted (i.e. able to only access a limited set of hosts such as the in-flight map as described in the article), or needs to pay/authenticate (and if so, at which URL). This could then yield an authentication token, to be provided for seamless reconnections for the same session.
There's "Hotspot 2.0" and WPA-EAP (i.e. WPA Enterprise), but these don't really have a good story for "pay via web portal" style usages and are more geared towards wireless carrier operated hotspot networks and corporate scenarios, respectively.
In cases where the Wi-Fi is provided as a value-add or is bought via another channel than the Wi-Fi network itself, I think you can just generate one-time WPA Enterprise credentials, with a QR code to facilitate data entry?
In case of in-flight Wi-Fi, the credentials/QR code can be printed on the boarding pass, or available in the app (the app caches it in advance while it's still on the ground, so when in the air you can use those credentials to connect).
This doesn't cover 100% of use-cases but it would at least cover a big one (a significant amount of public Wi-Fi is "value add" to another service - whether restaurants, hotels, flights, etc where there's an existing channel to provide one-off wi-Fi credentials over), it's a shame nobody deploys this.
I think you could even take this one step further: Have a captive portal on an unencrypted channel (using TLS obviously) to do the vending, so that the credentials don’t need to be purchased before the flight.
Oh, these are neat ideas, I hadn’t thought of that!
One concern might be expiring access credentials (not sure if most OSes will re-prompt for a new password or just give up), but you could just make the EAP credentials per-user instead and redirect users to the captive portal again once needed.
This leaves clients not supporting WPA-EAP, but these could just continue using the regular unencrypted/MAC-authenticated service.
That’s what Passpoint (aka Hotspot2)’s Online Sign Up is supposed to do. Main network is protected by WPA2/3-Enterprise (aka EAP), and there’s the OSU open network where you can get signed up and get a profile installed for the full main network. And every modern device supports EAP these days.
Well, the customer also needs to futz around with scanning a WR code, and get it from the device she scanned it on to the device she wants to use the wifi on (if they ain't the same.)
Though you could route around these problems, but giving them both a scannable code, and underneath some credentials as plain text they could type.
What if the captive portal just had a link (or on an IFE screen, a QR code) that connected your phone to a different, WPA2/WPA3 protected, hidden WiFi SSID that was generated exclusively for you? Phones nowadays support joining a passphrase protected WiFi AP via a QR code, so I'd imagine that's doable. The hard part would be finding routers that support >300 different hidden SSIDs, but honestly I would hope that that is technically feasible nowadays.
That way you'd at least have the protection of the WPA GTK.
You can have an AP accepting multiple different WPA2-PSK and/or WPA3-SAE passphrases, and since on WPA2 PMK depends on the password, and on WPA3 PMK is different for each client, you can put them in different VLANs or have per PMK MAC mapping if they share the same VLAN.
This. And even if the >300 is not available, how many people actually buy Wi-Fi on the plane? That is the number of clients that need to be supported. And if that's still a problem (or you don't want to guess), the SSID can be hidden and static and the only thing non-static is the password that works for just the duration of the flight you are on.
You can always use an open network to generate passwords for the proper internet connected WPA-EAP network (along with some in-flight multimedia like some carriers do). Extra step for sure but it solves the problem.
PS: I'm a couch expert so I have no idea if there's a problem with this idea.
The first problem that comes to my mind--clients will remember both wifi networks and may continue to choose the open network when e.g. waking from sleep.
The user can go in and forget the open network of course, but most won't know to do that.
QR code to connect to the _open_ but _hidden_ SSID. Instructs user to join WPA-EAP with supplied credentials once they've paid. Remains available to connect via QR in case customer somehow misplaced creds but avoids auto-reconnect during scan.
Isn’t this data meant to be exposed? You can get all this flight status on the Southwest intranet when you’re connected to WiFi as part of the flight status page.
This hack just goes a step further to plot the data over time.
The concern isn’t access to the flight status data (or even your data, which is most likely encrypted these days), but theft of service you paid for, by another passenger on the flight (you would probably at least get kicked out/experience issues with your own connectivity, and might worst-case be blamed if something bad happens using the connection you bought).
I used to play with IP-over-DNS, which more or less worked on an awful lot of these plane wifi systems. Haven't tried it in the past couple years though; it's always slow the point of barely being usable. You can probably get your mail via IMAP if you're patient and nobody's sending you large attachments, that's about it.
There used to be an app that would scan the ip and mac addresses on the network that were already connected to the internet. You could then change your settings to one of the mac addresses and when they were done you'd get the connection to yourself.
I used to travel a lot for work and just refused to pay for WiFi. This was good in airports and coffeeshops when you still had to pay to connect.
Now it's hardly needed, but I could see how it would be helpful where there's still a cost to connect.
It’s not an app, per se, but a concept of setting your WiFi card into monitor mode and listening to the radio traffic. Kismet is one of the suites that does that.
True. I just can't recall the name of the platform I used, but it was something similar to an ip address scanner which gave me a list of all devices already connected to the network along with their mac addresses.
Love stuff like this, it's how kids get into computers. I used to make minecraft servers for my friends and I to play on when I was 12, which lead to a software engineering career. Sounds like you've got something similar on your hands
A slightly more ethical solution, for those wondering, is SSH tunneling. A lot of gated wifi networks allow SSH traffic through without payment.
I used to spend a lot of time at JFK back when they still charged for WiFi. I watched a lot of Netflix for free by just logging into my router and opening a tunnel to my VPN server.
The rule is probably something like "if !paid: deny tcp 80, deny tcp 443". (Hopefully they got UDP for HTTP/3.) I suppose this has the desired effect of captive portals (break GMail until you pay), without having to field support requests from geeks ("I paid but SSH doesn't work, refund me"). I think their plan is that whatever obscure app you're using negotiates over HTTPS, but then actually transfers the data over some other port. I bet things like Zoom work that way. By not touching the obscure data paths, you avoid support requests.
Either that, or they just felt like throwing a fellow nerd a bone. If you ask the PM, "should I block SSH" they'll say yes, but if you just put it in there, who knows ;)
Whoever set that up probably wanted it for their own use, both for easily managing the system when they need to work on it, and for themselves when they're travelling anywhere.
If I'm ever in charge of rigging up a captive portal system like this, I'm certainly going to do something similar if I can get away with it. Maybe even put a hint on how to bypass in the portal's page source. "ssh works on port 46969, don't tell anyone." > rot13 > base64 -> "cache-burst-ID: ZmZ1IGpiZXhmIGJhIGNiZWcgNDY5NjksIHFiYSdnIGdyeXkgbmFsYmFyLgo="
Honestly, I think captive portals are probably on the way out, given how good 4G/5G is these days. I am not sure what business traveler wants 10kbps hotel wifi for $30/day when their phone gets 600Mbps down and 30Mbps up.
The LAN here seems relatively small and fixed, i.e., the number of passengers on a flight is known and does not change during flight. The airline could easily assign a unique IP address to each seat (ticket) without using DHCP.
This is generally in contrast to other instances of public Wifi.
The fact that newer phones (Pixel at least) can use WiFi (client mode) as the WAN/uplink side of its hotspot stack (NAT, AP, etc.) is pretty neat. Not long ago, only the cell modem could serve in that capacity, as far as I'm aware. Frankly I'm surprised a single WLAN radio can pull that off. I pay the $8 on my phone and share it to my laptop and whatever devices my travel companion(s) might have.
Windows has been able to do exactly this since Windows 7! It's called Wireless Hosted Network[0], and if you've ever seen the "Microsoft Virtual WiFi Miniport Adapter" (Windows 7) or "Microsoft Wi-Fi Direct Virtual Adapter" (Windows 10/11) in your list of network adapters (it may be hidden), it's there specifically to enable making a hotspot while being connected to a wireless network.
> Maybe at the cost of latency because it has to switch channels back and forth?
Not necessarily. It can be a client on 2.4Ghz and an access point on 5Ghz. Even without that, if it has MIMO, then one of the antennas can be receiving 2.4Ghz while the other is sending (at least in theory, if the crosstalk between the antennas is low and the selectivity of the receiver is sufficient).
I think kids sense wrongness even when the act is deemed victimless, repercussionless, etc. -- it's pretty clear that a thing was achieved that someone tried to prevent, and undermining someone's effort is typically wrong. Tough to think like a kid, though!
Network devices forward (switch, more technically) packets to and end device based on an internal MAC table (send packets for DE:AD:BE:EF to interface ge-0/0/0.0) and most devices populate their MAC table simply by looking at input packets and sending the "next" packet for that MAC address out the "last" received interface.
If two devices in a network have the same MAC address, they will effectively "fight" for control of the packet flow. You can win that fight by sending a lot of packets.
In practice, the other person is going to get annoyed and give up.
There are lots of technology which avoid this issue now, but the two primary ones are 802.1x (used in corporate/government environments) and DHCP snooping which can be much more broadly deployed. 802.1x is very complicated and I won't go into it, but, DHCP snooping works by limiting L2 forwarding (MAC table population) to only what the DHCP server says the end device should have and it does this just by inspecting the DHCP replies (no custom protocol) with some vendor specific extensions on the DHCP server side for complex scenarios (you can even do things like put ports in a specific VLAN based on the DHCP reply).
This works fine on a physical layer and most hotels are probably using something similar now (less for malicious abusive reasons, though that's a thing) but also just to work around poorly behaving devices and to reduce customer complaints. If you care (and have a modest amount of money) MAC and IP spoofing are dead on the physical layer.
For the wifi layer, very similar stuff exists in high-end gear (Rukus/Cisco) and is starting to trickle down to prosumer level gear like unifi. If you care (and have serious cash for Rukus) MAC and IP spoofing are also dead on the wifi layer.
Fun anecdote from the early 2000's re: duplicate MACs:
Embedded IP time clock kept intermittently barfing out frames with the source MAC addresses of other devices on the network. The switch would update its MAC table and direct packets to this device. The Customer's AS/400 would kill all remote terminal sessions when the clock ended up w/ the AS/400's MAC. (They were doing a layer 2-based connection to the AS/400-- APPN, I believe it was called... Ugh, it was temperamental and didn't like any layer 2 "hiccups".)
MAC addresses flapping between ports is one of those "breaking the laws of physics" kind of problems that teaches you to question your assumptions. Gear with a crazy brain can do anything it wants to and it doesn't care about your assumptions.
> it was temperamental and didn't like any layer 2 "hiccups"
The clock was probably doing the "correct" thing when it got a TCP packet for a connection which it didn't recognize and sent back an RST, which caused the client to abort.
> kind of problems that teaches you to question your assumptions
Yep. I learned a lot from dealing with large layer-2 networks (commonly running on hardware not suited for the task). Mostly I learned to never run large L2 networks.
That greatly depends on whether the medium is broadcast (like a radio) or broadcast-like (a shared copper wire) and if it has CSMA/CD logic. Many of the replies are losing that detail and thinking of how it would effect a 1000base-T network, which maps MAC addresses to specific ports.
For a broadcast network, the answer could be 'nothing' in the sense that both receivers would get the same traffic. The IP stack would then throw away packets destined for the other computer unless they were UDP broadcast or multicast, and even then it would only notice if someone was running Wireshark.
Advanced wifi devices/meshes will use beam forming and mesh allocation and might degrade if there were MAC duplicates, but I think they will generally operate in a non-exclusive basis due to end point movement and fading, so both computers will get a good data rate.
Great question. It could, but there is a strong chance that the true recipient has already partially or fully ACKd the segment, thereby changing the sequence number and preventing a reset.
No way to tell for sure, but I can only assume that he had actually hijacked somebody else's connection and the other person's device stopped working for them. I sure wasn't going to stand up and ask the plane if anybody had had their internet plan hacked...
It more or less turns into an ARP cache race, only one device is gonna win. You can do some tricks with gratuitous ARPs as well for "dumber" networks, but more sophisticated setups usually have some broadcast ARP filters that are tied to an auth layer (radius, 802.1x. etc) and will drop broadcast frames from un-authed hosts.
I should probably know this too, but I'll speculate wildly instead.
MAC is Layer 2, IP address is Layer 3. One way or another, the packet destined for the person you're spoofing will end up at your computer and work its way through the layers. From there, if it's a TCP/IP packet, I think it'll get filtered out at Layer 4 (transport) because your computer wasn't one of the parties that initiated the TCP connection (the sequence numbers won't line up, etc).
Packets being broadcast to multiple machines is common enough in various network setups, it's up to the individual machine to decide whether to process or drop the packet.
Since Wi-Fi is a broadcast medium, shouldn't it not matter? With a switch it would break things because MAC tables, but a Wi-Fi AP is a hub. Each device will receive packets for both devices, sure, but will that break things?
I know Windows gets upset when that happens but the network seems to still work.
It used to be more common about 10 years ago, but especially so among hotels catering to business travel. Your Motel 6 would probably have free wifi, the Hilton wanted an extra $20 a night.
It's a business hotel thing, oddly all the cheap chains will have free breakfast and wifi, but often something like the Hilton will be pay for both, likely because the clientele they're targeting is business employees who will just expense the whole thing.
Conference hotels often soak the companies with booths for internet access. One place I did for my company demanded $1500 for 3 days of internet access for up to 5 devices.
In-room, you get free internet access, but in the windowless ballroom with spotty cell-service, there's nothing available for free.
I’ve also seen the opposite, where in-room Wi-Fi was charged, but in the hotel’s function spaces, it was free. The economics of this are confusing, at best. I have also had the situation where the in-room wi-fi was so slow that using my phone as a hot spot was faster!
From my point of view, free WiFi became normal when it became less important because of affordable mobile internet.
From the point of view of the hotels it was about recovering their missing income after customers got mobile phones and stopped paying half a dollar per minute for using the hotel phones.
There was a period when both mobile roaming and hotel WiFi was expensive, so I often went out from my hotel room and bough a local SIM-card to get internet access.
What annoys me most, is that only when I finally could get a laptop that would work a full transatlantic flight on one charge, then suddenly airplanes all got power outlets.
Yes. You often also have to pay for parking in many places. The price you see online is rarely what you pay for. But that's part of the culture, it's the same for restaurants, online purchases etc.
I suspect the "how" is that we just never got the regulation that would prevent it because the 'small-government and low taxes' are aligned perfectly with the large business interests which tend to fund all campaigns. The "low taxes" types want to maximize the sting of all forms of tax and this is a great way to do that. And the businesses appreciate the psychological benefits of being able to show the minimum possible number. Even if a "display only the final price" rule applied to all a consumer's options, we probably just buy things more when they're labeled as "$99.99" instead of "$109.99."
For extra fun, consider how phone bills attempt to "pass through" their own tax obligations, which have little to do with your own incremental usage, in the form of 'recovery fees' tacked onto bills. I suspect we'll eventually see those creep into all kinds of transactions, especially among other monopolistic/oligopoly businesses where you have little if any choice.
The 2 largest retailers on earth have discovered that the x.99 prices make you less money than pricing at x.99 plus some arbitrary number between .99 and .01.
I think the EU law on that is the "Price indication directive", and AFAIK, it's been around since 1998. (may have replaced an earlier directive, my google-fu is lacking)
I think the norm is to show whatever price you want, with some countries banning that for fairly obvious reasons.
That's a weak justification to apply to prices listed right where the product is sold. Like, if one uses a sticker gun to put a price tag on a product itself.
I don't know of any US businesses other than waffle house that always include all taxes in the listed price, however.
There are laws against adding in taxes on listed prices in places like NJ, likely others as well.
Regardless, I'm not sure why people consider it such a big deal. It's consistent across the board and it's relatively basic math to estimate what the total would be.
I've lived in places that do it both ways and it's a non-issue.
Thankfully competition from AirBNB made them re-think the idea. That's my theory why it mostly went away anyway.
There's still some stragglers though, offering "basic" access free but charging for higher data limits, faster bandwidth, more devices. You can often get the higher plan just by signing up for the hotel's loyalty program.
It's not unheard of but it's probably been a decade since I've been to one personally. Some have free WiFi just for guests (probably good since the bandwidth is so saturated already).
The last couple of hotels I stayed in had free "basic" wifi for guests. Elite status could get higher speeds for free or anyone else could pay something like $10/day/device to get higher speeds.
I just switched to my cell phone data if the wifi was too slow.
This is what I did about 7-8 years ago on flights when I was still a reckless teenager. Would just wait for people to buy the plan, then spoof their Mac address.
There was also a specific airline, although I can't remember which one, which let me in for free without MAC spoofing - by using a Google Cloud VPN I had previously set up. The paywall was essentially blocking all IP ranges except for Google servers for Google Analytics.
Took an airline that required an app to pay to connect… but also opened up a window of a few minutes of open access to let you download said app from the iStore.
I always wondered if there was a way to further exploit that.
IIRC (assuming it was the same airline), it didn't close existing connections once the time ran out, so you'd just ssh to a server and proxy through that. When/if the connection dropped, you'd just change your mac address and start over.
Similar is probably possible on cruise ships, I noticed on Carnival you could still get notifications from discord (I assume because most android notifications go through cloud messaging and it's required for their own app to work without internet).
This is what I used to do at home when my dad would turn off my internet access (by whitelisting MAC-addresses. Before that he blacklisted MAC-addresses, but I just used the built in way to change it with each connection on windows until he found out.). My mom rarely used her PC so I would just change my address to hers. It worked until she had to use it and at that point none of us could access the internet.
WiFi signal is received by both. Packages are ignored if they are not requested by either one of the systems. You can also receive anyone else's packages while you are using your internet but ignoring the ones you don't need. (If interested try aircrack-ng.)
If it's important but you got time, you could always save the packets and crack them when quantum computing comes out for consumers. You have to wait a couple of decades probably, but maybe it's worth it
Of course if you don’t sit in a Faraday cage you can receive any electromagnetic waves around you. But you can’t actually receive other users IP packages.
“According to this data, the plane’s altitude was only fluctuating by about 20-30 feet. This is more stable than I expected!”
Autopilots are very good and they are servoing to the pressure altitude.
Many pressure altitude encoders used in modern aircraft (for example to drive altitudes that transponders report to SSR radar or via ADS-B) have 25 ft encoding resolution. That 25ft resolution is likely what is being seen here. Other encoders have 10 ft resolution but 25 ft is very common.
I don't know what sensors are feeding the API from the post, but most passenger jets do broadcast information about the accuracy of their sensed position, including vertical position/altitude. If you click on an aircraft on the map at https://globe.adsbexchange.com/, and scroll the left sidebar all the way to the bottom you'll see a section labeled "Accuracy". ADS-B Exchange doesn't show Rc/v, the vertical position accuracy, but it does show other values. See https://mode-s.org/decode/content/ads-b/7-uncertainty.html for more information.
Pressure encoders, as I said. That's what feeds all aviation altitude data... i.e. anytime you see the word 'altitude' and its not qualified with 'GPS altitude' which is effectively not normally used. ADS-B Out concurrently transmits GPS height about the ellipsoid data as well as pressure altitude data. No use is normally made of the GPS height data. We are discussing pressure altitude data here, that's what aviation works off of. The accuracy and reliability metrics in the ADS-B broadcast you are referencing refers to the GPS data not the pressure transducer/encoder data. In cases of encoder failure being detected a flag is broadcast and the pressure aka baro altitude data field is set to all 0. ADS-B cannot give information about the pressure altitude accuracy or reliability like it does for GPS metrics. It relies on the encoders being better than their +/- 125' accuracy requirement and that's tested for periodically. ADS-B can in principle broadcast 100' or 25' resolution encoders, that info is in the messages. The ones here will be 25'. (I've got a long background with ADS-B related technology, currently helping the FAA out on some niche stuff).
edit: trying to improve clarity/correctness but there is too much to cover here.
Cool, thanks for the info. (BTW I wasn't disagreeing with anything you wrote, I just wanted to mention, since the topic of resolution/accuracy came up, that lots of aircraft broadcast information about the accuracy of some of the sensor data they're reporting, which you can do some pretty cool stuff with. E.g. that's how https://gpsjam.org/ works.)
Oh sorry I did not think you were disagreeing I was just trying to be clear and more trying to clear up the GPS accuracy/reliability metrics like SIL, NIC, NACp and NACv being broadcast by ADS-B being completely separate to anything to do with pressure derived altitude, I was going down a rat hole and had to edit that several times. And it can be painfully confusing e.g. the failure flag for pressure altitude aka baro altitude in ADS-B speak failure is called NICbaro but has no relationship to the GPS NIC (Navigation Integrity Category) value. And depending on the system some of the GPS accuracy/reliability metrics are just hard coded, and the ones that really matter like NACp are derived from the GPS and SBAS reception.
John Wiseman does great stuff with ADS-B Out data.
Also for pilots/aircraft owners/A&Ps: The FAA PAPR (Public ADS-B Performance Report) https://adsbperformance.faa.gov/PAPRRequest.aspx provide a summary of their aircraft's ADS-B performance, including all the broadcast GPS quality metrics and any reported failure flags etc. The PAPR system will email out the PDF report. The owner/pilot/A&P can reply to that email and request a Google Earth/kmz and Spreadsheet/CSV data for that flight showing all the received ADS-B transmissions including all those accuracy/reliability metrics. Interesting stuff and very useful for diagnosing problems with ADS-B Out installations. So sensitive you'll might see say NACp degrade as an aircraft banks steeply because the GPS antenna now has a view of fewer GPS satellites. Installations in most (non-experimental/non-light sports) aircraft effectively require use of PAPR to formally validate a new installation is working correctly. It's a good thing for owners to also just periodically check their aircraft's ADS-B performance using PAPR. I suggest just before and after each annual inspection for GA/light aircraft.
Also worth noting that the datum used to translate from pressure to altitude switches at the transition threshold, usually 18,000ft, from actual local ground pressure (supplied by ATC in all initial contacts) to 29.92 Hg.
For small planes a 20-30 foot range isn’t abnormal for hand flying if you’re paying attention. I’m sure in cruise an airliner is using an autopilot though.
I once had ATC ask if everything was cool on flight following after a hundred foot drop and I was surprised they were paying that much attention. I had forgotten to put my life jacket on before a water transit and while I was putting it on handed it off to my wife who hadn’t taken lessons yet (she later got her license!). It was interesting to see that their tracking was precise enough for them to chime in.
>> Autopilots are very good and they are servoing to the pressure altitude.
It would have been cool to use a phone to record a GPS track with altitude and compare them. Pressure != GPS. Also wonder if there would be distinct jumps in the difference if they reset the pressure based altimeter to a different AWOS.
Not sure how it works in big planes, but in little ones you need to set your altimeter based on the local weather. The weather stations measure barometric pressure at their elevation and "correct it to sea level" you get this corrected reading over the radio and set it in your altimeter so your pressure-based altitude reading is corrected for local weather variations. Just going out flying for an hour the altimeter setting when returning to the same place might be off by a few millibar.
The QHN/Kollsman window setting only affects what is displayed to the wetware. When you strip away all that the autopilot is just servoing to a pressure altitude. But sure if you are flying below the transition altitude and are flying between areas with different QNH settings when you adjust the setting the autopilot will climb or descend as needed because you told it to servo to a different pressure altitude.
There are many EFB (e.g. Foreflight), or log book, or other flight recorders you can use on an iPhone. And some can record the pressure transducer in the iPhone to record an approximate "pressure altitude". e.g. Naviter SeeYou Navigator intended for gliders can do that (but it's not unusual for modern gliders to have an array of sophisticated air data sensors and specialized variometers and flight computers that would feed the app this data over Bluetooth). Popular EFB software Foreflight will not use the iPhone pressure transducer, if you want pressure data there you need to drive that through an external interface like a Sentry ADS-B receiver that has a pressure sensor built into it -- or much better if the aircraft is equipped with ADS-B Out can receive the "own-ship" ADS-B Out broadcast pressure altitude from it's high accuracy encoder). Any in-cabin pressure traducer will be sensitive to the difference between calibrated static pressure and cockpit pressure, things like opening or closing vents, or varying the airspeed significant (and ram air pressure or suction on the cockpit exit vents) can cause observable changes. And when using an iPhone or similar, especially without a great GPS satellite overhead view (e.g. in high wing aircraft) you are likely not to get high-quality GPS altitude data. think best case ~ +/- hundred feet, worse case with little overhead GPS sat view, much worse... but those consumer GPS app is likely to happily display multiple decimal points of precision :-)
You use standard pressure (29.92 inHg) above transition altitude, which, in the United States, is 18,000 feet. Pilots wouldn't be changing the altimeter after climbing past this point, and would start using local values once descending through it again.
Of course, your initial point is still correct: there could be slight variations if using those local settings and getting different values, but you'd only see that below transition altitude.
At high altitude you do this stuff "When you set your altimeter to 29.92, you're flying at standard pressure altitude."
The idea is all the planes use the same setting so the one at FL35 doesn't hit the one at FL36. But those are not exactly 35000 and 36000 feet above sea level.
I guess they got a lot more precise with implementation of Reduced Vertical Separation Minimum (RVSM) - planes had to be separated by 2000 ft and this was reduced in early 2000s to 1000ft
It was probably fairly precise already. To get their license, a private pilot must demonstrate via a checkride the ability to stay within 100 feet of an assigned altitude, even in a steep turn.
These are the instruments we are referring to not the ability of pilots. In fact in RVSM airspace the autopilot must be used.
Instruments must be very accurate given the reduced separation in RVSM airspace. Often on modern aircraft multiple altimeters are compared and voted to provide a single output provided to the displays and autopilot.
If a human can manage to keep it within 100 feet of a desired altitude, an autopilot most certainly can; it didn't require new technology in the 2000s. Autopilots in the 1960s/1970s weren't seesawing all over the skies.
RVSM is overwhelmingly about instrumentation accuracy and precision, not pilot capability. [0]
The pressure difference between 5K MSL and 10K MSL at standard conditions is 14.6 kPa.
The pressure difference between 30K MSL and 35K MSL at ISA is 6.3 kPa.
For a given amount of aircraft-to-aircraft variability in their precision altitude sensing equipment, the resulting difference in actual altitude is more than double in RVSM airspace than in the lower altitude range above.
That's the reason for RVSM: there is less change in pressure with change in altitude, coupled with a very busy altitude range (such that controllers would have an operational need to pass traffic overhead with only vertical separation rather than being able to use vectoring to achieve lateral separation between aircraft).
It's not a linear relationship, but if I take an airplane with a 0.75 kPa absolute error in one direction and pass traffic with a 0.75 kPa absolute error in the other direction 1000' indicated above them, at low altitude, that 1.5 kPa total error is a little over 500 feet while IFR-IFR separation is 1000 feet minimum outside of RVSM. (These aircraft would likely be right on the border of passing a non-RVSM static system check.)
If I take those same two aircraft into the mid flight levels and pass one over the other at 30K and 31K feet, the total error is around 1200 feet, which is why non-RVSM aircraft cannot be separated by 1000 feet in RVSM airspace, because you don't know that they'll miss each other.
Improve the accuracy and precision of the static system and improve the examination criteria, making the airplane RVSM-capable, and now you can pass that traffic over each other at 1000' of indicated separation and be sure they'll miss.
[0] - There is a pilot training requirement, which is focused on knowing the rules for RVSM and does not involve a checkride.
I think you're at least partially missing the point.
For autopilots servo'd to pressure altitude, holding altitude to within 0.02 kPa is more difficult than holding altitude to within 0.05 kPa or to within 0.30 kPa (which is roughly the private pilot checkride standard as-tested).
Modern autopilots are actually better at holding altitude to a very tight tolerance than ancient, analog autopilots. Both can hold standards well within the PPL ACS.
> holding altitude to within 0.02 kPa is more difficult than holding altitude to within 0.05 kPa or to within 0.30 kPa
"more" difficult is obviously true, but the difficulty of holding an altitude is only a small part of the overall difficulty of RSVM.
In other words, RSVM is much more about accuracy than precision, and the claim was that planes were "probably fairly precise already". The reason they needed upgrades was to improve the accuracy, not so much to improve the precision.
I have read somewhere that so much precision could actually be dangerous in some circumstances.
This is because this way, if a pilot goes 3000 ft for instance, it will be exactly 3000 ft, if another pilot also wants to go 3000 ft on a collision trajectory, it will be a guaranteed collision. When altitudes are not that accurate, there is a higher chance it being just a near miss. The solution, I think, was to simply avoid round numbers. So now, it is 2950 ft, 3050 ft,...
I may have the details wrong, but I am quite sure about that problem being seriously considered.
Yes, it's called the navigation paradox, and it mostly came about with the advent of GPS. It's the reason we now have what's called "strategic lateral offset procedure," or SLOP, whereby aircraft on heavily trafficked oceanic routes fly zero, one, or two miles off the centerline, randomly chosen.
This is really interesting. But it seems like it could make collisions more likely, and the better solution would be separate corridors for east vs west traffic. Are there really 5 bidirectional lanes?
It's a bit more complicated than that. The routes I'm talking about are the North Atlantic Tracks, which are used for most traffic between North America and Europe. There are multiple tracks and SLOP is used within each track. All of the tracks run in the same direction at the same time, switching directions twice a day. They go eastbound at night, westbound during the day. SLOP is a mitigation to prevent aircraft in sequence on the same track from colliding. There are, of course, many other systems and procedures in place to prevent such collisions, but it's belt-and-suspenders up there.
When I am on a flight and the flight does not provide the flight information, I am using the OsmAnd, https://osmand.net/, to monitor the flight altitude, speed and direction.
No idea how true it is, but I overheard someone on a flight say that whenever you feel a real sudden jolt on a plan it's really only moving like 2-3ft.
A plane going up and down 20-30 feet seems like it would be very unpleasant. Considering that there's longitude and latitude, isn't it more likely that the altitude is coming from GPS, which is notoriously inaccurate with regards to elevation?
20-30 feet change over what timeframe? The resolution of the chart data in the article is about 30 seconds. While I think the fluctuation is due to the accuracy of instrumentation, 20-30 feet change over the course of a minute seems like nothing.
Planes report pressure altitude via their transponders. 20-30 feet up and down is very normal for an autopilot.
GPS altitude is used for vertical guidance for certain types of GPS approaches (i.e. "LPV" approaches[1]) and requires the airplane's avionics to be equipped with a WAAS[2] receiver that provides accurate altitude information.
When you take off, you're going up at a rate of 500 fpm to 2000 fpm. Even if you go from +1000 fpm to -1000 fpm over the course of several seconds, you aren't going to feel much.
At cruise altitude, you're moving along at 500 mph, which is 777 feet per second. So going from +30 feet to -30 feet in a minute is just an adjustment of only about 5 degrees. You'd barely feel it, even walking down the isle. An acceleration of 33 ft/sec per sec is 1 g.
You experience greater changes in vertical motion on any flight you go on.
> So going from +30 feet to -30 feet in a minute is just an adjustment of only about 5 degrees. You'd barely feel it, even walking down the isle.
You would pretty obviously feel a change in pitch of 5° walking down the aisle.
You mixed feet per second and feet per minute. 60 feet of change across 777 feet of run is about 4.5° (inverse sin(60/777)), such as you'd experience if the change was in 1 second instead of in 1 minute.
Calculating 60' change in 777*60 feet, inverse sin (60/(777*60)) is 0.07°, which is why you don't feel that change in inclination of the aisle.
Yes, the elevation is based on sea level. I don't fly much and recently landed in Denver and was watching the altitude on the screen in front of me. As we were descending we landed well before I was thinking we would, about a mile in elevation above sea level.. it was "duh" obvious when it happened, but I was tired and clearly not thinking about it!
This only holds true if you’re flying at or above the transition altitude. The transition altitude depends on where you’re flying: for example, in the USA and Canada it’s 18_000 feet MSL.
It's still sea-level. The transition altitude just changes the altimeter setting from one that matches the current air pressure to a standard pressure setting.
The plane is measuring altitude, which is relative to a reference point, unlike elevation which is relative to sea level. And if the altitude is determined by pressure sensor, musn't it be relative to the ground directly below the plane, anyway?
(Although personally, I agree with the sibling comment that the variability is likely an artifact of the sensor resolution.)
Yeah, you make a very good point. Fortunately the blast radius of my scientific hubris is limited to whatever code I manage to deploy to the internet, and I'm not involved in designing or building aircraft.
btw: Aren't you the guy who tracks planes flying in circles? I follow you on Twitter. Such a cool project!
It's relative to sea level. After transition altitude (18k feet in most places) the pressure setting to the altimeter is changed to standard (iirc 1013 hPa) so all aircrafts are in the same reference regardless of terrain.
Planes dont measure height relative to the ground. How would that even work? Their sensor is air pressure, which is treated as a function of elevation.
They do sometimes! Via radar altimeters, when relatively close to the ground. And sometimes to keep autopilots from freaking out, we have to build radar reflectors to make the ground look level to radar even when it's really not. https://lustublog.com/2017/02/17/artificiel-mais-pas-superfi...
Thats funny, I discovered the same thing a few months ago and built a CLI flight tracker[1] that uses the API. I've tried it across a couple of airlines and it worked almost perfectly across all of them, because they were all using the same in flight ISP.
That's cool! I had wanted to make something similar, but I didn't have enough experience with making TUIs to build it without using the internet for reference during the flight. I'm glad to that it's been done though!
Maybe you can take risks like that, but I certainly can’t. I don’t think anyone with my name or skin color would be given the benefit of the doubt for even a moment.
the airline industry is nowhere nearly as stupid as the software industry with things like this.
the communication between plane and wifi/entertainment system, if there is any, is almost certainly one-way. likely, the wifi system providing this info is receiving data from the flight systems and repeating it or transforming it a bit and providing that.
it would not surprise me at all if the flight attendants have to program everything about the flight into the system prior to departure each flight, and there is no communication from the aircraft at all.
"The computer network in the Dreamliner's passenger compartment, designed to give passengers in-flight internet access, is connected to the plane's control, navigation and communication systems, an FAA report reveals." [1]
(I guess there's some kind of firewall, but we know that those are not always perfect)
IIRC the in-flight infotainment systems are entirely separate from the avionics control systems at the data layer. I recall being told that in some cases even the flight status is actually pulled from a 3p api service rather than hooked into the onboard avionics.
There could be some fuckery via shared power or other non-data systems but that’s probably beyond someone sitting in a seat with standard laptop hardware.
The weight-on-wheels switch reports its in-the-air status over ADSB. It errs in the direction of assuming in-the-air, which was implicated in a near miss on the ground in 2020 between two Air Canada flights[1][2]
Not necessarily. All this could be reported up to airline HQ through the satellite link and then the IFE/customer WiFi could be downloading it again to serve locally.
That would prevent any need for direct connection between the systems.
Is that how it works? I doubt it. But it could be done.
Is this the thread where the web developers speculate wildly without facts or evidence and pretend to know more about airplanes than the aerospace engineers who built it?
Relies very strongly on simple airgapping. Can't do anything to it if there's no wires in the direction you want. Can't remotely hack if there's nothing antenna connected that can talk to flight control. It has the luxury of not needing to do the "limited RCE" that is a modern web request
Reminds me of an episode of Leverage where they wanted to hack into Congress and change the text of a bill. In the show, it turned out everything was airgapped so they had to send a person to drop off a paper copy of the compromised bill. Hmm, that was also a plot line in Better Call Saul.
In the article above, in-flight wifi has an API reporting position, altitude, and velocity. That is a feed from avionics, which renders the claim of airgapped systems essentially null.
They could, for the sake of a ridiculous but clear example, have a display hooked up to the avionics and a camera hooked up to a separate computer which reads the values.
There are various ways of connecting systems while physically guaranteeing one way data flow—a fiber optic link with the transmitter removed from one end and the receiver removed from the other is basically a less silly “camera pointed at a display” and used in the real world.
You could argue the exact semantics of “air gapped”, but for the discussion here that’s accomplishing the same thing. The fact that the passenger network has some visibility into the avionics network is not, in and of itself, any indication of an issue.
The plane has a transponder that reports this information to the ground, ATC, other aircraft etc. The infotainment server has a receiver that gets this data. Or in some cases they instead pull it from a ground based service via the internet. The transponder is not able to receive signals, so it is air gapped.
A quick review of published information reveals this claim as false. A typical airliner FMS feeds information to IFE via gateway devices. The integration is intended to be one-way. Airgapped they are not.
Such analytical delusions are the first step on the road to failing to adequately mitigate threats. As practiced by “it can’t happen here” school of fucking up.
Fortunately, it seems far more likely that aircraft system designers do not rely on any such assumption, and practice defence in depth. There was a good talk at DEFCON 22 by Phil Polstra on the matter.
Interesting how they chose to make more general `vehicleId` instead of `planeId` or `tailNumber` or something. I wonder if Delta's fleet includes other things that have matching APIs to this one. I also wonder how much of their internal system structure one could learn from the `flightId` if they knew about other systems. It doesn't look like much beyond a composite key of otherwise knowable data, but still interesting.
But they also have airplane/flight specific identifiers like “flightNumber”, “flightId”, “noseId(?)” and “airSpeed”. Maybe vehicleId is part of a base class or primary key somewhere and that abstraction is leaking.
I've been tempted to mount a small anemometer to my car - by subtracting the groundspeed from the measured airspeed, one can get the wind speed and direction and figure out whether there is a headwind or tailwind and if so how strong. Theoretically this could be used to drive more efficiently, though the extra drag from the anemometer would probably cancel out any gains.
It'd be interested to make a little HTML page that can query the api for each airline that exposes something like this and give you an in-flight display on your laptop.
I want to see someone build a proxy that uses the free iMessage or WhatsApp allowed connection to send arbitrary data.
Like have a WhatsApp relay set up at home that you are sending messages to and from, from the plane.
Like at a most basic level, send a message of a URL to your home WhatsApp which loads the web page there, and sends the HTML back as a WhatApp message reply so you can render it etc.
Wonder what someone could all do and make work.
edit Guess someone made a TCP relay using WhatApp already, neat.
I've not read the EULA but why not just have an actual IP router?
Pay the signup charge, and also stand up a wifi network. Call it "Foo discounted" if the plane's SSID is "Foo". Put up a captive portal that lets the user claim various "discounts", like veteran, senior, child, etc. No matter what they choose, charge them $2 via a payment page. Once you've been made whole on the service cost, future visitors get a notice that "all discounts have been claimed, please use Foo".
Now you have free internet and all those using your router/portal have $2 internet. The upstream bandwidth is certainly atrocious so you will easily be able to multiplex all the data onto your connection.
Bundle it into a RPi kind of device (has to look finished, like a music player or smth, to get past security) so that you can continue to operate the device even when tray tables have to go up, when you go to the bathroom, etc.
I find it extremely doubtful that the airplane has WIPS or WIDS that will deassociate
connections to your rogue wifi. And after all, are you not allowed to have a LAN party?
I happened to have had a flight a day or two after the first beta of Apple’s Private Relay a year or two ago. I was able to use free WiFi the entire flight. Presumably because whatever they whitelisted for iMessage and/or push notifications covered that as well. They had blocked it before my return flight days later. ¯\_(ツ)_/¯
Instead of “wow, cool” my first reaction is “free messaging is a great perk, if this is abused they will shut it down”. I guess my hacker days are behind me.
Airlines already introduce free WiFi to everyone for free. JetBlue does it, Delta also does it for continental flights. Eventually all will, as there is more competition in the tech and prices drop.
I've noticed that airline wifi doesn't block DNS traffic. You can likely accomplish the same thing with a DNS tunnel like Iodine (https://github.com/yarrick/iodine).
Many years ago, I noticed I could browse the Google Play Store on a flight WiFi without paying for it. No images would load and no apps would download, but I could browse through app listings and read reviews.
Probably not. I bet something in Android didn't work properly until they whitelisted some Google domains — for example, maybe it didn't detect the Internet connection when the user paid for it, or maybe something on the entertainment tablets broke (I don't know if they usually run Android or something else).
This seems likely. ~6 years ago on a Delta flight I noticed that I could use Google and view cached pages without paying for WiFi. I managed to catch up on the news on my flight…
Flighty leverages the Apple Push Notification Service (APN), which the iMessage infrastructure also uses. It's why you can receive notifications in flight but can't act on them.
Way back in the day a lot of authenticated wifi firewalls did enable DNS requests to pass through, or at least to resolve using their DNS server, without being authenticated.
Someone smart created a TCP-over-DNS tunneling tool that I had a lot of great experience with, at least for more simple news websites of the day.
Tried this on a flight 4 years ago -- I got to SSH into a machine and read my mails, it felt like I was connecting from a space ship... so funny but not actually usable to browse the web or do any actual work ;-)
But SouthWest will give you a much prettier display of that same data (track your flight, see the current altitude and ETA, and a lot more, like the plane's position on the map) without paying for their WiFi. My guess is that they are using the same data that article writer wrote a program to process. Essentially there is one site you can visit for free and that's where it is.
I was on some US flight recently - maybe Alaskan airlines - and they basically had a LAN box with movies and shows accessible on wifi without internet access
I was just thinking that you could take a picture from the window and then tie the GPS coordinates to the image with the output from that JSON. Kind of handy.
I’ve managed to get a GPS lock while flying, it just takes a few minutes to find one. Was it misreporting my position? because it usually matched up with what I saw outside of the window
Probably because you were in a large aluminium tube at the time, and had no internet to get the AGPS data, so it had to receive the orbital elements from the satellites. (IIRC, this can take as many as 24 minutes worst case)
If you're using GNSS tracking on a flight, consider checking out the OSMand~ app for android. There's a map layout for flying, though I don't know if the navigation features work.
I think the "and" in that sentence used to be implemented as an "or" in the days before everyone's phones had GPS in them. So you'd need to power cycle the device before it'd work again. Now most devices need to hit both limits at the same time before refusing to work.
Even now, it seems it may be up to interpretation. In searching for those numbers, I saw a post in a amateur high altitude balloon forum asking which modules were "or". (Presumably since it's a little more likely your balloon will exceed the altitude restriction and not the speed one.)
Conceivably, the ADS-B data source might be the same as the data source for this API, at least in that they might be calculated from the same instruments and flight systems.
Anyone else freaked out by that "time" format though? Seems like a strange choice, would have expected something more standard like ISO 8601 with timezone offset.
"time": "Sun Sep 24 22:02:19 2023"
My best guess is that whoever designed this system preferred to transform the time into a localized (based on the flight's location, I guess?) representation on the server so that they could drop it directly into the web UI without much client-side logic.
Talking to the pilots costs about $200 and is really easy, though very illegal - just find out which ATC freq are they currently on and transmit, from a handheld radio or a HackRF. You could also transmit on Guard.
If you prefer to text rather than speak you can send them ACARS, with roughly the same hardware. Though if you use a handheld radio you'll also need a laptop to generate the baseband signal, as I don't think there are any commercially available ACARS transmitters.
(Please never do this, you'll go to jail for a long time).
I just listen (with an SDR, I never got a HackRF because I don't transmit). Where I live I can see planes on approach to SFO and can cross-reference flight codes on the radio with planes that I can see flying by and on flightradar.
Honestly, it seems pretty fair to me. If I'm a careful, occasional driver, and the insurance company otherwise has no way of knowing that, then they have to bill me like I'm commuting every day in stop and go traffic, distracted by podcasts and who knows what else.
There will probably always be a "premium" market for no-questions-asked insurance, but if the company can give me a break on my rate based on my driving behaviours correlating to a lower incident likelihood, I'll happily take that break. Even better if such measures correspond to drivers across the board adjusting their habits now that it hits them directly in the wallet.
The majority of fatalities involve drugs or alcohol, they often involve youth and speed, and occur at night. Many insurance claims involve single vehicle accidents and weather or other wear related damage. The most common two vehicle claim is rear ending into a stationary vehicle, where it's not particularly difficult to determine fault.
Further, none of this matters all that much if you have a straight liability only policy, since that's based on liability of damages and not replacement property values.
These devices make very little sense to me and I'd be curious to know if anyone has any data that the presence of these devices is having any impact whatsoever.
At it's face, yea, it sounds fair, and the more data you feed to the actuarial tables, the more accurately they can identify the specific cost of insuring that driver.
My concern is that it's a tragedy of the commons type situation: this normalizes data surveillance. We have no idea exactly what data the device is transmitting, and what the insurance company will do with that data. Regulations protecting this data are weak-to-non existent.
With everyone's budget being stressed, people are quick to trade a few dollars to sacrifice privacy, and then this technology is being mandated everywhere.
Fair, though given that manufacturers are already doing this stuff anyway, it feels like a problem to be solved with broader privacy legislation than by making good drivers pay for the cost of bad drivers.
On the other hand, I suppose I'm a bad person to make this argument since I actually dislike personal automobiles for a whole host of reasons, so I'd just as soon get back my privacy by walking, cycling, and using mass transit.
I did one of those once and tried for three months to drive really carefully.
in Boston.
it basically broke me and my driving sanity for 6+ months and made me a really worse driver for a while, maybe permanently?? and my rate basically didn't change at all.
This is why I love hacker news. I was sitting in the waiting area at Long Beach Airport about to board a Southwest flight when I read this article. Did the hack, it worked spectacularly. I didn't have jq installed, but whipped up a python script with 'import json', watched the data stream the whole flight. Thanks a million for posting this!
If you travel lite with clothes in a book bag(wash clothes if extended stay)… I don't see why anyone would fly United, Southwest, American Airlines, etc VS.the budget Airlines like Spirit.
Maybe if you have points with those airlines… Otherwise, save hundreds of dollars using budget airlines which the planes are newer in my experience, and never had a bad experience versus my recent bad experiences with Delta and the others in which I paid a lot more for. Almost all airlines I've had to pay for Internet access, including Spirit so for me, I don't understand why I would fly all the more expensive airlines versus using Spirit.
There's a lot of negative marketing out there about Spirit… After my 10 positive flights experiences in the last six months with them I don't believe the hype.
> I don't see why anyone would fly United, Southwest, American Airlines, etc VS.the budget Airlines like Spirit.
I'm on a spoke (not a hub) and just don't have the service available to use budget airlines even if I wanted to. We have JetBlue -- they fly to Boston and that's it. We have Allegiant and they fly to Phoenix (not really Phoenix -- Mesa), and we have Avelo they they fly to LA (not really LA: Burbank). All these airlines fly one flight per day, and often not every day of the week. When I'm traveling somewhere that works for the budget airlines, I'm still leery because if their plane breaks down or there is "weather in Cincinnati", I'm screwed. They don't have a second plane available.
otoh we have United, Delta, American, Alaska, Southwest with flights to several hubs each, multiple flights per day, through international ticketing, first class sometimes open... Plus I don't pay for luggage on the major carriers due to credit card membership/status.
You must have buns of steel. I flew Spirit exactly once (well, twice, it was round-trip), and it was such a miserable experience I swore to never do it again. Their seats are made of concrete as far as I can tell.
For domestic flights I pretty much always sit in the window and never get up during the flight. On spirit I had to get up and walk around after about 3 hours 'cause my ass was sore. Never again.
Not terribly negative, but yeah I always assumed it was cheap for a reason. I think I'd probably do a 1-2 hour flight on spirit if it was a good deal. Past that I'll spend a little money for a more comfortable flight... Guess I could also just bring a cushion on board with me lol
Sure for me I fly out of a major hub (Baltimore Washington International) and Spirit flies pretty much to every US city from there.
One thing bad about spirit is their extremely horrible refund policy .. their seats are a bit smaller but not by much.
Thus far in my ten recent experiences flying Spirit with clothes & travel necessities in my book bag has saved me lots of money and my flight experiences have been the same to even better compared to Dekta, United, Alaska or Southwest. Thus the first place I now go to book a flight is spirit due to my experiences and flying out of a major hub.
I hope JetBlue doesn't get the chance to buy them out ... Spirit allows a lot of ppl who couldnt afford to fly enjoy a benefit all should be able too and for me i like saving money!
Sometimes the budget airlines don't fly to where I'm going, or do so by long multi connecting routes. I'm currently sitting on an AA flight because it was the cheapest option with a reasonable travel time. Honestly, it kind of sucks for all the usual reasons, but I've at least got free wifi on my phone through some deal with T-Mobile.
Just to clarify, Southwest is classified as a budget airline, especially compared to the "big 3". Spirit and airlines like them are in their own class called ULCC (ultra low cost carrier) to differentiate them from the existing budget airlines.
On redeye international flights with exorbitant WiFi fees I'll admit to scanning for MAC addresses, get the top talkers, then come back later when ones been idle for like 15 minutes, presuming the person is asleep and change my mac to take the address and get online.
Glad someone looked into the flight tracker, I was always curious how real the data in it is.
Although it doesn't answer my curiosity about how they manage to mess it up occasionally. I've had flight data from different flights pop up a few times on Southwest, which is never reassuring to see.
If it's the panasonic inflight system, it receives flight data from the FMS. If the system does not receive flight data from the FMS then it will not be up to date. Your browser could also be retrieving old cached content.
Basically there is nothing about this system to assure you, it's entirely a secondary data-delayed system that is not critical to flight operations and as such can be INOP at anytime and no one will care.
> Your browser could also be retrieving old cached content.
No, these are flights I couldn't physically have been on. Sometimes it is old content, but it's for the flight the plane took previously and doesn't update.
Also the FMS may not be programmed until right before the plane takes off. The flight plan is filed with ATC but not programmed into the plane yet and that is sometimes done during taxiing, esp if the pilot is an air cowboy/behind schedule.
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.
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.
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."
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.
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.
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.
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.
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.
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
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.
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.
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.
[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.
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 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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
- 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.
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.
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.
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.
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.
I used to do this on long flights, but most in flight providers have stopped trying to identify and shape specific protocols and now limit bandwidth purely by client. If you get a few people on all at once it thinks you are streaming video and throttles you.
I believe that you can't both simultaneously provide wifi hotspot and use wifi internet (at least, I couldn't on a phone several years ago last time I tried it). I think you can only do that if the network the phone is using is accessed via the cellular modem.
I absolutely can, that's how I connect my ps4 to my uni accommodation internet as it's mschapv2 or smth the ps4 can't connect to. I know it's definitely using the wifi and not my mobile data as my data usage for the day is unchanged after I've downloaded a game.
Cheap Chinese android phone from 2020 (or maybe 2021 can't remember).
Depends on the phone OS and wifi chipset Some Pixel phones can do it last I checked, which was about a year ago. It's a fragile dependency. For example, a Samsung with the same wifi chip didn't work.
Reminds me how old and unsecure those system used to be, years ago they would perform DNS queries but block most traffic, meaning that you could get free internet by using DNS tunneling.
Same for the movies on board, if they have some apps and not just movies in front seat, you can use vlc, ffmpeg to download / watch the movie without ads / interruption.
When I was doing some digging they used a lot of Panasonic solution and open source stuff such as squid cache, apache http.
I just took two delta flights in the US. The first had free Wifi through Tmobile. It marginally worked. It was just fast enough to view low-intensity websites and I was able to connect to my linux servers back home.
I've done something similar on trains in the UK before, specifically LNER (was Virgin Trains East Coast at the time but don't think the Wi-Fi solution has changed) trains. The icomera captive portal has an endpoint which returns the GPS coordinates of the train along with the speed. And some other endpoints for next stops etc.
Once made a little React app that showed the train on a Leaflet map. Was a good waste of a few hours.
Fun fact: I used to work for a company that provided equipment and services for satcom. The price tier and license for airborne communication was higher and we had software calculating the speed and if the speed went over 300 m/hr or alike it will check your license features and expiration date. If you forgot to pay your bill, no wifi for ya! We did not use altitude for obvious reasons.
I remember doing something similar on a flight until a flight attendant, very confused, asked me how I had all of the graphs from the flight deck on my laptop.
Was a funny conversation, especially giving Panasonic (who made the inflight flight tracker) exposes way more data on their API than I could get in the airline’s provided view.
I did something similar on an easyJet flight, I wrote a little Python script to save the altitude and speed data from the free WiFi. They have a cool 3D WebGL rendering of the plane in the air like Flight Simulator, but the satellite imagery was really low res.
I have to wonder if some eager LEO would try to find some illegality in this, especially given all of the federal laws around aircraft. Obviously it's innocuous, but I'd think twice about writing about this kind of tinkering for that reason.
For those not in (I presume) the US, "Southwest" appears to be the name of an airline. I was disappointed to find out this wasn't a puzzle to solve when only travelling in a specific direction, but still an interesting read.
Yes, that's standard data which is broadcasted to the passengers via the plane app/website. Usually the apps will have some "show position" feature where you can see position, speed, altitude, ETA, etc.
// This looks like info about the system's satellite internet connection.
"sat_commlink_portal": {
// The connection is okay!
"status": "conn_ok",
// I'm not sure what this time is.
// It hasn't changed at all.
"time": "Sun Sep 24 22:02:19 2023"
The "time" field could be the timestamp of when the status field last changed. That's the most obvious thought anyway. :)
Read this post while traveling on an ICE train. I decided to see if there was something similar in DB WiFi - and it turns out you can get two json files with current trip data. Here's a graph of the train speed for the last hour of my trip:
Pretty sure all these hacks and tips for getting free Wi-Fi aren't actually very legal. Sure the chances of getting caught are small, but you are also stealing connectivity someone else paid for by spoofing their mac address. Something, something, mucking about with an airliner even if its just the wifi could probably be twisted into some sort of federal aviation offense too.
When I was 13, I got a modem, and I would frequently call MeritNet lines to see how far I could get on the locked-down Lynx browser without a login, not having access to type in any addresses myself.
If I managed to get on an interesting page before I was eventually booted off, I won.
You can also get an SDR (a $50 RTL-SDR will do) and listen to your own plane's ADS-B signal. For visualization you can use tar1090. Private Flightradar24.
With the same SDR you can also listen to the ATC comms, as well as see ACARS messages. It's a bit tedious to listen to ATC and your own pilots, but you'll know exactly why your plane is delayed.
I'm not so sure. The same data packet claims that the flight has 2h 25m of flight time left to cover 1167 miles. That works out to 483 mph, which is pretty close to the stated 487 and might be explained by some padding added to the time to account for taxiing.
Unless that 1167 figure is in a different unit it doesn't even come close to working out at 487 knots ground speed.
The blog says the destination was Oakland. The Oakland International Airport is at 37°43′17″N 122°13′15″W. The data packet also contains the current lat and long of the flight as 40.201 and -100.755 respectively. Plugging that in to a distance calculator [2] gives 1163 miles, 1010.6 nautical miles, or 1871.6km. So the distance value of 1167 appears to be miles.
At 487mph covering 1163 miles would take 2.3963039014 hours or ~2h23m. If the speed is knots then it would be 2.08233112598 hours or ~2h5m at 560.4296mph. So mph makes the most sense given an estimated time of arrival of 2h25m.
So I think you are right, the distance appears to be miles and the speed MPH. This makes sense for an in-flight infotainment system on a US domestic flight.
The difference between 1167 and 1163 can probably be explained by the fact that the plane is 6.5 miles in the air traveling at 8 miles per minute and we don't know update interval or if the distance is in the air or on the ground.
I have been on (international?) flights where the in-flight display gave me a choice. It may still be done on the backend but doing that kind of conversion in the UI is at least arguable.
Your ground speed plot hovering around 500 mph would be ~800 km/h which is oddly slow for an airliner, unless you were facing strong headwinds the entire way.
The nautical mile is historically the common unit for marine and air navigation.
Knots are typically used for aviation. Also different planes have their own optimal speeds for efficiency that the airlines aim for so if you know the airframe you can derive what they are most likely targeting. You can also compare the value to the filed flight plan and see if it is similar.
Knots are used for aviation, but this data looks like it's being consumed by the in-flight UI, and most _people_ are not familiar with knots in terms of speed. Indeed, using the UI shows MPH vs. knots. My money is this speed being mph.
One reason I think it could be MPH despite that is because some of the other data seems like it's been processed so that it doesn't need to be transformed any further on the client side before using it in the UI, and the UI displays the speed in MPH.
If I were still on the flight, I could just compare the numbers in these payloads to the MPH number in the UI and confirm.
Based on the lat/long of your destination and the coordinates of the plane I believe the distance and speed actually are in miles and mph: https://news.ycombinator.com/item?id=37694487
Well, most airlines. I think both China and Russia already switched to SI units (so km/h), and supposedly ICAO recommends using km/h but there is exception for using knots and there is also no end date to stop using knots, so everyone just continues to use knots.
It's not that they 'already switched', but rather that early Russian aircraft had used the metric system for instruments and China acquired much of their early aircraft from the USSR.
In the West, it was well into the 50s before knots became conventional. Many (but not all) British and American aircraft used miles per hour, and most of non-communist mainland Europe used the metric system. I am not aware of whether there was some agreement to choose knots, but by the 60s almost all western aircraft had instruments in knots and nautical miles.
Yeah, if this were something that I wanted to leave running for more than the duration of a flight, I'd reach for cron, but a bash one-liner was perfect for this use-case!
We messed around on a recent KLM flight and what's interesting is that you get a DNS prefix of klm.com in DHCP (or some ms extension of it). The gateway has a name of www that allows you to access www.klm.com even though no name servers are accessible so DNS shouldn't work.
On many United flights you can connect to onboard wifi without buying the plan and have internet access on port 22 and apparently unrestricted UDP. This allows me to connect to an EC2 instance running mosh. Coding in vim is a great way to pass the time on a flight.
On one of the earlier flights with wifi, I found that my Google docs were saving correctly even though I didn't pay for the wifi upcharge. The router wasn't blocking those ports. It seems like this has changed recently. Too bad.
Bring a Stratus, Sentry or open source equivalent with and you can get that data for most other aircraft within line of site in real-time, along with weather, radar, pilot reports and more.
Inspect element (F12) > Network tab > when you refresh the screen check the header section to see the raw data. You can right click and copy curl or xor.
I used chart.js [0], but I don't necessarily endorse it - it's just what I knew how to use quickly. I usually try to keep my posts free from javascript, and could have used a different tool that gives me SVG data or images.
I used chart.js [0], but I don't necessarily endorse it - it's just what I knew how to use quickly. I usually try to keep my posts free from javascript, and could have used a different tool that gives me SVG data or images.
> I didn’t know what I’d do with the data at this point, but I started collecting it right away so that I’d have as much as possible to play with later.
And people complain that everything everywhere collects data on everyone.
I just took a look on my machine and the images are all loading in Firefox. If they're still not loading for you, would you mind sharing more info? Are you just getting 404s?
I'm not too concerned about the risk associated with fetching a JSON file that their flight status page is already fetching on a loop. That said, I'm curious what risks you have in mind.
Cybersecurity and internet crime laws are notoriously outdated (created in the 80s). I could see a bad lawyer arguing that cURLing an API repeatedly is “hacking”.
Another thing to notice: they use the highly nonstandard time zone abbreviation “PDT”. This works because they’re a US-only airline but if an international airline did this, they’d be in for a world of hurt.
Is it really "highly nonstandard"? I thought it referred to Pacific Time during daylight savings. The rest of the time being PST (Pacific Standard Time).
> Specifically, time in this zone is referred to as Pacific Standard Time (PST) when standard time is being observed (early November to mid-March), and Pacific Daylight Time (PDT) when daylight saving time (mid-March to early November) is being observed.
> Time zones are often represented by alphabetic abbreviations such as "EST", "WST", and "CST", but these are not part of the international time and date standard ISO 8601 and their use as sole designator for a time zone is discouraged.
> Such designations predate both ISO 8601 and the internet era; in an earlier era, they were sufficiently unambiguous for many practical uses within a national context (for example, in railway timetables and business correspondence), but their ambiguity explains their deprecation in the internet era, when communications more often cannot rely on implicit geographic context to supply part of the meaning.
Turns out PST and PDT are safe (no one else seems to use them) but something like CST is not: it could mean Central Standard Time (America/Chicago during standard time) or several other choices like China Standard Time (Asia/Shanghai).
They're not US-only (note that the response included a value for whether it was a non-US-including flight), but they are North/Central America/Caribbean-only.
"Oh no, not again..."
quoted from (not stolen, not infringing any copyright because of fair use) from The Hitchhiker's Guide to the Galaxy by Douglas Adams.
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.
This is probably the least-intelligent comment on this entire page. I would literally buy downvotes to bury this obnoxious stupidity into oblivion.
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.
Background updates are a built-in, supported, documented feature, widely employed by applications on the platform, and accessible to anyone that reads the two pages of documentation required to use them:
“Pushing background updates to your App — Deliver notifications that wake your app and update it in the background.”
They're using push notifications in a novel way to provide the app the necessary information to update itself without needing to be connected to the full internet. That's quite a bit beyond "They're using push notifications" and no other app does that AFAIK. Almost all will use the push notification as a notification and trigger an update on app open which would fail.
Give me one example, then. Of an app which uses a notification as an actual app data source and not just as a notification which opens the app. And which also updates the primary app view to reflect this new information.
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.
Podcast players like Overcast use push notifications to learn about new episodes of podcasts that should be downloaded in the background. Presumably text-based RSS readers do the same.
Where are the push notifications originating from? Does Overcast have a cloud service that polls the RSS feeds and then sends the notification? I use AntennaPod on Android, and it definitely doesn't do anything like that -- the feed list is stored locally, and the feeds are polled locally.
Slack/Discord/Teams? Those are desktop web applications hosted via Electron. Failing to leverage basic platform functionality is practically their telos.
It’s a trivial, documented, supported, long-standing API for a common use-case. It is widely used, as documented, for its intended purpose.
I cannot share information about specific applications.
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!
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 really think you’ve missed the point. Opening any of those apps after receiving the notification requires a network connection to then update. It’s not done via the push notification itself. I have never seen that happen in my experience. Flighty does, hence why it’s deemed clever.
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.
I don’t know what you have against Flighty but you through considerable lengths in the thread below to spend time on letting everyone know how unimpressed you are about their efforts.
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.
You’re right, I see that as embarrassingly trivial. This whole thread is inane — if using a simple API is “amazing engineering”, what do you call the actual amazing engineering you’re holding in your hand right now?
I have nothing against Flighty — this has nothing to do with Flighty. 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, unusual, or difficult.
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.
Overly-effusive praise doesn’t do anyone any favors.
I build AI/ML systems. I think delivering digital content through alternative pipes is amazing work. It has applicability far beyond simple aerospace wifi paywalls.
If you really think the folks here do this to save a few bucks, you both 1) don't realize what the average pay of people here is, and 2) are completely tone- and context-deaf.
Look at the domain name of the site you're posting on and read it out loud. FFS dude. LOL
Tomorrow it'll be 8 bucks to drink water, 8 bucks to use the bathroom, ...
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.
This seems like a poor slippery slope argument. It’s not as if charging for internet is new, it’s been what? 20 years? And yet they still don’t charge for water
Lufthansa, or Luftwaffe as I call them due to the... military kindness they often display.
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).
Not only that but at the Beijing airport there were no water refill stations and the bottle of water I bought at the airport POST-security was confiscated upon boarding. Fortunately I was boarding an airline with free water, though.
And public restrooms seem to be paywalled everywhere in continental Europe too -- not sure about the airlines, since I usually fly US carriers, but every restaurant or shopping mall I visited in Italy, Germany, and the Netherlands required a euro or so to enter the toilet. I've never seen a pay toilet anywhere in the US.
Checked bags, carry-on bags, and meals used to be free, and they are all now not free.
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).
I had to tell him not to do that, but I was kind of proud of him for having the temerity to go for it.