mirror of
https://github.com/privacyguides/privacyguides.org
synced 2024-11-30 15:03:32 +01:00
fix: Remove broken invidious embeds (#2585)
Signed-off-by: Jonah Aragon <jonah@privacyguides.org> Signed-off-by: redoomed1 <161974310+redoomed1@users.noreply.github.com>
This commit is contained in:
parent
42b75c9265
commit
c0481d65d0
@ -75,11 +75,9 @@ WebAuthn is the most secure and private form of second factor authentication. Wh
|
||||
|
||||
When you create an account, the public key is sent to the service, then when you log in, the service will require you to "sign" some data with your private key. The benefit of this is that no password data is ever stored by the service, so there is nothing for an adversary to steal.
|
||||
|
||||
This presentation discusses the history of password authentication, the pitfalls (such as password reuse), and discussion of FIDO2 and [WebAuthn](https://webauthn.guide) standards.
|
||||
This presentation discusses the history of password authentication, the pitfalls (such as password reuse), and the standards for FIDO2 and [WebAuthn](https://webauthn.guide):
|
||||
|
||||
<div class="yt-embed">
|
||||
<iframe width="560" height="315" src="https://invidious.privacyguides.net/embed/aMo4ZlWznao?local=true" title="How FIDO2 and WebAuthn Stop Account Takeovers" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
- [How FIDO2 and WebAuthn Stop Account Takeovers](https://youtu.be/aMo4ZlWznao) <small>(YouTube)</small>
|
||||
|
||||
FIDO2 and WebAuthn have superior security and privacy properties when compared to any MFA methods.
|
||||
|
||||
|
@ -45,9 +45,7 @@ For frozen distributions such as [Debian](https://debian.org/security/faq#handli
|
||||
|
||||
We don’t believe holding packages back and applying interim patches is a good idea, as it diverges from the way the developer might have intended the software to work. [Richard Brown](https://rootco.de/aboutme) has a presentation about this:
|
||||
|
||||
<div class="yt-embed">
|
||||
<iframe width="560" height="315" src="https://invidious.privacyguides.net/embed/i8c0mg_mS7U?local=true" title="Regular Releases are Wrong, Roll for your life" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
- [Regular Releases are Wrong, Roll for your life](https://youtu.be/i8c0mg_mS7U) <small>(YouTube)</small>
|
||||
|
||||
### Traditional vs Atomic Updates
|
||||
|
||||
@ -55,11 +53,9 @@ Traditionally, Linux distributions update by sequentially updating the desired p
|
||||
|
||||
Atomic updating distributions, on the other hand, apply updates in full or not at all. On an atomic distribution, if an error occurs while updating (perhaps due to a power failure), nothing is changed on the system.
|
||||
|
||||
The atomic update method can achieve reliability with this model and is used for [distributions](../desktop.md#atomic-distributions) like Silverblue and NixOS. [Adam Šamalík](https://twitter.com/adsamalik) provided a presentation on how `rpm-ostree` works with Silverblue:
|
||||
The atomic update method can achieve reliability with this model and is used for [distributions](../desktop.md#atomic-distributions) like Silverblue and NixOS. [Adam Šamalík](https://twitter.com/adsamalik) provides a presentation on how `rpm-ostree` works with Silverblue:
|
||||
|
||||
<div class="yt-embed">
|
||||
<iframe width="560" height="315" src="https://invidious.privacyguides.net/embed/-hpV5l-gJnQ?local=true" title="Let's try Fedora Silverblue — an immutable desktop OS! - Adam Šamalik" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
</div>
|
||||
- [Let's try Fedora Silverblue — an immutable desktop OS! - Adam Šamalik](https://youtu.be/aMo4ZlWznao) <small>(YouTube)</small>
|
||||
|
||||
### “Security-focused” distributions
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user