Ply is a privacy-first "browser for synthesis": a real Chromium engine wrapped in tools for reading, capturing, and turning what you read into something you keep. By default, everything stays on your device, with no telemetry, no accounts, and no cloud. This handbook covers how to use every feature (Part I) and exactly how Ply's privacy and security work (Part II).
Ply is a privacy-first desktop browser built for one thing most browsers ignore: turning what you read into something you keep. It runs on a real Chromium engine, so the open web works exactly as you expect, but wrapped around that engine is a set of tools for reading, capturing, and synthesizing. You can clip a passage, jot a note tied to a page, save a link, and pull all of it together into a writing canvas, without ever leaving the browser or copying things into a separate app. That's why we call Ply "a browser for synthesis." It's a browser that helps you make something out of pages, not just find them.
The core promise is simple: by default, Ply keeps everything on your device. There is no telemetry, no usage tracking, no analytics, no remote servers holding your data, and no account to create. Ply never phones home, and it never loads content from outside services to dress up its own interface. Your history, your saved clippings, your notes, and your canvas all live on your own machine. There are exactly four times Ply ever reaches beyond your device, and all four are off by default and fully under your control:
That's the whole list. Part II of this handbook explains each one in detail, including exactly what is sent and what is not. Note: "On your device" is a promise about where your data goes, not a claim that your machine is unbreakable. If someone else can use your computer while it's unlocked, they can use Ply. For protecting data at rest, see the optional encryption vault later in this handbook.
Ply is for people who read to think: researchers, writers, students, analysts, and anyone who collects and connects ideas across many pages. If you've ever ended a research session with forty open tabs and no idea what you actually learned, Ply is built for you. Compared to a normal browser, Ply differs in two big ways. First, the research and synthesis tools are built in, not bolted on through extensions. Second, the privacy defaults are strong out of the box: ad and tracker blocking, fingerprinting defenses, manipulative-pattern blocking, third- party cookie stripping, automatic HTTPS upgrades, and link cleaning are all on from the first launch, with per-site controls when you need them.
When Ply opens, here's how the window is laid out. Later sections go deep on each piece; this is just to orient you.
From here, the rest of the handbook walks through each of these in turn, starting with how to get around, then capturing and synthesizing, then the privacy and security model in full.
This section walks you through installing Ply, what you'll see the first time you open it, how to make Ply your default browser, and the handful of settings most people want to adjust before they start browsing.
Ply ships as a separate download for each operating system. Pick the one for your machine.
macOS builds are code-signed and notarized by Apple, so Gatekeeper recognizes Ply as a known developer's app and won't show the "unidentified developer" warning. The first launch from a freshly downloaded copy may still ask you to confirm you want to open it, which is normal. Note: On a brand-new Mac you may need to right-click the app and choose Open the very first time if your security settings are strict. After that, Ply opens normally.
Where Windows signing is available, the installer is signed, so Windows SmartScreen is less likely to flag it. If you do see a SmartScreen prompt on an unsigned build, choose More info → Run anyway only if you trust the download source.
When Ply opens for the first time it starts on a single Home page. There's nothing to clean up and no preloaded clutter, just one tab to begin from. A short welcome tour appears over it. The tour is 7 steps, and each step uses Skip, Back, and Next controls, ending with a Get started button. The steps introduce, in order:
You can replay the tour at any time from Settings ▸ About ▸ Welcome tour, or from the Help menu.
Ply can act as your system's default web browser so that links from other apps open in it. The in-app trigger lives in Settings ▸ General, in the Default browser row with a Set as default button. What happens when you click it depends on your operating system:
Note: Set as default works only in an installed build, not while running Ply from a development copy. In every case the operating system gets the final say: you still have to confirm the choice in the OS, and Ply can't switch your default browser silently behind your back.
Everything below lives in Settings (open it from the gear in the bottom-left rail, or press Cmd/Ctrl+,). None of it is required, but these are the choices most people make early.
| Where | What you can change |
|---|---|
| Appearance | Theme (Light / Dark / Auto), accent color (Ply orange is the default, plus Warm orange, Amber, Moss, Slate, Plum), and interface density. |
| General | Your default search engine and the URL new pages open to. |
| Privacy & Security | The protection toggles. Ad/tracker blocking, fingerprint randomizing, manipulative-pattern blocking, HTTPS upgrade, AMP stripping, link- redirect skipping, and tracking-parameter stripping are already on by default. Third-party- script blocking and strict mode (a uniform en- |
| Where | What you can change US identity) are off by default; turn them on if you want stronger protection and can tolerate a few sites behaving differently. |
| Encryption | The optional password vault, which encrypts your synthesis data (workspaces, history, Stuff, Canvas, notes, and snips) at rest, and lets you unlock with Touch ID / Windows Hello. It's off by default. See the encryption section of this handbook before enabling it, and read the caveats there. |
| Passwords | The optional built-in password manager (save, fill, generate, and import logins). It rides the vault, so turn on Encryption first. Off by default. |
| AI | Off by default. If you want the AI features, this is where you enable bring-your-own-model and point Ply at your own endpoint. |
Caution: The password vault protects your data on a powered-off or stolen drive. If you turn it on and forget your password without setting up keychain unlock, your data is unrecoverable. Read the encryption section first.
When you update Ply, the next time you launch it you'll see a What's New dialog. It shows a cumulative list of every change since the version you last ran, so if you skip a few releases you still see everything you missed in one place. (On a brand-new install, with no previous version on record, it stays quiet.) You can reopen it any time from Settings ▸ About ▸ What's New.
Day to day, Ply behaves like a browser you already know: a strip of tabs at the top, a Back/Forward/Reload row, and an address bar in the middle. What is different is what happens behind the scenes to keep your machine responsive and your browsing private. This section covers the everyday mechanics and the few performance behaviors worth understanding so nothing surprises you.
Each tab is a page inside the current workspace. (Workspaces are covered in their own section; for now, think of each workspace as its own independent set of tabs.)
When you open a new page you land on Ply's start page rather than a remote home page. You can change what a new page opens to in Settings ▸ General (the new-page URL and the on- startup behavior). The start page deliberately hides most of the toolbar buttons, since there's no site yet to act on.
The bar in the middle is both an address bar and a search box. Type a web address and press Enter to go there; type anything else and Ply runs it through your chosen search engine (set in Settings ▸ General).
On the left of the bar sits a small site-privacy button that doubles as a security indicator: Icon Meaning Search glyph You're on Ply's start page Lock Connection encrypted (HTTPS) Warning Not secure (plain HTTP) Clicking it opens the privacy panel for the current site. Next to the bar you'll also see a short "N blocked" readout (or "blocker off") showing how many trackers Ply stopped on this page.
When a site tries to open a pop-up window (whether through a link set to open in a new window or a script calling for one), Ply never creates a separate floating window. Instead, the destination opens as a normal new Ply tab, with no hidden link back to the page that spawned it. This is a deliberate privacy and consistency choice, and it has one practical consequence worth knowing: Note: Sign-in flows that rely on a pop-up window (some "Log in with…" OAuth pop-ups) will not work as designed, because the pop-up arrives as an independent tab with no connection to the original page. Where a site offers a same-tab "redirect" sign-in option instead, use that.
Split view puts two pages side by side in the same workspace.
Toggle the button again to collapse back to a single pane.
You can pin a page so it stays put and out of the way. Pinned tabs are treated as important: as you'll see below, Ply never puts a pinned tab to sleep, so a pinned page stays live and ready.
When a tab is actually making sound, a small speaker button appears in two places: on that tab's row in the sidebar, and in the toolbar. Click either one to mute the tab; click again to unmute. Only tabs that are genuinely playing audio show the control, so a muted autoplay video in the background won't clutter your tabs with speaker icons. Muting is per-tab and deliberately resets when you restart Ply, the same way Chrome behaves, so a mute is a quick "quiet this for now" rather than a permanent per-site setting.
Ply works to stay light even with many tabs open, using two related mechanisms. A limited number of tabs stay "live." At most 8 pages keep a fully running, in-memory view at once (the most recently used ones). Open more than that and the least-recently-used page quietly unloads its live view. The tab itself stays in your strip, and clicking it reloads the page. Background tabs go to sleep when idle. A page you haven't touched for a while is frozen to free up memory and CPU. The default is 10 minutes of inactivity, adjustable in Settings ▸ Behavior (range 1 to 120 minutes). Two kinds of tab are always exempt: the active tab in each workspace, and any pinned tab. Caution: When you return to a frozen or unloaded tab, Ply reloads the page from scratch. Anything you'd entered but not saved, such as a half-typed form, an unsubmitted comment, or an in-page scroll position, may be lost. If you have work in progress on a page, finish or save it before leaving that tab idle for long.
In the left rail's bottom block, the Session button opens a small card showing Memory, Pages, Awake, and Asleep. The Memory line (the "MEM" figure) is Ply's real memory use as your operating system reports it: the same number you'd see for Ply in Windows Task Manager's "Memory" column or in macOS Activity Monitor's "Memory" column. This matters because browsers are notorious for memory figures that look alarmingly high due to how shared system memory is counted. Ply deliberately asks the OS for its own honest number rather than estimating internally, so what you see lines up with what your system tools show. The figure refreshes every few seconds, so expect it to climb as you open pages and drop as background tabs go to sleep.
A workspace is Ply's main way of keeping different projects and contexts apart. Each workspace has its own set of tabs (pages), its own split-pane layout, its own Stuff library of saved snippets, highlights, notes, and links, and its own Canvas synthesis document. Switching workspaces swaps all of that at once, so research for one project never mixes with another. You might keep one workspace for work, one for a personal reading project, and one for shopping; each remembers its own open tabs and the material you have collected. Workspaces live in the left rail at the top of the window. Each row shows the workspace's icon and color, its name, and a count of its open pages.
Note: Ply keeps a limited number of pages "awake" (with a live, loaded view) per workspace (eight at a time by default), plus it can put idle background pages to sleep after ten minutes. Sleeping or unloaded pages reload from their saved address when you return to them, so they may lose unsaved in-page state (like a half-filled form). The active page and pinned pages are never put to sleep.
Give each workspace a recognizable look so you can tell them apart at a glance:
The icon and color are purely visual cues in Ply's own window. They do not change anything a website can see, and they are not used as your taskbar or dock icon. Ply's app icon stays the same regardless of which workspace is active.
Each workspace carries its own settings and saved material, so the things you set inside it stay attached to it: its name, icon, and color; its open pages, tab order, and split-pane arrangement; its recently-closed pages (so you can reopen them); per-site zoom levels; and its Stuff library and Canvas document. When you export a workspace to share or back it up, this is the material that travels with it. (See the Import & Export section for exactly what an exported workspace bundle does and does not contain.)
A container workspace is a workspace that keeps its own separate cookie, login, and storage jar: a private compartment that is walled off from your other workspaces. This is an optional, off- by-default feature.
Normally, all of your non-container workspaces share one common pool of cookies and logins. That is convenient (sign in to a site once and you are signed in everywhere in Ply), but it also means a site can recognize you as the same person across every workspace, because it is reading the same cookies each time. A container changes that. When a workspace is a container, the sites you open inside it store their cookies and logins in that workspace's own jar, separate from everything else. This lets you:
Note: Containers separate where logins and cookies are stored. They do not change Ply's blocking policy. Ad/tracker blocking, fingerprint randomization, HTTPS upgrade, and everything else apply the same way in every workspace, container or not.
Containers are off by default, on purpose: leaving a workspace non-container means your existing logins keep working with no migration. To turn a workspace into a container:
The workspace is marked with a colored ring around its icon so you can always tell at a glance that it is isolated. Sites you assign to a named site container also route into their own dedicated jar, so a given site uses the same compartment everywhere you open it.
Because a container has its own separate login jar:
A container's separate jar exists only while the container is on. If you turn the container off, or delete the workspace entirely, that jar's isolated storage (its cookies, its logins, and the local data sites saved there) is cleared. There is no way to recover it afterward, so treat turning a container off as a sign-out from everything inside it. Caution: Switching a workspace back to non-container does not move its logins into the shared pool. It clears them. If you want to keep being signed in to those sites, sign in again in the shared (non-container) workspace afterward.
Exporting a workspace does not carry the container's cookies or logins. The exported bundle deliberately omits the jar, so if you export a container workspace and import it (on another machine, or as a backup), the imported copy arrives empty: it will not be a container, and none of its sign-ins come with it. This is intentional: a portable file with your live login cookies in it would be a security hazard. If you need to be signed in on the imported copy, sign in again there. See the Import & Export section for the full list of what a workspace bundle includes.
Ply is built for synthesis, and the place where everything you capture lands is Stuff, Ply's capture library. Think of Stuff as your personal scrapbook of what mattered on the pages you visited. Everything you save while reading flows into one searchable place, tied back to the page it came from, ready to be pulled into the Canvas later. Stuff holds four kinds of items:
Each item remembers where it came from. That provenance is what lets you trace a quote or an image back to its source weeks later, and it's what powers backlinks and citations elsewhere in Ply.
A snip captures a rectangle of the current page as an image and files it in Stuff.
The clip is saved as an image item in Stuff, with a title and an optional caption you can fill in. Snips are handy for visual material that doesn't copy cleanly as text: figures, tables, UI screenshots, anything you want to keep as a picture. Note: Snip images are stored as ordinary image files on your device. If you've turned on Ply's password vault (see the Encryption section), those image files are encrypted at rest along with the rest of your synthesis data.
Highlights save a passage of text you've selected, so you keep the exact wording and its source.
The selected text is saved as a highlight in Stuff, attached to that page's address. Highlighting also works in Reader mode. When you've stripped a page down to clean, readable text (see the Reader section), the same selection toolbar lets you save highlights from the decluttered view, and you close reader with Esc.
A note is text you write, pinned to the page you're looking at. Use it for a thought, a summary, a question, or a reminder about why a page matters.
The note is stored in Stuff as a note item, linked to the current page. Notes are the one kind of Stuff item that originates entirely from you rather than from page content. Note: Ply's AI features (when you've enabled your own model, see the AI section) can also save their output to Stuff as notes. Those, plus AI translations, appear under the AI filter tab described below.
A saved link keeps a web address and a title in your library so you can return to it deliberately, rather than digging through history. Links you save show up under the Links filter and can be opened straight from Stuff.
Open Stuff from the Library section of the left rail. The count next to it tells you how many items you've saved. The library view is titled "Stuff" and gives you several ways to narrow things down. Filter tabs sit across the top, each with a live count: Tab Shows All Every captured item Notes Your written notes (and AI-saved notes) AI Items produced by Ply's AI actions, including translations Snippets Snips (image clips) Highlights Saved text passages Links Saved web addresses Extensions Items saved by an installed extension Alongside the tabs you'll find a search box for scanning your library by text, plus filters to limit results to a particular workspace or a date range. Searching looks across the text of your items (note bodies, highlight quotes, captions, titles), so you can find that one passage even if you don't remember which page it was on. Where items came from. Every item displays its source page, so you always know the origin of a clip, quote, or note. If an item was saved by an extension rather than by you, it carries an extension provenance label (shown as ext: followed by the extension's name) so you can tell at a glance that it came from an add-on.
You can revise most items right inside the library without leaving Stuff:
What you can edit depends on the kind: Item Editable fields Snip Title and caption Note The note text Highlight The quote and an optional note about it Link The title Changes save in place. There's also a Select mode that exposes a small action toolbar with To canvas, Scaffold, and Delete, so you can act on several items at once.
Stuff isn't a dead-end archive. It's the raw material for synthesis.
Together, the backlinks panel and Canvas citations close the loop: you capture into Stuff while reading, see your captures resurface when you return to a page, and pull them into a finished document when you're ready to write.
To keep the library fast even after months of heavy use, each kind of store has a generous cap (for example, Stuff holds up to 2,000 items and history up to 5,000 entries). When a store fills, the oldest entries are trimmed to make room. Caution: Saves are designed to fail loudly, never silently. If your device's local storage genuinely runs out of room and Ply can't write a new item even after trimming, it shows a one-time "storage full" notice rather than quietly dropping your capture. If you ever see that message, it means a save didn't stick, so free up space (or clear old items) and try again.
The Canvas is where Ply stops being a browser and starts being a place to think. It is a rich-text editor built into each workspace, meant for turning everything you have collected (snippets, highlights, notes, and links) into a written synthesis: an outline, a draft, a research memo, a reading summary. You open it from the Canvas item in the Library section of the left rail. The Canvas is per-workspace. Every workspace has its own separate document, and when you switch workspaces the Canvas swaps to that workspace's document. Nothing carries over between them, so you can keep a "Job hunt" synthesis completely separate from a "Holiday planning" one without them ever bleeding together. There is no global Canvas: the document always belongs to whichever workspace you are currently in.
The Canvas is arranged in three areas. Down the left is a capture rail holding this workspace's highlights and snips, ready to drag straight into your document. The editor sits in the middle, with a Focus mode that clears everything else away for distraction-free writing and a font picker for choosing the writing typeface. On the right, a Sources and Outline panel keeps track of the document as you write: Sources lists the links and citations it contains, and Outline lists its headings so you can move quickly through a longer piece. Everything you already know still works the same way: existing canvases open unchanged, dragging a capture in still drops it as a citation, and the Markdown and PDF exports are unchanged.
The Canvas is a WYSIWYG block editor: you type, select, and format directly, and what you see on screen is what the document is. It deliberately supports a focused set of formatting, enough to write a clean, structured document, and nothing that would turn it into a sprawling page-layout tool.
| Formatting | What it does |
|---|---|
| Headings (levels 1-3) | Three levels of section headings to structure a document |
| Bold and italic | Standard text emphasis |
| Inline code | Monospaced inline text for snippets of code, commands, or literal values |
| Bullet lists | Unordered lists |
| Numbered lists | Ordered lists |
| Blockquotes | Set-off quoted passages |
| Horizontal rule | A divider line between sections |
| Links | Clickable links, restricted to http and https addresses |
| Snip images | Embedded images of snips you have captured into Stuff |
A few deliberate limits are worth knowing. Headings stop at level 3: there is no heading 4, 5, or 6. Links may only point to ordinary web addresses (http/https); the editor will not accept other kinds of links. And the only images the Canvas embeds are snips, the page captures you have saved into your own Stuff library. You cannot drop in an arbitrary image from the web. This last point is partly a privacy decision, explained at the end of this section.
The Canvas is designed to be fed from the Stuff library. The fastest way to do that is to drag a capture from Stuff and drop it into the Canvas:
The item is inserted at the drop point, formatted as a citation block, so you can build a document by collecting the right captures and arranging them in the order your argument needs. Because the Canvas and Stuff both live inside the same workspace, this is a tight loop: snip or highlight something while reading, then drag it straight into your synthesis. You can of course also just write in the Canvas directly, mixing your own prose around the captures you have pulled in.
Behind the scenes, your Canvas document is saved as Markdown, a plain, widely understood text format. You never have to see or edit the Markdown yourself; the editor handles the conversion in both directions. But the choice matters for a practical reason: because the supported formatting (headings, bold/italic, lists, quotes, rules, links, snip images) maps exactly onto what Markdown can represent, your document round-trips faithfully. What you write is saved as Markdown and reopens looking the same, with nothing quietly lost or mangled in between. This also means a Canvas written in an older version of Ply opens unchanged in a newer one, and that the exports described below are a direct, lossless reflection of what you see on screen rather than a separate rendering that might drift.
When a Canvas document is ready to leave Ply, you can export it two ways:
Both exports are produced entirely on your own machine; exporting a Canvas does not send it anywhere. The Markdown export is the document text; the PDF is a fixed, printable rendering of the same content. Note: Exports reflect the workspace's current Canvas. If you keep separate syntheses in separate workspaces, switch to the right workspace before exporting so you get the document you intend.
The Canvas is part of Ply's own trusted interface (the same privileged surface as the rest of the app's controls) and the captures you drag in often originate from arbitrary web pages. That raises an obvious question: could a captured highlight from a hostile page smuggle something harmful into the editor? In plain terms: no. Captured and pasted content can only ever become the formatting the editor actually supports: the headings, emphasis, lists, quotes, links, and snip images listed above. Anything that looks like active or executable content is not interpreted. It cannot run code, it cannot reach out to the network, and it cannot dress itself up as part of Ply's own controls. Two specifics are worth calling out:
Caution: Treating captured web content as inert text is a safety boundary, not an endorsement of the content itself. A highlight can still quote something misleading, and a validated link can still point to a genuine web page you would not want to visit. Ply stops captured content from doing anything active inside the app; it does not vouch for what the words or destinations actually say.
Ply is built for reading and synthesis, not just browsing. Two features make a long article easier to absorb and easier to keep. Reader mode strips a page down to its text, and highlighting saves a passage you care about into your library so you can find it again later.
Reader mode rebuilds a cluttered article into a clean, single-column reading view: no sidebars, no sticky banners, no auto-playing widgets, just the headline and the text. It's the fastest way to make a noisy page comfortable to read. There is deliberately no Reader button in the toolbar. You launch Reader mode one of three ways:
To leave Reader mode, press Esc (or use the Close reader control in the reader toolbar). Note: Reader mode works entirely from the page you already loaded. It reorganizes the article's existing content right there in your browser and fetches nothing extra from the network: no new requests, no third-party calls. Because it works on a copy of what's already on screen, it never changes or re-downloads the live page. Reader mode works best on article-shaped pages (news stories, blog posts, documentation). On pages that aren't really articles, like a dashboard, a web app, or a search-results page, there may be little for it to clean up, so the result can look sparse. That's expected; press Esc to return to the normal view.
Highlighting lets you save a specific passage of text (a sentence, a quote, a paragraph) straight into your Stuff library, so the words you found valuable don't get lost when you close the tab. To save a highlight:
The highlighted passage is saved into Stuff, Ply's on-device library, as a highlight item. It records the quote, the page it came from, and the date. You can find it later in the Library by opening Stuff and choosing the Highlights filter tab. Right-click any highlight there to edit it: you can adjust the saved quote or add a note of your own to capture why it mattered. Highlights live alongside the other things you collect in Stuff: snippets (a captured image of a page via the Snip button), notes (your own text tied to a page, via the Note button or Cmd/Ctrl+Shift+N), and links. Everything you save stays on your device.
When you return to a page you've saved things from, Ply reminds you. If you've kept any highlights or notes tied to the current page, the toolbar shows a backlinks pill reading something like "N items saved from this page." Click it to see those items again. Your past highlights and notes resurface in context, so revisiting a source brings back the thinking you did there the first time. This is what turns Ply from a place you read into a place you build understanding over time. You don't have to remember which article a quote came from; the quote remembers the article, and the article remembers the quote.
Reader mode and highlighting are the front half of Ply's synthesis workflow; the Canvas is the back half. Each workspace has its own Canvas, a writing space where you pull your collected material together into something coherent. Anything you've saved to Stuff, including your highlights, can be dragged directly into the Canvas, where it's inserted as a properly formatted, cited block. You can also select several items in Stuff (using Select mode) and send them to the Canvas in one step with To canvas or Scaffold. A natural rhythm emerges: read an article in Reader mode to focus, highlight the passages that matter, then later open the Canvas and assemble those highlights into notes, an argument, or a summary, and export the result to Markdown or PDF when you're done. The Canvas section of this handbook covers that side in full.
Ply gives you two distinct kinds of search: the familiar address bar for finding things on the web, and an on-device library search for finding things you've already saved or visited. The two never mix. Web search reaches out to a search engine, while library search runs entirely on your own machine.
The address bar at the top of the content pane doubles as a search box. Its placeholder reads "Search or enter a URL". To search:
If what you type is a web address, Ply navigates straight there instead.
Your default search engine is a setting you control:
This preference stays on your machine and is never sent anywhere except to the search engine you pick, and only when you actually run a search.
Library search looks across the things you have collected in Ply: your browsing history, your Stuff items (notes, snippets, highlights, links), and your per-workspace Canvas documents. It is reached through the AI "spark" button in the toolbar (the button labeled "AI · search tabs, search your library, summarize page"), under the Search library action. Note: The spark button only appears when you've turned on the bring-your-own-AI feature in Settings. The library search itself, however, runs locally and does not call any model unless you explicitly ask it to (see the AI cross-reference below).
Library search never leaves your device. When you search, Ply builds a temporary index in memory out of data you already hold (your history, Stuff, and Canvas), ranks your query against it, and shows you the matches. That index is built fresh each time and lives only in memory. There is deliberately no separate search index file written to disk. That data already lives in Ply's normal storage, and when you've turned on the password vault (see the Encryption section), it is already encrypted at rest there. Writing a second copy as a search index would either duplicate that encrypted data needlessly or, with the vault off, scatter a plaintext copy for no benefit. So Ply does neither, and the index exists only while a search is running.
Library search uses AND matching: an item only matches if it contains every word in your query somewhere, whether in its title, its body text, or its host/URL. This keeps results precise rather than flooding you with loose partial hits. Matches in a title count for more than matches in the body text, which in turn count for more than matches in a host or URL, and a full-phrase title match is ranked highest of all. Ties are broken by recency, so newer items surface first. Each result shows a short snippet of surrounding text so you can see why it matched, along with where it came from (a history page, a note, a highlight, and so on). Note: Opening a result is safe by construction. A result only ever leads to a real web address you already have in your history or saved items, and Ply re-checks that it is a genuine http(s) address before navigating. A search result is never treated as something that could send you somewhere new or run code.
Library search connects to the bring-your-own-AI feature (covered in full in the BYO-AI section), but only on your explicit say-so and in the most limited way possible. After you run a library search, you can select specific results and choose "Ask your model about these." Only then does anything leave your machine, and even then, only the snippets you selected (capped at the top few) are sent, and only to the model endpoint you configured in Settings. The rest of your library never goes anywhere. Caution: Sending snippets to a model is the one moment in library search where data leaves your device. It happens only when you click "Ask your model about these," only for the snippets you picked, and only to your own configured endpoint, whether that's your own local model or an API you pay for. The model is never handed a web address to open on your behalf; you open a result yourself, and Ply still re-checks it is a real web address first. Searching your library is entirely local and private; the AI step is opt-in, minimal, and points only at the endpoint you chose.
Ply ships no AI of its own. There is no built-in model, no default provider, no key, and nothing is enabled until you turn it on. This is deliberate: Ply's whole design keeps your activity on your machine, and an AI assistant that quietly phoned home would break that promise. So instead of bundling a chatbot, Ply gives you a thin, well-guarded pipe to a model you choose, and it only ever uses that pipe when you click an action. When you do enable it, BYO-AI talks to exactly one place: the endpoint you configured. That can be a model running locally on your own machine (for example Ollama or LM Studio), a model on another computer on your home network, or a hosted API you pay for. Ply never picks a provider for you and never sends anything to anyone but the endpoint you typed in yourself.
Everything lives in Settings ▸ AI.
Note: Your API key is stored encrypted on your machine using your operating system's secure credential store. Ply never displays the key back to you after you save it, never includes it in any settings export, and never hands it to the part of Ply that draws the on-screen interface. The only place the key is ever sent is your configured endpoint, as the authentication header that endpoint expects.
Once AI is enabled, a small spark button appears in the toolbar, next to the split-pane toggle. It opens a panel with three actions. Each sends a different, deliberately small slice of information.
| Action | What it does | What gets sent to your model |
|---|---|---|
| Search tabs | Helps you find an open tab by describing it | The titles and URLs of your open tabs, plus your query. The model replies with tab numbers only, and Ply checks each against your real tab list, so it can only point you at a tab you already have. It can never invent a new address or navigate somewhere on its own. |
| Summarize page | Summarizes the page you're reading | The visible text of the current page (capped at roughly 18,000 characters). The reply comes back as plain text. You can hit Save to Stuff to keep it as a note. |
| Search library | Searches your own saved material, then optionally asks your model about the results | The search itself runs entirely on your machine over your history, Stuff, and Canvas. Nothing leaves Ply for this step. Only if you click "Ask your model about these" are the handful of snippets you selected (up to eight) sent on. |
A fourth, related feature is translate selection: select text on a page and ask your model to translate it; the result can be saved to Stuff. Like everything else here, it runs through the same single, guarded path. In every case the model's reply is treated as plain, inert text. It is shown to you escaped (so a model can't smuggle markup or scripts into Ply's interface), and a model can never cause Ply to open a new web address it chose. Links are only opened when you click a real result, and even then the address is re-checked first.
The guarantee Ply makes is narrow and honest: your data goes only to the endpoint you configured, and never anywhere else. Several independent guards enforce that, and they all re-check on every single request, so even hand-editing Ply's settings file can't widen them.
These guards control where your data can go; they make sure it only ever reaches the endpoint you chose. They cannot control what happens after it arrives. When you use Summarize page, Search library's "ask" step, or translate selection, the selected text or page content really does leave your machine and go to whatever model endpoint you configured. So the trust boundary is the endpoint itself. A model running locally on your own computer keeps everything on-device. A hosted API means your selected text is handled under that provider's terms and privacy policy, just like any other service you send data to. Send sensitive pages only to an endpoint you trust accordingly. This is the same reasoning behind Ply's broader threat model (see the security and privacy sections): Ply protects the parts it controls and is upfront about the parts it doesn't.
Plytether is Ply's optional way to keep your own devices in step (your reading history, notes, highlights, links, snips, Canvas documents, and workspaces) without ever sending a byte through someone else's server. It is off by default, and it only does anything while you deliberately start it. It helps to be clear up front about what Plytether is not:
Plytether is a direct connection over your local network, the same Wi-Fi or wired LAN your devices already share at home, between two devices you have paired and verified. When the connection is open, the two copies of Ply talk to each other directly; when you close it, that channel is gone. Note: Plytether is the third (and only LAN-based) situation in which Ply touches the network at all. The other two are bringing your own AI model and the opt-in update check. Everything else in Ply stays on your device. See the security chapter for the full picture.
Before you can pair, a few things need to be true:
You find Plytether on the Devices · sync tab in the left rail (the little stats and gear area near the bottom of the sidebar). It is its own rail tab, not buried in Settings.
That code comparison is the heart of the security model. The number is derived from the secret the two devices just negotiated, so it can only match if you are genuinely talking to each other and nobody is sitting in the middle. An impostor trying to wedge itself between your devices would produce a different code on each side, and the mismatch is your cue to back out. You only need to do this comparison the first time you pair a given pair of devices, and afterward they recognize each other automatically on reconnect.
The Devices · sync tab is laid out as a clean three-column dashboard: the devices you've paired, this device and its pairing controls, and the offline workspace export/import. Each paired device shows what kind of machine it is, a Mac, a Windows PC, or an iPhone, with a matching icon and name, so it's easy to tell at a glance which device is which. You can also give this device a friendly name, in the same tab, that the others will display (leave it blank to use the computer's own hostname). A device only announces its name and type after you've paired and the encrypted channel is established, never during the open pairing handshake, so this convenience never leaks a name or device type to anything scanning your network. Both devices need to be on a recent enough version to show each other's type; an older one simply appears as a generic "Device."
Plytether splits your data into two groups and treats them very differently, because some things are safe to combine automatically and some are not. Append-only items merge automatically. Your history, notes, highlights, and links are things that only ever get added, never edited in place in a way that conflicts. So Ply simply combines both devices' copies, matching on content so you never get duplicates. After a sync, each device has the union of both. Bigger or changeable items go to a sync Inbox instead. Three kinds of data are riskier to merge blindly, because overwriting could lose work you care about:
| Item | Why it's handled carefully |
|---|---|
| Snip images | They are full pictures, and you may have edited captions or titles differently on each device. |
| Canvas documents | A Canvas is a living synthesis document; silently replacing yours could erase edits. |
| Workspace structure | Names, icons, colors, and preferences of a workspace can diverge between devices. |
Rather than overwrite anything, Ply routes these to a sync Inbox for keep-both review. A Canvas or workspace that has diverged on the other device arrives as a copy you can accept, so your local version is never silently replaced. Nothing in this group changes on your machine until you say so. Note: Workspace cookie jars and the pages currently open in a container workspace never travel over sync, only the workspace's structure (name, icon, color, preferences). This mirrors how Ply's offline workspace export behaves, so an imported or synced container is never a logged-in session masquerading as yours.
If you use Ply's password manager, a saved login can travel to a paired device too, the same way your history and notes do, over the same direct, encrypted LAN connection and never through a server. This is a separate opt-in, off by default: turn it on with the credential-sync switch on the Devices · sync tab (it's available only once both the data vault and the password manager are on). Because a password is the most sensitive thing Ply holds, it gets extra care on the wire. The login's details (which site, your username) ride along with the rest of the sync data, but the password itself is sealed end-to-end between the two devices' secure cores and never passes through Ply's ordinary interface layer in readable form, not even on the receiving device. A login that arrives is added alongside the ones you already have; a copy you already hold is left untouched rather than duplicated. See the password-manager section for what the manager stores and how filling works.
The Inbox lives in the Library section of the left rail, with a count badge when items are waiting. It is where you review and accept everything Plytether routes for triage. When you open it you'll find each pulled item presented for a decision: accept it (adding it alongside what you already have) or leave it. Because the policy is keep-both, accepting a diverged Canvas or workspace gives you a copy, so you can compare the two and merge by hand if you like. Each sync also drops a short per-pull summary into the Inbox: which device you synced with, when it happened, and how many items of each kind came across. Over time this becomes a simple, readable history of your syncs. Note: An untriaged snip waiting in the Inbox is protected from Ply's normal housekeeping. It won't be swept away as an orphan before you've had a chance to keep or discard it.
The Inbox is laid out in three columns: your paired devices on the left, what the selected device sent over in the middle, and the workspaces it pulled in on the right. Synced items and pull notices clear themselves automatically after two weeks. You can change that interval in settings, or set the Inbox to keep everything until you have triaged it yourself.
Plytether also lets you send a single page to a paired device rather than syncing everything. The page arrives in that device's Inbox, where you can open or keep it. This is handy for "read this on my other machine" hand-offs, and it travels over the same direct, encrypted LAN connection, never through any outside service.
Caution: Like the rest of Ply, Plytether protects data in transit and at rest. It does not protect a device that's already unlocked and in someone else's hands. Pair it with full-disk encryption and the password vault (see the encryption chapter) for the strongest posture, and only pair devices you actually control.
Ply keeps everything on your device, but "on your device" and "encrypted" are not the same thing. By default, the work you build up in Ply (your workspaces, browsing history, saved Stuff, your Canvas documents, notes, links, layout, and your snip images) lives in ordinary on-disk files in your user data folder. If someone gets hold of the drive, they can read that data. The data vault closes that gap. It is an optional, off-by-default feature that encrypts all of your Ply synthesis data at rest with a password only you know. When the vault is on, that data is sealed into an encrypted file on disk, and Ply can only open it once you've typed your password (or unlocked it through your system keychain, more on that below). The vault is off until you turn it on. Ply ships with no password, no key, and nothing encrypted. Nothing about encryption changes how the rest of the app behaves until you choose to enable it.
When you enable the vault, the following data is encrypted at rest:
That's the synthesis work that makes Ply Ply. Your interface preferences (theme, accent, density) and the small set of app behavior settings are not part of the vault, since they hold nothing sensitive.
You manage the vault from Settings ▸ Encryption.
From that point on, your data only exists in encrypted form on disk while Ply is closed. Caution: Choose your password carefully and write it down somewhere safe (a password manager is ideal). If you forget it and have not set up keychain auto-unlock, your encrypted data cannot be recovered, not by you, and not by anyone, including us. This is a deliberate part of how the encryption works, not a missing feature. See "If you forget your password" below.
Once the vault is enabled, Ply needs your password to open your data. The next time you start Ply, before the main interface loads, you'll see an unlock screen:
To guard against someone trying to guess the password by brute force, unlock attempts are deliberately rate-limited, and only one unlock attempt runs at a time. Combined with the deliberately slow key step (described below), this makes rapid guessing impractical.
You can change the vault password at any time from Settings ▸ Encryption. You'll be asked for your current password and a new one. Ply re-seals your data under the new password. Your data is never decrypted to disk during the change: the working copy stays in memory, exactly as it is while the app is running normally.
Retyping a strong password at every launch gets tedious. Ply offers an optional system keychain auto-unlock: it stores the vault's key in your operating system's secure keychain (Keychain on macOS, Credential Manager / DPAPI on Windows). When this is on, Ply asks the OS keychain for the key on launch and unlocks the vault without prompting you for the password. A few honest notes about this convenience:
You can turn keychain auto-unlock on or off at any time in Settings ▸ Encryption. Even with it on, your password still works at the unlock screen.
If your computer has a fingerprint or face sensor, you can unlock the vault with Touch ID on a Mac or Windows Hello on a PC instead of typing your password every launch. Choose it under Settings ▸ Encryption, where the unlock method is a simple choice between require my password each time, unlock automatically (system keychain), and unlock with Touch ID / Windows Hello. When biometric unlock is on, the lock screen prompts you for your fingerprint, face, or device PIN as Ply starts, and opens once it's satisfied. Your typed password always remains available as a fallback, so a missing or unrecognised sensor never locks you out. A plain, honest description of what this does: biometric unlock is a presence check layered on the keychain escrow above, not a second, separate lock on your data. The vault key is still held in your operating system's keychain; the Touch ID / Windows Hello prompt simply gates Ply's use of it on you being physically there. It protects against a casual person at your unlocked machine reaching for Ply, but, like keychain auto-unlock, it is not a defense against someone who can already fully use your logged-in account. If that's your threat model, keep using the password and leave biometric unlock off. Because the vault is genuinely encrypted, a forgotten password with no keychain escrow means the data is mathematically unrecoverable. Ply gives you one escape hatch: a "start fresh" option on the unlock screen. "Start fresh" discards the encrypted vault and lets you begin again with empty data. It is confirmation-gated so you can't trigger it by accident. Use it only when you've accepted that the encrypted data is gone. It does not decrypt anything; it throws the locked data away so you can keep using Ply. Caution: "Start fresh" permanently destroys the encrypted contents: your workspaces, history, Stuff, Canvas, and snips. It exists so a forgotten password doesn't lock you out of the app forever, not as a recovery tool. There is no way to get the old data back afterward.
You don't need to understand cryptography to trust the vault, but here's what's happening underneath, described plainly. When you set a password, Ply runs it through a deliberately slow key-derivation step (a function called scrypt, tuned to take a noticeable fraction of a second and a large chunk of memory). This slowness is the point: it's fast enough that you barely notice it once per unlock, but it makes guessing millions of candidate passwords per second (the way an attacker would) extremely expensive. The derived key is then used to seal your data with AES-256 authenticated encryption, a strong, standard cipher. "Authenticated" means every sealed blob carries a built-in integrity check: if even a single byte of the encrypted file is altered, or if the password is wrong, decryption fails outright rather than handing back scrambled or partial data. You either get your real data, or you get a clear error, never a corrupted in-between. Two more details worth knowing:
This is the most important part of this section. The vault is real protection, but only against a specific threat, and you should know exactly what it does and doesn't do. What the vault protects: a powered-off or stolen drive. If someone steals your laptop while Ply is closed (or the machine is off), your synthesis data is encrypted and they cannot read it without your password. This is the classic "lost laptop" scenario, and the vault handles it well. What the vault does NOT protect: a running, unlocked machine. While Ply is open and unlocked, your data is decrypted in memory so the app can actually use it, which is unavoidable. Anyone sitting at your unlocked computer, or any malware already running under your account, can see that data just as you can. The vault is not a defense against someone using your live session. Caution: Pair the vault with full-disk encryption (FileVault on macOS, BitLocker on Windows). The underlying browser engine writes its own working files to disk as you browse, and once those blocks are freed, Ply cannot reliably scrub them, because the operating system controls that storage. Full-disk encryption covers those leftover traces; the Ply vault alone does not. Used together, the vault protects your synthesis data specifically, and full-disk encryption protects everything the engine left behind.
A reasonable worry with any encrypted store is what happens if the power cuts out, or the app is force-quit, in the middle of saving. Could the vault be left half-written and unreadable? Ply is built to make that safe. When it saves the vault, it writes the new encrypted data to a temporary file, flushes it fully to the physical disk, and keeps the previous good copy as a backup until the new one is safely in place, then swaps them atomically. If a crash or power loss interrupts a save, Ply detects the torn write on the next launch and promotes the intact backup, so you come back to your last consistent state rather than a corrupted file. You may lose the very last unsaved change in a hard crash, but you won't lose the vault.
Ply has a built-in password manager so you can save your website logins and have Ply fill them in for you, without reaching for a separate app or a browser sync service. Like everything else in Ply, your passwords stay on your device. The manager rides the data vault: it is built directly on top of the encryption described in the previous section, and it is only available once the vault is on. That's a deliberate design choice, not a limitation: your passwords are the most sensitive thing Ply could hold, so they live only inside the same encrypted store as the rest of your synthesis data, sealed with your vault key. It is off by default, on top of the vault also being off by default.
While the vault is locked, the manager is locked too: your logins are unavailable until you unlock Ply, exactly like the rest of your encrypted data.
There are two ways to save a login:
On a site you have a saved login for, a key button appears in the toolbar. Click it and Ply fills your username and password into the sign-in form. Two safety rules govern filling, and they're worth knowing:
As your list of logins grows, the manager keeps it easy to scan. Categories and favorites run down the side, so you can group related logins and keep the ones you reach for most within easy reach, and every entry shows the site's real favicon. That same favicon appears in the in-page fill popover, so you can recognize the right login at a glance when Ply offers to fill one.
When you're creating an account or changing a password, Ply can generate a strong one for you, either a random password or a memorable passphrase, with options for length and character mix. The generator uses proper cryptographic randomness, so the results aren't guessable patterns.
Ply also includes a standalone generator you can open on its own. Use it to produce a strong random password, a memorable passphrase, or a numeric PIN, with a live strength readout as you adjust the length and options, then copy the result straight to the clipboard.
A saved login can also hold a two-factor (2FA) authentication code of the time-based kind (TOTP, the rolling six-digit codes apps like Google Authenticator produce). Add the secret once, and Ply keeps the current code ready alongside the login. Ply only ever shows you the six-digit code of the moment and how long it's valid; the underlying 2FA secret stays sealed in the store and is never displayed back to you.
When you copy a password to the clipboard, Ply clears it automatically after about 25 seconds, so a password you copied doesn't sit on the clipboard indefinitely for the next app (or the next person) to read.
You don't have to start from scratch. Ply can import logins from a CSV file exported by another browser or password manager, including Chrome, Firefox, Safari, Bitwarden, 1Password, and LastPass, recognising the common export formats automatically. The import reads the file directly into the encrypted store; the cleartext passwords in that CSV never pass through Ply's ordinary interface layer. Caution: A CSV exported from another manager holds your passwords in plain text. Import it, then delete the CSV file and empty your trash, it is the one moment your passwords sit unencrypted on disk.
Because your passwords ride the vault, turning the vault off deletes them along with the rest of your encrypted data, there is no separate plaintext copy by design. So keep a backup: the Passwords view can export a password-protected .plypass file that you can restore later, or carry to another machine. The backup is itself encrypted with a password you choose, so it's safe to store like any other sensitive file.
Note: An independent red-team security review of the password manager and the vault was carried out before release; the issues it found were fixed. See the version notes and the Threat Model section for the broader picture.
Ply supports small add-ons that extend what the browser can do, for example a tool that saves the current page somewhere, or one that helps you search your own browsing history. Extensions are deliberately kept simple, sandboxed, and on a tight leash, in keeping with Ply's promise that your data stays on your machine. Note: Ply does not ship with any third-party extensions, and there is no in-app store to browse or download them from. Every extension you run is one you chose to install from a folder on your own computer. If you've never installed one, you have none.
An extension in Ply is just a folder of files with a small description file inside it (its "manifest"). The manifest names the extension, gives it a version, lists which capabilities it wants, and points at the small window ("popup") it shows when you click it. Because an extension is a plain folder, installing one means pointing Ply at that folder and letting it make its own private copy.
During the copy, Ply guards against a few tricks: it refuses files that try to point outside the extension's own folder (so an extension can't smuggle in a copy of, say, your private keys), enforces limits on file count, size, and folder depth, and only accepts a whitelist of ordinary file types. If the manifest is missing required information (for instance, it has no name) the install is rejected outright rather than half-completed.
Every extension runs in its own isolated sandbox, separate from your normal browsing and from every other extension. The single most important rule is this: by default, an extension cannot send anything out to the network. All ordinary web and socket connections from inside an extension are blocked. It can read files only inside its own folder, nothing else on disk. That blocked-network default is exactly what makes it safe to let an extension read on-device data. An extension can be granted permission to look at things you already have locally (your current page, your history, your saved Stuff) but because it has no way to reach the internet, it cannot quietly ship that data off to a server somewhere. It can read, and it can act inside Ply, but it cannot phone home. The extension's popup window is hardened too: it can't open new browser windows, can't navigate away from its own files, and runs with the same locked-down settings as the rest of Ply's interface.
Beyond reading its own files, an extension can ask for specific capabilities. Each one must be declared in the manifest, and Ply enforces the declaration: an extension can't use a capability it didn't ask for.
| Capability | What it lets the extension do |
|---|---|
| Open a URL | Open a page as a new tab in Ply |
| Read the current page | See the URL and details of the page you're looking at |
| Save to Stuff | Add an item (such as a note) to your Stuff library |
| Search history | Look through your browsing history |
These come with guardrails so a capability can't be turned into a data leak. The most important one applies to opening URLs: an extension that holds any read permission may only open a page that is already in your history. It can re-open somewhere you've actually been, but it can't be used to open a brand-new, crafted address, which is the trick a malicious add-on would otherwise use to smuggle your data out inside a web address. Saving to Stuff and reading the current page are likewise confined to acting inside Ply, never reaching outward.
Some extensions legitimately need the internet, and Ply allows that, but only on your terms and only to destinations you can see. An extension that wants network access must declare a network permission and list the exact hostnames it intends to talk to. The list can't be empty or vague: if an extension asks for network access without naming specific hosts, Ply rejects the whole manifest and won't install it. Once installed, the sandbox allows connections only to those named hosts (and their subdomains) and continues to block everything else, including any attempt to redirect a request to a different host. Crucially, this allowlist is shown to you. In the Extensions manager, each extension's declared network domains are listed alongside it, so you can always audit exactly where a given add-on is permitted to connect. An extension with no network permission shows none, and reaches nothing.
The Extensions manager (in Stuff ▸ Extensions) shows everything you've installed: each extension's name and the network domains it has been allowed to reach, if any. From there you can remove any extension you no longer want. Uninstalling is thorough. When you remove an extension, Ply tears down all of its state at once: its registration, the private copy of its folder, any storage its sandbox accumulated, its open popup window, and its internal rate-limiting records. Nothing of the extension is left behind to act later.
These guardrails are real and they're strict: the blocked-by-default network, the history-only URL rule, the visible domain allowlist, the per-extension sandbox. They sharply limit what a misbehaving extension can do, and in particular they make it very hard for one to exfiltrate your data. Caution: Even so, an extension is code running inside your browser. The sandbox limits where its data can go, but a granted read permission still lets it see the data you allowed. Install only extensions whose source you trust, review the permissions and network domains shown to you at install time, and uninstall anything you don't actively use. The safest extension is the one you didn't install.
Ply lets you save a whole workspace to a single portable file and open it again on another copy of Ply. That's handy for moving a research setup to a new machine, keeping a backup, or handing a starting point to someone else. This section explains exactly what travels in that file, what deliberately stays behind, and Ply's broader stance on sharing.
A workspace export captures the shape of your workspace (its pages and how they're arranged, plus its name, icon, and color) as one file you can store or move anywhere.
That file is self-contained. It doesn't depend on anything left behind in your profile, so you can copy it to a USB stick, drop it in a folder, or keep several around as snapshots of different projects.
The import always lands as a new workspace. It never silently overwrites one you already have, so importing twice just gives you two copies.
This is the important part, because it's where Ply's privacy posture shows up. Included in an export Deliberately excluded The workspace's pages and their structure Cookies, logins, and any signed-in session The workspace name, icon, and color The workspace's isolated container jar (if it had one) Cosmetic preferences that travel with the Your global privacy & security settings workspace Any ability to switch on AI or auto-updates A few of these are worth spelling out:
Note: Because logins and the container jar don't travel, importing a workspace is safe to do with files from other people. The worst case is that you get a layout you then have to log into yourself. It is never a way for an imported file to quietly flip your protections off or sign you into something.
Ply is built so that everything stays on-device: no telemetry, no background cloud sync, and no third-party connections except for the few you turn on yourself. Sharing follows the same rule. There is no server-hosted share link. Ply will not, and is not designed to, upload your workspace to a service and hand you a URL that anyone can open. There is likewise no background cloud sync quietly copying your data somewhere while you work. If Ply ever adds a dedicated "share a reading list or workspace" feature, it will take the same form as today's export: an offline, password-encrypted file that you send out-of-band yourself, by whatever channel you already trust, such as a USB drive, your own file transfer, or an encrypted message. You hold the password; the recipient needs it to open the file. It would never become a hosted link or an account-based share. That direction is settled, not a placeholder. This is a deliberate trade-off. You don't get one-click "share to the web" convenience. In return, your synthesis work never sits on someone else's server, and there's no share URL that could leak, get indexed, or outlive your intent.
Exporting and importing is the right tool for snapshots, backups, and handing a layout to another person. If instead you want your own devices to stay in step (your history, saved Stuff, snips, Canvas documents, and workspaces flowing between, say, your laptop and your desktop) use device sync instead. See the device sync section of this handbook. Device sync is also on-device by design: it's an opt-in, direct connection between your own paired devices over your local network, confirmed with a short pairing code, and it is off until you turn it on. It is not a server and not a background daemon. It's the intended path for keeping your machines aligned, while export/import is the path for portable, one-shot files.
Export and sync both concern data in motion or in a file you carry. To protect Ply's data sitting on your disk (the workspaces, history, Stuff, snips, and Canvas stored on the machine itself) use the password vault (Settings ▸ Encryption). See the vault section for what it does and, just as importantly, the honest limits of what at-rest encryption can and can't protect. The vault and exporting are independent: a workspace file you export is its own object, separate from whether your on-disk profile is currently locked.
Ply keeps you in control of when it talks to an update server. By default it never checks for updates on its own, never downloads anything in the background, and never installs anything without you clicking to do so. This section explains how the update system works, how to check manually, how to roll back to an older version, and how Ply makes sure every build it runs is genuine.
Automatic update checks are opt-in and off by default. Until you turn them on, Ply makes no contact with any update server at all, so there's no update-feed traffic. This is deliberate: an idle browser that quietly phones home for version checks is exactly the kind of background connection Ply is built to avoid. If you'd like Ply to look for new versions when it starts, you can enable automatic checks in Settings ▸ About ▸ Updates. With that turned on, Ply checks the update feed once shortly after launch. Even then, it only checks; finding an update does not start a download. A manual Check for updates button in the same Updates area always works, regardless of the automatic setting. If you prefer to keep automatic checks off and just look whenever you feel like it, that's fully supported. The manual check is the only network contact that happens, and only at the moment you press the button. Note: Automatic and manual update checks, downloads, and installs are available on macOS and Windows.
Ply never silently downloads or installs an update. The process is broken into explicit steps, and each one waits for you:
At no point does Ply auto-download a build in the background or auto-install one when you quit. Nothing moves forward without a click from you.
Sometimes a new release doesn't suit you and you'd rather go back. Ply supports rolling back to an older version on macOS and Windows, from Settings ▸ About ▸ Updates. The Updates area lists older builds you can return to. Ply is careful about what a rollback is allowed to do:
Revert is a separate, deliberate action. It's not something the automatic update flow can trigger on its own. Note: Rolling back is available on macOS and Windows.
When you update to a newer version, or roll back to an older one, Ply verifies the build before it runs. This is the safeguard that protects you against a tampered or substituted installer, such as a file that was modified in transit or swapped out by malware on your machine. The check confirms two things about every downloaded build:
If either check fails, whether the signature is broken, missing, or belongs to someone else, Ply refuses to run the build and does not install it. A modified or impersonated installer is rejected rather than launched. This applies equally to forward updates and to rollbacks, so there is no "trusted" path that skips verification. Caution: These checks confirm that a build is an authentic, unmodified Ply release. They protect you from tampered or fake installers. They can't protect you from deciding to install a version you don't like; for that, the revert flow above is your friend.
Everything described here lives in one place: Settings ▸ About ▸ Updates. There you'll find:
The About screen also shows your current Ply version alongside the underlying Electron, Chromium, and Node versions, plus filter-list freshness, which are handy details if you ever need to report an issue. After you update and relaunch, Ply shows a What's New dialog the first time you start the new version. It lists every change since the version you were last running, so if you skip a few releases, you'll see a combined summary rather than just the latest entry. (On a brand-new install with no prior version, it stays quiet.) You can reopen What's New any time from Settings ▸ About ▸ "What's New", and replay the welcome tour from the same area or the Help menu.
This section walks through Ply's Settings screen one category at a time, so you can see what each control does and what it's set to out of the box. Open Settings from the gear in the bottom of the left rail, or press Cmd/Ctrl+,. The categories down the left of the Settings screen are: General, Appearance, Behavior, Privacy & Security, AI, Encryption, Passwords, Shortcuts, and About. (Two related things live elsewhere: Devices · sync is its own rail tab, not a Settings category, and is covered at the end of this section.) Where a setting affects how Ply protects you, you'll find a pointer to the relevant chapter in Part II rather than a full re-explanation here.
General covers how Ply behaves when you search, open a new page, and start up.
| Setting | What it does | Default |
|---|---|---|
| Default search engine | The engine used when you type a search term (instead of a URL) into the address bar. | Your chosen engine |
| New page URL | The page that opens when you create a new tab. | Ply's start page |
| On startup | Whether Ply reopens your previous session or starts fresh. | (varies) |
| Confirm before closing N tabs | Asks for confirmation before quitting when you have at least this many tabs open. | 2 (minimum 2) |
| Default browser | A Set as default button that registers Ply as your system's web browser. | Not set |
Note: Set as default only works in installed (packaged) builds. In a development build it deliberately refuses, so a throwaway copy never grabs your system's web handler. On Windows, clicking it opens the OS Default-apps screen and the checkmark appears only once Windows actually reports Ply as default.
| Setting | What it does | Options / Default |
|---|---|---|
| Theme | Light, dark, or follow the system. | Light / Dark / Auto |
| Accent | The highlight color used across Ply's interface. | Ply orange (default) / Warm orange / Amber / Moss / Slate / Plum |
| Density | How tightly rows and controls are packed. | (varies) |
| The default accent is Ply orange | (a warm clay tone). | The accent also tints small touches like |
the secure-connection lock and the "Private by default" shield in the rail.
Behavior controls page lifecycle and download prompts.
| Setting | What it does | Default |
|---|---|---|
| Auto-freeze idle pages | Puts a background tab to sleep after it has been untouched for this many minutes, freeing memory. The active tab in each workspace and any pinned tabs are never frozen. | 10 minutes (range 1-120) |
| Default zoom | The starting zoom level for new pages. | (varies) |
| Ask where to save downloads | Prompts for a folder each time instead of saving automatically. | Off |
Frozen pages reload when you return to them. Ply also keeps only a limited number of background tabs fully "awake" at once; beyond that, the oldest idle tabs sleep automatically. See Part II for how the keep-alive and freezing work together.
This is the largest category. Each toggle here switches a protection on or off globally; you can also make per-site exceptions directly from the privacy panel that opens when you click the shield in the address bar. Full explanations of every mechanism are in Part II. This table is the quick reference.
| Toggle | What it does | Default |
|---|---|---|
| Block ads & trackers | Blocks known ad and tracking requests, and hides ad/tracker page elements (cosmetic element-hiding). | On |
| Block 3rd-party cookies | Strips cookies on cross-site requests; your first-party logins are untouched. | On |
| Randomise fingerprinting | Adds per-site noise to canvas/audio/WebGL readings and presents a plain Chrome identity instead of Ply's. | On |
| Strict mode (uniform en-US) | Layers on a uniform US- English language profile so | Off |
| Toggle | What it does strict users blend together rather than each leaking their own locale. | Default |
| Block 3rd-party scripts | Blocks JavaScript loaded from other sites. Effective, but breaks many pages, so it's left off on purpose. | Off |
| Block manipulative patterns | Defuses dark patterns: dims guilt-trip "no thanks" buttons (still clickable), greys out fake countdown timers, and flags pre-checked opt-in boxes. | On |
| Prevent WebRTC leak | Stops video-call technology from revealing your local network address. | On |
| HTTPS upgrade | Upgrades insecure http:// page loads to https:// where possible. | On |
| Strip AMP | Rewrites AMP wrapper links to the original page. | On |
| Skip link-tracking redirects | Sends you straight to the destination instead of through a click-tracking hop. | On |
| Strip tracking parameters | Removes tracking tags (like campaign IDs) from URLs. | On |
| Block web fonts | Blocks remotely loaded fonts (a minor fingerprinting and beacon vector). | Off |
| Trim cross-site referrers | Reduces how much of the page you came from is shared with the next site. | Off |
| Clear history/downloads on quit | Wipes the chosen records each time you quit Ply. | Off |
Each blocker that defends against trackers, fingerprinting, scripts, manipulation, and cookies has its own per-site exception list: when something on a site breaks, open the shield panel and use the "Allow … on this site" toggle on that row. The exception applies only to that site and leaves your global setting alone. This category also contains a Containers manager, where you create and name isolated cookie/storage jars and assign workspaces to them. Container basics are covered in Part II. Caution: These protections raise the cost of tracking and profiling; they are not invisibility. Ply is honest about its limits: for example, fingerprint randomisation reduces, but cannot fully eliminate, what a determined site can infer. Read the Part II privacy chapters for the specific guarantees and caveats.
Encrypted DNS (DoH) is off by default, in which case Ply uses your system's DNS like any other app. Turn it on to send your DNS lookups through your own encrypted DNS-over-HTTPS resolver instead, so the network you're on and your internet provider can't see which sites you visit. Automatic encrypts your lookups but quietly falls back to ordinary DNS if the resolver is unreachable; Strict only ever uses the resolver, which is more private but means pages won't load if it's down (as can happen on some captive Wi-Fi).
Resolver URL is the https address of the resolver you trust. Ply offers a few well-known privacy resolvers as one-click presets (Quad9, Cloudflare, Mullvad) but never bundles a default or picks one for you, and a Test resolver button lets you confirm it works before you rely on it. Like the other privacy controls, this setting is left out of workspace exports, so importing someone else's workspace can never repoint your DNS.
Ply ships no AI of its own: no bundled model, no default provider, no key. The AI category lets you connect your own model, and it is off by default. When enabled, Ply talks only to the endpoint you configure, and only when you click an AI action.
| Setting | What it does | Default |
|---|---|---|
| Enable AI | Master switch for the AI features. | Off |
| Provider | OpenAI-compatible, Anthropic, or Google Gemini. | OpenAI-compatible |
| Endpoint | The model server's address (e.g. your local Ollama/LM Studio box, or a hosted API). | Empty |
| Model | The model name to request. | Empty |
| API key | Stored separately and encrypted; it is never shown back to you or to the rest of the app. | Not set |
| Test | Checks that your endpoint and key work. | (action) |
Note: Ply will only send your data over plain http:// to a clearly local or private address (such as a machine on your own network). Anything on the open internet must use https://, so your key and page text are never sent in the clear. See the BYO-AI chapter in Part II for what each AI action sends and how it's contained.
The Encryption category is Ply's password vault for the data it stores on disk: your workspaces, history, Stuff, Canvas, notes, links, and download records. It is off by default. From here you can enable the vault with a password, change that password, choose how it unlocks (require the password each time, unlock automatically with the system keychain, or unlock with Touch ID / Windows Hello), or reset the vault. Reset is the escape hatch if you forget your password, but it erases the encrypted data, because without the password it cannot be recovered. Caution: The vault protects a powered-off or stolen drive. It does not protect a running, unlocked machine, and it cannot scrub data your operating system already wrote elsewhere, so pair it with full-disk encryption (FileVault/BitLocker). The full threat model and recovery details are in the Encryption chapter of Part II.
The Passwords category is Ply's built-in password manager, and it is off by default. It rides the data vault, so it's only available once Encryption is on; the switch here enables the manager itself. The Passwords view (in the Library) is where you add, edit, generate, import, and back up logins. Full coverage, including how filling and two-factor codes work, is in the Password Manager chapter. Note: Because your passwords ride the vault, turning the vault off deletes them. Export a password-protected .plypass backup first if you might turn encryption off.
The Shortcuts category lets you remap keyboard shortcuts. Each action shows its current key combination; click it, press the new combination to record it, and Ply updates both the shortcut and its menu entry to match. A reset button restores the defaults. A handful of shortcuts are fixed and cannot be remapped (jumping to pages 1-9, and Esc to dismiss overlays or close Find). The complete default shortcut list lives in the Keyboard Shortcuts section of this handbook.
About is the status-and-maintenance screen.
Sync is not a Settings category. It's the Devices · sync tab in the left rail, a three-column panel for pairing this device with another of your own devices over your local network and syncing your data directly between them (no server in the middle). It is off until you start a pairing, uses a 6-digit code you confirm matches on both devices, and works only across your local network. Each paired device shows its type (Mac, Windows PC, or iPhone) and a name, and you can name this device here too. An optional, separate switch lets you also sync your saved logins (it appears once both the vault and the password manager are on). The full walkthrough, including what syncs and how conflicts are handled, is in the Sync chapter of Part II.
Ply ships with a set of keyboard shortcuts for everything you do most often: opening and closing pages, moving through your history, capturing snips and highlights, switching layouts, and finding text. You can use the defaults as-is or remap most of them to suit your fingers.
The table below lists every default shortcut. CmdOrCtrl means Cmd on macOS and Ctrl on Windows, so wherever you see CmdOrCtrl+T, press Cmd+T on a Mac and Ctrl+T on a PC.
| Action | Default shortcut |
|---|---|
| Command bar | CmdOrCtrl+K |
| Focus address bar | CmdOrCtrl+L |
| Quick switcher | CmdOrCtrl+E |
| New page | CmdOrCtrl+T |
| Close current page | CmdOrCtrl+W |
| Reopen closed page | CmdOrCtrl+Shift+T |
| Find in page | CmdOrCtrl+F |
| Highlight selection to Stuff | CmdOrCtrl+Shift+H |
| Reader mode | CmdOrCtrl+Shift+R |
| Reload page | CmdOrCtrl+R |
| Note on this page | CmdOrCtrl+Shift+N |
| Open settings | CmdOrCtrl+, |
A few shortcuts are fixed and cannot be remapped:
| Action | Shortcut |
|---|---|
| Jump to page 1-9 | CmdOrCtrl+1 through CmdOrCtrl+9 |
| Dismiss an overlay / close Find | Esc |
Note: A couple of these shortcuts are the only way to reach certain features. There's no Reader- mode or Highlight button in the toolbar, so CmdOrCtrl+Shift+R (or the right-click menu) is how you enter reader mode, and CmdOrCtrl+Shift+H (or the selection toolbar) is how you save a highlight. Snipping a page has its own toolbar button, and you can also right-click a page for many of the same actions.
Most shortcuts (everything in the first table) are fully customizable:
When you remap a shortcut, the app's menu bar updates to match. The shortcut shown next to a menu item always reflects your current binding, so the menu and your custom keys never drift apart. If you assign a combination that Ply can't represent in a menu, it won't accept it. That keeps your menus working no matter what you record. Note: The fixed shortcuts in the second table (the page-number jumps and Esc) are not shown in the Shortcuts editor and can't be changed. Caution: Your remapped shortcuts are part of Ply's own settings and are never carried into a workspace you import or export. Importing a workspace from someone else can't silently change your keyboard shortcuts.
This is where Part II begins. The chapters that follow get into the specifics (the blockers, fingerprinting defenses, containers, the data vault, and more), but they all rest on one idea, so it is worth stating plainly before anything else.
Ply is built so that your browsing, your notes, your snips, your highlights, your Canvas documents, and your settings live only on your computer. Ply does not run analytics. It does not send usage statistics, crash reports, or "anonymous" telemetry anywhere. It has no account to sign into, no cloud to sync to by default, and no background service phoning home while you sleep. This also shapes how Ply is built, not just how it behaves. Many apps pull pieces of themselves from the internet as they run: fonts from a font service, scripts from a content-delivery network, components fetched on demand. Ply deliberately does none of that. Everything Ply needs to run is packaged inside the app when you install it. Fonts, the ad-and-tracker filter lists, the reader- mode engine, the interface code itself, all of it ships with the download and is loaded from your own disk. Nothing is fetched from a remote server at runtime, and no remote code is ever downloaded and executed. If a feature would require reaching out to some third party to work, that feature is either built to work offline or it is not added. The practical upshot: under normal use, the only computer Ply talks to is the one the website you are visiting lives on, exactly the connection you asked for by typing an address or clicking a link. Ply itself adds no extra conversations on the side. Note: "On-device" is about Ply's own behavior. The websites you choose to visit are still ordinary websites. They can still try to track you, and that is what the privacy blockers in the next chapters are for. Ply's promise is that Ply doesn't add surveillance of its own and doesn't leak your data to anyone you didn't choose to contact.
There are exactly four situations in which Ply will make a network connection beyond loading the pages you visit. Each one is off by default, each one is something you turn on, and each one only happens when you take an explicit action. This is the complete list, and there is nothing else. # Feature When it talks to the network What it talks to 1 Bring-your-Only when you click an AI action (search tabs, Only the model endpoint own AI search your library, summarize, translate) you configured in Settings: your own local model, or an API you chose to pay for # Feature When it talks to the network What it talks to 2 Opt-in auto-Only if you turned auto-update on, and only Only Ply's own update feed update when you click to check, download, or install 3 LAN-only Only when you start a pairing or sync from the Only your own paired device sync Devices · sync tab devices, directly, over your ("Plytether") local network A few things worth underlining about each:
That is the entire list, and it's a standing commitment rather than just a current snapshot. Adding a fifth kind of network connection (any wider sync, any relay through an outside server, any hosted share link) is not something that can quietly slip into a future version. Any such feature has to pass its own written security review before it could ship, the same gate the LAN sync and encrypted-DNS features went through. The "four exceptions, all yours, all opt-in" rule is a designed boundary, not an accident of the current release.
Promises are good; enforcement is better. Ply doesn't merely intend to stay on-device. Its own interface is actively prevented from reaching the network at all, except to talk to itself locally on your machine. Here is what that means in plain terms. Ply's interface (the menus, the rail, the settings screens, everything that isn't a web page you opened) is wrapped in a rule that blocks every outbound connection it might try to make, with a single exception: connections back to Ply running on your own computer. So if some future feature, a bug, or a mistake ever caused the interface to try to fetch something from a remote server unexpectedly, that attempt would be blocked by default rather than quietly allowed. The safe-by-default posture means a slip can't silently turn into a leak, because the connection simply doesn't go out. The three approved exceptions above are handled in a separate, deliberately privileged part of the app that knows to make those specific connections only on your action. The interface you click around in has no such power. This is why "no third-party connections" is something Ply enforces, not just something it asks you to trust. Caution: No software can protect data on a device that someone else is actively using while it's unlocked. Ply's on-device design protects you from Ply leaking your data and from third parties on the web; it is not a substitute for locking your computer, using full-disk encryption, and keeping your machine physically secure. The data-vault chapter is honest about exactly what password encryption does and does not cover.
The rest of Part II takes each layer in turn. Use this as a map:
If you read only one thing in this part, let it be this chapter. Everything else is detail on top of the same promise: your data stays with you, and Ply doesn't quietly send it anywhere.
This section is for the curious and the cautious. If you've ever wondered how do I actually know a malicious web page can't reach my files or my other accounts through Ply, this is the honest answer. You don't have to read code to follow it. The ideas are simple, and they're the same ideas that keep a well-built browser safe. Ply keeps the web at arm's length. Every web page you visit runs inside a tightly sealed compartment, separate from Ply's own buttons, menus, and saved data. The page never gets to decide how sealed that compartment is. Ply decides, and it always chooses the safe setting. That separation is the foundation everything else rests on.
It helps to picture Ply as two distinct worlds that look like one window. The first world is Ply itself: the rail on the left, the toolbar, the address bar, Stuff, the Canvas, Settings. This is the trusted part. It can open files (your downloads, your snips, your encrypted vault), it draws the controls you click, and it holds your synthesis data. The second world is the web pages you open. Each tab is a web page running inside what we'll call a guest, a strongly isolated container that Chromium provides for exactly this purpose. The guest renders the page, runs its JavaScript, plays its video. But it lives behind a wall. It is not part of Ply's trusted interface, and it cannot reach across into it. Almost every meaningful security decision in Ply comes down to keeping that wall solid: web content goes in a guest, Ply's own controls stay outside it, and nothing the page does can blur the line between the two.
This is the part that matters most, and the part many browsers get subtly wrong: a web page does not get to negotiate how it's contained. When a new tab opens, Ply sets up the guest with a fixed, locked-down configuration and ignores anything the page (or even a bug in Ply's own interface) might ask for to weaken it. Specifically, every guest is:
The important word is forces. Even if a page's markup explicitly requests a more permissive setup, Ply overwrites those requests with the safe shape before the page ever loads. This means a future bug in Ply's own interface can't accidentally hand a page more power than intended, because the safe configuration is applied at the wall, not left to the page or to the surrounding code to request correctly. Note: This is why some web behaviors that depend on a tab having special privileges simply don't work in Ply. That's the cost of the wall being real rather than decorative, and it's a trade Ply makes on purpose.
Ply's trusted interface isn't loaded from your hard drive as a loose file, and it isn't loaded from the internet. It's served from a tiny web server that runs only inside Ply, on your own machine, reachable only by Ply itself. Think of it as Ply talking to a private copy of itself that lives at a fixed, local-only address. This sounds like an implementation detail, but it buys two concrete safety properties:
The handful of deliberate, opt-in exceptions to "no third-party connections" (your own AI model if you turn it on, the optional update check, and local-network device sync) are made by Ply's trusted side on your explicit action, not by a web page. The page-side wall stays shut regardless.
A guest is confined not just in what it can run, but in where it can go. Ply restricts guest navigation to ordinary web pages: the normal http and https addresses you'd expect, plus the empty blank page. A guest cannot navigate itself into Ply's private interface address, and it cannot jump to other kinds of locations that might be used to escape the sandbox. This guard is applied to every way a page might try to move. Clicking a link, a script- driven redirect, and navigations inside embedded sub-frames are all held to the same rule. Closing every one of those doors matters, because a page that could load Ply's own trusted interface inside its guest would be positioned to impersonate Ply and abuse its controls, so that specific move is always refused. Pop-ups get the same treatment, but turned into something useful instead of dangerous. When a page tries to open a new window (the classic target="_blank" link or a scripted pop-up), Ply doesn't create a real window. It opens the address as a plain new Ply tab instead, with no link back to the page that opened it. The original page can't reach into the new tab, watch it, or control it. (As a side effect, a few login flows that rely on a pop-up staying tethered to its opener won't work; that's a deliberate consequence of cutting the tether, not a bug.) And every address that arrives this way is re-checked to be an ordinary web page before anything opens, so a pop- up can't smuggle in a non-web destination.
Put the pieces together and you get a simple, honest guarantee about the worst case. Suppose a web page is outright malicious, or a page you trusted has been compromised and is now running an attacker's code. What can it actually do? It can do whatever a web page does inside its own sealed guest: render content, run its scripts, try to track you (which Ply's privacy blockers work to defeat). What it cannot do is step outside that guest. It can't read the files on your computer. It can't reach into the data stored by your other sites, because container workspaces and per-site isolation keep those apart. It can't touch your saved Stuff, your Canvas, or your encrypted vault. It can't operate Ply's own controls or settings. And it can't quietly open a connection to a stranger's server to ship anything out, because the page-side wall blocks third-party connections by default. Caution: No browser can promise perfect safety, and Ply doesn't. Sandboxes are strong but not unbreakable, and a determined attacker chaining a deep flaw in Chromium itself is a real (if rare) threat that no browser fully eliminates. What this architecture buys you is defense in depth: several independent walls, each of which has to fail before a page reaches anything that matters. The design goal isn't a magic shield. It's making the easy attacks impossible and the hard ones much harder, while keeping your data on your own machine where you can reason about it. That's the whole philosophy in one line: untrusted web content stays in its box, Ply's trusted controls stay outside it, and Ply (never the page) decides how thick the wall is.
Ply blocks ads and trackers out of the box. You don't install anything, sign up for anything, or pick a filter list. Protection is on the moment you start browsing. This section explains, in plain language, what Ply blocks, how it cleans up messy links, what you can do when blocking gets in the way of a site you need, and how Ply is honest with you about when protection is and isn't working.
Ply's ad and tracker blocking is driven by two well-known, community-maintained filter lists: EasyList (ads) and EasyPrivacy (trackers and analytics beacons). These lists are bundled inside Ply itself and loaded when the app starts. They are never fetched live from the internet while you browse. There's no background call to a list server, no "check for updates" ping mid-session. The lists refresh when Ply updates: a new version of the app ships with newer copies of EasyList and EasyPrivacy baked in. This keeps with Ply's core promise, since nothing about your browsing leaves your machine just to keep the blocker current. The trade-off is that the lists are exactly as fresh as your installed version, which is why Ply tells you how old they are (see "Knowing your protection is actually on," below).
Ply blocks in two complementary ways. Network blocking stops the request before it ever leaves your computer. When a page tries to load a known ad script, a tracking pixel, or an analytics beacon, Ply recognizes the address against EasyList/EasyPrivacy and quietly cancels the request. The tracker's server never hears from you at all: no connection, no data, nothing to log. Cosmetic blocking cleans up what's left. Some pages reserve a blank box for an ad that network blocking already cancelled, leaving an awkward empty gap or a "please disable your ad blocker" shell. Cosmetic blocking hides those leftover elements. The crucial detail: Ply does this with its own styling rules only, and it never runs scripts inside the page to do it. Hiding an ad slot is a purely visual touch-up applied from outside the page, so it can't be turned into a foothold for code on a hostile site, and a page's own security rules can't block Ply's clean-up. Note: Cosmetic blocking is best-effort tidying, not a second layer of security. A few sites detect that their ad box is hidden and nag you anyway. If a site becomes genuinely unusable, use a per-site exception (below).
Beyond blocking requests, Ply rewrites a handful of link patterns that exist purely to track you or to add a detour between you and the page you actually wanted. Three things happen, all entirely on your own machine, with no lookups and no extra requests to anyone:
email/analytics correlators. It only removes tags that have no effect on the page you see, and leaves anything a site genuinely needs (search terms, item IDs, page numbers) completely untouched. There's an important safety rule behind all three: Ply only ever rewrites a link to a destination already named inside the original link, and it always re-checks that the result is an ordinary http/https web address. A crafted link can't trick Ply into "cleaning" its way to something dangerous: the cleaned link can only ever point somewhere the original link already pointed. Note: Ply deliberately does not unwrap URL shorteners (bit.ly, t.co, tinyurl, and the like). The real destination isn't in the short link, and finding it would mean contacting the shortener's server, which is exactly the kind of leak you'd be trying to avoid. Those links stay as-is. You can turn the AMP stripping, redirect skipping, and tracking-tag removal on or off individually under Settings ▸ Privacy & Security ("Strip AMP," "Skip link-tracking redirects," "Strip tracking parameters"). All three are on by default.
Two more controls live alongside ad/tracker blocking:
| Control | Default | What it does |
|---|---|---|
| Block ads & trackers | On | Cancels known ad/tracker requests; hides leftover ad elements |
| Strip third-party cookies | On | Removes cross-site cookies; leaves your logins intact |
| Block third-party scripts | Off | Blocks JavaScript from other sites (aggressive; breaks some sites) |
| Strip AMP | On | Unwraps AMP links to the real page |
| Skip link-tracking redirects | On | Jumps past bounce/redirector hops |
| Strip tracking parameters | On | Removes campaign tags and click IDs from URLs |
Occasionally a site won't work properly with blocking on: a video won't play, a login won't complete, or a page sits blank. Ply lets you carve out an exception for just that one site without lowering your protection everywhere else.
The exception applies to that site only and stays in place until you switch it back. Everywhere else, full protection continues. You can review and manage your exception lists under Settings ▸ Privacy & Security.
Ply is built to never claim you're protected when you aren't. Blocking fails open: if the bundled filter lists somehow can't be parsed at startup, pages still load and work normally (Ply won't break your browsing), but network blocking is inert for that session. Crucially, when this happens Ply tells you the truth about it rather than showing a reassuring shield it can't back up. You can always check your protection's status under Settings ▸ About:
Caution: Ad and tracker blocking reduces tracking; it does not make you anonymous. No filter list catches everything, and a determined site can still fingerprint or track in ways a list-based blocker doesn't cover. Ply layers several other defenses on top (fingerprint resistance, manipulation-pattern defusing, and HTTPS upgrades), but treat blocking as one strong layer, not a guarantee of invisibility.
Each page shows a running tally of what Ply caught, both as a small "N blocked" readout next to the address bar and in detail inside the privacy panel. Four independent counters are tracked per page:
These counts are per page and reset on each new top-level navigation: when you follow a link or load a new address, the tally starts fresh for that page. So a number like "37 blocked" reflects what happened on the page you're looking at right now, not a session-wide running total.
You probably already know about cookies, the small files a site stores in your browser to recognize you on your next visit. Fingerprinting is the sneakier cousin. Instead of leaving something on your machine, a site reads dozens of tiny, mostly harmless-looking details about your device and combines them into one near-unique signature. No file is stored, so clearing cookies or going incognito does nothing to stop it. This section explains what fingerprinting is, how Ply pushes back against it, and, just as important, where that protection stops. Ply is honest about its limits: fingerprint defense makes you harder to single out, but it does not make you anonymous.
On its own, any single detail your browser exposes is boring. Your screen size. Your time zone. The exact way your graphics card draws a curve. The list of fonts you have installed. The subtle quirks in how your sound hardware processes a tone. Millions of people share each of these values. The trick is combining them. When a tracking script gathers twenty or thirty of these signals at once and hashes them together, the result is often unique, or close enough to it that the site can recognize "this same visitor" across pages, across sessions, and even across different websites that use the same tracking service. That is a fingerprint. It works without your permission, leaves nothing behind for you to delete, and survives a cleared cookie jar. Some of the most revealing signals come from APIs that were never meant for tracking:
Ply's main defense is a technique often called farbling. Rather than trying to hide these signals entirely (which is nearly impossible and often makes you stand out more), Ply mixes a small amount of noise into the values that fingerprinting scripts read back. Ad and tracker blocking and farbling are on by default. You can see farbling at work in the Fingerprinting row of the per-site privacy panel, which counts each time a site's fingerprinting attempt was disturbed. The noise Ply adds is carefully shaped so it is useful rather than chaotic:
To keep things consistent, the farbling happens on a throwaway copy of the data a site asks for, not on the real content you see. Images, audio, and 3D graphics still display and play correctly; only the values a script tries to read back for fingerprinting are perturbed. Ply also keeps its graphics story coherent: the GPU details reported through the older WebGL API and the newer WebGPU API are made to agree with each other, so a site cannot catch Ply contradicting itself. Note: The two graphics APIs report the same modest, common GPU description rather than your actual hardware. The graphics still work normally; only the descriptive label is normalized.
Farbling handles the exotic signals, but the single most revealing thing a browser broadcasts is plain text: its user-agent, the short identity string sent to every site, plus a set of related "client hints." A browser built on Electron (which is what Ply is built on) would, by default, announce itself with tell-tale tokens that no ordinary browser sends. That string alone would be a globally unique, version-leaking label that follows you everywhere, defeating all the careful noise added elsewhere. So when fingerprint protection is on, Ply presents an ordinary, current Chrome identity instead, and aligns the client hints a page can read in JavaScript with it. This has two benefits:
For people who want to push blending further, Ply includes an opt-in strict mode, found under Settings ▸ Privacy & Security as the strict mode (uniform en-US) toggle. It is off by default.
The main thing strict mode adds is a uniform US-English language profile. Normally your browser tells every site which languages you prefer, in your own order, and your specific combination of languages can itself be a distinguishing signal. Strict mode makes Ply report the same en-US language preference for everyone who turns it on, both in the page and in the underlying request, so strict-mode users look alike instead of each leaking their own locale. Note: Strict mode reports US English to sites regardless of your actual preferred languages. If you rely on websites automatically serving content in another language, you may prefer to leave it off.
It is tempting to assume that randomizing everything is safer. It is not, and Ply deliberately does not do it. Some signals carry very little distinguishing information to begin with, for example your reported CPU core count and device memory, which realistically only ever take a handful of common values. Ply pins these to a common value (the typical "8") rather than randomizing them. The reasoning is the heart of how blending works: if everyone reports the same ordinary number, you disappear into the crowd. But if Ply handed each browser a random core count, you would be one of very few visitors reporting that unusual value, which makes you more identifiable, not less. Randomizing a low-information signal is counterproductive, so Ply normalizes these rather than noising them. This is the same philosophy behind the Chrome identity: the goal is not to look mysterious, it is to look unremarkable.
Fingerprint protection meaningfully reduces passive, cookie-free tracking and helps you look like an ordinary member of a large crowd. That is a real, worthwhile gain, and it is on by default. But it is not anonymity, and it would be dishonest to suggest otherwise:
adversary, use a tool built for that purpose. See the threat-model section for the full picture of what Ply does and does not defend against.
The honest summary: Ply's fingerprint defenses raise the cost of tracking you and help you blend in, session to session and site to site. They are a strong layer of a broader privacy posture, not a cloak of invisibility.
Plenty of websites are designed to push you into decisions you didn't really mean to make: a "decline" button that calls you foolish for saying no, a clock counting down to nowhere to make you hurry, a subscribe box already ticked before you arrived. These tricks are usually called dark patterns. Ply ships with a built-in defense against the most common ones, on by default, that quietly takes the pressure off without ever taking a choice away from you. You can see it working in the site privacy panel (open it from the shield button at the left of the address bar). One of the rows there is Manipulative patterns, with a running count of how many it has defused on the current site and sub-labels for the three kinds it recognizes: guilt-trip button, fake countdown, and pre-checked box.
The key thing to understand is that this feature only restyles the page. It reads the page to spot a coercive pattern, then changes how that element looks. It never clicks anything for you, never unchecks a box, never submits or cancels a form, and never sends or changes any of your data. It works entirely inside the page you're viewing, reading the page's structure and applying Ply's own styling on top. Nothing about what you noticed leaves your machine. It is also deliberately gentle. In every case the original control stays fully usable. If Ply dims a decline button, you can still click it. If Ply flags a checkbox, the checkbox is exactly as the page set it, and Ply only draws your attention to it. The goal is to slow the manipulation down so you decide, not to make the decision for you.
This is the "No thanks, I hate saving money" style of button, a decline or dismiss control whose text is written to make refusing feel embarrassing. When Ply detects guilt-trip wording on a decline control, it dims that control so the manipulative framing loses its visual punch. Note: The button stays fully clickable. Dimming a confirmshaming button is the whole point. You can still calmly decline, without the page shaming you into clicking the other option. To avoid false alarms, Ply only treats a control as confirmshaming when its text is long enough to actually carry a guilt-trip phrase. A plain "No" or "Cancel" is never touched. The phrases it looks for are kept as a plain, auditable list covering English plus several major languages (Spanish, French, German, and Portuguese), so the matching is conservative by design.
A timer ticking down ("Offer ends in 04:59… 04:58…") is a classic urgency trick, and most of these clocks just reset when you reload. When Ply sees a clock that steadily counts down, it greys it out and makes it non-interactive, so the ticking number stops nagging you. Ply is careful here so it doesn't grey out clocks you actually want. It watches a value over time and only treats it as a fake-urgency timer if it sees it tick down several times in a row, by small, steady amounts. A clock that goes up (a normal wall clock) or jumps around (a video's playback time) is left alone.
This is the checkbox ("Sign me up for the newsletter", "Yes, I want to receive offers") that arrives already ticked, so that if you don't notice it you've consented to marketing or data- sharing by default. When Ply finds a checkbox that is already checked on arrival and whose label reads like a marketing or consent opt-in, it flags it with an outline and a small badge. Caution: Ply does not un-tick the box for you. That's a deliberate choice. The checkbox is part of a form the page may submit, and silently changing its state could alter what gets sent in ways you don't expect. So Ply highlights it and leaves the actual decision, and the actual click, to you.
Some sites might trip the detector in a way you'd rather override (for example, a real timer you don't want greyed out). Open the site privacy panel from the address-bar shield, expand the Manipulative patterns row, and use the Allow … on this site toggle. That exception applies only to that site, and every other site stays protected. You can also turn the whole feature on or off globally in Settings ▸ Privacy & Security ("block manipulative patterns"). Note: This is a per-site allowance you set yourself. Importing a workspace from someone else can never quietly switch your manipulation defense off, because the setting isn't carried in shared workspace bundles.
This is a first-version feature, and it covers exactly the three patterns above: confirmshaming, fake countdown timers, and pre-checked opt-in boxes. These were chosen because they have clear, recognizable signatures that Ply can spot with low risk of a mistake. One well-known category is deliberately not tackled yet: "nag" and hard-to-cancel flows, the maze of screens designed to make ending a subscription or closing an account painful. Those are the hardest to detect reliably, because what counts as an unfair obstacle versus a legitimate multi-step form is genuinely ambiguous, and getting it wrong would mean greying out controls you actually need. Since a false alarm that dims a real button is a worse outcome than occasionally missing a trick, Ply errs on the side of caution and leaves that category for a future version rather than guessing. Ply takes the pressure off the most common manipulative patterns while keeping every control you might want fully working. It never touches your data while doing it.
Websites regularly ask for access to things outside the page itself: your camera, microphone, location, the ability to send notifications, read or write the clipboard, and so on. Ply handles these requests with a simple rule that favors your privacy: ask you once per site, remember your answer only while Ply is running, and forget everything the moment you quit. Nothing about which sites you allowed is ever written to disk.
When a page asks for a sensitive capability, Ply shows you a short prompt naming the site and what it wants. You choose to allow or deny. That's it. There's no separate "manage site permissions" database to maintain, because Ply doesn't keep one. The prompts cover the capabilities you'd expect a browser to gate, including:
| Capability | What the site is asking for |
|---|---|
| Camera | Live video access (video calls, photo capture) |
| Microphone | Live audio access (calls, voice input) |
| Location | Your approximate or precise geographic position |
| Notifications | Permission to show desktop notifications |
| Clipboard | Reading from or writing to your system clipboard |
| Pointer lock | Hiding and capturing your mouse cursor (games, 3D apps) |
| Storage access | Letting an embedded site use its own cookies/storage |
If a capability isn't on Ply's short list of harmless, auto-granted ones (see below), you'll be asked about it the first time a site needs it.
The single most important thing to understand: your allow/deny decisions are remembered only for the current run of Ply, and only in memory. They are never saved to a file on your disk. Two consequences follow from this:
Note: This is a deliberate trade-off. Ply chooses privacy (no on-disk record of which sites you trusted) over the convenience of decisions that survive a restart. If you find yourself re-allowing the same site often within a session, that's expected behavior, not a bug. The decision sticks for as long as Ply stays open.
Some sites are written to re-request a permission on nearly every click or page change: a chat site that asks for notifications on each navigation, a page that re-prompts for the microphone every time you start a recording, and so on. Ply spares you the barrage. Once you've answered for a given site in the current session, Ply quietly reuses that answer for the rest of the session instead of popping the prompt again and again. When a prompt does carry a remembered decision, Ply tells you so, so you understand why you're not being asked repeatedly.
A small set of low-risk capabilities are granted automatically without a prompt, so ordinary browsing isn't interrupted by trivial requests. These are the kinds of things that don't expose your hardware or your physical location. At the other end, device access is denied by default and is not offered through a normal prompt at all. Connecting to USB devices, serial ports, or human-interface devices (HID), the low-level hardware bridges that a malicious page could abuse, is refused. Ply doesn't expose these to web pages, so there's no "Allow this site to connect to a USB device?" dialog to accidentally accept. Caution: Granting camera, microphone, or location to a site gives that site real access while it's open and you've allowed it. Ply's farbling and tracker blocking reduce passive fingerprinting, but they can't undo a permission you actively granted. If you allow the microphone, the site can hear you. Only allow these for sites you trust, and remember that quitting Ply revokes the grant.
If you use a container workspace (one with its own isolated cookie and storage jar, see the Workspaces section), permission prompts behave a little differently to keep the isolation honest:
This mirrors how containers work everywhere else in Ply: they change who the site thinks you are by keeping cookies and storage separate, and permissions follow the same boundary so a grant can't quietly leak from one identity to another.
Security tools are only useful if you understand exactly what they do and do not cover. This section is deliberately candid: it lays out what Ply protects well, where its protections stop, and the threats it was never built to handle. No tool can defend against everything, and a clear picture of the gaps is worth more than a reassuring slogan.
No telemetry, no phoning home. Ply does not track you, does not report usage, and makes no background connections to Ply's makers or any analytics service. There is no bundled "default provider" quietly receiving your activity. The only times Ply ever talks to a server other than the page you asked for are three explicit, opt-in features you turn on yourself: bring-your-own AI, opt-in auto-update, and LAN device sync. All three are off until you enable them. As a backstop, the app's own interface is also prevented from reaching anywhere except the page you requested, so a future bug can't quietly open a new connection. Ad, tracker, and fingerprint resistance. With default settings, Ply blocks ads and trackers using vendored, on-device filter lists (nothing is fetched from a network filter service at runtime), strips third-party cookies, hides cosmetic ad clutter, removes common tracking parameters from links, and "defuses" manipulative dark patterns like guilt-trip decline buttons, fake countdown timers, and pre-checked opt-in boxes. It also adds small, per-site randomization ("farbling") to the signals sites use to fingerprint your device (canvas, audio, WebGL, and WebGPU readings) and replaces the revealing Electron browser identity with an ordinary Chrome one so you don't stand out as a Ply user. Hostile pages are sandboxed. Every web page you open runs as an isolated guest, walled off from the app's own privileged interface and from your filesystem. Pop-ups can't open real windows or carry an opener reference; they become ordinary new tabs instead. A page can't reach Ply's internal controls even if it tries. Your synthesis data can be encrypted at rest. The optional data vault (Settings ▸ Encryption) encrypts your workspaces, history, Stuff, Canvas, notes, links, download records, and snip images on disk using a password-derived key with strong, modern cryptography. The key never leaves the app's memory and a wrong password never yields readable data. Strong, private-by-default settings. You don't have to configure anything to get the core protections. Tracker blocking, cookie stripping, fingerprint randomization, manipulation defusing, HTTPS upgrading, AMP unwrapping, redirect skipping, tracking-parameter removal, and WebRTC leak protection are all on out of the box.
The vault is genuinely useful, but its protection is narrow and worth stating plainly.
Caution: For real protection, pair the vault with your operating system's full-disk encryption (FileVault on macOS, BitLocker on Windows). Full-disk encryption covers everything on the drive; the vault adds a second password-gated layer specifically over your Ply synthesis data. One without the other leaves a gap. Caution: If you forget your vault password and have not enabled system-keychain auto-unlock, your encrypted data is unrecoverable. There is no backdoor and no recovery code. The "start fresh" reset option exists precisely because a forgotten password can't be worked around: it discards the encrypted data rather than recovering it.
Ply's fingerprint randomization reduces how easily sites can re-identify your device across visits, and it makes you look more like an ordinary Chrome user than a unique one. But it reduces tracking; it does not eliminate it. Determined trackers combine many signals, and some are impractical to spoof without breaking pages. Most importantly: Ply is not an anonymity network. It is not Tor, and it is not a VPN. It does nothing to hide your IP address from the sites you visit. Every site you load still sees the network address you connected from, and your internet provider still sees which sites you connect to. If you need to hide your network location or identity, you need a separate tool (a VPN or Tor) layered underneath Ply. Fingerprint resistance alone won't get you there.
The AI features are off by default and ship with no model. When you turn them on, you point Ply at a model endpoint you configure: your own local model, or a paid API you've signed up for. When you use an AI action (summarize a page, search tabs, search your library, translate a selection), the relevant text (page contents, your selection, or selected snippets from your own library) is sent to that endpoint. Ply enforces some guardrails: plaintext HTTP is only allowed toward provably-local addresses, so your text and API key can't cross the open internet unencrypted; your API key stays in the app's protected storage and is never handed back to the page; and the model's reply can only return as inert text, never as something that can navigate or run. But the central fact is yours to own: the endpoint you choose sees what you send it. If that's a commercial API, your text goes to that company under their terms. Choose an endpoint you actually trust, and be deliberate about which pages and selections you feed it.
LAN device sync ("Plytether") is off by default and only ever connects directly between devices you pair, on your own local network, never through a server or relay. Pairing uses a one-time exchange protected by a six-digit code shown on both devices. Caution: When you pair, compare the six-digit code on both screens and only continue if they match. That comparison is what defends against someone on your network impersonating your other device during pairing. A mismatch means something is wrong, so stop. After pairing, sync trusts those devices and your local network. Only pair devices you control, and be mindful on untrusted networks.
The opt-in updater and the rollback ("revert") feature verify each downloaded build before running it: on macOS, that the build is notarized by Apple and signed by Ply's developer identity for the exact version requested; on Windows, that the installer carries a valid signature. A revert can only move you to an older, genuinely-published version, never sideways or to something arbitrary. This depends on your operating system's signature-checking machinery working correctly and on your OS keychain (if you opt into vault auto-unlock). It is strong, but it is not magic. It trusts the platform's trust anchors.
To be unambiguous, Ply is not:
| Not a... | What that means |
|---|---|
| VPN or proxy | It does not hide your IP or route your traffic elsewhere. Sites and your ISP see your real connection. |
| Anonymity network | It is not Tor. It reduces fingerprinting but does not make you anonymous. |
| Password manager | It does not store or autofill your website passwords. (The vault encrypts Ply's own synthesis data, not your logins.) |
| Antivirus or anti-malware | It sandboxes web pages, but it does not scan files or detect malware on your system. |
| Defense against a compromised machine | If an attacker already controls your unlocked, running computer, Ply cannot protect you. Anything you can read, they can read. |
That last point is the most important boundary. Once your machine is unlocked and an attacker has code running as you, the vault is unlocked, your AI key is reachable, and your paired-device trust is theirs. Ply's protections assume the machine itself is yours.
If you want to get the most out of Ply's protections, do these things deliberately:
Short answers to the questions Ply users hit most often. Where a longer explanation lives elsewhere in this handbook, the answer points you to it by name.
Does Ply phone home or track me? No. Ply runs entirely on your device and sends nothing about you anywhere by default: no analytics, no usage pings, no account, no cloud. There are exactly four ways Ply ever talks to anything beyond the pages you visit, and all four are off until you turn them on, and each one only ever contacts a destination you chose:
That's the whole list. Ply has no other outbound connections, and a built-in safeguard actively blocks the interface itself from reaching anything other than these approved paths. Where is my data stored, and who can see it? Everything Ply saves (your workspaces, history, Stuff, Canvas notes, downloads list, and settings) lives in a folder on your own computer. Nothing is uploaded. For an extra layer of protection on a lost or stolen device, turn on the password vault (Settings ▸ Encryption) to encrypt that data at rest. See "The Data Vault (Encryption)".
Why didn't my logins carry into a container workspace? That's by design. A container workspace keeps its own separate cookie and storage jar, isolated from your other workspaces. The whole point is that signed-in sessions, cookies, and site data don't leak across the boundary, so a fresh container starts logged out everywhere, and you sign in again inside it. Your logins in your normal (shared) workspaces are untouched. If you'd rather a workspace share the common login state, leave it as a regular workspace. See "Container workspaces". Note: When you import a workspace bundle, it always lands as a regular shared workspace even if it was a container originally. A bundle carries no cookie jar, so an "imported container" would just be empty. Why does a site say my browser is unsupported, or my login won't work? Two of Ply's privacy features can occasionally trip up a strict site:
To fix it, open the site-privacy panel from the shield/lock button at the left of the address bar, and use the per-site "Allow… on this site" toggles to relax a protection just for that site, most often Fingerprinting or Ads & trackers. Your global settings stay unchanged. If a sign-in pop- up still won't finish, try completing the login in the new tab Ply opened, or temporarily relax the relevant protection for that site. See "Ad, Tracker & Cosmetic Blocking" and "Container workspaces". A page looks broken with blocking on. How do I make a per-site exception?
The exception applies only to that site and persists; everything else keeps its full protection. See "Ad, Tracker & Cosmetic Blocking".
I see a "storage full" message. What does it mean? Ply keeps your synthesis data in your browser's local storage, which has a size limit. When you bump against it, Ply automatically trims the oldest history entries and retries the save. If it still can't fit, it shows the one-time "storage full" notice so a save never fails silently. To free space, prune old History or clear out Downloads and unneeded Stuff items. Ply also caps each store on its own (for example, history holds up to 5,000 entries) and trims the oldest as you go, so it won't grow without bound. My data seemed to reset after I moved or reinstalled the app. What happened? Almost certainly nothing was lost. Ply serves its interface from a small local address, and on rare occasions (for example right after moving the app or a relaunch) it has to come up on a slightly different one, and your browser ties stored data to that address. To survive exactly this, Ply keeps a separate, address-independent backup copy of your saved state and automatically restores from it when it starts up on a different address and finds nothing there. So your workspaces, Stuff, and Canvas should reappear. If they don't immediately, fully quit and relaunch Ply once to let the restore run. (If you use the password vault, your data is in the encrypted vault file instead and is rehydrated when you unlock.)
I forgot my vault password. What are my options? The vault is genuinely encrypted, so there is no back door. That's what makes it protective. Your options:
There is no way to recover the old password or decrypt the data without it. See "The Data Vault (Encryption)".
Device sync won't connect. What should I check? Run through this checklist (see "Device Sync (Plytether)" for the full walkthrough):
An update or a rollback failed. Why? Ply deliberately refuses to install a build it can't verify. Before running any update or rollback, Ply confirms the download is the genuine, properly signed Ply build (correct developer signature and identity) and that its size matches what the update feed advertised. A rollback additionally must be to a version strictly older than the one you're running and present in the official feed, so Ply won't let anything force a sideways or forward install through the rollback path. If verification fails, Ply stops rather than installing something untrusted. Re-try the download; if it keeps failing, download the version directly from the official source. See "Updating Ply". How do I report a problem, and what gets shared if I do? Ply doesn't collect or transmit diagnostics. Settings ▸ About answers "What does Ply collect?" with "Nothing." A report is whatever you choose to write up and send yourself; no logs leave your machine automatically. Useful details to include: your Ply version and engine versions (Settings ▸ About), what you did, and what you expected versus what happened. Your data lives only on your device, so nothing is exposed simply by asking for help.
Ply 1.0.5 · 2026-06-30. By default, everything in Ply stays on your device. Your browsing, notes, captures, and synthesis live only on your own machine.
Ply