I don't mean to support or refuse the author's main points or analysis, but you might like to know that the Chrome team is currently working towards shipping the Topics API. I have strong opinions about it but I will try not to editorialize.
My high-level understanding is that they're going to run an ML model over your browsing history (locally on your device) to build a list of "topics" that you care about. Sites you browse can use the Topics API to pull a set of these interests from the browser to show you "relevant" ads. Mozilla has taken a negative position against this standard.
No, the idea is they're abusing existing APIs for fingerprinting purposes that Firefox privacy settings disallow --canvas font rendering difference detection, detecting your GPU model, and things of that nature.
But this new API demonstrates that Google is not on the consumers side when it comes to limiting tracking/data gathering ability, as the new API is explicitly for fingerprinting.
> No, the idea is they're abusing existing APIs for fingerprinting purposes that Firefox privacy settings disallow
But that’s exactly what I’m saying: the author asserts as fact the reason Chrome worked was because it gives up more personal information but there’s no interrogation of whether that’s actually true and if true, how it’s achieved.
I’m no defender of Google I just believe we should be making arguments we’re able to actually back up.
Fingerprinting is one of the techniques used to track you across the web.
If the site is serving Google, Meta, or ads from other networks, your unique browser fingerprint is one of the tools that makes it possible to target and retarget you.
I think we’re all aware of that. Where’s the specific evidence that Chrome passed the Cloudflare DDOS protection because it gave up more private information than Firefox did?
especially since the author had to change the privacy.resistFingerprinting in Firefox to true to get it to work (meaning that it was able to bypass Cloudflare's loop by being MORE secure). But that appeared to break other non-Cloudflare sites.
I think the fingerprinting is a red herring. Yes, Chrome is less secure. But Chrome worked.
It's quite possible someone at the author's workplace updated their Cloudflare WAF settings and made things more strict, causing more checks. I'd even offer that a Firefox extension might be contributing.
But the argument that Chrome worked because it offered Cloudflare personal information is pretty out there ;)
I thought it was the opposite: that instead of fingerprinting users, web services would instead just ask the browser which topics the user is interested in and display the relevant ADs. It's an explicit design goal to reduce the dependence on fingerprinting users, otherwise why would they do it. Topics are supposed to be the locally sourced privacy preserving alternative to invasive tracking.
Whether Mozilla/Apple/others agree is a different story. The blowback has mostly been around how topics aren't perfect and the design still leaves room for abuse and therefor effectively devolves to traditional tracking: https://mozilla.github.io/ppa-docs/topics.pdf.
Browsers don’t do that today and the result is that AD networks fingerprint and track you to try and serve you more relevant content.
The argument from supporters is that this is a step away from the “fingerprint and track” status quo MO. The argument from detractors is that it doesn't quite achieve that goal.
All you need to address your concern is for access to the API to be user-configurable.
That's a distinction without a difference. In both cases, user privacy is compromised. If anything, the proposal to make "user agents" snoop on the user is even more infuriating. That sounds more like trojan horse than "user agent."
In my experience with modest specifications, you can source servers from tier 1 vendors (Dell, HPE, etc) with 5 years of support for less than a 1 year commitment for the roughly equivalent AWS or GCE instances (without prepayment).
The monthly opex to house and power and cool those servers isn't _negligible_, but if you're doing back of napkin math comparing MRCs to Cloud you can just deduct the costs from their bandwidth charges that have been marked up 10,000%
Most of the stuff that makes the distribution different from Debian Testing is tightly coupled with Google's internal infrastructure and generally uninteresting (or unuseful) to users writ large. Just run Debian!
AirMap mobile app [1] has a very comprehensive database of no fly zones, airports/airfields, and summaries of national rules. It works well in US/Canada and lots of countries in Europe too.
I find it often misses local city or park-level rules so I'd always use it in conjunction with a local jurisdiction's app (if available), as well as checking council websites etc.
Based on the pictured bezel, it looks like they've got three rows 3.5" 14TB SATA drives up front in 14th generation carriers. Best guess would be something like an R740XD2 which has 26 total drive bays per 2U.
> Nobody at Google has a need to raise a ticket with some ops group in Bengaluru to partition a Kafka topic, renew a certificate, bridge two VPCs, or any of that type of thing.
Except when your team wanted to initially onboard with GOOPS and your request sat in Buganizer for 2 weeks waiting for someone to triage. Uh oh — we're turning down this service next quarter, you will need to go start this onboarding process again with its replacement.
Or when you needed quota in a cell where your product area didn't have Flex. Maybe you can set up a VC with your PARM? Does next week work for your launch plan? Hopefully they can do something for you!
Or when your logs access request sat in GUTS for a month because both of the approvers were on vacation and no, there's not an escalation path.
Or when you needed to change a firewall rule for a project your team inherited which for some reason runs on GCE. Make sure you bring your Ariane link when you open your request. Have ISE reviewed your code? No? ISE currently have a quarter-long backlog, so we're not sure we can grant your firewall exception.
None of these examples are contrived; the weight of the operational bureaucracy is staggering. It may well be that this stuff is felt more on the SRE/Security side around production launches than on the SWE side for experimentation or iterative development, but I struggle with the idea that Google is nimble.
Registered account to reply here, because your complaints feel one sided to me.
Most of what you described i felt as well _sometimes_ for security related stuff, like dedicated machines in that one cluster or an ISE review on short notice--but security related is also somewhat out of the norm and considering that is, Google does a great job.
For "normal" services what you described does not match my experience at all. Even for medium sized infrastructure services mostly everything just works (IME).
Never had a GUTS ticket that was not answered within a business day, but obviously just n=1 sample--imo support staff is mostly amazing.
Sure, things get hairy when you go off the beaten path, but day-to-day infrastructure is not the issue. As a user of Google products I don't care as much about developer velocity as I do them shipping swiss cheese products security-wise. If I have to wait a few months more for some new feature, I'll take that trade-off.
Right, the slothful approval process for log retention and access is a feature, not a bug. It's part of the reason why Google's technical privacy story is incomparable.
Well, yes. I was provisioning a new service last week and it took me half an hour of clicking buttons in AWS. Without knowing anything about Google, I would have assumed they'd overprovison compute capacity to save developer time at least for smallish requests, since they literally run their own data centres.
They do. When GP says stuff about not having flex in a cell, that essentially means "has not provisioned any quota whatsoever in that zone". Once you do the baseline work to provision some quota, generally speaking you have a somewhat over-provisioned pool to use for whatever.
More usual is "I need to run in at least three cells in region R". Thankfully, I never faced the "you need to turn up in cell EX tomorrow" without TPM support.
Hmm, what I mean is, I open up Steam on my Linux system. Usually it remembered my login but sometimes I need to login again. If I then type my password, it says: "type the code we emailed to continue".
So if I wouldn't have access to that email account, I couldn't login and lose the Steam account, even when knowing the password.
Although, some of the methods from the link would still work, so that's solved, I guess.
Except that even if you use Steam Mobile you can't turn off email-based "self-service account recovery" in Steam. Your email account is always going to be the final key to control of your account.
Which is why my email accounts have warned me that every time a botnet cracks my Steam account password there are attempts to open what they think is my email account with the password they just cracked. My Steam account password these days is cracked scarily often, and I'm afraid my Steam account is now one of my weakest links in my online security footprint. I'm not dumb enough to use the same password for my email addresses as my Steam account, but the fact that Steam seems to be allowing password spray fast enough that machines keep cracking 50+ character passwords in days is alarming.
(ETA: Note the reason I mention 50+ is that I specifically vary the length randomly; when I don't the cracks drop to hours apart.)
I'm curious about what specific thing is signaling to you that your Steam password has been cracked. (I assume you mean brute forced?)
It's significantly more likely that you've been keylogged or phished if attackers are actually accessing your Steam account with passwords of that complexity.
I don't understand how it can be possible to brute force a 50+ character password
with 5 bits per character (and assuming random characters, which is what you mean right?), that's 300 bits of entropy, nothing in the universe could brute force that
Most of those old password-length "time to crack" estimates are based on a single machine. Many of the common ones you see today are based on the added assumption that they aren't spraying directly at a password endpoint but are instead predicated on breaking the hashes and the extra (increasingly minimal in the age of Bitcoin) cycles needed to hash/salt/pepper the passwords and/or building rainbow tables.
I believe that the password spray capabilities of today's botnets on any endpoint that returns results as fast as network messages travel should not be underestimated in a distributed enough attack. Given that not-varying the password length had a noticeable impact on time, the warnings from my email providers, and other increasingly paranoid measures I've taken [0], I have no reason to suspect that this anything but a very distributed password spray attack.
Simple GitHub searches seem to indicate that there are known password spray capable Steam endpoints that currently still leak password correctness/verification data regardless of 2FA enabled (and also leak whether or not 2FA is enabled on the account) and always falls back to email-based 2FA. (These leaks and that fall back would have me believe it's one of the Password Recovery or 2FA Recovery endpoints.) Though I've not attempted to run such gists/"utility libraries" myself to verify (I'm too lawful neutral/not a black hat whatsoever), at a surface level it seems like more than enough evidence to suggest botnets would use such things if enough people were posting "helpful password recovery tools" on GitHub that password spray accounts you tell it to.
[0] The paranoia has gotten quite "fun":
- I only ever sign in to Steam now inside the Steam client and Steam Mobile app.
- I disabled all OAuth applications on my account, no longer sign in under any web browser, and have refused to allow new applications.
- I've removed all devices except my primary gaming desktop and mobile device.
- I've removed all credit card data that I can and haven't bought or paid for anything directly in the Steam client in years.
- There's evidence that password hashes used to be leaked from a file in the Steam client's folder. (I believe that file no longer exists in recent Steam clients, at least.) For that reason, I've turned on Windows Controlled Folder Access (aka Windows Ransomware Protection) on all of my Steam folders. This has been an amazing bundle of joy~ and has basically stopped me from playing Steam games. Games are developed by children and it is amazing the number of entry point binaries a single game might have to run, how often even "offline only" games still want to run binaries they copy or bury in random places in %LocalAppData% or worse %Temp%. The whack-a-mole to enable games to run under Controlled Folder Access becomes its own very not fun minigame before you can actually start the real game. (It's also really interesting to see what some games do when they fail to get folder access they just assume they'll always have. So many permutations of "the game works but crashes at weird points" or "the game thinks it is running on a Mac for stupid reasons" or "the game thinks you intentionally want to run it without the ability to save or load saves, because that's a thing people might do?".)
My paranoia suggests my next steps are only to isolate Steam to its own entirely separate user account on the machine and/or its own unique VPN.
My basic threat modeling assumes if they were compromising anything specific outside of Steam, they'd have compromised my email accounts already.
At this point it increasingly feels like the only reason I keep Steam installed is to reset the password every time I get a Steam Guard email.
I have no stakes in defending Steam, but—you realize that if someone were cracking passwords left and right for years then the web would be full of complaints like yours? Everyone would know that it's a thing that's happening. Eternal questions would be pondered to the sound of Guard notifications, lovers would gaze at stars with faint notificationing in the background, and musicians and poets would compose songs to that tune.
Frankly a keylogger on your laptop sounds more plausible.
My belief is that this is a canary in the coal mine. We know that password systems don't work in the long run. There's been lots of reasons to get people away from passwords for day-to-day things. Some canaries are going to die sooner than others, and I have some ideas why this particular canary of mine died early. There are other complaints out there about Steam specifically of hacked accounts where passwords were "guessed" and then email accessed. Additionally, I have a pretty good idea of why, for what I think to be very dumb reasons, my account is a particularly well known to be "high value" account (going back to the parent comment way above that depending on how you value it, my Steam account is worth more than the PC I connect to it with). Steam itself is also in the weird "entertainment" place where it has bank-like features, but not quite the same pressure to have bank-like security (because it's just "games" and "hats"). The article here itself points to things likely written prior to 2012 that are still in active use today in Steam's login path (whether or not you believe age/tech debt implies "broken" most banks have upgraded their login systems likely four or five times since).
(My account is one of the oldest accounts on the platform, predating Half-Life 2's launch, and originally accessed via dial up internet. It has several now rare collections of games and at least a couple now "impossible to buy" games. Most critically to it being "well known" to have such value, it has several of the most rare/valuable "TF2 hats", which I think is incredibly dumb and that the marketplace is a huge gambling mistake, and those were known at the time when all Steam inventories were public [oh, the spam and phishing attempts that generated back when that was public and easily accessible]. My limited regard for the marketplace and limited use of it would make it somewhat obvious if I had "sold them" in the time since inventories allowed going private.)
As for a keylogger, specifically, I would go insane if I ever had to type 50+ character passwords. The keys you will log are Ctrl and V. Sure that opens up questions to clipboard logging and/or Password Manager incursion, but as I mentioned above, I have enough reason to suggest the threat isn't that sophisticated (in part because it is just "games" and "hats"), and paranoid circumvention in place already (even beyond the ones mentioned specifically in the above comment).
Also, there are plenty of reasons it might not be happening as badly elsewhere as it is happening specifically on Steam. Microsoft (and Microsoft Research) has made it very clear in recent papers that distributed password spray (where the spray is spread out over large numbers of IP addresses/countries/etc) is the number 1 issue right now in passwords, and that detection and blocking are crucial. Steam has argued in the past that such things are impossible to do at their scale. (Microsoft would argue today that their scale in Office 365/Azure AD/Microsoft Accounts has easily now dwarfed Steam's scale.) There's enough evidence today (as I already mentioned) that Steam still doesn't have those detections/blocking in place (and are relying too much on Steam Guard/2FA to keep accounts safe). (Not to get too deep into the woods of Steam criticism, but the argument may not be that it is impossible at scale but that it is impossible to prioritize it within Valve's notorious management culture.)
You could attempt contacting steam and ask if they know how many attempts have been made from different IP addresses in total for login to your account. I feel like that's really the only way to verify what you're proposing. Steam likely has logs of all the IP addresses that attempt login to whatever account.
I'm skeptical of what you're proposing because it's not hard to design a system that freezes mass random IP login attempts to an account after 'x' low number of random attempts and then only allow the past successful IP addresses to continue with a successful login. As well, as do an email verification if the password is successful but being used from a new IP address.
I have sent tickets to Steam asking for such corroboration. I've never gotten beyond a "don't worry Steam Guard seems to be working as intended" and general Tier 1 copy-paste responses.
So I figured I'd go read what's ‘password spraying’ that you mention:
> Password spray is the opposite of brute-forcing. Adversaries acquire a list of accounts and attempt to sign into all of them using a small subset of the most popular, or most likely, passwords.
Firstly, you seem to believe that password hashes provide only a small reserve of difficulty compared to the abilities of current computers. That's not so. Just read or watch any introduction on hashes: the most basic principle is that even with a huge cluster of top-of-the line hardware, it would take billions of years to guess a password of a decent length. When hash algorithms are ‘broken’, like with md5 and sha1, it's because newly found weaknesses bring down their strength by a factor of billions.
Secondly, you seem to conjecture that attempting password guesses against a network service would somehow bring that difficulty down considerably, to reachable levels. However: local hash guesses are made on GPUs or specialized FPGAs, whereas servers run on regular multi-purpose CPUs—plus, if you had a server respond to login attempts nonstop, it would spend half of the time in context switches and kernel calls. Top http frameworks in pure C reach just over a million responses per second when doing nothing but sending empty responses. You're asking that Steam dedicate a fleet of thousands of servers to facilitate cracking your password. And on top of that, the service would also need a database that likewise serves billions of requests a second.
Additionally, modern hash algorithms like bcrypt are constructed so that they take considerable and configurable time (on any hardware), so the hashing rates are on the order of tens of thousands a second or less, instead of billions and trillions. Since Steam are evidently very concerned with account security, I'd guess they take advantage of these algorithms—and since you changed the password recently, it was probably hashed with the latest used algorithm.
Besides all of the above, a service easily foils password guesses by limiting the number of attempts against an account in a time span, which is by now one of the basic prescribed measures. The whole purpose of ‘password spraying’ is to sidestep this limitation by attacking a lot of users but using most common passwords. In no way does it help with guessing a single long random password.
Lastly, while it's conceivable that Steam could have some vulnerabilities that would make cracking its accounts easier, those wouldn't be burned by attacking the same accounts over and over for months.
To sum up: the whole magnitude of the task is such that no one would solve it just to steal your trinkets, even if they could. It's time to accept that either your passwords are easily guessable, or are lifted from you in some way.
> You're asking that Steam dedicate a fleet of thousands of servers to facilitate cracking your password. And on top of that, the service would also need a database that likewise serves billions of requests a second.
No, I'm just saying that I believe Steam presumably scaled naturally (through decades of growing usage and also decades of huge scale DDoS attacks) to something like that for other reasons and are possibly missing safeguards to prevent it being misused.
Obviously, I'm making cynical assumptions and failing to give Steam the benefit of the doubt here. I'm sorry.
> Additionally, modern hash algorithms like bcrypt are constructed so that they take considerable and configurable time (on any hardware), so the hashing rates are on the order of tens of thousands a second or less, instead of billions and trillions. Since Steam are evidently very concerned with account security, I'd guess they take advantage of these algorithms—and since you changed the password recently, it was probably hashed with the latest used algorithm.
The article points to evidence that the login system possibly hasn't been updated since around 2012. Plenty of systems were still using unsalted MD5 back in 2012. It's a huge assumption that they've kept up with modern hash algorithms.
Additionally, the SteamGuard files stored in the base client directory were reported to include MD5 hashes at least as recently as 2014. (Even worse that file contained long lived tokens directly able to bypass SteamGuard.)
I hope Steam is doing better than that today, but you can forgive my pessimism/cynicism after fighting this cycle much longer than I would have liked that the conclusions I jump to remain that Steam isn't doing enough to protect account security.
> It's time to accept that either your passwords are easily guessable, or are lifted from you in some way.
I've gone through a lot of paranoia and anxiety over this. I've done a lot to eliminate suspects and shrink attack surface, and continue to do so. So far as I can tell this is specifically a Steam phenomenon, Steam is the weak link in the chain, and my other accounts seem secure accept that my email providers report failed login attempts from the same IPs mentioned in SteamGuard emails shortly after the SteamGuard timestamp.
Anyway, I've expended too many words of paranoia and cynicism in this thread. I appreciate the attempts to help.
> Steam presumably scaled naturally (through decades of growing usage and also decades of huge scale DDoS attacks) to something like that for other reasons and are possibly missing safeguards to prevent it being misused.
Just to drive the technical point home: such scale is basically just not feasible. We're talking literally thousands of servers doing nothing but md5 hashes, to vaguely bring cracking a shortish password into the realm of possibility. No one would set up such a system, any sane sysadmin would investigate the load long before it gets to such scale, and the budget would raise questions. Even if Steam uses md5, every little piece of logic around the hashing function multiplies the CPU load compared to bare hashing.
DDOS protection is done on specialized hardware, again long before the count gets to thousands of servers. You buy a box and put it in your datacenter in front of the balancer servers. In my experience, one box nicely handled load going to about two hundred application servers (iirc), likely with plenty of capacity to spare.
So you can estimate the necessary time just with http responses: 50 alphanumeric characters is 62^50 = 4.16e89 permutations, divided by 7.3 million = 5.7e82 seconds, or 1.8e75 years.
On that four-GPU box from 2016, cracking would take 3.3e71 years—which is considerably better but still doesn't quite fit in the age of the universe. So even md5 stolen from Steam Guard wouldn't help much in the case of a long password (unless some miraculous attacks were developed since 2016).
> So even md5 stolen from Steam Guard wouldn't help much in the case of a long password
(Though, with unsalted md5 or sha1, it's possible to find a shorter collision instead. But afaik it requires executing specific techniques instead of the regular algorithms, and obviously the Steam server isn't doing that, so it must be done locally with a stolen hash.)
the iap is an http proxy, so you need a way to send non-http traffic. this might require client modifications (not everything is proxy-aware), and you can't always modify the source.
some protocols are udp and latency sensitive, which doesn't work well enough tunneled
This is likely aimed at $device_manufacturer that wants to put a cellular modem into their device for remote telemetry (uploading a tiny payload every 24 hours for the lifetime on the device). There's a lot of attention in the docs towards "fleets" — they aren't expecting you to just buy one.
Aside, your second point is incorrect. The SteamDB folks have a public write up on analysis of the preload system: https://steamdb.info/blog/steam-download-system/