Elon Musk confirmed SpaceX has open sourced the Grok Build CLI this week, reports The Register, "just days after researchers caught the AI tool scooping up users' entire repositories and uploading them to company-controlled cloud storage." That discovery had "gathered so much negative attention that Elon Musk felt compelled to issue a public statement alongside SpaceX, and its technical staff, promising to delete all data that Grok Build has ever stored and give users more choice over how their data is handled." SpaceXAI's data grab was first publicized Sunday [July 12] by Cereblab, who probed Grok Build traffic and found that repos were being packaged up as Git Bundles and beamed to Google Cloud storage... [Elon Musk] said SpaceX would open-source Grok Build to sow greater trust in the product, after the codebase was audited for security vulnerabilities... ["Open-sourcing Grok Build allows anyone to support making a reliable and robust harness," SpaceX posted on X.com. "Check out our code, including the Git repo for the Grok Build CLI."] In a separate statement accompanying the open source announcement, SpaceX said it has always respected Zero Data Retention (ZDR), which was applied to enterprise customers by default, and acknowledged that data retention was enabled by default for everyone else, which has now been corrected. It said: "In response to user questions about privacy: Since launch, Grok Build has fully respected zero data retention (ZDR). All users have always had the ability to disable data upload in the CLI. When data upload was disabled, this choice was respected. In the early beta, data retention was enabled by default for non-ZDR users. Based on your feedback, we changed this. We are now going further to protect privacy. With all retained data deleted, retention default off, and an open-source harness, we are offering complete user privacy. You can also run Grok Build fully open-sourced and local-first with your own inference. "We disabled default retention for all Grok Build users starting on July 12th. Additionally, we are deleting all coding data that was previously retained, ensuring every user's preferences are respected. With these steps, Grok Build goes beyond other major coding products to protect user privacy." SpaceX also invited researchers to probe Grok Build for security issues and report them to its bug bounty program, which offers rewards ranging from $100-$20,000, depending on the severity. The article notes Simon Willison, creator of Datasette and co-creator of Django, wrote this week that the Grok Build codebase comprises 844,530 lines of Rust code. "There are still remnants of the code that used to upload everything to Google Cloud," Willison writes, "but they seem to have been disabled now." Elon Musk also posted Wednesday that "Once we have completed our review for security vulnerabilities, we will make the entire codebase of X open source, with no exceptions. Moreover, we will invite third party reviewers to examine the system that is running to confirm that the open source code is what is running."

Read more of this story at Slashdot.

New Windows LegacyHive zero-day gives hackers admin privileges



Download audio: https://dts.podtrac.com/redirect.mp3/api.spreaker.com/download/episode/73051530/securitythisweek_0242_the_hives_that_bind.mp3

How many times in your career as a software developer have you been handed a “requirement” that turned out to be difficult and costly to fulfil?

I’ve been there many times, and I imagine you have, too.

The hack I discovered a few years into my career is that one person’s “what” is almost always another person’s “how”. Software requirements very rarely describe an actual need – a user goal, for example. They’re usually a decision that someone has taken about how to address a need.

When we make decisions – the user will select their house number from a drop-down list – we constrain future possible decisions, reducing the options we have available to solve a problem we might not even be aware exists.

Visualising design decisions as a tree, we can more clearly see the relationships between decisions – how one decision is a consequence of an earlier decision.

We can traverse the tree in three directions – we can go down by asking “How?” How are we going to populate the list of house numbers? I call this direction of traversal “execution”.

We can go left or right by exploring other options – does it have to be a drop-down list? Could it be they stick a pin in a street map instead? Or just enter it in a text box? I call this direction of traversal – where we stay at the same level in the tree and evaluate other paths – “exploration”.

And we can climb back up the tree to the root decision that led us to these options by asking “Why?” Why does it need to be selected from a drop-down list? So we can be more confident it’s a real address. Okay, so why do we need to be confident it’s a real address? Because we’ll be delivering to that address.

And there, folks, is Waldo! That’s the real need.

Traversing the decision tree in this direction helps us understand not just what we’re creating, but why we’re creating it. It’s the context that’s so often missing in the design process.

Why is “Why?” such a powerful question?

Remember that in a decision tree, each decision constrains possible future decisions. Each time we commit to a specific branch, we lose significant optionality – we get fewer execution choices to work with and a smaller potential solution space. This reduces our chances of solving a problem with limited time and resources.

When we take a step back to an earlier root decision, optionality opens up again. I’ve lost count of the times when a deadline was looming and the path we’d chosen just wasn’t going to get us there in time, and I asked the question “What is it we’re trying to achieve, again?” 99% of the time, it turned out the requirement wasn’t the real requirement – it was a decision. And 99% of those times, it turned out there were quicker and cheaper options – often not involving writing any code at all.

In fact, this happened so often in the early part of my contracting career that I eventually adopted a policy of questioning every requirement in a specification, and ultimately rejecting any specification the team hadn’t been directly involved in agreeing.

This is why I refer to software requirements specifications these days as “handcuffs”.

And we must not forget that, no matter how clear the rationale for a design decision is, it is at best an educated guess at what will solve the root problem. Only reality can answer whether it actually does.

This brings me back to the topic of feedback latency which builds on the same decision tree model. How far down a branch do we go before we get meaningful feedback on the root decision?

It turns out that the practice of creating and releasing software in thin slices, getting continuous feedback from the real world about which decisions were the good decisions early and often, is also highly compatible with preserving optionality for longer.

Big Design Up-Front could be characterised as having very high feedback latency – we spend a lot more time climbing the wrong trees. It can also be characterised as closing off alternative branches too early – long before we’ve got anything real to go on – and collapsing optionality in the absence of any evidence that we’re on the right execution path.

In Extreme Programming, we delay committing to decisions – especially decisions that will be hard to change – as long as we reasonably can. This helps us to keep things as simple as we can (Y.A.G.N.I.), and it also helps to keep our options open for longer.

Another way we can keep our options open is by hiding the “how” behind some kind of abstraction. An interface, for example, describe what a module should do, but we can defer and/or substitute the choice about how it does it – the execution paths below it in the decision tree – more easily.

The outside-in test-driven design process described in Steve Freeman and Nat Pryce’s highly-recommended book Growing Object-Oriented Software Guided By Tests uses mock objects to define abstractions (contracts) before committing to any implementation.

This keeps options open for longer, and also has the benefit of allowing us to solve one problem at a time. It also provides a flex point in the architecture that keeps our options open in the future, should needs change. Checking out the basket charges the customer’s credit card. How? We’ll get to that later, but we know what the basket needs to tell the payment processor to do.

This was the original intent of mock objects – a tool for defining contracts for object interactions without committing to implementations. Mocks are a design tool, not a testing tool.

One final thought: software developers tend to be very “how”-oriented (we like solving problems), but – like the myth that pigs can’t look up – it’s also a myth that we can’t look back up a decision tree and understand the real needs that are driving the design. It’s very much in ours and our customers’ interests to do so.

The arrow of time doesn’t only run in one direction.

Choosing between TCP and UDP is crucial for data transport. TCP ensures reliability and ordered delivery, making it ideal for critical applications, while UDP prioritizes speed and low latency, suited for real-time scenarios.

Originally posted in Obics.io I moved from Windows to Linux 1 month ago, after using Windows for the last 30 years (and developing software 15 years). It wasn’t easy to leave my comfort zone, but I got so frustrated with Windows performance that I couldn’t take it anymore. As I was able to do more tasks in parallel with AI coding agents, the performance of the system degraded. I started having frequent crashes, a constant huge memory consumption, and overall slowness.

Learn how to combine passkeys with Vonage Silent Authentication to secure signup, recovery, and account verification.