That was a major concern of mine. You can set the Research mode to "Off" by default and check URLs on a case-by-case basis and still do custom searches. Admittedly, it takes some of the serendipity out of it, but it addresses your concern.

I considered (and was planning on) adding a "block URL" feature - but the issue of how to store those sensitive URLs (to block) came up. Because localStorage and sync storage in Chrome is not sandboxed or encrypted, the blocked list would be "in the open" to other extensions. Yes, you could hash the urls you'd hope to block, but then there would be no way to read that list back to the user at a later point in time, and slight mismatches in URL schemes would lead to an imperfect system. So simply toggling Research Mode and researching pages of interest is the best option, IMO.

I don't cache any personal info in localStorage or sync storage (which at least Chrome does not encrypt :< ). The api results are stored in a local variable within the scope of the extension. And the "history" is a hashed and padded blob.

This is also why I released it for both Chrome and FF, since some people assign different use cases to different browsers. The code is also public/open-source.

Maybe I missed it, but as far as I can tell, this comment is the only documentation of what "research mode" means. You might want to address that somewhere...

No, you're right. Adding it now (thanks!) (update added to landing page and pushing out to the Chrome/FF stores)

Nice work. How about a whitelist mode? Basically, the research mode + the ability to add sites (e.g., news sites, blogs, etc.) to the whitelist.

I like the idea of adding a whitelist to complement using the extension with Research Mode turned "off". I'll add that to the todo list! Thanks!

I want to echo that sentiment (maybe to push it up higher on your list!) -- a white list and/or black list would be very helpful.

I would also like to express my appreciation for making a firefox addon as well. I feel like ff is often left by the wayside.

In my extension (thinkcontext) to get around leaking browsing behavior to 3rd party sites I download the complete data set. That way all queries are local which has the added benefit of low latency.

Sounds fantastic for your extension, but it would be too heavy for Kiwi. The entire Reddit, HN, and Google News data sets would (easily) be too large

> Because...sync storage in Chrome is not sandboxed or encrypted, the blocked list would be "in the open" to other extensions.

Unless things have changed from a couple of years ago (highly doubt it), I don't think this is the case. https://groups.google.com/a/chromium.org/d/msg/chromium-exte...

chrome.storage docs: "Confidential user information should not be stored! The storage area isn't encrypted." https://developer.chrome.com/extensions/storage

I was intending to just dispute that 'the blocked list would be "in the open" to other extensions'.

Why couldn't you use chrome.storage.local or the background page's localStorage? Either should protect the data from other extensions and not expose it to third parties.

I wanted explicit language from Chrome's docs about how it scopes storage.

Firefox provided it: "The simple storage module exports an object called storage that is persistent and scoped to your add-on." https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_A...

But all Chrome's docs said were the previously mentioned warning about not using it to store confidential user info.

So, to answer your question: caution

Actually, if you go back to my init commit on Github - you can see that I originally used the chrome.storage API. I extricated it from the code - except for the non-sensitive settings

It doesn't help in this case since they're third-party APIs, but if you controlled the backend it seems like a good application for bloom filters.

Still, the problem inherent to the concept is that it leaks the users' history to third-parties.

Its default usage does. The idea is that it returns enough value in exchange to be worth it. It also has a "Custom Search" feature that is useful without sharing your history.

The problem isn't just private links. Even knowing about the public sites that someone visits can expose information about their politics, religion, sexual orientation and other things that they may want to keep private (especially in countries where they can be discriminated against or even killed based on this information).

One would hope there aren't too many things you genuinely want to keep private where the only protection is an unguessable URL. That's never going to be terribly secure. Google Docs you have to go out of your way to create a doc that works that way.

Nearly every website's password reset links are a secret in the URL.

Hopefully single-use!

It's too bad that there's no standard way to flag part/all of a URL as secret as a hint to caching engines and the like.