|
|
This seems like it won't last, but it's AWESOME and I really hope you survive Apple's inevitable attempts to kill this. A universal chat application would be amazing, and will maybe help bring attention to the value of standards and interoperability (hopefully by governments/regulators).
|
|
|
 |
|
Have you ever received C&D for your work? There's a big problem of OSS projects being TOS-trolled by billion dollar companies and having to shut down out of fear.
|
|
|
|
You know, your question is very interesting: no, we didn't. Anecdote: we reverse engineered several Microsoft products and before Microsoft Windows 7 launch we were contacted by Microsoft QA and they offered us support to check if our software was compatible with it! BTW, our software was installed in millions of computers around the globe. For example, Trend Micro used our software for supporting their antivirus in Outlook Express and Windows Mail. Our Deviare Hooking Engine [1] was eclipsed when Microsoft Detours [2] turned to an MIT license and free. Even when our was superior in several ways. This is why I wrote that you should continuously fight for "adversarial interoperability". [1] https://github.com/nektra/Deviare2 [2] https://www.microsoft.com/en-us/research/project/detours/
|
|
|
|
I agree. After receiving a C&D from Meta for my OSS project (along with some other maintainers from some other projects) I strongly believe adversarial interop is a basic digital right that is required to fulfil the broken or revoked promises of web 2.0 If you know anybody that can help please let me know because I want to get back to maintaining the project.
|
|
|
|
Did you contact specific organizations such as FSF, EFF, etc and/or specialized lawyers? There were well known people defending itself or being plaintiffs. For example, https://cr.yp.to/export.html
|
|
|
|
What is the project? On what grounds did they C&D you?
|
|
|
|
Here's a write up of the legal threats timeline to our projects and how it coincides with their in house development of an npm package: https://gist.github.com/smashah/667d4d5cf31670ee87547450861a... They sent us C&Ds based on ToS. Meta has done this before to insta and android devs. Some never came back to their projects. It causes insane amount of stress and depression amongst the devs I've spoken with who went through the same thing.
|
|
|
|
What would they demand they cease doing? Publishing software? If the use of this software is against their rights in some way, the end users running it would be the ones in violation. Publishing original software is protected expression.
|
|
|
|
One prominent counterexample to this thesis is DRM circumvention software, which regularly gets taken down via DMCA notices. I wouldn't be surprised if Apple even invokes that particular law.
|
|
|
|
|
iMessage is not DRM. It is not protecting IP.
|
|
|
|
The component that tries to identify that you're accessing it from the right device isn't DRM? I don't think courts would agree with that.
|
|
|
|
It's not done for the purposes of content protection/DRM. There may be other laws it falls under, but I don't think the DMCA is one.
|
|
|
|
Interestingly, the reference implementation does seem to reference FairPlay, which is very much a copy prevention/anti-circumvention system (used for iTunes content, but also video encryption via HTML EME): https://github.com/JJTech0130/pypush/blob/main/albert.pyAssuming that DMCA does not cover API authentication (i.e. preventing unauthorized third-party clients from being able to access a server-side API – and I really don't know if it does or doesn't!), I wonder what the implications are if the same mechanism is used for both DMCA-covered DRM mechanisms, but also non-covered other purposes. My intuition would be that it can't be good to "multi-purpose" a DRM tool from a DMCA enforcement point of view, but maybe that was never Apple's plan, and they just used the most secure attestation technology they had available on each platform, which for Intel Macs might just have been software-only FairPlay.
|
|
|
|
ROFL.. Yeah, and when exactly should everyone expect to stop seeing DMCA take down notices that didn't abuse the system, willingful harm creators, and an appeals process that is an unfunny joke? Until then, it doesn't matter what the law says. They will abuse it, because PROFITS.
|
|
|
|
|
Emulation software isn’t wholly original as it needs firmware and software from the device so emulated. An iPhone emulator with no bootrom and no iOS isn’t very useful. An open source client for an API need not include any non-original works.
|
|
|
|
|
Note that a key cannot be copyrighted, but it can be considered a circumvention tool for access controls that protect other copyrighted works.
|
|
|
|
There is a very useful iPhone emulator with no bootrom and no iOS: https://touchhle.org/It targets games, so manages to be useful without having to emulate or re-implement the majority of the OS.
|
|
|
|
|
After digging in more I believe that is only done in that proof of concept. If that's the case then it's too bad they didn't go back and update the POC to avoid the need for the binary.
|
|
|
|
For the app it is probably just done server side.
|
|
|
|
What are the potential legal and ethical ramifications for developers and users in using such emulation methods or accessing private APIs?
|
|
|
|
> Publishing original software is protected expression. That means Jack Shit in a world where a lawsuit can ruin a person's life regardless of its legal merit, with zero consequences for the corporation that filed it even if it gets tossed out by a judge eventually. LPT: Live as if human/constitutional rights didn't exist. Because if push ever comes to shove, you will quite possibly find that they indeed don't exist in practice.
|
|
|
|
But there are consequences. Even if the financial costs are not meaningful to a big company, the backlash created by such actions can have wide ranging implications, from lost sales to loss of the public mindshare, to attracting legislative attention.
|
|
|
|
We are in an age of shamelessness and self-interest. There's no story in the world that will get people to stop using services like Whatsapp or Instagram. The only thing stopping these big companies is potentially setting a legal precedent that interop projects are legal. They can potentially win such a case as it stands because the targets for their threats are few and far between. If we as digital humans want to solidify this digital right then we need to have a unified front against threats like this. That means we need to have an OSS union behind which companies and individuals can unify if a precedent setting case ever does come up
|
|
|
|
Yes they demanded us to delete and stop working on all projects. At the time it seemed like a serious threat.
|
|
|
|
|
I saw an article on the topic where the reporter spoke with Beeper's CEO, Eric Migicovsky. He seems to believe that blocking Beeper might cause problems for legitimate Apple user's. Obviously that outcome is something he wants, but I still think its interesting. [0]: https://www.theverge.com/2023/12/5/23987817/beeper-mini-imes...
|
|
|
|
Apple maintains iMessage compatibility with devices that are long out of support, if Beeper Mini is sufficiently similar to the client in for example iOS 12 then it makes an Apple decision to break Beeper fairly expensive. Even if they do the work to publish iMessage updates for the old iOS versions it just buys a little time before the new version gets reverse engineered, and that at the cost of poor user experience for the people with those devices in a form they will directly blame on Apple. Given all that I suspect he's right.
|
|
|
|
> Even if they do the work to publish iMessage updates for the old iOS versions it just buys a little time before the new version gets reverse engineered There's probably a cliff in complexity. Once Apple starts requesting signed attestations from the secure enclave on the devices that have one, it's game over. They probably don't just yet, since still too many people use iMessage on first-party clients that don't have one, e.g. Intel laptops without a T1 or T2.
|
|
|
|
If Apple does start enforcing signed attestations, they will say that it's to reduce abuse. I have no doubt (being in the anti-abuse world) that spammers and phishing gangs will immediately begin using Beeper to spam iMessage users because this allows them to avoid buying an iOS device. With end-to-end encryption, Apple may also decide to roll out privacy-protecting client-side spam and phishing detection, which would IMHO be a really great thing.
|
|
|
|
The phone number registration https://blog.beeper.com/i/139416474/sending-and-receiving-me... will make it possible to enforce legal action against malicious and spammy messages. Note that iPhones already receive SMS spam and fraud just like every other phone. However, you are correct that the blue bubble is no longer a guarantee that the bad actor is using an iPhone.
|
|
|
|
> The phone number registration https://blog.beeper.com/i/139416474/sending-and-receiving-me... will make it possible to enforce legal action against malicious and spammy messages Like the legal action that is currently protecting us from robocalls? I don’t know if iMessage registration requires bidirectional SMS verification, though. If it does, that would be significantly harder to spoof than just caller IDs.
|
|
|
|
They do receive spam and fraud, but the numbers are orders of magnitude less than every one’s else BECAUSE it’s tied to hardware. I don’t know the details of how’s these guys got around it, but this is bad for the rest of us when phishing skyrockets.
|
|
|
|
I don't understand what you're talking about. I get far more SMS spam on iOS than I did on Android. Whether the number uses iMessage or not is totally irrelevant.
|
|
|
|
How can you get more SMS spam on one platform than another? With SMS they're just blindly sending to your phone number, your SIM could be in any device. They don't know what platform you're receiving it on.
|
|
|
|
Android is much better at blocking it. There were also differences in the platforms with how/when your phone number can leak to spammers and data aggregators, although I'm no longer deep enough into mobile OS or related CVEs to know current details.
|
|
|
|
Maybe Apple needs an even blue-r bubble to set apart the super attested users from the mere blue bubble peasants
|
|
|
|
they could call it "apple blue" and charge a few bucks a month for it. People love that stuff
|
|
|
|
They can desaturate the iPhone / MacBook Air users to disambiguate from the MacBook pro / iPhone pro / max users. Also device age in years will add hints of green hue. That way people know they're talking to someone who can afford to spend thousands of dollars on hardware every year.
|
|
|
|
wait is this where "green with envy" will come from?????
|
|
|
|
|
I imagine the next color being purple since that's a sign of royalty. Hail to the king baby!
|
|
|
|
> With end-to-end encryption, Apple may also decide to roll out privacy-protecting client-side spam and phishing detection, which would IMHO be a really great thing. Spam protection should be on the recipient, rather than the sender.
|
|
|
|
As we’ve learned very clearly over the last 20 years of commercialization of spam, that never works. The only tractable way to fight fraud and abuse is to impose cost.
|
|
|
|
The massive prevalence of physical junk mail would refute your argument that even a significant per message cost would dissuade abuse.
|
|
|
|
Scope and scale is important here, the amount of junk mail from business interests outside of my immediate region is not very high. If physical mail were free and you could send it from anywhere in the world, junk mail would be so much worse than it is. You couldn't run a lot of internet scams at the costs of physical mail and be profitable.
|
|
|
|
Probably not because even if the postage is free the paper, printing, envelopes, etc. are not.
|
|
|
|
How many pieces of physical junk mail do you get per day? Now how many spam emails do you get per day? Include the stuff that lands in your spam folder, because we're talking about cost to send junk mail here. I'm willing to bet the latter is much, much higher. It certainly is for me.
|
|
|
|
I disagree. Email has SPF and DKIM an what have you exactly because client side filtering doesn't work right. Mail gets dropped beforr the clients even get a chance to run filters. That's not to say that requiring remote attestation or blocking third party clients entirely is proportional, but Apple should (and does) play a role in spam prevention.
|
|
|
|
SPF and DKIM are ways of signing a message, but it's still typically up to the recipient or the recipient's mail server to decide what to do with that signature. And they're only checkable on the recipient's mail server because email isn't properly end-to-end encrypted, and exposes metadata.
|
|
|
|
SPF and DKIM can be checked client side no problem, assuming your mail server doesn't mangle the received-from headers. We just generally only use them as server-side filtering.
|
|
|
|
That's a brief statement which makes me think I'm missing something obvious, but it doesn't seem obvious to me. Would you please expand on that?
|
|
|
|
I think it's a bad idea to lock out unattested clients, and as long as third-party clients are accepted, spam will always be sendable. If you're not doing end-to-end encryption, you can catch it at send time by having the server reject the client for sending spam. If you're doing end-to-end encryption, the only options are the sender or the recipient, and attempting to block it at the sender would require prohibiting interoperability.
|
|
|
|
While I love the principle of accepting third-party clients, Apple clearly doesn't which make this argument fairly non-compelling for them.
|
|
|
|
There’s also the registration process that could be locked down and/or hardened. There may or may not be additional metadata (including out of band) that could identify first-party clients. I would think that’s the biggest issue right now. If spammers can register “real” iMessage accounts at scale without Apple hardware, Messages becomes less pleasant, very quickly.
|
|
|
|
Apple can break Beeper without relying on the secure enclave: If Apple devices just send their serial number (IMEI for their GSM products), their servers can refuse to talk to hardware they didn't manufacture.
|
|
|
|
|
Not if they require a certificate containing the serial number/imei/... + a nonce provided by Apple, signed with a private key/certificate stored in the secured enclave, loaded into the device when it's manufactured.
|
|
|
|
The GP comment was: > Apple can break Beeper without relying on the secure enclave: If Apple devices just send their serial number You have come full circle with the comment 4 posts up.
|
|
|
|
Beeper will know only a small number of valid serial numbers If it ever becomes popular, there will be a lot of duplicate serial numbers. That's easy to detect and ban.
|
|
|
|
How does this address iMessages sent from non-iPhone devices?
|
|
|
|
If in the data sent across (via Apple servers) the IMEI and serial no of the device are also transmitted, then Apple can in that millisecond query on their various lists/inventories that this device is legit (activated device + IMEI + serial) and if all lights are green, proceed to deliver, otherwise drop it. (perhaps different sets of data can be used, but it must be something that Apple already has, and the user has already provided (i.e. the iMessage email or the iMessage phone number, from the iPhone's enabled Settings)
|
|
|
|
As someone who once bought fake airpods on ebay, I can tell you that Apple can't do this. I spent a number of days with them where they were trying to work out if they were fake. The serial number was real but they were fairly sure the number had been taken from a real product and reused, but were unable to say for sure. I ended up just returning them (because of the ebay return window) but found it interesting that Apple couldn't easily check this, and was very aware of the issue.
|
|
|
|
you already have to do this to get certain apple services (including imessage) working on hackintoshes. turns out there's a really easy work-around: guess-and-check serial numbers on apple's web site until one works. they rate limit it a bit but you can usually find a working one without a terrible amount of hassle.
|
|
|
|
Do you mean that I now have a nice party trick - DoSing friends iPhone from sending iMessage? :)
|
|
|
|
If you have a FlipperZero, DoSing iPhone users with Bluetooth is a bit of fun!
|
|
|
|
|
|
That would make sense: because Apple have deeply coupled iMessage to the OS they can’t simply roll out a new version of the app with protocol changes that would block Beeper, they’d have to release entire OS updates. No matter the method it would be a scorched earth approach. I suspect the number of people actually using Beeper will be far below a rounding error for Apple.
|
|
|
|
Non-Apple legitimate users aren't the only concern for Apple: Once third-party clients are readily available, this makes spam much harder to filter. Right now they can probably just ban known-spam-originating devices, which is much more effective than banning iCloud accounts since there is a much higher cost to the spammers.
|
|
|
|
You say this like Apple doesn't release OS updates. Why are you putting that as some arbitrary limiter to what Apple could do to protect its walled garden?
|
|
|
|
They don't usually remove features as important as iMessage from older iOS versions. I don't believe they push updates to the iPhone 7 and older anymore, so they'd be unable to use iMessage.
|
|
|
|
I have a 6sPlus, and messages work just fine, and it may not be iOS 17, but I recently-ish ran an update for its OS that Apple deliberately updated (which you just know must have been an important update). You can stop making stuff up now
|
|
|
|
Uptake for OS updates is very high on iOS though right? I heard a while back that it is like 90+% in 6 months. (could be totally wrong on that can someone confirm?)
|
|
|
|
Uptake of updates is, uptake of devices isn’t. Here I have 1st gen retina iPad from 2012 which is on the latest iOS available for it - 9.3.5 (from 2016, current version is 17.1.2). As of today FaceTime and iMessage still work perfectly fine. That and reading the books is actually about the only thing it can do right now.
|
|
|
|
There’s a ton of devices out there unable to upgrade to the latest iOS. Obviously you can release point upgrades for old versions but I do wonder what the uptake of those is like. I’d wager there are a ton of very old iOS devices out there. At the very least many more than there are potential users of Beeper.
|
|
|
|
anecdote of 1, but i have a 6S+ that is kept up with any updates it receives which is 15.8. there maybe some devs that have older devices that they intentionally keep at even older versions, but if someone is using an old iDevice as a daily driver, they're probably still more likely to run the updates. at least, that's my reaches up and grabs for an opinion
|
|
|
|
I'm not that familiar with ios apps, can they not push out updates to individual apps?
|
|
|
|
On iOS many of the individual apps e.g. Mail, Notes you can delete and then re-download from the App Store. And as part of Security Updates they have patched vulnerabilities just in the relevant apps. So there is nothing technical stopping them. It's just been customary to treat iOS as a product where all features ship together.
|
|
|
|
I don’t think this actually physically deletes the app, given that it’s back once you reset the phone. It’s most likely just hidden/deactivated until you “reinstall it from the app store”. Actual updates require the app binary/bundle to be mutable.
|
|
|
|
Apple never patches security vulnerabilities in individual apps except for Safari, and they’ve stopped doing that too.
|
|
|
|
Not the OS-included ones, afaik. Some Apple apps are through the AppStore normally, which can be updated independently (i.e. TestFlight, despite its deep hooks).
|
|
|
|
Why did google break out Google Play Services as a separate app, was that when they started integrating more with third-party android phone suppliers, and they didn't want to have to wait for OS upgrade cycles from slower-moving companies?
|
|
|
|
Probably they originally did it because Android has high-assurance embedded use-cases (compare/contrast: Windows IoT Core) where you want to strip out everything possible from the attack surface. But mainly it's because base Android (AOSP) can be arbitrarily modified by the OEM; and Google doesn't want to have to trust installations of Google Play Services that have been arbitrarily modified by OEMs. (Especially because those versions would likely all act differently-enough from one-another that they would be forced to loosen their server-side, network-traffic-fingerprint-based "authentic Android device" detection that allows them to ignore/block bots pretending to be Android devices.) By shipping Google Play Services through the store, they can ensure that, on devices that run it, it's exactly the same code for every device that runs it, with no OEM alterations. (And they can also include various checks to reject devices that would try to alter that code at load time. This is the real reason why e.g. Huawei devices are blocked from using Google Play Services — they try to patch unspecified parts of the Play Services code while loading it, "breaking the integrity of the platform" from Google's perspective.)
|
|
|
|
Man, that's contrived. Really its simple: Google seperates out Play Services so they can harvest user data from virtually all Andoid devices. It lets them market Android as OSS while still reaping the benefits of closed source data scraping.
|
|
|
|
Google can harvest data from "virtually all Android devices" just by offering Chrome, Google Search, and Gmail as apps. Almost every Android user has at least one of those apps installed. They don't need Play Services itself to spy on you on top of that.
|
|
|
|
derefr cited one reason but there's another that's relevant to this thread: updates. In the Android model handset manufacturers and carriers decide when (or if) to ship updates. Google distributing their apps through the store gives them a way to roll out new features to a reasonable portion of their user base.
|
|
|
|
will iMessage Contact Key Verification coming in iOS 17.2 break Beeper — or just make it super annoying like the “not a genuine Apple part” warning when replacing a screen or battery
|
|
|
|
> because Apple have deeply coupled iMessage to the OS No they haven't. On my Mac it's just an app and a reusable framework. There is nothing stopping them releasing it on the App Store similar to Mail.
|
|
|
|
> There is nothing stopping them releasing it on the App Store similar to Mail. In the sense that the app is just a wrapper around a system framework, sure. But changing that framework would be an OS release.
|
|
|
|
Mail is also deeply coupled to the OS. The app itself does very little.
|
|
|
|
|
Messages is the same on OSX and iOS. It's not deeply integrated into the iOS by any normal definition. It's just shipped together.
|
|
|
|
Messages has a bunch of special privileges on iOS, which is why they had to add the whole Blastdoor protection framework and why it's such a juicy target for sandbox escape exploits.
|
|
|
|
Nope. It just happens to be on everyone’s device and usually enabled
|
|
|
|
Yes, and when it's enabled it has more privileges than most other apps, doesn't it? But yeah you can still remove the app. Btw, maybe related, on iOS I have "app privacy report" enabled, to show me a list of apps and the recent entitlements they used. Every Apple app, even those that don't need access to them, is shown as having recently accessed my Contacts. I find this weird. Anyone know why they do that? e.g. I've never even used the Health app and yet it's accessing my Contacts for some reason.
|
|
|
|
It’s basically the same as any other app, there are some special permissions it has to integrate with the OS a bit better but nothing too interesting. Not sure what’s going on with Contacts but it might be a bug?
|
|
|
|
The Messages app in macOS is less capable than the Messages app in iOS. It cannot even edit sent messages.
|
|
|
|
It can, by right clicking the desired message to edit. This is in macOS Sonoma, and I believe was a part of Ventura as well.
|
|
|
|
Oh interesting, I have a 2015 MacBook Air. Wonder if the feature is not available on whatever macOS version I have.
|
|
|
|
It’s a Ventura and later feature and your MacBook Air probably topped out around Monterey or earlier. 2016 MacBooks Pro also didn’t make the cut for Ventura.
|
|
|
|
|
It's not too hard to think through - They would need to accept and verify a flag from messages that the copycats can't reproduce. At the very least that would require a client update from anyone using official iMessage clients, which covers many millions of devices. Unless they're able to hook into already existing flags/keys on the devices since they already verify application signatures and a whole other host of things. Apple can probably do it, but much like jailbreaking how fast can they release breaking changes?
|
|
|
|
They could probably require a new check but whitelist already registered numbers.
|
|
|
|
What's brilliant is they get press either way this goes down.
|
|
|
|
i understand no such thing as bad news/publicity, but if the 800lb gorilla squashes the little guy, then that's some pretty bad news. with the recent Twitt...er,X and reddit debacle with 3rd party apps, that 800lbs is pretty powerful when it wants to be edit, because i used the wrong turn of phrase
|
|
|
|
is it powerful? In both cases X and reddit, nothing meaningful happened. Apple could block any device without attestation then offer a discount for those on old products to upgrade. Now bad news is good news.
|
|
|
|
On the contrary, the EU law that enforces interoperability should put some wind under this project's wings.
|
|
|
|
|
But EU interoperability laws are cancelled out by DMCA (aka EUCD). That’s why reading a DVD with VLC has always been “technically” illegal. If Apple is able to update the protocol in such a way that it requires some kind of signed attestation from the secure enclave (basically a DRM) they’ll get legal protection. Also. Nobody uses iMessage in the EU. It’s all WhatsApp here. Blue bubbles are an American obsession.
|
|
|
|
The recently enacted DMA requires interoperability. Unless Apple wins its case against iMessage being classified as a gatekeeper service, it'll be required to support interoperability. I'd be surprised if tricks like hardware attestation were compliant, unless Apple allowed other companies' hardware.
|
|
|
|
Furthermore some implementations cannot provide hardware attestation, so it probably couldn't be limited to implementations which can, if the EU really means "interoperable"
|
|
|
|
However, iMessage (the software) is already interoperable with SMS and MMS.
|
|
|
|
What exactly is considered bypassing DRM in the case of Beeper Mini, and what copyrighted content is the DRM protecting? This might be news, but the DMCA laws don't allow you to restrict software which is compatible with your own, especially if the competitor never used your code.
|
|
|
|
> Blue bubbles are an American obsession. No it’s not, it’s an obsession by a small number of users, not widespread at all.
|
|
|
|
|
The timing is potentially clever. Apple has committed to supporting RCS next year, and will face regulatory pressure in places like Europe. Even if short lived they could onboard a lot of Android users and then use RCS once it’s supported.
|
|
|
|
I wonder if these events are connected. Imagine Apple hearing through the grapevine that someone had a proper iMessage implementation and that they planned to release it for Android. Perhaps one way to get in front of that would be to commit to RCS. One could imagine the Nothing Phone events having the same cause.
|
|
|
|
>A universal chat application would be amazing It would be, however would not bet my chatting account history on a phone number. Phone number does get lost over time. Email is more reliable, but may be a private key for authentication instead. Also a modern day chat app, one would expect to have chatting over bluetooth as well Internet such as Briar, and chatting over Tor such as Quite would be much more needed.
|
|
|
|
I'm not so sure about email being more reliable than a phone number. I believe more people have a contract with their cellular provider than with their email. Free email accounts could be banned with no recourse.
|
|
|
|
We had universal chat applications & standards and interoperability in the 2000s. Pidgin (et al.) + libpurple allowed users to use a singular application for chat--even the proprietary protocols. We also had (& still have) XMPP from that era which many of the big boys like Google jumped on, killed, then jumped off (EEE?). Are we just repeating history ( https://ploum.net/2023-06-23-how-to-kill-decentralised-netwo...)? There’s an XKCD about inventing yet a new standard despite us having good ones for decades…
|
|
|
|
Given how many large chat systems are based on XMPP, it should be possible to select a set of standard extensions to interoperate with each other. Sadly, I don't see it happening.
|
|
|
|
True. But developers should push in that direction anyhow since it still means interop for those in that camp already… and considering how well those large systems have scaled, it’s a good idea.
|
|
|
|
This was never enough for me. On paper Pidgin did the trick, but you still had to remember which of your friends preferred which platform, you had multiple "friend" entries for the same person, many used silly pseudonyms that they certainly didn't go by IRL, you had no way to tell if your friends actually were monitoring each of their accounts (I uninstalled aim months ago, have you been sending me messages on it?), you couldn't have group conversations across networks without mental gymnastics or compromise, the features offered on each platform were inconsistent, both on their native apps and the features pidgin actually implemented. That to me is not universal chat, that's just welding 10 chat apps into one, somewhat poorly. That being said XMPP was well on the way to becoming something universally supported, and though the protocol itself was way more complicated and crufty than I'd like, it's a shame that Google particularly abandoned it for really no reason.
|
|
|
|
Since those services all died off my memory is a bit foggy, but I recall stacking contacts in one with Adium & being able to prioritize in that meta contact which service they provided. But I really only ever used it for two-person conversations so I had no experience with the group situation. Even still, a multi-chat app was a vastly better user experience than running several independent applications (with the cost of missing ‘advanced’ features & occasional outages as protocols needed to be reverse engineered & the proprietary providers had no incentive for backwards compatibility). > Google particularly abandoned it for really no reason What most annoying is seeing Big Tech now trying to write a new standard to comply with the EU instead of using the existing standard they abandoned that already has all the mileage & scaling looked at. Instead all the same hurdles will have to be overcome yet again, just like the current growing pains of Matrix meanwhile XMPP is still quietly holding strong for massive chat/presence systems.
|
|
|
|
I agree that it's better than using multiple applications, but today I just use one (for personal conversations at least, Slack for business and Discord for communities is a bit different), which is texting.
|
|
|
|
My texting is scattered. I’d prefer it to be all XMPP, but I engage with Signal, & Mattermost, IRC, & Matrix on a regular basis… & largely this is a result of me just quitting the other chat platforms that most are using here (LINE, Facebook Messenger) which has made communications more difficult for others. I could run gateway to puppet all those accounts which is a lot closer than Pidgin was at unifying it all, but I’ve been a bit lazy to set it all up (& if the common gateway tool wasn’t Python I’d be more thrilled to touch it).
|
|
|
|
What is currently not interoperable between the majors mobile OS makers?
|
|
|
|
Well messaging for one thing... Some others: - Find my device features including Bluetooth ping networking (airtags, Tile, Android's upcoming network) - Airdrop/Nearby Share - Bluetooth LE proximity pairing (at least I doubt this works when pairing cross ecosystem) - Carplay/Android Auto - Airplay/Google Cast
|
|
|
|
|
See my comment below for why this isn't the interoperability I'm interested in. I don't want to use Apple's service, I want Bluetooth tag pinging to be standard across Apple, Tile, and Android ecosystem devices so that they all work equally well regardless of the percentage of one brand of phone or another in the area the tag is pinging from.
|
|
|
|
Is there a way to SEE the location of my Apple manufactured Airtags from Android?
|
|
|
|
Does this still work? that repository appears to be abandoned.
|
|
|
|
Apple did actually open up the network, there are plenty of third party devices that are 'Find My' compatible. It's intended for integration into things like bikes or scooters. You can buy tags from AliExpress for $5 that implement it. I've been using a few for a couple of months, and no issues so far.
|
|
|
|
It would be preferable if Find My capable smart devices could forward tag pings on to non-Apple owners and vice versa. Right now, Find My is strong in the US where iPhones are very common, but it works worse in places where most phones are Android, and vice versa for Androids in the US versus abroad. You are referring to being able to track devices via the Find My portal on Apple.com or your Apple devices, but I am referring to being able to merge the networks so that Apple devices will forward pings onto Android's Find My network and vice versa.
|
|
|
|
> that repository appears to be abandoned The last commit and release is from october.
|
|
|
|
- Carplay/Android Auto Are there any headunits that only support one or the other? The cheap Chinese unit I got last year supports wireless for both. It would be nice to have an open protocol though, so third parties could develop alternative UIs.
|
|
|
|
Or so that there isn't a duopoly lock in for a new phone OS or an android fork that doesn't have Google Play Services on it. Just like Google Cast and Airplay, this should be an open standard, not a pair of incompatible proprietary locked down solutions.
|
|
|
|
|
okay but this "interoperability" is legitimately hard without degrading the user experience because apple's unique level of control allows it to produce a superior product with more consistency. airdrop is best-in-class; open-source solutions like wi-fi direct are dumpsterfires with trash UX. LE proximity pairing is, i believe, a custom chip apple put in airpods (h1 chip) because bluetooth is stuck in 2005 and still doesn't have easy pairing, full quality two-way audio, etc. carplay/auto have different feature sets and airplay is an objectively easier experience than google cast. the EU is fundamentally interested in these changes regardless of consumer welfare. this is sour grapes because they fail at tech by every conceivable metric and by degrading everything to a common feature set and commoditizing certain standards, they hope to give domestic companies a prayer. that it prevents innovation and improvements is merely a secondary concern for the hard-headed anti-Americans in brussels.
|
|
|
|
> apple's unique level of control allows it to produce a superior product with more consistency Another way to read this:
Apple has a superior product because they perform anti-competitive practices and don't allow other companies to out-product them. And when they do, they buy them/shut them down before anyone is the wiser.
|
|
|
|
editorialization. you know as well as anyone that restricting your feature development to your own platform rather than doing a retarded design by committee helps one innovate faster.
|
|
|
|
We don't need to speculate; internal emails from the Epic trial discuss the motivations. https://www.theverge.com/2021/4/27/22406303/imessage-android... In short, Eddy Cue proposed in 2013 that Apple owning the best-in-class messaging app would be a win, and even mentioned the cost being low. Phil Schiller shut him down, arguing it would remove a barrier preventing iPhone parents from buying their kids Android phones. That reads like anti-competitive motivation to me. In particular, it looks like tying, where two unrelated products are connected artificially. The wikipedia article on anticompetitive behaviors has a section on tying, and mentions another case involving Apple that bears some resemblance involving iPods being artificially restricted to only playing tracks either from iTunes or direct CD rips. So I think the anti-competitive angle has some real merit. The innovation claim, though, I have a harder time with. I don't see how releasing Messages for Android implies design-by-committee. They could just release it, like Beeper Mini just did, but without the reverse engineering part.
|
|
|
|
They could definitely just release an app for Android instead of opening the protocol, but as an Android user I'd reject it for the same reason I reject my Apple friends suggesting we all use WhatsApp or Signal: I don't want different conversations living in different chat apps for no reason. That to me is the bad old days of Facebook Messenger+Twitter DMs+SMS where I had to remember which platform each of my contacts prefers to use and then deal with missing features and an inconsistent experience all the time. As much as I think Beeper's work on iMessage is important, apps like that do not and have never solved this problem. Because then you have different contact identifiers to contend with, the inability to make groups amongst those users, differing features, and the list goes on. If you look closely at what I'm saying here, it's easy to compare it to what iMessage users say about why Android users create problems for them, and that's true. That's why messaging interoperability is important.
|
|
|
|
Interestingly enough, in my life, WhatsApp has just won. Everyone I know uses it, people I meet when traveling use it. Pretty much every Airbnb host tries to contact me on WhatsApp. My physio right now in Malaysia organizes all my appointments on WhatsApp. But I only travel East of the UK, so Europe/Afria/Asia, I have no idea what South America is like, and can guess that it's not as ubiquitous in North America based on these threads. I cannot remember the last time I've received a non-spam SMS. The whole iMessage thing feels so alien to me. My girlfriend is an Apple fan-girl and has never used iMessage in her life. I kinda wanted to see what was special about it and when I asked her about it, she had no idea what I was talking about.
|
|
|
|
Innovation is a good thing, but for many items on this list there's no more innovation happening. Google Cast and Airplay have been mostly unchanged for the last ten years, and the same is true for Airdrop and Nearby Share. You can definitely make the argument about innovation in the messaging space, but RCS is very extensible. RCS Encryption definitely needs to be standardized, but I recommend you check out how Google layered it on top of RCS [1] including handling fallbacks for corner cases like switching your RCS client away from Google Messages before the system realizes it. This is to say that RCS is pretty flexible, the key is handling the fallback paths in the extension design and working with other vendors to standardize promptly, so we don't end up with the same kind of broken mess that the carriers made. [1] https://www.gstatic.com/messages/papers/messages_e2ee.pdf
|
|
|
|
> apple's unique level of control allows it to produce a superior product with more consistency Honestly, this reads more like marketing spin to cover anti-competitive behaviour than a forum post.
|
|
|
|
i am not, nor have i ever been, employed by apple. i use none of their products as my primary devices. stop breaking the forum rules.
|
|
|
|
Have you used Nearby Share on Android? It's IME just as good Airdrop, the only real issue is that it's not baked into Windows PCs like Airdrop is with Macs (confusingly MS has their own thing called Nearby Share for Windows devices). I've actually had less issues with Nearby Share, my iPhone stopped sharing to my mini after a few months but could talk to everything else. Android solved BT pairing in a superior way years before with NFC pairing. Touch two things and paired. I could get my airpods to pop up on my iPhone 1/10 times. Finnicky, overhyped crap IMO. Only reason NFC pairing didn't catch on is Apple holding the NFC chip hostage for the sole use of Apple Pay.
|
|
|
|
yes, i primarily use an android phone. nearby share is janky and terrible. additionally, the fact that it's not built in everywhere is a ding from the standpoint of an end user.
|
|
|
|
It is built in to the Share dialog, so it is accessible anywhere the Share dialog is shown. And when you copy something to clipboard, the popup at the bottom includes Nearby Share. Where else would you like to see it? Certainly not every iOS app has a custom Airdrop integration either. Every time I've nearby shared it's worked just fine. What phone do you have?
|
|
|
|
It's really not. Just make the "superior product" interoperable.
|
|
|
|
But it often not that simple, anyone who has done cross-platform development can tell you this by heart, it doesn't matter what you do, you must adhere to the lowest common denominator. Interoperability isn't free.
|
|
|
|
I'm not asking them to implement these things on every platform, but it's not difficult to make documentation they certainly already have about protocols available.
|
|
|
|
Protocols calcify when you don't control all the endpoints, consider the case in point, iMessage, it is seems like there is some security implications for spoofing iMessage for any random number, yet, apple's recourse is very limited if it can't update all the endpoints (devices). The same is also true, say about AirDrop, if apple makes it "Open" and they have to make a breaking change for security or whatever reason, they can't feasibly even make an update available for non-apple devices let alone enforce it. Now "Apple" has broken your non-apple device and along with it their reputation. Open is good, but the cost is non-zero.
|
|
|
|
By that logic the Outlook for Windows team should be responsible for patching Gmail for Android. This argument is silly. You could use this line of reasoning to justify why all computers should use the same OS from the same vendor. Of course then you'd have a monoculture where implementation bugs that cause vulnerabilities are universally exploitable, instead of only exploitable on machines running that vendor's software.
|
|
|
|
This isn’t uncommon at all when dealing with development that requires interoperability. Far from it, actually. If a part of your user base uses another service, you’ll inevitably have to add workarounds specifically to cater to users for that service. It’s just a fact of life when multiple groups have to implement a spec. If you aren’t willing to add workarounds, users will think your software is broken when they should be blaming someone else. For example, Firefox maintains a few workarounds for websites that ship in the browser. They aren’t the web developers responsible for the sites but someone has to make it work. Interoperability is not free.
|
|
|
|
Not free, but worth it for messaging to solve the real pain points that iMessage and Google Messages users deal with while trying to communicate across the aisle.
|
|
|
|
You're free to make value judgments, but for a business to follow through, the economics of it must be sensible. As a consumer, I prefer a secure messaging platform over an open one any day of the week.
|
|
|
|
>A universal chat application would be amazing
Can't Whatsapp, Signal, Telegram, Viber and other chat apps be installed on both Android and iOS?
|
|
|
|
> A universal chat application would be amazing You mean like WhatsApp, Signal, Telegram and dozens of different chat apps available for both Android and iOS?
|
|
|
|
Beeper is an app that unifies all the messaging protocols you mentioned (and others) into a single app. They are not introducing another protocol. Universal in this context is referring to the ability to use a single app across protocols rather than the ability to use a single app across platforms.
|
|
|
|
I miss the days of jabber being able to senselessly talk to aim, msn, yahoo, icq, etc. All chat contacts in one account.
|
|
|
|
|
Ok, I get it. It's what EU mandated and from March '24 all major chat apps have to be able to communicate with each other.
|
|
|
|
|
This downloads from GitHub and ’executes’ specific code points in what looks like a proprietary Apple binary, ‘IMDAppleServices’. Where was that binary sourced? Could you provide more context for what is performed at the hard-coded call-in addresses in your code? Does this relate to how you’re presenting a unique device identifier to the network? Do all clients share one identifier, or is it generated per Apple ID? Have any Apple IDs been locked out of iMessage during your development and testing?
|
|
|
|
I am not the developer but I also looked at that binary to help the project at some point. It's taken straight from OS X 10.8 (more precisely from an Update Combo on their download portal). It's calling NACInit, NACKeyEstablishment and NACSign functions from it (which have no entry points but with reverse engineering the offsets have been figured out). They are themselves relying on OS X system functions to get device information. The Python code is using Unicorn to emulate it and patch the calls to those functions to stubs returning pre computed values from a Mac machine (stored in a data.plist file). All clients are using the same machine identifier. IIRC, nobody did get its account locked but if the Apple ID has not been used at all it might fail (it depends on the donor device that generated data.plist, if it's a hackintosh for example it will likely not work).
|
|
|
|
That seems like a problem. Emulating the protocol is okayish-to-gray but having the binary there will just be a straight DMCA. Wonder what the actual app is doing since this is just the PoC.
|
|
|
|
I don't think the finer legal points matter too much. If Apple wants to sue them, they'll sue them, regardless of legal merit. And I suspect Beeper is betting they can make their case from a more philosophical angle, such that it's irrelevant what grounds Apple cites when suing them. Beeper will fight it either way. I'm an Apple user who has no need for this app. But I really appreciate that Beeper has the balls to reverse engineer the protocol and build a business around it while fully expecting a lawsuit. That's some old school hacker shit and I'm here for it. Apple tried and failed to sue Corellium for emulating their hardware, and now Corellium has a viable business around it. I don't see why Beeper should fare any differently. They just need to be prepared for a fight, both legally (lawsuits) and technically (ongoing game of cat-and-mouse).
|
|
|
|
Reverse-engineering and documenting protocol is OK. Implementing protocol according to the documentation is OK. Copying and modifying binary with proprietary license is not OK.
|
|
|
|
How do you run the binary if that's not OK? In order to install it, The binary gets copied from the installer (dmg/zip/app store/CD install media), and then to run it, it gets copied from your hard drive to RAM, so that's clearly okay in some circumstances. Furthermore, once it's on my hard drive, I can copy it over and over again in random places on my hard drive for funsies and the operating system will gladly cooperate. Once it's on my drive, I can go in with a hex editor and randomly change bytes for funsies. It's on my hard drive. Am I then not allowed to delete the program from my system? If I use shred to delete it, which will set the bytes in the file to zero, or format the hard drive, am I breaking the law?
|
|
|
|
In my very limited understanding, distribution is the key. It’s legal for Apple to distribute Apple binaries. It is not legal for someone else to distribute Apple binaries. Copying a binary from installer to app folder: not distribution Putting the binary on a USB and giving it to your buddy: gray area, not worth prosecuting, but maybe technically distribution Uploading the binary to a GitHub repo titled “Apple binaries here”: obviously distribution
|
|
|
|
Which is weird if you think about it. If I buy a car, give it a paint job, mount some LEDs, and a new sound system, I'm totally within my rights to sell it. I can't say that I'm Ford or Honda when selling this modified car, but I'm totally allowed to sell it.
|
|
|
|
Yes, and this analogy is even more valid than usual, because unlike most software where each binary is an exact copy of all the others, in this case each binary is actually unique to a device. But it's more like a ticket, or an NFT. It's a unique blob that was sold to you. You should be able to transfer it. Apple's best argument here might be that the blob is meant for one person, and distributing it this way is like sharing a ticket to the cinema between multiple people. I can't enter the cinema, then come outside and pass you the ticket so you can enter it too.
|
|
|
|
In that case the easy way out (and what plenty of Hackintosh/console hacking/emulation/etc. communities have done since the beginning of time) is to just download the file directly from Apple when the app starts up the first time or have an “import BOOT.bin here” button you use to activate the app. If someone can source the binary you need to get the app to work I think that’s DMCA legal.
|
|
|
|
Those are all fine but it's not the context of the copying in the discussed scenario.
|
|
|
|
I dont believe Apple would sue. I think they would just change the protocol to block this from happening.
|
|
|
|
I think you might be right, especially with the heat on them from the EU right now. It's faster to play the technical cat-and-mouse game for as long as possible.
|
|
|
|
There's also a very small chance that the EU would sit idly by and watch Apple wreck compatibility.
|
|
|
|
>Beeper will fight it either way. That sounds nice and all, but what happens when the first bill comes due from their legal team?
|
|
|
|
I imagine they'd use some of the $16m+ they raised in VC money to pay the lawyers...
|
|
|
|
I have a hard time believing that the folks who were smart enough to do all this work somehow forgot that lawyers cost money
|
|
|
|
i don't disagree, but nobody can compete with the money Apple can spend. not every David can find a Rainmaker when competing against Goliath. Goliath still wins a lot. He was a champion after all
|
|
|
|
I’d donate to a legal fund on this personally. I think a lot of people and large corporations would like to see Apple have to make concessions here. I think if it comes to it, Apple will wind up looking very bad in a trial. Their behavior here is deeply anticompetitive. iMessage is just too important to modern text communication to be as locked down as it is. If Apple doesn’t want to make an Android app, they should at least make an API so other developers can.
|
|
|
|
> iMessage is just too important to modern text communication to be as locked down as it is.What do you mean; if a private company creates something, and enough people buy/use it, at some point it becomes a common good? I like the idea of iMessage being open, but I don't like the idea of forcing Apple under government threat to open it
|
|
|
|
I don’t know what you mean by “common good” in this context, but if a company has a dominant market position and uses its power to cripple competition, then it falls within antitrust laws. iMessage is so important today, especially to young Americans, that its exclusivity to iOS has become a significant barrier to Android or other operating systems from being competitive. It’s up to regulators and the court system to decide whether that is a violation of antitrust law. But if it is, then yes, the government should force them to open it. That’s what it means to enforce antitrust law.
|
|
|
|
Apple does not require any consumer to use iMessage, nor do they make installing alternatives such as Whatsapp difficult. iMessage is simply a messaging option. This is in stark contrast to how MS treated IE back in the antitrust lawsuit days. The fact that lots of people prefer to use iMessage -- despite myriad easily-accessible alternatives -- doesn't feel anticompetitive in the slightest; in fact making a product that people freely choose over similar alternatives is the definition of winning competition.
|
|
|
|
The Messages app is the only one everybody has no choice but to use though, since it’s the only one on iOS that does actual SMS, which is needed for interacting with businesses and in other scenarios. It’s also the most discoverable one and the only one that comes on the phone by default. It has a privileged place in the ecosystem, and that’s why it’s a potential target for antitrust regulation.
|
|
|
|
I feel so old. What is it that I'm missing out in iMessage that is so important? Honest question, I've been texting since t9 and have never owned an Apple device.
|
|
|
|
It’s really nothing special. I personally use WhatsApp with most of my friends. The problem is when you have one person in a group that is on Android when everybody else is on Apple. This causes the iMessage conversation to use SMS instead. To signify this in the app, texts appear as green bubbles instead of blue, so it’s obvious when it happens. This is bad because SMS is totally obsolete. It causes images and videos to be shared in extremely low resolution, along with problems of messages not getting delivered reliably and other missing features. So effectively to the iPhone user, Android users very visibly cause group chats to be super crappy in iMessage. This is not the fault of the Android user really, because it’d work way better if Apple supported RCS like Android phones do, but many people have a very strongly negative impression of Android due to this. In fact, some iPhone users put social pressure on people with Android devices due to this in the form of excluding them from group chats or complaining about how they cause problems. Apple has been perpetuating this problem because it suits them. People know this, but it’s Android and Android users that suffer regardless due to Apple’s dominant market position.
|
|
|
|
It provides a much better group messaging experience than SMS (you can see who’s in a group and add and remove people), delivery/read receipts, better image quality, is encrypted (although that gets somewhat negated by automatic iCloud backups), and is free as long as a data connection is available. Of course many other messengers offer most of these features too, but for some reason, no alternative has been able to establish itself in the US.
|
|
|
|
iMessage was heavily integrated into the ios flow when sms was the dominant mobile text messaging system. It's not special, and that's the point. It just worked the way people want texting to work as smart phones gained momentum, and iPhones have so much of the market share that it's way more irritating to use a separate messaging app when you can't change the default integration on ios. I miss the convenience of heavily integrated iMessage comms at least twice per day.
|
|
|
|
Interesting, I use both Messages and a few third-party messengers, and I wouldn't say that Messages is integrated more deeply with iOS, in the way that e.g. Safari and Mail were for a long time (before you could re-associate http and mailto URLs). The share sheet just shows my most-frequently-used messengers, as well as direct contact names for my most important contacts, no matter what messenger they're actually on. The only thing I can't yet do on my third-party messenger is initiate messages from my Apple Watch, but that's presumably due to a lack of a native watch app more than anything.
|
|
|
|
Yes, governments can require interoperability and can limit monopolies. That's how antitrust laws work, like it or not. But if you want to get all libertarian, why should companies be able to use government power (as in courts, DMCA and the like) to shut down smaller companies that reverse-engineer their protocols?
|
|
|
|
I'm a major libertarian, and you have a great point. Apple should maintain their competitive advantage via technical means or let more cooks in the kitchen.
|
|
|
|
Which is pretty much where "if you can't innovate, litigate" has its roots.
|
|
|
|
|
The Streisand effect will certainly boost enrollment if Apple sues.
|
|
|
|
There’s no need for Apple to react to this project at all. Eventually, someone will send spam using this app, at which point automated systems at Apple will “console ban” the hardware identifier shared by all of the app’s customers. The project presumably has a library of valid hardware identifiers collected and ready to go, and eventually that’ll be drained by spammers faster than revenue versus device purchasing allows for. Apple can just wait silently as the app exhausts their pool of hardware identifiers, each banned by pre-existing anti-spam automation, without ever acknowledging their existence.
|
|
|
|
Followup: One day after widespread press, Beeper has apparently triggered Apple’s protections and is temporarily offline until they rotate identifiers and perhaps IPs. Apple has neither acknowledged that Beeper exists, nor stated whether Beeper was blocked by automated or a manual process. This happens every year with third-party iMessage clients, but we’ll see how it goes for them. Perhaps it’ll be different this time.
|
|
|
|
Apple may not buy WhatsApp will. If there's ever a commercial or OSS third party WhatsApp voice client I would expect they will try to send their Perkins Coie dogs after the project. They've already done it to many oss projects, terrifying Devs from continuing their work
|
|
|
|
The app is not redistributing it, it just requests a server to get validation data (since anyway the actual library loading involves patching every system function, making the function independent from the host device, see [0] if you want to see how it's stubbed to run on Linux using a data.plist file), and thus there is no need to emulate it on device. [0]: https://github.com/Dadoum/imd-apple-services
|
|
|
|
My (very limited) understanding is that this "validation data" is related to the certificate generation (see [0]). So if the app isn't emulating this on device, and instead calling out to a Beeper server that is hosting the Apple binary, is this a potential security risk? Is it possible to use the data that gets sent off device to derive the client encryption key? If so, that would be a huge security hole in this implementation, completely negating their claim of maintaining secure E2E encryption. [0]: https://www.reddit.com/r/beeper/comments/18duom1/is_beeper_m...
|
|
|
|
I didn't implement all the IDS stuff, but I am pretty sure the certificate is not used at all to derive keys for anything related to iMessage. I think it is used to attest that the device running it is running Apple software, and it may generate keys to make that an identifier to Apple (probably also because the user may not have any Apple account, so they have to generate another identifier for that purpose).
|
|
|
|
Doesn’t this already have precedent? Nintendo used to check for the existence of their logo in cartridges before loading them so that anybody who wanted to create an unauthorised cartridge for a Nintendo system would have to reproduce their logo and infringe on their copyright. I’m pretty sure the court ruled that reproducing the logo for the purpose of interoperability was fair use.
|
|
|
|
There are reverse engineering/interoperability exemptions to the DMCA so it may not be that simple. So would be curious if they have already sought legal advice which says they are in the clear.
|
|
|
|
they raised $16mm. I assure you they've talked with a lawyer or two.
|
|
|
|
If they actually just took a binary from OSX and stuck it into their app it probably wasn't the best lawyer
|
|
|
|
I believe it's server-side: not distributed.
|
|
|
|
Sam Bankman-Fried raised $1.8B, yet we know how that ended even with lawyers available, so... We'll see.
|
|
|
|
I hope we get to a place where people like this simply generate an OpenPGP key/OpenSSL certificate for a pseudonym and just throw this stuff up on .onion and .i2p domains. A place where DMCA and copyright literally cannot be enforced because it's impossible to.
|
|
|
|
This reminds me of the near-ish-future "Rainbow's End" by Vernor Vinge, wherein instead of giving out phone numbers or email addresses or screen names (identifiers), people give out opaque GUIDs [0] that act as communication handles with capabilities baked in. So, you could give out one to friends that allows people to open a synchronous voice channel to you, but give out one on your business card that just allows people to send text messages to you. The book doesn't talk about it too much, but presumably these handles could be limited-use (time-based or only granting a capability to send a certain number of messages) and could be revoked. I know it would probably be off-putting to give each person I meet a different GUID for contacting me (kind of like telling them your email address is <their_name>@<my_vanity_domain>), but it might reduce the spam I receive. [0] if you're searching the ebook, they're called "golden enums" in the text
|
|
|
|
Not sure how likely is that considering that Beeper is an actual/company startup which seems to have received funding from YC? However, considering that I'd except they'd know better than to just outright take a binary from MacOS and use it in their app (assuming that's actually the case..).
|
|
|
|
It's not impossible, just currently not worth the tradeoffs of enforcing. There's nothing stopping governments from passing laws holding IP address owners responsible for the traffic they originate. At that point VPNs and Tor exit nodes will stop allowing illegal activity. VPNs are already moving this direction, no longer supporting port forwarding ie hosting content on bittorent.
|
|
|
|
If that becomes a problem and they get enough funding, I'm sure they can spend a few days / weeks reverse engineering the functions they need. At this point it just needs some effort, not some crazy research capabilities.
|
|
|
|
Given that these are cryptography-related functions, I feel like symbolic execution could yield the actual algorithm they use.
|
|
|
|
It's probably not even that hard. If some block looks like a crypto section, you can likely match the relevant constants to the algorithm. It's not like Apple will use some super custom solution there. "Where is the AES and how is the IV generated" is more likely question.
|
|
|
|
It’s already in the works, someone has already made a lot of progress on this front on pypush’ Discord server.
|
|
|
|
I already had a significant respect for Beeper (Cloud) as a technical product. The backend being Matrix with open source bridges was a great choice. This write up adds so much more to that respect. It would have been easy to botch this, it would have been easy to do a worse implementation that would have caused problems for users whether they cared or not, but Beeper seemingly took the time to get right. Congrats to Eric and the team on the launch!
|
|
|
|
Did you get permission from Apple to connect to their servers? Google Play does not allow apps to connect to 3rd party APIs without consent. The relevant policy can be found at: https://support.google.com/googleplay/android-developer/answ... "We don’t allow apps that interfere with, disrupt, damage, or access in an unauthorized manner the user’s device, other devices or computers, servers, networks, application programming interfaces (APIs), or services, including but not limited to other apps on the device, any Google service, or an authorized carrier’s network." From what I understand your app connects to APNS without permission from Apple. I have personally had my Google Play Developer account banned for making an app that connected to a 3rd party service
|
|
|
|
I'm surprised Apple hasn't cut them off yet. They must not be able to for some legacy reason. I suspect the only way to cut them off would be to cut off all the older phones like iPhone 3GS as well. >the iMessage protocol and encryption have been reverse engineered by jjtech, a security researcher. Leveraging this research, Beeper Mini implements the iMessage protocol locally within the app. All messages are sent and received by Beeper Mini Android app directly to Apple’s servers. The encryption keys needed to encrypt these messages never leave your phone. Neither Beeper, Apple, nor anyone except the intended recipients can read your messages or attachments. Beeper does not have access to your Apple credentials. >We built Beeper Mini by analyzing the traffic sent between the native iMessage app and Apple’s servers, and rebuilding our own app that sends the same requests and understands the same responses. https://blog.beeper.com/p/how-beeper-mini-works
|
|
|
|
Is this specifically unauthorized, though? The user is permitted to use Apple's services, and Apple has, as far as I know, not announced that third party apps may not use their services.
|
|
|
|
If Apple files a complaint with Google it will definitely get taken down under this clause, so I think the only way it will stay up is if Apple doesn’t care. With the trouble Apple goes through to ensure you are accessing APNS from an Apple device including obfuscating the signing algorithm and requiring unique hardware identifiers I think it’s safe to assume they don’t want 3rd parties accessing their services.
|
|
|
|
Even Signal pitches a fit if you use a third-party app with their servers. It's a common (and unfortunate) practice.
|
|
|
|
what does this mean? plenty of 3rd party signal clients exist (flare being a well-known one); signal explicitly factored out a libsignal presumably to _encourage_ this. i’ve run multiple 3rd-party signal clients, even alongside the official apps, and never seen any problems or warnings. [flare]: https://gitlab.com/schmiddi-on-mobile/flare
|
|
|
|
|
By calling that a “fit” it sounds like you’ve an axe to grind. That was pretty damn polite for a heated mailing list discussion.
|
|
|
|
I use my own personal fork of the official Signal app (I absolutely despise the idea of going back to having a separate SMS app), so I do. Sort of.
|
|
|
|
> It's a common (and unfortunate) practice. It would be nice if third party clients were allowed to connect, but it's totally understandable if they don't want to allow it. Servers cost money, and misbehaving client apps that you have no control over sound like a pain in the ass.
|
|
|
|
> I have personally had my Google Play Developer account banned for making an app that connected to a 3rd party service. Well what did it do with the service?
|
|
|
|
I had app that connected to the Snapchat API and let you upload photos with custom effects and photos from your photo album before that was a feature (not sure if it is today, I don't use Snapchat)
|
|
|
|
Great job! Just from taking a quick look at this, what you have here is much bigger than iMessage itself. This could literally allow things like Universal Clipboard to work on Linux and Windows - by using the method presented here to access the iCloud Keychain and generating Continuity keys and placing them there - then the iPhone will broadcast its clipboard data encrypted with those keys via BLE. If I understand all of this correctly.
|
|
|
|
I had been wondering where Beeper's route to profitability was, but if they can get Continuity and AirDrop stuff working with Windows that will be an instant no-brainer subscription for a lot of people (including me), so I guess it works out.
|
|
|
|
It works over wifi, but you might be interested in KDE Connect [1]. It can do clipboard, remote input, file sending, command running, etc. on Windows and Linux. [1] https://kdeconnect.kde.org/
|
|
|
|
Would like to try it out but the developer decided to force sign-in with google and I have removed that from my AOSP build.
|
|
|
|
Beeper is a really cool idea by some cool people (people behind the Pebble smartwatch) but I've resisted using it for fear of bans. I don't want my Slack/Discord/Instagram/AppleId/etc to get banned for using something not allowed under the terms of service. How are people who use Beeper dealing with this? Are you just using dummy/test accounts that you don't care about or are you just rolling the dice. I would like to live in a world where I could use Beeper without worry but I don't feel like we currently live in that world. Am I wrong?
|
|
|
|
I’ve been using Beeper as my main chat client for multiple years and haven’t had any issues with account blocks or bans on any of their supported platforms. I have Discord, Signal, WhatsApp, iMessage, and LinkedIn connected. There are technical issues at times but they are well communicated and usually resolved pretty quickly.
|
|
|
|
I've used Beeper for about a year with Facebook, Signal, Instagram, Twitter, LinkedIn, and iMessage. Instagram signs me out once a month or so for security suspicions, but I just reconfirm my account with 2FA. Other than that, no issues.
|
|
|
|
> I would like to live in a world where I could use Beeper without worry but I don't feel like we currently live in that world. Am I wrong?I've been using Beeper for close to six months, and it's been a dream.
|
|
|
|
Since they've been on waitlist-mode for several years, it's not currently easy to try out in any case.
|
|
|
|
|
|
They’ve opened invites from existing users
|
|
|
|
Beeper mini does not require an apple account so there's not much harm Apple can do
|
|
|
|
If you have an Apple account, why are you even using Beeper? I guess it might have some advantages for convenience (multiplexing chat apps), but is that the main selling point right now? I'd imagine the target market is Android users who want to talk to people on Apple Messages. So they can just create a new Apple account, right? (Isn't that kinda hard anyway, though? You need to tie it to billing, etc.) And if that gets banned, who cares? It's not like they were using it for anything else anyway.
|
|
|
|
I sit in front of my work laptop which is signed into my work apple account. My iPhone is signed into my personal Apple account. I cannot iMessage from the keyboard because they won't play together. I've been using Cloud Beeper since early summer, and it makes the two apple systems play nice together. I also have a Windows machine signed in to it, but that's a nice to have.
|
|
|
|
Wait, how does this work? Is it using Handoff and sending from your phone, or Beeper is just a GUI and you've extracted a token from your personal phone to use with Beeper on your work device? Btw, this is mostly unrelated, but do you work for a large company? I'd assume most security teams would have a problem with a setup like this.
|
|
|
|
Neither. Their cloud server is a farm of Mac Minis or similar. Then Beeper Cloud is basically a proxy from the app to that data center.
|
|
|
|
Ah I see. I thought I remembered reading about that on Twitter (in the context of people criticizing it as false advertising). So basically this Beeper mini is the "proper" implementation of full e2e encryption, while the cloud service was the bridge to get them here?
|
|
|
|
That's my understanding, yeah. I don't love my apple ID being signed into a box I can't access, so would love to see THIS service go cross platform.
|
|
|
|
I'm more interested in the multiplexing aspect, yes I'm iOS/macOS so I don't care about the iMessage aspect alone though I'd love to pull all my chats into 1 extendable app.
|
|
|
|
An Apple account isn't particularly useful for messaging without an Apple device to message people with.
|
|
|
