I'm curious how does the second hop work? are the third parties contracted by Apple to provide the service? What's in it for them?
I presume the answer is “money”
Apple's iCloud+ “VPN”
361–370 of 413 posts
Re: Apple's iCloud+ “VPN”
#362Earlier quoted context omitted.
If you believe this you have misunderstood how iCloud works.
Would you clear the misunderstanding then?
iCloud Backup works differently to all other iCloud services.
How it all works is documented: https://support.apple.com/guide/security/welcome/web
Re: Apple's iCloud+ “VPN”
#363Earlier quoted context omitted.
iClouds lack of encryption basically invalidates all other promises they make.
If you believe this you have misunderstood how iCloud works.
OP is talking about the security of iCloud backups and that using this feature cancels out a lot of the end-to-end encryption that Apple talk about heavily in their marketing.
What is being misunderstood?
Re: Apple's iCloud+ “VPN”
#364Not being able to circumvent region locked content makes it only 50% useful for me unfortunately. I often end up using Epic browser which has a built in proxy from other countries to watch region locked content. I would recommend it for non-confidential stuff.
Re: Apple's iCloud+ “VPN”
#365My experience with this so far was... mixed. - This breaks DNS resolution for company-internal domains. - This routes all my traffic through CloudFlare or another CDN I might or might not trust (yes, the IP is hidden, but not the data) - it significantly slows down my internet access on my location. - it tends to turn itself on again without my intervention especially the last point is very problematic for me
To use it you're clearly using early beta software. Clearly it isn't going to "turn itself on again". I turned it on and actually forgot I did. Performance is decent here. I mean of course it's going to be worse than native, but that's the compromise. As to trusting Cloudflare -- what do you mean? You understand your connection is still TLS end-to-end encrypted (presuming that's what we're talking about), right? I me…
> To use it you're clearly using early beta software. Clearly it isn't going to "turn itself on again".
Of course I’m talking about the beta version. But I can assure you that once I found out that it interferes with internal DNS, I turned it off (it’s on by default on the current betas) and a day later it was back on.
That’s what I meant with „it turns itself on again“
Re: Apple's iCloud+ “VPN”
#366This is interesting. I think overall I approve as it benefits people by default. It does mean you now have to trust Apple since that's the first hop. However you're already doing this when you spin up your AWS Lightsail Wireguard instance, say. AWS can see ingress and egress traffic and so you just need AWS to not be part of your threat model. Same here. Though I dont see this as too much of a problem since it applie…
> your AWS Lightsail Wireguard instance
This will still be your fixed IP, not adding much to your privacy.
Re: Apple's iCloud+ “VPN”
#367Earlier quoted context omitted.
> This breaks DNS resolution for company-internal domains. Is this not the case for any VPN or proxying service? In fact, it could even be a security flaw if your internal domains were accessible on external VPN style endpoints?
Also it’s developer preview 1. People like the OP who gripe about bugs on such an unfinished product are the reason why Apple doesn’t make those first builds available to anyone but their registered developers for the first month.
I have of course reported the issues using the feedback app, but judging by previous experiences with other apple betas, I wouldn’t hold my hopes up of any of this getting fixed.
There’s value in talking about issues early as it allows admins of corporate networks to make adjustments to their infrastructure (like introducing split dns rather than just have *.internal.example.com resolve to internal addresses) to be prepared for the eventual launch of this feature in September
Re: Apple's iCloud+ “VPN”
#368Earlier quoted context omitted.
> Props to Apple for the design of this service. I was under the assumption that it was mostly Cloudflare Warp repackaged with a different name?
That would be an incorrect assumption. It's an onion that goes to Apple first and then to a variety of external vendors -- Fastly, Cloudflare, Akamai, and likely others.
So, the difference is that they encrypt data before they send it through?
I'm not sure if my assumption is completely incorrect. While it's onion routed, the grunt of the work seems to be done by "trusted partners".
Re: Apple's iCloud+ “VPN”
#369Earlier quoted context omitted.
Are you really arguing that because child pornography exists, no large company should offer ETE photos? Despite there been reasonable solutions like bloom filters and client sided hash detection, so that known child abuse material can be detected, without it needing to compromise the privacy of 99.99999% of users? And that photos present some of the most sensitive materials on your device: - geo-IP location showing b…
> Despite there been reasonable solutions like bloom filters and client sided hash detection, so that known child abuse material can be detected, without it needing to compromise the privacy of 99.99999% of users? This is not a good argument. “Known child abuse material” is the tip of the iceberg. There’s nothing stopping people from creating new “child abuse material”, and the people who are doing that sort of thing…
So because there are pedophiles, we should build backdoors in all cloud image hosting services?
Should we build backdoors in AES because there are terrorists in the world?
Re: Apple's iCloud+ “VPN”
#370Earlier quoted context omitted.
Are you really arguing that because child pornography exists, no large company should offer ETE photos? Despite there been reasonable solutions like bloom filters and client sided hash detection, so that known child abuse material can be detected, without it needing to compromise the privacy of 99.99999% of users? And that photos present some of the most sensitive materials on your device: - geo-IP location showing b…
In the bloom filter example, what device calculates the hash inputs for the bloom filters? If it's the server, then the server needs a copy of the image to check. So is it the client? If so, how can you prevent a malicious client from forging their hashes to be those of known-safe images? Not saying it's not possible to build an E2E image storage service that also has the protections society tends to demand. Just say…
Apple has direct-from-bootloader control over all of their hardware, unless you boot Linux on a Mac (in which case you don't get iCloud).
So a 'malicious client' doesn't need to be part of the threat model here. And also, if you really stretch your argument, that's like saying we need to outlaw Linux and open source software because malicious actors can modify the code.
The whole idea that society demands content providers compromise ETE just because of child pornography isn't something I've heard of being 'accepted as common truth' outside of this post.
Some politicians demand it, but I thought at least amongst tech, there's the recognization that strong, *unbreakable* encryption is important.
There's an implicit obligation to build services and technology that is resistant to abuse, but that isn't an argument to not implement ETE.