5 ms·
There are some pretty serious privacy issues with this extension. There should be a way to block domains that you don't want searched, otherwise secret URLs su
by ejcx 11y ago
There are some pretty serious privacy issues with this extension.
There should be a way to block domains that you don't want searched, otherwise secret URLs such as youtube private links, google docs, etc are exposed. One scary thing is you are potentially exposing them to third parties, by searching reddit, HN, and google.
This is a pretty good example of why people need to be wary of chrome extensions they install. They sit in an advantageous position where violating things like SOP, CSP Rules (depending on the browser) and more is okay by using the background page.
- spenvo 11y agoThat 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.
- Schwolop 11y agoMaybe 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...
- spenvo 11y agoNo, you're right. Adding it now (thanks!) (update added to landing page and pushing out to the Chrome/FF stores)
- mnutt 11y agoIt 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.
- Dysprosium 11y agoStill, the problem inherent to the concept is that it leaks the users' history to third-parties.
- spenvo 11y agoIts 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.
- jaredsohn 11y ago> 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-extensions/NuhGzFIvCKE/sTB4iLSF8qcJ https://groups.google.com/a/chromium.org/d/msg/chromium-exte...
- spenvo 11y agochrome.storage docs: "Confidential user information should not be stored! The storage area isn't encrypted." https://developer.chrome.com/extensions/storage https://developer.chrome.com/extensions/storage
- jaredsohn 11y agoI 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.
- spenvo 11y agoI 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_APIs/simple-storage 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
- thinkcontext 11y agoIn 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.
- spenvo 11y agoSounds 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
- sinaa 11y agoNice work. How about a whitelist mode? Basically, the research mode + the ability to add sites (e.g., news sites, blogs, etc.) to the whitelist.
- spenvo 11y agoI 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!
- malnourish 11y agoI 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.
- eli 11y agoOne 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.
- greenyoda 11y agoThe 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).
- Pxtl 11y agoIt'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.