quote:

After Zuckerberg’s email, the Onavo team took on the project and a month later proposed a solution: so-called kits that can be installed on iOS and Android that intercept traffic for specific subdomains, “allowing us to read what would otherwise be encrypted traffic so we can measure in-app usage,” read an email from July 2016. “This is a ‘man-in-the-middle’ approach.”

ymgve posted:

https://techcrunch.com/2024/03/26/facebook-secret-project-snooped-snapchat-user-traffic/?guccounter=1

wait what the gently caress is this

quote:

Whoa. Facebook had a secret "Project Ghostbusters" (get it?) which allegedly was to decrypt "man-in-the-middle" style Snapchat traffic to copy it. Yellow highlight indicates redactions just lifted in nine unsealed plaintiffs briefs in private antitrust lawsuit. Wild stuff. /1

quote:

A lot of new stuff. There was lots of reporting (including Apple threats to boot Facebook) at the time on Facebook's software and Onavo acquisition allowing it to "spy" on competitive apps but I recall the decryption was written as a hypothetical. CEO email kickstarting it. /2

quote:

You can read the press back in Jan 2019 spoon fed by Facebook PR to friendlies with no mentions of decrypting SSL then compare to this internal email below sent to Facebook's most senior executives - "currently includes SSL decryption"... /3

quote:

And the allegations do get worse...seeing the underlying evidence at trial is important. "The company's highest-level engineering executives through the IAAP Program was a legal, technical, and security nightmare...'I can't think of a good argument why this is okay.'" /12

quote:

Here is the full unsealed docket item including the allegations against Facebook for "wiretapping" Snapchat including the Zuckerberg emails. /6

https://storage.courtlistener.com/recap/gov.uscourts.cand.369872/gov.uscourts.cand.369872.735.0.pdf

ymgve posted:

https://techcrunch.com/2024/03/26/facebook-secret-project-snooped-snapchat-user-traffic/?guccounter=1

wait what the gently caress is this

post hole digger posted:

mystes posted:

Edit: Also I don't think this is new information and I think people are just looking at documents that were just released from the class action suit and thinking that out of context they might sound worse than the previously known information, which they probably aren't

mystes posted:

It still seems problematic if they were collecting data on teens, but like, hypothetically (and this is probably giving facebook way too much credit) if the app store description itself was vague just to evade app store policies, but with respect to the actual user they paid, they were very clear on what was being collected, and they had parental consent and only collected data on snapchat and not like personal information it might not be as bad

Salt Fish posted:

This was my first reaction. On second thought though I realized due to living in hell the user's consent doesn't matter because the data doesn't belong to them, it belongs to snapchat and the other app owners. Meta wasn't stealing from the users, they were stealing from businesses. That's why they could actually face consequences.

Salt Fish posted:

This was my first reaction. On second thought though I realized due to living in hell the user's consent doesn't matter because the data doesn't belong to them, it belongs to snapchat and the other app owners. Meta wasn't stealing from the users, they were stealing from businesses. That's why they could actually face consequences.

Last Chance posted:

why is Zuckerberg such a huge piece of poo poo?

Last Chance posted:

why is Zuckerberg such a huge piece of poo poo?

Carthag Tuek posted:

ya i remember reading about that vpn lawsuit a while ago but the newly de-redacted(?) details is good info

Salt Fish posted:

This was my first reaction. On second thought though I realized due to living in hell the user's consent doesn't matter because the data doesn't belong to them, it belongs to snapchat and the other app owners. Meta wasn't stealing from the users, they were stealing from businesses. That's why they could actually face consequences.

mystes posted:

Whereas, for example, presumably an ISP can do whatever the gently caress it wants and because it's not trying to evade an app store policy it won't become an issue

Last Chance posted:

why is Zuckerberg such a huge piece of poo poo?

post hole digger posted:

the docs so nice they dacted them twice

shackleford posted:

i have not been following the latest unredactions here were they really installing a CA certificate and re-terminating the TLS traffic or were they installing some kind of MDM profile that enabled a traditional HTTP proxy for particular hostnames

i guess it doesn't really matter all that much but one of them fucks with the CA/WebPKI ecosystem and the other is just a standard enterprise feature used in a hilariously inappropriate fashion

seems kind of mindboggling that either of these approaches would be something allowed in the apple or google ecosystems, that's like just malware? like there just shouldn't be interfaces to control this poo poo programmatically from random mobile apps

namlosh posted:

https://youtu.be/WkLvpxImRGw?si=uV0D64rpXDP11ceg

I sub to this guy… hope he’s not a pos cause I know nothing about him. but I feel it’s a good explanation.
now to figure out how to explain it to family members

quote:

Facebook's IAAP Program used nation-state-level hacking technology developed by the company's Onavo team, in which Facebook paid contractors (including teens) to designate Facebook a trusted "root" Certificate Authority on their mobile devices, then generated fake digital certificates to redirect secure Snapchat analytics traffic (and later, analytics from YouTube and Amazon) from Snapchat's servers to Onavo's; decrypted these analytics and used them for competitive gain, including to inform Facebook's product strategy; reencrypted them; and sent them up to Snapchat's servers as though it came straight from Snapchat's app, with Facebook's Social Advertising competitor none the wiser.

Paul van Brouwershaven posted:

We are working with 114 customer accounts to revoke and re-issue 1,176 affected clientAuth TLS Certificates without the serverAuth EKU. Here is a summary of our progress as of this posting:
137 of 1,176 certificates have been revoked or expired.
208 certificates have been re-issued with revocation pending.
30 out of 114 customer accounts have fully remediated the issue (certificates re-issued and old certificates revoked).

We will be providing weekly updates on our progress until this issue is fully remediated.

Ryan Dickson posted:

Hi Bruce,

One question about the timeline disclosed in the report and data we see in CT.

As I understand them, the EV Guidelines (Section 9.7 (3)) require all EV subscriber certificates to include the Issuer’s EV policy identifier (in this case 2.16.840.1.114028.10.1.2).

The timeline disclosed above indicates that for about 11 days, Entrust’s EV TLS CP OID was removed from TLS certificate issuance profiles. During that time, it looks like Entrust issued about 2,000 EV certificates without the Entrust EV TLS CP OID.

We also observe at least 4 EV certificates without the Entrust EV TLS CP OID issued after 9/22/23, which seems at odds with the disclosed timeline.

In any event, some of these certificates were recently revoked (e.g., https://crt.sh/?q=0fd0adac015b97aaae3ae8d97335de6c37bcfa155749a7f7434eee1b3196edb9 was revoked on 3/21/24), presumably necessitated by the absence of cPSURI (https://bugzilla.mozilla.org/show_bug.cgi?id=1883843).

Can you share:

if you intend to open a separate incident report for the other issue described here (i.e., EV certificates issued without Entrust's EV TLS CP OID), like you did for https://bugzilla.mozilla.org/show_bug.cgi?id=1886467, since it appears to be a separate and distinct issue? If not, how do you recommend this is recorded? I'm asking because complete and transparent reporting creates opportunities for others to learn from the incident and avoid the same root cause, while also promoting continuous improvement.
how this corpus of certificates missing Entrust’s EV TLS CP OID intersects (or doesn't) with those disclosed in https://bugzilla.mozilla.org/show_bug.cgi?id=1883843?

Thanks,
Ryan

mystes posted:

This is implying that Facebook was MITMing all traffic from the Onavo vpn but it doesn't sound like this was possible?

Subjunctive posted:

where’s the detail about them being able to read DMs? it says they have access to the Titan API, but to access users’ “messaging app and non-app friends”. when I read that before I thought it was to let them send messages on the Netflix user’s behalf, to do things like watch parties or recommendation messages or whatever

is there something more somewhere about the DM access? very curious now

quote:

By 2013, Netflix had begun entering into a series of “Facebook Extended API” agreements, including a so-called “Inbox API” agreement that allowed Netflix programmatic access to Facebook’s users' private message inboxes, in exchange for which Netflix would “provide to FB a written report every two weeks that shows daily counts of recommendation sends and recipient clicks by interface, initiation surface, and/or implementation variant (e.g., Facebook vs. non-Facebook recommendation recipients).

Subjunctive posted:

where’s the detail about them being able to read DMs? it says they have access to the Titan API, but to access users’ “messaging app and non-app friends”. when I read that before I thought it was to let them send messages on the Netflix user’s behalf, to do things like watch parties or recommendation messages or whatever

is there something more somewhere about the DM access? very curious now

sb hermit posted:

It’s spread throughout the article but in particular there’s a part that reads: