10 ms·

Better password protections in Chrome

131 points by hbcondo714 7y ago

TMWNN 7y ago
chrome://flags/#username-first-flow is needed to see the Warn you if passwords are exposed in a data breach option in Sync and Google services
dannyw 7y ago
Some of these changes, such as realtime sending of all non-popular URLs, concern me a little. I am happy for Google to use this information for aggregated security purposes (e.g. bots analyse suspicious new pages). I am not happy with this being associated to the Google account. However, AFAIK, I have no way of knowing this, and in the absence of an explicit statement, I have to assume the worst: that Google will use this to target me ads. If any Chrome team members are reading this comment, could we get some sort of confirmation that these security features will not be used to collect more data to target me ads?
- msbarnett 7y ago
  > If any Chrome team members are reading this comment, could we get some sort of confirmation that these security features will not be used to collect more data to target me ads Any statement they make is open for change at a later date if management changes their mind. You’d be better off thinking about moving to a browser made by a company that whose privacy protections don’t exist in a perpetual conflict of interest with the company’s dominant revenue source
- aawc 7y ago
  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 :)
  - tsukurimashou 7y ago
    So basically "you have our word, so trust us!"
    - delroth 7y ago
      Do you see any other alternative than trust for such a system? - Building a fully local system will not provide the same coverage and doesn't allow sharing findings across users (which means that when a new phishing page appears, it will appear as "new" for every single user, instead of being new for N users and then known bad for the rest of users). It also heavily reduces what kind of analysis can be done since you can't just store large datasets on every single device and/or run expensive algorithms on every single web page load on a mobile phone. - Making it open source would not help. You can't know whether the code you can see is what is deployed remotely, so in the end you just end up trusting a different assertion instead (if you can't trust a privacy policy, why could you trust that the deployment is not backdoored?). It also has some significant cons: malware / phishing / abuse detection is in essence a cat-and-mouse game, and secrecy is unfortunately a key requirement in how everyone is building anti-abuse systems across the industry (not necessarily because they want to, but because nobody knows how it could work otherwise). - You could even go all the way and have e.g. remote attestations, reproducible builds, etc. that allow proving that indeed the code running remotely is the open source code you want and can audit. This is barely doable with available technology these days, and even if someone was to do it there would maybe be 1K people on this planet able to understand why this is trustworthy. A prime example of this is looking at people in this very thread not understanding the differential privacy scheme for detecting compromised passwords. Not trusting Google is a personal opinion, and I completely respect that. But implying that there is an alternative to trust for this kind of system is IMO misleading. Using DDG or Protonmail or any other service doesn't change the fact that you have to trust someone, it's just a different someone. You might personally believe their word more than Google's word, but if e.g. DDG started logging your identity and log requests and sell that to ad companies you would have very little way of learning about it either. Disclaimer: I work for Google, not on Chrome, but I have worked on anti-abuse systems in the past.
- GoblinSlayer 7y ago
  AFAIK, Chrome was already sending everything for ad purposes (it's basically enhanced google analytics that happens to be the user agent too). It will just now send for another purpose.
Shank 7y ago
So let me get this straight. We currently consider it poor practice if passwords are stored for authentication purposes in anything but heavily salted PBKDF2, bcrypt, or sometimes scrypt. Yet it's okay to just send SHA256 unsalted hashes to web services for the purposes of verifying that those same SHA256 hashes aren't already stored? It's good that Google is encrypting these hashes, but come on, really? Surely there has to be a better way than just shipping off unsalted password hashes to a centralized location. Edit: Okay, unsalted scrypt for the password. Thanks for the clarification :)
- dannyw 7y ago
  In the infographic, they use Scrypt, I imagine with an expensive cost.
  - aawc 7y ago
    https://cs.chromium.org/chromium/src/components/password_manager/core/browser/leak_detection/encryption_utils.cc?l=60&rcl=67e916763b91bda759b9370a9a89fb3e1c8a4cde 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;
- ReverseCold 7y ago
  I'm assuming it's similar to the haveibeenpwned pwned passwords API? https://haveibeenpwned.com/API/v3#PwnedPasswords https://haveibeenpwned.com/API/v3#PwnedPasswords
  - Shank 7y ago
    It...appears to be so? The infographic states that they "send a strongly hashed and encrypted copy of your username and password to Google." They explicitly mention that the username, not the password, is sent with a 3-byte hash prefix. They make no mention of prefixing the password in the infographic. In the linked paper where they discuss the tradeoffs and take blinding into consideration. They note that the protocol is that a client calls CreateRequest(u, p) which creates a Req that is then sent explicitly to Google. It appears to me that they consider the merits of sending a hash-prefixed password, but do not make it explicitly clear that the final solution sends a hash-prefixed password. I think that they would want to explicitly say that only a partial hash is sent to Google, if that were the case?
dannyw 7y ago
I don't like the direction of "popular websites are exempt, small websites are restricted". Chrome has blocked autoplaying videos with sound for most sites except a small, hardcoded list that includes YouTube. This means that if you create a YouTube competitor today, you are playing at a technical disadvantage. Or if you're just hosting videos on your own personal website! What if Google's algorithms classify your new startup as "potential phishing", because users are re-using their own passwords on your site? How can you appeal? What recourse do you have against Big G's algorithm?
- ljm 7y ago
  I don’t like how it’ll become a new tracking datapoint. Google will learn about your passwords and of course that will be something that can be targeted through ads at some point. Even worse if you can use such targeting to figure out who is possibly vulnerable. Or maybe that’s just paranoid, but I don’t trust an advertising firm (which is all google is at heart) to not do this.
- kerng 7y ago
  That's what comes with market domintation. It's like Microsoft in late 90s. Get Firefox!
  - criley2 7y ago
    Doesn't something like 95%+ of Mozilla foundation funding come from Firefox funneling users to Google? I like Firefox but it wouldn't necessarily exist if it wasn't part of the beast
    - paulryanrogers 7y ago
      Is there a widely supported alternative not already based on Blink or Webkit?
    - skinkestek 7y ago
      Why even mention that? Using Firefox makes a difference in many ways. That said I wish Mozilla would allow other forms for income and just be honest about it (unlike Pocket which I think is a good idea destroyed by them being sneaky about it.)
hongzi 7y ago
I guess someone somewhere maintains a database of all leaked username passwords and this feature compares a credential with this database? Is that how this works?
- snug 7y ago
  Possibly, internally at google, we had something similar that would look for passwords found in the wild that you're using for internal google logins
- zemnmez 7y ago
  it's probably Have I Been Pwned. Typically this constitutes a big pile of hashes
robbya 7y ago
Does this use Troy's have I been pwned dataset?
- dhdhebsb 7y ago
  No they went and rolled their own in true Google fashion
  - dannyw 7y ago
    When you’re google size and investing engineering and cryptography resources into building security features, applied at scale to a billion* users, you probably want assurance that this list will he maintained for as long as you want it to be maintained, AND for no third parties like HIBP to enumerate over all google emails. * random number.
    - rimliu 7y ago
      Google does not have a very good record of maintaining their non-core projects.
      - dannyw 7y ago
        Publicly, yeah. But you really think google would depreciate some core internal service actively used for account security, as well as internal employee security?
hu3 7y ago
The Verge article about it: https://www.theverge.com/2019/10/2/20892854/google-password-checkup-hack-detection-now-available https://www.theverge.com/2019/10/2/20892854/google-password-...
aquova 7y ago
Reading through the article and the other sources linked, this seems to be a different dataset and implementation than the "Have I been pwned" dataset that Firefox and other password managers reference. However, I don't see any information about where their data comes from, only information about how the feature/extension works to not leak your password during verification.
- tialaramex 7y ago
  To be fair, if you have money (which Google does) you can buy a LOT of this data, every single day, forever. There are at least two distinct outfits which pay grey hats to steal data from black hats who in turn obtained it typically through cheesy script kiddie attacks on web sites or phishing. If you give them not very much money they'll "monitor" their stream of supposedly fresh stolen data (a lot of it isn't fresh because crooks are also often liars) for specific data items you tell them about. This is a bad deal, but apparently some pretty big US companies pay for that service. It's fine though because everybody reading this has unique strong passwords for every account right? Right? If you give them a LOT of money (or if you were say one of my former employers and you owned the company that does this outright) you just get the raw data. As like UTF-16 XML or CSV files with different types of quoting on each line, or whatever other crazy and inadequately documented nonsense came to mind for each such type of file delivered.
- dannyw 7y ago
  At Google’s scale, I HOPE they have an internal team dedicated to building out their own HIBP, and at the very least scanning employee credentials on a near real-time basis.
zaroth 7y ago
The cryptography behind this is done very well so that Google does not ever see even your hashed password, or know if there was a breached password detected. What Google does see is a hash-prefix of your username, to narrow down the encrypted data set of compromised credentials being returned to your Chrome instance. Here’s what happens. Your instance of Chrome hashes your username and password and encrypts that value with an ephemeral key which doesn’t leave Chrome, Kc Google gets the encrypted cred-hash and applies a second round of encryption with a key only known to Google, Kg. They return the doubly-encrypted cred-hash, and also return 256 candidates encrypted with just Kg for you to compare against, those 256 candidates are selected based on a clear-text 3 byte prefix that Chrome also sends them. When Chrome gets the results back, it decrypts the cred-hash using Kc which results in the cred-hash now being encrypted only with Kg; coincidentally this is the same exact key used to encrypt the candidates, allowing Chrome to do a simple byte-compare to see if there’s a match between your cred-hash and the encrypted breach candidates. The cool part is the encryption operation is basically communicative. You can add your layer of encryption first, send the value to Google, they add their encryption and you get the double-encrypted blob back, and then you remove your encryption to end up with a plaintext encrypted just with Google’s key, even though Google never saw the plaintext, and you never saw their key. This trick allows your browser, and only your browser, to compare your cred-hash against the breached cred-hashes while all the data you are comparing is actually encrypted with a secret key held by Google that never leaves Google’s server. The only information leak is the 3-byte hash prefix to identify the slice of the comparison set. This is definitely not nothing, but perhaps it is a reasonable trade-off.
- flashman 7y ago
  Is this an okay simplification? • I want to send my password (44) to Google but don't want them to know it's 44. So I multiply it by 37 (Kc) and send 1628. • I also tell Google that the password is between 40 and 50. (Equivalent to sending three characters of cleartext.) • Google multiplies 1628 by 78 (Kg) and sends me the result, 126984. • Google also sends me every number between 40 and 50, multiplied by 78. • I divide 126984 by Kc and get 3432. I see that 3432 is in the set of other numbers Google sent me (44x78). So I can infer that my password is in Google's set of breached passwords.
jijji 7y ago
this is a solution looking for a problem, enabled by default. i think most people dont care that homomorphic encryption is being used, they dont want their user/passwords being sent across the wire in any way shape or form, especially enabled by default.
ggm 7y ago
I like the secured hash check method. I think this is good. Most of my current life is in unique-per-site and 2FA but the burden of remembering which one(s) are using shared was more than my motivation to fix. This mechanism may take me to fixing faster.
LockAndLol 7y ago
I thought this would be about finally introducing a master password, but nope!
OliverJones 7y ago
Seems to me Troy Hunt (the independent developer of https://HaveIbeenPwned.com/ https://HaveIbeenPwned.com/) and Cloudflare's Junade Ali deserve at least a mention in the Google announcement. They're pioneers of this database of pwned passwords and the ability to look up candidate passwords securely. https://HaveIbeenPwned.com/ https://HaveIbeenPwned.com/ https://haveibeenpwned.com/Passwords https://haveibeenpwned.com/Passwords https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/#cloudflareprivacyandkanonymity https://www.troyhunt.com/ive-just-launched-pwned-passwords-v... Mr. Hunt personally paid to operate these services for quite a few years. Then he got sponsorship from 1Password to defray the server costs.
- Ajedi32 7y ago
  I suppose you could give Troy Hunt credit for popularizing the idea of anonymously checking for breached credentials, but Google doesn't use HaveIBeenPwned's database, nor is their method for checking for exposed passwords quite the same.
- dhdhebsb 7y ago
  I’m happy to see this comment. I guess I don’t really care if Google wants to succumb to NIH syndrome and build this themselves, but they should at least acknowledge the person whose idea they are repackaging.
  - greggman2 7y ago
    Why? Did Apple acknowledge all the PDAs that came before iPhone? Did Spotify acknowledge subscription music services like Rhapsody from 2003? Did Flickr mention Smugmug?
quotha 7y ago
Say no to chrome. Here is why: https://notochrome.org/why/ https://notochrome.org/why/
jdlyga 7y ago
This is similar to what Firefox has been doing lately, right?

131 points by hbcondo714 7y ago

chrome://flags/#username-first-flow is needed to see the Warn you if passwords are exposed in a data breach option in Sync and Google services

dannyw 7y ago

Some of these changes, such as realtime sending of all non-popular URLs, concern me a little. I am happy for Google to use this information for aggregated security purposes (e.g. bots analyse suspicious new pages). I am not happy with this being associated to the Google account. However, AFAIK, I have no way of knowing this, and in the absence of an explicit statement, I have to assume the worst: that Google will use this to target me ads. If any Chrome team members are reading this comment, could we get some sort of confirmation that these security features will not be used to collect more data to target me ads?

msbarnett 7y ago
> If any Chrome team members are reading this comment, could we get some sort of confirmation that these security features will not be used to collect more data to target me ads Any statement they make is open for change at a later date if management changes their mind. You’d be better off thinking about moving to a browser made by a company that whose privacy protections don’t exist in a perpetual conflict of interest with the company’s dominant revenue source
aawc 7y ago
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 :)
- tsukurimashou 7y ago
  So basically "you have our word, so trust us!"
  - delroth 7y ago
    Do you see any other alternative than trust for such a system? - Building a fully local system will not provide the same coverage and doesn't allow sharing findings across users (which means that when a new phishing page appears, it will appear as "new" for every single user, instead of being new for N users and then known bad for the rest of users). It also heavily reduces what kind of analysis can be done since you can't just store large datasets on every single device and/or run expensive algorithms on every single web page load on a mobile phone. - Making it open source would not help. You can't know whether the code you can see is what is deployed remotely, so in the end you just end up trusting a different assertion instead (if you can't trust a privacy policy, why could you trust that the deployment is not backdoored?). It also has some significant cons: malware / phishing / abuse detection is in essence a cat-and-mouse game, and secrecy is unfortunately a key requirement in how everyone is building anti-abuse systems across the industry (not necessarily because they want to, but because nobody knows how it could work otherwise). - You could even go all the way and have e.g. remote attestations, reproducible builds, etc. that allow proving that indeed the code running remotely is the open source code you want and can audit. This is barely doable with available technology these days, and even if someone was to do it there would maybe be 1K people on this planet able to understand why this is trustworthy. A prime example of this is looking at people in this very thread not understanding the differential privacy scheme for detecting compromised passwords. Not trusting Google is a personal opinion, and I completely respect that. But implying that there is an alternative to trust for this kind of system is IMO misleading. Using DDG or Protonmail or any other service doesn't change the fact that you have to trust someone, it's just a different someone. You might personally believe their word more than Google's word, but if e.g. DDG started logging your identity and log requests and sell that to ad companies you would have very little way of learning about it either. Disclaimer: I work for Google, not on Chrome, but I have worked on anti-abuse systems in the past.
GoblinSlayer 7y ago
AFAIK, Chrome was already sending everything for ad purposes (it's basically enhanced google analytics that happens to be the user agent too). It will just now send for another purpose.

Shank 7y ago

So let me get this straight. We currently consider it poor practice if passwords are stored for authentication purposes in anything but heavily salted PBKDF2, bcrypt, or sometimes scrypt. Yet it's okay to just send SHA256 unsalted hashes to web services for the purposes of verifying that those same SHA256 hashes aren't already stored? It's good that Google is encrypting these hashes, but come on, really? Surely there has to be a better way than just shipping off unsalted password hashes to a centralized location. Edit: Okay, unsalted scrypt for the password. Thanks for the clarification :)

dannyw 7y ago
In the infographic, they use Scrypt, I imagine with an expensive cost.
- aawc 7y ago
  https://cs.chromium.org/chromium/src/components/password_manager/core/browser/leak_detection/encryption_utils.cc?l=60&rcl=67e916763b91bda759b9370a9a89fb3e1c8a4cde 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;
ReverseCold 7y ago
I'm assuming it's similar to the haveibeenpwned pwned passwords API? https://haveibeenpwned.com/API/v3#PwnedPasswords https://haveibeenpwned.com/API/v3#PwnedPasswords
- Shank 7y ago
  It...appears to be so? The infographic states that they "send a strongly hashed and encrypted copy of your username and password to Google." They explicitly mention that the username, not the password, is sent with a 3-byte hash prefix. They make no mention of prefixing the password in the infographic. In the linked paper where they discuss the tradeoffs and take blinding into consideration. They note that the protocol is that a client calls CreateRequest(u, p) which creates a Req that is then sent explicitly to Google. It appears to me that they consider the merits of sending a hash-prefixed password, but do not make it explicitly clear that the final solution sends a hash-prefixed password. I think that they would want to explicitly say that only a partial hash is sent to Google, if that were the case?

dannyw 7y ago

I don't like the direction of "popular websites are exempt, small websites are restricted". Chrome has blocked autoplaying videos with sound for most sites except a small, hardcoded list that includes YouTube. This means that if you create a YouTube competitor today, you are playing at a technical disadvantage. Or if you're just hosting videos on your own personal website! What if Google's algorithms classify your new startup as "potential phishing", because users are re-using their own passwords on your site? How can you appeal? What recourse do you have against Big G's algorithm?

ljm 7y ago
I don’t like how it’ll become a new tracking datapoint. Google will learn about your passwords and of course that will be something that can be targeted through ads at some point. Even worse if you can use such targeting to figure out who is possibly vulnerable. Or maybe that’s just paranoid, but I don’t trust an advertising firm (which is all google is at heart) to not do this.
kerng 7y ago
That's what comes with market domintation. It's like Microsoft in late 90s. Get Firefox!
- criley2 7y ago
  Doesn't something like 95%+ of Mozilla foundation funding come from Firefox funneling users to Google? I like Firefox but it wouldn't necessarily exist if it wasn't part of the beast
  - paulryanrogers 7y ago
    Is there a widely supported alternative not already based on Blink or Webkit?
  - skinkestek 7y ago
    Why even mention that? Using Firefox makes a difference in many ways. That said I wish Mozilla would allow other forms for income and just be honest about it (unlike Pocket which I think is a good idea destroyed by them being sneaky about it.)

hongzi 7y ago

I guess someone somewhere maintains a database of all leaked username passwords and this feature compares a credential with this database? Is that how this works?

snug 7y ago
Possibly, internally at google, we had something similar that would look for passwords found in the wild that you're using for internal google logins
zemnmez 7y ago
it's probably Have I Been Pwned. Typically this constitutes a big pile of hashes

robbya 7y ago

Does this use Troy's have I been pwned dataset?

dhdhebsb 7y ago
No they went and rolled their own in true Google fashion
- dannyw 7y ago
  When you’re google size and investing engineering and cryptography resources into building security features, applied at scale to a billion* users, you probably want assurance that this list will he maintained for as long as you want it to be maintained, AND for no third parties like HIBP to enumerate over all google emails. * random number.
  - rimliu 7y ago
    Google does not have a very good record of maintaining their non-core projects.
    - dannyw 7y ago
      Publicly, yeah. But you really think google would depreciate some core internal service actively used for account security, as well as internal employee security?

hu3 7y ago

The Verge article about it: https://www.theverge.com/2019/10/2/20892854/google-password-checkup-hack-detection-now-available https://www.theverge.com/2019/10/2/20892854/google-password-...

aquova 7y ago

Reading through the article and the other sources linked, this seems to be a different dataset and implementation than the "Have I been pwned" dataset that Firefox and other password managers reference. However, I don't see any information about where their data comes from, only information about how the feature/extension works to not leak your password during verification.

tialaramex 7y ago
To be fair, if you have money (which Google does) you can buy a LOT of this data, every single day, forever. There are at least two distinct outfits which pay grey hats to steal data from black hats who in turn obtained it typically through cheesy script kiddie attacks on web sites or phishing. If you give them not very much money they'll "monitor" their stream of supposedly fresh stolen data (a lot of it isn't fresh because crooks are also often liars) for specific data items you tell them about. This is a bad deal, but apparently some pretty big US companies pay for that service. It's fine though because everybody reading this has unique strong passwords for every account right? Right? If you give them a LOT of money (or if you were say one of my former employers and you owned the company that does this outright) you just get the raw data. As like UTF-16 XML or CSV files with different types of quoting on each line, or whatever other crazy and inadequately documented nonsense came to mind for each such type of file delivered.
dannyw 7y ago
At Google’s scale, I HOPE they have an internal team dedicated to building out their own HIBP, and at the very least scanning employee credentials on a near real-time basis.

zaroth 7y ago

The cryptography behind this is done very well so that Google does not ever see even your hashed password, or know if there was a breached password detected. What Google does see is a hash-prefix of your username, to narrow down the encrypted data set of compromised credentials being returned to your Chrome instance. Here’s what happens. Your instance of Chrome hashes your username and password and encrypts that value with an ephemeral key which doesn’t leave Chrome, Kc Google gets the encrypted cred-hash and applies a second round of encryption with a key only known to Google, Kg. They return the doubly-encrypted cred-hash, and also return 256 candidates encrypted with just Kg for you to compare against, those 256 candidates are selected based on a clear-text 3 byte prefix that Chrome also sends them. When Chrome gets the results back, it decrypts the cred-hash using Kc which results in the cred-hash now being encrypted only with Kg; coincidentally this is the same exact key used to encrypt the candidates, allowing Chrome to do a simple byte-compare to see if there’s a match between your cred-hash and the encrypted breach candidates. The cool part is the encryption operation is basically communicative. You can add your layer of encryption first, send the value to Google, they add their encryption and you get the double-encrypted blob back, and then you remove your encryption to end up with a plaintext encrypted just with Google’s key, even though Google never saw the plaintext, and you never saw their key. This trick allows your browser, and only your browser, to compare your cred-hash against the breached cred-hashes while all the data you are comparing is actually encrypted with a secret key held by Google that never leaves Google’s server. The only information leak is the 3-byte hash prefix to identify the slice of the comparison set. This is definitely not nothing, but perhaps it is a reasonable trade-off.

flashman 7y ago
Is this an okay simplification? • I want to send my password (44) to Google but don't want them to know it's 44. So I multiply it by 37 (Kc) and send 1628. • I also tell Google that the password is between 40 and 50. (Equivalent to sending three characters of cleartext.) • Google multiplies 1628 by 78 (Kg) and sends me the result, 126984. • Google also sends me every number between 40 and 50, multiplied by 78. • I divide 126984 by Kc and get 3432. I see that 3432 is in the set of other numbers Google sent me (44x78). So I can infer that my password is in Google's set of breached passwords.

jijji 7y ago

this is a solution looking for a problem, enabled by default. i think most people dont care that homomorphic encryption is being used, they dont want their user/passwords being sent across the wire in any way shape or form, especially enabled by default.

ggm 7y ago

I like the secured hash check method. I think this is good. Most of my current life is in unique-per-site and 2FA but the burden of remembering which one(s) are using shared was more than my motivation to fix. This mechanism may take me to fixing faster.

LockAndLol 7y ago

I thought this would be about finally introducing a master password, but nope!

OliverJones 7y ago

Seems to me Troy Hunt (the independent developer of https://HaveIbeenPwned.com/ https://HaveIbeenPwned.com/) and Cloudflare's Junade Ali deserve at least a mention in the Google announcement. They're pioneers of this database of pwned passwords and the ability to look up candidate passwords securely. https://HaveIbeenPwned.com/ https://HaveIbeenPwned.com/ https://haveibeenpwned.com/Passwords https://haveibeenpwned.com/Passwords https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/#cloudflareprivacyandkanonymity https://www.troyhunt.com/ive-just-launched-pwned-passwords-v... Mr. Hunt personally paid to operate these services for quite a few years. Then he got sponsorship from 1Password to defray the server costs.

Ajedi32 7y ago
I suppose you could give Troy Hunt credit for popularizing the idea of anonymously checking for breached credentials, but Google doesn't use HaveIBeenPwned's database, nor is their method for checking for exposed passwords quite the same.
dhdhebsb 7y ago
I’m happy to see this comment. I guess I don’t really care if Google wants to succumb to NIH syndrome and build this themselves, but they should at least acknowledge the person whose idea they are repackaging.
- greggman2 7y ago
  Why? Did Apple acknowledge all the PDAs that came before iPhone? Did Spotify acknowledge subscription music services like Rhapsody from 2003? Did Flickr mention Smugmug?

quotha 7y ago

Say no to chrome. Here is why: https://notochrome.org/why/ https://notochrome.org/why/

jdlyga 7y ago

This is similar to what Firefox has been doing lately, right?