I get the spirit of this project is to increase safety, but if the above social contract actually becomes prevalent this seems like a net loss. It establishes an exploitable path for supply-chain attacks: attacker "proves" themselves trustworthy on any project by behaving in an entirely helpful and innocuous manner, then leverages that to gain trust in target project (possibly through multiple intermediary projects). If this sort of cross project trust ever becomes automated then any account that was ever trusted anywhere suddenly becomes an attractive target for account takeover attacks. I think a pure distrust list would be a much safer place to start.

CORS today is just an annoying artifact of a poorly conceived idea about domain names somehow being a meaningful security boundary. It never amounted to anything more than a server asking the client not to do something with no mechanism to force the client to comply and no direct way for the server to tell if the client is complying. It has never offered any security value, workarounds were developed before it even became a settled standard. It's so much more likely to prevent legitimate use than protect against illegitimate use that browsers typically include a way to turn it off.

With CSRF the idea is that the server wants to be able verify that a request from a client is one it invited (most commonly that a POST comes from a form that it served in an earlier GET). It's entirely up to the server to design the mechanism for that, the client typically has no idea its happening (it's just feeding back to the server on a later request something it got from the server on a previous request). Also notable is despite the "cross-site" part of the name it doesn't really have any direct relationship to "sites" or domains, servers can and do use the exact same mechanisms to detect or prevent issues like accidentally submitting the same form twice.

This is whiny and just wrong. Best behavior by default is always the right choice for an SDK. Libraries/tools/clients/SDKs break backwards compatibility all the time. That's exactly what semver version pinning is for, and that's a fundamental feature of every dependency management system.

AWS handled this exactly right IMO. Change was introduced in Python SDK version 1.36.0 which clearly indicatesbreaking API changes, and their changelog also explicitly mentions this new default

   api-change:``s3``: [``botocore``] This change enhances integrity protections for new SDK requests to S3. S3 SDKs now support the CRC64NVME checksum algorithm, full object checksums for multipart S3 objects, and new default integrity protections for S3 requests.

"U.S.-based Instant Brands Holdings Inc. (formerly known as Corelle Brands Holdings Inc.) is issuing a new $450 million first-lien term loan. The company will use the proceeds, along with $100 million in cash, to refinance its existing $200 million term loan due 2024, $100 million seller notes, and fund a $245 million dividend to shareholders."

If you subtract out the refinanced debt the new owners walked away with $100M in company cash and another $150M in borrowed money.

If we sell our products for less on channels outside Amazon and Amazon detects this, our products will not appear as prominently in search and, if you do find them, they will lose their prime check mark and with that, their sales.

Everything else seems pretty straightforward facts or opinions, but that bit attributes some significant behavior to Amazon without providing any sort of evidence that it happens.

From a 2021 article[1] about packages used to deliver malware "we have alerted PyPI about the existence of the malicious packages which promptly removed them. Based on data from pepy.tech, we estimate the malicious packages were downloaded about 30,000 times."

For comparison yt-dlp has tens of millions of total downloads and gets downloaded over 70,000 times every day [2]

[1] https://jfrog.com/blog/malicious-pypi-packages-stealing-cred...

[2] https://pepy.tech/project/yt-dlp