csande17

Big embarrassing network-exploitable bugs in major open-source projects happen sometimes, and network-scanning attack botnets have been around forever. Small shady CAs mess things up sometimes. People upload malware to PyPI and NPM all the time, and "move fast and break things" software-deployment startups get breached all the time, to the point where it doesn't even really feel like news to me when those things happen again.

It's unfortunate that a few of those events all happened at around the same time. But, like, even if that's not a coincidence and these events are actually happening more frequently, you should have been preparing for them anyway!

That extension exposes a public API that allows setting any search radius up to 10 km ( https://en.wikipedia.org/w/api.php?action=help&modules=query... ), so presumably there's no barrier to making the search radius smaller, but maybe there'd be performance issues if you allowed making it larger.

(NearbyPages just embeds a Vue app into the page that makes a client-side fetch() call to invoke that API with a hard-coded radius.)

These days there is a package that builds the kernel for you, but it relies on the "savedconfig" system to just save/load the entire kernel config file instead of using USE flags. So you still have to root around in the config menu yourself to change things.

In my experience Linux is very good at correctly declaring dependencies between options, and still working with options disabled, so this isn't as much of a problem as it seems to be for Chromium.

(I mean, this particular library seems to be one of those AI-generated ghost town projects that has stuff like a big fancy GOVERNANCE.md but no actual user or contributor community, but that's the strongest reason I've heard to use things like Tailwind.)

You can't do that with Rust because "Rust's type system" is literally just the vague concept of "a type system that is safe". The implementation of this ideal in rustc can have flaws, but Rust itself cannot, because Rust itself has no flaws by definition.

Rust cannot fail, it can only be failed.

To prevent cases where users can upload an excessive amount of data on March 31 that they then can't afford the April bill for, AWS should also maintain a "next month's balance" limit that gets handled in the same way.

It would take a bit more work to correctly handle things like ephemeral data and tiered storage classes, but it's not insurmountable.

You could apply the same kind of billing to most other long-lived resources, including VMs that run business-critical services.

But then Google changed the default voice assistant on Android to use Gemini. So instead of relying on hard-coded "if the user says this exact phrase, do the thing we said would happen" conditions, people now have to hope the model's smart enough to figure what "turn on my lights" means from first principles every single time.

It's still possible to back up an iPhone to a jailbroken computer, using roughly the same iTunes sync system that was available on iPods. For now.

> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.

> No replacement opt-out; unavailable Landlock remains advisory.

With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.

If you ask "did you build this using Codex or Claude", it removes most of the wiggle room. And it's worded pretty neutrally, so it will often get vibe-coders who aren't technically using either of those tools to say something like, "Actually, I've built a custom harness for DeepSeek..." instead of an outright denial.

Apps get to choose what permissions are needed to access their intents, so under Android's security model, really it's Chrome's fault (or whatever browser the user has installed) for exposing an intent that allows apps that don't have the INTERNET permission to exfoltrate data.

Similarly, apps are also allowed to collude to share data with each other if they want; that's how stuff like Google Play Services works.

> Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.

(And because this happens during the stable release process, there are a lot of 24-hour periods where they issue a ton of CVEs for all the minor bugs fixed in the release.)

I personally did get the vibe that you were being evasive, just because the things you were saying didn't quite match what people were asking about, in a way that felt kind of like a corporate legally-not-a-denial denial. It's like, "Hey, has Contoso Apartments hidden a camera in my bathroom?" "Contoso Apartments is committed to your privacy and safety. We have strict controls in place to ensure that our maintenance staff cannot make a copy of your key without notifying you. To the best of my knowledge, we do not have any company initiative that involves opening envelopes addressed to you." Like it's theoretically reassuring for the company to commit to those things, but the fact that they can't directly answer the original question is disconcerting.

Ultimately there's probably not a whole lot you can do about this. Like realistically if Microsoft is doing this, they've probably constructed it in a way where not many people know and/or they can plausibly deny it. So it comes down to (a) Microsoft denies doing it, but isn't making the broadest legally binding commitment possible, (b) does the reader believe Microsoft and OpenAI are trustworthy with respect to privacy and intellectual property issues or not.

I've been in this kind of situation before, and it can be frustrating when people don't believe that you're in a good, isolated department of the company and you're committed to upholding ethical standards. I guess that's why big companies pay the big bucks :)

But if Microsoft really was selling private repo content to OpenAI, it probably wouldn't go through those access controls. It'd be an executive-level decision with enough force to plow through all the red tape, and it'd be implemented as a data pipeline or similar automated process that wouldn't trigger the same kind of notification as, like, a Trust and Safety employee taking manual action.

Probably the better evidence here is in GitHub's ToS where they say in pretty strong/binding terms that they aren't doing this: https://docs.github.com/en/site-policy/github-terms/github-t... . If they are secretly selling your data to OpenAI they haven't left themselves a ton of wiggle room if people ever found out.

(Probably the biggest loophole they could use is to send private repo content to an OpenAI service for scanning/safety purposes. The ToS allows this and they're almost certainly doing it with other services like PhotoDNA. Then OpenAI can just violate whatever agreement they have not to store the data sent to that service.)

I think this is the exact point that the article was getting at in the last section. It is okay to not be very good at software engineering or people management! It is useful to know these things if you want to understand why the Bun project made specific technical decisions, but they don't make the people involved "bad people" in a more nebulous moral sense.

The lead developer of Zig is discussing these factors because the main technical decision was moving away from Zig.