[dpifke]

Presumably the non-public data is being scraped using the employees' credentials (i.e. username and password).

It is perfectly reasonable for an employer to have a policy which states, "do not give your work username and password to a third party." I can't imagine a court ordering otherwise.

Providing an API for this data is a non-trivial amount of work, involving significant technical and compliance challenges. Employee schedules would be useful as a signal for trading in AA stock. How do you enforce that the third party is properly protecting that information, e.g. during SEC-mandated blackout periods around earnings?

The union might be able to negotiate for AA to hire lawyers and IT staff to work on such an API, but I really can't see the employees being automatically entitled to it.

[dkonofalski]

If the scraping is happening "on-device", though, then they're not providing their details to a third party. They're simply accessing their schedules. Otherwise, pulling up their schedules in any web browser would be considered giving their credentials to a third party since that's basically what's happening here. It would be like logging in to the aa.com employee site and then installing a Chrome extension that reads the page that was downloaded. Nothing is given to the Chrome extension in terms of credentials, only page content.

[dpifke]

It might be possible to build this app in a way that none of the information ever leaves the device. I would be very surprised if that was the case here.

Most large IT departments have a list of approved browsers and browser extensions. The scenario you described would fall under the same policy. If Chrome uploaded the content of intranet web pages to Google, I expect it would be banned as well.

[dkonofalski]

>It might be possible to build this app

Not only is it possible to build it this way but I think it's far more likely that it already is built this way. Since the app is pulling up schedules for individual users, there's no benefit to scraping the info on a server or caching any of it as it would be unique for each user. There's no reason for that info to leave the device. The content is pulled, formatted, and then displayed in a style that matches the rest of the app. This can easily be done on-device and would be less efficient to do off-device.

>Most large IT departments have a list of approved browsers and browser extensions.

This is completely irrelevant considering this is being done on mobile devices. On iOS, at least, it's all webkit and done within the app itself. I was just using Chrome as an example for how this process is done without sending the credentials to a third party. Unless the company wants to ban people checking their own schedules, there's no way they can stop someone from logging in to a web browser and having the content scraped. As an example, let's say they only allowed Microsoft Edge as the "approved" browser and they didn't allow any Edge extensions to be installed. The user can still pull up the page in Edge, save the content once it's loaded, and feed the folder/HTML file to the app to scrape the content. There's literally no way for them to prevent this other than by severely obfuscating the content (e.g., randomly adding invisible characters into strings to prevent string searches or adding bogus HTML elements to prevent searches for element patterns) or ceasing access to it completely.

[dpifke]

Looking at the privacy policy[0], the app does send some information to backend servers, specifically "flight related information." If the employees' "flight related information" is not publicly available, I can see AA having a legitimate issue with it.

But the scraping does appear to happen on-device, and it claims the password is not transmitted, so that's better than I initially thought.

[0] https://www.iubenda.com/privacy-policy/40331177

[dkonofalski]

That would make sense for that context, though, since they're likely providing additional info regarding flight information and, according to the policy, only for flights that are saved to the user's account. That would imply that things like flight numbers are stored in the user's account which makes complete sense and wouldn't necessarily be anything other than public information.

[bryanrasmussen]

>It might be possible to build this app in a way that none of the information ever leaves the device. I would be very surprised if that was the case here.

I'm doing some similar stuff to automate an app for personal use, I might at some point turn it into a paid for app, when I do so I would actually have to redesign the application to send personal information off the device. Which I suppose I would not do.