> Someone asking you to write a test for new code

per the response: "I'm not sure what kind of test would you like me to write for this change, as it's simply adding 4 quotes"

Maybe one showing that the change doesn't make it worse. Here's the code change:

  - <a class="item muted sidebar-item-link" href=${$(this).data('href')}>
  + <a class="item muted sidebar-item-link" href="${$(this).data('href')}">

I know zero about this code path, but suppose it's expected that `${$(this).data('href')}` is already a properly quoted value, like `"https://example.com"`. Then the first line expands to:

  <a class="item muted sidebar-item-link" href="https://example.com">

and the second expands to:

  <a class="item muted sidebar-item-link" href=""https://example.com"">

which would have all kinds of room for mischief. Or suppose the template engine auto-quotes values that it injects, so the quotes aren't necessary at all, which is a pretty common approach. The point is that you don't randomly want to throw quotes into HTML or single quotes into SQL just for giggles. You have to write tests demonstrating that the existing common use cases still work after the change, even if it's simply adding 4 quotes.

I'd say also add a test that shows the HTML injection (which spurred the PR) isn't possible. Given an attacker-controlled URL of:

    foo onclick

the following shouldn't render:

    <a class="item muted sidebar-item-link" href=foo onclick>

The following should:

    <a class="item muted sidebar-item-link" href="foo onclick">

Oh, for sure! That'd end the conversation: "your change breaks the existing tests. Fix that and we'll re-consider."

I wonder why they didn't change it to use DOM APIs instead. Related comment:

https://news.ycombinator.com/item?id=47945472

Not sure. Are those APIs widely supported now? This is far outside my expertise and I don't know the current state of the art.

That totally justifies the very normal extortion like blog post in response.

> isn't hard to imagine that prosecutors

mainly because I have no idea whether it's realistic to imagine what prosecutors do. I can also easily imagine it to be illegal and wildly unrealistic behaviour for a prosecutor, in my ignorance.

> Warrants related to people getting an abortion?

The question here isn't whether abortion is illegal in some states, but about period tracking data could be used as evidence, or justify an investigation - especially data that is seemingly illegally obtained. AFAIK, illegally obtained evidence is normally not valid grounds for investigation, and might actually weaken the case based on "fruit of the poisonous tree" doctrine.

> I can also easily imagine it to be illegal and wildly unrealistic behaviour for a prosecutor

It's not [1]. There's no safeguards on information available for purchase like this. The US has very little in the way of digital privacy laws.

> especially data that is seemingly illegally obtained.

That's the thing, it's not illegal to sell private data. It's not illegal for prosecutors and cops to buy private data.

It definitely feels like it should be, so I get why you'd think that. Feels aren't the legal code.

[1] https://www.npr.org/2026/03/25/nx-s1-5752369/ice-surveillanc...

> it's not illegal to sell private data

In this case, though not covered by HIPAA, it's also not clear there was legal consent to sell this information given it was against their privacy policy.

Is there any precedent of subpoena-ing chat logs, or locale information, based on (illegally obtained information of) a missed period; or is this Handmaid's-Tale-fantasy territory?

> illegally obtained information

It's not illegal to purchase bulk data without a warrant. [1]

It should be.

So yes, there is precedent of prosecutors buying bulk data and using it in prosecutions.

In fact, that's basically a huge part of the "value add" of palantir.

[1] https://www.npr.org/2026/03/25/nx-s1-5752369/ice-surveillanc...

There's a perfectly functional voting mechanism for that..

> Until it actually _is_ cheaper, it doesn't make much sense to purchase

Once it is cheaper, there will be more demand so it will no longer be cheaper. Buying now gets current prices (though demand is still fairly high).

Would a third party 'productising' FOSS be acceptable to the FOSS community?

for example, adding support, bug fixes, corp-friendly licencing and pricing models, private code/package repos, code/package signing, etc. Providing biz ppl to be available for meetings, legal protection, PII, etc.

To foster goodwill, they could even send some of the profit back to the original maintainer, ala pikapods: https://news.ycombinator.com/item?id=31312682

I'm not suggesting productizing but if someone skimmed 0.5-5% off of some of my packages licenses and gave me the rest without me having to do anything I would be happy with that. I think the important thing would be, customers would likely expect less support so licenses should be cheaper.

People who don't want tiered licenses could definitely just mit it and walk away of course.

I do like the idea of paying back the original maintainers otherwise people could sandbag projects to fork them later.

> skimmed 0.5-5% off of some of my packages licenses

What do you mean by this? A FOSS product that has a paid packaged version?

> If none of the money is yours it means it is not your profit

Maybe they mean their org makes a lot of money the money for their parent corp, but little of that ( goes into / is reflected in ) their own orgs budget?

Is that correct? https://github.com/advisories/GHSA-r2x7-6hq9-qp7v returns a 404.

it is https://github.com/browser-use/browser-use/security/advisori..., but it will also 404 until they make it public.

A LoC based valuation probably assume humans writing code and therefor work-hour costs, I'd bet it no longer applies to generated LoCs.

But even in this example, the 2ms vs 0.2 is irrelevant - its whatever the timings are for TB-size objects.

So went not compare that case directly? We'd also want to see the performance of the assumed overheads i.e. how it scales.