Disclosure: I'm the TL of this project on Chrome and I work very closely with the Safe Browsing engineers regularly.
> What if Google's algorithms classify your new startup as "potential phishing", because users are re-using their own passwords on your site?
That's not how our phishing detection works. In fact, our internal studies show that a lot of users reuse their passwords often and while that's not the best password hygiene, it's the user's choice to make and we have to respect that and build protections with this in mind.
> How can you appeal?
Right from your search console.
> What recourse do you have against Big G's algorithm?
Ultimately, Google/Safe Browsing has a lot more to lose if their users stop trusting their product(s). I can tell you that we take false positives very seriously and try hard to provide a fair and speedy resolution.
[Disclaimer: I'm the TL of Safe Browsing in Chrome, and I worked directly with the author of the linked article for Firefox v4 support.]
FWIW, Google Chrome does the same because both Google Chrome and Firefox use the same Safe Browsing protocol v4.
The linked post was written a while ago when Firefox still used the protocol v2 but the post is still largely accurate.
Did you turn on that 'Block dangerous and deceptive content' feature in Firefox' security tab? It works by consulting Google each time you visit a new website. You can imagine the rest.
Patently wrong. Here's how the API works:
The Update API lets your client applications download hashed versions of the Safe Browsing lists for storage in a local database. URLs can then be checked locally. Only if a match is found in the local database does the client need to send a request to the Safe Browsing servers to verify whether the URL is included on the Safe Browsing lists.
Not quite.
In the case of OCSP, in the absence of OCSP stapling, all TLS connections are verified with an external server(s).
In that case of SafeBrowsing however, as noted in the article, for those URLs whose hash prefix doesn't match one of the hashes on one of the blacklists, the browser doesn't contact any other server.
Only when there's a partial match does the browser ask for a full hash from the SafeBrowsing server.
Very neat. Thank you!
Here's a bug report :)
When I zoom out of the grid-based listview using semantic zoom, and click on one of the columns, I expect to see that column in the view. Currently, it just goes back to the previous state of the zoomed-in view.