There's a big difference between leaking interesting, but ultimately not important, details about upcoming products vs. blowing the whistle on malpractice and abuse in organizations.
Companies have, alas, found creative ways to follow the letter of GDPR but not its intent. Lots have dark patterns have emerged, like leading users to first tick checkboxes, then inadvertently hitting the highlighted "accept all" button which makes their checkbox choices moot.
Best as I can tell, this scoop about WhatsApp backups in Android is not entirely correct. The author concludes:
Users were led to believe they were encrypted. They were not.
Google knew users were mislead.
But backups (apparently) were encrypted. They were not end-to-end-encrypted, because they were instead encrypted with keys that Google (rather than only your device) knows.
Now, critically, this does mean that Google could be compelled by law enforcement to decrypt such a backup. But it's not accurate to say that the data was not encrypted.
ShowView (you may know it under other brands such as VideoPlus+) was an early example of the same ideas of URL shorteners.
It was a whole thing in TV magazines of the 1990s — shows would have a (seven- digit?) code you could input, and VCRs would know how to resolve that into the recording time (and station), saving you from inputting all that manually.
For a few days, there was a kerfuffle in the .NET ecosystem.
On Wednesday, Microsoft posted a blog post about the current state of Hot
Reload in .NET 6,
which is arguably one of its tentpole features. Buried in it was a vague
paragraph that the author later clarified to me:
support for Hot Reload in
dotnet watch was not going to ship, even though
it had previously been available in the .NET 6 previews, and was working up
until Release Candidate 2. Indeed, the code was flat-out removed altogether in
a pull request.
This spawned all kinds of speculation, including the optimistic take that this feature was merely being postponed to a later release, but also the more cynical take that Microsoft wanted to keep Hot Reload as an exclusive feature for its commercial Visual Studio IDE, rather than something anyone can access with their open-source tooling, but also didn't want to communicate this. Stores include one from The Verge, who also suggest the vague wording was intentional:
Sources describe the move as a business-led decision, and it’s clear the company thought it would fly under the radar and not generate a backlash.
However, the story didn't fly under the radar, and it also apparently led to internal controversy at Microsoft.
On Saturday — probably not a typical day for anyone at Microsoft to make decisions — , Microsoft officially reversed course. A pull request that reverted the previous one, which first seemed like a provocation, was in fact ultimately merged, undoing the change.
Hard to say how believable Microsoft's explanation is:
With the runway getting short for the .NET 6 release and Visual Studio 2022, we chose to focus on bringing Hot Reload to VS2022 first. We made a mistake in executing on this plan in the way it was carried out. In our effort to scope, we inadvertently ended up deleting the source code instead of just not invoking that code path. We underestimated the number of developers that are dependent upon this capability in their environments across scenarios, and how the CLI was being used alongside Visual Studio to drive inner loop productivity by many.
Even taking that at face value, removing major features from tooling while already in the Release Candidate stage is something that should be avoided at all cost, and that should have been obvious to whoever made the call.