WiFi without internet on a Southwest flight
jamesbvaughan.com
jamesbvaughan.com
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.
nmap -sn 192.168.0.1-255
To find everyone on the network, then start spoofing each of their MACs until you find one that worksMAC 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.
https://serverfault.com/questions/462178/duplicate-mac-addre...
what happens depends on your LAN setup, but generally its a fail.
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.
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.
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.
In summary: it's fine.
I know Windows gets upset when that happens but the network seems to still work.
sync boot
I always wondered if there was a way to further exploit that.
In-room, you get free internet access, but in the windowless ballroom with spotty cell-service, there's nothing available for free.
"Follow the money"
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.
That's basic price elasticity of demand and entirely unsurprising. When something costs 10% more, people buy less of it in general.
We also buy more things priced at $99.99 than at $100.00, which is more of the psychological trick than it is rational price elasticity.
Hard to advertise to a wide audience when the final price after tax is one of 12 different prices depending on where they live.
I don't know of any US businesses other than waffle house that always include all taxes in the listed price, however.
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.
I think the norm is to show whatever price you want, with some countries banning that for fairly obvious reasons.
I just switched to my cell phone data if the wifi was too slow.
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.
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.
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.
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.
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.
Granted, being a NOC engineer at Wayport (now AT&T WiFi) certainly helped me understand how it all works.
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.
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.
at least they bothered to type something!
> 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.
[1] https://www.ietf.org/rfc/rfc9293.html#name-reset-generation
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.
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.
That makes me really reconsider my past struggles with this form of Internet access.
A multicast packet might vary based on physical distance to the imposter?
Because if that's a crime we're screwed because then it's illegal to read, or listen.
https://www.theverge.com/2021/12/31/22861188/missouri-govern...
https://github.com/aselvan/scripts/blob/master/macos/free_wi...
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.
[1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
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.
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.
Only works with IFE equipped planes, of course.
Though you could route around these problems, but giving them both a scannable code, and underneath some credentials as plain text they could type.
That way you'd at least have the protection of the WPA GTK.
It's not airtight, but better than the system it would be replacing.
PS: I'm a couch expert so I have no idea if there's a problem with this idea.
The user can go in and forget the open network of course, but most won't know to do that.
This hack just goes a step further to plot the data over time.
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.
Well, if he doesn't know there's anything wrong with it, it's not really temerity.
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!
20 years ago, all I saw were dual mono bayonet jacks you'd need an adapter for to plug in normal headphones, but straws would get you nowhere.
I was curious so I searched: https://simpleflying.com/inflight-entertainment-headphones-e... - pneumatic headphones from the 1960s were used on Delta as late as 2003, but electronic headsets debuted on 767 in 1982.
Apparently the dual mono jacks are to discourage people taking the headphones, rather than restricting access to audio.
This is generally in contrast to other instances of public Wifi.
Great time to have an Android device with hotspot handy. :)
Most laptops can't do this, right?
Maybe at the cost of latency because it has to switch channels back and forth?
> Most laptops can't do this, right?
Any laptop can do this if you plug a USB WiFi dongle into it :P
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).
[0] https://learn.microsoft.com/en-us/windows/win32/nativewifi/a...
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.
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 ;)
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="
May be too obscure though.
You told him off for such a small thing? You were impressed but didn’t give encouragement? You are a horrible parent.
It’s slow, but it works and is a handy “last resort” tool.
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.
(Although personally, I agree with the sibling comment that the variability is likely an artifact of the sensor resolution.)
btw: Aren't you the guy who tracks planes flying in circles? I follow you on Twitter. Such a cool project!
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.
[1] https://en.wikipedia.org/wiki/Localizer_performance_with_ver...
[2] https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System
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.
*edit: units
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.
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.
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.
You’re talking about getting different aircraft to agree between each other.
The post upthread expressed surprise at an aircraft maintaining a steady altitude to within tens of feet. That’s been a thing for many decades.
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.
"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.
edit: trying to improve clarity/correctness but there is too much to cover here.
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.
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.
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.
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.
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.
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.
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 :-)
$ curl https://wifi.delta.com/api/flight-data | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 448 100 448 0 0 5600 0 --:--:-- --:--:-- --:--:-- 5743
{
"timestamp": "2023-07-11T14:54:41Z",
"eta": "17:48",
"flightDuration": 278,
"flightNumber": "DAL786",
"latitude": 39.723472595214844,
"longitude": -97.1514205932617,
"noseId": "3879",
"paState": false,
"vehicleId": "N879DN",
"destination": "KPDX",
"origin": "KATL",
"flightId": "N879DN_SF_20230711121358",
"airspeed": null,
"airTemperature": 24,
"altitude": 33922,
"distanceToGo": 179,
"doorState": "Closed",
"groundspeed": 442,
"heading": -73,
"timeToGo": 174,
"wheelWeightState": "Off"
}
And a fun snippet for you. $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=", .latitude, ",", .longitude' | tr -d '\n'; echo
https://maps.google.com/?q=40.5615234375,-101.2824478149414apologies for joking. it must suck.
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.
(I guess there's some kind of firewall, but we know that those are not always perfect)
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.
That would prevent any need for direct connection between the systems.
Is that how it works? I doubt it. But it could be done.
1: https://www.tsb.gc.ca/eng/rapports-reports/aviation/2020/A20...
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.
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.
$ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"' Invoke-WebRequest https://wifi.delta.com/api/flight-data | ConvertFrom-Json | %{ "https://maps.google.com/?q=$($_.latitude),$($_.longitude)"Presumably a train's groundSpeed and airSpeed are the same. If they diverge you have bigger problems than a JSON schema.
Is there a variant of this for ships? surfaceSpeed vs seaFloorSpeed?
[nervously looks out window]
Similar to how I can log into my ASUS router from my home wifi by visiting asusrouter.com.
I’m on a flight right now and just went to this URL. Sure enough, it works!
I know this information is available via the wifi portal’s UI, but a JSON blob just hits different.
```
{"timestamp":"2023-09-28T21:57:39Z","eta":"23:45","flightDuration":164,"flightNumber":"DAL992","latitude":47.4557876586914,"longitude":-111.73490905761719,"noseId":"3883","paState":false,"vehicleId":"N883DN","destination":"KMSP","origin":"KSEA","flightId":"N883DN_SF_20230928195737","airspeed":null,"airTemperature":null,"altitude":35273,"distanceToGo":13,"doorState":"Closed","groundspeed":499,"heading":95,"timeToGo":107,"wheelWeightState":"Off"}
```
Apologies for the JSON formatting, I’m on mobile.
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.
Would this be related to DNS?
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?
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.
I chose to scrape it for a couple reasons:
1. I wanted see all of the data for the entire flight - that status page only visualizes the current values.
2. It was fun!
(US Civilian GPS units are prohibited from working above 60,000 ft above sea level and 1,000 knots due to ITAR munitions export restrictions.)
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 have GPS Test[1] on my Android - it's pretty neat to launch it while on a flight - seeing the speed in realtime is pretty fun.
[1] https://play.google.com/store/apps/details?id=com.chartcross...
https://www.flightaware.com/live/flight/SWA2340/history/2023...
So while I believe the data source is the same, one can see quantization artifacts when comparing both signals.
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.
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).
Interesting data like Accelerator Handle position, you can figure out how much a rider is really cranking it, and how aggressive they are riding.
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.
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.
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.
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.
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.
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'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.
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 sure about my backside.. don't do squats lol ... 5'10 170
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!
I just did it for fun, ok fine.
I think I even made a script in lua to do it automatically
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.
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.
I remember DRM breaking multiple times for the IFE because they assigned the same IP to multiple devices.
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.
Here's an example of it happening to someone else: https://community.southwest.com/t5/Inflight-Experience/Fligh...
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.
As soon as I activated the "Free Messaging" service, I got a bunch of notifications from my Apple Home and Google Nest devices.
And the WiFi essentially has to allow the Apple push notification system entirely in order for iMessage to work fully the way people expect.
So it's really a side effect. But yeah for example with the free iMessage connection on Southwest, I can see all the notifications come in on Discord, but of course I cannot connect within the discord app to actually load all those messages. I can only read them as they come in as push notifications.
Have to? Isn't there an option to send 'offline' notification? I mean, coming from the app itself, rather then external callback? With that, app could ommit the official way of using Apple Push service, no?
So sure, an app can generate a notification popup itself, but it's pretty limited as it won't be able to generate a notification after being backgrounded for more than 10 minutes.
And the 10 minutes is also only if the app is designed to extend the duration as long as possible. Normally it would get cut off after 1 minute.
So because of this it seems that in the vast, vast majority of cases apps choose to send their notifications from the Apple Push notification service.
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)
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 feel like it would need to work like Opera mini to maybe be usable. Even then interactions would be uncomfortably slow.
I always appreciated the hack, even though I could never bring myself to use it due to the obvious cache pollution problem on the various DNS servers.
I guess it's Flighty (https://apps.apple.com/us/app/flighty-live-flight-tracker/id...)
I love that people are into this. In the days before iPhones, I had "Microsoft Streets and Trips" + a USB GPS unit + Laptop. It was fun having it on a flight and seeing movement data in realtime. It was less fun answering questions from people who thought looking at the GPS data was somehow nefarious.
Streets and Trips was fun on a laptop for long car drives as you could live reroute in the car much like any old app can do these days but seemed somehow magical back then.
My kid liked to suction cup his GoPro to the window to take a time lapse movie of the flight and one FA told him he had to take it off the window because he was, and I quote: "modifying the structure of the aircraft and that's not FAA-approved".
"Another consideration, in the case of this type of equipment, is the applicability of the term "alteration". FAA Order 8110.3 7E, defines an alteration as "a modification of an aircraft from one sound state to another sound state". The use of suction cups, or other temporary methods of attachment (not including permanent mechanical attachments to the aircraft), would not be considered a modification to the aircraft."
https://mypilotpro.com/wp-content/uploads/2020/05/FAA-Camera...
But still, the aircraft is the the airline's property, not yours. If they tell you not do something to it, you don't get a choice in the matter.
That memo is about attaching it externally. Attaching it to an internal window is probably a non-issue.
I once had a security agent ask me to prove a GoPro was a camera because they didn't understand how there could be no screen or viewfinder. It was most frustrating because this was an area where they would have encountered it many times (lots of scuba divers).
Way before cellphones, I'd bring my 2m radio on the plane and make contacts on simplex. That was fun to throw your callsign out and say "aeronautical mobile".
https://developer.apple.com/documentation/usernotifications/...
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.
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.
However, even with reasonably strict neutrality, this is still possible. Many mobile carriers zero-rated streaming services here, but unlike your operators they'd do it for any streaming service. It was pretty easy for any streaming provider to sign up. They'd basically give the operator the IP ranges they'd be streaming from and the operator would just zero-rate data to those IP ranges (and they'd usually apply bandwidth throttling to around 1.5Mbps so that you'd only get 480-720p video). The key is simply not discriminating between providers within a category.
The rules primarily target ISPs selling directly to customers.
I usually keep it off otherwise though because average bandwidth tends to be better on LTE in my experience.
> 52. Finally, we decline to apply our rules directly to coffee shops, bookstores, airlines, and other entities when they acquire Internet service from a broadband provider to enable their patrons to access the Internet from their establishments (we refer to these entities as “premise operators”). These services are typically offered by the premise operator as an ancillary benefit to patrons ... Although broadband providers that offer such services are subject to open Internet rules, we note that addressing traffic unwanted by a premise operator is a legitimate network management purpose. [0]
It seems like a reasonable distinction: if you're letting someone else use your Internet connection, it's your prerogative to block things that you don't want on your network.
- [0] https://docs.fcc.gov/public/attachments/FCC-10-201A1.pdf (page 31)
- 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.
Flightaware.com also works, presumably because Alaska uses Flightaware for its tracking map.
Unfortunately, I couldn't get it to load on my Alaskan flight a few days ago on the free messaging plan. Maybe they've changed it
If so, that would be the easiest, Telegram has a really good bot API.
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 tried it on a trip to Tokyo and immediately got completely blocked. It took me a few minutes to figure out they'd blacklisted my MAC address. I changed the MAC of that interface and then behaved.
I think I had to use Shadowsocks or something at the end to completely bypass it.
That said, technically there's two pretty easy ways to do it for WhatsApp traffic, and then there's the way I suspect they're doing it...
a) chat runs on different ips than attachments; always has, most likely always will (other than some transitional HAProxy at the old hosting when nearly everything had been moved to the new hosting).
b) WA chat is not HTTPS (or even TLS) and attachments are. Chat also cycles between different ports, so you could just block port 443 and be good.
c) I actually suspect, based on poking around a little that it's mostly just killing connections that use a lot of data. Maybe in combination with some other things. Being on a plane doesn't really put me in a debug the network kind of mood, so I never got to the bottom of it, but I'd regularly be able to make short connections to my home network while on the messaging plan, at least when this stuff was new. OTOH, I think I recall being able to connect through the WA VPN while on a plane on the messaging plan, but that was when we had a publicly available, but not publicly linked list of IP addresses on our website; I have no doubt that DPI vendors had that list.
If you don’t mind, could you expend on this? Are there specific reasons to not be using TLS?
I wasn't much involved in anything on the chat channel, and I didn't do any implementation work on Noise, but I did some later prototype work with it, and if I recall correctly, it had much simpler framing than TLS as well; although maybe that was mostly TLS options getting me down --- the SNI header has 9 bytes of overhead, 5 of which are lengths, Noise didn't have anything like that as I recall. Do you really two bytes of versioning on every application data packet, like TLS has? I'm not sure you really need a type indicator byte either, context says you're sending a handshake packet initially, and then application data after that, but I'm pretty rusty on this now, so maybe there's a justification.
For users paying for internet by the byte, every byte counts. For users on networks with large delays, every round trip counts. For attachments, it's less critical (if your data access costs were high, you could configure attachments not to load) and that infrastructure was always built around http(s), so while there would have been an efficiency improvement to move that off https, it would be hard to justify the engineering time; especially post the move to FB infrastructure with its CDN that was easily configured for our attachments. OTOH, chat never ran on TLS, so adopting Noise vs adopting TLS was a choice we could consider, and we picked the best solution for us. Unfortunately, it's pretty easy to identify Noise vs TLS --- OTOH, the service IPs are already identifiable, so a little more blending on the protocol level wouldn't help much.
[1] https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...
[2] Also using system TLS libraries is fraught with peril. It's fine, but not super great, for http, but using it for a custom binary protocol is going to be terrible. You'll need to debug all of the edge cases that the system https library doesn't hit, and will then have to craft workarounds that just work, even if you can't reliably identify the underlying versions because Android OEMs do weird stuff.
The why was because of trust store issues. Every device has its own built in trust store, and especially on devices like TVs and DVD players, they couldn't be updated. After looking at all the devices we supported, there was no common certificate signer amongst all of them.
This meant that we would either have to get multiple SSL certs signed by different parties (some of which weren't all that secure) and present the right one depending on your device type, or we could just roll our own over HTTP. So we chose the latter.
Of course, there's not really very useful client identification in the TLS Hello, so you have to kind of guess who needs what. If we had to use different CAs for different clients, it would have gotten a lot harder, because it's not like we could rely on clients filling out SNI either. So then you need to get more ips for each service. I do recall needing to do that a little, but we only needed a single 'legacy' group that was useful for everything that couldn't manage the modern certs.
Was creating your own certificate authority and pinning it in the app not an option?
I wonder if TCP over ICMP would work better.
How Airline WIFI allows Texting but not Media in WhatsApp/iMessage
1. Open browser with iOS user agent and ios sized h/w. 2. Click on t-mobile free wifi link 3. Enter _any_ t mobile number you may know.
These days you can passthru your WiFi or even a wired connection (via USB to a connected PC or a Ethernet-to-USB adapter) via a Hotspot.
https://docs.gl-inet.com/router/en/3/setup/gl-e750/internet/...
My iPhone does not.
Cheap Chinese android phone from 2020 (or maybe 2021 can't remember).
[0] https://documentation.meraki.com/MR/Monitoring_and_Reporting.... This basically detects any access points in a wireless network repeating a signal and automatically boots them. only works on 2.4GHz networks if I understand correctly.
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.
Also, KDE Itinerary: https://invent.kde.org/pim/itinerary/-/blob/master/src/app/S...
I'm off pinging the relevant projects :)
Once made a little React app that showed the train on a Leaflet map. Was a good waste of a few hours.
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.
// 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. :) km/h ice train speed
160 +----------------------------------------------------------------------------+
| + + + + + ** + |
|* ** |
140 |*+ ** +-|
|* ** |
|* ** |
120 |*+ ** +-|
| * * * |
| * * * |
100 |-* * * +-|
| * * * * |
80 |-* ** ** * ** +-|
| * ** *** * * |
| * ** * ** |
60 |-+* * ** * ** +-|
| * **** * ** * ** |
| * * * * * * * |
40 |-+ ****** * **** ** * * +-|
| ***** * **** * ** |
| * * * * ** |
20 |-+ * * * * ** +-|
| * * * * ** |
| + * * * + + + *+ * + |
0 +----------------------------------------------------------------------------+
0 50 100 150 200 250 300 350
countIf I managed to get on an interesting page before I was eventually booted off, I won.
Tided me over until I actually got to use an ISP.
The code is horrendous but it has worked for years and I guess when I wrote it originally I didn't want to use a go struct for some reason?
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.
edit: Updated the article. Thanks!
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.
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.
The nautical mile is historically the common unit for marine and air navigation.
https://www.metric-conversions.org/speed/knots-to-miles-per-...
487 knots would be 0.73 Mach which is much closer to the rule of thumb 0.78 Mach cruise speed expected.
https://krepelka.com/fsweb/learningcenter/aircraft/flightnot... (and yes, it's a simulator but it's still good for real world)
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.
[1]: https://geohack.toolforge.org/geohack.php?pagename=Oakland_I...
[2]: https://www.omnicalculator.com/other/latitude-longitude-dist...
The two units are confusingly close to each other though.
I often use crontab, but this looks easier for testing. Thanks.
You can see the code that's generating these charts here: https://github.com/jamesbvaughan/jamesbvaughan.com/blob/main...
WiFi without internet on a Marabu flight https://marx.wtf/2023/09/30/wifi-without-internet-on-a-marab...
You can see the code that's generating these charts here: https://github.com/jamesbvaughan/jamesbvaughan.com/blob/main...
And people complain that everything everywhere collects data on everyone.
Fun research!
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.
Overzealous prosecutors.
The in-flight webpage was continuously fetching a specific end-point from the in-flight web server.
This end-point is basically public data.
All he did was duplicate what the webpage was already doing, and then do some basic analysis on the data the end-point was returning.
http://www.timezoneconverter.com/cgi-bin/zoneinfo.tzc?s=defa...
Granted, I think everything should always be a UTC offset, but I'm also weird.
https://en.m.wikipedia.org/wiki/Pacific_Time_Zone#:~:text=Sp....
What do you think is the correct format?
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.
https://en.wikipedia.org/wiki/Pacific_Time_Zone# https://www.timeanddate.com/time/zones/
> 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.
https://en.wikipedia.org/wiki/List_of_time_zone_abbreviation...
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).
Ambiguity is bad.
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.”
https://developer.apple.com/documentation/usernotifications/...
edited for politeness
What’s the relevance?
Push notifications aren’t some odd “alternative pipe” and conveying data via push notifications is a known and supported use-case.
It’s also the trivial, obvious approach to anyone who asks the question “how can I push data to the application when it’s not running.”
No other app has updated its app state based on the content of notifications. Slack/Discord/Teams et al (the ones that aren't allowed on free messaging plans) will show you previously cached messages and then an infinite spinner when you open it. Fastmail/Gmail/Outlook et al will show you existing emails but not load the new ones.
Could other apps do this? Surely. Do they? No.
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.
Do you genuinely believe it’s uncommon for applications to leverage this useful, trivial, long-standing platform API for its intended and explicitly documented purpose?
I can’t imagine why you’d believe that, but another commenter already provided the requested single example up-thread.
> I cannot share information about specific applications.
So you don't have an example of an app using such a basic and widespread feature? Ok.
You’re the one with an extraordinary claim here — that applications aren’t using such a basic, documented, widespread feature.
It’s patently silly and I have no idea why you’re so self-assured in your ignorance.
Background notifications can and do carry arbitrary application data, and are used to update the application state in the background.
This is their intended purpose, it’s what they’re documented to do, it’s how Apple intends them to be used, and it’s common application behavior.
This is literally a plainly documented feature of the platform. It’s not clever or unique or unusual — it’s a simple feature that Apple specifically documents.
I cannot even begin to fathom why people are confused about this, and it’s truly mind-boggling that this has required a thread at all.
Slack/Discord/Teams are non-native applications that do not leverage the platform’s support for updating application state via notifications. That does not mean the use of background notifications is unusual or rare. It is not.
Your lack of amazement is duly noted, I suggest you don’t waste any more time on it.
That said, I, like others, are indeed impressed for a couple of reasons.
For starters because of the simple fact that they’ve found a novel way to use background notifications to provide users without unrestricted internet access with flight updates.
Contrary to what you imply, and subsequently fail to substantiate, there aren’t many, if any, other apps that use background notifications in such a novel way, certainly not in a way to circumvent restrictions and limitations on data connections.
Moreover, I have never seen background notifications being used to push concrete data to apps. This is because there are severe payload size constraints on notifications, including background notifications.
Typically when background notifications have been used, it simply contains an instruction to download data from a remote server, something that wouldn’t work on a limited connection.
Instead, Flighty uses the minimal payload size to push the actual concrete data used by the app.
Additionally there are some limitations in how often a background notification gets delivered to the tune of a few times per hour, worse yet, delivery of these notification is inconsistent because it’s beyond the app’s control of they get delivered at all.
To account for this, Flighty will use the background notifications to update the data where it can and make estimations in times it cannot not until the next time it can receive an update.
I’d go as far as call that amazing engineering.
You might not and I don’t know your qualms with Flighty, but you’re doing a poor job of convincing people to see it your way.
I have nothing against Flighty — 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.
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.
Was quite shocked.
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).
There are budget airlines outside the US that are charging for water (which I think is unethical IMO, since people avoiding drinking water could lead to an increase in medical emergencies).
Look at the domain name of the site you're posting on and read it out loud. FFS dude. LOL