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.
Clearly $350 billion revenue in 2024 is not enough...
Perhaps Google should Google the concepts of "customer service," "standing behind your product," and "brand reputation."
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.
can you elaborate on this?
I always wonder who's the one maintaining the "poke" feature in Facebook.
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.
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.
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 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.
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.
Your immediate dismissal of an actual task I've been assigned irks to the point of being given a snarky response.
Indeed, I recently ran into a Google page that served up the old (~2013) Catull logo.
And people say Google abandons products.
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'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 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.
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.
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.
I don't go out of my way to publish my cell or address but a lot of people have them.
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.
$5000 (after complaining lol) really is a joke.
Are we really to the point people don't understand the concept of a phone book anymore?
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.
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.
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.
Ratio of abuse traffic per IPv6 from a /64 might also make a good threshold.
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.
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.
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.
msdrigg•3h ago
So Google's solution to this is to force JS usage for username recovery. Wow good job team /s
jsnell•2h ago