5 ms·

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 emplo

by dx87 7y ago

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?

banana_giraffe 7y ago
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.
- kelnos 7y ago
  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.
  - fiddlerwoaroof 7y ago
    The HTTP server was a great idea: the problem wasn’t the server but the bug in the server.
    - saagarjha 7y ago
      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?
xiphias2 7y ago
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.
- remarkEon 7y ago
  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.
  - xiphias2 7y ago
    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.
    - remarkEon 7y ago
      Great point. If Apple or Google enforced what you're saying in their app stores this problem would disappear overnight.
    - mgoblu3 7y ago
      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.
      - yjftsjthsd-h 7y ago
        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.
- andreareina 7y ago
floatingatoll 7y ago
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."
perfectstorm 7y ago
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.
kelnos 7y ago
> 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.
- ryandrake 7y ago
  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.
  - the_other 7y ago
    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.
    - carstenhag 7y ago
      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-b0a865934398 https://medium.com/@orhanobut/no-op-versions-for-dev-tools-b...
chmike 7y ago
I guess it was not known that the facebook sdk did something as nasty as this
bvandewalle 7y ago
It's an imported library. Almost nobody vets those libraries ever. And that's the current state of software supply chain.

by dx87 7y ago

banana_giraffe 7y ago

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.

kelnos 7y ago
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.
- fiddlerwoaroof 7y ago
  The HTTP server was a great idea: the problem wasn’t the server but the bug in the server.
  - saagarjha 7y ago
    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?

xiphias2 7y ago

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.

remarkEon 7y ago
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.
- xiphias2 7y ago
  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.
  - remarkEon 7y ago
    Great point. If Apple or Google enforced what you're saying in their app stores this problem would disappear overnight.
  - mgoblu3 7y ago
    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.
    - yjftsjthsd-h 7y ago
      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.
andreareina 7y ago

floatingatoll 7y ago

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."

perfectstorm 7y ago

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.

kelnos 7y ago

> 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.

ryandrake 7y ago
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.
- the_other 7y ago
  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.
  - carstenhag 7y ago
    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-b0a865934398 https://medium.com/@orhanobut/no-op-versions-for-dev-tools-b...

chmike 7y ago

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

bvandewalle 7y ago

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