MyNameIsFred

I'm a personal and professional advocate from r passkeys, yet I must acknowledge that your criticisms and skepticism are valid. I don't see this as a flaw in the passkeys concept so much as a growing pain. It's a very different mental model, and I've seen businesses make some very poor implementation decisions based on some poor understanding of what this system aims to be. That in turn adds to a bad consumer impression, a growing body of bad examples for others to look to and replucate, and it all just compounds.

This rebuttalakes no sense to me. What you cite is about about transport encryption. App -> Server. The end of the process is that the receiver (Telegram servers) receives a decrypted (plaintext) message, just as kelsey98765431 is saying.

The simplified terminology is not for you or I as technologists. It is for the general consumer market. Yes, public/private key cryptography has been a thing for decades, but it has been out of reach for the consumer market. The whole passkey idea is to reduce the technical and cognitive friction to make it a viable replacement for passwords.

You are completely correct and I really wish you weren't.

MS ToDo was hewn from the corpse of Wunderlist. It's the same "ding".

Yes! I dove into this (and later, Moondlander) because I have mobility issues and had to reduce travel, but the resulting 90WPM and (unprovably) faster coding have been awesome side-effects.

> Yeah it's a neat idea but I struggle to think of good use-cases [...] If I'm working on a service [...]

I suspect that's simply not the use-case they're targeting. You're thinking of a database as simply the persistence component for your service, a means to an end. For you, the service/app/software is the thing you're trying to deliver. Where this looks useful is the cases where the data itself is the thing you're trying to deliver.

That's an alarming equation. The harder you lie, the less likely you'll be called out on it.

What else in life works that way?

Yes, thank you. A mindset which thinks that documentation is wasted due to a need to constantly update, is cousin to the mindset which thinks that software, once written, is a purchased asset which needs no further attention nor maintenance.

They most certainly do not "handle it just fine". They are highly scammable, they know it, and it's "solved" my moving as much of the burden and repercussions onto the consumer as possible.

I've had my identity stolen, and both my wife and I have been mistaken for somebody else. There ARE way to move past this condition (inline with Google Pay, apparently), but it's just done via trust. Or apathy. Or acceptable risk. Or some combination thereof. It never truly goes away.

What wouldn't be the 5th time I've heard such stories, but I don't think it's in any way specific to IBM. Employers like that want any OT you do to be dedicated to THEIR endeavor, not somebody else's...even your own.

If you're able and willing to code in your off-time, you should be doing it for the good of the Company. /s

My team of consultants will write Android apps, and the customer takes ownership of the code base when we're done.

My wife would leave me if she knew how much I love Kotlin, but I could never use it for work projects because we just could not justify expecting random inheriting developers to know Kotlin and accept its legitimacy. That constraint lifted in an instant. It's a political thing, but it really matters.

I haven't done Windows development for a long time, but I think that this may be an overstatement, at least on that platform.

You need to have cursor focus to receive key events, right?

The clipboard, by contrast, can be continually monitored, while playing completely "by the rules", right?

I do not see this as an actual rebuttal to the idea of it being a backdoor. The article makes two points: 1. Ultimately, verification falls to the user, so even in a secure system, user error, misunderstanding, and/or laziness can result in becoming compromised 2. Clients can lie to us anyway

The point about this "backdoor" business is that the WhatsApp client does not even give the user the chance to even make a mistake of skipping or mis-executing validation. Instead, it will just make that mistake FOR you, every time, for your convenience!

That utter failure of design, and breach of trust, enables a remote actor (the WhatsApp servers) to access secure data. So yes, it is a "backdoor".