chrome://on-device-internals reports "Model Name: v3Nano Version: 2025.06.30.1229 Folder size: 4,072.13 MiB" on a random Windows machine I just checked.
Thank You stranger! I would have assumed the size would vary based on whether your hardware supports the high-quality GPU backend (4 GB) or defaults to a smaller CPU-compatible version (3 GB) but the 22GB note on that page is really confusing. Even if it was including the model server where's the remaining 18GB going towards?
I'd imagine that the 22GB was decided through modelling various scenarios. For a start, it's not just a 4GB current model, it's 2x4GB to be able to update it without needing time when the computer is without a model, that's up to 8GB.
Then it's possible the model you get will scale with the CPU/GPU/RAM available, so if you have a 12GB GPU you probably get a better model, perhaps that's a 10-11GB model? At 2x that's 22GB.
Then consider that a machine is not static, GPUs/hardware come and go, VRAM allocation in integrated graphics changes, etc. You end up with just needing to pick a number and not confuse users.
This is part of it, and also we just didn't want to use up the last of the user's disk space! It's disrespectful to use up 3 GB if the user only has 4 GB left; it's sketchy if the user only has 10 GB. At 22 GB, we felt there was more room to breathe.
One could argue that users should have more agency and transparency into these decisions, and for power users I agree... some kind of neato model management UI in chrome://settings would have been cool. But 99% of users would never see that, so I don't think it ever got built.
I clicked on a few red team "scenarios" if you want to call them that, a few of the tiles look like output of regular tools vaguely related to each but the rest - including the main "terminal" thing - seems more on the fictional side to the point I don't see this being educational.
There's plenty of training material out there these days actually using these tools in contained but realistic environments, if education is the goal just go for those.
> Would he have not disclosed it if they offered hush money? We won’t know, for his case I hope not. In any case - what was he expecting?
A bog-standard responsible disclosure that any tech CEO should either be familiar with or have someone at hand that is, as is clearly communicated in that e-mail.
Both e-mails are OP reaching out to help this company out, the first fixing the vulnerability, the second giving them a chance for compliance / potential regulatory aspects they might want to follow. It's not on random people reporting security vulnerabilities to tutor random companies on this and both behaviors (non-responsiveness, then hostility) of this CEO, despite being sadly common, are actively harmful if you want to get productive security reports in the future. (And the company unilaterally signing up for bug bounty programs is rather irrelevant for independent researchers as well if they have no interest in participating in those.)
Their accompanying website [0] says mobile phone data comes from teralytix while car movement data is sourced through inrix [1], which appears to gather data through navigation apps of some sort (vague as can be expected but the linked paper [2] claims that).
As far as I'm aware this type of data does not meet the requirements [0] for a GDPR violation and there was a bit of initial litigation around Google's street view data gathering which left this part out as well (e.g. [1] for a somewhat recent discussion).
In terms of landing page it certainly worked, got me to check out the linked demos until I hit the signup nudge. Some of them don't seem to be available in English which might be a negative depending on your target audience.
Loading those exposes the e-mail of the account used to create the application (in [0], data->userInfo->email) and those "blocks" downloads contain the entirety of the prompts / applications, which is nice I guess but surely those are only required on the serverside?
I think I’ll start by removing the non-English demo links from the landing page, and later, when we have multilingual versions, we’ll link the corresponding demos.
As for the second issue, We’ll remove unnecessary userInfo. Also, although these demos allow users to duplicate the internal blocks and prompts of the agents, we’ll implement some optimizations on the API next week to prevent unnecessary exposure.
It’s great to have you take a look and provide this feedback!
Thank you for your feedback. I will do a better job crediting the creators. The content currently displayed is partly my own, created to showcase how the platform will function and appear once it’s fully launched. I will, however, make sure to clearly credit any third-party content where applicable moving forward.
As DIY-it grows, my goal is to have a platform where users can find and complete their own projects. The affiliate links help support the platform without impacting the experience or cost to users. I don't like how all blogs have a wall of ads ruining the flow of finding and working on projects.
I appreciate the input and will continue working to improve transparency on the site.
