Everything Apple announced: Tor-ish Safari anonymization. Cloaked iCloud addresses. Cloud CI/CD. And more Apple on Monday opened its 2021 Worldwide Developer Conference by promising a raft of operating system and privacy improvements – including a relay system to anonymize Safari connections, and randomized email addresses for online account signups. Expectations were lower than those at last year's event, which heralded a major …
"When browsing with Safari, Private Relay ensures all traffic leaving a user’s device is encrypted, so no one between the user and the website they are visiting can access and read it, not even Apple or the user’s network provider."
About that. The user's ISP is cut off this interaction, but the rest of that's likely wrong or definitely wrong. The feature supposedly integrates with Safari. Unless that's just a brand name for a disconnected feature, there's a good chance that the only traffic which goes through the system is traffic generated by Safari. That is the important stuff if you're worried about people stealing or compromising your data, but it isn't all of it. The rest of it includes plenty that can be used to fingerprint you. That can help to reassociate your traffic with your device if the attacker is sufficiently motivated.
The more important part is the suggestion that Apple can't associate your traffic. It's complete rubbish. They can do so by comparing logs of traffic usage. Such techniques are used for Tor already, and they work there too, but they're not reliable when used there. The reason: in order for it to work, the attacker must operate all the relays in use and Tor is made up of a bunch of independent relays so you have to spend a lot and hope that the random path generator has put the victim in your sights. Apple's system doesn't use independent relays. They operate every one of them. They can easily use attacks like this if for some reason they decide to. That is without considering that they could just log while forwarding your connection from relay 1 to relay 2. It's not using an open source protocol, so we can't confirm that they're not.
This is not a Tor-style privacy protection. This is an Apple VPN. It's probably fine as a VPN, and if that's all you need, it's probably safe to use. Just don't expect more from it.
Yeah, you kinda have to take Apple's word for it for now when its people say "no one, including Apple, can see both who you are and what sites you're visiting."
Presumably the Apple security guide [PDF] will be updated with details of Private Relay for cryptographers to study and assess. That guide is usually detailed enough to determine the viability of a design.
C.
From a reading of comments by Federighi, it seems they are using an “independent, 3rd-party relay,” though unnamed.
https://sixcolors.com/link/2021/06/federighi-on-apples-latest-privacy-features/
This seems to indicate that the user info & destination is obfuscated to the relay, also, thus not relying on a single-point to funnel traffic like typical VPNs.
@doublelayer: I agree, and I'd add that either this assurance is wrong, at least to the extent it is aimed at the end user, or a significant chunk of enterprise security (or parental controls, for that matter) - validating/filtering connections, botnet detection, and such - goes out of the window.
Time to send iPhone Sixes and SEs to death row along with a bunch of perfectly good computers which will not be allowed to run a stripped down but still secure version of the new OSes. No updates for the browser is death for a phone. Hello landfill, prepare a welcome my otherwise functional old iPhone SE.
Not only will iOS 15 run on anything that will run iOS 14, but in a change of policy iOS 14 will continue to get security updates.
I haven't looked closely at what Macs will run Monterey, but it does include the Mac Mini 2014, which rumours had said it wouldn't, and iMacs back to 2015.
I've had a look at the list of supported Macs now:
https://www.apple.com/macos/monterey-preview/
(scroll down almost to the bottom. and feel the 1970s with the white text on purple).
I do think it's a bit mean of them not to support the mid-2015 27″ 5K Retina iMac, which could be had as quite a capable machine with up to 1TB of SSD (so not cheap). The next model (and the 2014 Mini) used Intel integrated or Iris graphics instead of a 2GB ATI GPU, so perhaps they just don't want to spend the money on porting the driver. If so, it would be in their interests to explain themselves, including reasons why the driver had to change at all.
Big Sur won't run on a 7 year old Mac Mini (it was bought early in 2014, even if the model is "late 2012") and Catalina crawls, but Windows 10 nips along.
A "security update" to Safari completely broke web debugging and I had to install a "technology preview".
Trying to fix that, I mistakenly upgraded my iPhone from 14.4 to 14.6. Now XCode won't connect and build for it - because that's abso-bloody-lutely what you expect from a point release. But of course, I can't downgrade the phone to a version that is supported. [Some nice people on the web have solved that and have hacks for Big Sur, which I might try.]
People bitch about Microsoft but Apple are far worse.
I expect that's just a short term thing to avoid forcing people into a choice of updating to iOS 15.0 or staying on iOS 14.x with known (thanks to the iOS 15 security patch listing them) vulnerabilities.
They only need to keep pushing patches onto iOS 14.x until the end of the year at the most before they can reasonably expect everyone to upgrade to iOS 15.
Apple does tend to provide security updates for their operating systems even after releasing new versions. The machines they don't support will eventually become insecure, but it's not immediate. The only thing that will happen immediately on release is annoying banners informing users that new app updates are available but you can't have them because the OS update is required.
I have had plenty of apple stuff obsoleted. Yes they give security updates for a couple of years, but after that, the phones, ipads, and ipod touches become junk. I run dosdude1 os patcher in order to keep a perfectly good mac mini working for my significant other that apple has relegated to the junk heap. Yes 10 years old but plenty fast enough for what it is asked to do. If it weren't for iphoto, Manjaro or Mint would run on it. Apple has to generate bloat to obsolete its older hardware or sales would drop off this quarter.
Some apple products get minimal updates, for example the ipad 1, all the while apple claims they are just as good as the day they were manufactured, except they are insecure and crash rather than open web pages.
Not arguing that point, just exactly when it comes into effect. I have one of the Macs that isn't going to get the update, but it's still functional. I will still be comfortable running Big Sur on it for a while before security updates stop and I relegate it to offline Mac OS and Linux for online tasks.
> If it weren't for iphoto, Manjaro or Mint would run on it.
Could be worth running MacOSX in a VM within your preferred Linux, filesharing a data folder outside the VM (to eliminate any risk of future hypervisor "improvements" locking out access to the VM's disk's contents).
Since it's Apple hardware, I would think you wouldn't even have legal Licence concerns.
.
> I have had plenty of apple stuff obsoleted.
Ditto. Kept a lot of my own and other people's stuff running wayyyy past Apple's sunsetting, for... Christ, total of over 20yrs thru all the various iterations. You develop this massive internal web/db of knowledge of compatibilities and dependencies, and necessarily accompanyingly accumulate the actual "physical" archive/library of tools and versions and apps and OSes and twiddles and versions and versions and versions and...and...
And after a while you just get sick of it.
Apple does tend to provide security updates for their operating systems even after releasing new versions
In the past they haven't done it for iOS, which leaves a window of opportunity for attackers who might be able to reverse engineer exploits for the old version by looking at the release notes of new version and comparing code.
There are a lot of people who don't trust .0 versions and will wait a bit to upgrade to the new release. Pushing security fixes for the old version for a few months would address that but IMHO they aren't likely to deliver those fixes longer than that.
True, although they do patch old versions of IOS which are running on devices which don't run the latest, I.E. they don't patch IOS 13 but they do patch IOS 12. In any case, they are extending that protection to IOS 14 now even if you can upgrade, so that complaint was valid but is now closer to resolved by their decisions.
True, but that is because anyone running IOS 14 can upgrade to IOS 15 whenever they want. The overlap is useful so people remain secure while watching 15.0 and 15.1. If they're still using IOS 14 even when 15.1.2 comes out, maybe it's time for them to install it.
Is it just me, or do I smell Apple about to launch their version of Facebook, which will obviously promise anonymity to their users... the only question being whether it will allow people from outside the Apple ecosystem to join as well. They have had their own, "messenger" service for some while which bypasses SMS between Apple users. If they were to try something like this, however, I feel sure they'd end up in court on a worse wicket that they already are with the app store debacle.
There's not a chance in hell Apple is going to wade into the shitstorm that is social media. They are making iMessage a bit more friendly for group chats is all.
They are not making another Facebook, they are just adding features that analysts see as treading on WhatsApp/FB Messenger territory. Hence why all the articles talking about this mention Facebook but not Twitter.
The story references that but I can’t see it mentioned on an Apple page, anyone have a link to the reference?
Non of my kit that will go to so 12 or iOS 15 is a12 or newer than 2016.
I like the feature but won’t upgrade for that.
I would like to know why the limitation.
Expectations were low for this event and Apple really managed to live down to them. There was really nothing for the fanbois to get excited about and not much in the way of helpful differentiators that would justify users spending twice as much money for the luxury of being captive in Apple's Magic Garden. That's not a surprise, there's no way a closed corporate cannot innovate more effectively or quickly than a lively, global open-source community, but it does mean that in future Apple will always be a follower rather than a trend setter. There's a middle-aged bulge to the company's latest offering, small improvements in privacy that could already be achieved by installing Ghostery or a VPN, an "App Library" that was apparently designed by a kindergartner on crack, a few extra voices for Siri... It's not the kind of thing that stirs the blood but rather the product of a committee of marketing executives sitting around a table desperately searching for ideas to deliver to slaver Tim before he sends you off to work in one their production factors in China alongside the Uighurs being "re-educated" by the Chinese state.
Oh, my.
Did you miss the bit where you could put your iPad down on the desk beside your Mac and then smash the Mac's mouse through a hot edge on the Mac screen so that you can click and drag on the iPad? And then drag a file between them?
Or where people in two separate households could watch Disney's streaming service on their living room TVs attached to Apple's "Apple TV" media box, *synchronised* via chat on their iPhones and chatting in real time?
Or the OCR text recognition on photos in the album?
I've never personally wanted any of those things, but surely you can see the appeal for the average person. And none of them is technically trivial to do, particularly the synching of TVs in separate houses. They must be calculating time-of-flight like NTP to pull that off.
So let me get this straight... If your only copy of your driver's license or other government ID is on your phone, there would be zero chance you could keep your phone locked at perhaps the most important times - during non-consentual encounters with TSA, LEA, etc. Seems like a bad idea to me. Guess you could just refuse to show ID but I suspect that would do nothing than invite more scrutiny. Still going to be paper boarding passes and a physical ID for me.
I'm guessing showing your ID will not actually unlock the phone. That's how Apple Pay works anyway. If you authorise a payment with your fingerprint or face ID, then it only authorises that payment. You have to reauthorise again to actually unlock the phone. So it shouldn't be possible for them to browse your phone if you pass it to them to show the ID. Just guessing obviously.
If you unlock by biometrics, they are allowed to force you to submit the biometrics by taking the phone and forcing your finger on the sensor or showing it your face. Those who don't like this may only use a passcode or may use the shortcut to disable biometrics in a worrying situation, but in that case, they'll have to enter their passcode once to show the ID. They can be recorded doing this to obtain the code for future use. Failing to show the ID may itself be punishable and certainly would result in further intense questioning. I wouldn't use this feature either.
> fingerprint or face ID
I would never consider using any biometric ID on any networked device.
Reason? Security.
Your biometric ID is a single unit of info, regardless of its intra-record field length. Anyone burgling a raw ID db can just hoover them up and use them. Then what are you going to do -- change your fingerprints? Change your retinas?
Anyone using biometric ID is declaring a lifelong Position that it is impossible for now and for ever:
A/ that anyone will ever leak their info (neither deliberately, accidentally, nor involuntarily (eg, by being hacked) ),
AND
B/ that any possible accident, ignorance, stupidity, structural SNAFU, corporate blunder, inexperience, irresponsibility, arrogance, malice, HR Policy, or any other cause, might lead to their personal info being stored in cleartext on any machine attached to a network or with a disk removable casually or with a screwdriver.
The only real defence is not to open that attack surface -- consider it public knowledge and never use it for security purposes.
(Simple _convenience_ purposes, fine. Security, no.)
Why would your ONLY copy of your license be on your phone? The way you get it into your phone is by scanning your physical license. If you choose not to carry your physical license that's your decision and you have to live with the consequences.
As for unlocking your phone, Apple Pay can be used without unlocking it. Since the license is kept in the wallet, you'd probably access it the same way and just flip to a different "card" or maybe they'll add a "display ID" button. If the cop etc. uses RFID, or scans a QRcode shown along with your license you'll keep physical possession of your phone. Even if they grabbed it out of your hand they couldn't access anything on it, it remains locked.
Not sure if this would work for the TSA anyway - unless things have changed since the pandemic you show them your ID after you've already put your phone in the little tub to be xrayed. They would need different procedures to support using your phone for ID.
If showing my license when I'm pulled over can't be done without the cop touching my phone then I'll give him my physical license. The fact I'd still need my physical license for some things doesn't mean it isn't useful to have my license in the phone for other places you need to show your ID like when buying liquor.
I notice that one of the most requested App Store features is still missing in action - the ability for third party devs to offer discounted upgrades between major versions of their apps. Third party devs have been asking for this ability since the App Store first opened. Apple seem to think that every dev should just get paid once and then offer free updates forever.
Later, Apple did allow for in-app purchases, but this can be a horrible user experience and it can be harder to persuade someone to purchase new features within an app they already own, than it can be to get them to upgrade to a whole new version.
So version two of your app could in theory offer more features that can be unlocked via an in-app purchase, but users often resist this and see it as a subscription in disguise. Also, it means you either need to charge a fee for the base product, and then expect users to pay even more money after they've just bought the app (not a great user experience), or give away the base app for free and then charge in-app purchases to unlock features, something that isn't always feasible with some app types.
I've personally had this when version two of an app I sell was a ground-up rewrite, with a completely new interface and feature set. There wasn't really an easy way of dividing the new functionality out from the existing due to the way the new interface was designed. The whole point of the new features and design was to tightly integrate everything and make it very easy to use. Splitting it up and placing some features behind a pay wall just wouldn't make sense. I've spoken to several other developers who feel the same. They've tried the in-app purchase approach to adding features, but the over all user experience is poor and the return on time invested just doesn't justify doing it.
In-app purchases are fine for in-game add-ons etc. but when it comes to upgrading between major versions of an app, with major feature improvements, it's clunky at best.
It seems every app store provider wants devs to use a subscription based model to maintain an income whilst developing their apps. I however will resist this for as long as possible. I've actually gained customers who have told me they moved to my app specifically because my competition has gone over to a subscription model and my app is pay per version based.
How about just creating a new paid for app? Publishing app2 that is the paid version.
I see a lot of apps doing that.
Also, full agreement on the subscription based models - I don't care for them, as a consumer.
I understand the desire behind them, etc etc - but they should be the exception, not the norm they have become of late
I have a dev friend who did what I think you mean, but Apple refused to publish the second app as it was considered too similar to the first and therefore confusing to customers. So he had to undo all the work he'd done on the second app and crowbar it into an 'in-app purchase' update to the first, which he said was such a horrible user experience he ended up canning the whole project.
Personally I just removed the first version of the app from sale and released a version 2. It meant existing customers had to purchase again at full cost, which isn't a great way to retain customers and creates ill will, but it was the only way around it. Although, if they contacted me I did give them a 'deal', but officially that goes against App Store policies, so I can't advertise that as it risks me being banned from the store.
All in all, the way Apple want you to do it is not the best for customers or small devs.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
