Leace

Extensions doesn't work. Initially they thought it was a great idea but after some backlash Mozilla decided to add some popular ones: https://github.com/mozilla-mobile/fenix/issues/5630

Yes, not to mention when you want to share the link in DDG you share the original link directly but in Google you'd share the redirector link.

Given Google's scale they probably don't care about the long tail of technical users such as us.

> I switched my iPhone to Duck Duck Go over the last few days simply because I hate hate HATE getting linked to Reddit AMP pages from Google.

Funny thing because I also switched to DuckDuckGo to avoid AMP on mobile and stayed on DDG for years (!g is still needed sometimes unfortunately).

> What do you mean "all parties"? They're excluding at least one party - nVidia users.

I mean all parties that implement the standard protocol. It's rather nVidia that's not interested in giving their users a chance to use properly Wayland not Sway developers "excluding users" by not doing free work for nVidia.

> I have read this and I don't understand why Wayland developers don't want to write an adapter for NVidia's proprietary API.

If you're NVidia user you're justified to feel bad about this entire fiasco but remember protocols exist so that everyone implements their own part and users can mix-and-match and it works together.

If AMD and Intel can dedicate resources to maintain their Wayland implementations with no complains why NVidia can't?

> why Wayland developers don't want to write an adapter for NVidia's proprietary API

Because they could use the time spent on maintaining NVidia proprietary API adapter writing open-source software that will benefit all parties.

> This would be a good time to mention that sway doesn't support the nvidia proprietary driver

It's rather nvidia proprietary driver that doesn't support standard Wayland protocols and thus doesn't work with Sway not the other way around.

See this for details: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html

That's really surprising as the beta link is on the login page: https://mail.protonmail.com/login :)

> Still sad about the loss of the XMPP service a few years ago though.

XMPP pre-Conversations.im was pretty bad anyway but Fastmail could review their stance given some other mail providers re-enabling modern XMPP: https://mailbox.org/en/post/daniel-gultsch-creator-of-conver...

Fastmail is a direct competitor to Gmail. That is Fastmail is Gmail but different. Fastmail is opposed to E2E e-mail encryption as this makes some of their features impossible (e.g. full text e-mail search).

Protonmail on the other hand has OpenPGP encryption that can be used even cross providers (on https://beta.protonmail.com composing an e-mail to Werner Koch <wk at gnupg.org> will enable encryption). But they don't support all usual e-mail features like IMAP and SMTP (there are bridges but...).

> IMO we need something simpler, websocket and JSON based.

Why JSON? JSON is the packaging format of this decade but remember when XMPP was conceived XML was the packaging format of that decade.

Maybe CBOR would be more appropriate. No need to encode binary data (signatures, encryption) in base64 wrappers and more efficient encoding of frequently used stuff (no need for Whatsapp-stype FunXMPP).

XMPP were lacking "gamification" tools that'd encourage people to do better. Eg. for TLS there is https://www.ssllabs.com/ssltest/ but for XMPP it was only recently that https://compliance.conversations.im/ sprung to convince server operators to upgrade.

Also, clients. https://conversations.im/ is good for Android . https://dino.im/ looks like a promising Desktop client but where are the iOS clients? Stuck in XMPP dark ages from what I've heard.

> I mean how many of you stick with this test driven development practice consistently?

I do for some projects. For example currently I'm working on a project that has a high test coverage and most bugs and enhancements start first as a test and then they're implemented in code. TDD makes sense when the test code is simpler to write than the implementation code.

> Can you describe the practical benefit?

It may take some time to write initial tests but as I'm working with some legacy enterprise tech serializing all inputs and testing on that is a lot faster than testing and re-testing everything every commit on real integration servers.

Tests provide you with a safety net when you do refactors or new features so that the existing stuff is not broken.

> Do you happen to rewrite the tests completely while doing the implementation?

Yeah, I do. There are two forces at play - one of them pushes to test that cover more stuff in a black-box matter - they won't be broken as often when you're switching code inside your black-box. On the other hand if you've got finer grained test when they break it's obvious which part of code is failing.

> When does this approach work for you and when did it fail you?

It works for projects that are hard to test other way (we've got QA but I want to give them stuff that's unlikely to have bugs) and for keeping regressions at bay. It did fail me if I didn't have necessary coverage (not all cases were tested and the bug was in the untested branch).

I wouldn't also bother to test (TDD) scratch work or stuff that's clearly not on critical path (helper tools, etc.) but for enterprise projects I tend to cover as much as possible (that involves sometimes writing elaborate test suites) as working on the same bugs over and over is just too much for my business.

New firmware is quite interesting if one is using OpenPGP: it supports newer algorithms (25519) and key attestation (proofs that the key was generated in hardware, useful for enterprises). Still, PIV applet has some more advantages (like dozens of possible encryption subkeys) but this is mainly a limitation of OponPGP Card spec.

> Optional: verify public key on Keybase.

For organizations publishing employee keys via Web Key Directory can also be an additional signal that the key is trustworthy.

It's also quite simple: for example exporting the key 5C090ED7318B6C1E (binary, not armored) and putting it on this exact URL: https://datadoghq.com/.well-known/openpgpkey/hu/964aj6q73iat... is enough to discover the key using e-mail address.

This post goes into more detail: https://spacekookie.de/blog/usable-gpg-with-wkd/

WKD is used by Linux distros (ArchLinux, Gentoo, Debian...) and kernel.org itself: https://www.kernel.org/category/signatures.html#using-the-we... as well as some OpenPGP sites (e.g. ProtonMail).

Nope, you were right. It's for USB MITM. I guess the assumption is that the keyboard is wired in a different way (a laptop?) or in wireless scenarios (NFC Yubikey).

Yes but do mind hardware bugs that affected YubiKeys such as https://magicofsecurity.com/roca-critical-vulnerability-in-i...

Also I'd strongly encourage generating encryption subkey in software (offline, air-gapped machine) and then copying it to Yubikeys. If you lose your Yubikey (or mistype 3 times the PIN) you wouldn't be able to decrypt your secret data.

I used them too and they're fantastic. I even bought a couple of licenses for IrfanView although I didn't need them.

Too bad there's no Linux version.

> Is there any credit card size yubikeys yet?

Nope, I'd like to see one too. In the mean-time Fidesmo card can replace some usages of Yubikey (U2F, OpenPGP): https://shop.fidesmo.com/products/fidesmo-card-2-0

> 1) This is an upgrade to the touch sensitive button that's on all YubiKeys today. The reason you have to touch the key is so that if an attacker gains access to your computer with an attached Yubikey, they will not be able to use it (it requires physical presence). Now that touch sensitive button becomes a fingerprint reader, so it can't be activated by just anyone.

I'd like it to work that way but when I'm reading the article it doesn't explicitly say that (only mentioning integration with Azure that's not interesting for me).

Is there any authoritative info that the fingerprint reader will work as touch button but with verification of fingerprints in all scenarios? (like touch-to-use on OpenPGP applet, U2F applet etc.)

> - The administrator can enforce use of hardware-backed keys [1]

This is also available on PKCS/OpenPGP for some tokens (and not only for auth keys). See: https://developers.yubico.com/PIV/Introduction/PIV_attestati... and https://developers.yubico.com/PGP/Attestation.html

> I wanted to find out how secure people think this is

It depends on what do you compare this with. PKCS/OpenPGP smartcard is protected by a PIN (6 digits min, 3 tries and it locks itself out) and then touch on each use (with Yubikey).

U2F on the other hand it just protected by touch so anyone having the token can authorize themselves. (Sites usually use it in conjunction with username/password that is "something you know").

On the yet another hand I didn't review the implementation and would welcome corrections here.

> Accurate URLs verified by PGP.

What does it mean? I'm not seeing any PGP clearsigned text in there...

Not the poster but it may be useful to know that Andrew_nenakhov is a CEO of company that provides a Jabber messanger (Xabber).

Seems like a technical ad for their product. If the thread model includes malicious admins then all bets are off as admins can change both server-side and front-side code.

Some measure of security could be achieved using browser extensions (c.f. Mailvelope or https://stosb.com/blog/signed-web-pages/).

I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario.

This pattern of concatenating commands to have a minimal image is a workaround from times when multi-stage builds were not available.

Typically but not necessarily. F-Droid can distribute apps with original signatures from developers if the app builds reproducibly. See: https://f-droid.org/en/docs/Reproducible_Builds/

Works on mobile. See countless comments here.

> No one wants to look at their entries from 2005 from when they screwed up while learning about subkeys

Yeah, it's interesting that even platforms such as Keybase that allow changing or removing data timestamp them in irremovable ways sometimes (e.g. following someone snapshots their profile in the follower's sigchain).

> In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method.

Actually having a key on a keyserver was never relevant as web-of-trust runs parallel to the key origin (that is if you're connected to WoT you'd know which key is the real one). But it's not practical in general.

> like listing your key ID on a TLS-enabled website

Web Key Directory is something like that and it's trivial to set up: https://spacekookie.de/blog/usable-gpg-with-wkd/

Project looks definitely interesting. Too bad the code looks like callback-hell from 10 years ago: https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e83...

Still, an interesting alternative for people who consider https://keys.openpgp.org too radical.

Do you use Lttrs daily? I'm wondering if it works in practice (even when using non-standard setup) or if it's just a proof-of-concept (that'd mean it may take some time to mature).