Archive for January 27, 2020

Monday, January 27, 2020

Core Data Lab 1.0

Ron Elemans (via Mike Rundle):

The Core Data viewer app we had in mind should be able to filter data in any way we like, show related data defined by Core Data relationships, allow to edit and delete data, show any type of web data automatically, and present all data conform the object model including binary and transient fields.

A database viewer is of course not complete without obvious features like a metadata viewer, which allows you to inspect all aspects of the Core Data Object model, and export functions, which allow you to export any data selection as CSV or JSON file.

But there is more. The app should also be able to show all Core Data apps that we ever started in an iOS, iPadOS, tvOS or watchOS simulator in a handy overview, together of course with the related database. And we are always curious how ‘other’ apps uses Core Data. So our Core Data app should be able to find the database for a given Core Data app, and the other way around.

[…]

Another nice feature we implemented is a data change tracker, which lets you see in a graphical way how a Core Data app mutates a database.

The initial version already looks better than the previous such apps I tried. I can’t believe it’s only $10. The developer was very responsive to the feature requests and bugs that I sent in.

See also: CoreDataUtility, Core Data Explorer.

Previously:

Safari Runs Disabled Extensions

Jeff Johnson (tweet):

I reported this issue to Apple Product Security on November 17 2019. I received a reply from Apple Product Security on December 16 that said they do not see any actual security implications from my report. I replied, arguing that it was a privacy violation. A disabled extension can phone home without the consent of the user, indeed without the knowledge of the user, and expose information about the user: the user’s IP address, the user’s username (which is probably their real name), the fact that the user has installed the extension, the exact time that the user launches Safari, every time the user launches Safari, etc. I also suggested to Apple Product Security that executing native Mac code without any action by the user is a security problem, and furthermore that a maliciously crafted app extension could exploit any vulnerabilities in the SafariServices API that may exist, or exploit any sandbox escapes that may exist, despite being disabled in Safari, and again without any action at all by the user, except for installing the app. I received another reply from Apple Product Security on January 24 2020 reiterating that they do not see any actual security implications.

This does seem like something Apple should fix.

Update (2020-03-27): Jeff Johnson:

After installing Safari 13.1, I can no longer reproduce the issue with my sample Safari app extension, which I made available for download in my previous blog post. As far as I can tell, the issue is completely resolved.