Hacker News Reader

Comment by dx87 | Hacker News Reader

It's good that they removed it, but it's also dissapointing that they had no idea that it was happening until someone made a blog post about it. Do their employees not vet any of the code they use, and just slap things together off the internet and hope it's not doing anything their users don't like?

View on HN

> Do their employees not vet any of the code they use, and just slap things together off the internet

That sounds like a pretty accurate description of how software is built. (No, I'm not being flippant.)

> ... and hope it's not doing anything their users don't like?

I expect most don't think too much about it, not out of malice, but because their product manager told them "I want FB login" and to do that, they either spend an afternoon using the FB SDK, or spend a week figuring out how it works, implementing it from scratch themselves, and debugging the inevitable interop issues with whatever oauth2 (or whatever) library they've picked. It's really a no-brainer... few developers can take the week-long route and then justify that to their manager. They'll get fired.

I've worked at places where "cowboy coding" was the norm and people would just look up how to do something on StackOverflow and copy/paste it. But to pull in a major 3rd party dependency like this and just "YOLO" ship it in your company's product? That's almost unbelievable. Didn't anyone have a look to see what the thing does? Assuming the SDK comes with source code, and if they integrated a 3rd party library that doesn't come with the source, even more shame. All it would have taken was a single engineer to notice unexplainable network traffic to a third party at runtime--at any time during development. So much WTF here.

Conversely, I’ve never worked anywhere, in 10+ years, where “we shouldn’t be sending this data to X, it’s bad for our users”, would have got further than the developers. Marketing, Product and management rarely care: in many cases they want the data to go to as many analytics and targeting services as they can.

Since the GDPR came into effect, at least in Germany I notice how product managers and other parties are involved in stuff like this, and not only devs and dev leads.

As an example, 2 weeks ago I had to implement Instabug's SDK for one of our app brands, and created a no-op fake library [0] in order not to shop any Instabug code to the other 5+ apps.

Simply because our PM was afraid of possibly sending stuff to them while not having added them to the privacy policy.

[0]: https://medium.com/@orhanobut/no-op-versions-for-dev-tools-b...

Lots of tempting 3rd party iOS frameworks are binary only without source, such as Google Maps for iOS. Who knows what kind of telemetry and event listeners these frameworks install.

It’s the official SDK of one of the biggest companies. I can’t fault them on not catching this. What Facebook does is ugly.

Yeah, this.

I really can't fault Zoom here. They used an existing tool provided by a company that is, allegedly, reputable.

Though, thinking about it more perhaps Zoom should get some more scrutiny here because this isn't the first time Facebook has said eff it to user privacy. Distrust of Facebook should be the default.

Actually Apple and Google should not allow this in their app store policy. An 3rd party SDK sending data if it’s not needed should be a BIG no-no....I expect at least Apple to require this.

There are probably thousands of other apps that have the same problem.

Great point. If Apple or Google enforced what you're saying in their app stores this problem would disappear overnight.

Would be pretty hard to scan for, but I agree that there should be something at least outlined. Privacy policies clearly are aren’t useful enough.

Hard in the general case, but I'll bet it's trivial to scan for the Facebook SDK, or any other blacklisted libraries, unless they're intentionally obfuscated.

And it's known that what Facebook does is ugly. So Hanlon's Razor and all that, but given recent events it strains credulity that the developers weren't at least suspicious.

Often the developers are aware of, or at least suspect these types of things.

However, it's the Project Managers and Product Owners that are not aware and they say "do it because that's what the customer wants!" and you can argue. You really do so at your own peril if you don't have others on the team to back you up.

As a sometimes iOS developer, I can’t even imagine how you could build something like Zoom without at least sometimes auditing the network traffic. Even a novice user can do this in a few minutes with Charles Proxy.

People on the team knew, they just either didn’t care or were ignored when they voiced concerns.

To rephrase this into something more beneficial to others trying to learn from this:

"It's good that they removed it, and it goes to show just how important it is to inspect your application's wire traffic as part of your development and testing processes. Otherwise you'll have no idea what's happening until someone makes a blog post about it."

Between this and the HTTP server, it feels like Zoom of old that wrote the app was more willing to make the user experience vs user privacy trade off in favor of user experience.

Now you need to log in via Facebook with a separate browser window, and thanks to the HTTP change, you need to click on a browser dialog to launch a meeting from a link. So, they've either changed their policy to err more towards the privacy side and haven't found all the cases yet, or, more likely, still have the same attitude except when the tech world starts screaming at them.

I think it's more likely that the developers responsible for the HTTP server just didn't know much about local security, and Zoom doesn't have a good security review process (where actual infosec professionals are involved). That doesn't absolve them of responsibility, of course, but I really don't think it was malice or an intentional desire to ignore privacy concerns.

The HTTP server was a great idea: the problem wasn’t the server but the bug in the server.

The “bug” where it would basically act like persistent malware, or the bug where it would act like persistent malware but also allow attackers remote access to your machine?

I guess it was not known that the facebook sdk did something as nasty as this

It's an imported library. Almost nobody vets those libraries ever. And that's the current state of software supply chain.

they can't see what happens inside FacebookSDK's code. even if they could see it, good luck convincing the PMs and directors to avoid implementing Facebook login.

Reply on news.ycombinator.com