Your browser AI’s most important setting may be the source list

A browser feature makes the boundary visible

Mozilla announced new Smart Window form-filling and page-watching features on October 27. Its opt-in desktop beta can draw from selected tabs to suggest text for forms, and users review suggestions before submitting. Mozilla says selected source-page information goes to Gemini 3.1 Flash Lite for form assistance; ordinary saved autofill values stay on the device.

The distinction is the newsworthy lesson. Information being visible in a browser does not by itself mean it belongs in an AI request or a particular application. Selecting sources is a decision about purpose: which facts are appropriate for this task, and which should remain outside it?

Our interpretation is that good browser assistance should make that decision easy to understand. A user needs to know what was selected, what the system produced, and what still requires review. Convenience is useful when those boundaries remain visible. It becomes harder to assess when one vague instruction appears to authorize every tab and every next step.

This guide develops a fictional example: a student preparing an application for a community design workshop. It is not a report of hands-on testing, and it does not assume every reader has access to Smart Window. You can practice the same source-selection method manually.

The exercise is intentionally ordinary. Privacy choices are often made during rushed everyday tasks, not only in dramatic security incidents. A clear method for a workshop form can carry over to other work without requiring a lengthy policy review each time.

Source: Mozilla: Skip the busywork with Smart Window ↗ · Firefox Help: Fill out forms faster with Smart Window ↗ · Firefox Help: Create tasks in Smart Window ↗

Choose for the destination, not just the topic

Our fictional student has a public portfolio, a class-project page, a private planning document, and a chat with a collaborator. All four relate to design, but they do not have the same purpose or audience. A topic match is therefore an insufficient reason to include them together.

Start by reading the destination form. What does it actually ask? If it needs a short description of past projects, the public portfolio may be enough. If it asks for availability, the student can supply that directly without exposing a whole calendar or private planning page.

Make a small source list and write a reason next to each item. A useful reason is concrete: this page contains the published project title and my stated contribution. A weak reason is that the page might help. The second reason quietly invites broad collection without deciding what benefit it offers.

Then ask what a reasonable reviewer would expect to receive. A workshop organizer might need to know the student's role in a project. They probably do not need a teammate's private criticism or an unpublished client's contact details. Keep those outside the source set unless there is a specific authorized reason to include them.

This is a proposed practical privacy habit, not a claim that a source picker can guarantee every downstream outcome. The immediate benefit is clarity. By narrowing the input, you also make it easier to check whether each generated statement has an appropriate basis.

Create a small, reviewable application packet

You can reduce repeated source decisions by maintaining a short packet of facts you are comfortable using for applications. Include your preferred name, a concise project history, approved public links, and a description of your actual contributions. Review it periodically and remove outdated claims.

Keep this packet separate from a full personal archive. Its purpose is to support a particular kind of task, not to summarize your entire life. If a form asks for something outside it, that is a prompt to make a new decision rather than an invitation for the system to search more broadly.

In the workshop example, the packet might distinguish a solo poster design from a group exhibition. That distinction matters because a polished sentence can accidentally turn participation into ownership. Write roles precisely enough that an assistant can describe them without improvising status.

A no-purchase, no-new-tool version is simply a local document you copy from manually. The point is not to maximize automation. It is to keep the evidence small enough that you can recognize when a draft goes beyond it.

Do not fill the packet with sensitive data merely because another form might ask someday. Add information when there is a real purpose and an appropriate destination. If the packet becomes a collection of everything you have ever submitted, it has lost the focus that made it easy to review.

Treat the packet as source material, not a template that must be pasted unchanged. An accurate answer still needs to address the particular question in front of you.

Check claims before polishing the voice

Suppose the generated application says the student led a community campaign. The portfolio says only that they designed two posters as part of a team. The first sentence may sound stronger, but it changes the claim. Correct that before adjusting tone or making the answer more concise.

Review factual units individually: project title, role, date, quantity, result, and current availability. For each, ask whether the selected material supports it. A sentence can contain several claims even when it reads smoothly. Fluency should not make those claims harder to inspect.

Pay special attention to numbers. A draft might convert a goal into an achieved result or combine figures from different projects. In the fictional application, a planned exhibition attendance estimate should not become the number of people who saw the student's work. Keep intended outcomes and recorded outcomes distinct.

Then review fit to the question. An answer can be factually accurate and still fail to explain why the applicant wants this workshop. Personal motivation may require the student's own fresh input. An assistant should not invent a moving reason simply because the field is empty.

Only after the facts are settled should you edit voice. You can make the text warmer, shorter, or more direct while keeping the same evidence. This order reduces the chance of becoming attached to a polished sentence that you later discover is unsupported.

If you cannot verify a detail quickly, omit it or replace it with a narrower statement you can support. A modest accurate application is a better representation of the person than an impressive draft they cannot explain.

The last click carries a different responsibility

Mozilla says Smart Window suggests form content and does not submit the form for the user. That boundary is worth preserving in your own habits. Preparing text and committing it to a destination are different decisions, especially when a form includes declarations, agreements, or information about other people.

Read the completed form as the recipient will see it. Check that text did not land in the wrong field and that an answer does not depend on context absent from the submission. A perfectly accurate project paragraph can still be confusing if the organizer cannot tell which question it addresses.

Review attachments and links separately. A link to an entire shared folder may expose more than the single portfolio sample you intended to provide. Use the actual destination's sharing controls and verify what a permitted recipient can access. Do not assume that a generated link label describes the access granted.

Before submission, decide whether to keep a copy and what it should contain. A record of the final answers can help with later follow-up, but it need not include unnecessary source-page content. Save only what serves your purpose.

The ethical point is practical accountability. The applicant should understand what they are claiming and where they sent it. An AI-assisted draft can make preparation easier, but it should not leave the person unable to explain the finished application in an interview or conversation.

Watching a page is a task, not a promise of constant coverage

Mozilla's announcement says Smart Window page checks run while the browser is open, with daily or weekly checks selected by the user. Its task documentation describes managing watched pages and pausing or deleting tasks. That makes this a bounded convenience, not a guarantee of continuous monitoring.

For the workshop example, a useful watch request would identify the official page and the exact change that matters, such as applications opening for a named session. A vague request to find interesting opportunities leaves too much room for interpretation and makes false matches harder to judge.

Record what you would do if no notification arrives. If a deadline matters, keep an independent calendar reminder or another appropriate check. This is a proposed reliability practice, not a claim that Mozilla's feature has failed. It follows from distinguishing a helpful signal from a guaranteed service level.

Also decide when the task should end. After submitting an application, you may no longer need to watch the opening date. A task list that accumulates indefinitely becomes difficult to understand. Reviewing old watches can reduce distracting alerts and clarify what you still care about.

When a match appears, open the original source and confirm the details before acting. A changed page might contain the right words while referring to a different location or date. Treat the alert as a route back to evidence rather than a replacement for reading the actual announcement.

This same habit applies beyond one browser. Write a specific condition, identify the authoritative source, understand the checking schedule, and keep a fallback for consequential deadlines.

A useful consent choice has a small scope; try the method on a fictional form

Consent is easier to understand when it names a specific action. Using these two public pages to draft this application is a more concrete decision than allowing assistance with browsing in general. In your workflow, prefer choices you can restate in one sentence.

Ask three questions before sharing source information with an AI feature: what is being sent, why is it needed, and what output am I authorizing? If the answer is unclear, simplify the task or consult the product's current documentation. Do not fill the gap with an assumption that everything stays local or that every model setting applies to every feature.

Mozilla distinguishes the models used for these new features from the user's Smart Window chat model choice. That is a useful reminder to read feature-specific explanations. A familiar settings screen may not describe every data flow in a growing product.

For shared work, consider the people represented in the source. Your access to a collaborator's note is not automatically permission to submit it to a new recipient or service. Ask for an approved public description or write a narrower answer using your own contribution.

A good practical default is to make the source set smaller before making the instruction longer. That does not solve every privacy problem, but it gives both the user and any reviewer a more manageable task. You can inspect three relevant paragraphs more effectively than an undifferentiated collection of open tabs.

The aim is informed control that fits ordinary work, not a ritual of clicking through warnings nobody can connect to the task.

Create a practice form with four fields: project, role, motivation, and availability. Use fictional names and non-sensitive sample material. Prepare one short public-style project description and a separate private note containing details that should not be used.

Draft answers manually or with a tool you are already authorized to use, supplying only the public-style description. Then inspect whether the role remains accurate, whether missing information is identified, and whether the motivation is invented. Add your own fictional motivation and revise the draft.

Ask a second person to compare the final answer with the approved source. Give them no access to the private note. They should be able to explain why each factual claim belongs. If they cannot, narrow the answer or improve the packet.

Next write a precise watch condition for the fictional workshop page. State the event, the page, the checking expectation, and the end condition. Do not actually submit or enable anything for this exercise. You are practicing how to define a useful request.

Keep the resulting checklist short enough to use on a real task: choose relevant sources, inspect factual claims, review the destination, and confirm before submitting. Browser AI is most useful when it reduces repetitive work while leaving these decisions understandable to the person whose information and reputation are involved.