No, the fact that all of these ships show the same false location strongly suggests that they are being spoofed from a single terrestrial source; this effect is not practical to achieve by modifying the signals transmitted by the satellites, even if the US wanted to for some reason.
> making everyone appear at exactly the same location would be nigh-impossible, though.
I don't think this is actually the case. In a spoofing scenario, all of the rogue signals would typically be generated by a single terrestrial station. The time of flight of all of the generated signals will be the same, so all that matters is the position solution reflected in the transmitted signals, as the fundamental principle of GPS based on TOF is no longer in play. So I'd think that in a typical spoofing scenario, all receivers thinking they're in more or less an identical location is what you'd expect.
It might be possible in a borderline case for the receiver to receive some spoofed signals and some real signals simultaneously, in which case you'd expect weird results, but I think you'd definitely see a correlation around the position being broadcast by the spoofer.
You're more or less inside a Faraday cage. I find you'll generally get a strong lock just holding your phone near the window, though TTFF can be relatively slow compared to normal due to the lack of AGPS.
Nobody remotely versed in this stuff would expect SMS to be end-to-end encrypted, though to be honest the more notable fact to me here is that Apple can read any plaintext in your backups. iMessage is an over the top messaging service more akin to WhatsApp or Signal than it is to SMS, so that is a more relevant comparison. I don't know if any of the clients store plaintext messages that would be backed up to Apple in a similar manner or not, but I'd hope at least the more security focused ones do not.
Apple makes privacy claims about iMessage including 'Apple can’t decrypt the data.', which is notably false in this (common) scenario, and requires a large asterisk on those claims, IMO bordering on making them unethical, period.
> At the end of the day, if the person who wrote that software had written it differently, then those planes would not have crashed and hundreds of people would not have died.
You can't really blame the software engineers. This was all thought out and tightly specified by Boeing to their avionics subcontractor (Collins, IIRC). This is how it was designed and engineered to work at a systems level - it is a design hack. As far as I know there weren't any software bugs or 'hacks' involved, and the avionics operated as designed (aside from the AoA DISAGREE alert, which was due to a requirements miscommunication, not a bug). It was broken by design, which happened long before implementation, at Boeing.
> When the flight computer trims the airplane to descend, because the MCAS system thinks it’s about to stall, a set of motors and jacks push the pilot’s control columns forward. It turns out that the Elevator Feel Computer can put a lot of force into that column—indeed, so much force that a human pilot can quickly become exhausted trying to pull the column back, trying to tell the computer that this really, really should not be happening.
The Elevator Feel Computer is a part of the 737NG as well, and would behave the same way in those airplanes when receiving such erroneous AoA data; it's nothing new in the MAX. It certainly did not help the crews during the fatal MAX incidents, and is clearly not an ideal design, but it's also barely a footnote in the root cause analysis, along with the stick shaker and stall warnings blaring at them constantly. The pilots would easily be able to overcome it long enough to get safely on the ground. What was a bigger problem for those crews was that the MCAS has enough trim authority to make it impossible, with any amount of elevator input, to restore level flight - limiting its trim authority was part of the 'fixes' required to get them airborne again.
I don't think it's reasonable to blame the implementation of MCAS for the accidents, its existence is to blame, and really highlights how nothing about the 737 platform has been designed holistically - it is a patchwork of hacks on hacks dating from the 1970s, which is difficult to reason about as a whole, and has dark corners. To truly 'fix' MCAS, you need to consider AoA as critical air data (which the 737 does not), and you need to integrate it holistically with the rest of the flight controls (which the 737 cannot, since it is not fly-by-wire), and you need to consider it critical equipment (it's an 'augmentation' and not considered critical on the 737, 'justifying' the lack of redundancy). Once you've done those things, you've basically got the bones of a proper envelope protection system in place, and you've obviated the need for MCAS in the first place. Of course the 737 team couldn't do this, because the business decided that it was more important to avoid (and hide) any differences than to bring the aircraft in line with modern standards.
Realistically, this should have been trapped by the safety analysis of the flawed design, which should have considered its effect on the whole flight control system when evaluating it, but Boeing again only considered MCAS to be an 'augmentation' and it got an abbreviated safety review as a result. Some engineers did express concern about some of these factors, but given the environment outlined in TFA, those concerns did not go anywhere, because they would have basically scuttled the idea and sent everyone back to the drawing board, which Boeing was desperate to avoid having already been caught flat-footed with the launch of the A320neo.
The 737 airframe needs to be put to rest, it is simply not safe or sane to keep stacking more hacks onto it. But there's no indication Boeing's working on a successor so it's probably going to be on the market for another 20+ years. Hard to imagine folks will probably be flying on an airframe with a 100 year old design (2024 + 20 years before a new revision + 20 years life span = 2064, around 100 years from the 737 launch before they start retiring)!
As the pilots of the doomed Boeing jets in Ethiopia and Indonesia fought to control their planes, they lacked two notable safety features in their cockpits.
One reason: Boeing charged extra for them.
For Boeing and other aircraft manufacturers, the practice of charging to upgrade a standard plane can be lucrative. Top airlines around the world must pay handsomely to have the jets they order fitted with customized add-ons.
Boeing’s optional safety features, in part, could have helped the pilots detect any erroneous readings. One of the optional upgrades, the angle of attack indicator, displays the readings of the two sensors. The other, called a disagree light, is activated if those sensors are at odds with one another.
Boeing will soon update the MCAS software, and will also make the disagree light standard on all new 737 Max planes, according to a person familiar with the changes, who spoke on condition of anonymity because they have not been made public. Boeing started moving on the software fix and the equipment change before the crash in Ethiopia.
The angle of attack indicator will remain an option that airlines can buy. Neither feature was mandated by the Federal Aviation Administration. All 737 Max jets have been grounded.
“They’re critical, and cost almost nothing for the airlines to install,” said Bjorn Fehrm, an analyst at the aviation consultancy Leeham. “Boeing charges for them because it can. But they’re vital for safety.”
“There are so many things that should not be optional, and many airlines want the cheapest airplane you can get,” said Mark H. Goodrich, an aviation lawyer and former engineering test pilot. “And Boeing is able to say, ‘Hey, it was available.’”
But what Boeing doesn’t say, he added, is that it has become “a great profit center” for the manufacturer.
The three American airlines that bought the 737 Max each took a different approach to outfitting the cockpits.
American Airlines, which ordered 100 of the planes and has 24 in its fleet, bought both the angle of attack indicator and the disagree light, the company said.
Southwest Airlines, which ordered 280 of the planes and counts 36 in its fleet so far, had already purchased the disagree alert option, and it also installed an angle of attack indicator in a display mounted above the pilots’ heads. After the Lion Air crash, Southwest said it would modify its 737 Max fleet to place the angle of attack indicator on the pilots’ main computer screens.
United Airlines, which ordered 137 of the planes and has received 14, did not select the indicators or the disagree light. A United spokesman said the airline does not include the features because its pilots use other data to fly the plane.
When it was rolled out, MCAS took readings from only one sensor on any given flight, leaving the system vulnerable to a single point of failure. One theory in the Lion Air crash is that MCAS was receiving faulty data from one of the sensors, prompting an unrecoverable nose dive.
In the software update that Boeing says is coming soon, MCAS will be modified to take readings from both sensors. If there is a meaningful disagreement between the readings, MCAS will be disabled.
Yes, this was the root of the miscommunication. The AoA indicator (ie. an instrument that gives a numeric value of AoA to the pilots) was optional. The AoA disagree alert (ie. an indication that the two AoA sensors do not agree) was not intended to be optional, and I believe it's required equipment, but it ended up tied to the indicator option. What is worth noting about this is that Boeing knew about it for a long time (I forget the timeline, but at least a year, I believe), without telling airlines or releasing a fix.
> Boeing has publicly blamed its software supplier, a company now known as Collins Aerospace Systems, for tying the AOA Disagree alert, which was supposed to be a standard feature on all 737 MAX aircraft, to an optional AOA Indicator display714—the result of which rendered the AOA Disagree alert inoperable on more than 80 percent of the MAX aircraft.
There've been so many issues it's definitely getting confusing, but the thing blocking the MAX10 certification is a problem with the engine anti-ice system.
You're correct that this problem exists on all MAX variants, but those other variants are already certified (the issue was discovered post certification), and it's deemed to be not severe enough / with a good enough mitigation that they are allowing Boeing some time to come up with a fix for the already-certified design, and continue producing it. The expectation is that once Boeing has a proper fix and retrofit plan, it will be required by an AD on all aircraft. However it's unlikely the FAA will certify the new MAX10 variant with this known issue, and so far Boeing doesn't have a fix.
It shouldn't be that bad, CloudFlare's anycast should direct you to a nearby resolver, and doing your GeoDNS on that resolver IP instead of ECS is probably not that much worse than doing it on the actual client IP. Both approaches aren't great at picking an ideal CDN node, GeoIP is notoriously unreliable, and it tells you nothing about network topology.
Breaking DNS entirely is much worse behaviour, especially because GeoDNS itself is arguably not in the spirit of DNS which is distributing a consistent database, not making it up on the fly based on the client's info. The archive.is admin is being ridiculous, the least they could do is block anyone not using a resolver supporting ECS to be consistent, but no they have something personal against Cloudflare.
I occasionally click on Sponsored search results, if they're what I'm looking for and I don't much care for the company on the other end of the link. Take that, Big Corporate!
It can't be mutual because the receivers don't broadcast, so the sender doesn't know which contacts are in range.
I was also thinking you might be able to use asymmetric crypto for this, and encrypt the hash + a nonce using your private key, and anyone with your public key can decrypt it and check the hash against the contact list. But this means the potential receiver needs to decrypt with every public key it knows, which for large contact lists might be prohibitively expensive.
Someone has probably devised a more clever way, though.
Fundamentally this verification is based on your contact list, which is formed from people you already know and have added to your contacts, so there's not really any need for a centralized trust. Presumably you trust the e-mail address of the contact you added, and the federation protocol could easily define how the authoritative hash/key for each user would be shared based on their e-mail.
In most cases this could also be resolved at first contact in meatspace, directly between the devices when establishing contact via the typical ways users share contact information - QR code or some form of short range networking, or even with an SMS challenge.
Really? It doesn't seem to me like it gets any more trivial than 'hit DNS for the domain to find federation server, send a GET request' to me. You could even do the whole thing with DNS, though that has privacy implications. What am I missing?
There's a report on very similar jamming happening during the Syria conflict that will hopefully be enlightening as the methods and actors are presumably similar https://c4ads.org/wp-content/uploads/2022/05/AboveUsOnlyStar...