Posts

Post not yet marked as solved
1 Replies
1.1k Views
Safari in iOS 13 has gained the ability to share web pages as Web Archives. By default, share options are set to Automatic however, which explains that it will "pick the most suitable format for each app or action". With share or action extensions, it seems that always results in Safari just sharing the URL however (the item provider only supports type `public.url`). I'm wondering if there's a way for extensions to indicate which format they prefer to receive, without asking the user to manually select the appropriate format each time they share a page.I've tried setting `NSExtensionActivationRule` to a predicate that only accepts `com.apple.webarchive`. This results in the extension only showing up once the user manually changes the share option from Automatic to Web Archive, which is not really what I was hoping it would do.Has anyone found a solution for this? Am I missing something?(This isn't really about Safari App Extensions, but I wasn't sure where else to post this.)
Posted Last updated
.
Post not yet marked as solved
0 Replies
300 Views
I'm looking for guidance on using CloudKit end-to-end encryption for an app I'm building. I'd like to offer the same strong privacy guarantees many Apple services offer, but it seems these may rely on private CloudKit APIs. As the Apple Platform Security guide explains (https://support.apple.com/guide/security/cloudkit-end-to-end-encryption-sec3cac31735/web): Many Apple services, listed in the Apple Support article iCloud security overview, use end-to-end encryption with a CloudKit Service Key protected by iCloud Keychain syncing. For these CloudKit containers, the key hierarchy is rooted in iCloud Keychain and therefore shares the security characteristics of iCloud Keychain—namely, the keys are available only on the user’s trusted devices, and not to Apple or any third party. Talk of a CloudKit Service Key makes it sound like this uses a built-in encryption feature. That seems to be confirmed by this remark in an academic paper on CloudKit architecture (CloudKit: Structured Storage for Mobile Applications, can't include a link to a PDF apparently): CloudKit supports encrypted field values, available in the private database. While I could generate a key on the device and store it in iCloud Keychain to safely share it with the user's other trusted devices, that means I'd have to manually encrypt and decrypt CKRecord fields and attachment data, losing type-safety in the process. It seems doable, but I'm wondering whether I'm missing anything and if there isn't an easier and possibly more efficient and secure built-in way to implement this. I asked a similar question about this last year, but I was hoping someone from Apple wants to chime in now that the forums have become more active again.
Posted Last updated
.
Post not yet marked as solved
1 Replies
611 Views
I'd love to find a way to programmatically create a Web Archive from a page that's currently open in Safari.A new public API to do just this was recently exposed on `WKWebView` in the WebKit project, which hopefully will be made available in future macOS/iOS updates. Exposing a similar API to Safari App Extensions would greatly improve the user experience of an app I'm currently working on.I'm imagining a `getWebArchive` method on `SFSafariPage`, analogous to the current `getScreenshotOfVisibleArea` method.Happy to discuss my use case in more detail, or help clarify the request in any other way.(I've also filed this request as issue FB7563410 through Feedback Assistant.)
Posted Last updated
.
Post not yet marked as solved
3 Replies
593 Views
Inspired by WWDC 2019 session 421 and the associated sample project, I've been working on a custom instrument. Things are mostly going great, but I have a question about the use of engineering type tracks and augmentations. It seems following the sample code (defining `<engineering-type-track>` in the instrument with a separate `<augmentation>` definition) adds tracks below all other instruments that may have been added to the document. That means these other instruments will be shown between the main track and additional 'augmented' tracks (see https://ibb.co/vB17Hjd), losing the connection between the instrument and these tracks. This is in contrast to what seem to be truly hierarchical instruments like `os_signpost`, which nest additional tracks under the main instrument track (see https://ibb.co/BG7MnHZ). Is there any way to get this same behavior in a custom instrument?
Posted Last updated
.
Post not yet marked as solved
5 Replies
2.6k Views
It seems more and more Apple provided iCloud features are using end-to-end encryption. In iOS 13 for example, protection is extended to Safari history and open tabs. I'm wondering if there's a good way to support end-to-end encryption in our own apps built on CloudKit.As explained in the iCloud security overview:End-to-end encryption provides the highest level of data security. Your data is protected with a key derived from information unique to your device, combined with your device passcode, which only you know. No one else can access or read this data.One approach that comes to mind would be to generate a symmetric key (such as AES-GCM) on the device and put this in the user's keychain to safely share it with the user's other devices (to avoid the need for a separate passphrase or other custom key sharing mechanism). You could then use that key to encrypt CKRecord fields and CKAttachments. That means you lose type safety of individual fields and can no longer rely on CloudKit's support for indexes or CKReferences, but I don't see a way around that.This is mostly out of curiosity, but would this approach make sense? Does it resemble Apple's use of end-to-end encryption, or does that rely on CloudKit features that aren't available to third-party developers?
Posted Last updated
.