Airliners are not a Heroku dyno that you can "push code" into. There aren't APIs you can call, pull requests or Docker containers. We're not talking about a webserver or a couple of rails apps. We're talking about stuff being physically separated, non TCP, non IP, non Ethernet, uni-directional connectivity. Your OSI model doesn't apply here. Your API command list doesn't apply here. Your very notion of networking doesn't apply here. This is not about releasing early and iterating. We're talking about systems with a lot of redundancy and actual physical backups where efficiency is not an issue. The devops mentality does not work in this case.
It's important to put things to the test, but I tend to listed to people who are actually qualified and know what they're talking about. Even that RenderMan talk at DEFCON 20 came with a bunch of caveats. If you don't want to watch the whole thing, the TL;DW version is: Boeing and Airbus are not stupid, a 787 is not a D-Link wireless router and you pretty much can't get to the flight controls from the in-flight entertainment system. https://www.youtube.com/watch?v=Uy3nXXZgqmg
As explained in the linked video above (from DEFCON 22), there is a device called a Network Extension Device (NED) which is a one-way gateway between the FMS and the IFE for showing the progress of the flight to passengers.
Yeah, but I think that the main message is that there are pilots in the cockpit who can easily override any weird input. Even if it is theoretically possible (hey, you never know, right?) to impersonate avionics and mess up with the FMS/ECU/EICAS, there's no such thing as a pilot going "holy crap! the plane is going sideways and there's nothing I can do!". I'm pretty comfortable calling this whole "hacking the engines from the in-flight entertainment system" fiction.
Why on earth would you need more than a simple one way API between the FMS and IFE to be able to show inflight progress. For that matter, why would it be more complicated than a simple serial cable with just the O pin on the FMS side, and just the I pin on the IFE side to feed information at regular intervals to the IFE. I have no idea how exactly the systems are setup, but off the top of my head I can come up with several VERY simple methods of insuring that the communication between the FMS and IFE is in deed unidirectional. If this story is true, I would be highly disappointed in Boeing!
neurotech1 above says that it's unidirectional in hardware, so it's a moot point. But you could also do a simple relay server with API. FMS pushes the info to a "server" through a one way link. IFE would request the info from the server and displays it as necessary.
The Heroku situation is more nuanced than it seems. This is not a PCI DSS 3.0 issue. The thing is that Heroku provides a platform and this platform is not PCI DSS compliant (1.21, 2.0, 3.0, you name it) and Heroku is not willing to let QSAs verify their compliance on behalf of their clients (and, yes, I have first hand experience with this very scenario). There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go. Let's say you use a payment gateway and cardholder data never touches your Heroku environment (e.g. you're redirected to Payment Gateway XYZ's app to enter your payment information). In this case your Heroku environment would be potentially out of scope, as you're not transmitting, storing or processing cardholder data. If you're handling cardholder data in any capacity in your Heroku environment, then, yes, you're in for a big compliance surprise.
> Heroku is not willing to let QSAs verify their compliance on behalf of their clients
This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes.
> There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go
>This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes.
Exactly. And, personally, I think this is rather odd. They could solve this in a heartbeat.
>Not true, see below:
Duly noted and thanks for the link, but here's the thing, though: what if you're not eligible for a self-assessment?
> what if you're not eligible for a self-assessment
If you're doing higher transaction volume and are not eligible for a self-assessment, you have to have a certified QSA sign off on an audit of the internal processes.
The QSA will make sure that all the required systems and processes are in place and sign off on it.
PCI is definitely a fairly frustrating thing to deal with but there are some good practices underlying it that many orgs would simply not do if it weren't required by their merchant processor.
QSA here. In a nutshell, I'd say don't. PCI compliance is enforced by the card brands and acquirers, so it's not up to you to raise a flag here. Maybe they have compensating controls in place to address those issues (one can be PCI compliant while storing cardholder data in clear-text) and, depending on the line of business, they might have a business justification for storing security codes (unusual, but it can happen). Ultimately, it's not your call. What you might perceive as a violation could very well be a known issue with several compensating controls in place to minimize the risk and, if that's OK with the card brands and/or acquirers, your competitor is doing nothing wrong. Leave it to their QSA to determine their compliance status and to their acquirer to make sure that they're compliant.
And that's why you don't make games that need to be online 100% of the time to function (and charge $60 for it). Also, it should be noted that paying $400 for a console only to be told that you can't use it because some teenagers are bored is a bad investment. Sony and Microsoft should know better. They are both big and juicy targets, but there are bigger and juicier targets out there that are able to weather those lame attacks. It's Christmas day and a lot of people who got Sony and MS products are unable to fully utilize those products. Those guys are ripping Sony a new one every other day since 2011. Sony learns nothing and remains awful in incident response and recovery.
You understatement the amount of bandwidth that was being sent. It was huge. No one but Google and Facebook can weather what Lizard Squad (and the botnet operators they buy from) have access to.
I'm just gonna copy & paste my comment on another site about this: As a Brazilian, I can tell you that this is more than moral panic. Those balloons are a major fire hazard. There are many, many instances of fires breaking out because of balloons in forests, houses, warehouses... They're also a huge air traffic hazard (listen to ATC near Brazilian airports and you're pretty much guaranteed to hear pilots complaining about them). Just last week a balloon "landed" in the tarmac of Brazil's largest airport, barely missing an airliner. To top that off, they're annoying. These balloons usually carry fireworks and are launched late at night, so you'll wake up at 2 AM to the awesome sounds of fireworks. Sure, they're pretty to look at, but they're also a really bad idea.
Well done. I can see this working well for aviation enthusiasts (i.e. X-Plane folks) who like to use real world data. However, METAR/TAF are not the friendliest of formats. Have you considered including a METAR/TAF decoder?
The data that I get from the web service does include a breakdown of the specific conditions (not a human readable translation, but enough to generate one). So far I haven't implemented that since I can read METARs myself. I'd want to be careful not to consume too much screen real estate. Something to think about for sure.
For sure. If you're getting your weather data via METAR/TAF, you should be able to read it :). And one can always resort to this (even though it won't decode everything). http://heras-gilsanz.com/manuel/METAR-Decoder.html
Addendum: I did put the "about x minutes/hours" old thing on the data because of all the parts, the Zulu time is the one I consistently do have trouble with. :)
The as-of time is in the METAR. It's the block immediately following the station identifier, e.g. 172054Z means the 17th of the month at 20:54 Zulu. That's the time of observation.
You're right that the TAF doesn't indicate the time the forecast was published (although usually it's assumed to be the first hour of the forecast).
If you meant instead, as-of meaning "when the data was loaded", that's true... Not shown. I have the METAR ages turn red when they hit an hour (normally they are issued every hour) as a "clue" to the user to refresh. But certainly I could be more explicit.
> If you meant instead, as-of meaning "when the data was loaded", that's true... Not shown. I have the METAR ages turn red when they hit an hour (normally they are issued every hour) as a "clue" to the user to refresh. But certainly I could be more explicit.
