Some notes on Hypernote security

Hypernote is a strict subset of the web meant to be easily rendered in native UI frameworks like SwiftUI and Jetpack Compose in addition to browsers. JS wouldn't have any semantic meaning to a Hypernote renderer. You can think of it as early HTML with forms and buttons but JS hasn't been invented yet. (Naturally it's up to someone building a web-based Hypernote client to do the same sorts of sanitization that any app that shows user-generated data does... running the hypernote through a schema validator should be sufficient. But the fact that this is hard is more of a sign that we should try to get away from the web if we can!) The default assumption is that any hypernote you load might be malicious, just like any webpage you might load could be malicious. The security model is also similar to a nostr client, where any note you load might be malicious. The new, fun, dangerous part is that a hypernote can have "actions" defined within it that publish nostr events. The Hypernote itself never gets ahold of your private key, it's only given nostr capabilities like event signing by asking the permission of the Hypernote Client "will you sign this event?" "will you run this query?". So if you load an evil Hypernote that has an action inside it that publishes an "I'm gay" note when you click a mislabeled button, it's incumbent upon the Hypernote Client to confirm that action with the user. As you can see in the video, every action I take in my web prototype hypernote client is confirmed via the nos2x window extension. I imagine the eventual UI can have something like when you authorize an app to connect to your GitHub. "This hypernote wants to be able to publish kind 0, 1, and 30078 events on your behalf" SPOOKY. "This hypernote wants to publish 30078 (application data) events on your behalf" Not as spooky! One idea that this gets me thinking of: we might want to add attribution tags to all events published from hypernotes for the sake of deniability. "I'm not gay, I just got tricked by this malicious hypernote: naddr... See, the note is tagged with it!" This could be done by the Hypernote Client. As for the server side stuff, there's nothing a server can do that a hand-crafted hypernote can't do. Unlike the web, the server doesn't have any more info about the user than anyone else does. The only data they get from the user is what that user explicitly publishes. > The early web had the same problems. We’ll go through this exact same cycle with nostr. I appreciate this sentiment, but instead of being doomers, let's design concrete attacks to this current design to figure it. Hypernote is being built in the year 2025 with reference to the pitfalls of the web (such as a reliance on scripting that pulled it away from being a hypermedia). You say "arbitrary scripts within that payload" but there are no scripts in Hypernote. The attack surface is: 1. declarative "queries" (with pipes for declarative data transformation, a potential danger if not implemented well!) 2. "actions" which can create nostr events on the user's behalf with the permission of the user. (they currently have "triggers" so they can go off based on queries but I'm removing that functionality because it was a bad idea) 3. web-based clients that naively pass dom attributes or svgs to their renderer with embedded scripts (my current implementation is potentially vulnerable to this, although I haven't managed to trick it yet) Maybe I'm missing something, but even if someone snuck a malicious script into a web client in the current design, that script's damage would still be gated by the user's nostr signing method. 4. Unknown unknowns (plz find!)

Announcing Harbor 1.0! Here's a vlog about it. Get it at https://harbor.cash

“A revolutionary age is an age of action; ours is the age of advertisement and publicity. Nothing ever happens but there is immediate publicity everywhere. In the present age a rebellion is, of all things, the most unthinkable.” Kierkegaard

No but there will be!

The science of divs

Hypernote Elements https://hypernote-elements.vercel.app https://github.com/futurepaul/hypernote-elements

this is a vlog about hypernote

It’s a good name for a box!!

Where we’re going we wont need web

If you just parse a little harder bro what you’re looking at is a working nostr client defined as a nostr event published to the absolute wrong kind of