My only criticism is enabling telemetry by default. I'm a fan of having people opt-in.
Ironically enough the opposite happens with opt-out telemetry, for the same reason: a lot of power users will turn off telemetry, thus you will never see their usage patterns and will have to infer them. Dogfooding helps.
You claim power users opt in to telemetry, and then immediately say power users opt out.
From that you get two situations.
Opt-in:
- Regular users: click all 'ok' through setup at lightning speed, no telemetry enabled.
- Most power users: consciously don't check the box to opt-in because of privacy worries.
- Big picture power users: consciously check the opt-in box given they trust you (because they want their usage patterns to be profiled and optimized for).
Opt-out:
- Regular users: click all 'ok' through setup at lightning speed, telemetry enabled.
- Most power users: consciously check the box to opt-out because of privacy worries.
- Big picture power users: consciously don't check the opt-out box given they trust you (because they want their usage patterns to be profiled and optimized for).
The “Firefox Problem” is that all the power users disable telemetry, so all the “cool” features that power users like (but never get used by “regular people”) get ignored or removed instead of improved because, according to the metrics, “nobody uses them”.
Knowing what (vulnerable) version of software a user is using transmitted in the clear was absolutely a part of the NSA monitoring error information from windows crash logs https://www.schneier.com/blog/archives/2017/08/nsa_collects_... - so forgive me if I do not trust the developer to know what makes me unsafe or not.
If you enable telemetry by default I will do my best to never use your product.
The overwhelming majority of people don't care about digital privacy because the cost is opaque to them.
Also, telemetry when done right isn't "spying". Again, it is anonymized and used to see, for example, where the hot paths and paper cuts in applications are.
if it has telemetry, then it is a tool the customer buys, that also has the function of listening and reporting to others, how it is being used.
you want to sell it - no problem. but tell the customer, "look, this is bugged, and it's going to tell me what you are doing. but it's a great product." anything with opt-out telemetry needs a big version of that warning on the top of the page.
personally i am not a buyer. but that's my preference.
it's bugged. the same as a mole in your company. or a sculpture with a listening device in it.
tell the user that your thing is bugged!
One useful trick is to cua-driver 'launch_app' instead of the default 'open' or other osascript, since it can start the app without raising/focusing it, and the tests don't disturb your active desktop while they run
If you want to use it directly as an automation framework, you can take a Swift dependency on 'CuaDriverCore': https://cua.ai/docs/cua-driver/guide/getting-started/swift-i...
- Closing the coding feedback loop by having agents verify their own changes in a real app
- Automating repetitive workflows across apps that don't have good APIs
- Agents recording product demos of them using software. One compelling use case here: https://x.com/trycua/status/2047383207612645426
- Creating CLI and APIs for apps by reverse implementing their GUI, e.g. see: https://github.com/HKUDS/CLI-Anything
The audit trail question is interesting and I haven't seen it come up much. When an agent clicks through an ERP or edits a file, you've got logs, but how do you explain the "why" behind each decision to, say, a compliance team?
Curious if that's something you're thinking about or if it's too early.