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.
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.
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.
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.
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.
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.
I wonder if they just do some rudimentary packet inspection and drop packets above a certain size. My thinking being that short text messages result in very small packets, while large images will result in many large packets. Dropping large packets is most likely OK. I'd need to test this hypothesis by sending a very large text message (resulting in many large packets)
I'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.
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’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!
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 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.
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 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".
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
- 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 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.
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.
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.
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 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 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.
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 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.
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.
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.
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.
Yeah I recently found this out. It never really did work that well, I did manage to telnet into an SMTP server and manually send an email but for anything else it struggled.
I 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.
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!
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.
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.
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.)
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.
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.
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.
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 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 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…
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 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?
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 ;-)
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.
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.
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.
> 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).
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.
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.
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.
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.
> 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
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.
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!
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.”
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.
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.
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.
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.
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.
"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.
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
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.
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).
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).
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
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.
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.
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]
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
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.
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.
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'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.
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”.
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.
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.
673 comments
[ 7.9 ms ] story [ 368 ms ] threadInteresting 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.
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.
https://en.m.wikipedia.org/wiki/Opera_Mini
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.
https://www.rfc-editor.org/rfc/rfc2549
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?
https://github.com/yarrick/iodine
I wonder if TCP over ICMP would work better.
How Airline WIFI allows Texting but not Media in WhatsApp/iMessage
https://www.youtube.com/watch?v=AYSxxO2yZp8
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.
[1]: https://github.com/NalinPlad/OuterFlightTracker
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.
https://news.ycombinator.com/item?id=37693293
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...
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.
https://cplusplus.com/reference/ctime/ctime/
(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...
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)
https://www.flightradar24.com/data/flights/wn2340#322ad9f6
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.
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.
https://github.com/aleixrodriala/wa-tunnel
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.
https://analogbit.com/software/tcp-over-dns/
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.
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.
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!
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.
Just take any adhesive label off of the "clearance" meat at the supermarket, and apply it to the cut you wanted to buy. Instant savings!
https://www.youtube.com/watch?v=HmZm8vNHBSU
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.
There's a significant contextual, moral and ethical difference between "exploring a lock" and "opening it and stealing whatever it's holding from you".
Also, you're another one who apparently needs to read the domain name of this site aloud to yourself again.
How much will you pay me to delete it? I can send you an Ethereum address.
Yeah, you can argue internet isn't a necessity. Neither is the bathroom, you can use a poo bag and a diaper. But we're a civilized society. So we provide bathrooms to anyone that needs them. And internet access.
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
https://simonwillison.net/2020/Oct/9/git-scraping/
apologies 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)
[1] https://www.wired.com/2008/01/dreamliner-security/
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...
2: https://www.youtube.com/watch?v=nj7nG6gJqsU
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.
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]
https://xkcd.com/2170/
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.
Once made a little React app that showed the train on a Leaflet map. Was a good waste of a few hours.
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.
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.
https://na.panasonic.com/ca/industries/avionics