Thread

Could this be used to run malicious code ?

More than likely

In the case that hypernote is presenting the components are published server side so the clients doesn't execute any code more than parsing the hn, maybe nostr:nprofile1qqsq6myr3rwtqjdcm48u357ccwae8h3a4y96s28y7zwg458ngeyg5vcpz4mhxue69uhk2er9dchxummnw3ezumrpdejqzyrhwden5te0xy6rqtnxxaazu6t0qy28wumn8ghj7un9d3shjtnyv9kh2uewd9hs4808mz can tell more about this, or the security of hn syntax. However, I don't see significant vectors of attack in this approach at first glance. On the other hand, the security risks of MCP involve prompt injection, where the llm using it can be guided to provide sensitive information or perform suspicious actions. In this case, since MCP's are used by a human, the responsibility lies with the user when providing sensitive information or performing any suspicious actions.

nostr:nevent1qqs0yr4c3y9sg0rra3lxyxgd3veeae6fzyu5c46gr667ke5xaj9hkespz3mhxue69uhhwmm59ehx7um5wghxuet59upzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qvzqqqqqqyysnhu9

Somebody somewhere will find a way, to inject client side js. They always do.

Secondly, remember on nostr , the relay is the “server” god knows what weaknesses can be exposed there with different relay implementations.

So it's a general problem, not specific to this

Hmm 🤔 nothing can beat a signature verification, and all of this are signed notes

Signing. For the most only proves authorship, it does nothing to verify the payload

The payload is signed by the author therefore if you trust the author you trust the payload

Nope doesn’t work like that . All it does is verify the note originated from a pubkey

The note contains the payload, in this case a hypernote element, where is the problem? 🤷

You have no idea whether that account has been compromised. You have no idea whether somebody has placed arbitrary scripts within that payload. All signing does is provide proof of authorship, it does not provide proof of author other than it was signed by something with the public/private key pair. It does not validate or verify the content. The threat level in these systems is always what’s in the content. The early web had the same problems. We’ll go through this exact same cycle with nostr. Just because you can do something, it’s not always a good idea too do it, until. You’be mitigated the risk of bad actors. There will always be bad actors, it’s a fact of life. Personally, I wouldn’t trust this implementation until it can be verified. Right now, I would treat it as a moderate cool, but cautious of its safety

To pinpoint the exact threat. The hypernote element contains executable code.

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!)

You are pointing to features of PKC, where a private key can be used by anyone who has it and produce valid signatures. This is not introduced by Nostr, PGP has always had an advisory of a trust relationship between the key and the entity supposed to be behind it. The solution is web of trust, where there are out-of-band ways to determine links between the key and the person behind it. On the other hand, I'm not sure if you understand how Nostr event signatures work. Of course, it is a verification that the content field of the event is by the author who signed the note; it cannot be changed or modified and still be valid for the signature. Each Nostr event is a portable, self-signed certificate; it is tamper-evident against any modifications. Also, this note can explain more things about HN security measures. nostr:nevent1qqs0h39n5ta2flyywwff4tts4ey8zjmfzlmp4q82k4rsusz3arltstcpz3mhxue69uhhwmm59ehx7um5wghxuet59upzqrtvswydevzfhrw5ljxnmrpmhy778k5sh2pguncfezks7dry3z3nqvzqqqqqqyzn350y

Not exactly being a doomer . It’s just a harsh reality of building on the web. Been there and done that many times. If there is a way it will be found. I see you’ve given this some thought and seems you’re continuing to do so.

Kind of frustrating feedback tbh. "It will be hacked trust me I'm experienced" doesn't help me. If you engage with the actual design of hypernote and especially the current implementation I bet we'll find problems! But you're not doing that you're just calling it a website when I've actually spent a lot of time figuring out how to make it not be a website.

I’ll take a look