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.
The main cost of running a bug bounty program is developer time spent triaging submissions from all the people who just run an automated scanner against your website and submit everything it outputs.
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.
The counter-argument would be that if you consider the name on an account to be something needing security protections, then Looker Studio code should not have had the ability to access the name on an account.
Since you're the person that didn't answered with "hah you say: don't code bugs", I'll take some time to answer you.
> 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.
Guess what else uses Google Accounts? Everything that Google needs authentication for. When designing software, so much effort is put into its design, possible user stories and architecture. We put so much effort into unit tests, integration tests, regression tests whatnot.Security is no different. When designing services, considering the data flow is critical for security. An engineering organization should take into account of data that needs authentication. Those should be separate isolated services.
They can crate security islands for critical parts. Why Looker needs to get the full name from an e-mail that this person hasn't initiated a two-way contact? Or even, why it can in the first place? There is a service that does this resolution (Contacts?). Google failed to consider that limiting this kind of queries when creating this service. It has nothing to do with the functionality of Looker Studio. Now anything touches this service has problems. The old and the new products. You'll not be able to resolve these problems by deprecating Looker Studio nor deprecating Reader solved these issues.
> 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.
It is not the sharing of the authentication provider but the authorization of the kinds of queries is the problem here. It is not the problem with the age of the service Looker provides either. Yes you may be able to extract some data if the pod running Looker Studio got compromised, maybe even PII data. The dependencies can get old or can have critical bugs. However, they shouldn't be able to be exploited to extract large swaths of data due to layering and consideration of security architecture. That's why creating those security narrow-waist points are so important. They need to be given the same care of the correctness of the software and other UX goals.
Even a smaller company needs to consider these architectural details when designing integrated services. With GDPR, you should be able to delete every piece of PII. It gently forces you to do the right thing already. It is totally unacceptable that bigger companies like Google skipping this.
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.
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.
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.
There still is a standard password recovery flow with mail/capability URL that is reasonably safe and hasn't changed too much in a decade.
It is the bullshit some security advisories brought us that introduced new dangers. By sharing telephone numbers for example...
These threats are also worse than losing an account in many cases, because now the data can easily be correlated, which has proliferated through a lot of 2FA bullshit.
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.
My point was not that this job doesn't deserve attention (it does!), but that it would deserve attention from the senior personnel, not (just) the interns. I've seen too many times how important tasks, which are difficult to achieve for someone who wasn't there, are given to newcomers with little oversight and guidance. Maybe that's not how it is here, in which case - good for you!
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.
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)?
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?
Instead of snark please re-read the entire comment thread
from the beginning and you'll realize that the scenario you're imagining is completely different from what is being discussed.
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.
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 my country, there is already a (little known and not really enforced) law, that says, that for similar work there has to be a similar pay (simplifying massively). There is possibly a bunch of workarounds for this (as usual), but a good HR will not like the idea of hiring another SWE, with the same title as other SWEs, but with 2x pay.
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.
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.
That's good! Cool URLs never die. I thought they would be able to do a more effective search of their codebase to find references to their old logo in their own code.
I'm sure they could, but to what end? It'd be a bunch of work to find them all, and they could never really be sure they didn't miss one. Meanwhile the cost of just serving that old logo forever is basically nothing.
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.
There are major things at some large enterprises that are given the same level of support. Friend works on an internal link shortener app that is heavily used at their mega corporation and it gets maybe one ticket every other sprint just for upgrading node versions etc even though its monitoring is down.
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.