> That makes me wonder - I’m sure it’s not a novel thought - if there is a more suitable species of algae for these conditions we can inject into bleached corals?
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.
> 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.
Maybe the pharmaceutical industry can target a new market here...
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.
contracts are intended to document hoare logic. i.e. pre, post, invariant.
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.
> Contracts are explicitly not input validation. They are there to encode what you expect
The line between what's "input validation" and what's "What you expect" is very muddy. Input validation is a statement of "this is input I expect".
Is it input validation to say a string must be at least some length characters? What if that string is a password? What if it's an MD5 sum?
It SHOULDN'T be used for input validation but it will be. And almost certainly the person that does use it for input validation will argue that they were just laying out expectations.
> The line between what's "input validation" and what's "What you expect" is very muddy. Input validation is a statement of "this is input I expect".
> Is it input validation to say a string must be at least some length characters? What if that string is a password? What if it's an MD5 sum?
Think of it this way: pre-conditions are what the function assumes to be true when it’s called. If it would not be justified to make that assumption at the point where the function is called, it is the responsibility of the caller to perform a runtime check to ensure that it applies. So you might well have a precondition at the level of the function and an explicit check of the exact same condition on the caller side to ensure that it’s respected. If the caller fails to ensure that the condition is fulfilled, and the precondition thereby trips, that’s a programming error.
This is why in my own code I define macros assume and require. The former documents assumptions, asserts for debug builds, and calls __builtin_unreachable for production builds. The latter documents validated requirements, always runs, and is guaranteed to produce a core dump if violated.
Yep this is exactly it. It's a sanity check that enforces the invariants so that when someone else violates those invariants and they don't know what went wrong they can easily debug it.
> Is it input validation to say a string must be at least some length characters
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.
Some people. Most projects I know of build -Wall and fix all the errors. Developers all run - Error. 30 years ago this was madness but compilers are good about fixing false positives and so it is reasonable.
It isn't reasonable to expect downstream (i.e. Debian) to fix warnings but developers generally do for code they maintain.
For my own code I generally -Wall -Werror and if that breaks a prospective dependency in a nontrivial manner I find a replacement. I'll also tend to go looking for a replacement if a prospective dependency breaks when compiled with either asan or ubsan. Why would I voluntarily subject myself to such shoddy code?
I perform my own builds with -Wall -Werror. But it is a kindness to users of your code to provide a build flag that excludes -Werror. This allows user who are building with a GCC compiler version later than mine to sill build the code without having to modify the build scripts.
The standard doesn't require compilers find all such cases. The standard allows it, but doesn't require it. There are many known cases where the compiler cannot find a case (at least not in a reasonable amount of time)
The consequence of not being required in the standard is that compilers may not implement it and if they do, they will likely have different implementations/functionality
The consequence of being required is the standard is limited to exactly what we are sure everybody can do today. If there are advances in proving C++ code the new advances cannot be used to tell you about more bugs.
It depends what you need to run. There exist a number of Windows images which can be run without any paid license requirements for test and validation IIRC.
> They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
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.
Can I do hardware attestation across several devices yet? My desktop, my phone, a console, my girlfriends phone of a different brand if I need to log into a shared account, etc?
It seems like one of those things that only works if you're sticking to one ecosystem.
Yes. You can register as many different passkeys as you want. Any limitation in passkeys registration quantity is a limitation of the website/app itself and not a limit of the spec, etc.
? If a website sucks and can't support multiple passkeys that's not a flaw of passkeys. It's a flaw of the website. You could make the exact same argument for TLS or 2FA or every other security feature.
If the developer fucks up the website/app, that is their fault and not a failure of the technology.
>that is their fault and not a failure of the technology.
Respectfully, you should consider reconsidering this mindset. The best engineers and tech designs take into account not only how users will use a technology but also how they will misuse it.
Only in theory. Suppose you are a bank, which enclaves/sources/devices do you support vs. not support? What do you do for users on a desktop PC that don't have an enclave? Phishing sites will leverage your weakest enrollment option.
Strictly speaking it's mainly hardware attestation but it's technically "hardware based passkeys" and "remote attestation". So if you rely on attestation in general and don't restrict the attestation source it works just as well.
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.
Stealing passwords is already an incredibly rare attack nowadays. The attack is almost always on the cred reset path. Suppose a user loses their phone with the secure enclave and wants to login to your site using their laptop without a secure enclave.
Are you really going to block that cred reset on the grounds that it's a downgrade? You're going to have a lot of users calling your support asking why they can't login after switching devices.
So you allow it, then oops it was not a laptop, it was a phishing site.
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.
The phishing site will say something like "Your passkey is out of date, click here to create a new one" I call that cred reset since it is similar to password reset, perhaps some sites support multiple passkeys, in that case the phishing site will use the register new passkey path instead of reset existing.
Phishing sites already frequently target the reset/create-new-password path because it's actually easier to get a user to generate a new password vs. trick their password manager. Plus 2FA is usually required anyway since no 'remember me' cookie is avail so a password reset is equal in difficulty to a password login.
That method still works just fine with passkeys right?
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. 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.
> That method still works just fine with passkeys right?
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.
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's a linux container but through WSL and natively integrated into windows. that's basically it.
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).
So it's not something for me, but like everything Microsoft makes, it's for our BOFH's who will torment us with yet another corporate compliance machine.
Note that these specific mosquito species are invasive in most of the world after they escaped their native ecosystems and proceeded to spread like wildfire so arguably eradicating them would be a net benefit for most ecosystems.
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.
reply