Lol the irony of publicly announcing the addition of end-to-end encryption in one app (Whatsapp) while secretly breaking TLS in another, all in the same year #Tethics
So, the FANGs can conduct mass psyops warfare against the populace basically with impunity -- a pesky little suit now and then is inconsequential.<p>But what will happen when they get caught stealing each other's surveillance booty?
Whatever may be the end goal, MITM is called an 'attack', not 'research'.<p>I'd not last a single day at such a company who would ask me to do such things. I had worked for a national political party in IT and left the job once I found about it corrupt practices and scams.<p>If we, as engineers collectively upheld ethics as part of work culture, Meta wouldn't have attempted it.
Isn't this known since 2018?<p><a href="https://mashable.com/article/facebook-used-onavo-vpn-data-to-watch-snapchat-and-whatsapp" rel="nofollow">https://mashable.com/article/facebook-used-onavo-vpn-data-to...</a>
Direct link to PDF:<p><a href="https://s3.documentcloud.org/documents/24520332/merged-fb.pdf" rel="nofollow">https://s3.documentcloud.org/documents/24520332/merged-fb.pd...</a><p>Here is Meta's response:<p><a href="https://ia802908.us.archive.org/29/items/gov.uscourts.cand.369872/gov.uscourts.cand.369872.749.0.pdf" rel="nofollow">https://ia802908.us.archive.org/29/items/gov.uscourts.cand.3...</a><p>Meta denies that they violated the Wiretap Act but offers no evidence of consent. (They try, but it is a laughable attempt.) Meta is also arguing the documents are not relevant. Meta claims the VPN app intercepting communications with other companies that sell online ad services, e.g., Snap, was not anti-competitive. It was just "market research".<p>Why is Meta so afraid to produce documents about "market research".<p>Meta does _not_ deny that they intercepted communications. From the attention this is getting on HN, MalwareBytes, etc. it seems clear no one using the VPN app would have expected Meta was conducting this interception. It is difficult to imagine how anyone could have consented to interception they would never have expected.<p>Additional details:<p><a href="https://ia802908.us.archive.org/29/items/gov.uscourts.cand.369872/gov.uscourts.cand.369872.741.0.pdf" rel="nofollow">https://ia802908.us.archive.org/29/items/gov.uscourts.cand.3...</a><p>Apparently Facebook was using a "really old" version of squid.
So was the plan to just yolo this out into the wild?<p>because the document says here that it was going to be given to trial participants as part of yougov(and others) survey. Which implies that they would have been informed/paid.<p>If its the former, then obviously thats unauthorised wiretapping. If its the latter so long as informed consent is given, that a shittonne better that the advertising tech we have now.
This seems to be a valid reason to implement certificate pinning in the application's network layer. At least 3rd party VPN providers don't get to intercept without replacing the pin.
I used to work for a startup that did very similar kind of thing. We paid people to install our app and our root cert. We had our own VPN server through which all traffic of the panelists (people who participate in a panel) went and we were able to decrypt all traffic that used the PKI that the operating system provided. Some apps used some other kind of encryption (banking apps eg.) so that could not be decrypted. Then we also collected additional data, for example we took screenshots of whatever was currently on the screen and tried to map those to applications for which we recorded screenshots. This was done to know what app the user was running at what time.<p>I didn't work with the data collection, so my info is a bit limited. Facebook was our customer even though they had already bought Onavo.<p>I can answer some questions if you have any.<p>The company did go bankrupt and the technology was sold.
...with the consent of the users who installed this.<p>Some recent related discussion: <a href="https://news.ycombinator.com/item?id=39860486">https://news.ycombinator.com/item?id=39860486</a>
[dupe]<p>Lots more discussion on the various aspects of this:<p><a href="https://news.ycombinator.com/item?id=39832952">https://news.ycombinator.com/item?id=39832952</a>
There's a lot of confusion around these stories these days, which reminds me of the "Gmail is looking at your emails" stories[1].<p>First, this is not wiretapping, come on. There's targeted man-in-the-middle (MITM) attacks, and then there's this. This is plainly "we are using advanced powers to analyze your traffic".<p>This is not even Superfish[2] type of stuff, where Lenovo had preinstalled root certs onto laptops to display ads. This is "if you opt in we will analyze your data".<p>Every program you install on your laptop can basically do WHATEVER it wants. This is how viruses work. When you install a program, you agree to give it ALL power. This is true on computers generally, and this is true on phones when you side-load programs. The key is that when we install something we understand the type of program we're installing, and we trust that the program doesn't do more than what it _claims to be doing_.<p>So the question here is not "how does Onavo manage to analyze traffic that's encrypted", it's "does Onavo abuses the trust and the contract it has with its users?"<p>[1]: <a href="https://variety.com/2017/digital/news/google-gmail-ads-emails-1202477321/" rel="nofollow">https://variety.com/2017/digital/news/google-gmail-ads-email...</a><p>[2]: <a href="https://www.virusbulletin.com/blog/2015/02/lenovo-laptops-pre-installed-software-adds-its-own-root-ca-certificate/" rel="nofollow">https://www.virusbulletin.com/blog/2015/02/lenovo-laptops-pr...</a>
Did the bury the lede? Sure this a blow against "competitors" but that is ultimately a competition for the collection of data, user data. In doing this FB has expanded its ability to hoover up more data at the individual user level, correct?<p>Yeah, crap move but my concern isn't those other scoundrels, it's me / us.
<i>Documents and testimony show that this “man-in-the-middle” approach—which relied on technology known as a server-side SSL bump performed on Facebook’s Onavo servers—was in fact implemented, at scale, between June 2016 and early 2019.</i><p><i>Facebook’s SSL bump technology was deployed against Snapchat starting in 2016, then against YouTube in 2017-2018, and eventually against Amazon in 2018.</i><p><i>The goal of Facebook’s SSL bump technology was the company’s acquisition, decryption, transfer, and use in competitive decision making of private, encrypted in-app analytics from the Snapchat, YouTube, and Amazon apps, which were supposed to be transmitted over a secure connection between those respective apps and secure servers (sc-analytics.appspot.com for Snapchat, s.youtube.com and youtubei.googleapis.com for YouTube, and *.amazon.com for Amazon).</i><p><i>This code, which included a client-side “kit” that installed a “root” certificate on Snapchat users’ (and later, YouTube and Amazon users’) mobile devices, see PX 414 at 6, PX 26 (PALM-011683732)(“we install a root CA on the device and MITM all SSL traffic”), also included custom server-side code based on “squid” (an open-source web proxy) through which Facebook’s servers created fake digital certificates to impersonate trusted Snapchat, YouTube, and Amazon analytics servers to redirect and decrypt secure traffic from those apps for Facebook’s strategic analysis, see PX 26 at 3-4 (Sep. 12, 2018: “Today we are using the Onavo vpn-proxy stack to deploy squid with ssl bump the stack runs in edge on our own hosts (onavopp and onavolb) with a really old version of squid (3.1).”); see generally <a href="http://wiki.squid-cache.org/Features/SslBump" rel="nofollow">http://wiki.squid-cache.org/Features/SslBump</a></i><p>Malware Bytes Article: <a href="https://www.malwarebytes.com/blog/news/2024/03/facebook-spied-on-snapchat-users-to-get-analytics-about-the-competition" rel="nofollow">https://www.malwarebytes.com/blog/news/2024/03/facebook-spie...</a>