The concerns here are valid but the fact the authors label this being about Apple Intelligence and Private Cloud Compute really devalues their credibility in general.
Siri doesn’t have any of the new AI features, the prompts they’re using have been around for years, and private cloud compute has always been about Apple Intelligence generative features.
They also end it with trying to sell their service around AI which further devalues it, and even trying to give it a name like "AppleStorm".
I think some of the points are valid, but I think the over emphasis on Siri vs Private Cloud is massively overblown. That to me is just the nature of a transition like this and eventually more if Siri will likely fall under "Apple Intelligence" since it makes sense that they would have a single platform on the backend.
Then there is this header:
> "End-to-End Encryption? I’m Not Sure"
Well.. it is still end to end encrypted. Nothing about using Siri to dictate it changes that since you know... your on one of the ends. It is like saying that me taking a screenshot of the conversation somehow broke E2E.
That isn't to say that the concern here is not valid, but there are so many examples of things being twisted and manipulated to get you to use their product that I have a hard time really understanding what is an issue and what isn't.
Like ok you made an app using SiriKit using Apple's recommended settings (which may be recommended for a reason). But do you have the ability to have them not go to apple's servers if you configure it a certain way... it seems the author just ended with "Well it happens when I made this app" and never looked further.
They are arguing in bad faith. They clearly know how to disable the relevant subset of these features. They don't do this upfront because they would have nothing to write about otherwise.
As a user, you can configure these settings in the UI. You can use the defaults command. They can be configured using a configuration profile/MDM. You could block the domains based on their associated feature, which are publicly documented by Apple. [1]
It's like complaining about Windows telemetry without bothering to configure the registry (or even open the settings menu).
Smartphone OS manufactures like Apple and Google do not allow strong secure features to black domain or IP addresses. There are attempts at cheep hacks to use VN or accessibility work a rounds but they can be overwritten by the OS and they prevent use a firewall and VPN at the same time.
I have used encrypted DNS profiles on iOS to block them at the resolver level. However, the correct thing to do is to disable the feature in a configuration profile. You can also block them on macOS using Little Snitch or similar.
No, you sometimes can't use two apps on iOS that attempt to configure DNS and a "VPN" for local filtering purposes at the same time (the latter is often a glorified hosts list).
You absolutely can use encrypted DNS and/or a VPN (or Private Relay). None of these have bearing on using an application firewall or pf on macOS.
I think people are unaware of the difference between Apple Intelligence and Siri - they even have the same colour glow now. Also, can you always tell if it's Siri or Apple Intelligence handling a request?
The only privacy screen on macOS and iOS is during oob or after OS updates, and it does not make a distinction. As the OP post highlights, there is no way to avoid said telemetry from being sent or configure it in Settings. So all this is not only shady but quite illegal.
You normally don't notice tbh. Switching PDS is entirely invisible to the frontend. There's a lot of self hosted PDS users (since it's basically a small go router + sqlite) but there's also bigger community PDS projects being spun up including blacksky and northsky.
As for frontends, there's a bunch of them and a lot of them focus on changing the UX. But for self hosted "bluesky", there is https://deer.social which is a forked client that still relies on the bluesky appview/backend and there is https://zeppelin.social which is downstream of deer social but also runs their own appview independent of "big bluesky".
If you go to that URL, you'll see the landing page for the atproto PDS software.
Edit: Ah, and seems Kuba is hosting a directory of profiles using their own PDS as well, lots of examples over there: https://blue.mackuba.eu/directory/pdses
Biggest one right now (excluding the default one) seems to be atproto.brid.gy, which has 40393 accounts.
Not only is the bluesky network highly centralized right now, its UI is designed to perpetually lock users into the main bluesky server. Even if you use your own identity, when sharing the URLs to the posts via the UI, the URL defaults to bsky dot app domain, which will break if the author ever moves to a second server.
2. If you change your handle (for did:plc, did:web can't do this because DNS) it used to break links but nowadays this isn't a problem because handle resolution respects historical handle naming (I think it works by post+handle age but I can't remember).
3. Also if you share posts using the did syntax instead of handle syntax (which bluesky seems to be slowly changing over to, at least profiles do this now), it's stable regardless of handle changes.
4. If you want to switch frontends, you can use an extension or app like at://wormhole to do so. UX for this should improve over time but that's a big "eventually".
5. Hopefully the at:// URI format catches on but that's a long ways away given that browsers make using custom URIs an absolute nightmare.
The default Bluesky frontend uses bsky dot app URL when you use the "Copy link to post". Now if one day, you lose trust in this server and switch your PDS, this link continue working depends on this very non-trusted server. If this server is profit-seeking, it can break such links.
An extension or another app is not the solution, and neither is the new at:// URI format, because what matters is the relationship the default server sets up with its majority of users. Most bsky users will lose their traffic to their own posts and therefore will be locked-in, cementing this one server to be the dominant one in all perpetuity. We will therefore get all the patterns of monopolistic abuse that we have seen elsewhere.
Android phones don't support it globally so saying that Apple is "forced" to compete where Android doesn't proves the point that they're doing more than needed.
Just because you can provision Felica cards outside of Japan doesn't mean that you can actually use them. It's not really global support if you can add Suica in the US and then not use it. More likely is that Felica Networks agreed with this logic and Apple is only paying the license fee for JP devices, or has some side deal about not delineating between regions. If Apple didn't support Felica, it would just move more users in Japan onto physical cards or Android.
On recent US SKU iPhones — don’t know how recent —- you can add a Suica card directly to Apple Wallet annd use it anywhere the physical card is accepted. No weird regional deals.
iPhone just wasn't going to exit the curious gadget status and become a first class citizen in the Japanese phone market without it. Same for emoji support and flick inputs and lots of those little things.
They were never forced to compete in the sense that no one is forced to be first class citizen anywhere. Apple just wanted to be by its own free will. That's technically correct.
But that part is on Apple. They could have made it Japan SKU exclusive. It isn't solely because it's their policy that an iPhone is universally an iPhone and there will never ever be Verizon backplates or brown box CostCo specials with plastic backplates. No one else cares, so everyone else make FeliCa enabled versions as Japan specials.
