skaul

Cool work. Can I ask: why not use MASQUE for this, instead of WireGuard-over-QUIC? Is it because it meant less changes on your partner's side?

So two hops, basically. First hop sees your IP address but not the website you're going to, second hop sees website but not IP address. Similar to Private Relay: https://support.apple.com/en-us/102602.

Credit to bsclifton for the idea!

It's not but given that Perplexity doesn't have an API and blocks automated downloads, I'm not sure what else to use. Explained in the docs: https://github.com/ShivanKaul/chromium-drift/blob/main/docs/...

Sorry about that! I've fixed the colors and contrast now.

Thanks, fixed now.

I worked with Ralph when he was at Brave. I fondly remember many long walks in downtown Vancouver with him, getting tea at Matchstick and chatting about Rust and privacy and ancient Egyptian hieroglyphics. I still can't believe this. Huge loss.

Programming languages need to give the developer a way to iterate (map, fold, for-loop, whatever) over a collection of items. Over time we've come up with more elegant ways of doing this, but as a programmer, until LLMs, you've still had to be actively involved in the control logic. My point is that a developer's relationship with the code is very different now, in a way that wasn't true with previous low-to-high level language climbs.

Programming with LLMs is fundamentally different than going from a lower-level to a higher-level language, even apart from the whole non-determinism thing. With a programming language, you're still writing a for-loop, whether that's in C, Java or Rust. There's language primitives that help you think better in certain languages, but they're still, at the end of the day, code and context that you have to hold in your head and be intimately familiar with.

That changes with LLMs. For now, you can use LLMs to help you code that way; a programming buddy whose code you review. That's soon going to become "quaint" (to quote the author) given the projected productivity gains of agents (and for many developers it already has).

You can add these to your `~/.claude/settings.json`:

  "env": {
    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "DISABLE_AUTOUPDATER": "1",
    "IS_DEMO": "1"
  }

We used to use Bloom filters in 2019, funnily enough: https://brave.com/blog/improved-ad-blocker-performance/

That is correct.

We use the same adblocking engine (adblock-rust) on all platforms, including iOS, hence the shared memory savings.

> Or does it still replace them with ads for scanmy cryptocurrency?

Brave never did that.

Brave blocks third-party ads & trackers by default.

(disclaimer: I lead privacy and adblocking at Brave)

Brave Software | C++ Engineer, Filterlist Engineer | REMOTE | Full-time

Brave is building a privacy-first browser and a more transparent Web for over 100M users.

On the privacy team, we are looking for:

- C++ Engineer: Working on privacy features in our Chromium-based core engine. Link: https://job-boards.greenhouse.io/brave/jobs/7339167

- Filterlist Engineer: Working on adblocking and JavaScript fixes for websites. Link: https://job-boards.greenhouse.io/brave/jobs/7434948

We are a remote-friendly company with a very-low-meeting culture.

Contact: shivan at brave dot com

Self-plug but if anyone is interested in learning more about how browser fingerprinting works and the different protections browser makers deploy against it, I wrote a longer post about this a few months ago: https://pitg.network/news/techdive/2025/08/15/browser-finger...

This would be akin to Chrome sending the user's (unmodified) URLs to Google. Even Chrome thinks that that would be really bad for user privacy, and goes through elaborate techniques to not leak the user's direct browsing to Google, even for security-positive use-cases like Safe Browsing.

This is easy in Brave, just go to brave://settings/shields/filters and enable the "YouTube Anti-Shorts" filter list.

> Even if you know the source of the text before you feed it to the model you still need to solve the problem of how to send untrusted text from a user through a model without that untrusted text being able to trigger additional tool calls or actions.

We're exploring taking the action plan that a reasoning model (which sees both trusted and untrusted text) comes up with and passing it to a second model, which doesn't see the untrusted text and which then evaluates it.

> The most credible pattern I've seen for that comes from the DeepMind CaMeL paper

Yeah we're aware of the CaMeL paper and are looking into it, but it's definitely challenging from an implementation pov.

Also, I see that we said "The browser should clearly separate the user’s instructions from the website’s contents when sending them as context to the model" in the blog post. That should have been "backend", not "model". Agreed that once you feed both trusted and untrusted tokens into the LLM the output must be considered unsafe.

You're right that if the user logs into a sensitive website, the "isolated browsing" mitigation stops helping. We don't want the user to accidentally end up in that state though. Separately, I can also imagine use-cases for agentic browsing where the user doesn't have to be logged into sensitive websites. Summarizing Hacker News front page, for one.

> I haven't seen a single credible technique from anyone that can distinguish content from instructions

You specifically mean that it's ~impossible to distinguish between content and instructions ONCE it is fed to the model, right? I agree with that. I was talking about a prior step, at the browser level. At the point that the query is sent to the backend, the browser would be able to distinguish between web contents and user prompt. This is useful for checking user-alignment of the output of the reasoning model (keeping in mind that the moment you feed in untrusted text into a model all bets are off).

We're actively thinking and working on this, so will have more to announce soon, but this discussion is useful!

> you reply to me like I need to be lectured

That's not my intention! Just stating how we're thinking about this.

> defense in depth is to prevent one layer failure from getting to the next

We think a separate model can help with one layer of this: checking if the planner model's actions are aligned with the user's request. But we also need guarantees at other layers, like distinguishing web contents from user instructions, or locking down what tools the model has access to in what context. Fundamentally, though, like we said in the blog post:

"The attack we developed shows that traditional Web security assumptions don’t hold for agentic AI, and that we need new security and privacy architectures for agentic browsing."

That was in the blog from the starting, and it's also the most important mitigation we identified immediately when starting to think about building agentic AI into the browser. Isolating agentic browsing while still enabling important use-cases (which is why users want to use agentic browsing in the first place) is the hard part, which is presumably why many browsers are just rolling out agentic capabilities in regular browsing.

That's not how defense-in-depth works. If a security mitigation catches 90% of the "easy" attacks, that's worth doing, especially when trying to give users an extremely powerful capability. It just shouldn't be the only security measure you're taking.

(I lead privacy at Brave and am one of the authors)

> Instead they believe model alignment, trying to understand when a user is doing a dangerous task, etc. will be enough.

No, we never claimed or believe that those will be enough. Those are just easy things that browser vendors should be doing, and would have prevented this simple attack. These are necessary, not sufficient.