I understand that you cannot make any promises or provide a time estimate. I’m glad to hear that FlightXML is in active development and that there’s a bunch of higher priority features being worked on.
To answer your questions, I don’t feel that my server infrastructure is particularly vulnerable to attack (my servers run on Google App Engine), but currently the FlightAware POST endpoint is the only insecure channel through which data is entering my system - the weakest link, as it were. Since these alerts can result in notifications to end users, I’d prefer it was secure and tamper-proof.
I’m currently doing IP checking to authenticate the origin of the POST request (see this previous post:http://discussions.flightaware.com/flightxml/flightxml-alert-remote-host-t14311.html) but this isn’t bulletproof - a checksum with a shared secret would be better. I’m most worried about data integrity or destination misdirection (data confidentiality is not really an issue here except that alert callbacks expose my alert_ids). It seems to me that SSL with certificate validation would be the best way to solve all of these concerns, but in the interim, since there’s a bunch of work on your side to support that, perhaps some other way of authenticating the POSTs as coming from FlightAware and being unaltered could be added? A checksum perhaps that can be verified using a shared secret - e.g. my account key?