NGL it's the exact wording I'd personally like to see from a product that had an infra provider have an incident just so that I can mentally tune in enough to figure out if I need to care.

TLDR Yes but it's complicated. There are more suitable algae species but AFAIK coral under heat stress will still often expel the algae even if the algae isn't the one stressing the coral. So you have to essentially breed a more tolerant coral and then provide the algae.

Now luckily there do exist more heat tolerant coral and algae species living alongside each other. Unfortunately those species are located in the Persian Gulf/inside the Strait of Hormuz so they are regularly subject to added stressors from Oil/NG extraction, military conflicts, and waste dumping. And of course their location makes research on them/collaboration between research institutions complicated.

And it's not like you can just transplant these coral somewhere else and they'll live. They are adapted to their environment and that environment plays a part in their heat tolerance as well. But research on these coral ecosystems will likely shed a light on how to help other coral species to adapt and evolve.

Kind of? But it really depends and there's a lot of edge cases the phishing website would have to dodge to avoid breaking the custody chain.

If you force the user down to "use your password/security questions/whatever" to auth and create a new key then yes phishing is still viable here but one of the key advantages of pushing for a passkeys-first approach is that you can make the other auth methods harder. i.e. mandate password + 2FA as a strictly backup method instead.

> The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks.

Yep and passkeys explicitly exist to eliminate this behavior.

> Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.

Well here the caveat is that the phishing website would have to force the user back down to password-auth or security questions or whatever other "weak" method and then use that to create a passkey but not have perms to do anything else.

Now if the phishing site tries to MITM the actual passkey registration flow there are a lot of ways to detect a phishing attempt and terminate the registration and alert the user through alternate contact methods.

TLDR: there are probably still ways to execute a phishing attack but to succeed they have to be far more sophisticated and there's countless ways to accidentally break the passkey auth chain in a way that halts the attack.

If the developer fucks up the website/app, that is their fault and not a failure of the technology.

Yes. Yes it is. Input validation should happen at the public API and then contracts after that.

Contracts are very explicitly for things you don't want to ever see happen. They are "something went wrong".

So your API would accept a function that handles input validation and maybe has its own contract for things it explicitly doesn't handle but then internally you use contracts to enforce that the string is already input validated and you don't have to enforce edge cases.

The first declaration of a function must include the contract pre/post conditions and follow-up re-declarations of the function must either not include any contract conditions or the same conditions as the initial declaration.

And you can avoid re-including the world because pre/post conditions should be externally visible behavior or call out to functions for pre/post checks on internal behavior.

Essentially you either define them using what you have in scope during the initial declaration or you call out to a function located elsewhere that can have access to more/internal scope and do more complicated checks.

It includes checkpoint semantics (something that is part of contracts in general) as well as processing through the contract violation handlers.

Functionally contract_assert should eliminate the need to use assert at all and is an over all substantial UX improvement.

They can be compile time if the compiler can verify them statically (where they become a noop), runtime otherwise, or disabled entirely if you can't prove them statically but don't want the overhead cost.

Realistically contracts will gradually evolve towards static/compile time asserts as tooling improves.

And like the blog post states, contracts are explicitly not input validation. They are there to encode what you expect and what you don't internally in your code rather than just documenting those pre/post/invariant conditions in comments.

That's not the argument being made.

The argument I'm making is that the only MITM/phishing vulnerability is in the initial passkey registration and not in the auth.

So once you have a passkey and the flow supports attestation, as long as you use the passkey you are effectively immune to MITM and phishing.

Now if you input a password or recovery code or whatever and use that to register a new passkey that's initial passkey registration again and not MITM or phishing of the passkey itself. The reason this matters is because you can register as many passkeys as you want. Say you sign up and log in on your phone. Now you register a passkey on the phone. You want to log in on your laptop, use the key from your phone to log in and register one for the laptop as well. Now you lose your phone or your laptop, you use the other to log you in and set up a new passkey for that device.

Once that initial passkey was registered the auth process is pretty watertight and each device you regularly use gets a new key after auth so you generally always have at least one device that you can use to get into your others.

Now of course if you only have one device and it gets destroyed or if all your devices are destroyed in a fire or flood or whatever then you have to go through the untrusted reset/re-registration flow but in all other scenarios you always default to the passkey-based "use another device you own" methods to register new keys.

TLDR: the point is that you very rarely ever do a true cred reset. The flow itself incentivizes multiple passkey auth methods such that bootstrapping new keys from an untrusted environment is rarely if ever required. This works best for "core services" like your email/google acct/apple acct/microsoft acct where you are generally expected to want access to them anywhere you do stuff so the passkey flow is best pared with SSO to increase the odds you've used the acct on at least one other device.

Software passkeys can be stolen if the client is compromised but they aren't vulnerable to MITM or phishing as long as attestation is used.

> which enclaves/sources/devices do you support vs. not support?

You support all of them and prefer the strongest configuration for the source available.

If you've registered a hardware based key with attestation and then an attack tries to intercept that via phishing or MITM, the key already has its capabilities established and if you try to use the key without attest it should fail.

If you register a key without attestation support then you may be vulnerable to MITM or phishing but you can't intercept a user/their passkey with a stronger set of capabilities and downgrade them.

https://learn.microsoft.com/en-us/windows-hardware/manufactu...

https://learn.microsoft.com/en-us/windows-hardware/manufactu...

This is only technically true because of the definition of what a passkey is is vague.

Hardware Attestation solves this problem and is "good actually". The issue with attestation is when site attempt to restrict which enclaves/sources can register keys. But if you don't restrict who/what can register keys, attestation is super useful for preventing this exact issue.

When you register your key initially you establish your hardware attestation parameters. The attacker cannot know those parameters unless they were the ones to initially register you for the site as the public attestation signature is unique per-key and the private one per-use with the public one verifying the private one.

So if you have remote attestation you can verify whether the source presenting the signature for auth is the same source that created the signature and trivially block MITM attacks. Likewise for more complicated custody/proxy chains.

This just by itself largely solves MITM key re-enrollment attacks but tech camps that support passkeys either ideologically oppose attestation (due to understandable enclosure fears) or enforce hardware attestation for enclosure purposes without bothering to address MITM/signature origin checks.

Hitler and Nazi Germany did not start with the Holocaust. It was instead the end result. Something can be compared to Hitler or compared to the Nazis or their rhetoric without being literally the Holocaust.

Keep in mind that Hitler and the Nazis took power starting in 1933 but forcing jews to carry identification (i.e. add israel or sara to non-jewish names and add jewish identification marks to paperwork) didn't start until mid-to-late 1938 with Kristallnacht following only months later in Nov 1938.

But in that early period however Nazis began

- gutting research institution

- literally destroying research institutions and research. (ex the famous 1933 book burning picture was from the demolition of the Institute for Sexual Research which studied gender non conformity, intersex traits, and broader topics in the LGBTQIA academic space. Also was where the first transgender sex reassignment surgery took place.)

- expelling academics

- dismantling social programs

- pressuring companies into aligning with state ideological and industrial objectives

- seizing control of, attacking, or privatising domestic and foreign media

- pressuring domestic and foreign entertainment into aligning with Nazi ideological stances

- punishing, oppressing, and expelling political and cultural enemies of the party from the military and civic institutions.

- converting prisons into work camps.

- building out detention facilities/prisons for "illegals" with deplorable conditions with intent to make them suffer as long as possible. These would later become concentration camps and then death camps once crowding became too extreme. And notably this began with the romani population in the early 1930s who Nazis believed to be criminals illegally present within the country.

--------------------

Nazi germany was so much more than just the Holocaust and genocide of the Jewish people. They were part of it however they were the conclusion not the start.

It replaces the need to install docker and mess with a lot of hackery instead with an officially first party supported linux container subsystem.

Edit: and since I forgot to mention a key value-add of this is that it's integrated with group policy, defender etc so you can limit specific users or groups or OUs, etc to running specific containers or to exposing specific resources/network devices/hardware/etc to WSL at all. It makes managing all of it no different than managing any other part of an enterprise windows setup.

And likewise WSL has native antivirus/anti-intrusion instrumentation hooks via a Microsoft Defender for Endpoint/MDE plugin to WSL so that unlike with docker, etc you don't get a sudden blindspot that's non-trivial to monitor (or that comes with a heavy perf penalty).

These are some of the most problematic/disease causing of the mosquitoes but also notably mosquitoes in the Aedes genus are essentially the only mosquitoes that are "hunting" during the day. All the other mosquitoes operate almost exclusively in the evening and at nighttime.

So by eliminating these mosquitoes a major disease vector is eliminated but at the same time it completely eliminates mosquitoes during the day (i.e. the main time when you are out and about trying to enjoy the summer).

You still have to run romex for the other circuits. But it's not hard to run those on a separate breaker. Rooms often have like one and a half 15A circuits each because lighting used to draw so much power but now you can drop it down to one 15A circuit per room and run a single circuit that switches out to the entire house off of one 15A breaker.

> what's the difference between a power supply running on 48 volts DC versus 110 or 220 volts AC?

It's already DC. A properly sized buck converter based LED driver is going to have like 80-95% efficiency when the LED is on (and it's trivial to draw no power when off) and they are like 0.25USD per IC.

They are going to have equal or better performance than AC->DC switching mode power supplies because buck converters are already the simplest and most efficient type of SMPS.