...who for some reason deserve to be protected from automation more than fucking literally everybody else, apparently.

This sort of attack is inevitable when you have open-access software repositories. If anybody can upload a package, that implies any bad guy can upload a package. So:

• Ask yourself if you really need a package for this, or is it simple or straightforward enough you can code it yourself and avoid the dependency and the associated supply-chain risks.
• Do your research. Don't just grab the first package that looks like it fits your needs. Review all of the results, then look at who published them and look them up on the web. Look at their web site. Look at what other packages they've published. Look at how active they are aside from the package you're looking at. Toss any that have red flags like no history aside from this package.
• Validate your packages. Authors often sign packages. If they do, get their keys and enable validation so you only accept packages signed by the author you know. That way if a package gets hijacked it'll fail the signature check.

One would think the third-party doctrine would pretty much scuttle OpenAI's objections.

If a store does this and they give you any guff at all about being let out you pull out your phone, call 911 and report a kidnapping in progress. Because that's what it is. The store's within it's rights to deny you entrance, but to deny you exit they have to have reason to believe you've broken the law in some way. You haven't. Their policy isn't the law. Let the authorities explain this to them.

I think the backdoor isn't Chinese in the sense of the government or the country, it's more of a vendor problem globally. Vendors do this to keep control of what they sell, to be able to force customers to buy support subscriptions on pain of having the product stop working if they don't. Vendors from countries other than China do this just as often. We should be worried about what all vendors do, not just Chinese vendors.

Bypass the Senate. The law regarding DST requires Federal law to make DST permanent, but doesn't require any special law for states to eliminate DST entirely and go on Standard Time year-round. Cotton can't do a thing about that, and maybe he'll develop some sense when the choice is between Standard and DST year-round rather than DST year-round vs. only in the summer.

I don't think genAI is a threat to the open-source ecosystem as far as it's copying of FOSS code goes. The people looking for that kind of code wouldn't be looking for the source code for FOSS projects anyway. The threat, if any, will be from genAI code being contributed back to FOSS projects. Aside from provenance issues, it tends to be low-quality and buggy and will just increase the workload for FOSS maintainers without offering anything useful. Witness genAI offering a suggestion to a bugfix submission: https://social.hails.org/@hail...

Thanks to Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021), even relatively small pieces of code (such as function declarations in header files) must be considered copyrightable. It's possible they aren't, but the appeals in that case resulted in rulings that they were copyrightable, and the SC decision in favor of Google turned on fair use, not whether the code in question was copyrighted or not, so it can't really be used to stand for the proposition that the appeals courts got it wrong.

With AI-generated snippets, it's going to turn on whether the snippet is close enough to identical to the original code to be considered a copy and whether that copying could constitute fair use. I think any lawyer would tell you that's not the kind of thing you want to bet on in court. If the code's simple enough that it clearly wouldn't be a copyright violation even if it were nigh-identical, it's simple enough you're better off not using AI and having your engineers write the code themselves, and if it's significant enough that that's not feasible then it's almost certainly copyrightable and the fair-use argument is going to be an uphill battle for something that significant. Either way, you're better off avoiding anything where you don't know the provenance of every line of your code.

AI doesn't "siphon up and launder" code any more than your brain does. Both *can* memorize (which is why sometimes comedians can accidentally steal a joke), but both are also learning from patterns.

AI isn't going to make people stop contributing to open source.

Source addresses of the attack are known. The ISPs know which customer was using that address at that time, and dealing with the customer is their problem not the attack target's. If they don't deal with it, they get to deal with lots of angry customers who've suddenly lost connectivity to the majority of the Internet because entire blocks of the ISP's address space are being blocked by Cloudflare et. al..

Time for a law that says that if the manufacturer removes any functionality from a product that was present when it was purchased or originally offered for purchase, any owner of that product is automatically entitled to a refund of 100% of the original purchase price (if they can provide a receipt) or 100% of the initial manufacturer's recommended price (if no receipt is available) upon demand. The manufacturer may, if the owner can't present a receipt, require the owner to provide the serial number, photograph of the serial number and/or photograph of the entire item to claim the refund, and may require the owner to return the item at the manufacturer's expense.

It's time to go after the source of the problem: the compromised devices. Identify them and force the ISPs that serve them to block outgoing traffic from that customer, on pain of having entire netblocks blocked by Cloudflare etc..

At a minimum repositories should require that all packages be signed by the maintainer(s), with signatures verified upon download by keys not fetched from the repository itself. The tech is already there using GPG. The main thing that should be added is that the repository should sign maintainer GPG keys after having verified that that maintainer owns the packages signed by his key, that way clients can check for that as well and avoid packages signed by keys that don't own the package. Best practice here would be for maintainers to use a separate key for signing packages.

Requiring 2FA and such would be recommended, but with signature checking even if an attacker compromised the maintainer's account on the repository they still couldn't upload a package with the correct signature.

This won't solve the problem of maintainer systems being compromised, but that's a very non-trivial problem to solve. Nor would it solve the problem of a maintainer giving legitimate privileges to upload official packages to a party they don't realize is untrustworthy, but again that's non-trivial to solve. Neither of those problems is something there's a technical solution for, I'm afraid. And of course it creates a problem with key rollover and succession, getting clients to use the new keys at the correct point, but that merely requires some effort to get the protocol right.

This is one of those "practitioner skilled in the art" kind of things. We've had SQL and UML for ages that use and visualize parent-child relationships. Once you know them, this is an obvious application for making queries about the relationships. Given how ubiquitous trees of various kinds are, I doubt their specific implementation is particularly novel.

Most of the things people complain about involve third-party cookies of one sort or another. Very few people would object to most first-party cookies or the reasons they're used. After all, if you visit a site obviously they know everything you do there. So, my ideal rules:

1. No consent required for cookies when being set by or sent to the site you're visiting. Site in this case being the 2nd-level or 3rd-level domain of the host you're visiting (depending on the TLD).
2. As an exception to the previous rule, consent required for any cookie being sent to a server for the site you're visiting that is controlled or operated by any entity other than the entity that controls and operates the site. This is to close the loophole of third parties requiring a hostname in the site's domain pointing at their servers to conceal the fact that they're third-party hosts.
3. Consent required for cookies being set by or sent to any site other than the one you're visiting.
4. The operator of the server or domain setting or sending cookies is responsible for obtaining consent, not the site being visited. If consent has not been affirmatively obtained, it must be assumed to have been denied.
5. Any server or domain that requires consent be obtained MUST NOT present any content that obscures content on the site being visited, that materially negatively impacts viewing of the site being visited, or that materially negatively impacts use or operation of the site being visited. No pop-ups, no overlays, no blocking or obscuring content on the site until the user consents.
6. 1. That should let users simply reject all third-party cookies in their browser and be done with it.