They want to keep people in their walled garden so bad, that they'll transparently attack attempts to make things better for everyone.
There are too many hardware and software decisions they have made in recent years to list, but one decision I think representative of the company's pursuit of profit in spite of its users interests is the fact that iPhone cases do not fit models from year-to-year, even for the small refreshes.
[0] https://techland.time.com/2013/11/12/for-one-night-only-sili...
Many of us willingly pay a premium for that. It has its benefits and nobody forces you to lock yourself into their ecosystem. Crying about it when you willingly pick something outside of their defined ecosystem and have some weird expectation of access is baffling.
Cool, stay in the walled garden if you want to. That doesn't mean other users need to be forced within in it with you, too.
The vast majority of people aren't thinking "Wow, I love how Apple takes away my freedom and forces me to use apps even if I might want to use something else", they're buying an iPhone because it's shiny and is what they're familiar with.
Those people deserve to be afforded user freedom and to own the devices they purchased.
Go up to a random stranger and ask how much it would be worth to them to be able to sideload apps or have a bash terminal on their iPhone. They wouldn’t even say “zero dollars”, they would just laugh.
I am a professional iOS developer and I also couldn’t possibly care less.
The average user doesn't give a crap if you can sideload some random app that is only needing to be sideloaded because its likely dodgy as hell.
Also if someones using an iOS device and is skilled enough to need to sideload then they'll know full well they CAN sideload by deploying an app from xcode.
Not a single one of the items you've mentioned has to be a 'walled' experience when interacting with someone not inside the ecosystem, it's bizarre that you'd even think it would be unless you've got very little understanding of how computers work in 2023.
Also your reply suggests you haven't actually understood what I wrote
Your reply suggests you never understood what my original post was refering to.
Network effects absolutely do and Apple knows this. Otherwise they wouldn't go out of their way to distinguish non-Apple users in chats.
Using an analogy from a person I follow on Mastodon: “For $1.99 per month, I will give you a QR code that tells 24 Hour Fitness that you are their customer when you really aren't. You can work out for free whenever you want.”
And:
“The Department of Justice is investigating 24 Hour Fitness for banning the people I charge $1.99 per month for access to all 24 Hour Fitness locations without actually being a member. What a world!”
> Beeper uses real registration data from real Macs and iPhones. These credentials are being used by real people, with real Apple accounts, to send real iMessages.
I doubt it'll have an impact though, and this will likely get shut down just as other methods have been.
One of the things I liked about earlier OS X and Macs was the potential to do hacky things, and the plethora of tools to accomplish just that on your Mac.
Turns out hacking and tinkering has the potential to impact their bottom line, so no more of that without Apple getting in the way to make it inconvenient to impossible.
this hasn't changed, has it?
When iMessage is under their control (it is their creation after all), they (Apple) can be sure that what is happening is exactly what users expect. We can know that the messages are encrypted E2E without someone in the middle.
With Beeper, there are no guarantees of that anymore. I could be messaging a person that is using Beeper, or some other tool, and the messages are being intercepted by that other tool's server and decrypted there. I'd be _expecting_ E2EE but not getting it.
Perhaps Beeper has the best of intentions, but if you _allow_ Beeper you will need to allow everyone or then it gets even messier than it already is.
When I see a blue message, or know I'm in an iMessage chat I have certain expectations. If you allow outside apps to interface with it like Beeper is doing then my expectations would need to be adjusted and I would no longer be able to trust that what I expect to be happening is always happening.
Beeper's integration is open-source. Anyone can audit it. That means that Beeper requires less trust from its users than iMessage does! Nobody gets to audit iMessage.
> Perhaps Beeper has the best of intentions, but if you _allow_ Beeper you will need to allow everyone or then it gets even messier than it already is.
And if iMessage's protocol is E2E encrypted, then that is already guaranteed to be secure from MITM. The only new attack surface would be the endpoint, AKA the messaging app itself. The only way to guarantee coverage for that attack surface is to audit every messaging app, including iMessage. That is not the case, so there is no change in expectation.
---
Your entire argument boils down to this: You trust Apple, and distrust everyone else: therefore, as an iMessage user, you should just throw E2E encryption out the window, and use unencrypted SMS instead!
Beeper is only ONE of the concerns I mentioned. As I said, Beeper may have the best of intentions, but not every solution will be. And if you allow Beeper, you're going to have issues with others doing the same.
iMessage is end-to-end encrypted. Here's how you can MITM it though, if you allow third party tools like Beeper.
For an app like this to work it uses a 3rd party app, because it has to fill the gaps of work being done by iMessage, which means it's handling keys, handling encryption, as well as all the user facing functionality.
How do we know that all of these tools are not MITM'ing the solution? It could just as easily not E2E encrypt the data and decrypt on the server, before sending it to you via the app on your device (an Android device, or web app, or whatever you're using to interact with Beeper as a non-Apple device user). I understand Beeper operates locally, but even in that scenario a malicious app utilizing this same functionality and code could send the decrypted data elsewhere, requiring no server MITM, just a modified client side app.
To an Apple user, we would have no way to tell that the user on the other end is potentially compromised. This _does_ change the trust model, does it not?
Again, Beeper may have the best of intentions, but allowing Beeper to operate would mean allowing others to operate and they may not have the same intentions.
Allowing these types of tools absolutely changes the trust of the solution.
And to be clear, yes, we can view the Beeper code since it's open source. The real concern is other tools utilizing the Beeper code but in a modified way. Just because Beeper's code is open does not mean all solutions are open. And on my end, as an Apple user, I have no way of knowing someone is using a "best of intention" app like Beeper, or a maliciously modified fork of it.
OK. I agree to drop the word, "even". I could have phrased that more generosly. Here's a try: "Did you consider the rebuttal provided in the article?" I didn't want to be redundant by repeating it.
---
Let's look at this with some perspective. There are 3 ways this can pan out:
1. What Apple wants: Everyone buys an iPhone and uses iMessage.
In this scenario, the security of literally everyone depends on their trust in one party (Apple), because iMessage cannot be audited. It's also never gonna happen, so there's that.
2. What Beeper wants: 3rd party apps can send and receive messages with iMessage, and all messages are E2E encrypted.
In this scenario, trust is only needed when the app at each end is closed-source. Open source apps can be audited, so conversations between them can be known to be secure. Messages between closed and open source apps must rely on the trust of one closed source app.
This is worse if one or more 3rd party apps is closed source, because that introduces more parties who demand trust.
This is better if all 3rd party apps are open source, because it allows guaranteed secure comms between users of open-source apps. It's a neutral change for iMessage users, because they must trust the same number of parties (just Apple).
3. What we got: iMessage is only encrypted (if Apple is trustworthy) when both users are using iMessage.
This is worse, because iMessage users (and everyone who messages with them) are practically guaranteed to send and receive unencrypted messages. We have thrown the baby out with the bathwater.
On top of that they’re acting like spoiled children used to getting their way, pointing fingers, because they ‘lost’ the instant messaging war.
https://www.theverge.com/2023/9/21/23883609/google-rcs-messa...
Their extension is proprietary and unavailable to anyone except themselves and Samsung. This means that Google is making a bad faith argument as they’re not advocating for RCS, but their own incompatible version of it.
https://www.phonearena.com/news/rcs-support-on-iphones-what-...
And Google has said that they plan to switch to MLS [1]. Releasing their own E2EE spec more widely at this point would be pointless.
[1] https://security.googleblog.com/2023/07/an-important-step-to...