Managing Site Logins
Erase wipes out your Pelorus search sessions, which by definition includes signing you out of anything you logged into. But that means a site you use constantly and frequently need to be signed into is going to ask you to log in again every time you go back after a search session. If that is not what you want, Pelorus gives you flexibility to persist your login sessions site-by-site while erasing only the rest of your tracks. This page explains what this all means, how it works, and how to see the data that sites have stored about you.
Allow Login Sessions
Allow Login Sessions, under Settings > Privacy & Security, is the master switch for all of it. With it off, nothing is kept, and sites on your keep list are shown as inactive until you turn it back on.
Keeping a Site
Whether you have a search card open or are browsing any other website, you will always see a shield icon on the right side of the card's header. Tap the shield for options to Keep Me Signed In, or view the site's tracking details. Any site on which you select Keep Me Signed In will be allowed to store its cookies and other site-specific local data on your device, associated with the Pelorus browser. With Allow Login Sessions turned on, this will ensure you can stay logged in across your Pelorus usage sessions. And when you Erase a session, everything else that site stored, such as its cached files, will still be cleared while your login is preserved. Sites that are not tagged with Keep Me Signed In will still be wiped completely.
There is an important technical detail to be aware of here. Browsers are not able to reliably and consistently distinguish between general data a site stores and a login. A login is just one cookie among the others a site sets, and nothing marks it as the one that matters. So when you keep a site signed in, Pelorus has to keep all of that site's cookies and local storage, not only the login. That means the site can still recognize you the next time you visit, but it can also remember anything else it saves for its own purposes - such as its own analytic data, a record of what products or articles you looked at, the preferences and A/B test assignments it set for you, and the advertising identifiers it uses to tailor what you see. All of it stays until you remove the site from the Keep Me Signed In list or you manually clear that site's data under Settings > Privacy & Security > Site Data. Keeping one site keeps nothing for any other site, and the advertising and tracking companies that appear on a kept site's pages are still cleared with everything else in accordance with your other Privacy & Security anti-tracking settings. Keeping a site is a deliberate exception, which is why we ship Pelorus with no sites already specified on the list.
For the curious Why Browsers Cannot Reliably Tell the Difference
The constraint here is in the storage model the web standardized on. It is not anything Pelorus or WebKit chose and there is little it can do to work around these constraints. (WebKit is the foundational browser engine behind both Safari and Pelorus.)
A cookie carries no purpose field. The Internet Engineering Task Force published the RFC 6265 standard, giving cookies a name, a value, a domain, a path, an expiry, and a few flags (Secure, HttpOnly, with SameSite added later in RFC 6265bis). That is all. There is no attribute that says "this is a session credential" versus "this is a preference" versus "this is a tracking ID." The name is whatever the site picked (sid, PHPSESSID, auth_token, _ga, prefs, x7q), the value is opaque to the browser, and a site is free to name its login cookie theme if it likes. Browsers merely store and return bytes of data; they are not told what the bytes mean.
Logins are not even always a single cookie. Many sites split a session across numerous cookies (a session ID, a CSRF token, a "remember me" token, a device-trust cookie), and some keep the session in localStorage or IndexedDB rather than in a cookie at all, with a token the page's JavaScript attaches to every request. A browser that kept "only the login cookie" would, for those sites, keep nothing that works.
The site's data is one blob per origin. Cookies, local storage, session storage, IndexedDB, the cache, and service workers are all keyed by origin and stored together. WebKit's WKWebsiteDataStore lets Pelorus remove data by origin and by data type (cookies, local storage, cache, and so on), which is why Erase can clear a kept site's cached files while leaving its cookies and local storage. It does not let anyone remove "the cookies that are not the login" because no such distinction exists in the data store.
Heuristics exist and fail. A browser could always guess: keep cookies marked HttpOnly (often, but not always, session cookies), or drop ones whose names look like analytics (_ga, _fbp). But guessing means some portion of sites will break unpredictably, and a site that wanted to survive heuristic attempts to block it would just rename its tracking cookie. We would be playing constant whack-a-mole to engineer and adapt around those changes. Firefox's "Total Cookie Protection" and Safari's Intelligent Tracking Prevention (ITP) both address a different problem, third-party cookies across sites. Neither claims to separate first-party login state from first-party everything-else, for the same reasons Pelorus has not been able to.
As a consequence of these constraints, we have built Pelorus to be honest about what it can allow - the whole first-party origin data, or none of it. But we chose to build in a site data manager and other tools so you can keep your logins but still be able to inspect and clear the data a site has stored for you.
Signing in to a Search Engine
You can sign in to a search engine on its own search card, or just by browsing to it in Pelorus, just as you would in a browser. Most engines work fine without a login, but some may need an account before they will search at all or might limit anonymous (logged-out) searches, like Kagi. Keep Me Signed In on that engine and the login will persist.
You should weigh the cost of signing in. For most users, this is a non-issue and the convenience of being able to sign in outweighs the privacy implications. But make your choices eyes-wide-open: an engine you are signed into can tie your searches - whether they're in Pelorus or any other browser - to your account and keep them in its own history on their servers. That record of your searches lives with the engine and is governed by their own philosophy on exploiting users for revenue and their own data safeguards, privacy policies, and terms of use. Pelorus cannot see that data, and its Erase and Reset functions cannot reach it.
For the curious How Long a Login Lasts
Most sites with account/login functionality have limits on how long you can remain logged in before you get logged out automatically or have to re-verify who you are. Pelorus cannot control how often those come up; those are settings and allowances set between you and that provider.
Seeing What a Site Has Stored
Settings > Privacy & Security > Site Data lists every site that has stored something in Pelorus. Each entry shows what it holds, such as cookies, local storage, and cached files, and Clear Site Data removes that one site without touching the others. That is the way to clear one site without erasing everything.
Clear All Website Data, on the same screen, wipes every site's data in Pelorus at once, kept sites included, and empties the keep list. It leaves your settings, engines, and keys alone.
Popups and Sign-In Windows
Some sites sign you in through a window that opens over the page. Pelorus shows it as a sheet. When it closes and the site has set a login cookie, the page under it reloads so that the new login takes effect.
What Erase Still Clears
With Allow Login Sessions on and a site kept, Erase still closes every card, forgets the search, and destroys everything every other site stored. Your settings, engines, presets, and API keys were never part of Erase. Privacy and Security covers the rest of what Erase does and when it can run on its own.