Honestly that sounds more like a hardware issue than software

Oh come on, just accept that the wording of the headline is wrong and misleading.

If a Country is named in the headline like this, it is always implied to be the state/government. No other interpretation makes sense, the society is surely not using ai to censor.

Even if we consider that not to be the case, just for the sake of the argument, you still can not say “a few people at this project” = “Germany (Society)”. I heavily caution you to not go down the generalization route of “a select group” = “german society”. You ought to think about what that assertion would mean in the context of hamas and palastinians.

Also TU is a public university, so it’s still an emanation of the state, state-funded and state-controlled.

While universities get funding from the state, they are mostly free to research what they choose. On the projects website is also no sign of direct funding by the state. You are free to criticize the research, but what you are implying is that the state should censor the direction of research because you don‘t like it, which is quite ironic.

This is a clickbait headline. The headline implies that the German State is using AI to censor. It is not! While there might be a lot to criticize the German State/Goverment for, this is not it.

It is a different actor developing a model, not the state. One can rightly criticize that, but that is definitely protected under scientific freedom.

[…] the Decoding Antisemitism project at the Center for Research on Antisemitism at the Technical University Berlin […]. With the help of a large language computing model, the project aims to create “an [AI] algorithm that will automatically recognize antisemitic statements in web comments . . . so that antisemitic posts can be removed more efficiently and accurately” by online platforms.

Most people don’t know that it wasn’t just VW. Sadly I don‘t think you will find any moral acting car manufacturer out there.

Automakers who have been caught using a defeat device within a diesel vehicle, in a similar manner to Volkswagen include: Jeep and Ram under FCA[391] (now a part of Stellantis), Opel[392] (when under GM), and Mercedes-Benz.[393]

While not all using defeat devices, diesel vehicles built by a wide range of carmakers, including Volvo, Renault, Mercedes, Jeep, Hyundai, Citroen, BMW, Mazda, Fiat, Ford and Peugeot[48][49] had independent tests carried out by ADAC that proved that, under normal driving conditions, many diesel vehicles exceeded legal European emission limits for nitrogen oxide (NOx), some by more than 10 times, and one by 14 times.[49]

Beyond exclusively diesel or passenger vehicles, automakers such as: Hino[414] (subsidiary of Toyota), Hyundai and Kia,[415] Nissan,[416] Mazda, Yamaha Motors, Suzuki,[417] Subaru,[418] and others have been proven to be falsifying fuel economy or emissions on non-diesel powered and/or commercial vehicles.

Soure (Wikipedia)

So much needless negativity. Not all features need to be for you.

But, given some users’ sensitivity to this, these types of features will always be optional for use by people who want them.

I would welcome a local model with good integration, I have use for it.

Tldr:

To balance AOSP’s open nature with its product development strategy, Google maintains two primary Android branches: the public AOSP branch and its internal development branch. The AOSP branch is accessible to anyone, while Google’s internal branch is restricted to companies with a Google Mobile Services (GMS)licensing agreement.

Beginning next week, all Android development will occur within Google’s internal branches, and the source code for changes will only be released when Google publishes a new branch containing those changes. As this is already the practice for most Android component changes, Google is simply consolidating its development efforts into a single branch.

They just used the self reported labels on Apple‘s Appstore for this “study”, who knows what a company “forgot” to put in there.

This is an important issue IMO that needs to be addressed and the official response by Bitwardens CTO fails to do so.

There is not even a reason provided why such a proprietary license is deemed necessary for the SDK. Furthermore this wasn’t proactively communicated but noticed by users. The locking of the Github Issue indicates that discussion isn’t desired and further communication is not to be expected.

It is a step in the wrong direction after having accepted Venture Capital funding, which already put Bitwardens opensource future in doubt for many users.

This is another step in the wrong direction for a company that proudly uses the opensource slogan.

The problem with passkeys is that they’re essentially a halfway house to a password manager, but tied to a specific platform in ways that aren’t obvious to a user at all, and liable to easily leave them unable to access of their accounts.

Agreed, in its current state I wouldn‘t teach someone less technically inclined to solely rely on passkeys saved by the default platform if you plan on using different devices, it just leads to trouble.

If you’re going to teach someone how to deal with all of this, and all the potential pitfalls that might lock them out of your service, you almost might as well teach them how to use a cross-platform password manager

Using a password manager is still the solution. Pick one where your passkeys can be safed and most of the authors problems are solved.

The only thing that remains is how to log in if you are not on a device you own (and don’t have the password manager). The author mentions it: the QR code approach for cross device sign in. I don’t think it’s cumbersome, i think it’s actually a great and foolproof way to sign in. I have yet to find a website which implements it though (Edit: Might be my specific setup‘s fault).

The lock-in effect of passkeys is something that this protocol aims to solve though. The “only managed by your device” is what keeps us locked in, if there is no solution to export and import it on another device.

The protocol aims to make it easy to import and export passkeys so you can switch to a different provider. This way you won’t be stuck if you create passkeys e.g. on an Apple device and want to switch to e.g. Bitwarden or an offline password manager like KeyPassXC

The specifications are significant for a few reasons. CXP was created for passkeys and is meant to address a longstanding criticism that passkeys could contribute to user lock-in by making it prohibitively difficult for people to move between operating system vendors and types of devices. […] CXP aims to standardize the technical process for securely transferring them between platforms so users are free […].