I don't think Beeper can promise end to end encryption for 3rd party services either. Fundamentally if you're interfacing with a service like iMessage or Whatsapp - even if they offer end to end encryption - the message has to be decrypted and then sent to the 3rd party app. Unless that gateway is running on your phone, the messages have to be decrypted in the cloud somewhere. At that point, you are placing all your trust in the 3rd party app's cloud services.
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
Pretty much useless to self-host your own beeper server since you cannot use their client with your own homeserver.
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.
As far as I can tell, the Beeper official client is a fork of Element, and there aren’t any huge missing features (other than easily setting up bridges).
True, but at the same time, it’s a very small attack vector. I’d say the vast majority of users could really care less that an iMessage is decrypted for a brief period in-memory on some Mac VM in a data center.
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).
> I’d say the vast majority of users could really care less that an iMessage is decrypted for a brief period in-memory on some Mac VM in a data center.
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.
Law enforcement doesn't need to do that. They can go direct to Apple because Apple's iCloud backup breaks iMessage end-to-end encryption for almost all people anyway (few enable the advanced protection program that fixes this blatant hole and both sides need it enabled to preserve the encryption). This isn't a conspiracy theory, it's documented behavior from Apple. People don't know or care.
Use Signal if you want end-to-end encryption and don't feel bad about using Beeper for people stuck on iMessage.
>"Sunbird actually logged and stored messages in plain text on both the error reporting software Sentry and in a Firebase store. Authentication tokens were sent over unencrypted HTTP so this token could be intercepted and used to read your messages"
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.
It really does beggar belief. I’d love to do interviews with the team, I’ll bet somebody knows why this happened, even if they’re not eager to talk about it.
> 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?
Why are we blaming PMs, here? Plenty of engineers out there make really stupid decisions every day.
>Why are we blaming PMs, here? Plenty of engineers out there make really stupid decisions every day.
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.
Just yesterday I was protesting unnecessary complexity in my story until my lead had a sidebar chat about an upcoming project.
How was I supposed to know that?
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.
All the way to the CEOs. I find it hard to believe that someone at this position in a tech company did not see any red flags, particularly as all the tech forums I have seen pointed out the potential issues within minutes of the announcement.
Well, managers are happy to take responsibility for their project/product when everything goes well. It’s actually the argument for their salaries and bonuses compared to lowly engineers. So why should they not take responsibility when it goes sideways? Particularly when failure affects the whole product like the Sunbird app.
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 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.
Their definition of done clearly didn’t align with reality. Product Managers fault although I am sure there is more to the story (aka no Product Manager)
One of the counterintuitive things I've learned is that "security is everyone's job" is one of the worst possible scenarios.
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.
Depends what the culture is at Sunbird. Potentially it's very bottom-up and eng is making all the technical decisions and PM just steers the overall vision.
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.
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.
Observability is a good engineering practice. Sentry is invaluable to get app crashes in prod, and I wouldn't want any PM deciding whether we set up sentry or not. The real issue is the lack of control of what is logged and what logs go to sentry
Yes... Why would a PM put Sentry on the roadmap, unless that PM has some reasonable level of technical understanding, but at that point the same PM should have been aware of many of the security implications of the overall project.
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 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"
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.
The product manager was overridden by the board / CEO who emphasized hyperaccurate metrics and time to market. Product managers are usually caught in the crossfire between a dev team who can't left-pad without 400 packages, and a C-suite who does not give a flying french fry about technical details.
> How do these managers get jobs in these big name companies?
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.
> They are actually a really small joint venture between Carl Pei and Teenage Engineering.
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.
It is a big name company though. Not a lot of companies have access to a supply chain and logistics to design and ship products like they do worldwide.
Worldwide? Nothing Phone 1 wasn't even available for purchase in the U.S and I've yet to see any of their other products being sold throughout latam. They operate like the infamous street fashion brand Supreme with limited "drops" in carefully chosen markets to generate hype through manufactured scarcity.
LOL you can find lots of small companies in China you have never heard of that make (better) phones and ships to dozens of countries. Nothing isn't any better than those companies other than marketing.
I work for a company like this right now. About the same number of employees, same mistakes and same time to market on innovative stuff. Here's my two cents on how this can happen:
> 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.
>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.
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".
Why are Uber, Lyft, and AirBnB being added only now, after their infinite-VC-money heyday is drying up, and when the general public is starting to hate them and are returning to taxis and hotels?
I'll stick with the ~1T market cap software/service ones: Facebook, Apple, Amazon, Microsoft, Google/Alphabet: FAAMG; But in discussions I'll include any company that has similar tech/business requirements or behavior.
When all the thoughtlord talent is finally and permanently collected into an enumerable initialism, so no thoughtlord feels any insecurity at being excluded from FAANGMAULTALONRIP.
What? Mozilla basically abandoned Servo, because of costs. And spent some money on CEO pay and on ridiculous preach-to-the-choir outreach campaigns and whatnot. And they regularly say no to security features. (eg. TLSA/DANE support https://bugzilla.mozilla.org/show_bug.cgi?id=672600 )
At some point their engineers are just better. I've been part of teams where every one was highly skilled, maybe a few juniors. And teams where everyone was junior and because they were very skilled on one specific thing, they assumed they were senior. The difference in those teams are that skilled engineers:
- 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.
> There is no product manager. There is a project manager. They steer on deadlines and functionality, nothing more.
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.
> 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.
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.
As a security researcher, bad security practices are prevalent in mobile by big companies and governments alike. They are just hoping that no one will reverse engineer their apps and APIs.
what damn engineer thought it was good idea to have sentry on in release on an app that uses firestore? I am extremely careful of when I turn on release app mode reporting to 3rd parties and about sandboxing said things so that passwords and ug messages do not get sent to 3rd party.
This has the overall feeling of something developed by a team where leadership sincerely believes that security is everyone's job. Because it's everyone's job and they hire good people, they don't need specialists.
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.
Replace 'Security' with 'Safety' and your comment still rings eerily true! One exception (? probably not an exception) is that sometimes organizations will still hire safety/security specialists (because the externally viewed perception of not having them is damaging), but these specialists are then (perhaps unintentionally) knee-capped to various extents in order to prioritize promises to leadership or other org. goals that must be hit. The net result is that good and capable folks who care deeply about the company's mission may watch in consternation as the org. slowly train wrecks itself if the roll of the dice doesn't land right. See, for example, the story of several autonomous driving organizations.
This is shockingly bad. Like so bad it has to be malice, right? To make requests over HTTP instead of HTTPS you have to do so intentionally, right?
> 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).
> Authentication tokens were sent over unencrypted HTTP
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?
Under strict hierarchies of business, workers must do what they’re told and lack organization with their peers to gain leverage over bad direction from ownership/exec
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
That's a bit of a false dichotomy - just because they follow Sam Altman doesn't mean they can be incompetent. OpenAI was successful because of the rare mix of leadership with a vision and competent workers to back it up. Sam leaves, the vision dies. Workers leave, the product dies.
Why would anyone even build a product on top of unencrypted HTTP these days? I don't even use my NAS over HTTP in my local network when I can use HTTPS instead.
"Nobody had time to figure out how to patch the letsencrypt runner to work with the only docker image that was compatible with the whatever web engine we run"
That’s what ChatGPT generated for us. There was a note saying something like „this is just an example. In a production environment please ensure proper encryption,“ but we ignored that.
I think it's funny that carl himself said in the announcement video that everything is end-to-end encrypted. Not just in transit, e2e! What a sh*tshow...
Like the article said, this is particularly bad considering how much they hyped up this feature. I first heard about it through MKBHD’s YouTube channel, in a video with almost 3M views. And they couldn’t even bother to validate that basic security measures had been implemented? Or maybe they just flat out didn’t care and thought nobody would notice, which might be even worse. I viewed Nothing as just an overhyped “Android phone but with lights on the back” but this has shown they’re a bit worse than that.
Just regarding the MKBDH video, he does explicitly call out the security issues inherent with the design at around 5:53, and credits it as a reason not to try this feature. So, yeah, it's wild that they considered this ready to ship.
But they didn't reverse engineer anything, afaik. Their Android app is just talking to a Mac Mini somewhere in a closet, logged in with the users Apple account (or so was stated in one of the interviews).
Does anyone know how many users a single Mac Mini handles? While I admire the hacker mindset, this solution seems incredibly wasteful so I am curious of its carbon footprint.
Okay, automating Apple account logins on a fleet of macOS VMs is still rarely treaded territory, so it takes some real technical chops, even if it’s mostly stitching together other people’s work. TLS termination on the hand takes <1hr following a guide, if you haven’t done it hundreds of times before…
Naah, if I would to attempt it my first try would be something like VNC (out of the box support) and Automator (out of the box support), or then some other tool to control mouse & keyboard.
The hardest part is probably keeping the duct-tapped stuff running.
How are you keeping all those sessions updated in real time? How are you parsing messages sent from others to be able to forward them to the user? How are you handling 'reactions' and 'threaded replies' and attachments?
You are dismissing a very hard problem with handwaving.
iMessage just stores messages in SQLite on macOS. They have a server process that runs on macOS and reads that database. So it’s not like they reverse engineered the protocol; they just read a local database in a standard, open-source format.
Some of the early research found "BlueBubbles"[1] mentions in some places, and the lack of TLS is almost definitely because BlueBubbles currently doesn't support TLS on its own.
Reading Sunbird's site makes it all feel like a scam. Their FAQs and Privacy and Security page are just chock full of what appear to be egregious lies. Both repeatedly state that messages are never stored, and end-to-end encrypted. It is not possible they didn't know this was a lie, because it is fundamentally built in a way that can't have E2E encryption (leaving aside the other horrendous security aspects).
> 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.
"Get hyped for the phone that will change the world!"
>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?
Apple should probably implement a brown bubble designation for anyone using iMessage and not able to pass device authentication. Kinda surprised the app got taken down so quickly. This is the type of app LE loves. Being able to surveil into conversations by piggybacking off the weak link
I realize this isn't in the realm of trademark law, but the green bubble is a mark that indicates you are talking to someone with an apple device, and not to someone through a shady poorly implemented hack.
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.
Yes, let's give corporations more power. Image bubble colour indicate the protocol you're using, and nothing more. It don't - and can't - guarantee security (many people learned this lesson with https).
But sure, let's let corporations super-copyright the colour green.
> the green bubble is a mark that indicates you are talking to someone with an apple device
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.
The other story people are missing here is that even if this wasn't a security issue, iMessage is adopting RCS next year, so the whole blue/green bubble thing will become much less relevant.
Even if RCS makes messaging with non-Apple devices more reliable, I‘d assume Apple would continue to use blue for Apple devices only, solely from a branding perspective. Despite all the things regulators are pushing them on, it seems reasonable that a brand can provide aesthetic-only markers for mutual users of the brand.
google has added e2ee in their implementation but it's not part of the standard, i think they use the signal protocol
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
Apple is implementing RCS as the actual standard, not Google's implementation. Which is the right move, if RCS is going to happen, Google should not be controlling it. Apple said they're planning to work at getting encryption build into the actual standard.
The whole blue/green bubble thing is how Apple got something like 80% market share in probably the most valuable demographic in the world - US teenagers. They are no going to let it become less relevant without a desperate fight.
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.
Apple is not changing anything about how iMessage works, it's clear in their statement in the article you linked:
> 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.
Right? Even if RCS is adopted by every major manufacturer, it's far too late to grab any market share. Everyone uses iMessage/WhatsApp now. Text messaging is dead, even if you can send gifs/stickers/group chats/video/etc.
Apple is almost certainly aware of this at the C-Suite level; I wouldn’t even be surprised if Tim Cook were briefed.
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.
iMessage is one of the primary moats keeping a lot of people on iPhone. I'm not necessarily as sure as the parent comment that the c-suite was briefed or anything, but I do think that iMessage exclusivity is pretty important to Apple
The risk here has never gotten near a point of being about Sunbird slowing down iPhone sales by allowing iMessage on Android. Beeper already has been doing a workaround for sending iMessages from other platforms for a while.
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.
That's probably a fact, and still a very interesting fact because it seems mostly US-related. In central europe, not tha many people use iMessage or even know that it exists.
The funny thing is that exclusivity would have been broken by the digital markets act if it actually were a moat here in Europe. But it's not, nobody cares about iMessage here. Even iOS users.
iMessage is a relic, most people in Europe use WhatsApp and alternatives in other continents. The whole blue/green thing is just Apple-driven hype to remember folks that iMessage even exists.
This is not the case. WhatsApp is only prevalent outside the United States and doesn't compare to iMessage in terms of features, privacy, security, long-term storage of messages and media, etc.
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?
Sounds like if you were running more than a couple of customers on the same hardware it would be easy for Apple to swat you. Since IIRC iMessage is authenticated with device keys so all VMs on the device would share the same key. 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.
> 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.
> 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.
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".
It's a bizare mindset. Facebook, WhatsApp, Signal, Telegram - none of them are forced to be interoperable. If I build a messaging protocol, there's no requirement for it to be interoperable. 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?
> Facebook, WhatsApp, Signal, Telegram - none of them are forced to be interoperable
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.
> 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".
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.
I still can't fathom why people would care in the slightest what their message bubble color was (I mean as a European I don't get iMessage at all, I use Signal and WhatsApp for the less tech-literate family of mine), it sounds like the most insanely petty thing to grab onto to care about.
The colors functionally denote the features available in the chat. In group chats, having a single non-iMessage user devolves the features available to the group chat to the SMS level. You also lose E2E and high res pictures and video.
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).
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.
146 comments
[ 2.9 ms ] story [ 205 ms ] threadObviously 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.
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).
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?
[1] https://youtu.be/ji5HwS3bhlU?t=352
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.
1: https://bluebubbles.app/
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?
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.
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.
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.
https://texts.blog/2023/11/18/sunbird-security/