Part of the problem with (most) airline web sites is that they still rely on very old mainframe reservation systems. These run low-abstraction code and use fixed-format EDIFACT messaging (often using ALC, a six-bit character set predating ASCII), and are therefore hard to work with and hard to connect to modern web infrastructure.
ITA Software (which I cofounded but at which I'm no longer an employee, and which is now part of Google) has been working on a new reservation system built on modern technologies. This is a monumental undertaking, but they have already launched with at least one airline.
It'll get better, but for the next few years, at least, airline websites are going to be patchwork quilts prone to this sort of problem.
Looks a lot like a backend session key collision. Some session could see passenger manifests, others shouldn't and someone got accidentally merged into the one that could. I'll start checking my apps and see whether low and high sensitivity information use different code paths and maybe rely on layered sessions or something like that from now on.
Yes, or it could be that a web session got improperly connected to a reservation system session with additional privileges. The res system has its own notion of sessions and privileges, completely independent of web session management. With ITA's res system, you keep the web view of the system completely in sync with the reference view in the res system because the web infrastructure can actually talk directly to the res system using a real API. With a legacy res system running in TPF on a mainframe, it's not so simple, because you have to intermediate everything through very old protocols and transports that were designed long before Tim Beners-Lee set fingers to keyboard.
The design of the interface will probably reflect some of the architecture of the back-end - if all connections are virtual and go through one or more physical ports or if each connection requires a physical connection (that may be multiplexed into something else on its way to the heavy iron). I designed a much simpler thing that connected a PC running a Visual Basic app (cut me some slack - it was 92 or so) between a SQL Server and an AS/400 machine through an ancient ISA board that was only happy under OS/2 but tolerated DOS enough to cooperate a little. It was quite an experience - at least the data arrived in ASCII.
I have no idea what United is running (besides the Windows ASP.NET front-end), but I wouldn't be surprised if it's something complicated enough to induce programming errors in clever people.
ITA's quizzes more than once inspired me on tests I subjected candidates to in order to gain a better understanding of the plumbing inside their heads. I assume the reservation system plumbing is equally interesting.
Nevermind session management. The real question is: Why does the publicly accessible booking website have access to the passenger manifest of the aircraft at all?
In what possible way could knowing who the other people on the flight are benefit an individual booking a seat?
This is sloppy, sloppy coding; probably a result of some poor schmuck pulling an all nigher or two because the somebody promised an unrealistic deadline.
Here's my guess: it's probably because you can have multiple people on one reservation. Each passenger on the flight gets an ID, and each reservation contains the IDs of the involved parties. Invalid reservation ID? List all the passengers, obviously!
Well, you need a list of seats occupied by all other passengers so that you can pick yours. The names probably happened to be in the same data set (and yes, of course it's sloppy coding).
The "seat" object though is not connected to knowing "who" is in that seat, only that it is full.
As in "if seat.isoccupied()"
At no time should the passenger object be visible to perform a new booking. I see where you might need it if you are changing a reservation, but again this shouldn't in any way be linked to the passenger manifest.
Maybe they want to be able to verify, across multiple sessions, that multiple seats aren't occupied by the same person, or to potentially be able to visually indicate that someone has multiple seats.
Obviously you can easily design a schema that does that without including the names of other passengers, but that schema would be idiosyncratic to that one purpose.
Given a certain level with the airline, United for example blocks the seat right next to you to offer you extra space (this can be overruled if the plane gets too packed). Thus, one passenger may be linked to more than one seat.
I once had my session completely swapped with another user's session when using GEICO's online management in 2008. This sounds like a one-time error, but since I had the other user's contact information in front of me, I gave him a call and sure enough he was logged in as me, and me as him. We both called geico the next day explaining the situation and their senior IT folk got back to me within 24 hours saying they had fixed the bug. I always wondered since then how often this happens on large sites.
I buy a lot of tickets on United's website (formerly Continental's), and it isn't a great experience – but the idea that this list is the flight's passenger manifest just doesn't make sense to me.
The screenshot shows the point in the ticketing workflow where you give the name (and basic TSA-required details) of the passenger purchasing the ticket. If you're logged in to the website, you can add as many passengers as you want to your account, which might be handy if you purchase tickets for your family or for coworkers. My guess would be that somehow the session got into an incorrect state and is showing the passengers from one or more other accounts.
Also, the form is the same whether you're booking a one-way flight with one manifest, or a roundtrip with many connections where each flight has a unique manifest. I don't understand how the system would be able to deal with these diverse sets of data.
Heh, last week I couldn't book a ticket for two days, as the fare box would come up empty. Tried different browsers/computers: no dice. Maybe this is related to United+Continental's integration?
I wonder: When he selected the other passengers, did their information populate? Telephone/address/etc.?
Ben here. Other info thankfully didn't seem to come through or be present in the response. But still gave me pause and not something I wanted my name on :)
There is a risk that these types of information leaks will become more common. Organisations are being forced to compete and have an online offering. This is great but suddenly you have linked systems that put sensitive customer data within touch of others. One wrong code and your hidden data is no longer hidden. In the past the sales and payment systems were totally separate.
Strange that you got more access to data with an expired session than with a valid one.
Sidenote: Can't wait 'til Tinfoil opens up to a larger group; I've been over to your site several times over the past week. Looks like a useful product.
ITA Software (which I cofounded but at which I'm no longer an employee, and which is now part of Google) has been working on a new reservation system built on modern technologies. This is a monumental undertaking, but they have already launched with at least one airline.
It'll get better, but for the next few years, at least, airline websites are going to be patchwork quilts prone to this sort of problem.