Hello, everyone! I'm using CloudKit JS with a React SPA to allow users from a mobile app to access their data in a web browser. Currently, the project is still under development so there are no public users beside my team. The way I've integrated CK JS in my app is via their CDN, importing the required url in my index.html file. However, I'm having issues with the Authentication using Apple Sign In. While the Sign In and Sign Out buttons work correctly for me and my teammates, the session is not persisted for everyone. Actually, I'm the only one from me team that does not have to log in every day. I have the following configuration function: export const configureCloudKit = () => { window.CloudKit.configure({ locale: 'en-us', containers: [ { containerIdentifier: CONTAINER_ID, apiTokenAuth: { apiToken: API_TOKEN, persist: true, signInButton: { id: 'apple-sign-in-button', theme: 'black', }, signOutButton: { id: 'apple-sign-out-button', theme: 'black', }, }, environment: 'development', }, ], }); }; As you can see, I'm using the persist:true option so there shouldn't be any issues with having a persistent session. From my research, I found that CloudKit JS sets a cookie called iCloud.com.myContainerName and if I delete that cookie, when I reload the browser, the session is indeed lost. This happens for all my teammates, same cookie and same behavior. Nevertheless, I also found three cookies that are not present for any of my teammates but me (using Google Chrome). Those are called: X-APPLE-WEBAUTH-AC-PARTITION X-APPLE-WEBAUTH-AC-SERVERINFO X-APPLE-WEBAUTH-AC-TOKEN But even if I delete those cookies, the session is not lost for me. Does anyone know whether I'm doing something wrong with the configuration? Or if there are something I'm not taking into account regarding the cookies handling in my project?

I'm a new developer who is looking to make my first app easier to manage on my end by staying in the Apple ecosystem. My ideal backend is just pure and simple CloudKit. This should help me cut down on costs and increase my security, or so I thought. The more I looked into the issue of mobile app security --more specifically, preventing fraudulent access to backend APIs-- the more it seems like CloudKit is a disaster waiting to happen. While data in transit is encrypted and there's even end-to-end encryption for private DBs, securing an app's public DB in the presence of modified apps is a daunting, if not impossible task. My assumption is that a modified app cannot be trusted to make honest assertions about itself, the device, or its iCloud account, and can potentially lie its way into restricted areas of the DB. If an app is compromised, CloudKit queries from that app can be used to make malicious queries or even changes to the databases. I'm hoping App Attest, even with its potentially circular logic, can at least make life harder for fraudsters, competitors, and vandals (when combined with other security measures like jailbreak, debugging, hooking, and tampering detections), but I have not found a single mention on how App Attest might be used to protect CloudKit. There doesn't even seem to be a verified way for me to build a third party server that can handle App Attest and then tell CloudKit to allow a user through (with all the security hazards a new developer faces when configuring an authentication server). The message seems to be: App Attest is important, but you can't use it with CloudKit, so build your own server. Questions Is my assumption that a compromised app can make malicious queries or changes to an app's CloudKit DB correct? Can App Attest be made to protect a CloudKit public DB, with or without the involvement of a third-party server to handle attestations?