jupenur

> Ultimately, it all stems from our responsibility to our users. The security researchers are not special, the insight and confidentiality are, and we need them to keep our users safe. Ignoring a security report communicates you don’t care about users’ security, and it’s rightly a reason for shame.

100%. This was always true and I still think it is. LLMs don't change anything. At most they shift the balance and force a temporary compromise.

> LLMs are as good as almost any security researcher

This statement is extremely dependent on the definition of a security researcher. It might hold if you consider anyone with a HackerOne account, but if you restrict the definition to people who actually put in some effort, it's just not true. LLMs can find some real vulnerabilities, yes, but they also spew unprecedented volumes of garbage that an expert can immediately recognize as such.

> The insight is not scarce and precious anymore. The bottleneck now is not finding potential issues but assessing which ones are real.

Assessing which ones are real should be part of the insight. Real researchers will not submit 150 pages of spam, and three real bugs hidden in 150 pages of spam are not insight. In most cases a researcher will spend significant effort on triage before submitting anything, and an LLM still cannot do that reliably.

> Confidentiality, embargoes, and coordination also don’t matter nearly as much as they used to.

I'd argue these now matter more: the one thing LLMs do seem to do fairly well is figure out specific things based on sufficient information and a scope that's limited enough. So a plain commit containing a security fix is now much easier and cheaper to turn into an exploit than it was before.

> The years of vulnerability reports being special might be over, as weird and uncomfortable as that feels.

I'd hope not. Bug bounties might be over unless someone can figure out the spam problem, but disclosure programs that don't offer monetary incentives are probably just going through a tough period that will eventually calm down as the operators of LLMs realize the costs and do the math.

Unreliable reports have always been an issue and will remain one, LLMs or no. When it gets worse, like in the current influx of LLM-generated reports, the focus should be on identifying reliable researchers, building relationships, and providing guidance on how they can make the reports easier to triage.

Researchers are not special, but the insight they can provide totally is. LLMs might force everyone to make better use of that insight, instead of just consuming bug reports and drowning in triage.

One specific area where I'd love to see more focus and attention is the web as a platform for E2EE applications. Currently, because of the inherent problems related to application delivery and trust relationships on the web, every step forward in E2EE adoption is a step away from webapps being first-class citizens -- even as PWAs keep becoming more viable for a wider range of use-cases otherwise. Even though an increasing number of companies maintain web implementations of their E2EE apps, these are always the fallback option when nothing "better" is available; the tech to make E2EE secure in webapps doesn't exist yet, but companies also have a unrelated incentives to push users to native apps. There are no serious efforts to remedy the situation and develop tech that would make it possible to deliver secure E2EE through the web.

The post mentions a couple of relevant goals:

> 3. Control over endpoints

> 8. Third-party scrutiny

They also mention the Code Verify extension[1], which may seem like a solution, but does not stand up to scrutiny: It only notifies the user of unexpected changes in the app, but does not prevent them. The detection logic it implements also seems trivially bypassable, and in more ways than one. Even if it was sufficiently enforcing application integrity, an extension like Code Verify is unlikely to ever become widely-adopted enough to make a dent. And of course it's not even available in all browsers on all host platforms.

There are also other similar extensions that suffer from similar shortcomings.

Browser vendors could solve the problem by providing APIs that allow the kind of integrity enforcement needed, akin to SRI[2], but that would mean you first have to agree on a standard and then implement it consistently everywhere and then webapps could slowly start adopting it. And because of past failures like HPKP[3], browser vendors would probably be hesitant to even start considering anything like it.

I believe a solution is possible using only the currently available web APIs, however, and for the past few months I've been prototyping something that's now at a stage where I can call it functional. The general idea is that using service worker APIs and a little bit of cryptography, a server and a client application can mutually agree to harden the application instance in a way that the server can no longer push new updates to it. After that, the client application can be inspected manually with no risk of it changing unannounced, and new versions of the app can be delivered in a controlled way. While my prototype is nowhere near production-grade at this point, it's nearing a stage where I'll be able to publish it for public scrutiny and fully validate the concept. Until then I'll be implementing tests and examples, documenting the API and threat model, and smoothing out the rough parts of the code.

If anyone's interested in collaborating on this or just hearing more details, feel free to reach out. I'd love some early feedback before going fully public.

My proposed solution is to use Service Workers to cache a web app in the browser and employ clever tricks to prevent the server from pushing updates to either the Service Worker or the caches. This way the user can then control any updates and verify new versions using means that are already familiar from other ecosystems: comparing hashes, trusting only signed code, etc.

The goal isn't to develop a new e2ee messaging app. Instead I'm prototyping something that resembles an auto-update framework like Squirrel [1], only for web apps. Ideally it will be largely "plug and play", i.e. you could take the existing WhatsApp web app, serve it using the updater framework, and your users would now have a trustworthy version of WhatsApp.

So far I have a small amount of PoC-level code validating several small parts of the larger concept. For instance, I'm fairly confident that I will be able to reliably prevent forceful server-controlled updates, which is a core requirement. Right now I'm in the process of formalizing a threat model, hoping to spot any gaps before I move forward with the implementation.

Feedback on the idea in general would be highly appreciated, but I'd also love to hear any more specific concerns regarding technical solutions, UX, etc.

Even if you don't use Chrome, you probably have at least a few Electron apps installed; they all suffer from the same issue.

The only logical conclusion is the macOS privacy model, TCC, is doomed. There's always an app that has non-default TCC permissions and is vulnerable to some type of local code injection, and at that point any malicious app can also access those TCC-protected features.