Benjamin Mayo (MacRumors):
Asked about the possibility of third-party watch faces on Apple Watch, Lynch says that the watch face is the home screen of the watch and they want everything to work reliably and consistently.
As Apple controls all the faces the user can choose, Caldbeck adds that users “don’t have to worry about the watch face still working when there’s a major watchOS update. We’ll take care of that.”
[…]
If third-party faces were available, Apple argues it wouldn’t be able to ensure that the watch faces keep working if they change something in the operating system, like this year’s watchOS 10 redesign that includes a new swipe up gesture to reveal a tray of user-selectable widgets.
This explanation doesn’t make a lot of sense to me.
Previously:
watchOS watchOS 10
Andrew Orr (Hacker News, Reuters):
Japan is the next country to impose regulations on these companies, according to The Japan Times. It will require Apple and Google to let users download apps through services other than their app stores. The government aims to stimulate competition and believes it could reduce app prices.
The government will compile a list of prohibited actions for OS providers to prevent them from showing bias towards their services and payment platforms.
[…]
Furthermore, the two companies will be compelled to enable users to make payments through third-party platforms.
Previously:
Android Antitrust App Store Google Play Store In-App Purchase iOS iOS 17 Japan Legal Sideloading
WWDC 2023 session 10060:
We have heard from developers like you that it can be challenging to get all the information you need from the great third-party SDKs that your apps depend on. Privacy manifests are a new way for third-party SDK developers to provide information about their privacy practices. This information helps you accurately represent privacy in your app.
Third-party SDK developers can include a privacy manifest in their SDK. They can create a new privacy manifest right from the Xcode navigator, by creating a file named “PrivacyInfo.xcprivacy”.
[…]
When you’re building your app to submit to the App Store, Xcode 15 can aggregate all the privacy manifests in your app’s project, and produce a privacy report that summarizes the declared data uses.
[…]
In some cases, domains may be used for both tracking and non-tracking functionality. An approach that you or a third-party SDK developer could take is to separate the functionality into different host names. For example, you can host tracking functionality at tracking.example.com, and non-tracking functionality at non-tracking.example.com. Then, declare tracking.example.com as a tracking domain in the privacy manifest.
This is neat, but I still question how useful this is when it’s all based on the honor system. Is there any evidence that nutrition labels do more than provide a false sense of security? Apple seems to be acting like the problem with nutrition labels is that they could be accidentally incorrect.
Dave Verwer:
Privacy nutrition labels on the App Store were a step forward for how informed people could be about what an app is doing with their data, but I’d also bet that a non-trivial amount of them are incorrect in some way. 😬 In the vast amount of cases, I’d expect that to be caused by the inclusion of third-party SDKs.
[…]
But that’s not everything, and tucked away at the bottom of the news post was a little note that says everything about how seriously Apple think about this. They say that later this year, they’ll publish “a list of privacy-impacting SDKs (third-party SDKs that have particularly high impact on user privacy)”.
Mysk (Nick Lockwood):
The rogue 2FA app that steals scanned secrets is now ranked 18 on the German App Store for the productivity category. No wonder! The app disguises as a Microsoft app. It is the top hit when you search for “Microsoft Authenticator” and the developer has updated the screenshots in the ad card to highlight the word “Microsoft”. Surprisingly, the product page of the app shows different screenshots with the word “Microsoft” removed.
The app now has 1.2K reviews, as opposed to 18 when we first addressed the app.
Previously:
Update (2023-08-01): Apple (Hacker News, MacRumors, The Register):
Starting in fall 2023, when you upload a new app or app update to App Store Connect that uses an API (including from third-party SDKs) that requires a reason, you’ll receive a notice if you haven’t provided an approved reason in your app’s privacy manifest. And starting in spring 2024, in order to upload your new app or app update to App Store Connect, you’ll be required to include an approved reason in the app’s privacy manifest which accurately reflects how your app uses the API.
If you have a use case for an API with required reasons that isn’t already covered by an approved reason and the use case directly benefits the people using your app, let us know.
There is now a list of APIs and reasons.
Jeff Johnson:
I don’t even see the point of self-documenting. Either it’s based on the “honor system”, which would be stupid, or Apple is going to test your usage somehow, in which case the privacy manifest is redundant.
Marcin Krzyzanowski:
Despite stupidity of explicitly declaring a reason to use foundation provided API (just prevent it from doing forbidden operations), there’s only ONE reason you can use UserDefaults for. And it’s not even clear how it contradicts API documentation.
The raise of new crazy rejections on the horizon.
all of all, this is plain stupid security by obscurity. I’m 100% sure none of the big players have to care about this, neither Apple applications. as usual just a burden put on the shoulder of small developers.
Paul Haddad:
TIL that using the standard user defaults functionality is going to require special privacy declaration. Other troublesome API includes getting the modification date of a file and figuring out how much disk space is available…
What’s next, you must declare each For loop that you use within your app? Beyond stupid.
Rosyna Keller:
The system makes available certain defaults available to all apps based on global user preferences. These can be used to fingerprint users. Hence, the changes.
Steve Troughton-Smith:
UserDefaults has always been a silent exfiltrator of private data; every framework your app can access (Photos, Music, Safari, telephony, etc) generally needs access to its own UserDefaults store, which left tons of side channels for any app to pick up things like phone number, email address, real name, recent Photos searches, etc, without any kind of permissions prompt. Any library you include in your app, like analytics packages, can yoink all of this without you [as app developer] knowing.
Shantara:
I agree with strengthening user privacy in general, and this approach makes sense for permissions such as user location, camera or contacts.
But in my opinion it serves no purpose for such ubiquitous permission as User Defaults. To borrow a comparison I’ve seen elsewhere, it’s like a network access permission on Android. Every single app declared it, and it became universally accepted and ignored. Or the cookie prompts, which users have been trained to ignore for years.
Andrew Wooster:
Wild overreach from Apple. Can’t read defaults data from other apps in the same app group. Can’t log in crash reports how much disk space is remaining, etc (their own crash reporting system basically does not work). I get that Apple is trying to protect users from being uniquely identified, but there are only a few apps where that sort of data is at the scale where it is valuable. Maybe go after them and not the rest of us.
James Dempsey:
Because clearly individuals devious enough to figure out how to do device fingerprinting won’t be able to come up with plausible-sounding reasons to use those APIs.
Kuba Suder:
I see it as a way of emphasizing that you can’t do some things with it and making you acknowledge it in writing, and then when an app is caught abusing it, they can’t pretend they didn’t know 🤔
Michael Love:
I don’t think it’s aimed at bad actors; it’s aimed at big companies with lawyers, and specifically at their SDKs. Facebook may be utterly amoral, but they’re not going to lie about fingerprinting in a privacy manifest for a library used by tens of thousands of apps; the risks from getting caught are too high.
I don’t see why they would care about getting caught. Worst case, they just stop doing it. It’s not like Apple is going to delete Facebook’s developer account.
Sindarina:
It’s kind of amazing how much this tries to ‘both sides’ the issue of developers abusing APIs to do fingerprinting of their users; ‘an additional hoop developers must jump through’, ‘the controversial App Tracking Transparency initiative’, ‘clever developers’, ‘those who have been taking advantage of this loophole’, etc.
Francisco Tolmasky:
This is only true if you believe that Apple has the ability (and desire) to actually implement this in good faith — and we know they don’t. Apps that are clear scams (like fake authenticator apps), get past app review AND remain as the top hit for long periods of time. Meanwhile good apps get jerked around for weeks. You can write the best rules you want, but unless you execute them fairly, it becomes the equivalent of “3 felonies a day”: the ability to arbitrarily deny any app.
[…]
Of course it’ll make it worse, it’s another complicated metric. The reviewers already aren’t technical, & now they’ll judge more complicated “defenses”. And it requires more upfront work by devs (the smallest of whom will be hit hardest, huge companies can do it easily), in exchange for the same crapshoot as today. You can be flagged for an description that has never changed, you think adding more places to dock you will make things more “consistent”?
Isaiah Carew:
to anyone that believes apple will use privacy manifests for reasonable policies that benefit users…
like, where have you been?
were you asleep for the last ten years of sandbox woes?
are you new here?
sorry, but the list of totally onerous rules, missing apis, and riduluously capricious enforcement has jaded me. i can only see this pushing developers and users to more reasonable platforms.
Update (2023-08-17): Apple (via Accidental Tech Podcast):
You only need to supply NSPrivacyAccessedAPITypes for apps and third-party SDKs on iOS, iPadOS, tvOS, visionOS, and watchOS.
In other words, not for macOS—so far.
Update (2023-08-23): Marco Eidinger:
In this blog post, I’ll share a shell script that helps you to identify if your code base might use a required reason API.
App Store App Store Scams App Tracking Transparency iOS iOS 17 Mac macOS 14 Sonoma Privacy Privacy Manifests Programming Xcode
Brandon Jackson (Hacker News, 3):
A package was delivered to my house on Wednesday, May 24, and everything seemed fine. The following day, however, I found that my Echo Show had signed out, and I was unable to interact with my smart home devices.
[…]
When I connected with the executive, they asked if I knew why my account had been locked. When I answered I was unsure, their tone turned somewhat accusatory. I was told that the driver who had delivered my package reported receiving racist remarks from my “Ring doorbell”[…].
[…]
If the driver’s claims were accurate, I could easily verify them with video footage. Second, most delivery drivers in my area share the same race as me and my family. It seemed highly unlikely that we would make such remarks. Finally, when I asked what time the alleged incident occurred, I realized it was practically impossible for anyone in my house to have made those comments, as nobody was home around that time (approximately 6:05 PM). […] Instead, the Eufy doorbell had issued an automated response: “Excuse me, can I help you?” The driver, who was walking away and wearing headphones, must have misinterpreted the message.
[…]
I fully support Amazon taking measures to ensure the safety of their drivers. However, I question why my entire smart home system had to be rendered unusable during their internal investigation.
So their system is that the driver doesn’t have to present any evidence, and you need to record everything just to prove your innocence?
Previously:
Amazon cancels my [7-year-old affiliate] account after exposing account lockout for “racist doorbell”
[…]
Amazon accuses me of breaking terms of service.
[…]
Amazon’s claims of abuse are wrong
Alexa Amazon Amazon Echo Ring Web
