DEV Community: ming ming

Your Mac has been keeping a file on your family

ming ming — Sun, 08 Nov 2026 14:02:23 +0000

Your Mac has been keeping a file on your family

Since macOS 13 shipped in 2022, every Mac has run two daemons whose only job is to build a graph about you. Who you are, who you know, how those people relate to you and to each other, how you communicate, where you go, what you do and when. The daemons are called knowledgeconstructiond and intelligenceplatformd, and the closest thing Apple has ever documented about them is a two-sentence man page.

A security duo going by The Bishop and The Knight took the system apart in October and published the anatomy. The graph lives in ~/Library/IntelligencePlatform, fifty-one plaintext SQLite databases protected by macOS's Full Disk Access permission. The core one, graph.db, is a triple store: 181 entity classes, 278 predicates, and a confidence score on every row. What goes into it is basically everything the OS can see. Contacts. Photos, with faces. Calendar titles and attendees. Family Sharing, including the age of every member. The emergency contact in your Medical ID. Events and people Siri Suggestions digs out of your mail and messages. Apps donated through App Intents. Beside the graph sit tables for who appears with whom in your photos, a communication log without content, location and movement, and a stream of device signals: screen locked, Wi-Fi, Bluetooth, charging, ambient light.

Then there is the part the HN headline picked up: a pair of XGBoost classifiers, shipped as CoreML models, that decide who counts as family. They read 144 features and output a probability for seventeen relationship columns per person, recomputed every day. Twenty of the features are identity: same last name, shared home address, an iCloud Family flag, age difference. Forty are communication patterns. Eighty-four come from photographs.

One shipped feature name is worth reading twice: photosPersonPosteriorProbabilityGivenSaturdayNight. A real input to a real classifier, and its job is deciding whether someone is your sister.

The scores look mundane until you look at what produced them. A mother scored 0.960, the ceiling of that column. Nobody typed it. The post counts nine independent signals that land on the same person: the partner column, a composite score, a household entity, the Family Sharing token, an iCloud flag, top twelve-month contact, a Photos face cluster, a Contacts record, a reachable handle. The model joined them and concluded "partner" for someone the owner had never labeled.

The joins are where it stops being about you. From one store, the authors worked out that there is a child in the household and roughly how old, which daycare the child attends along with both phone numbers, where the family will be and between which hours on a given Thursday, and which password manager is installed. A relationship is intelligence one level above the rows it was inferred from.

Deletion does not fully retract any of it. The live graph drops a contact, but a second table, expired_stable_graph, keeps the retracted rows with their confidence and sources, about forty-eight hours by the authors' measurement, longer on their own machines. The scorecard still scored two people a day after the graph had dropped them, people it knew only from a calendar invitation.

The authors also run a thought experiment that applies to any personalized system: what happens when this file ends up in the wrong hands, paired with a local model that has had its guardrails stripped. They call the graph a privacy single point of failure, and they play the scenario out in a second post.

To be fair to Apple: everything happens on device. The databases sit behind the Full Disk Access permission, so other apps cannot read them without the user approving it. Apple's researchers published a paper on the graph techniques back in 2023. And the same store exists on iOS, where a forensics tool called iLEAPP has been reading it since September.

The fair criticism is narrower and harder to wave off. The depth of the inference is undocumented. The kinship classifier is mentioned nowhere. And the graph does not just hold your data; it holds data about everyone who has ever emailed you, appeared in your photos, or been invited to a calendar event, and none of those people were asked.

The authors open-sourced a dashboard called iKnow that reads your own graph locally, if you want to see the file your Mac keeps on you.

I made a 56-second film about how the graph and the family classifier work:

And if you want to cut a clip like this into a GIF, try the tool I used: https://gif-master.com/en/tools/video-to-gif

Genie 4 vs. Genie 3 vs. Marble: What the Demos Show, and What They Hide

ming ming — Wed, 28 Oct 2026 14:37:31 +0000

Genie 4's demo starts with a man playing saxophone on a floating platform in the middle of a lake. The light, the water, and the plants look like a film shot. It takes a second to remember that this is a generated world.

A demo is not a product. It is a selected scene, a selected prompt, and a selected take. It does not show the failed attempts, the latency, or what the world looks like after ten minutes.

I have not run Genie 4. It is a research preview for trusted testers, with a waitlist for Project Genie and early access through the Gemini API and AI Studio. So this is a visual comparison of the official demo footage from Genie 4, Genie 3, and World Labs' Marble. The useful question is what each demo can actually tell you.

What Genie 4 is claiming

Google DeepMind's announcement says Genie 4 is a real-time, interactive world model. It generates the scene, the ambient audio, and character dialogue together. It handles physics like aerodynamics and collisions, and it can be steered with text prompts while it runs.

There is also a reasoning loop: Gemini 3.8 Flash watches the generated world, breaks goals into steps, and checks whether each step happened. That is a different claim from "the video looks real." It is a claim about causality over time.

Official Genie 4 demo. The video has audio; this GIF does not. Source: Google DeepMind.

The saxophone clip is the best argument for the photorealism claim. The weakness is that it is exactly the kind of scene a demo team would pick: soft light, slow movement, no text, no crowd, no edge cases. The official post lists the current limits: object permanence can drift, details can shift over longer sessions, and complex physical interactions, audio accuracy, legible text, spatial accuracy, and long-term consistency are still being researched.

Genie 3 is the baseline

Genie 3, from August 2025, is the model Genie 4 is measured against in public. It generated interactive worlds at 720p and 24fps, with consistency for a few minutes. It could also accept promptable world events, not only movement.

Official Genie 3 demo: first-person house painting. Source: Google DeepMind.

On paper, the jump is clear: 720p to 1080p demo footage, short sessions to a broader real-time experience, no native audio to generated audio and dialogue. In the footage, the difference is also visible. The Genie 3 house-painting clip is coherent and interactive, but the hands and the roller show their limits. It reads as a generated world, not a filmed one.

That is not a knock. Genie 3 was already doing something unusual: generating a world while you move through it. Genie 4 is the same idea with more detail, more physics, and a voice.

Marble is solving a different problem

World Labs' Marble is also called a world model, but it does not generate a live video feed. It creates persistent 3D worlds from text, images, video, or coarse layouts. You can edit and expand those worlds, then export them as Gaussian splats, meshes, or videos.

Official Marble demo: a 3D courtyard. Source: World Labs.

The Marble courtyard is the strongest still image of the three. The stone, the vegetation, and the light hold up when the camera moves. But it is not trying to simulate a person playing saxophone while the world responds in real time. It is trying to give you a reusable 3D space.

That difference matters for developers. Genie 4 and Genie 3 generate an experience. Marble generates an asset. They can both be useful, but they do not replace each other.

What the demos show, side by side

	Genie 4	Genie 3	Marble
Real-time interaction	Yes	Yes	Explorable 3D, not live video
Native audio / dialogue	Yes, per Google	No	No
Main output	Interactive video world	Interactive video world	3D world / exportable assets
Demo resolution	1080p	720p	720p-class
Availability	Research preview, waitlist	Limited testers	Generally available
Main open questions	Long-session drift, audio and text accuracy	Action space, multi-agent interaction, text, duration	Not a live simulation

This table is built from the companies' own claims and demo footage. It is not a benchmark. The scenes are different, the prompts are different, and each company picked the clips that make its model look best.

What the demos hide

The demos do not show the boring parts:

how long the world takes to start;
what happens when the prompt is ambiguous;
how the model handles a failed action;
what the frame rate looks like under load;
how the audio holds up when a character speaks for more than a line;
how much a session costs;
what the world looks like after ten minutes.

Genie 4's own limitations section is more useful than its highlight reel. Object permanence, text rendering, spatial accuracy, and long-term consistency are still open problems. The word "preview" is doing a lot of work in that announcement.

What this means if you build things

Genie 4 is not something you can build on today. It is a research preview, and the public access path is a waitlist and early access. If you are planning a product around it, you are planning around a date you do not control.

Genie 3 is the proof that the approach works, not a platform to ship on.

Marble is the most immediately usable of the three if you need a 3D environment or an asset pipeline. It is still a different product from a real-time world simulator.

The demos show a real jump in visual quality and a real jump in ambition. They do not show a finished tool. Watch the API access and the failure cases, not just the highlight reel.

Sources

Genie 4 official announcement: https://deepmind.google/blog/genie-4-a-new-generation-of-world-simulation/
Genie 3 official announcement: https://deepmind.google/blog/genie-3-a-new-frontier-for-world-models/
Marble official announcement: https://www.worldlabs.ai/blog/marble-world-model
Demo clips: official Genie 4, Genie 3, and Marble videos; shortened and converted to GIFs for this article. Footage belongs to the original creators.
GIF compression: https://gif-master.com/en

I Got Tired of Explaining UI Bugs With Screenshots

ming ming — Thu, 16 Jul 2026 03:40:11 +0000

A lot of UI bug reports start with a screenshot and one sentence:

The dropdown is broken on mobile.

Then someone asks:

What did you click before that?

Then someone else asks:

Can you send a recording?

And now the bug report has become a conversation about the bug report.

The screenshot shows the result, but not the interaction that caused it. A screen recording solves that part, but then you have a video file that is too large to casually paste into an issue or a chat. So the usual next step is to find a GIF converter, upload the video, trim it, add a note somewhere, export the GIF, then compress it because the GIF is now too large.

I got tired of doing that.

Not because any one of those tools is difficult to use. The annoying part is moving the same file through several tools just to explain one small UI problem.

So I built GIF Master, a browser-only workflow for turning a recording into a small annotated GIF.

The idea is simple, put all the steps into single window, no more file downloads and uploads:

Record the issue.
Then
Mark the issue.
Then
Make it small enough to share.

The kind of bug this is for

Take a common example: a dropdown menu covers the submit button on a narrow screen.

A ticket that says “dropdown is broken on mobile” is technically true, but it leaves a lot open:

Which page?
Which viewport?
Does it happen before or after opening another panel?
Is the button hidden, moved, or just unclickable?
What should the expected layout look like?

A short GIF can answer all of that without turning the issue into a wall of text.

The useful version of that report is usually only a few seconds long:

Open the settings panel.
Switch to a narrow viewport.
Open the dropdown.
Show the menu covering the button.

Then add a red rectangle around the collision, an arrow pointing to the dropdown, and one sentence:

Expected: the menu should stay above the form.

That is enough. The person reading the issue knows what happened, where to look, and what the expected behavior is.

I did not want another “all-in-one dashboard”

The workflow I wanted was deliberately boring.

Start with a screen recording. Keep only the useful part. Add text, arrows, rectangles, emoji, or a small image when they help explain the issue. Export a GIF. Compress it. Download it.

No new browser window. No sending the recording to a server first. No exporting a video just so another tool can ask you to upload that same video again.

The tools are connected because the task is connected:

A recording gives the bug report context.
A short GIF makes the context easy to consume.
An annotation removes ambiguity.
Compression makes the result practical to paste into GitHub, Slack, Linear, Notion, or a pull request.

That last part matters more than it sounds.

A GIF that is clear but too large to send is still inconvenient. A GIF that is tiny but unreadable is not useful either. The goal is to reduce the size enough for quick sharing while keeping the UI details and annotations legible.

Why I kept the files in the browser

Bug recordings can be awkward.

They may contain a staging environment, an internal admin page, customer data, unfinished features, or an account that should not be uploaded to a random service.

GIF Master processes the recording, editing, GIF generation, and compression in the browser. The file stays on the device unless you decide to export and share it.

That does not make every recording safe by default. You still need to be careful about what is visible on screen. But it removes one unnecessary step from the workflow: uploading a bug recording before you have even decided where it should go.

A GIF is not the whole bug report

I still want the usual details in a good issue:

Steps to reproduce
Expected behavior
Actual behavior
Browser, device, or viewport details
Console errors when relevant

The GIF is there to make the visual part obvious.

It is especially useful for things that are annoying to describe precisely: a layout shift, a hover state that disappears too early, a modal that closes unexpectedly, a button that becomes covered by another layer, or an animation that ends in the wrong