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

Zoom’s Use of Facebook’s SDK in iOS Client

blog.zoom.us

Post reply on HN
Print view View original

141–150 of 272 posts

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#141

Post by luckylion »

thulecitizen wrote: post #8
ccktlmazeltov wrote: post #3

And so zoom crumbled from the social pressure, while every other service and website is thinking "oof, they didn't realize that everybody does this to do advertising"

Sometimes I really wonder who is on hackernews that stuff like this gets downvoted. Apparently a healthy dose of (scientific) skepticism means one is being ‘rude’ in SV circles. I guess the intellectual-property-rentier industrial complex that is Silicon Valley doesn’t like people looking behind the curtains.

Who in their right mind would downvote a "but everybody does this?! it's so mean to focus on this instance" comment?

/s

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#142

Post by azinman2 »

bscphil wrote: post #83
aaronbrager wrote: post #52

Earlier quoted context omitted.

You can pretty easily see all the traffic on your own phone. You can even do it on device https://apps.apple.com/us/app/charles-proxy/id1134218562

Does this work with apps that do their own TLS using their own pinned certs? I don't see how it could. Surely that's a lot of high profile apps these days. If this app works without root, it must be possible to apps on iPhone to add their own certificates to the system, which are then trusted by other applications - that would already be pretty alarming. I think Android still requires certificates to be manually impo…

You can add an ssl certificate but if they do cert pinning then it breaks. Most don’t do cert pinning.

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#143

Post by rpastuszak »

mikenew wrote: post #45

So it sounds like Zoom was using the Facebook SDK, and now they're not. I've been and iOS developer for a long time. I can tell you from experience that everyone does this. I have never worked for anyone who didn't ask for their app to include some combination of Facebook, Google, Flurry, AppCenter, Segment, Intercom, Parse, or whatever other random analytics framework the PM happens to be infatuated with. Getting ma…

> As long as you're running binary blobs that can make whatever network connections they please, people are going to take your data and send it to places you don't know about.

PWAs could answer this problem, at least to some extent, but Apple historically has been limiting the features to protect the AppStore and the Apple Tax (v. the recent local persistence changes in ITP).

It's better than, say, Google pretending that third-party cookies make the web a safer place (yup, that happened).

(Don't get me wrong, I think ITP and Safari are great)

> Get mad at Apple for not letting you wireshark your own iPhone.

People on HN can, but an average user shouldn't have to care about that. I'm 100% up for stronger legislative measures (both tech and dark UX patterns) and more education in this area. Sounds boring, but without it we'll just keep running in circles.

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#144

Post by Certhas »

JMTQp8lwXL wrote: post #58
intopieces wrote: post #55

Earlier quoted context omitted.

>Getting mad at Zoom for using the Facebook SDK is missing the point. It's really hard to believe this point given that... getting mad seems to have worked.

Doesn't scale. We can't have 1,000,000 front page "App X uses Y SDK" posts. People will stop caring. Nobody's made a post of that flavor in awhile, and Zoom got caught in the crossfire. Honestly, if anything it shields other apps. People have a limited capacity for repeatedly addressing the same thing.

That's exactly what laws are for.

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#145

Post by StreamBright »

mikenew wrote: post #45

So it sounds like Zoom was using the Facebook SDK, and now they're not. I've been and iOS developer for a long time. I can tell you from experience that everyone does this. I have never worked for anyone who didn't ask for their app to include some combination of Facebook, Google, Flurry, AppCenter, Segment, Intercom, Parse, or whatever other random analytics framework the PM happens to be infatuated with. Getting ma…

>> I can tell you from experience that everyone does this.

This is not true and even if it was true it is an extremely lame argument. You can justify pretty much everything with this logic.

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#146

Post by enitihas »

lultimouomo wrote: post #136

Nice way to bury an innocuous "iOS Advertiser ID" in the middle of the list. What "iOS Advertiser ID" means is, to a very good degree of approximation, your deanonimized identity. Also, that just linking the SDK in your app deanonimzes the user to Facebook is very, very clear in its documentation. It's not like Zoom didn't notice until someone told them. They made a decision, and now they're changing it because they…

They are changing because right now they are growing like crazy without the need to do much on user acquisition, and a bad PR is just too costly right now. But good to see them doing it.

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#147

Post by nothrabannosir »

dannyr wrote: post #95
mikenew wrote: post #59

Earlier quoted context omitted.

My point is that you've removed one instance of the Facebook SDK from your phone, but you still have 50 others. Plus probably hundreds of other analytics frameworks that you've never even heard of that are just as bad or worse.

So if you can't stop ALL of them, you stop NONE of them.

This is unsustainable. It requires constant vigilance and turns the privacy matter into a cat and mouse game where we are constantly one step behind the worst actors. These systems exist everywhere in the world and they’re fundamentally inefficient. E.g. recycling, or “please bring your own plastic bag”, which relies on goodwill.

Compare to a system where you fix the incentives to automatically align everyone’s interests: e.g. bottle deposits, or a small fee for plastic bags. Now people will want to do the right thing, because it is aligned with their own interests.

The same holds here: fix this one instance with enough outrage, there will be a thousand more. Instead, let’s fix the misaligned incentives between app builders and users, so their invasion of my privacy costs them as much as it does me (e.g. GDPR).

This is how you make efficient markets: align incentives. Fixing everything on a case by case basis only provides temporary relief.

[edit: note that OP never said "don't do it", they just said "it's missing the point". which I think is a fair call. this one fix is good, but it's unsustainable.]

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#148

Post by envy2 »

lultimouomo wrote: post #136

Nice way to bury an innocuous "iOS Advertiser ID" in the middle of the list. What "iOS Advertiser ID" means is, to a very good degree of approximation, your deanonimized identity. Also, that just linking the SDK in your app deanonimzes the user to Facebook is very, very clear in its documentation. It's not like Zoom didn't notice until someone told them. They made a decision, and now they're changing it because they…

The list is in alphabetical order. It's not malicious...

Re: Zoom’s Use of Facebook’s SDK in iOS Client

#150

Post by minusf »

hamburglar wrote: post #135
mikenew wrote: post #45

So it sounds like Zoom was using the Facebook SDK, and now they're not. I've been and iOS developer for a long time. I can tell you from experience that everyone does this. I have never worked for anyone who didn't ask for their app to include some combination of Facebook, Google, Flurry, AppCenter, Segment, Intercom, Parse, or whatever other random analytics framework the PM happens to be infatuated with. Getting ma…

I'm really liking Zoom's responses to incidents lately. Both this and the "oops we implemented certain features by leaving a localhost webserver gaping open" fiasco fairly recently got extremely nimble responses from them, and the responses were absolutely the right thing to do. They could have hand-waved the http server away and claimed to have "secured" it, and they could have hand-waved this away as "standard prac…

in the end they did the right thing with the local web server, but iirc their first response was "this is a non issue and needed for proper operation".

a definite improvement in this case and so far.

Post reply on HN