This article highlights something interesting... it is quite common to get at least one /64 IPv6 block from a hosting provider or ISP. Yet most of the rate-limiting and IP blocking is done for a single IP. Sounds like when dealing with IPv6, an entire block of /64 should be rate-limited or blocked.
I'd be rather surprised if IPv6 hasn't done some damage to the idea of IP blocking on the whole. It's possible, even as a residential Internet user, to request a /56 or /48 automatically with DHCPv6 Prefix Delegation. I have a /56 with Comcast. That's potentially up to 65536 /64 blocks, just from a residential user, so if you're going to attempt IP filtering for IPv6, it's got to be a lot smarter than swapping out your single-IP blocking for /64 blocking.
What if the user only get one address, how to separate the two?
Seems like a need to share if a larger block (providor) is handing out based on blocks or single addresses…
Say what? IPv6 was designed that first 64 bits are network, last 64 bit are host.
Since /64 is smallest network in IPv6 and because of that most providers hand out /64 when you ask for IPv6 public address because A) Most Rate Limiting uses /64 and B) IPv6 has so many IPs, no one cares.
Vultr has at least one /32 I was able to find (2001:19F0::/32) which if you cut that into /64 comes out ~4.2 Billion different networks or same amount of IPv4 address that exist.
ARIN will hand anyone who asks a /48 IPv6 subnet which 65,536 unique networks and getting larger prefix is not hard.
Rate limiting on /64 for IPv6 is well known and I know Google does it for other services. Sounds like this was not properly updated when they put IPv6 into play.
I had assumed that most people would block by /64. Probably safest to count distinct abusive/noisy IPv6s per /64 and block/throttle when it hits a threshold.
Ratio of abuse traffic per IPv6 from a /64 might also make a good threshold.
I did something similar way back when I was trying to find the phone number for a person, using Facebook.
When recovering a password Facebook would give you most of the digits of the phone number, so I wrote them down in a vcard file and imported it on my phone to just look at the pictures. It worked surprisingly good.
There is also a similar hole with Google profile photos and other Google apps. For example if you see a review by John Smith on Google maps, you add emails on Google Hangouts, guess a bunch of variations like johnsmith@gmail.com, smithjohn@gmail.com etc and see the profile photos to compare the match.
g has been demanding a valid phone for years, as have most other major providers. if you lose the number you sign up with, you can potentially get locked out of the account. whats your mo?
Not sure how it looks in USA, but in EU you can get a prepaid SIM card for $2 and use it forever for cases like this. You'll probably have to top it up with another $1-2 if used sparingly, but that's the price of such separation.
I’m mostly impressed that he can throw 40k requests per second at a server for a prolonged period and not somehow spike the resources enough to set off some alarms.
it is possible that it did throw an alarm but the behavior ceased soon enough afterwards that it didn't escalate to alert-level paging, or that -- even if it did -- those resources were back to normal within a few minutes that it took to open laptop, password password OTP, link-following and graph-referencing annnd oh it's already coming back down before the status update is drafted.
And 40kqps isn't really much at the scale of Focus (or most of Google's APIs) so I could easily see it going under the radar, especially each using different IP addrs and with IPv6 across /64.
The gap worth noticing here isn't monitoring, though, it's the zero rate limiting on js_disabled flow using a token borrowed from an earlier js enabled flow.
It must be a daunting chore to maintain all the legacy pages. The amount of now-years-old stuff that long-standing sites have to maintain, or choose to maintain, is shockingly high, and testing the combination of all that stuff is impossible.
If you want an example of how diverse in age these apps are, dig around in the Gmail settings panel. Eventually you will land on a popup that uses the original Gmail look and feel, from 2004.
Bug bounty program appears to be an efficient spend. For a few thousand dollars they mobilize unpaid people looking for extreme edge cases and then surface these issues. It would’ve cost way more to pay an employee to search for this.
Depends on the company. Also It can be a good way to say to management, "look, this old deprecated shit needs to be replaced because it's insecure; maintenance is a security issue"
Which is exactly why companies are aggressive about deprecating old products and services. "But why can't they just leave them running and not touch it?" Because every such service eventually becomes a security hole. The only secure code is no code.
While your argument seems to make sense on the surface, it fails in deeper inspection.
What security implications did Google Reader have? I do understand keeping older APIs and endpoints for authentication and authorization are indeed dangerous. However, if your architecture causes the mere clients of those authorization infra to be exploited, I think the problem isn't keeping the products running. You designed something inherently insecure.
Google Reader used Google accounts for authentication, so an exploit in Reader could potentially be compromising to your entire Google account. This very article gives an example of that; Looker Studio was used to reveal the name on any account, even though most accounts have likely never used Looker Studio.
Google could mitigate this by not having universally shared accounts across all services, but they're not going to do that because most users would find that inconvenient.
That describes most/all software older than a decade with no updates applied. How many libraries was Google Reader using that now have known vulns? I'm guessing it's more than zero.
This is the same logic as "just don't write bugs", if it was that easy everybody would already be doing it.
Google Reader was the last major user of the old social sharing stack at Google designed for Buzz, a product mostly remembered to these days for United States v. Google and the 2011 FTC consent decree. When people redesigned Google's social stack for G+ (e.g. all the infrastructure like Zanzibar underlying Circles, which to this day is close to state of the art!) the choice was between migrating Reader to the new tech - which nobody could justify the cost of - or keeping the old tech around for Reader when that tech was known to have had serious privacy issues leading to a major lawsuit.
If “what security implications does xyz have” was easy to answer then there would never be another hack or data breach. The simple answer is that we don’t know. And it is very expensive to find out.
I'm indicating that "it isn't easy to answer" is the root of problem there.
It means that the engineering teams were incompetent in designing a system with a "narrow waist" security infrastructure. Then the solution isn't deprecating xyz but fixing the security infrastructure. Otherwise the same issues will surface again and again in the newer products.
I was recently editing the Wikipedia page for Google Bookmarks (2005-2021). I wanted to add a logo to the page, but I was having a lot of trouble finding a high-quality copy of the logo anywhere. Eventually I figured out that Google's old URL scheme for product logos was very guessable, and they had never taken it down: https://www.google.com/intl/en-US/images/logos/bookmarks_log...
They'll probably never stop serving those old URLs because who KNOWS where they might still be in use. One of surely a million examples of weird little legacy things Google is stuck with.
I tried to guess what it might be ... I went to check moon.google.com, one of the older apps/jokes that I can recall still running. It seems that they got someone to update moon.google.com with a more recent look and feel, and dozens of moons instead of just the one.
Something that can be hard to appreciate if you haven't managed this sort of project is that it can be surprisingly hard to throw money at the problem.
If you try to hire at your regular "bar" for skill for boring work like this - people will often quit. This is one of the reasons many company's integrations are lacking despite it being a strategic interest - integration work is miserable and doesn't help your career.
Hiring below the skillbar at the same pay, is dangerous and often doesn't actually work out - if it was that easy someone more skilled probably would have fixed this a while ago.
So you try to pay more for the miserable work - but hold on, now you have to pay out of band salaries, and legal tells you that opens you to massive liabilities.
Ok - maybe you can just level them differently? No, HR will tell you that will mess with all your internal level processes - which are key to running the company. They're going to add a lot of additional overhead tracking these "fake" leveling bands and dealing with the consequences.
None of this means the problem is literally unsolvable, but it now requires a huge amount of time and effort from people near the top of the company who everyone would much rather spend their time on making the company better.
All of this to say - sure you could solve this problem, but it's actually much more complex than adding some line items to a budget.
Source: have watched many big companies try and fail for years to staff unsexy work like this.
In addition to having the money, Google also needs the incentive to spend that money on such projects. If the perceived return on capital is low (or negative!), the incentive is simply not there.
In addition to having the money, Google also needs the incentive to spend that money on such projects. If the perceived return on capital is low (or negative!), the incentive is simply not there.
Perhaps Google should Google the concepts of "customer service," "standing behind your product," and "brand reputation."
> Google the concepts of "customer service," "standing behind your product," and "brand reputation."
They're probably satisfied with their reputation with their customers, who are advertisers. The corporate IT folks who buy their G Suite products are also their customers, but overall the majority of the users of Google's software are not their customers, and Google cares about them the same way I care about how the gasoline in my car feels.
"Sure, Google retrieved the 10,285 results from my obscure query in a few milliseconds, but did you see how they stored their 12-year-old company icon image? Phhht.... I'm going with Bing!"
Google's main search page is the slowest page & UI I have found on the internet today (not accounting for bandwidth limits). Even on modern devices it lags at text entry and even rearranges characters in the text box so you have to wait 10+ seconds for it to finish loading or it will go haywire. The shopping and other pages are actually worse. So it appears you're right, $350B isn't enough money to maintain a web page in 2025.
don't forget how long the google.com redirect takes now if you dare to click a link on the SERP instead of just consuming their "AI Slop Overview" directly.
It must be a daunting chore to maintain all the legacy pages. The amount of now-years-old stuff that long-standing sites have to maintain, or choose to maintain, is shockingly high, and testing the combination of all that stuff is impossible.
One company I worked for used interns and new hires for that. One of the early tasks assigned to the intern pool was to comb the web sites for outdated information, or things that no longer conformed to the current brand book. The list then went somewhere else so the pages could be updated or deleted.
The major benefit of this was giving the new people an overview of what we do, why we do it, and a slice of the history of the products.
This is where modern "learning" falls down. You load a page, read its contents, compare with what it is supposed to be, update if outdated, move on. I know I know, that sounds like, egad, work, but that's called a job.
Your immediate dismissal of an actual task I've been assigned irks to the point of being given a snarky response.
What is the point of assigning something to a new hire, if they can't do it without another person watching the whole thing over their shoulder AND they are unlikely to benefit from this knowledge in the future (since it's a legacy page that is supposed to be deleted)?
I often assign things to new hires because I expect them to approach the question without the biases of long-time team members who have learned to overlook and normalize some bullshit. Either the new person is wrong, and I explain why, and they learned something, or they're right and the existing stuff can't be defended or justified, and I learned something.
Anytime a website is created, the information/text to used in the site is provided to the devs. You provide the same data to the QA team to ensure the Dev team did their job.
How are we seriously this obtuse? Is it deliberate?
It is shocking how many people fail at this. If you were the employee and did not have enough information to perform the task, speak up. You are not going to get in trouble or whatever other type of situation one might imagine for not asking.
> This time can also be significantly reduced through phone number hints from password reset flows in other services such as PayPal, which provide several more digits (ex. +14•••••1779)
I've never thought about this but it's extra scary. If you have the same phone number and email address with enough services and they all mask in a different order for reset hints...
If it makes you feel better (it probably won't) hundreds/thousands of services have collected your phone number over the years (for 2FA or any other reason), with or without consent, and a large chunk of them have had data breaches. So your name-email-phone number combo is 100% already available in public data dumps.
Yeah, you could get an unlisted number but you were charged for it and almost no one did because it was also how people you wanted to get in touch with you found you a lot of the time. Not that data breaches aren't bad but a lot of the breached info has been pretty routinely available for a very long time. (And, as you say, cell phone numbers are probably less routinely available than landlines were.)
I don't go out of my way to publish my cell or address but a lot of people have them.
people always trot this out, but it was very possible to have your information unlisted so it was not printed in the book. you could also use a different name. an old coworker selected to have his name listed as David King so that when found in the book it would show up as King David.
having an unlisted number wasn't uncommon. for privacy minded people, it was a simple phone call to make it unlisted, and most just did it at time of getting the number.
There are now Telegram bots to find such information. The fact that this bruteforce was revealed probably annoyed many users (like the infamous "EoG" bot).
There's services that do this automatically for a price, and they've been around for a while, for e-mail, phone numbers, and much more. Any bits (literally, bits) of information given without authorization (or plausible belief it's the intended user on the other side) will be efficiently put together from a variety of sources, as there's no shortage of incentive, and many all over the world prodding services used by billions of people worldwide. And then eventually leaked..
There used to be deep web services that provided a lot of this stuff for free back in the early 2000s or so. I think everything like that is behind at least some level of paywall now but it's not hard to get a fairly complete dossier on someone given a bit of background information and a pretty small expenditure.
There were a few stories in the past about people social engineering their way past support by asking one companies support for the last 4 of a card and then using that last 4 for a different company.
> Those security lapses are my fault, and I deeply, deeply regret them.
> But what happened to me exposes vital security flaws in several customer service systems, most notably Apple's and Amazon’s. Apple tech support gave the hackers access to my iCloud account. Amazon tech support gave them the ability to see a piece of information – a partial credit card number – that Apple used to release information. In short, the very four digits that Amazon considers unimportant enough to display in the clear on the web are precisely the same ones that Apple considers secure enough to perform identity verification. The disconnect exposes flaws in data management policies endemic to the entire technology industry, and points to a looming nightmare as we enter the era of cloud computing and connected devices.
Get personal info, then call carrier for a SIM swap, access crypto from there. Bonus: no KYC, since it's the other person's identity + you can login from 4G internet, so a trusted IP range.
I haven't been able to get into my main Google account for years because they enabled 2FA without warning and it had a phone number I no longer have. I have the username and password and I get all the emails because I also have the recovery email address. I just need to get the recovery code by SMS.
Wow, if I needed any more proof Google is a ghost ship then this is it. The $5K bounty is an insult, and the fact that they low-balled it in the first place makes them look like absolute clowns. Good on you for calling out how little of a shit Google gives about actually protecting user data.
Nobody is forced to participate in a bug bounty. If you don't like the rewards, don't do it. There's a limit to the financial viability of these programs.
Who's talking about participation? We can be appalled by their business practices as their customers (actual or potential). These are the same companies that tell us that our privacy and security is their #1 concern, and use that justification to take away our rights "for our own good", but when there's a real threat they address it with with a business-casual equivalent of "fuck off".
Neat find, though it's funny to me that a phone number is something people (including everyone on this thread I bet) have been handing out like candy their entire adult lives - to friends, stores, banks, employers, government agencies, random websites – but still expect it to remain some critical secret that no one should ever find out. A phone number is about as private as your name, and you should consider it as such.
You really trust that not a single friend of yours has ever clicked the "share contacts" button after downloading Facebook/Instagram/Snapchat/LinkedIn/TikTok...? You trust that your auto dealer or bank has not shared your details with Experian (even though you signed a piece of paper explicitly authorizing that)? You trust that your mobile operator itself isn't sharing your contact data with advertisers (go back and read your carrier agreement)? You trust that your grocery store's membership system has fool-proof IT security? Look up "recent data breaches" on Google and see how many of those companies/hospitals/government agencies you had a relationship with. I can guarantee that despite your best efforts and "trust" your phone number is accessible in a few clicks to anyone who cares to look.
1. Google shouldn't make it trivial to find out my phone number from my email. Given that even Google itself, despite having better technology available, still allows the dumpster that is SMS verification to be used as an auth "factor," they should not be enabling SIM-swapping so directly. Just knowing someone's number makes it trivial to social engineer a SIM-swap, and that can likely unlock every account most people have, and a lot of important accounts (like banks) even for security-minded people, since banks love SMS and hate everything else.
2. I shouldn't act like my phone number is a well-protected secret, or trust that anyone who calls or texts me has gotten it from a trusted source.
This is why I use things like Firefox Relay's email/phone masking for sites and services I don't trust. Would be interested if people know of free alternatives, as the phone mask requires their premium plan, and that can be a no-go for friends and family.
It helps somewhat, but unless you give a unique number to every single friend, business, bank, store, your real number will find its way into data breaches sooner or later. Heck AT&T and T-Mobile have themselves had large scale hacks in the last few years.
Uhh . . . this is not an earth-shattering take, considering they used to publish entire books with everyone's phone numbers and addresses in them, and you had to pay a fee not to have your number listed.
Are we really to the point people don't understand the concept of a phone book anymore?
You can for a small fee on some websites get my number.
Heck if you find a phone book from ~2000 where I use to live then you could just look it up in the phone book. Number portability saw to that.
Considering the number of data breaches and past history of phone numbers. To expect any sort of privacy is 'nice to have' but not going to happen. At this point it is basically security thru obscurity to expect it to be private.
Even when they had 'unlisted' numbers you could buy a book from the phone company that had it in there anyway. They even had reverse phone books you could buy. I even remember CD's from ~1998 that had the whole country. You didn't even need to keep the books.
Back when phone books were a thing, you couldn't take over a phone number from the other side of the country in the middle of the night and use it to transfer funds to a foreign bank account before you even wake up.
Social security numbers were also never supposed to be secret but as their use changed over the years, so did the way people treat them.
Yes, phone numbers are leaked everywhere. So are social security numbers and home addresses. That doesn't mean your website should be leaking that information.
Things have changed in the last decades. With all the unsolicited calls (and especially scams) one would prefer to keep their phone number as private as possible. Doesn't mean that delivery can't get it, just that it shouldn't be on the net.
Oh, so this is how vendors are going to start playing it to minimize bug bounty costs, huh? Good luck with that- the whole point of the award being a decent chunk of change is to make responsible disclosure more appealing to researchers who might otherwise go the other direction.
To anyone whose number hasn't already leaked to the B2B SaaS outbound databases: do everything you can to protect your privacy there is still hope for you, the rest of us are already lost
Maybe this specific exploit was already known for a long time to an illegitimate actor, because legit actors saw past rewards and simply gave up too early.
This article highlights something interesting... it is quite common to get at least one /64 IPv6 block from a hosting provider or ISP. Yet most of the rate-limiting and IP blocking is done for a single IP. Sounds like when dealing with IPv6, an entire block of /64 should be rate-limited or blocked.
I'd be rather surprised if IPv6 hasn't done some damage to the idea of IP blocking on the whole. It's possible, even as a residential Internet user, to request a /56 or /48 automatically with DHCPv6 Prefix Delegation. I have a /56 with Comcast. That's potentially up to 65536 /64 blocks, just from a residential user, so if you're going to attempt IP filtering for IPv6, it's got to be a lot smarter than swapping out your single-IP blocking for /64 blocking.
It is already pretty common to start with IP blocking but upgrade to blocks when the bad behavior continues.
Assuming a /64 as a starting point is an easy win and bumping it up with repeat offenders seems pretty easy in the grand scheme of things.
What if the user only get one address, how to separate the two? Seems like a need to share if a larger block (providor) is handing out based on blocks or single addresses…
Say what? IPv6 was designed that first 64 bits are network, last 64 bit are host.
Since /64 is smallest network in IPv6 and because of that most providers hand out /64 when you ask for IPv6 public address because A) Most Rate Limiting uses /64 and B) IPv6 has so many IPs, no one cares.
Vultr has at least one /32 I was able to find (2001:19F0::/32) which if you cut that into /64 comes out ~4.2 Billion different networks or same amount of IPv4 address that exist.
ARIN will hand anyone who asks a /48 IPv6 subnet which 65,536 unique networks and getting larger prefix is not hard.
> Since /64 is smallest network in IPv6
A /64 is not the smallest network in IPv6. Nothing stops you having a /112 or a /126 or whatever you like.
It is the only network size on which SLAAC works however, so it's a good choice for lan sizes.
Rate limiting on /64 for IPv6 is well known and I know Google does it for other services. Sounds like this was not properly updated when they put IPv6 into play.
I had assumed that most people would block by /64. Probably safest to count distinct abusive/noisy IPv6s per /64 and block/throttle when it hits a threshold.
Ratio of abuse traffic per IPv6 from a /64 might also make a good threshold.
Yes that does happen to be what is commonly done
I did something similar way back when I was trying to find the phone number for a person, using Facebook.
When recovering a password Facebook would give you most of the digits of the phone number, so I wrote them down in a vcard file and imported it on my phone to just look at the pictures. It worked surprisingly good.
There is also a similar hole with Google profile photos and other Google apps. For example if you see a review by John Smith on Google maps, you add emails on Google Hangouts, guess a bunch of variations like johnsmith@gmail.com, smithjohn@gmail.com etc and see the profile photos to compare the match.
This is why I don't use a real phone number with any of these services. They don't need my phone number to operate either.
g has been demanding a valid phone for years, as have most other major providers. if you lose the number you sign up with, you can potentially get locked out of the account. whats your mo?
Not sure how it looks in USA, but in EU you can get a prepaid SIM card for $2 and use it forever for cases like this. You'll probably have to top it up with another $1-2 if used sparingly, but that's the price of such separation.
I’m mostly impressed that he can throw 40k requests per second at a server for a prolonged period and not somehow spike the resources enough to set off some alarms.
it is possible that it did throw an alarm but the behavior ceased soon enough afterwards that it didn't escalate to alert-level paging, or that -- even if it did -- those resources were back to normal within a few minutes that it took to open laptop, password password OTP, link-following and graph-referencing annnd oh it's already coming back down before the status update is drafted.
And 40kqps isn't really much at the scale of Focus (or most of Google's APIs) so I could easily see it going under the radar, especially each using different IP addrs and with IPv6 across /64.
The gap worth noticing here isn't monitoring, though, it's the zero rate limiting on js_disabled flow using a token borrowed from an earlier js enabled flow.
These bug bounties pay peanuts. Sad.
They're only hanging themselves by cutting the bounties like this.
It must be a daunting chore to maintain all the legacy pages. The amount of now-years-old stuff that long-standing sites have to maintain, or choose to maintain, is shockingly high, and testing the combination of all that stuff is impossible.
If you want an example of how diverse in age these apps are, dig around in the Gmail settings panel. Eventually you will land on a popup that uses the original Gmail look and feel, from 2004.
Bug bounty program appears to be an efficient spend. For a few thousand dollars they mobilize unpaid people looking for extreme edge cases and then surface these issues. It would’ve cost way more to pay an employee to search for this.
Depends on the company. Also It can be a good way to say to management, "look, this old deprecated shit needs to be replaced because it's insecure; maintenance is a security issue"
Which is exactly why companies are aggressive about deprecating old products and services. "But why can't they just leave them running and not touch it?" Because every such service eventually becomes a security hole. The only secure code is no code.
While your argument seems to make sense on the surface, it fails in deeper inspection.
What security implications did Google Reader have? I do understand keeping older APIs and endpoints for authentication and authorization are indeed dangerous. However, if your architecture causes the mere clients of those authorization infra to be exploited, I think the problem isn't keeping the products running. You designed something inherently insecure.
Google Reader used Google accounts for authentication, so an exploit in Reader could potentially be compromising to your entire Google account. This very article gives an example of that; Looker Studio was used to reveal the name on any account, even though most accounts have likely never used Looker Studio.
Google could mitigate this by not having universally shared accounts across all services, but they're not going to do that because most users would find that inconvenient.
> You designed something inherently insecure.
That describes most/all software older than a decade with no updates applied. How many libraries was Google Reader using that now have known vulns? I'm guessing it's more than zero.
This is the same logic as "just don't write bugs", if it was that easy everybody would already be doing it.
Google Reader was the last major user of the old social sharing stack at Google designed for Buzz, a product mostly remembered to these days for United States v. Google and the 2011 FTC consent decree. When people redesigned Google's social stack for G+ (e.g. all the infrastructure like Zanzibar underlying Circles, which to this day is close to state of the art!) the choice was between migrating Reader to the new tech - which nobody could justify the cost of - or keeping the old tech around for Reader when that tech was known to have had serious privacy issues leading to a major lawsuit.
If “what security implications does xyz have” was easy to answer then there would never be another hack or data breach. The simple answer is that we don’t know. And it is very expensive to find out.
I'm indicating that "it isn't easy to answer" is the root of problem there.
It means that the engineering teams were incompetent in designing a system with a "narrow waist" security infrastructure. Then the solution isn't deprecating xyz but fixing the security infrastructure. Otherwise the same issues will surface again and again in the newer products.
Brilliant. Just write secure code. I wonder why no one thought of that before...
> It must be a daunting chore to maintain all the legacy pages
I always wonder who's the one maintaining the "poke" feature in Facebook.
I thought it was gone but I’m reading it was just hidden but re-added to the UI in 2024. That was always my favorite feature haha.
> Eventually you will land on a popup that uses the original Gmail look and feel, from 2004.
Indeed, I recently ran into a Google page that served up the old (~2013) Catull logo.
I was recently editing the Wikipedia page for Google Bookmarks (2005-2021). I wanted to add a logo to the page, but I was having a lot of trouble finding a high-quality copy of the logo anywhere. Eventually I figured out that Google's old URL scheme for product logos was very guessable, and they had never taken it down: https://www.google.com/intl/en-US/images/logos/bookmarks_log...
They'll probably never stop serving those old URLs because who KNOWS where they might still be in use. One of surely a million examples of weird little legacy things Google is stuck with.
I tried to guess what it might be ... I went to check moon.google.com, one of the older apps/jokes that I can recall still running. It seems that they got someone to update moon.google.com with a more recent look and feel, and dozens of moons instead of just the one.
And people say Google abandons products.
> It must be a daunting chore to maintain all the legacy pages.
Clearly $350 billion revenue in 2024 is not enough...
Something that can be hard to appreciate if you haven't managed this sort of project is that it can be surprisingly hard to throw money at the problem.
If you try to hire at your regular "bar" for skill for boring work like this - people will often quit. This is one of the reasons many company's integrations are lacking despite it being a strategic interest - integration work is miserable and doesn't help your career.
Hiring below the skillbar at the same pay, is dangerous and often doesn't actually work out - if it was that easy someone more skilled probably would have fixed this a while ago.
So you try to pay more for the miserable work - but hold on, now you have to pay out of band salaries, and legal tells you that opens you to massive liabilities.
Ok - maybe you can just level them differently? No, HR will tell you that will mess with all your internal level processes - which are key to running the company. They're going to add a lot of additional overhead tracking these "fake" leveling bands and dealing with the consequences.
None of this means the problem is literally unsolvable, but it now requires a huge amount of time and effort from people near the top of the company who everyone would much rather spend their time on making the company better.
All of this to say - sure you could solve this problem, but it's actually much more complex than adding some line items to a budget.
Source: have watched many big companies try and fail for years to staff unsexy work like this.
> pay out of band salaries, and legal tells you that opens you to massive liabilities
can you elaborate on this?
You can give people time to go fix things that bug them. Two systems that you use don't work together and it bothers you? Have a day a week to fix it.
isnt exactly this why most of it ends up outsorced to consultants or third parties generally?
In addition to having the money, Google also needs the incentive to spend that money on such projects. If the perceived return on capital is low (or negative!), the incentive is simply not there.
In addition to having the money, Google also needs the incentive to spend that money on such projects. If the perceived return on capital is low (or negative!), the incentive is simply not there.
Perhaps Google should Google the concepts of "customer service," "standing behind your product," and "brand reputation."
> Google the concepts of "customer service," "standing behind your product," and "brand reputation."
They're probably satisfied with their reputation with their customers, who are advertisers. The corporate IT folks who buy their G Suite products are also their customers, but overall the majority of the users of Google's software are not their customers, and Google cares about them the same way I care about how the gasoline in my car feels.
Why? Nobody is abandoning their services.
"Sure, Google retrieved the 10,285 results from my obscure query in a few milliseconds, but did you see how they stored their 12-year-old company icon image? Phhht.... I'm going with Bing!"
Google's main search page is the slowest page & UI I have found on the internet today (not accounting for bandwidth limits). Even on modern devices it lags at text entry and even rearranges characters in the text box so you have to wait 10+ seconds for it to finish loading or it will go haywire. The shopping and other pages are actually worse. So it appears you're right, $350B isn't enough money to maintain a web page in 2025.
don't forget how long the google.com redirect takes now if you dare to click a link on the SERP instead of just consuming their "AI Slop Overview" directly.
There is something wrong with your computer.
It must be a daunting chore to maintain all the legacy pages. The amount of now-years-old stuff that long-standing sites have to maintain, or choose to maintain, is shockingly high, and testing the combination of all that stuff is impossible.
One company I worked for used interns and new hires for that. One of the early tasks assigned to the intern pool was to comb the web sites for outdated information, or things that no longer conformed to the current brand book. The list then went somewhere else so the pages could be updated or deleted.
The major benefit of this was giving the new people an overview of what we do, why we do it, and a slice of the history of the products.
On the other hand they had no idea if the information was valid or wildly outdated. But better something than nothing I guess. :-)
This is where modern "learning" falls down. You load a page, read its contents, compare with what it is supposed to be, update if outdated, move on. I know I know, that sounds like, egad, work, but that's called a job.
Your immediate dismissal of an actual task I've been assigned irks to the point of being given a snarky response.
How does a new hire know "what it is supposed to be"?
The information is transferred through a method called "communication" by another human.
OP originally pitched the website clean up work providing a way to learn about the company, its products, history, etc.
If something is obvious, sure, but how is the new intern even going to know when to ask?
What is the point of assigning something to a new hire, if they can't do it without another person watching the whole thing over their shoulder AND they are unlikely to benefit from this knowledge in the future (since it's a legacy page that is supposed to be deleted)?
I often assign things to new hires because I expect them to approach the question without the biases of long-time team members who have learned to overlook and normalize some bullshit. Either the new person is wrong, and I explain why, and they learned something, or they're right and the existing stuff can't be defended or justified, and I learned something.
Anytime a website is created, the information/text to used in the site is provided to the devs. You provide the same data to the QA team to ensure the Dev team did their job.
How are we seriously this obtuse? Is it deliberate?
It is shocking how many people fail at this. If you were the employee and did not have enough information to perform the task, speak up. You are not going to get in trouble or whatever other type of situation one might imagine for not asking.
> This time can also be significantly reduced through phone number hints from password reset flows in other services such as PayPal, which provide several more digits (ex. +14•••••1779)
I've never thought about this but it's extra scary. If you have the same phone number and email address with enough services and they all mask in a different order for reset hints...
If it makes you feel better (it probably won't) hundreds/thousands of services have collected your phone number over the years (for 2FA or any other reason), with or without consent, and a large chunk of them have had data breaches. So your name-email-phone number combo is 100% already available in public data dumps.
not so long ago practically everyone's name and phone number was available publicly for free in any phone box
Not to mention that these "phone books" also included everyone's address, and married couples were usually listed together.
Yeah, you could get an unlisted number but you were charged for it and almost no one did because it was also how people you wanted to get in touch with you found you a lot of the time. Not that data breaches aren't bad but a lot of the breached info has been pretty routinely available for a very long time. (And, as you say, cell phone numbers are probably less routinely available than landlines were.)
I don't go out of my way to publish my cell or address but a lot of people have them.
people always trot this out, but it was very possible to have your information unlisted so it was not printed in the book. you could also use a different name. an old coworker selected to have his name listed as David King so that when found in the book it would show up as King David.
having an unlisted number wasn't uncommon. for privacy minded people, it was a simple phone call to make it unlisted, and most just did it at time of getting the number.
You could pretty easily opt out of that, at least in many places, although you might need to pay a small fee.
If you have used Twitter or Facebook long enough while keeping the account, public your information is.
Or Yahoo, AT&T, T-Mobile, Equifax, Capital One, Chase, eBay, Home Depot, Marriott, most health networks...
Thanks yoda
There are now Telegram bots to find such information. The fact that this bruteforce was revealed probably annoyed many users (like the infamous "EoG" bot).
There's services that do this automatically for a price, and they've been around for a while, for e-mail, phone numbers, and much more. Any bits (literally, bits) of information given without authorization (or plausible belief it's the intended user on the other side) will be efficiently put together from a variety of sources, as there's no shortage of incentive, and many all over the world prodding services used by billions of people worldwide. And then eventually leaked..
There used to be deep web services that provided a lot of this stuff for free back in the early 2000s or so. I think everything like that is behind at least some level of paywall now but it's not hard to get a fairly complete dossier on someone given a bit of background information and a pretty small expenditure.
There were a few stories in the past about people social engineering their way past support by asking one companies support for the last 4 of a card and then using that last 4 for a different company.
Here's the one I'm thinking of (time flies, doesn't it?)
https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking...
> Those security lapses are my fault, and I deeply, deeply regret them.
> But what happened to me exposes vital security flaws in several customer service systems, most notably Apple's and Amazon’s. Apple tech support gave the hackers access to my iCloud account. Amazon tech support gave them the ability to see a piece of information – a partial credit card number – that Apple used to release information. In short, the very four digits that Amazon considers unimportant enough to display in the clear on the web are precisely the same ones that Apple considers secure enough to perform identity verification. The disconnect exposes flaws in data management policies endemic to the entire technology industry, and points to a looming nightmare as we enter the era of cloud computing and connected devices.
When I was at university, I went to a talk from a security researcher who found this was the case with credit cards.
Even scarier, whoever has access to admin those services can just look up the unmasked data! Better to use unique numbers and addresses per service.
what’s the risk? your email being made public? your phone number?
Get personal info, then call carrier for a SIM swap, access crypto from there. Bonus: no KYC, since it's the other person's identity + you can login from 4G internet, so a trusted IP range.
Where can I get this though?
I haven't been able to get into my main Google account for years because they enabled 2FA without warning and it had a phone number I no longer have. I have the username and password and I get all the emails because I also have the recovery email address. I just need to get the recovery code by SMS.
What can be done to protect oneself from a SIM swap attack?
Absolutely nothing whatsoever.
If SIM Swap doesn’t work, you can always attack SS7. There’s also nothing you can do about that.
So stop using your phone number as an authentication factor. It’s trivial to pwn for any actor determined-enough.
2025: https://qbix.com/blog/2025/06/06/%e2%80%9cno-way-to-prevent-...
2023: https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says...
2021: https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says...
Which is funnier?
This is super creative and cool. Brutecat back at it again heh
Wow, if I needed any more proof Google is a ghost ship then this is it. The $5K bounty is an insult, and the fact that they low-balled it in the first place makes them look like absolute clowns. Good on you for calling out how little of a shit Google gives about actually protecting user data.
Nobody is forced to participate in a bug bounty. If you don't like the rewards, don't do it. There's a limit to the financial viability of these programs.
If the bug bounty program doesn’t pay out much, there will be plenty of less reputable actors happy to pay more
Who's talking about participation? We can be appalled by their business practices as their customers (actual or potential). These are the same companies that tell us that our privacy and security is their #1 concern, and use that justification to take away our rights "for our own good", but when there's a real threat they address it with with a business-casual equivalent of "fuck off".
> 2025-06-06 - Vendor confirms that the No-JS username recovery form has been fully deprecated
So Google's solution to this is to force JS usage for username recovery. Wow good job team /s
Logging in at all requires JS, so there's very little value to a no-JS username recovery flow.
Neat find, though it's funny to me that a phone number is something people (including everyone on this thread I bet) have been handing out like candy their entire adult lives - to friends, stores, banks, employers, government agencies, random websites – but still expect it to remain some critical secret that no one should ever find out. A phone number is about as private as your name, and you should consider it as such.
No it isn't. You give it to people you trust mostly you don't expect them to make it available publicly on the Internet.
You really trust that not a single friend of yours has ever clicked the "share contacts" button after downloading Facebook/Instagram/Snapchat/LinkedIn/TikTok...? You trust that your auto dealer or bank has not shared your details with Experian (even though you signed a piece of paper explicitly authorizing that)? You trust that your mobile operator itself isn't sharing your contact data with advertisers (go back and read your carrier agreement)? You trust that your grocery store's membership system has fool-proof IT security? Look up "recent data breaches" on Google and see how many of those companies/hospitals/government agencies you had a relationship with. I can guarantee that despite your best efforts and "trust" your phone number is accessible in a few clicks to anyone who cares to look.
I feel like both sides are right here:
1. Google shouldn't make it trivial to find out my phone number from my email. Given that even Google itself, despite having better technology available, still allows the dumpster that is SMS verification to be used as an auth "factor," they should not be enabling SIM-swapping so directly. Just knowing someone's number makes it trivial to social engineer a SIM-swap, and that can likely unlock every account most people have, and a lot of important accounts (like banks) even for security-minded people, since banks love SMS and hate everything else.
2. I shouldn't act like my phone number is a well-protected secret, or trust that anyone who calls or texts me has gotten it from a trusted source.
This is why I use things like Firefox Relay's email/phone masking for sites and services I don't trust. Would be interested if people know of free alternatives, as the phone mask requires their premium plan, and that can be a no-go for friends and family.
It helps somewhat, but unless you give a unique number to every single friend, business, bank, store, your real number will find its way into data breaches sooner or later. Heck AT&T and T-Mobile have themselves had large scale hacks in the last few years.
Uhh . . . this is not an earth-shattering take, considering they used to publish entire books with everyone's phone numbers and addresses in them, and you had to pay a fee not to have your number listed.
Are we really to the point people don't understand the concept of a phone book anymore?
Do I give it out? Not so much.
Do I expect it to be private? No.
You can for a small fee on some websites get my number.
Heck if you find a phone book from ~2000 where I use to live then you could just look it up in the phone book. Number portability saw to that.
Considering the number of data breaches and past history of phone numbers. To expect any sort of privacy is 'nice to have' but not going to happen. At this point it is basically security thru obscurity to expect it to be private.
Even when they had 'unlisted' numbers you could buy a book from the phone company that had it in there anyway. They even had reverse phone books you could buy. I even remember CD's from ~1998 that had the whole country. You didn't even need to keep the books.
Back when phone books were a thing, you couldn't take over a phone number from the other side of the country in the middle of the night and use it to transfer funds to a foreign bank account before you even wake up.
Social security numbers were also never supposed to be secret but as their use changed over the years, so did the way people treat them.
Yes, phone numbers are leaked everywhere. So are social security numbers and home addresses. That doesn't mean your website should be leaking that information.
Things have changed in the last decades. With all the unsolicited calls (and especially scams) one would prefer to keep their phone number as private as possible. Doesn't mean that delivery can't get it, just that it shouldn't be on the net.
TIL about another google product I knew nothing about. https://lookerstudio.google.com
Not a homegrown product. Looker was a pretty popular tool for data analysis and visualization and was acquired by Google a while ago.
Lookerstudio was formerly google data studio, which was homegrown at google!
You are blessed to have not been harassed by your GCP rep to attend a demo of this software.
> 2025-05-15 - Panel awards $1,337 + swag. Rationale: Exploitation likelihood is low. (lol)
Oh, so this is how vendors are going to start playing it to minimize bug bounty costs, huh? Good luck with that- the whole point of the award being a decent chunk of change is to make responsible disclosure more appealing to researchers who might otherwise go the other direction.
To anyone whose number hasn't already leaked to the B2B SaaS outbound databases: do everything you can to protect your privacy there is still hope for you, the rest of us are already lost
I think it's hard to top Equifax's breach/leak
Maybe this specific exploit was already known for a long time to an illegitimate actor, because legit actors saw past rewards and simply gave up too early.
$5000 (after complaining lol) really is a joke.