skaul

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)

[BOTH FILLED] 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.

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.

(disclaimer: I lead privacy at Brave and wrote the article)

See the blog post for how we implemented this: https://brave.com/privacy-updates/35-block-recall/#how-we-im.... We took Recall's guidance for web browsers and extended it to apply for ALL windows, not just Private Browsing: https://learn.microsoft.com/en-us/windows/ai/recall/recall-w...

(disclaimer: I lead privacy at Brave and wrote the article)

How am I supposed to use Brave or Signal if the setting to disable this feature is not accessible because I can't even see the settings screen first?

Brave's implementation shouldn't block screen readers or screenshot tools. It only blocks Recall. See the blog post: https://brave.com/privacy-updates/35-block-recall#disabling-...

(disclaimer: I lead privacy at Brave and wrote the article)

Windows lets browser apps (more technically, apps that have an `http` or `https` protocol handler registered) to use `SetInputScope` function to set `IS_PRIVATE` for a window. We were able to use that and have it apply for all Brave windows, and thus granularly turn off Recall without affecting non-Recall screen readers or screenshot capabilities.

Signal doesn't have protocol handlers for `http` and `https`, so it can't do the same.

(Disclaimer: I lead privacy at Brave)

Mozilla uses the core protocol for Divvi Up for its privacy-preserving advertising. Brave recently wrote about why we disagree with the design of that system: https://brave.com/blog/mozilla-ppa/. The core difference is that Mozilla's system is a lot more complicated and expensive to operate, and it needs that complexity because they're trying to work with the existing third-party based advertising ecosystem and its enormous financial incentive for ad fraud.

Brave's DP system Nebula is not ads-related and is only used for product analytics, so it's a lot simpler while still preserving user privacy because it's not operating under the same constraints.

I thought this was what MuleSoft was designed to be, though I haven't kept track of what it looks like now

https://github.com/brave/brave-core/pull/11750 describes the more technically-involved part of the feature - we had to make sure that we detect an AMP page before it gets to the Chromium renderer process, in order to prevent the page from loading the AMP resources (and thus leaking the user's IP address and browsing behaviour to Google).

Brave has an option to block cookie notices - you need to enable the "Filter obtrusive cookie notices" list in brave://adblock. https://twitter.com/shivan_kaul/status/1488989740690853888

We're experimenting with blocking cookie notices by default in Nightly. There's webcompat risk - some websites just break if you block the cookie notice. "Works on 90% of websites" is just not good enough when deploying to 50 million Web users.