Siri app conversations

macOS 27, aka Golden Gate featured a new Siri app, which allows a user to store their conversations with Siri unlike the default Siri invocations where they disppear after use. The new Siri app keeps a persistent history of your conversations, allows you to pin important chats, and organises them in either a grid or list as per preference.

Siri can also be interacted with from the new Unified Search bar, which is triggered via ⌘ + Space. 

Figure 1 - Unified Search bar (previously Spotlight search)

Figure 2 - Siri app conversations

Siri has now been embedded into almost all contextual (right-click) menus throughout the OS and is seen in most 3rd party App menus as well. 

Figure 3 - "Ask Siri" in the right-click menu in an email in Microsoft Outlook

Figure 4 - Reply from "Ask Siri" saved in Siri conversations

Most Siri interaction (without explicitly using the app) also results in information being stored in the Siri App. The default retention setting (at least what I had on mine) was "Forever". The other options are 30 days and 1 Year. 

This means there is now an opportunity to pull data from this database for forensic purposes. The database can be found here:

~/Library/Daemon Containers/<UUID>/Data/AgentSessionKit/AgentSessionStore.sqlite

where UUID would be a different one on every host.

Every event is stored in the ZAGENTSESSIONEVENTENTITY table and sessions are tracked in ZAGENTSESSIONEVENTENTITY.

Getting data out

A query like the one below can be used to pull out useful data:

SELECT 

(SELECT  ZBUNDLEID FROM ZAGENTPROVENANCEENTITY WHERE Z_PK=ee.ZAGENTPROVENANCE) as agent,

ee.ZSESSION as session, re.ZISPINNED as is_pinned, 

datetime(re.ZCREATIONDATE + 978307200, 'unixepoch') as session_created, 

datetime(ee.ZCREATEDAT + 978307200, 'unixepoch') as event_created, 

re.ZSUMMARY as session_summary, re.ZTITLE as title, ee.ZROLERAWVALUE as role, 

ee.ZTEXTCONTENT as text_content, 

datetime(re.ZSELECTEDAGENTPROVENANCESETAT + 978307200, 'unixepoch') as selected_agent_provenance_set_at,

re.ZSESSIONID as sessionid, re.ZSOURCEBUNDLEID as source_bundleid,

datetime(re.ZLASTMODIFIEDDATE + 978307200, 'unixepoch') as record_last_mod

FROM ZAGENTSESSIONRECORDENTITY re

LEFT JOIN ZAGENTSESSIONEVENTENTITY ee on ee.ZSESSION=re.Z_PK

ORDER BY ee.ZSESSION ASC, ee.Z_PK ASC  

Figure 5 - Query output

Siri can be asked to work with file attachments and process them in various ways. The above query will not pull out attachment related information. The files aren't usually stored in the database. They are instead referenced in the ZARTIFACTENTITY table stored usually as a JSON string which contains nested/embedded bookmark objects and plists where you can sometimes find bookmarks to files on disk.

Interesting find

There is a field ZPERSISTABLESTATERAW in the database table ZAGENTSESSIONRECORDENTITY which indicates if an entry can be removed. If this is zero, then that entry does not show up in the conversations, and can be removed at a later time.

Figure 6 - ZAGENTSESSIONRECORDENTITY table

As seen above, sessions 15 and 17 have this set to zero. There are no events retained for session 15 currently in the database, while session 17 has this data (below).

Figure 7 - Data corresponding to session 17

Automation

A plugin to read Siri App data has been added to mac_apt. It can read standalone databases too (via mac_apt_artifact_only).

Tags in Safari History db

I noticed an interesting feature in Safari's History database today. Safari tries to interpret every page you visit into a few words, represented as a Tag. But importantly, not all pages are tagged. The exact mechanism of how it arrives at a tag name is also uncertain but it piqued my interest as a case I was recently working on had some curious Tag entries in it!

This does not seem to be a new feature, as I've seen this in databases going back to at least 2021. 

Artifact location

In the Safari History db located at ~/Library/Safari/History.db

There are 2 tables of interest here: history_tags and history_items_to_tags. As the name suggests, the latter has info to join the tags to the actual history_items table entries while the former (history_tags) has the tag details.

Figure 1 - Tables holding tag data

This is what my own Safari history_tags table look like: 

Figure 2 - history_tags table content

The modification_timestamp represents the last time a page (assigned that tag) was visited. The value is of type NSDate (aka Cocoa timestamp) having epoch of 2001-01-01.

The Tag name is in the title column. Now notice that identifier column that always starts with a 'Q'. This is because Safari links every tag to a wikidata item (as shown below).

Figure 3 - The identifier field

Quick query to pull out this information along with the full history data from the database:

SELECT history_visits.title, url, 

  datetime(visit_time + 978307200, 'unixepoch') as visit_time, 

  history_tags.title as tag_title,  

  history_tags.identifier as tag_identifier, 

  datetime(history_tags.modification_timestamp  + 978307200, 'unixepoch') as tag_mod_date

FROM history_visits 

  LEFT JOIN history_items on history_visits.history_item = history_items.id

  LEFT JOIN history_items_to_tags ON history_items_to_tags.history_item=history_items.id

  LEFT JOIN history_tags on  history_items_to_tags.tag_id=history_tags.id

ORDER BY visit_time

Figure 4 - Output showing full history with tag details

Remember, not all pages have tags, and in the ones that do, the tags may not always be accurate. In my database about 98% of the time, the tag represented something related to the page (not always the central theme but definitely related). Below is an example of what a page was tagged as, but its a completely different story, both are related to planes though.

Figure 5 - Sample data from history

 

Forensic fun facts and usage

While in my own experiments, clearing the Safari history does seem to remove the corresponding entries from this table as well, I do also have some test systems where the history_tags table has old data having thousands of entries, with several having an item_count of 0 (as can be seen below). 

Figure 6 - history_tags with no associated history items due to deletion

While the above may not be the smoking gun you are looking for, it can provide some good insight of what themes the end user was browsing and when. 

On the case that inspired deeper inspection of this table, the tag was "APT" (Q230724), which got me excited only to find out that it refers to Advanced Package Tool, as in Homebrew or Linux 'apt'. But the website we were interested in was a phishing site impersonating the real Homebrew site, and it was properly tagged as APT, while the real Homebrew site got no tags!

mac_apt has been updated to add parsing of tags. Tags without item counts are shown as type "TAGGED". 

Figure 7 - mac_apt Safari output