Asking before going online: consent for web search

01

Introduction

Brello 1.0 (version 1.0.0, 4 October 2026) is a private AI assistant for Android and iPhone, made by Stuvio, that runs its language models entirely on the phone. Web search is off by default, and when a question looks as if it needs current facts, Brello stops and asks before anything is sent.

There is no account and no Brello server. A model is downloaded once, and from then on the assistant answers offline. Web search is the exception. When Brello searches, the search text goes from the phone to a search engine, and up to four result pages are requested from their websites, which see a normal web request. It is the only point at which text from a conversation leaves the phone, so we treat it as the person’s decision rather than the software’s.

This paper describes that decision as Brello 1.0 implements it: the checks that route each message, the word list that triggers a request, the card that asks, the rewriting that fixes what text is sent, and the status and meta lines that report afterwards what happened. Figure 1 follows seven example messages through the checks, in six steps. The rules and interface strings in the figures are the app’s own; the example messages are illustrative. We report no user measurements. This is a description of the design as built, with its limitations.

Section 2 places the design in the privacy research it draws on. Sections 3 to 8 describe the mechanism in the order it runs, section 9 sets out what leaves the phone and to whom, and sections 10 and 11 cover limitations and open questions, including how we intend to carry the pattern into Brello Super Intelligence, which is in development.

02

Background and related work

Three findings from privacy research shape the design: protective settings should be the default, a request for consent works best at the moment the data would be used, and a request repeated too often stops being read.

On defaults, Article 25 of the GDPR requires data protection by default: in a system’s default settings, only the personal data necessary for each specific purpose should be processed.1 Cavoukian’s Privacy by Design principles state the same idea as an engineering goal, so that a person’s privacy stays intact if they do nothing.2 Defaults matter because people tend to keep them. Schaub, Balebako, Durity and Cranor note that default settings “may be kept unchanged out of convenience or because they are interpreted as implicit recommendations”.3

On timing, the same authors describe a design space for privacy notices with four dimensions: timing, channel, modality and control.3 A notice can appear at setup, just in time, in response to context, periodically, persistently or on demand. A just-in-time notice appears when a data practice is about to happen, so the person decides in context. A control can be blocking, non-blocking or decoupled from the notice. A blocking notice holds the action until the person chooses, and the authors argue it should offer a meaningful choice rather than take-it-or-leave-it.

Asking too early fails in practice. In a 2012 study of the permission screen Android then showed at installation, Felt and colleagues found that 17% of participants paid attention to permissions while installing, and only 3% of survey respondents answered all three comprehension questions correctly.4 Since Android 6.0, apps must request dangerous permissions at runtime, and Android’s developer guidance reads: “Ask for a permission in context, when the user starts to interact with the feature that requires it.”5

Asking too often fails as well. Böhme and Köpsell ran a field experiment with users of an online anonymisation tool and found that people accepted a consent dialog more readily the more it resembled a routine licence agreement, which they read as a sign of habituation.6 Schaub and colleagues make the same point about notices in general: repeated notices are clicked away without their content being considered.3

Together these point to a shape for consent around web search: off by default, asked at the moment a question needs it, with an alternative that still helps, and rare enough to stay meaningful. Brello 1.0 follows that shape. Sections 10 and 11 say where it falls short.

03

Design goals

We set five requirements for how Brello 1.0 goes online, and each is met by a specific mechanism.

1. Nothing leaves without a decision. With default settings, no text from a conversation goes to a search engine. Web search starts switched off, and the hidden browser Brello searches from is not even warmed up until search is on.
2. Interrupt only when it helps. Brello asks only when the wording suggests the answer depends on current facts. Photo questions, short small talk, arithmetic, and creative tasks that mention nothing fresh never bring up the card.
3. Give the reason and the consequence. The card says why it is asking and what stays on the phone, and says before the choice is made that choosing search turns web search on.
4. Make declining useful. “Answer offline” still produces an answer from the on-device model.
5. Show what happened. While a reply is being made and after it is finished, the interface says whether the web was used.

Goals 1 and 4 follow from the work on defaults and meaningful choice, goal 2 from the evidence on habituation, and goals 3 and 5 from the work on notice timing. None of them is new. What this paper adds is a complete, documented instance of them in a working on-device assistant, with the exact rules and copy.

04

How a message is routed

Up to three checks run on the phone before the model writes anything, and Figure 1 shows them in order. The first looks for a photo. The second reads the web search setting. The third depends on that setting: with search off, it looks for time-sensitive wording, and with search on, it looks for small talk, arithmetic and creative tasks.

Photos never search

A message with a photo is answered by the on-device model and is never searched, whatever it says and whether or not web search is on. The rule is fixed rather than a judgement, so no wording can turn a photo question into a search. Photos are never uploaded in any case, and the rule also keeps the words of a photo question on the phone. The cost is that a photo question cannot get current facts, a limitation we return to in section 10.

With search off, Brello asks before time-sensitive questions

With web search off, Brello asks only when the wording of a question looks time-sensitive, and otherwise answers on the phone without asking. Small talk, arithmetic and creative tasks are answered on the phone in the same way, unless they use one of the listed words. Section 5 gives the list, and section 6 describes the card that asks.

With search on, Brello skips messages that never need the web

With web search on, Brello searches for any message that merits a lookup, and the research pipeline runs on the phone, as described in “Answering from the open web, without a server”. A message merits a lookup unless it is very short, arithmetic, small talk or a creative task. Brello does not search for messages under four characters, for pure arithmetic such as “12 * 7”, or for short small talk such as “hi”, “thanks”, “how are you”, “who are you” and “what can you do”. Creative and writing tasks are recognised by words and phrases such as write, translate, summarize, proofread, brainstorm, tell me a joke and role play, and are answered on the phone unless the message also mentions something fresh. “Write a poem about autumn” is not searched. A request to summarise today’s headlines is treated like any other question about the news.

The checks are word-level heuristics. They are cheap to run on a phone, they behave the same way every time, and they can be tested: Brello 1.0’s unit tests cover the search heuristics and query refinement. The price of that predictability is that they read wording, not meaning, so they can be wrong in both directions, as section 5 explains.

05

Detecting time-sensitive questions

With web search off, Brello asks before answering when a question contains a word or phrase from a fixed list of time-sensitive signals. Each signal points at something that changes: a price, a score, a forecast, a result or a release. Table 1 gives the list in Brello 1.0.

These are the questions a model on a phone is most likely to answer from out-of-date memory, because its knowledge stops where its training data ends. The check can be wrong in two directions, and the costs are lopsided. A false alarm costs one tap on “Answer offline”. A miss means an answer from the model’s own knowledge, which may be stale.

Two details reduce the cost of a miss. When a question is about time, Brello adds the current date to the system prompt, so the model at least knows the date. The system prompt also tells the model: “If you are not sure about something, say so instead of guessing.” Neither kind of error sends anything off the phone.

06

The permission card

When the check fires, the reply pauses with the status “Needs the web” and Brello shows a card. The card is the whole consent interaction: a title, two sentences, two buttons and a footnote, each with one job. Figure 2 recreates it with its exact copy.

1. “Search the web for this?” The title asks about this message only, names the action and waits. Nothing is sent until the person chooses.
2. “This looks like it needs up-to-date information.” It gives the reason, and “looks like” is accurate about what the check is: an inference from wording, not a certainty.
3. “Brello can look it up straight from your phone — the AI still runs on-device.” It says what would change and what would not. The lookup goes directly from the phone, and the model that reads the results and writes the answer stays on it.
4. “Search the web” and “Answer offline”. Both buttons are verbs and both lead to an answer. Declining is not “Cancel”. It is a real choice with a useful result, which is what Schaub and colleagues ask of a blocking control.3
5. “Choosing search turns on web search. You can switch it off anytime from +.” It states the lasting consequence before the choice is made, and names the way back.

What the choice changes

Choosing “Search the web” does two things: it runs the search for this question, and it turns web search on for the questions that follow. While search is on, a “Web search” chip sits in the input bar. Search can be switched off from the + menu, which confirms with a “Web search off” toast, or with the “Search the web” switch in Settings, shown in Figure 3. Choosing “Answer offline” leaves search off, and the next time-sensitive question brings the card back.

One decision rather than a prompt for every message

We chose a single decision that lasts until it is reversed. Asking before every search would look stricter, but someone following a live story would see the same card on every question, and a prompt seen that often stops being read.3,6 The decision is stated with its consequence, can be reversed from two places, and stays visible as the chip for as long as it lasts. The cost is granularity: after one yes, later searches are not confirmed one by one. Whether people understand a lasting yes as intended is an open question, discussed in section 11.

07

From question to search query

When a search runs, Brello rewrites the question on the phone into a short query, and that query is the only text from the conversation that the search engine receives. People ask the way they would ask a friend, and a search query is shorter and leads with keywords. Because the rewriting runs before anything is sent, it also fixes exactly what leaves the phone. Figure 4 applies each rule to the app’s own examples.

• Instructions about the answer are removed. “Keep it short.”, “in two sentences”, “ELI5” and “please” tell the model how to reply, and a search engine has no use for them.
• Contractions are expanded, so “what’s” becomes “what is”.
• A common phrasing is rewritten. “What’s new in X” becomes “latest X news”.
• Time-relative questions gain a date. A question with no year gets the current month and year, so that the query names the period the person means: “latest iPhone release” becomes “latest iPhone release October 2026”. Live data is the exception, and questions about weather, scores, prices, stocks, rates and traffic are left undated.
• Follow-ups borrow context. A message of four words or fewer, or one that refers back with words such as “he”, “it”, “that” or “they”, gets the first ten words of the previous question placed in front of it. On its own, “how old is he?” means nothing to a search engine.

Only the last rule carries words from earlier in the conversation, so a follow-up search can send up to ten words of the previous question. For that reason we list it with the privacy properties in section 9. What happens after the query leaves, from the provider chain to BM25 passage ranking, is described in “Answering from the open web, without a server”.

08

Showing what happened

Brello 1.0 reports whether the web was used twice: in the reply’s status line while the reply is being made, and in its meta line once it is finished.

During a search, the status line beside the reply’s orb moves through “Searching the web”, then “Reading 4 sources” with small letter marks for the sites being read, then “Thinking”. Without a search it goes straight to “Thinking”, or to “Reasoning” in Think harder mode. It ends on the name of the model that wrote the answer. Figure 5 shows both paths.

Every finished answer then carries a quiet meta line beside a lock, such as “3.1s · Web + on-device” or “2.4s · On-device”, giving the time taken and whether the web was used. The meta line records whether web results were given to the model, and the numbered citations show which pages it relied on: a web answer shows source cards above its text, and each citation opens its page. A “Web + on-device” answer can still draw on the model’s own knowledge, because the prompt tells it to answer from general knowledge when the results do not answer the question. The letter marks on the cards are drawn on the phone, so showing a source sends no request to the site.

Every notice, by timing

Table 2 places each notice in Brello 1.0 in the design space of Schaub and colleagues.3 All of them are visual and appear on the phone itself.

The design gives notice at setup, on demand, just in time and persistently. Only the card blocks: the reply waits until the person chooses, and the Settings switch is a control decoupled from any notice. The meta line is the one element without a counterpart in the taxonomy. It is not a notice about a practice in progress but a record attached to each answer, which is where we think an after-the-fact disclosure belongs.

09

Privacy properties

A search sends two kinds of request directly from the phone: the query to a search engine, and ordinary page requests to up to four websites in the results. Table 3 lists everything that leaves during a search, and to whom.

The engines are tried in a fixed order until one returns relevant results, and a provider that fails or is blocked is rested for two minutes, so a single search can reach more than one engine. Search and page requests carry the Do Not Track and Global Privacy Control signals, DNT: 1 and Sec-GPC: 1.7,8 The rest of the conversation, any photo and the answer stay on the phone, and the model that reads the pages and writes the reply runs there too. There is no Brello server, proxy or relay, so there is nothing for us to log.

The invisible browser that runs searches exists only while it is needed. It warms up only when search is on, and after three idle minutes it is torn down and its cookies, cache and local storage are wiped. Results are cached in memory for fifteen minutes to avoid repeat lookups, and are gone when the app closes.

Asking does not change what the other side sees. The search engine and the websites receive each request, including the phone’s IP address, as they would for any ordinary web request, and the query still reveals what the question is about. Brello does not hide that, and it adds nothing of its own. That is why the card asks rather than assumes, and why we describe the trade in plain terms. The NIST Privacy Framework treats such description as a function in its own right, Communicate-P: activities that let organisations and individuals reliably understand how data are processed and the privacy risks involved.9 The rest of Brello 1.0’s data handling is covered in its privacy policy.

10

Limitations

The design rests on word lists and fixed rules, so it can be wrong in both directions, and the consent it collects is coarse.

• It can miss. A question can depend on recent facts without using any listed word, such as a question about who holds a particular office. With search off, Brello answers it from the model’s knowledge without asking.
• It can over-ask. A listed word can appear in a question that does not need the web. “What is the history of the stock market?” contains “stock” and may bring up the card, at the cost of one tap.
• The signals are English. The list is made of English words and phrases, like the app’s interface, so a question in another language is less likely to match.
• A yes lasts. One yes turns search on until the person turns it off, and later searches are not confirmed one by one. The chip and the meta line show the state instead.
• Follow-up expansion is a word count. It borrows the first ten words of the previous question whole. They can be cut mid-phrase, as in Figure 4, and can carry details the person did not think of as part of the new question.
• A photo question never gets current facts. The photo rule keeps every photo question on the phone, including one where fresh information would help, such as what an item in the photo costs today.
• Search depends on third parties. One provider attempt can take up to 14 seconds, and a search can come back empty, in which case Brello answers from the model’s own knowledge.
• Asking does not change what a search engine sees. The query still reveals the topic, and the engine and websites see the request and the phone’s IP address.
• No user measurements. This paper reports no measurements of how often the check fires, which button people choose, or whether they understand the card. Brello 1.0 contains no analytics, so such data would have to come from a study.

11

Open questions

Status: design intent, not results. Brello Super Intelligence is in development. This section describes intent for it; the sections above describe Brello 1.0 as built.

Brello Super Intelligence (Brello SI) is in development, and we intend it to keep the rule this paper describes: a reach beyond the device waits for the person’s decision. The Brello Charter, version 1.0, describes the open web as a layer Brello SI is intended to use only when the person allows it (section 4), and commits us to asking before Brello spends money, sends a message or deletes something on their behalf (commitment 05). Read the Brello Charter.

• How consent should scale with consequence. A search reveals a query. An action taken for someone can have effects that cannot be undone. We intend each such action to need its own decision, and we have not settled how that request should read.
• How long a yes should last. It could cover one question, one conversation, or everything until it is switched off. Each choice trades attention against granularity, and the card would have to state its scope in a few words.
• Whether the time-sensitivity check can be learned without losing predictability. A model-based check might catch paraphrases that the word list misses, but it would be harder to test and to explain.
• How to tell that a prompt is understood, not just answered. The rate at which people choose each button measures behaviour, not comprehension, and we do not yet have a method we trust for measuring understanding. Our approach to pre-release evaluation is set out in “Evaluate first, then ship”.
• What a request to use private compute should say. When work has to leave the device, the request has more to explain than a search does: where the work runs, what is kept and how that can be checked. The design space is set out in “Private compute you can verify: the design space”.

We intend Brello SI to keep the three parts of this design for every request that leaves the device: it will ask first, give the reason, and record afterwards what was sent.