Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Airlines don’t care about privacy: Case Study Emirates.com

medium.com

Post reply on HN
Print view View original

41–50 of 177 posts

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#41

Post by kkm »

asterius wrote: post #35

If you look at https://track.emirates.email you will see that it isn't emirates either, but a service provided by Mandrill, an add-on for MailChimp, and the cert is valid for https://mandrillapp.com . Surely they could have figured out how to use SNI. The fact that your mail client / embedded browser takes you happily to sites with broken certs, giving them a tracking token (and in this case, total access to your boo…

Exactly, the fact that the url does not have any expiry (apart from the end of booking), the email providers in this case Mailchimp would also have access to the same.

For the case why browser did not redirect the broken cert, that is because the link sent in the email was over http.

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#42

Post by tyingq »

ziikutv wrote: post #3

Its funny to be reading this just a week after noticing this. Every airline uses some sort of a contractor or a shared piece of software for online checkins. You can tell by the formed URI fragments and the JSON being sent back and forth. Its all trash. I wanted to work on a business that unified all check-ins under single company. I do not think however, it is reasonable given that all of these airlines have the pro…

That's not quite right. They all (mostly) do checkin with some combinination of PNR identifier, and last/first name. There's no actual collusion though. Just coincidental settling on the same minimum need.

They isn't much in common across airlines as far as the actual code goes, though. Beyond that they all use some limited set of CRS providers, like Galileo, Sabre, Amadeus, etc. That is to say, there's some common code, but it's pretty far down the stack, and only common across a few carriers.

One example: https://www.nytimes.com/2017/09/28/business/airport-check-in...

Hit several carriers, but not all by a long stretch.

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#43

Post by walrus01 »

product50 wrote: post #22

I mean - after Equifax got away with leaking SSNs, Names, Addresses with DoBs of all 142M Americans - this is seriously nothing. At this point, I have become apathetic on these privacy related issues as nothing will be done.

https://medium.com/message/everything-is-broken-81e5f33a24e1

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#44

Post by Arbalest »

kkm wrote: post #5
Arbalest wrote: post #2

Yet another reason blocking ads is a must. But not just blocking ads, trackers as well. I use uMatrix and uBlock origin. Unfortunately this does nothing to deal with the aforementioned redirect chain. I suppose maybe this means it is time to go back to the telephone and flight agencies.

Some of the tracking protection tools might help, but not all for exactly the reasons you mentioned. However, you can enforce some settings in Firefox and Firefox based browsers to control referrer leakage in control. But it does break few websites. I can recommend taking a look at : https://wiki.mozilla.org/Security/Referrer and see what suits your need.

I wonder if enabling referrer trimming by default on common browsers would force people willing to use tracking to reconsider their practices. Like everything (it seems) it is always a game of cat and mouse, and the best way to make it harder for trackers is to make sure the targets keep moving.

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#45

Post by kkm »

dictum wrote: post #30

In line with the age-old advice on how sausages are made, here's my advice: don't ever inspect the data leaving a mobile device. – Just as I was about to add this comment, I remembered how it's not limited to mobile devices anymore. (Thankfully with certificate pinning and integrity checking you may be spared of the risk of ever finding out what your apps actually do. Remember: only weirdos and terrorists tinker.)

Certificate pinning and integrity checking will only come into play if the services move to HTTPS :). Sadly, Emirates is sending HTTP links to help user's manage booking.

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#46

Post by AdmiralAsshat »

I had a coworker who was flying to Morocco (I forget what airline). He called me over to his desk at some point to show me the screen as he was picking out his seat. By each occupied seat was a headshot of the passenger, pulled from what I assume was their Facebook profile.

It was amazingly creepy.

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#47

Post by fareesh »

These magic URLs that can log you in automatically, generally ought to necessitate a very high degree of paranoia from whoever is implementing them. In this case the single point of failure seems like the leaky referrer, which ought to have been noticed as part of the aforementioned paranoia.

I guess the problem here is that from an overall experience POV you want users to be able to get to their booking from their email without having to go back and forth to figure out their booking reference number and type it in.

Even as an advanced user sometimes there is very little you can do to protect against this. In a lot of cases, blocking trackers is also a flaky solution because sometimes custom event tracking takes place as part of a JS event, and the event fails horribly due to the library not being loaded thanks to your blocker, and as a result the event doesn't do what it's supposed to, and you can't use the interface.

For mobile users, blockers are either not easy to install, or exist on some fringe browser that is untested, and breaks the UI.

I wonder if it is possible to measure or guess how many humans have access to your booking in such cases. Some part of the sysadmin team at each of those tracking companies, maybe product leads, customer support?

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#48

Post by granshaw »

I can easily see how this happened - Product deems that requiring a login for that page is too high a barrier and bad for business. Engineering thinks that “it ain’t so bad” since said links have a difficult to guess uuid; but of course forgot about or didn’t consider all the trackers that Marketing setup.

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#49

Post by kkm »

fareesh wrote: post #47

These magic URLs that can log you in automatically, generally ought to necessitate a very high degree of paranoia from whoever is implementing them. In this case the single point of failure seems like the leaky referrer, which ought to have been noticed as part of the aforementioned paranoia. I guess the problem here is that from an overall experience POV you want users to be able to get to their booking from their e…

For measuring presence of trackers on popular websites, I recommend: https://whotracks.me/

Disclaimer: This is a project from the company I work for. (Cliqz)

Re: How Airlines don’t care about privacy: Case Study Emirates.com

#50

Post by asterius »

seanmcelroy wrote: post #38
asterius wrote: post #36

Earlier quoted context omitted.

Certificate pinning is going away: http://www.zdnet.com/article/google-chrome-is-backing-away-f... I think we can be confident that sites that don't even use CSP won't be implementing Expect-CT any time.

HPKP is what the article you posted to is referring to, and probably will go away completely. However, profiling the public key of the site a mobile app connects to and erroring out if it is compromised to prevent MitM attacks is called 'certificate pinning' for mobile apps but is not related to the HPKP pinning of browsers. A reference for certificate pinning: https://blog.netspi.com/certificate-pinning-in-a-mobile-…

It seems grandiose to call that 'certificate pinning' when it is just hard coding, e.g. a self-signed CA cert or (worse) a particular server cert.

Makes me suspect that a lot of client side validation is happening with mobile apps.

Post reply on HN