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).
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.
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.
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.
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.
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.
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.
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.
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.
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’d pay for a blue Apple checkmark!
I imagine the next color being purple since that's a sign of royalty. Hail to the king baby!
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.
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)
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!
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.
Non-Apple devices could just lie
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.
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.
I believe you can bruteforce/generate IMEIs somewhat easily. https://github.com/bstein/py-imei-generator
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.
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.
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.
I’m talking about the iPhone.
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.
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.
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?
fwiw it hasn't been called "OSX" for awhile now
Mail is also deeply coupled to the OS. The app itself does very little.
In the sense that the app is just a wrapper around a system framework, sure. But changing that framework would be an OS release.
I'm not that familiar with ios apps, can they not push out updates to individual apps?
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.
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.
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.
Apple never patches security vulnerabilities in individual apps except for Safari, and they’ve stopped doing that too.
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.
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?)
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
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.
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
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.
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
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
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
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.
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
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.
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?
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.
Another Apple ecosystem that can be used by non-Apple devices. OpenHaystack [0] has been working well for quite a while.
[0] https://github.com/seemoo-lab/openhaystack
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.
The last commit and release is from october.
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?
- 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.
Sadly, yeah- even in OEM units.
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.
One of my companies lives from this kind of things so it would last if someone could fund it. More food for thought: "Reflecting on 16 Years of Work on Adversarial Interoperability" (now, more than 20...) [1]
[1] https://blog.nektra.com/2020/01/12/reflecting-on-16-years-of...
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.
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.
This was tried by apple. https://www.engadget.com/apple-drops-its-lawsuit-against-a-m...
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.
They are though. https://news.ycombinator.com/context?id=38534247
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.
Depends on whether you consider a private key an "original work": https://github.com/JJTech0130/pypush/blob/main/albert.py#L16
The situation seems very similar to the AACS key leak back in the day: https://en.wikipedia.org/wiki/AACS_encryption_key_controvers...
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.
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.
"Section 1201 provides for felony liability for anyone commercially engaged in bypassing a DRM system: 5 years in prison and a $500,000 fine for a first offense."
So it's even worse than the risk of being taken down. Way worse.
https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-w...
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.
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.
Tell that to Alexey Pertsev.
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?
On the contrary, the EU law that enforces interoperability should put some wind under this project's wings.
Exactly what I thought
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"
No it’s not, it’s an obsession by a small number of users, not widespread at all.
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.
it might even be the reason for it's existence
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.
Jabber transports, they were great.
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.
Relavent xkcd: https://xkcd.com/927/
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…
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.
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.
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.
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.