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.
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.
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 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".
Sometimes PDFs store actual character data (like vector graphics), and sometimes they store static images. Last I checked (admittedly a few years ago), Word conversion only works on the former. It didn't do OCR or anything so dramatic.
If only some PDFs will work for them, they wouldn't accept them at all.
Following that statement, the author spends the rest of the article explaining how the people asserting supremacy often do not see it as such.
It is an implicit and unwitting reality of the position they are taking. I used to be one of these folks; I couldn't see the harm and hate of my own positions, thanks to the fog of ethnocentrism.
The striking difference here, at least to me, is the a matter of scale and delay. Aphids and fungus are smaller than the ants, and have shorter lifecycles than the ants themselves. Planting and cultivation of a coffee plant suggests understanding of much larger scale (both literally and conceptually).
Sorta. The basis for your concern underlines one of the problems. When such gaffs happen in engineering, the firm is blamed. Within the firm, individual actors are blamed.
In software, on the other hand, your major system might have responsibility for a critical system spread across a total of 1 persons, so he gets all the blame. Is that really okay for one hip-shooter to take this on in the first place?