Hacker Newsnew | past | comments | ask | show | jobs | submit | shortsunblack's commentslogin

Yes. HMAC extension allows for this use case.


Android to this day does not support CTAP 2.1, hence it does not support hardware-bound passkeys with PIN via NFC as transport. You can only do PIN via USB.

Google does not care about FIDO or standards compliance. They care about vendor lock-in their proprietary passkey offerings allow.


KVM was made because Citrix made moves against Xen that spooked Linux community, hence KVM. Then Red Hat ran with it and based its virtualization platform on it.

Citrix involvement has subsided in meantime and the ecosystem is much healthier (governance is actually under Linux Foundation), but the damage was done.

Xen to this day lacks in features, also.


Also, Xen's main clame to fame was that para-virtualization allowed it to host Linux and *BSD VMs at close to zero overhead, but at time what everyone was looking for was a way to host Windows VMs, which is where all the pain points and the money was. CPUs were evolving to support this use-case, making para-virtualization less important, and Xen had to evolve quite quickly to include QEMU in the mix, leaving a bit of convoluted mess initially, and causing a lot of friction during the attempts to get merged into the Linux kernel. On top, the Xen management tool-stack had been written by happy amateurs in Python and Twisted, before any of those technologies where near ready for production use, with massive slowness and unfixable memory leaks as results. KVM provided a fresh take built with the benefits of hindsight, got merged into Linux on the first attempt, and gained the backing of Redhat, and the rest is more of less history.


KVM was launched before Citrix acquired XenSource. But Redhat had also tried to acquire XenSource and threatened its founders that if they did not come along Redhat would “rip off their heads and shit down the hole”, because “Redhat was the only company allowed to make money off open source”. In that light it made sense for Redhat to back a competitor to Xen.


The current reference design is not compatible with existing law. eIDAS regulation that is the legal basis for digital wallet mandates unlinkability. GDPR has a general requirement for technical controls to be state of the art. Inherent reliance on American monopolies is incompatible with Digital Markets Act.

The current design and usage of cryptographic primitives does not allow for unlikability (it is actually quite easy to for verifiers and relying parties to collude) and it certainly is not state-of-the-art. BBS signatures would achieve actual unlinkability, but those have been outright rejected by the designers.

Current implementation is poised to not comply with the regulation that established the mandate for the wallet and it violates GDPR. The best one could hope for is for CJEU to strike down the whole project.

The GitHub organization of the OP's post has various issues that discuss these ills. Here is a position of several cryptographers against the current design: https://github.com/eu-digital-identity-wallet/eudi-doc-archi...


The legal obligation has to come from relevant member state or EU law. Not third party countries' laws.

This at best is force majeure that prohibits OpenAI with satisfying its contractual obligations that are there to comply with EU law. But contractual obligations are not the only control organizations have to ensure compliance with EU law, so this is not a defense.


From the law itself:

> 1. The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay...

> 3. Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:

> e. for the establishment, exercise or defence of legal claims.

https://gdpr-info.eu/art-17-gdpr/

The law makes no reference to the idea that the legal claims must be under a member state or EU law.


OpenAI is breaching relevant laws that regulate data protection. Being compelled by a foreign power, for instance, are not grounds for data processing under GDPR.

OpenAI has not started to "be incompliant" with GDPR with this order, yes. More like OpenAI was always incompliant because it does not have relevant controls installed that mitigates extraterritorial tendencies of US law.

Regardless of legality of retention this order brings, them not notifying their users (the court did not compel them to hide this from their users (no gag order is in place) about this material change of data processing, could be constituted as breach of various consumer protection laws, misrepresentation, unfair dealing, false advertising and related.


The order mandates retention of all user data, even of non-Americans. This is a massive extraterritorial overreach and a highlight of how US law has zero regard to data protection as a fundamental human right. As if there were not enough concerns about US cloud providers already.


And United States still has regulations. Chevron doctrine is not a thing in Europe and European institutions do not get captured by NIMBYs when industry wants to build a railroad, a house or an apartment complex. There are no hundreds of governmental organizations demanding you impact assessments and environmental studies.

For crying out loud, as an American you cannot work on your own house, since a lot of labour is licensed (electrical work, etc) and taped in red.

The regulation Americans talk of in disparaging way is always the regulation that shifts and allows consumer/user surplus.


In the US you can work on your own house, including electrical and plumbing (including natural gas and propane lines, I think). For minor repairs like replacing a switch or receptacle, I don’t think a permit is required. For more substantial changes a permit is generally required and as is an inspection. Supplies for doing all kinds of residential construction work are readily available at retail establishments that normal people visit regularly.


Cloud init/Cloud config is a standard way to provision Linux hosts. It is slowly being outcompeted by Ignition and the friends, though.


> It is slowly being outcompeted by Ignition and the friends, though.

I hope not, because I lack enough foul language to describe my burning hatred for Ignition and all its cutesy campfire-related project codenames. Hate-red.


EU law largely does not regulate national security matters of the states. Though that justification is limited per international law (such as ECHR, which is the basis of many anti-government surveillance rulings by CJEU). All European Union members are part of ECHR because that is a pre-requisite for EU membership.

But ECHR is not part of EU law, especially it is not binding on the European Commission (in the context of it being a federal or seemingly federal political executive). This creates a catch-22 where member states might be violating ECHR but are mandated by EU law, though this is a very fringe consequence arising out of legal fiction and failed plans to federalize EU. Most recently, this legal fiction has become relevant in Chat Control discourse.

Great Britain and Poland have explicit opt-outs out of some European law.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: