[koolba]

> There is no data collection by default. Everything is opt-in. The only information we communicate is what you opt into. The browser history stays in your browser and is not sent to Apozy.

Maybe I'm not getting how this works, but how can a service like this function without sending the URL (or FQDN etc) to a remote service? It's too much data to have the entire map of all servers on the internet bundled locally (probably a pain to update too...). That said, what does it mean to use this plugin but not opt-in? Is that possible, or are you referring to users opt-in as part of the install?

[rickdeaconx]

We don't need to send any information to our service to protect you from bad sites because that is handled locally. The browser history already exists so the load on your machine is the same with or without Apozy. We use the headers to make it efficient for a large number of sites - 1M+

Using the extension without opting in means you don't see site privacy grades but you're still protected using a Trust on First Use model of security created with your browsing history.

[koolba]

> We don't need to send any information to our service to protect you from bad sites because that is handled locally. The browser history already exists so the load on your machine is the same with or without Apozy. We use the headers to make it efficient for a large number of sites - 1M+

Okay so the local version is comparing the user's current page vs. the sites they've gone to prior? And if it seems off based on some heuristics it flags the page. Interesting idea.

Wouldn't work for me though as I have my browser set to nuke everything each time it's closed.

> Using the extension without opting in means you don't see site privacy grades but you're still protected using a Trust on First Use model of security created with your browsing history.

I originally thought it was just this piece which would need some type of client / server interaction to either fetch the "bad lists" or send the current URL/FQDN for validation.

[uzay]

> Wouldn't work for me though as I have my browser set to nuke everything each time it's closed.

If you don't nuke your local storage, it should still work. I do suspect it may be more annoying without any browser history to go on because there's no model built, so you have to 'prime the pump' a little more than a user who has history would have to.

-Erhan

[tptacek]

Are you storing a shadow browser history in localStorage?

[koolba]

I would imagine it's either that or they're somehow querying localStorage for the existence of any data for a given domain to indicate that you've been there before (which obviously wouldn't work for sites that don't use localStorage).

[rickdeaconx]

We keep just the FQDN for sites that you "unlock". If you don't click unlock, nothing is stored.

[hunter2_]

With TOFU, "priming" equates to blind trust in practice. This is an important point even when you don't nuke on browser-quit. You can have TOFU (e.g., SSH), WoT (e.g., PGP), or PKI (e.g., TLS)... each with it's pros and cons. I can only hope that someday we have something without the "priming" hole of TOFU, the UX hurdles of WoT, and the fact that HTTPS doesn't really stop people from being phished.

I think opting in to the server side checking (which is a bit like the domain-based blacklists that modern browsers have, I think) is the best thing we've got at the moment, so long as that channel isn't compromised.

[rickdeaconx]

We rely on the whitelist to block all new threats, putting us ahead of domain-based blacklists. The server side checking is just to create a grade for privacy which you can look at for informational purposes as you browse.

[koolba]

My setup nukes everything. Each time my browser starts it's as a fresh install with no browser history, local storage, cache, etc.