You would have another browser engine at your fingertips; with all its upsides and downsides. Outside of the Apple world there are no really usable webkit based browsers (even though it originated from Linux).

To be fair, it is not sponsorship. Kagi pays for a service they use. And since this is just one of many sources, this is likely also a relatively small amount of money. If they would deliberately pay more than what they use to “do something good” for yandex, then sure, it would be a much bigger issue.

The only seriously usable webkit based browsers are on OSX or iOS. So far this looks like a best shot at having a cross platform browser with all necessary features to become mainstream and which is based on webkit.

If that helps erode the chromium monopoly, it’s a win.

Drawing attention

From an acceptance point of view there is no difference in forcing providers to implement an API to talk to your device or forcing providers to talk to a central service (or at least any service implementing a certain interface).

If the goal was for more surveillance, they could have immediately gone for that route.

They could also have kept the current “ask the user” approach and mandated website providers to store these information. That would have been a much smaller step and would have brought them closer to big brother as well.

Now they went for an approach that takes a step away from what we already have, making it more privacy friendly. Websites don’t have to ask (and potentially store) your birthday anymore and can still stay compliant.

The US bills I have read also don’t enforce any real age (how could they). They require the birthday to be stored on the device for the device to reply with the info if the user is within a certain age bracket. But nowhere did I see anything that would force users to store their truthful birthday. All that it would do is making the already existing age checks much more convenient and giving parents the opportunity to make them slightly more secure.

Isn’t that level already socially normalized? Every second website asks me for my birthday to derive my age for as long as I can think. Many of them ask me basically every time I use them (even Steam, where I am logged in and my payment history alone should imply that I am old enough).

How would the current approach help?

Its not invasive yet (no third party, no ID, no verification; its basically just another user controlled date field that is not even exposed). So it is not lowering any barrier in that regard.

It’s also not a helpful intermediary step for harder measures, because as soon as you want a third party to do attestation, storing that on a user controlled device is just unnecessary complexity and risk of circumvention. It would be easier and safer (for those introducing it) to just let the attesting party talk to the providers directly.

The comment you answered to said not all software has to implement age checks; only those who actually deal with age relevant content. You said it would be a foot in the door. So… who’s foot to do what?

Who exactly gains anything from forcing lets say Krita to implement an age check?

No. Because the information is user provided and unverified, so there’s no reason to lock anything down that could increase security. Once they want attestation, they need a third party service involved, in which case the device being part of the trust-chain doesn’t make sense anymore.

In business notebook comparison they are well within the norm. For private use … yeah, that’s a lifestyle choice.

The 3D stuff around games is actually the smaller problem. It’s performance critical but it’s basically “just” one API (bundle) to implement that then covers a big chunk of the game’s implementation.

Productivity software usually consists of a shit ton of other stuff. They would probably render fine, but then they ship with a weird ass licensing management system that will deny to work. Or parts of or even a whole app use .NET and suddenly you have the complexity of all the WinAPI calls hidden behind .NET Framework. Maybe the app does a few lowlevel WinAPI calls themselves on top, that Wine didn’t need to implement so far. Or the app you want to run is only distributed via Windows Store as UWP; the necessary APIs also haven’t been implemented yet.

Wine is awesome, but it’s not fully covering all the shit Window’s APIs offer.

A company that lets you use Linux as a main OS might not like if you also want to run Windows in a VM.

My point was rather to be careful when you use it, to not get into legal trouble (especially because it just works with the default settings).

Unless you somehow use it commercially. Then the missing license could cause legal issues.

The main advantage of SB is TPM. At runtime the key isn’t available and unlocking your disk works automatically as long as nothing has been tampered with (which is then also a nice canary: if you suddenly have to enter your password during boot, something’s off).

Even having no pre-boot PIN with SB on is nice, then you only need your user space login where you could even use fingerprint reader if you like. For servers they can already start serving without anyone having to intervene manually (which is nice after power outage, for example).

So yeah, SB, TPM and FDE are a very nice bundle that heavily secures against the most relevant attack vectors.

For the user they come with the OS

That’s my point, though. Plasma isn’t an OS. You can can have a OS that ships Plasma with Calligra instead of LibreOffice and Falkon instead of Firefox. Or neither, and instead they give you a greeter with the choice to pick your browser. Or the OS is minimal and doesn’t bundle any of them. In Arch for example you normally don’t even get Konsole or Dolphin unless you install them (or you pick the nuclear option and install _all _ KDE packages which also includes a ton of stuff you likely never need).

AUR is the place for unverified submissions. The verified stuff typically ends up in the main repos.

The preinstalled apps are not a feature of KDE (or Gnome, XFCE, etc.). Actually they all are structured in a very modular way where you can use or omit individual components. Firefox and LibreOffice are completely independent of it even; they merely add compatibility layers to make the integration more seamless.

What you experienced was something to attribute to the distribution you chose. They are the ones to decide which components to bundle and preinstall. That is also the reason why so many distributions exist in the first place, because different teams/devs have different visions about what the desktop should look and feel like after install.