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

Reverse Engineering the Facebook Messenger API

intuitiveexplanations.com

Post reply on HN
Print view View original

11–20 of 40 posts

Re: Reverse Engineering the Facebook Messenger API

#11

Post by mmcwilliams »

baq wrote: post #10
stcroixx wrote: post #8

Earlier quoted context omitted.

So the government will get to decide whose business is defined as a 'platform' before they enforce this requirement of maintaining an API suitable for 3rd party clients? Do they also decide what features are required to be in that API? I guess on a case by case basis? Software in the pharma industry works kind of like this. That's why it can take months to years to make a tiny one line change to an application once i…

At some point a public company becomes an utility. I'd argue that Meta and Google are at this point, albeit for different reasons. The specifics are obviously difficult to reason about, but the scale of network effects and/or amount of internet communities which only exist as facebook groups or whatsapp groups and would simply be gone if either stopped existing is... troubling.

At the point that a public company becomes a utility, why not nationalize it? The alternative being presented here is that private companies should be legislated and regulated into behaving in a particular way which is an incredibly inefficient way to manage a public good.

Re: Reverse Engineering the Facebook Messenger API

#12

Post by 3np »

hardware2win wrote: post #3
mschuster91 wrote: post #2

I miss the good old days when FB Messenger was usable with ordinary XMPP clients. Platforms should be forced by law to open themselves to third party clients ffs. Yes, spam will be a problem - but seriously: FB is big enough to afford investigation teams that cooperate with law enforcement to tackle the spam at the source.

> FB is big enough to afford investigation teams that cooperate with law enforcement to tackle the spam at the source. Same can be said about Google, Apple, Microsoft, etc Yet spam still exists, how is that possible if your assumption was true?

Lack of incentives due to costs being externalized.

It's not that they can't, it's that they don't want to enough.

Re: Reverse Engineering the Facebook Messenger API

#13

Post by pocket_cheese »

smashed wrote: post #5

Ouch. The API designer inside me is shivering at that monstrosity. > You might ask why the Messenger API expects a JSON string inside a JSON string inside a JSON string inside an HTML form. You would have a very good question. Probably multiple layers of tooling and encapsulation to get to the real backend, or just unpaid tech debt. Also, first the author discovers a GraphQL endpoint. I thought great, just introspect…

My experience at FAANG was that every major service had like 9 layers of abstraction or had to traverse several hops to do the actual thing. I've kinda become jaded and feel like most things that make money are ugly. Whether it's a giant plate of spaghetti served up by some start-up trying to be the first to market, or a lovecraftian horror that is only exceeded in scale by it's unknowability - like what OP posted. The end result is the same... 40 api calls to submit a form :'''(

Re: Reverse Engineering the Facebook Messenger API

#15

Post by mschuster91 »

hsbauauvhabzb wrote: post #6
mschuster91 wrote: post #2

I miss the good old days when FB Messenger was usable with ordinary XMPP clients. Platforms should be forced by law to open themselves to third party clients ffs. Yes, spam will be a problem - but seriously: FB is big enough to afford investigation teams that cooperate with law enforcement to tackle the spam at the source.

Mind elaborating on why you think that should be a law?

Because platforms intentionally go away from their open beginnings once they gain traction and moat. Facebook's removal of xmpp was the first, then Twitter came along with restricting features to only the official client (polls and medis in DMs) years ago, and now it's cat and mouse, with Twitter kicking off apps with zero notice.

Even Reddit, which has historically been extremely open towards third party apps, now gates features - RIF for example can't integrate with rewards, which is IMO pretty moronic as it could be a pretty good revenue stream for Reddit.

Capitalism has failed, and it's high time governments step in to break open the walls of the gardens.

Re: Reverse Engineering the Facebook Messenger API

#16

Post by derhagen »

mschuster91 wrote: post #2

I miss the good old days when FB Messenger was usable with ordinary XMPP clients. Platforms should be forced by law to open themselves to third party clients ffs. Yes, spam will be a problem - but seriously: FB is big enough to afford investigation teams that cooperate with law enforcement to tackle the spam at the source.

That's almost what the EU's Digital Markets Act will require them to do: https://www.theverge.com/2022/3/24/22995431/european-union-d...

Re: Reverse Engineering the Facebook Messenger API

#17

Post by grishka »

It would've probably been much less ugly if the author reverse engineered one of the mobile apps instead of the web version. Those must use a much saner API that actually feels like an API.

I myself reverse engineered and patched Instagram for Android once because I got fed up with ads in my feed, but there's a high probability that all Facebook apps use the same "proxygen" HTTP client library. This library is notable because it is written in C++, thus requiring JNI bindings on Android, and that part can't be obfuscated — so, easy to find and fully stable across versions.

So I just added some calls into my own code (java source -> javac -> dx -> baksmali -> copied to "classes" in apktool project directory) in the bytecode of those JNI bindings and started logging requests to see how the ads are returned. I then built a response rewriter to remove the ads. If you have a spare Android device, you could even avoid messing with the app entirely by injecting your own code into the unmodified app using Xposed Framework. Xposed is very underrated as a reverse engineering tool.

Re: Reverse Engineering the Facebook Messenger API

#18

Post by stanleydrew »

mmcwilliams wrote: post #11
baq wrote: post #10

Earlier quoted context omitted.

At some point a public company becomes an utility. I'd argue that Meta and Google are at this point, albeit for different reasons. The specifics are obviously difficult to reason about, but the scale of network effects and/or amount of internet communities which only exist as facebook groups or whatsapp groups and would simply be gone if either stopped existing is... troubling.

At the point that a public company becomes a utility, why not nationalize it? The alternative being presented here is that private companies should be legislated and regulated into behaving in a particular way which is an incredibly inefficient way to manage a public good.

Honestly in practice I'm not sure there's much difference. A "nationalized" utility would still be regulated by legislation to behave "correctly" when operated by the executive branch. See e.g. USPS.

Re: Reverse Engineering the Facebook Messenger API

#19

Post by mmcwilliams »

stanleydrew wrote: post #18
mmcwilliams wrote: post #11

Earlier quoted context omitted.

At the point that a public company becomes a utility, why not nationalize it? The alternative being presented here is that private companies should be legislated and regulated into behaving in a particular way which is an incredibly inefficient way to manage a public good.

Honestly in practice I'm not sure there's much difference. A "nationalized" utility would still be regulated by legislation to behave "correctly" when operated by the executive branch. See e.g. USPS.

I think the difference between the USPS--which has laws preventing it from making a profit--and a US-based tech firm that profits by selling user data to advertisers would be a massive one.

Re: Reverse Engineering the Facebook Messenger API

#20

Post by userbinator »

This amazes me with just how bloated and inefficient simple things have become.

In ~4 decades we went from literal 'netcat chat' where your message may be shorter than TCP/IP headers most of the time, to slightly more featureful but still simple with IRC, and then the IM protocols of the 90s/2000s with even more features but usually quite tame (speaking from experience of working with MSNP). After that it started getting worse with XMLification, and now the web-based stuff.

But those last two requests aren’t API requests, they’re just requests to fetch images!

...that naturally raises the question of "what images? I didn't send any."

It's horrifying to see a <40B message get turned into 730B. I suspect that the majority of the time, the actual message content you send will be dwarfed by overhead.

Post reply on HN