Nothing's iMessage app was a security catastrophe, taken down in 24 hours
arstechnica.com
arstechnica.com
Which product manager in his/her right mind, thought this was passable when you're building and marketing your product as an iMessage alternative and every single early access reviewer raised these exact security concerns in public?
It's the one thing you had to make sure was air-tight, especially considering the raised eyebrows and extra scrutiny you'll get from security researchers when they see something as juicy as "iMessage on Android". Any security issue on launch day/week will get you nailed to the cross and bury your credibility for good.
How do these managers get jobs in these big name companies? You could have at least hired a third party for a pen-test/security audit before the big launch. It's the best way to uncover shoddy dev and security practices that creep in when you're crunching to get something out the door by launch day.
Why are we blaming PMs, here? Plenty of engineers out there make really stupid decisions every day.
(To be clear: I'm an engineer, not a PM.)
EXACTLY! Because it's a known fact all devs make mistakes, and as such, as a product manager/owner you're responsible for the bigger picture of the product and ensuring the right requirements, checks and bound are put in palce and validated for a successful product release.
It's not the job of the lowly SW engineers who have little visibility in the product as a whole and who just sprint to punch out Jira tickets handed to them from above, to check your product works as intended, it's your job as a PM/PO to ensure the work of all the devs integrates nicely into a cohesive product as per the requirements/vision.
Kind of like that famous story of that intern who got fired for deleting the production DB by mistake on his first day. Was it the intern's fault for the mistake or the fault of all the seniors and managers who should have placed the proper checks and bounds in place so that nobody can so easily delete the production DB?
So the buck for the product success/fail stops with those at the top who orchestrate the band, not with the individual SW engineers at the bottom.
Nope, not at all.
>Security is everyone’s job
In theory at well run tech companies ideally yes, but when you're overworked and underpaid and crunching like in a sweatshop to meet some arbitrary deadline coming from above that you did not agree with, then work becomes a chore doing the bare minimum just to get home before dinner, and every other potential issue outside my allotted tickets that's not part of my KPIs becomes "not my job" and "someone else's problem" because "fuck it, I'm already overworked and I won't get any extra recognition for doing even more overtime on security topics nobody seems to care about".
In short, as a dev, you don't care about the outcome of the product because you're not paid or empowered enough to care.
Shit rolls uphill. If you want devs to actually give a fuck about the product as a whole instead of just mindlessly punching Jira tickets, then you need to empower them, pay them well and respect them and their WLB, which the vast majority of companies worldwide do not (HNers are a priviledged bubble that's the exception). Otherwise you get what you se before you, a shitshow, because most tech companies are run like crap.
You cannot say that the project works because of you, and then turn around and pretend you have nothing to do with its failures.
You'd be surprised. I've been in at least 2 companies where that was the case and had to be the scapegoat for projects going sideways due to poor management.
Humans are shit and would much rather push the blame on someone if the company culture is not blameless.
First, the vast majority of people are not equipped to find or address major security issues well. Unless you have specialists integrated in the right places this means everyone's likely to be bad at the security part of their job and ill-equipped to notice.
Second, this means conflicts of interest everywhere. When you have a dedicated security org, you have people whose job it is to catch issues, hold things up, and generally make sure things get fixed. Without that, you have a bunch of people who have to choose between the possibility of a security event they don't understand and the certainty of blowing a deadline.
Third, security being everyone's job almost certainly means accountability is broken. Consequences will likely fall on some junior employee who might be directly accountable for an issue, but the huge org around them that did not enable them to succeed go unaffected.
You need specialists, an org to enable them, and an enterprise-wide apparatus to support a strong security process.
However I'd hope this is a case of an overworked team and over zealous management, because the alternative suggests a dangerously incompetent dev team.
So, they're useless?
Product managers should ideally be the technical voice of reason between the tech illiterate visionaries and the engineers in the trenches, steering the visionaries on what's technically feasible within the available resources.
A not unreasonable guess would be that Sunbird doesn't have a great number of senior engineers on staff, either do to cost, or because very few wanted to take on such a project. So it cobbled together by inexperienced engineering that know enough to understand the Sentry is useful, but not experienced enough avoid logging credentials.
Basically all the errors listed in the article just reads like what happens when you set a bunch of inexperience developers and SREs to build a platform that doesn't want to exist. Which leads me to: How the does this even work? I'd assume a massive number of virtualized macOS installation, anything more advanced would sort of negate the incompetence on the security front.
Sort of a side note: I questioned the point of the Nothing Phone and Nothing Phone 2 when they where both released, they are nothing more than Android phones with a few gimmick but everyone was loosing their minds over those things and now ArsTechnica writes: "Nothing has always seemed like an Android manufacturer that was more hype than substance" (and apparently also did for back when the Nothing Phone release. I'm getting so very tied of the hype and how easily any criticism can be reject as me being old and "not getting it".
I think there is a perception issue. Ars is not a person. I don’t know who was hyped when the phone was released, but Ron Amadeo sounds like someone who would indeed have been skeptical about Nothing’s pitch.
Nothing is very far from what I would consider a "big name company" They are actually a really small joint venture between Carl Pei and Teenage Engineering. This whole iMessage fiasco is exactly why I have such a hard time taking Carl seriously in anything he does. He seems more concerned with creating hype through smoke and mirrors than in releasing anything truly innovative and substantial.
That's just 'Nothing' the company making the phone, but the iMessage for Android app was built by Sunbird, a different company. It's written in the article.
Agree that these companies are more like Juicero, built on hype and false trust to sell mediocre products that aren't special.
"Pei says that Teenage Engineering is one of Nothing’s founding partners, and will drive the design aesthetic at his new company."
> Which product manager in his/her right mind
There is no product manager. There is a project manager. They steer on deadlines and functionality, nothing more.
> How do these managers get jobs in these big name companies?
Because they talk well and they've delivered before. Have they delivered something good and secure? Nobody cares, deadlines were met and functionality was shipped.
I notice the same in IT sales. Sell too much for too little, collect bonus and move on. Nobody comes back to you if the project fails or becomes too expensive and if they do, you blame the one engineer you had glance over the proposal before sending it to the client.
> It's the best way to uncover shoddy dev and security practices
As a project manager, that's the last thing you want. First, it'll show what you didn't manage well. Secondly, it costs money. Finally, negative findings will delay delivery and means you failed to deliver on time, which is your only priority.
Maybe I sound overly cynical, but I've seen this exact thing happen everywhere, from small firms to Fortune 500 to government.
And yet FAANGMAULs and other tech-first companies like Mozilla, seem to be doing quite well on security with relatively very few oversights, caused by dev gross negligence.
So it's definetly possible to deliver airtight products if that's your goal and part of your dev culture, instead of just "ship it by Christmas at any cost".
What is the MAUL part of your FAANGMAUL acronym.
FAANGMULA in the above case.
When will we stop adding companies' acronyms?
New enterprises can’t. And if you go back to those companies growth phases you’ll see security decisions that seem bananas now.
- Code review holistically bc they understand that part of the codebase, and other parts it interacts with, and they ask thoughtful questions. So things like logging sensitive info in plain text are not even a question.
- They understand how multiple components of a system work, like the tcp/ip stack, http, and other parts. Specifically not just how they eg. send messages, but how connections are setup/managed/torn down. Often that's where the security issues are (like which parts of a connection are insecure and when/how the upgrade happens).
- They have this deep understanding because they put effort and time to diagnose issues that happen do them and enjoy sharing. Unskilled devs just say "it's not working, someone else fix it please". I had a mobile dev once lose his mind because he was unable to upload a file to the api. Turned out his app was using a library that was messing up the multipart upload boundaries and content length headers (tracked it to a bug with multiple gh issues). He was unable to use this info to proceed.
- Participate in the hiring process, for they're a good filter for the company
- They abstract away a lot of the implementation details from product managers and eat a lot of the complexity to the point that the product manager only sees 60% or less of the actual work in Jira.
- A security autidor would need to really be worth his pay to find vulnerabilities, scanning for OWASP top 10 is not enough.
Note, these engineers do not need to be 10x, they just need to...be engineers.
Companies like Sunbird would not know how to tell one from the other, and product managers don't know what a secure app looks like. They could actually add that as a requirement and not know how to verify it. Often it's the developers that tell QA how to verify something. If your engineers are crap, you end up with apps like Nothing Chat. They aren't to blame, the company had no standards to begin with.
A glance at LinkedIn suggests you’re correct: the Sunbird app team seems to include a bunch of business people, a project manager, and no software engineers.
1. Pitch some grandiose idea to clueless execs
2. win over big money contracts
3. farm out the actual work to the cheapest body-shop and pocket the rest
This is exactly it. These product managers are judged on delivering on time, delivering UI glitz and UI functionality. Rarely anything else.
Actual product security is not even in the top-25 factors they are rated on.
One of these PMs once told me "We will put up some text on our website stating how we are extremely secure against all including nation state attackers, and that's the extent we're investing in security. We will not invest any time in implementation work related to this."
Eventually we did get this PM removed, but about a year of damage was done.
(LinkedIn tells me this PM is now at a FAANG)
This is why I assert that silicon valley was ruined by the rise of the PMs. In the 90s I had never met a PM, now I can't throw a twinkie in any direction without hitting at least three.
When there are deadlines to hit, average quality non-specialist management will generally prioritize keeping promises to leadership over meeting security requirements. It takes a rare manager with a strong grasp of the importance of security to stand up and tell their VP "We're not shipping, the security isn't there".
So how do these managers get there? They cut the corners that don't matter and hit the ship date. It gets them the promotion.
> Which product manager in his/her right mind, thought this was passable when you're building and marketing your product as an iMessage alternative and every single early access reviewer raised these exact security concerns in public?
This all falls on technical leadership and the software engineers. No passing the buck to non-technical people who aren't reading or writing code and probably don't understand encryption (although they should at a place like this).
https://www.sunbirdapp.com/sunbird-stance-on-privacy-and-sec...
This quote is nice:
> Some of the messaging community believes that software that is open source is more secure. It is our view that it is not. The more visibility there is into the infrastructure and code, the easier it is to penetrate it.
In my opinion, Sunbird Messaging are fraudsters, and Nothing was their mark.
And closed source code never had any "gaps" whatsoever, eh.
100% agree with this. `nothing` since its inception has been nothing but a marketing gimmick.
>Unveils phone with blinking LED for notifications and Nothing else interesting
Cool...not sure how this changes the world or is considered an innovation of any kind. Have their phones done anything worth talking about since launch?
Had Apple pulled Sunbird’s access to iMessage before information about their shoddy security coming out via third-party, they would have run the risk of playing into Google’s narrative about Apple being petty about their closed standard.
Here’s what I think (and hope) will happen:
* Apple will revoke Sunbird’s access and/or will sue them; they can almost certainly detect them via fingerprinting and other techniques
* Apple will take steps to further protect the iMessage standard
The interesting thing here is that Sunbird’s marketing and PR execution, at a casual glance, appear to be as impressive as their engineering implementation dismal, thereby suggesting the usefulness of cautious maneuvering by Apple.
Google Cloud would ideally have a role in protecting users here, too; ie blocking Sunbird from its platform on account of exposing users to such formidable risk while so blatantly misrepresenting their security posture. Apple could implore Google to consider, which could look good for GCP; while extending a mutual commitment to implementing RCS together in the interest of users at a moment when skepticism of large tech is at an all-time high.
What makes you think this?
The issue is Sunbird's shoddy implementation in particular compromising the security of a bunch of their users' accounts, with a real Android OEM vouching for their service and shipping it on their new phone, giving Sunbird a big publicity boost in the process.
How do your expect that they will do this? IIUC they are basically logging in to real Apple hardware with the users credentials. There is nothing concrete that can be used to identify these sessions. (Obviously things like shared IPs, reused machines and other patterns can be used, but these aren't 100% accurate).
That being said it surprises me that this can be profitable. If they run multiple users on the same hardware they risk being banned pretty quickly. In theory they can reuse hardware after user churn but that can probably be done a limited number of times. Is old used Apple hardware just so cheap that they can buy them then resell for a reasonable cost?
> Maybe they are betting that A) Apple doesn't care enough B) They aren't technically breaking any rules C) Enough "real" people do have multiple VMs signed into iMessage that they don't stand out enough to get blocked.
We seem to get a scam startup à la Psystar every couple of years. Some of them seem to believe that they’re too small and not worth Apple’s lawyers’ time, and other seem to be convinced that they are within their rights and Apple an evil monopolist.
It's not "Google's narrative" (which makes it sound like it's not true), it's the truth and abusing a monopoly, that is being investigated by the EU. We're expecting an EU decision soon if Apple are a gatekeeper with iMessage (as per the DMA/DSA), which they almost certainly are. If that is indeed the case, they'll be forced to open it to competitors anyways. So the whole thing is moot - see also Apple starting to finally adopt RCS, probably trying to anticipate EU regulations and spin them being forced to do the correct thing as "innovation".
Facebook and WhatsApp probably will be forced to be interoperable too.
> If I build a messaging protocol, there's no requirement for it to be interoperable.
None, but it's the decent thing to do. And since corporations are often incapable of doing the decent thing, they have to be forced.
> Apple does not hold a majority market share in most of the world. Where is this monopoly, and why should they be forced to share the fruit of their labours?
You're approaching this from an American "if it's not an absolute 99.99%+ monopoly it's fine", instead of the EU "do they have a portion of the market so big they can distort it and prevent competition and thus hurt consumers". Apple are absolutely hurting consumers with their abusive practices, regardless if their share of phone sales is 30% of 60%. So they will be forced to adapt common standards (USB C), open up their walled gardens, etc.
I'm not, but thanks for assuming. Apple is part of an oligopoly, which by definition doesn't hold enough market share to prevent competition.
The facetious "99.99%+" point is masking the actual relevance. A company with 30% market share does not hold the power to impact the market in a monopolistic manner. In fact, the precedent set is worrying - if market share isn't the primary factor in regulating monopolistic behaviour, what is? Arbitrary, hand-wavey 'oh, they seem big enough' decisions from bereaucrats?
I am a fan and supporter of inter-operable protocols. Forcing companies to bend to will around how they can build their software though is inherently stifiling though. I don't see any reason that Apple should be forced to provide iMessage interoperablity any more than Ford should be forced to share transponder information with Audi, so someone who owns both can unlock both cars with a single key.
Wow! How do such fundamental errors make it into these apps? Did _nobody_ who was working on it have an previous experience? Or is this another case of upper management ignoring the experts and pushing terrible ideas regardless?
hopefully workers start to wake up to the leverage they can have over just about anything after seeing the “openai is nothing without its workers” organizing going on
Because these hierarchies ultimately aren’t in their interest or the interest of customers, and are only as inflexible as workers allow them to be
- OpenAI is nothing without Sam Altman
- OpenAI is nothing without its workers (following Sam Altman)
- OpenAI is nothing without its workers (Sam Altman is just a figurehead)
A glitch in the Matrix?
The different colors of bubbles are a consequence of iMessage's origin as a protocol that supplanted SMS/MMS messaging while allowing the older protocols as seamless fallbacks; WhatsApp, Signal et al never had a requirement like that, and consequently never had to deal with different feature sets among their users (at least, not to the same extent).
See TextSecure
If even one non-iOS user joins a chat then all features except for basic texting (SMS and MMS) are dropped.
I don't think I need to tell you how much of todays' social interaction happens in group chats. Not having WhatsApp in the Netherlands when you're younger than 30 would effectively make you a hermit.
It's probably similar with iMessage in the US.
This creates an enormous peer pressure effect, especially for young people, to buy an iOS device.
Obviously they can still make better decisions than these guys - don't write confidential data to your logs! Don't unencrypted HTTP APIs! But unless the gateways to the 3rd party services run locally, you will never have end to end security.
Edit: Beeper has published their bridges as open source, so you could self-host it. That would at least give you full control of the stack. https://github.com/beeper/self-host
EDIT: forgot to add that there are several beeper specific MSC's that other clients don't render, thus if you want the full experience you either use their service or just stick with a normal matrix instance.
And it’s been working fine with Element as client.
You place your trust in 3rd party cloud servers for so many things. Email, as an example, is far more confidential / important, but most people never have it encrypted.
It’s still a fair criticism, but I still see Beeper + iMessage as more privacy-friendly than like FB Messenger (which has way more users).
And yet, that's precisely where I would go if I were law enforcement or a secret service. Tell them they're being used by terrorists/drug kingpins/CSAM peddlers, slap a gag order on 'em, and scoop up everything. And unlike Apple, Whatsapp or Telegram whoever hosts such a service can't even refuse such an order on grounds of technical impossibility because the messages are in plaintext in memory.
Use Signal if you want end-to-end encryption and don't feel bad about using Beeper for people stuck on iMessage.
Is this some sort of weird “they trust me, dumb fucks” social experiment?
Example: https://github.com/mautrix/imessage
The hardest part is probably keeping the duct-tapped stuff running.
You are dismissing a very hard problem with handwaving.
I am for reverse-engineering, but at some point civilized society invented the trademark, and today it seems necessary to create similar bodies of law that protect companies from charlatan Middleware that abuse markings of trust for personal profit.
But sure, let's let corporations super-copyright the colour green.
The bubble color was and is a signifier of transport layer only; I've personally had situations (generally with spotty or very poor coverage) where individual messages go over SMS even for conversations on all Apple hardware where the rest of the conversation is going over iMessage.
rcs is too controlled by carriers for my liking. it's very much an sms replacement, rather than a protocol that treats the cell network as merely a data layer
It's not clear if iMessage will interoperate via RCS, which is what would make blue/green bubbles less relevant. My assumption would be no as they'd cede moat, and there isn't much of a network effect for them to gain from.
> We believe RCS Universal Profile will offer a better interoperability experience when compared to SMS or MMS. This will work alongside iMessage, which will continue to be the best and most secure messaging experience for Apple users.