atanasi

If you use a security key only for the most important accounts like Apple or Google, keys are set up once and then unchanged for years.

The service may require attestation and verify the actual authenticator metadata.

If the passkey is not accepted by the service, it can use the signaling API to indicate that the passkey was not registered validly.

Airpods use AAC-ELD for better microphone quality. While the codec is an open standard, activating it with Airpods is proprietary.

My bank in Finland allows activating the bank's app remotely. They verify the NFC chip of the ID card in addition to photos and other factors.

The app would be restricted to environments certified by Apple or Google. Then the app can apply features like trusted time to implement client-side rate limiting.

If the app wants to take advantage of mandatory hardware attestation, it has to require Android 13 or later. This would undermine somewhat the promise that the app supports a wide range of devices. Even banks don't currently enforce Android 13+.

The current policy trend in the EU is definitely not based on the principle of each user evaluating their own risk. On the contrary, service providers like financial institutes and identity providers have the responsibility to keep users safe, and more and more regulation will be made. The natural consequence is restricting which platforms are supported.

Bad money drives out good money only if there is a legal tender law such that both have to be accepted for the same nominal value. In this case, good money is hoarded because it cannot be traded for its true value.

It's the security of the ecosystem, where the interests of app vendors are fundamental: content distributors can count on enforcing DRM, and banks are relying on the camera used for KYC actually being a camera and not a virtual device.

Reading comprehension problems can often be caught with some static analysis combined with AI.

FSF has published a commentary: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

GPL licenses have allowed so-called "mere aggregation", where separate programs are distributed together. Such programs don't have to be all covered by GPL.

On the other hand, if parts are intimately tied to each other such that they are effectively a single program, GPL applies to the whole.

The FSF commentary explains that the judgment depends both on the mechanisms and the semantics of the co-operation. Technical implementation details don't make programs separate if they are intimately designed to work together: "But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."

Server-side solutions don't catch all cheats. They can block actions that are impossible according to the game rules but they cannot prevent clients from disclosing too much information to the player about other players, or automating actions that are technically possible, like using aimbots.

I have heard that AES is very complicated to implement in software, if one intends to avoid side-channel leaks.

In the case of printing, the context provides some information. In particular, Erlang JAM file seems unlikely to be printed.

Are they even similar to JavaScript or PHP?

Certificates are precisely for authentication, but the simplest form employed by automatic systems like letsencrypt only tries to verify domain control. It does not bind the certificate to any legal identity, unlike stronger forms of certificates.