71–80 of 204 posts
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.
Earlier quoted context omitted.
> 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…
Earlier quoted context omitted.
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."
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.
Earlier quoted context omitted.
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 somet…
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.
Earlier quoted context omitted.
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 somet…
> 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.
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.
Ratio of abuse traffic per IPv6 from a /64 might also make a good threshold.
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 fe…
> 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.
And people say Google abandons products.