- The stick-and-rudder skills aren’t hard and not the main reason people die. It’s the decision making that kills.
- The “faster to fly” than drive for me starts at about 3 hrs drive (wind, preflight time, takeoff / climb / landing time, deviations by ATC, etc). My indicated airspeed is roughly your true btw.
- Looks and feels like Cirrus with AI. I am missing barn doors for luggage and dogs; 200 kts cruise; 6 hrs with tip tanks; and gross to actually do it. I’ll stick with my Bonanza.
- Main problem you will face is insurance. It will be expensive if even obtainable for low experienced pilots.
For future inflation. It was relatively low between 2010 and 2020 and has been reducing at a fairly fast pace recently. It’s not obvious it won’t go back to the baseline.
If we assume that server is “evil” then the server can store both PIR encrypted and plain text phone number in the same row in the database and when this row is read, simply log plain text phone number. What do I miss here? We can send PIR request and trust server not to do the above; or we can send plain text phone number and trust server not to log it — what’s the difference?
A very simple PIR scheme on top of homomorphic encryption that supports multiplying with a plaintext and homomorphic addition, would look like this:
The client one-hot-encodes the query: Enc(0), Enc(1), Enc(0).
The server has 3 values: x, y, z.
Now the server computes: Enc(0) * x + Enc(1) * y + Enc(0) * z == Enc(y).
Client can decrypt Enc(y) and get the value y. Server received three ciphertexts, but does not know which one of them was encryption of zero or one, because the multiplications and additions that the server did, never leak the underlying value.
This gives some intuition on how PIR works, actual schemes are more efficient.
[Disclosure: I work on the team responsible for the feature]
In this PIR model the server has to read the whole database, otherwise it would be easy on the server to see, that these rows were not accessed and therefore they are not the one the client queried.
In this PIR model the server runtime is O(n) where n is the number of rows.
To keep it practical, we do support sharding the database. Client leaks a few bits of hashed query to pick the right shard, where we process the entire shard. There is a inherent privacy-performance tradeoff: less shards = less leakage vs more shards = better performance & less privacy.
I think OP is talking about the set of “spam phone numbers” stored on the server and looking at side channels based on what data is looked up by processing the query.
Not sure if its implemented exactly like this but one could imagine that the server must use the client's public key to encrypt the database into a blob it can't decrypt. The encrypted input is used to read the encrypted blob in a way the server can't understand to construct a result the server cannot understand. The result blob is sent to the client which can decrypt it.
Yeah but as I wrote elsewhere, the DB isn’t a KV store of plain text numbers and their encrypted representation. Instead the entire database would be encrypted and you’d do set containment operations in encrypted space which wouldn’t /couldn’t leak anything about your query (modulo unexpected side channels in the design).
I don’t know how they do this efficiently and at scale with lots of updates, but maybe this database is kinda small to begin with anyway and the updates are reasonably cheap to process relative to how many spam numbers are out there.
That could only work if the server didn't have its own database copy. Not sure how a client would be able to provide the server with a database encrypted by the client.
If the server can decrypt it, it's not really safe if you're assuming server is evil
The database isn’t secret here. The server indeed has its own copy - it would have to otherwise what is the client query resolving against. What’s secret is which phone numbers are contacting the client. So instead of sending the phone number to the server, you send an encrypted version of the phone numbers. This encrypted version is then checked against the encrypted database. This prevents the evil server from discovering the phone number the client is checking.
If you read the docs, a perfectly valid implementation is an HTTP request that sends the unencrypted database to the client which then checks the numbers locally - it achieves equivalent security priorities. The advantage here is that the database can be large enough to make distribution less practical than just doing a lookup per number and that’s where the HE comes in.
Remember: evil in a security context means someone trying to actively circumvent your protection guarantees, but you’re making an assumption that the database needs to be secret when it may not as the privacy and security guarantees are about the client’s information. Apple isn’t necessarily saying the database is secret since it’s just “this phone number is likely spam”. Of course, it’s possible that the server itself can’t even generate a valid query. It’s possible Apple designed it such that the query has to be generated on a valid Apple device to begin with (since it has a chain of trust to each device manufactured).
That’s not what I saw in the code but I didn’t spend much time so I might be wrong. I’ll check it more carefully later. But if this indeed is whole DB then it’s very limited use case.
It’s a lot more complicated because the phone numbers themselves are stored encrypted and there’s not a 1:1 mapping between encrypted representation and the mapping. So processing the query is actually blinding the evil server afaik.
There’s no single encrypted representation of a phone number. Rather the entire database is encrypted and the accesses performed by the HE algorithm would be randomly accessing the database in a way that wouldn’t leak anything. Now of course if you have billions of lookups a day maybe something does end up leaking because you’d be able to extract networks from data patterns (ie if the same number is contacting 100 numbers, the data access patterns might be the same) but it’s a lot more complicated than what you’re proposing and I wouldn’t be surprised if this is explicitly handled in the design of the feature.
Since for telescope what matters is the surface size of the mirror (light collected is proportional to surface which is proportional to r^2), the 9m telescope is ~1.9x better than 6.5m one. This is a big difference. Not even counting the loses from a non perfect alignment of a folding mirror compared to a fixed one.
DME (distance measuring equipment) is much simpler than LORAN. However, navigation computers can use multiple VOR / DME signals to compute position similar to LORAN or GPS. The problem is that DME / VOR are typically limited to 50-200nm (and even lower at lower altitudes) which requires extensive network to make it comparable to GPS / LORAN.
The basics: A VOR (Very high frequency omni-directional range) station just gives you the bearing to the VOR. It's simple. It's a large ring of antennas with another antenna in the middle. It sends out a big omnidirectional pulse, and then sweeps around the circle like a lighthouse. The time difference between the omnidirectional pulse and the directional pulse tells you your bearing to the VOR station. The aircraft just receives; it doesn't send anything. Range is maybe 200 miles.
DME (Distance Measuring Equipment) came later. It's a request-response system. Time between aircraft request and DME station response gives you distance to the DME station. Most VORs also have a DME system installed, so you can get range and bearing.
VOR bearings aren't very accurate. Error is up to ±4°. So position from VOR and DME isn't very good far from a VOR. VORs are thus installed at major airports, so positional info gets better as you approach the airport, and pilots can find the airport reliably.
SJC (San Jose International Airport) has a VOR northwest of the airport. It's a huge antenna array in a big open field, and can be seen from 101 north of the airport. It needs all that open land to work well. Obstacles would distort the directional beam and make the error worse.
The FAA has shut down over a hundred VOR stations as redundant.[1] The original plan was to shut down even more, but there was much pushback. In addition to airport VOR stations, there were chains of "enroute" VOR stations, so that aircraft could fly along established airways from VOR to VOR. Some of those have been shut down.
The FAA now uses the term "minimum operational network" for what's available with GPS down.[2]
GPS jamming is very real. Here's a real-time map of known GPS jamming and spoofing.[3] Current jamming is mostly near Ukraine and Lebanon, plus the Black Sea. War zones. Discussion at Ops.group, which is a site for people involved in international aviation operations.[4]
Botched go around killed many pilots. May be trimmed too much up for landing with flaps and didn’t push nose down hard enough. In general, touch and goes in a high performance planes is not a good idea (no time for checklists, runway length, and actually wrong muscle memory for real takeoffs / landings). RIP.
There’s a balance of risks in T&G vs full-stop taxi-backs. On the day of the individual flight, taxi backs are surely safer. But if they let you get in less than half of the circuits (as would be common at busy GA airports) or if they cause your proficiency training to become twice as expensive, the overall system safety difference isn’t clear.
I come down on the side of being willing to do touch and goes in any aircraft (and have shared circuits with heavy jets doing touch and goes, so it’s done at all levels).
From the video, this does look like a botched climb from either an intended T&G or bounced landing after a series of T&Gs, so I’ve got to agree with your point about the “that day” safety here.
I kinda wish computer systems were more involved in planes.
Computer systems have controlled the movement of elevators for 50+ years. They stop the elevator moving when the door isn't shut very effectively. They have certainly saved more lives compared to even a well trained elevator operator.
With today's tech, it would be possible to make a computer that prevents stall of any aerofoil. Anytime an aerofoil is nearing stall conditions, do whatever is necessary to prevent it stalling by actuating control sticks in the direction to prevent the stall.
Self-driving cars can't even manage 2 degrees of freedom with billions of driver-miles of data. What do you think can be done in 3d space, with more instruments and many orders of magnitude of less data?
> With today's tech, it would be possible to make a computer that prevents stall of any aerofoil. Anytime an aerofoil is nearing stall conditions, do whatever is necessary to prevent it stalling by actuating control sticks in the direction to prevent the stall.
What a brilliant idea! It certainly could never directly lead to the deaths of 346 people in two separate plane crashes or anything.
On a slightly less snarky note, what do you imagine an autopilot is?
> I kinda wish computer systems were more involved in planes.
> Computer systems have controlled the movement of elevators for 50+ years. They stop the elevator moving when the door isn't shut very effectively. They have certainly saved more lives compared to even a well trained elevator operator.
I thought you were talking about the elevators on a plane and was trying to figure out why whether a plane door was closed mattered for controlling the elevators.
As the old quotation goes, Aviation in itself is not inherently dangerous, But to an even greater degree than the sea, it is terribly unforgiving of any carelessness, incapacity or neglect.
Even if the accident pilot had intended a stop-and-go and assuming reports of a bounce are accurate, it was too late. Trying to force a landing risks porpoising. Going around after a bad bounce is the safer choice — but a high workload event: full power, first notch of flaps, nose forward, and the all-important right rudder.
Are pilots four point strapped? The video looks like a heavy impact with a whip effect from the wing hitting the ground, but the forces involved look generally in the class of automobile impact. Is GA lax on restraints?
Are there "airbags" in GA, or accidental deployment too high a failure risk?
> but the forces involved look generally in the class of automobile impact.
I don't think that's something you can eyeball?
For one thing, planes infamously don't appear to be moving super fast even when moving at speeds that would raise eyebrows in a car. On normal final approach a Cirrus SR22 has an airspeed of around 80 knots (92 mph, 148 kph) and that looks like this: https://youtube.com/shorts/XZcW11zgWQE - the accident plane almost certainly had a higher velocity when it hit the ground
And for another, impact with the ground especially in a dive is very different from impact with another vehicle as is typical for road accidents. Instant deceleration is a whole other beast. Imagine driving straight into a thick concrete wall at over 90mph - there's nothing that seatbelts and airbags are going to do to save you from fatal injury (an example of such a test crash: https://www.carscoops.com/2022/11/what-happens-when-you-cras...)
More like Plato. But cybernetics and systems theory seem more apt models, and, most interestingly, they derive as much from anthropology as from math. . . .
reply