[meowface]

Your best bet is probably to just do all the processing locally in the browser. The issue is 1) from most end users' perspectives, they have no idea if it's actually running locally or talking to a server, or how to verify it, or probably what that difference even means in the first place, so a skeptical user won't necessarily gain that much additional peace of mind, and 2) hypothetically a compromise could still result in the local data being siphoned off by an attacker. The latter's still a risk for regular desktop applications, but a bit less so (since you can get a signed binary).

The homomorphic encryption approach probably isn't worth the effort. There's always going to be a trade-off between doing something useful and sufficiently/securely obfuscating/anonymizing the data. So I'd recommend the local approach, with a prominent explanation of how you don't and can't see any of the data.

[hunter2_]

This could work if the analytics engine is free and (ported to) JavaScript, but not if it's closed source. In the latter case, a trusted third party (escrow, one might call it) as OP described does seem like the way to go.

The problem is, why would end users trust the third party more than the analytics developer? Are there companies that specialize in being this third party and have amassed mutual trust of the general public (akin to a notary public) for handling data and code without leaking either?

[michealr]

Analytics wise, I'm ok with being restricted, other commenters have mentioned looking at WASM as a possible workaround. So local does seem to make the most sense, practicality wise

A thought, the possible scope of services in the data notary or data escrow side of things does seem like an underexplored product category.

[meowface]

Any such data notary/escrow company has a pretty good shot of eventually getting breached (they'd naturally be a prime target, since the attackers could get tons of data from tons of people on behalf of tons of different companies), and that'll possibly destroy that company and maybe also your app. There's also the risk they may eventually have rogue employees, etc.

[hunter2_]

Regular notaries could be as crooked as rogue employees, yet we still use them because imperfect barriers are still barriers (as with security).

But yeah, when computer-related vulnerabilities are thrown into the mix, it could get ugly.

[meowface]

Sure, there's often going to be some centralized source one needs to trust. The issue with a digital escrow vendor is kind of like the issue with cryptocurrency exchanges - one single breach and you immediately walk out with an unfathomably huge treasure trove.

A rogue notary employee can do some damage and notarize things in exchange for bribes, and a rogue bank employee could help siphon some money away, but a rogue digital escrow employee could be bribed to hand over terabytes of extremely sensitive data on lots of big customers, and a rogue cryptocurrency exchange employee could possibly help someone steal hundreds of millions of dollars pretty easily. It's a huge house of cards.

[nindalf]

It doesn't need to be in JavaScript. Any language that can compile to WebAssembly would work too. But I agree with the broader point - the code needs to execute on the client, not the server.

[satyrnein]

Maybe a browser extension with limited permissions? Say the tool looks at Slack and counts how often you use the ROFL emoji. The extension could be granted access to *.slack.com but no other domains.

[meowface]

That could work, but then you have the additional barrier of having to convince people to install your browser extension, and for people who are already worried about privacy, that comes with its own can of worms. Especially if they don't necessarily understand or trust the permission model.