Ollie, a family-oriented AI assistant, entered the race with a promise that isn't about the product but about data governance: it wants access to the details of your daily life and says it won't use them to train models or share them with third parties. TechCrunch covered it on September 3. One day later, GitHub shipped a star history endpoint that returns historical counts with timestamps without exposing the identity of who starred what.
Two announcements at wildly different scales, published a day apart, pointing at the same place.
Why it matters
The signal isn't that privacy is trendy. It's that it's moving from the terms-of-service page into the response schema.
GitHub's case is the boring one and, precisely for that reason, the most informative. According to the changelog, earlier this year they restricted the endpoints that listed stargazers to admins and collaborators, and only now are they offering the alternative: a timestamped aggregate. First they broke integrations to get identities out of the response, then they put back the metric people actually needed. That order says everything. Privacy there doesn't depend on nobody misbehaving: the identifiable data doesn't travel because the API doesn't return it.
Ollie's case is the opposite in nature. With the available material we have a promise — no training, no sharing — and nothing about how it's backed. The piece has no detail on encryption, on local inference, on retention, or on external audits. That doesn't invalidate it, but it places it: it's a policy commitment about data the system does collect and can read.
What changes in practice
If you maintain tools that charted star growth, the migration is concrete and you need to do it: stop walking stargazer lists and ask the new endpoint for the historical series. Less pagination, less personal data in your database, less surface to justify when someone asks you what you store.
The more useful takeaway, though, is about design. When you review your own APIs, the question isn't "do we have permission to return this?" but "does the consumer need the identity, or is the aggregate enough?". In my experience, most internal dashboards ask for identities out of inertia: the endpoint was built with the easiest join and nobody looked at it again. Aggregating at the edge, on the server side, eliminates an entire class of incidents instead of managing it.
The distinction worth keeping in mind when evaluating any product sold as private:
| Dimension | Policy promise | Data shape |
|---|---|---|
| What backs it | Terms of service and reputation | The response schema |
| If there's a breach | The data exists and leaks | There's no identity to leak |
| If ownership changes | Revisable with a terms update | Requires exposing the field again |
| Verifiable from outside | Hard without an audit | Visible in a single call |
| Cost to implement | Low | High: breaks existing consumers |
The last row explains why almost everyone picks the middle column.
When NOT to use it
Aggregating isn't free, and selling the aggregate as a universal solution is dishonest.
- You lose real capabilities. Without identities you can't do case-by-case support, you can't track abuse or detect anomalous patterns. If your product depended on knowing who starred a repository to detect artificial star inflation, the new endpoint doesn't replace that and there's no point pretending it does. There, the path is to rethink the feature, not to migrate and hope.
- It doesn't apply to the assistant case. An assistant that organizes a family's life needs the personal detail to be of any use. There's no aggregation available: the design decision shifts to where the data lives, for how long, and who can read it. Conflating the two problems leads to solutions that protect nothing.
- Careful about taking the promise as a technical guarantee. With the published information we don't know whether Ollie encrypts client-side, whether it runs local inference, or whether anyone external has verified anything. As long as that's missing, "we don't train on your data" is a revocable decision: it survives the current terms, not necessarily an acquisition or a change of business model. That's not an accusation, it's what the provided material lets us state.
- If your data model doesn't change, don't announce it. Slapping "privacy first" on your home page while you keep storing everything is the fastest way to get caught out in the first incident.
What I'd do today
I'd migrate any integration of my own that still depends on the stargazer listing, because it's already restricted and now there's a replacement. Then I'd do a short pass over our internal endpoints looking for the ones that return identities where a count was enough, and I'd start with the one that has the most external consumers.
On the assistant, I'd wait. The category is interesting and the positioning is sensible, but before giving it access to a family's calendar and conversations I want to read the technical detail: retention, effective deletion, subprocessors, and what happens to the data if the company changes hands. Until then, what we have is a stated intention, which is quite a bit more than others offer and quite a bit less than a guarantee.