I used to use FTP in Windows Explorer, Internet Explorer, and Mozilla Firefox about 15 to 30 years ago. It was convenient at the time. FTP was unceremoniously killed in mainstream browsers too. You can still use it through other software and raw libraries. Later, I read the protocol specification and realized it is badly designed - though at least simple and concise compared to the sprawling number of features in HTTP.
The comment you replied to was: "The only good products Google has ever built in-house are [...]"
I don't have enough information to judge how much of Chrome was original work and how much was pre-existing work. Though I guess by now, after nearly 20 years, Chrome's codebase looks absolutely nothing like KHTML.
I see some irony here. For a period of time, Google chose not to include JPEG XL in Chrome because vulnerabilities in the library could compromise the software - a legitimate concern. Yet, Google is the author of the Brotli data compression format a decade before the JPEG XL drama, and was happy to use it in Chrome and encourage others to use the library, despite the fact that it also increases the attack surface.
Things like Rust in Chromium weren’t even being talked about back when Brotli was introduced to Chromium.
I think Chromium as a project would be happier if they had less unsafe code in general, and holding new dependencies (especially those like media formats, which have a long history of security issues) to that standard doesn’t seem particularly surprising.
There’s always going to be trade-offs: how much benefit does this provide (users, developers) compared with how much risk does it incur (safe/unsafe code, quantity of code you’re now on the line for the security of).
(And that’s taking that reason to not support JPEG XL at face value, ignoring any debate about it.)
From a browser point-of-view, the real questions are about data size (if you can get the wireless interface back to a low power state, you’re winning on power benchmarks), about decompression cost (again, power benchmarks), and decompression time (for performance benchmarks and user-perceived performance).
Storage and compression compute costs aren’t really relevant — only insofar as if there’s very little adoption, the security risk of exposing the code is there but isn’t providing user benefit.
This is getting real close to "yet you participate in society, curious." Yes, Google chose not to use some software and chose to use other software. It's not ironic to decline to use some software because it increases the attack surface, and then find out that it's not enough and the software you did choose to use is vulnerable. It's just unfortunate.
My reading of the critique is that the criteria was unevenly applied. Decompression vulnerabilities exist in both libraries. They rejected one on the basis that it expanded the attack surface area, but accepted the other, despite similar claims applying to it as well.
It's pretty far from the "yet you participate in society" anti-pattern.
The server is getting overloaded, so here's the text for reference:
Steal my Bitcoin
0.65 hours without a successful hack
There is a bitcoin key hidden on this server worth about $502.
It is accessible to the PHP user account through the print-flag binary.
This PHP version was selected from before the PHP2SHELL CVEs were released.
First person to get the wallet wins. If you don’t need the money, consider donating it to those who do: givewell.org.
All traffic is logged. This is a known vulnerable machine, so we cannot guarantee privacy. Other attackers may access or monitor activity and data beyond our control. Do not submit anything you want to keep private.
Challenge wallet
Explorer ↗
bc1qlnu5…t3cxqy
0.00625104 BTC
≈ $502.35 USD
stealmybitcoin.com · Terms of participation
How so? Anyone can do this, if it fits their agenda. Especially useful way to use your stolen/extorted BTC. If I had an exploit for this right before or right after embargo was lifted, and I could do that again, then it is in my interest to have cybersecurity people get more lax. For example, any secret agency in the world could be behind such a psyop. But also any criminal group or company invested in this field. You seen recently (Shinyhunters) how people can wear double hats.
Another trick could be to increase hype. Original author could've done that, for example because they always planned to burn 1k USD in BTC on this for whatever reason.
And then there's the trick to hope others follow, after which he, ehh, magically takes the money. That's a bit akin to ICO scams.
Can I prove any of the above theories? No. But the author cannot prove their motives are sincere either.
I sometimes posted a donation link or joke site and got surprisingly large donations.
Made my tax audit rather painful.... "I posted a joke on the internet about binary numbers not being worth anything and someone gave me $10k of bitcoin that I'm now declaring - is it income for the work of writing the joke, or a gift? The sender likely didn't know who I was, and was likely overseas but I cannot prove who they were or which country they were in".
Wouldn't it be the same as what the tax authorities expect of street buskers, where something was done publicly (just here on the internet) and as a result randoms gave you money/cash (here again the digital equivalent) after the fact with no strings attached?
Great way to inject some price information into the “AI automates exploits at scale” narrative. “AI can now chain complex exploits, it’s point-and-click pwnage, you say? Over or under $500 a pop?”
I'm seeing a few comments that say $500 isn't enough, and its not worth it for them to try to hack it.
But if it costs fewer than $500 of tokens in an AI, then it seems like it is? I thought a lot of the claim people are making is that you dont actually need to hack anything you just ask an AI and it does it. The exploitable bug is public and documented. All the pieces are theoretically there, and there are repeated claims that AI is trivializing exploits and its super easy to hack things now.
If that were true, and someone can hack the server for less than $500 of tokens, its an easy profit.
It’s not very much information, I agree. Even such scant information, however, is a significant and refreshing improvement on the current state of the narrative. Kudos to the servermaster, I say.
For $500 he can look in the logs and find all manner of new exploits, or new deviations of the existing ones, he can then sell for thousands. Clever business model lol
These projects would be more interesting and ethical if the current and historical logs were instantly put up somewhere public in real-time for anyone to observe.
Regardless, I'm guessing the smart hackers aren't going to bother.
> The non default php settings he set break the exploit.
If that's the case, then there is a mitigation for all vulnerable versions, but the team that released php2shell said there is absolutely no complete mitigation and every PHP version between 5.4 and these latest updates is absolutely vulnerable. So which is true?
> About eMudhra / With over 17 years of expertise, eMudhra is a global provider of digital identity, trust, and security solutions, enabling secure digital transformation for banks and financial institutions (BFSI), enterprises, and governments across more than 35 countries worldwide. Its product suite spans CertiNext
I was hoping the statement at the bottom would be written in past tense: eMudhra was a global provider of digital identity ... had temporarily enabled secure digital transformation ... Its product suite spanned CertiNext...
You can't do that because an RSA private key contains two numbers - the modulus and the exponent. Even better, an RSA private key usually has the modulus stored as its two factors rather than their product.
Also note that using small numbers like 65537 for RSA public exponents is common practice.
> Bruh, you just literally went ——— BEGIN PUBLIC KEY ——— 4 ——— END PUBLIC KEY ———
No, their private key is 4. Moreover, you wouldn't see the literal number 4 because the PEM key file would have the cryptographic sections encoded in base64.
reply