HN user
https://cs.chromium.org/chromium/src/components/password_man...
static constexpr size_t kHashKeyLength = 32;
static constexpr uint64_t kScryptCost = 1 << 12; // It must be a power of 2.
static constexpr uint64_t kScryptBlockSize = 8;
static constexpr uint64_t kScryptParallelization = 1;
static constexpr size_t kScryptMaxMemory = 1024 * 1024 * 32;Disclosure: I'm the TL of this project on Chrome.
Your concern is fair.
TL answer: I can tell you that this data is used only for improving user security. Legal answer: Please read the Chrome Privacy Notice :)
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] You can check by going to chrome://safe-browsing/#db-manager
[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.
This is incorrect from Malware blacklisting purposes. I don't know about URL prediction.
For Safe Browsing protection, here's how it works (in progress): https://chromium.googlesource.com/chromium/src/+/refs/change...
[Disclosure: I'm the Software Engineer on Chrome who wrote parts of this Safe Browsing code, and that incomplete documentation linked above.]
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.
From: https://developers.google.com/safe-browsing/v4/update-api
Source: Safe Browsing engineer on Chrome.
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.
Source: I'm a Chrome SafeBrowsing engineer.
Chrome SafeBrowsing engineer here.
Google has published the protocol that clients need to follow to fetch updates from the SafeBrowsing servers here: https://developers.google.com/safe-browsing/developers_guide...
Both Chrome and Firefox implement that protocol. I believe Edge uses Microsoft's own service. Not sure about Opera.
Thanks for correcting me. I never realized this.
The pathname "/a/google.com" means it does come from within Google.
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.
hahahahaha
btw, no love for "yahoo" either.
That's what you get now, but that wasn't the case earlier. The author says he patched it for that keyword ("google").
I see changes coming in as I try more things. Good job folkster!
not anymore. he probably pathced this one too.
Canary & Dev on Windows, Dev on Mac and Linux.