Sign In

Kyle Simpson

Revolutionizing the way we build and use web applications

Kyle Simpson is a dedicated advocate for a world where technology serves to enhance human lives, striving for a society filled with more happiness and fulfillment.

Having studied Computer Science at Texas State University and the University of Oklahoma, as well as receiving a High School Diploma from PC North HS, Kyle has a strong educational background in the field.

Throughout his career, Kyle has held various positions in renowned organizations, including stints as a Co-Founder at Vella.ai, a Principal Software Engineer at Socket Supply Co., a Distinguished Engineer at MURAL, and a Human-Centric Technologist at Getify Solutions, showcasing his expertise and versatility in the tech industry.

Among his notable roles, Kyle Simpson has also served as the Head of Curriculum at MakerSquare, a Co-founder at HubAustin Coworking, a Software Engineer at Mozilla, a User Experience Architect at Pointserve, and a Sr. Presentation Layer Developer at Avenue A | Razorfish, demonstrating his wide-ranging experience and skills.

Currently, Kyle is an advisor at Vella.ai, where he continues to contribute to the advancement of technology that prioritizes the well-being and experiences of users, emphasizing the human aspect behind digital innovations.

Highlights

Aug 23 · linkedin

Very simple question for you:

Since we've had passkeys pretty ubiquitously available for a couple years now, why are you still building web apps with traditional auth systems that rely on username/password/email-magic-link/sms-2fa/etc?

I don't understand the slow-mover objections to this?

Aug 9 · linkedin

A number of folks commented on my recent posts about the (now newly named!) "Local Data Lock" library, that since it's doing local encryption (using a key protected in a local client biometric passkey), it's clear it should also be doing the storage of that data locally... in localstorage, indexdb, etc. That's why many people argued it should use "Store", "Vault", etc in its name.

I disagree, because for this library, the scope is more narrow. The "local" part refers specifically to the encryption and biometric passkey management, and it's agnostic of storage choice (locally or remotely).

Yes, the main purpose of this library is for the "local-first app development" community, where indeed you would be storing data in the client. But the library can definitely be used in broader cases than this, so I wanted to keep it storage-agnostic as much as possible.

But... I have two important things to discuss and expound on:

  1. Is there any case to be made for encrypting locally in the client but not storing that encrypted data locally?

Actually, yes! Imagine for example an app that lets users create and protect (encrypt) data on their own device, BUT where this app STORES that encrypted data on their own cloud servers instead of the user device. In such a case, ideally, the service would never be able to read the user's encrypted data (so it can't keep the encryption key!), it would only be able to provide the encrypted blob back to a client, and let them decrypt it.

There's a number of interesting app use-cases for things like this. It's sorta like E2E, except that in this case, the two "E" (ends) can just be the user's own device(s) rather than different users' devices. For example, companies wanting "plausible deniability" over not being able to leak user info to police/government authorities, would very much want to do things like this.

But the problem is always "where do we store the encryption key?" in such cases. Now, "Local-Data-Lock" library offers a great answer to that question: store the key in a biometric passkey!

I hope those kinds of apps consider using my library. :)

  1. All that said, providing a clean API abstraction for local-client storage (across local-storage, indexdb, cookies, etc) where the API automatically handles the encryption (on write) and decryption (on read)... that wraps around the "Local Data Lock" library... that is a SEPARATE and useful library idea.

And such a library should indeed probably be called "Local Vault". So... you might be able to guess where I'm going with this.

I'm now going to make that "Local Vault" library! Stay tuned. :)

Kyle Simpson
Add to my network

Location

Austin, Texas, United States