akerl_

I think a quick glance at the poster's submission history might suggest they're not experiencing the same reality as you and I.

You're correct that we disagree on that point. Flock is providing a tool; if we think the tool can be used in problematic ways, we ought to regulate users of the tool (in this case, government entities). This has the added benefit that the burdens on the government around their treatment of citizens have a higher bar for transparency and conduct than we place on private entities.

Is that the case? I see this note focusing on AI reports in the release notes, and I've poked around the OpenSSH project more generally and don't see any indication that they don't accept or welcome other AI inputs.

> No, AI assistance is NOT welcome in general.

Can you cite that? I see them specifically welcoming AI security reports; I don't see any evidence that other AI submissions are not welcome.

Is it?

Cards on the table, I am an optimist. But this feels pretty realistic: it's basically a corollary to the idea that public outrage about bad policies, bad practices, or bad tooling is problematic for these government entities. They want to avoid it. There's plenty of examples of this, even honing to just the US. Increasingly there's even examples of this specifically in the US, for police departments, for usage of Flock.

To spare you the search of his comment history, my memory is that it's roughly: the stolen car databases have tons of cars listed that weren't actually stolen, or have already been recovered, so you end up pulling over a ton of unsuspecting people just driving around.

I'm getting https://xkcd.com/810/ vibes.

If government entities get good PR for rolling out strong policies, practices, and tooling for the data they have, and that makes more of them very keen to do so... mission accomplished?

There always ends up being a real world to digital interface and it always has the potential for abuse, and thus always requires some level of monitoring and validation.

The department in this article appears to be doing just that:

> Every search run through the Flock Safety platform is automatically logged — who ran it, when, and the reason they gave for doing it. SPD said they also have other safeguards in place, including mandatory training, role-based access controls and supervisory oversight.

I think we may be agreeing?

I'm in favor of pushing for police departments (and really any governmental body with access to any kind of data) to have regulations around access to that data, access controls to restrict illegitimate access, and monitoring to detect improper access by people who do have legitimate access but don't follow the proper regulations.

I think you're correct that we don't tend to see the instances where improper usage occurs, tautologically because those entities aren't doing their homework on the above.

This feels like a weird comment on an article about how they monitored usage, identified misuse, and terminated the people involved.

There's surely plenty of entities that need better controls around usage of technology / records / etc, but this is an example of somebody having an incentive and then following through.

Or pay the news organizations making content you want to consume.

The difference is that Mullvad doesn't enable any east/west connectivity at all. If somebody guesses a user's Mullvad 16 digit number, they can use Mullvad's services as that user. If somebody gets a SmokeVPN users's 16 digit number, they can connect to that user's other devices.

How would you take any action with an abuse report and no logs? You'd get a report or subpoena or similar that listed an egress IP and a timestamp and say "We need information on this user for this charge" or "You're ordered to halt this illegal traffic", and you'd not have any way to tie that out to a specific user retroactively. There are plenty of providers who take the stance that they don't log and thus effectively cannot prevent or restrict illegal or abusive activity. I'm just not understanding how you could claim to both be logless and restrict those things.

Some questions:

> Your 16-digit account number is your login - anyone who has it can use your account, and it cannot be recovered if you lose it.

Can you explain the intent here? 16 digits seems to be nowhere near the threshold that's viable for any user authentication in 2026, especially given "Your own devices on one account can still talk to each other, like a small private LAN.".

> Acceptable use. We're logless and don't monitor what you do - but illegal or abusive use is not allowed and puts the whole shared service at risk. No spam, and zero tolerance for child sexual abuse material.

If you're not logging, how are you enforcing this? And relatedly, are you "logless" or do "traffic logs live in memory only and are scrubbed"?

> I plan to open-source the full stack as soon as I get feedback from real users, people like you

Why wait?

I think you've accidentally lumped together "people who work in tech in / around the field of information security" and "criminals".

There have been a variety of cultural elements to people doing security research / hacking on their own systems / etc.

There has never been "honor" among criminals looking to use technology to steal money or steal things that can be converted to money.

The danger of using quotation marks around things that aren't quotes is that you can wildly misstate what somebody said and readers are left to ponder if you just don't understand or if you're willfully trying to misrepresent them.

The reason a bet on this would need a date other than "ever" is because if one side of the bet can't be resolved until infinite time has passed, it just doesn't make any sense.

What is the good faith interpretation you’d suggest?

Nobody is suggesting uncritical praise.

This comment could make the same point and be even more effective if wasn't written as a snarky retort in violation of several of the guidelines of the site ( https://news.ycombinator.com/newsguidelines.html )

Interesting. I’ve only used Maven-format repos once or twice and always via somebody’s preexisting CI tooling. Is there essentially a “draft” release that you can edit repeatedly before hitting “publish”? Is that draft release visible externally as a pre-release, or only to the author?

Generally each artifact in the release is atomic, as is (and was) the case here.

You’ll never get served a partially uploaded wheel for amd64 Linux, but somebody could come back a year later and add a 2nd wheel to that release for a different architecture.

That’s exactly how individual artifacts are (and were) on PyPI. This change isn’t to artifact immutability, it’s to releases (collections of artifacts)

No?

Again, can you think of any packages managers that have a finalize step like you’re describing?

All the package managers I’m aware of do one of two things:

1. You push once with everything baked in.

2. You push as many things as you want forever.

Python releases can sometimes have many different package files (for example, because each platform can have its own wheel), which makes the first option pretty challenging.

Worth noting, because I think it’s confusing some folks on this comments page, that “file” here is “a wheel for a platform” or “a complete sdist”, not “each individual .py file in a release”

You can’t go back later and add “evil.py” to a bunch of existing release files, but you could previously go find a bunch of releases that didn’t have arm64 files, publish malicious ones, and use that to catch people using those versions on arm64 systems

Are there any package managers that have that kind of publish/finalize flow?

Every one I’m aware of works either as a one-shot (you have to submit everything in one push) or lets you keep adding new assets forever (other, obviously, than PyPI with the addition of this 14 day wall).

I wonder when Kalshi will start offering bets where one side doesn’t pay out until the end of the universe.

This is a gnarly vuln but a top tier write-up.

I'm scared of companies where SOC2 auditors are driving their security improvements. It's a bit like letting my toddler drive how I stock my pantry: surely by the end the pantry will be more full, but not really in the way I want.

What about the other Lavabit users whose data he had handed over previously, before deciding to say no?

Even setting aside that there are, in fact, many human and robot eyes staring hard at the firehose of published packages on popular registries, the whole argument feels like a false dichotomy.

If you're going to "DYOR" or whatever, having your automated dependency management on a cooldown timer seems like a snazzy way to smoothly provide a window for all your fancy dependency validation to happen.

Agreed. Whenever we end up getting non-IKEA furniture I preemptively cringe as I open the instructions.

The only time I’ve had a mistake building IKEA furniture was after opening both pieces of a combo shelf at once: there was a subtle but relevant distinction between the crossbars that was not obvious from the instructions, because ordinarily you wouldn’t have pieces from another shelf to confuse with each other.