In theory, it should be the same verdict. In the US, the right we have is for free speech. You can say and publish anything you want (with reasonable restrictions regarding slander/libel, etc.). But the first amendment right to free speech is not the same as the right to be heard. Just because you can publish what you want doesn't mean you have any guarantee that anyone has to read it. You are not guaranteed an audience for what you say. The only right you have is that the government cannot shut you up without a damn good reason.
Will the courts continue to rule this way is the real question. After all, the courts do seem to be trending towards shills for corporate interests. Because of that, there is a chance they would ban ad block software if their benefactors wished it. It's hard to say for sure.
PTC will only get about 40% of the accidents. A GPS and baseline speed limit enforcer would be a very small fraction of that because most of that 40% of accidents has nothing to do with the baseline speed limit. It's mostly temporary speed zones, signals, and authority violations.
A lot of the preventable accidents aren't caused by engineers blowing the baseline speed limits. They're caused by blowing temporary speed limits, signals, and authority limits. And if you're going to the trouble of adding all of the equipment to stop a train blowing a speed limit, the incremental cost to add the rest of it isn't all that high. Given that the whole system will prevent orders of magnitude more accidents makes the added cost worth it.
Yeah. We had that problem solved a while back. I was just bringing up the fact that a GPS is nice but it's not 100% reliable, especially in canyons and tunnels. And the backup system wasn't as simple as plugging in another sensor. It requires more work than that.
The point being made is that "GPS and some simple software" isn't going to cut it. It's a difficult problem to solve. A lot more difficult than you might think if you didn't have the background to really know what is involved.
Last time I read about it, it's estimated that PTC will only stop about 40% of the accidents.
Thing is, as complicated as PTC really is, it's still the low hanging fruit that's the easier problem to solve than most of the rest. And considering that it will save lives, it's worth it in the long term.
Track and equipment maintenance standards being beefed up will account for another chunk. But you're right. It's really difficult to plan for that dipshit who stops on the tracks around a blind corner.
I bet the only time it's a distraction is when you have a helicopter boss who is constantly nagging you if you aren't always 100% focused on your task. If it's a passive recording system for after-the-fact investigation and that's it, it's much less of a distraction.
You say that as if PTC has been installed and fully vetted. I can tell you from personal experience that the technology is still years away from being a reliable safety system. I used to work for the leading company that's building it for Amtrak and all the other major railroads.
Speaking as someone who spent three and a half years working on Positive Train Control software, it's not as simple as throwing a GPS on the train.
There are a huge number of operating rules that must be enforced besides just a base speed limit. Not only does every mile of track have a speed limit that can vary widely, every type of train has a maximum safe operating speed that must also be considered. Then there are all the temporary speed limits that the computer has to know about. If there's a work crew out on the tracks, they drop the speed limit. If there's damage to the track, they drop the speed limit. etc. Then there are all the signals along the route. There's half a dozen different types across the country depending on what has been upgraded and what hasn't and they all govern how fast you are allowed to go at that location at that time. Then you have to throw in all of the other things along the track like grade crossings and switches. There's a bunch of different types of each and they all have different rules on what you have to do when you approach them. To top it off, you can't go anywhere until a dispatcher grants you authority to run on the track. And that's done in any of a dozen different ways depending on who owns the track and where it is.
Did I mention that the operating rules are different for each railroad? They are and you have to make sure you follow the right rules.
Then you can have the added complexity of interoperability. Every railroad, by contract, is allowed to operate on each others track. They even contract out engineers between each other. So you can have a BNSF engineer operating a CSX locomotive on UP track. And you have to have to figure out which rules apply in that case because they're different than an Amtrak engineer operating the same CSX locomotive on the same UP track. Or a BNSF engineer operating a KCS locomotive on UP track.
Then when you think you have that all figured out, throw in the fact that we have agreements with Canada that let our trains run back and forth between two countries.
Once you have all of that complexity, you have to be able to predict how long it takes to slow a train down so you know how far back you have to get off the throttle and/or hit the brakes. That calculation is impacted by the number of cars in the train, the weight of the cars, the grade of the track, the curves you're riding on, and even how long it takes for the air pressure to be let out of the brake line (a long time in a mile long train). There's a ton of calculus being done by the computer several times a second to keep an accurate estimation of your braking curve. Beyond that, the computer has to give the engineer a warning before cutting in and doing his job for him. So you have to predict the stopping distance with the added distance you'd travel if you wait a specified time after warning but before you enforce the stop.
Now, you have all of that. Then you have to factor in that your GPS isn't always accurate so you can't always count on the fact that it will tell you precisely where you are. Running through a tunnel cuts off your GPS feed. As you get towards the mouth of the tunnel, you get a lot of multipath errors that make your GPS location jump around pretty damn fast so you have to program the computer to account for it. The backup is the wheel tachometer that lets the computer know how fast the train is going and you can assume that a train isn't going to be jumping off the tracks 500 feet into a field to the left so that does make the job a little easier. But just when you think you've solved the problem, you have to deal with the fact that the diameter of the wheel isn't 100% constant. Sure, it's a steel wheel and it doesn't change rapidly. But it does wear down as the train is driven. So you have to keep calibrating the wheel diameter over the miles because even a small variation can lead to a significant position error over a long trip. A 0.1% error over a 1,000 mile trip will have you a mile off from where you really are. And 1,000 mile trips are a daily occurrence with trains.
So yeah, it's not as easy as just throwing a GPS on your locomotive and calling it good.
I don't care if you believe me or not. They don't run down to Fry's and buy an off the shelf router to put in an airplane, regardless of what you see in the movies.
I keep forgetting how slow websites really are with all that crap. Once in a while I end up using a browser without a script blocker and I wonder if I'm back in 1995 loading over dial up before I remember that it's all the scripts and crap that you don't need.
If that's the case, I'd assert that it's even less likely he was able to hack in.
I've written more than my share of ARINC 429 drivers and code that uses them. Hacking into a box at one end of a 429 connection so you can pass the data you want is significantly harder, especially in older aircraft which use more primitive operating systems (if they use an operating system at all). It's not like they're running off-the-shelf Linux with everything enabled. If they have a full operating system it will be something like VxWorks or Green Hills Integrity. Beyond that, you're not using the full RTOS, you're using the ARINC 653 compliant subset that has some pretty robust partitioning. And when you set them up for your system, you take out the parts you aren't planning on using so you have less to certify. There are no service ports left open on the IP stack. There are no terminals or file transfer services to hack into. Hell, many (most?) of those types of systems don't even have a file system at all. And if you're trying to hack a pre-RTOS era box, you have an IP stack that was customized specifically for the box to provide only the services required for that box and every other port will be closed. They were pretty adamant that the ports we were going to use were the only ones you could use when I had to run my IP stack through the testing gauntlet in the pre-RTOS days, not to mention that every single packet had to be screened for validity before it was accepted. They did quite a bit of testing to make sure we didn't have any "undefined behavior" resulting from corrupted or incorrectly formatted packets.
If you manage to get hacked packets to the box, you still have to find your way through the very custom software to get anything specific out of the 429 port at the other side. Which in most cases is virtually impossible because it's specifically designed to pass only the data it expects to pass. Then you have to deal with how to get the data you want through the 429 network. That's a network which has very specific message handling built into it and each computer using it configures their software to route the 32 bit packets very specifically. Keep in mind that 8 bits out of those 32 bits is the routing label that determines what the packet is used for. If the receiver isn't expecting a specific label, it will drop the packet. Beyond that, 429 is a single point to single point connection. The protocol has no provision for routing packets past that. You have to specifically design a computer to forward the data between two connections. And when you do that, you only route just the very specific data you want to route. You don't design it to accept any data from anywhere and pass it on to everywhere else. That's a huge safety hazard. Engine control data coming from the GPS interface simply doesn't get passed through the data concentrator because that's not where it's designed to come from.
If that weren't enough, you have to add in the fact that out of the 32 bit packet, you really only have 21 bits for payload, broken up in a couple of different ways depending on what you're sending. Every given routing label identifies what data is being sent. And for a lot of it, they only ever send one packet on a periodic basis for status update. It's a lot less common to send multi-word packet sequences. Even then, they're very specifically formatted and there's heavy range checking and so forth on expected vs received values for safety reasons. So it's not like there's a lot of room to pack in anything to hack with.
The more I read about this the less I believe he could actually hack a real plane.
The reason they have multiple engines on a plane is to eliminate a single point failure that would make the plane have "premature contact with the ground". And on trans-pacific flights, having 3 or 4 engines gives you a significant safety margin for you to reach dry land. As engines have gotten better and more reliable, the requirement for 4 engines has been reduced to 2, starting with the Boeing 777 and going forward.
You can still make it to your destination after you lose your single GPS. Try making it to your destination after losing your single engine and let me know how it works out for you.
A switch on an avionics system won't be like a typical of the shelf commercial router. There's no need to have a programmable router on an airplane. Once it's configured, there's no need to log into it to change anything. It likely won't have any administrative access for configuration at all. It will be programmed at the factory with the only option to reconfigure being a complete system software load.
Perhaps he setup a test system in his basement with normal Ethernet switches and was able to do something interesting that would not have worked in the air with real AFDX switches?
That's where the uncertainty comes in. Near as I can tell, it's "very unlikely" that what he built could hack an actual plane. But I can't say with 100% certainty that he hasn't found a weakness that can be exploited. I doubt he has. But it is theoretically possible.
Because that adds weight and power consumption for no good reason. When it comes to that, the airlines and the manufacturers are pretty religious about reducing both. Every extra ounce reduces fuel efficiency. Every milliwatt consumed reduces efficiency. If you don't have to have two separate GPS units, you're not going to have them on the plane. The networking standards for avionics systems are capable of having the two networks connected together to share the data without letting one impact the other. So they do it that way rather than have two receivers on board.
Speaking as someone who worked for a Boeing subcontractor who designed their on board computers, I can tell you that there is a physical connection. There's only one set of SATCOM radios on board. The avionics systems use it for some of their communications and have for a long time. The airlines wanted to monetize the extra bandwidth by selling access to the passengers for a price. I am told they didn't add a second set of radios to provide bandwidth to the passengers.
So at the very least, there is a switch that connects the avionics network, the in flight entertainment network, and the SATCOM radios. And while this is a physical connection, there is a fair amount of confidence that it's still a logical separation. The AFDX/ARINC 664 standard is pretty extensive and allows for very strict connection management. While Roberts may have been able to get a packet out of the IFE network and have it look like an engine control message, there's very little chance that packet would make it anywhere close to the engine control computer. Of course, that assumes that the avionics network was set up correctly. And that's a pretty good assumption given the safety requirements in place for avionics design. Still, there's that one in a million shot that there is an exploitable flaw. It's probably less chance than that, but it's not guaranteed to be zero.
Considering that both the Avionics systems and the in flight entertainment systems are both able to reach the SATCOM radios, I'm not sure this assertion is true.
I've spent a great deal of my career working on avionics systems and did work on early Ethernet implementations in the late 90's, well before ARINC came up with AFDX/664 standards. Back then we restricted Ethernet to single point to single point dedicated channels with no switching or routing of any kind. The first vague ideas of having an in-flight entertainment network were starting to form. But at the time, it was just high level R&D.
From what I've been able to piece together is that Chris Roberts bought an under-seat device and hooked up something in his basement for proof-of-concept attacks into the avionics network. But without all of the rest of the equipment, he had to build up his system with commercial grade equipment. And that's where his "hacking the engine controls" story falls apart. Sure, he may have been able to get a specifically formatted packet through the IFE network and send it out the port that connects to the rest of the plane. And with his generic Ethernet switches, he may have been able to get that packet through to where he thought the engine control computer was. But his model is flawed.
AFDX/ARINC 664 is an entire structure built on top of the physical layer of Ethernet. While it may use Ethernet frames to pass the data, there's a ton of bandwidth management and strict routing management built on top of it. Assuming for the sake of argument that the avionics network was indeed set up correctly, there's no way an engine control packet coming from the IFE network would be routed. The filters would see that the IFE port isn't authorized to send that data and it would be dropped, perhaps with an error log of some kind. The only thing the IFE network should be able to talk to is the SATCOM radio and only within very specific parameters. There's no way a properly set up avionics network is vulnerable to an attack like this.
Of course, that begs the question. Did they set up their avionics network correctly? It's highly likely that they did, but I'm not going to say with 100% certainty that there are absolutely zero vulnerabilities. Suffice it to say, I'm extremely skeptical of Roberts' claims. But I will stop short of saying that he is, without question, full of it.
Because at a number of stores, they wouldn't take "no" for an answer without a fight. They would spend a lot of time push selling their catalog or whatever the hell it was they were trying to use to distract you from the fact that they collect your data. It was just easier, not to mention a lot quicker, to give them false information than to argue for a couple of minutes with a pushy sales clerk.
Slashdot Mirror
In theory, it should be the same verdict. In the US, the right we have is for free speech. You can say and publish anything you want (with reasonable restrictions regarding slander/libel, etc.). But the first amendment right to free speech is not the same as the right to be heard. Just because you can publish what you want doesn't mean you have any guarantee that anyone has to read it. You are not guaranteed an audience for what you say. The only right you have is that the government cannot shut you up without a damn good reason.
Will the courts continue to rule this way is the real question. After all, the courts do seem to be trending towards shills for corporate interests. Because of that, there is a chance they would ban ad block software if their benefactors wished it. It's hard to say for sure.
I doubt you meant to imply they should not implement it, but 40% is quite significant.
I covered that in some of my other posts.
PTC will only get about 40% of the accidents. A GPS and baseline speed limit enforcer would be a very small fraction of that because most of that 40% of accidents has nothing to do with the baseline speed limit. It's mostly temporary speed zones, signals, and authority violations.
A lot of the preventable accidents aren't caused by engineers blowing the baseline speed limits. They're caused by blowing temporary speed limits, signals, and authority limits. And if you're going to the trouble of adding all of the equipment to stop a train blowing a speed limit, the incremental cost to add the rest of it isn't all that high. Given that the whole system will prevent orders of magnitude more accidents makes the added cost worth it.
Yeah. We had that problem solved a while back. I was just bringing up the fact that a GPS is nice but it's not 100% reliable, especially in canyons and tunnels. And the backup system wasn't as simple as plugging in another sensor. It requires more work than that.
The point being made is that "GPS and some simple software" isn't going to cut it. It's a difficult problem to solve. A lot more difficult than you might think if you didn't have the background to really know what is involved.
Last time I read about it, it's estimated that PTC will only stop about 40% of the accidents.
Thing is, as complicated as PTC really is, it's still the low hanging fruit that's the easier problem to solve than most of the rest. And considering that it will save lives, it's worth it in the long term.
Track and equipment maintenance standards being beefed up will account for another chunk. But you're right. It's really difficult to plan for that dipshit who stops on the tracks around a blind corner.
Agreed.
I bet the only time it's a distraction is when you have a helicopter boss who is constantly nagging you if you aren't always 100% focused on your task. If it's a passive recording system for after-the-fact investigation and that's it, it's much less of a distraction.
You say that as if PTC has been installed and fully vetted. I can tell you from personal experience that the technology is still years away from being a reliable safety system. I used to work for the leading company that's building it for Amtrak and all the other major railroads.
Speaking as someone who spent three and a half years working on Positive Train Control software, it's not as simple as throwing a GPS on the train.
There are a huge number of operating rules that must be enforced besides just a base speed limit. Not only does every mile of track have a speed limit that can vary widely, every type of train has a maximum safe operating speed that must also be considered. Then there are all the temporary speed limits that the computer has to know about. If there's a work crew out on the tracks, they drop the speed limit. If there's damage to the track, they drop the speed limit. etc. Then there are all the signals along the route. There's half a dozen different types across the country depending on what has been upgraded and what hasn't and they all govern how fast you are allowed to go at that location at that time. Then you have to throw in all of the other things along the track like grade crossings and switches. There's a bunch of different types of each and they all have different rules on what you have to do when you approach them. To top it off, you can't go anywhere until a dispatcher grants you authority to run on the track. And that's done in any of a dozen different ways depending on who owns the track and where it is.
Did I mention that the operating rules are different for each railroad? They are and you have to make sure you follow the right rules.
Then you can have the added complexity of interoperability. Every railroad, by contract, is allowed to operate on each others track. They even contract out engineers between each other. So you can have a BNSF engineer operating a CSX locomotive on UP track. And you have to have to figure out which rules apply in that case because they're different than an Amtrak engineer operating the same CSX locomotive on the same UP track. Or a BNSF engineer operating a KCS locomotive on UP track.
Then when you think you have that all figured out, throw in the fact that we have agreements with Canada that let our trains run back and forth between two countries.
Once you have all of that complexity, you have to be able to predict how long it takes to slow a train down so you know how far back you have to get off the throttle and/or hit the brakes. That calculation is impacted by the number of cars in the train, the weight of the cars, the grade of the track, the curves you're riding on, and even how long it takes for the air pressure to be let out of the brake line (a long time in a mile long train). There's a ton of calculus being done by the computer several times a second to keep an accurate estimation of your braking curve. Beyond that, the computer has to give the engineer a warning before cutting in and doing his job for him. So you have to predict the stopping distance with the added distance you'd travel if you wait a specified time after warning but before you enforce the stop.
Now, you have all of that. Then you have to factor in that your GPS isn't always accurate so you can't always count on the fact that it will tell you precisely where you are. Running through a tunnel cuts off your GPS feed. As you get towards the mouth of the tunnel, you get a lot of multipath errors that make your GPS location jump around pretty damn fast so you have to program the computer to account for it. The backup is the wheel tachometer that lets the computer know how fast the train is going and you can assume that a train isn't going to be jumping off the tracks 500 feet into a field to the left so that does make the job a little easier. But just when you think you've solved the problem, you have to deal with the fact that the diameter of the wheel isn't 100% constant. Sure, it's a steel wheel and it doesn't change rapidly. But it does wear down as the train is driven. So you have to keep calibrating the wheel diameter over the miles because even a small variation can lead to a significant position error over a long trip. A 0.1% error over a 1,000 mile trip will have you a mile off from where you really are. And 1,000 mile trips are a daily occurrence with trains.
So yeah, it's not as easy as just throwing a GPS on your locomotive and calling it good.
I don't care if you believe me or not. They don't run down to Fry's and buy an off the shelf router to put in an airplane, regardless of what you see in the movies.
Not just what language but "What is your target environment?" That makes a big difference too.
I guarantee that you're not going to find good advice about what IDE is best on a Dice "insights" clickbait page.
I keep forgetting how slow websites really are with all that crap. Once in a while I end up using a browser without a script blocker and I wonder if I'm back in 1995 loading over dial up before I remember that it's all the scripts and crap that you don't need.
If that's the case, I'd assert that it's even less likely he was able to hack in.
I've written more than my share of ARINC 429 drivers and code that uses them. Hacking into a box at one end of a 429 connection so you can pass the data you want is significantly harder, especially in older aircraft which use more primitive operating systems (if they use an operating system at all). It's not like they're running off-the-shelf Linux with everything enabled. If they have a full operating system it will be something like VxWorks or Green Hills Integrity. Beyond that, you're not using the full RTOS, you're using the ARINC 653 compliant subset that has some pretty robust partitioning. And when you set them up for your system, you take out the parts you aren't planning on using so you have less to certify. There are no service ports left open on the IP stack. There are no terminals or file transfer services to hack into. Hell, many (most?) of those types of systems don't even have a file system at all. And if you're trying to hack a pre-RTOS era box, you have an IP stack that was customized specifically for the box to provide only the services required for that box and every other port will be closed. They were pretty adamant that the ports we were going to use were the only ones you could use when I had to run my IP stack through the testing gauntlet in the pre-RTOS days, not to mention that every single packet had to be screened for validity before it was accepted. They did quite a bit of testing to make sure we didn't have any "undefined behavior" resulting from corrupted or incorrectly formatted packets.
If you manage to get hacked packets to the box, you still have to find your way through the very custom software to get anything specific out of the 429 port at the other side. Which in most cases is virtually impossible because it's specifically designed to pass only the data it expects to pass. Then you have to deal with how to get the data you want through the 429 network. That's a network which has very specific message handling built into it and each computer using it configures their software to route the 32 bit packets very specifically. Keep in mind that 8 bits out of those 32 bits is the routing label that determines what the packet is used for. If the receiver isn't expecting a specific label, it will drop the packet. Beyond that, 429 is a single point to single point connection. The protocol has no provision for routing packets past that. You have to specifically design a computer to forward the data between two connections. And when you do that, you only route just the very specific data you want to route. You don't design it to accept any data from anywhere and pass it on to everywhere else. That's a huge safety hazard. Engine control data coming from the GPS interface simply doesn't get passed through the data concentrator because that's not where it's designed to come from.
If that weren't enough, you have to add in the fact that out of the 32 bit packet, you really only have 21 bits for payload, broken up in a couple of different ways depending on what you're sending. Every given routing label identifies what data is being sent. And for a lot of it, they only ever send one packet on a periodic basis for status update. It's a lot less common to send multi-word packet sequences. Even then, they're very specifically formatted and there's heavy range checking and so forth on expected vs received values for safety reasons. So it's not like there's a lot of room to pack in anything to hack with.
The more I read about this the less I believe he could actually hack a real plane.
You really don't know much about how AFDX partitions the network, do you?
Never underestimate the power of willful ignorance.
The reason they have multiple engines on a plane is to eliminate a single point failure that would make the plane have "premature contact with the ground". And on trans-pacific flights, having 3 or 4 engines gives you a significant safety margin for you to reach dry land. As engines have gotten better and more reliable, the requirement for 4 engines has been reduced to 2, starting with the Boeing 777 and going forward.
You can still make it to your destination after you lose your single GPS. Try making it to your destination after losing your single engine and let me know how it works out for you.
A switch on an avionics system won't be like a typical of the shelf commercial router. There's no need to have a programmable router on an airplane. Once it's configured, there's no need to log into it to change anything. It likely won't have any administrative access for configuration at all. It will be programmed at the factory with the only option to reconfigure being a complete system software load.
Perhaps he setup a test system in his basement with normal Ethernet switches and was able to do something interesting that would not have worked in the air with real AFDX switches?
That's where the uncertainty comes in. Near as I can tell, it's "very unlikely" that what he built could hack an actual plane. But I can't say with 100% certainty that he hasn't found a weakness that can be exploited. I doubt he has. But it is theoretically possible.
Because that adds weight and power consumption for no good reason. When it comes to that, the airlines and the manufacturers are pretty religious about reducing both. Every extra ounce reduces fuel efficiency. Every milliwatt consumed reduces efficiency. If you don't have to have two separate GPS units, you're not going to have them on the plane. The networking standards for avionics systems are capable of having the two networks connected together to share the data without letting one impact the other. So they do it that way rather than have two receivers on board.
Logical? Yes. Physical? No.
Speaking as someone who worked for a Boeing subcontractor who designed their on board computers, I can tell you that there is a physical connection. There's only one set of SATCOM radios on board. The avionics systems use it for some of their communications and have for a long time. The airlines wanted to monetize the extra bandwidth by selling access to the passengers for a price. I am told they didn't add a second set of radios to provide bandwidth to the passengers.
So at the very least, there is a switch that connects the avionics network, the in flight entertainment network, and the SATCOM radios. And while this is a physical connection, there is a fair amount of confidence that it's still a logical separation. The AFDX/ARINC 664 standard is pretty extensive and allows for very strict connection management. While Roberts may have been able to get a packet out of the IFE network and have it look like an engine control message, there's very little chance that packet would make it anywhere close to the engine control computer. Of course, that assumes that the avionics network was set up correctly. And that's a pretty good assumption given the safety requirements in place for avionics design. Still, there's that one in a million shot that there is an exploitable flaw. It's probably less chance than that, but it's not guaranteed to be zero.
The systems are completely, physically separate.
Considering that both the Avionics systems and the in flight entertainment systems are both able to reach the SATCOM radios, I'm not sure this assertion is true.
I've spent a great deal of my career working on avionics systems and did work on early Ethernet implementations in the late 90's, well before ARINC came up with AFDX/664 standards. Back then we restricted Ethernet to single point to single point dedicated channels with no switching or routing of any kind. The first vague ideas of having an in-flight entertainment network were starting to form. But at the time, it was just high level R&D.
From what I've been able to piece together is that Chris Roberts bought an under-seat device and hooked up something in his basement for proof-of-concept attacks into the avionics network. But without all of the rest of the equipment, he had to build up his system with commercial grade equipment. And that's where his "hacking the engine controls" story falls apart. Sure, he may have been able to get a specifically formatted packet through the IFE network and send it out the port that connects to the rest of the plane. And with his generic Ethernet switches, he may have been able to get that packet through to where he thought the engine control computer was. But his model is flawed.
AFDX/ARINC 664 is an entire structure built on top of the physical layer of Ethernet. While it may use Ethernet frames to pass the data, there's a ton of bandwidth management and strict routing management built on top of it. Assuming for the sake of argument that the avionics network was indeed set up correctly, there's no way an engine control packet coming from the IFE network would be routed. The filters would see that the IFE port isn't authorized to send that data and it would be dropped, perhaps with an error log of some kind. The only thing the IFE network should be able to talk to is the SATCOM radio and only within very specific parameters. There's no way a properly set up avionics network is vulnerable to an attack like this.
Of course, that begs the question. Did they set up their avionics network correctly? It's highly likely that they did, but I'm not going to say with 100% certainty that there are absolutely zero vulnerabilities. Suffice it to say, I'm extremely skeptical of Roberts' claims. But I will stop short of saying that he is, without question, full of it.
It was actually Todd Wilkinson and it was in Fryburg, CA which was a fictional San Diego suburb. But yeah, I used that address more than once myself.
Because at a number of stores, they wouldn't take "no" for an answer without a fight. They would spend a lot of time push selling their catalog or whatever the hell it was they were trying to use to distract you from the fact that they collect your data. It was just easier, not to mention a lot quicker, to give them false information than to argue for a couple of minutes with a pushy sales clerk.