Create MacOS.System.IntelligencePlatform.Wifi.yaml

[ydkhatri]

This artifact parses the views.db database, part of Apple Intelligence which provides detailed connect/disconnect events on recent wifi connections.

[scudette]

We generally try to add sqlite artifacts to the sqlitehunter https://github.com/Velocidex/SQLiteHunter

[ydkhatri]

I see the point in trying to keep all sqlite ones in the same artifact. However, it is not conducive to analysis as the results are cluttered in the notebook with too many empty tables (VQL cells). And as we continue to add more items to the sqlitehunter module, it will only get worse. Grouping is also problematic. One may not want to process all MacOS sqlite artifacts.

While this may be a good one for collecting all sqlite files, it's not usable for review/analysis of results. Ideally, we want to review one artifact in one notebook. Any output with more than 2-3 cells is difficult to work with.

We can add this to sqlitehunter, but I'd rather have it independent (or both places) for reasons cited above.

[scudette]

Thanks for this feedback - it is a good discussion to have

1. Having all sqlite artifacts in the same artifact helps collection - the user does not need to remember each and every one of the hundreds of artifacts
2. it is more scalable - we know we dont miss anything but just collecting one artifact
3. Removing boiler code and eliminate subtle bugs - also this allows the same artifact to work on a bunch of precollected files, live system, dead disk etc
4. You make a good point regarding the presentation aspect of how do we present only relevant artifacts

There are two scenarios - the first is:

1. I want to just throw all sqilte artifacts at an endpoint and see what sticks - in this case it is ok to have lots of cells
2. I want to only look for certain artifacts - here I can restrict what to search for in the sqlitehunter parameters and notebook should only show relevant collections

Both these could be addressed in improving the presentation