Replies (28)
Agreed, and Amber is annoying to run as well with the notifications and junk.
these apps sign 10s of thousands of things every second and here i am trying to see what is being approved..
made me sad 😭
It makes sense to set some actions to always approve. You have the right point but this is still a test network. There is room for the future of Amber, I am certain.
Core app gang but I would reskin it personally
Wait I'm gonna reskin my amber because I can lol hold up
When you say “device keys” do you mean just a generated pair of keys specific for that operation that don’t need identity (but need to publish a nostr event nonetheless)?
I still use amber for when I need remote signer (bunker) stuff. But I agree with you about the permissions, I was complaining about this 4-5 months ago any no one understood.
Every native Nostr app doesn't understand when I refuse to sign an event. They just continues to ask for a signature until I close the app or give in. It makes them unusable
I think that nsec.app does it, but there should be an agreed upon set of basic + advanced presets for different kinds that will be auto signed. That way it doesn’t flood the user with a bunch of sign requests, because they’ve already preapproved for the given kind it’s asking to sign in whatever group they allowed.
That "garbage" often includes meta data that should be signed by an nsec. The issue is that most people rush through that first step on Amber when adding a connection; if you spend an extra 10 seconds reviewing permissions, then this issue doesn't occur (until the app adds more permissions that weren't approved during setup)
A standard might be nice but why are the apps flooding me with sign requests in the first place?
This is apos' fault, not Amber"s one.
Using Amber, or any other signer, more will force apps to improve how they manage rejections.
Hopefully, but in the short turn it just means I don't use any other apps :)
We generally recommend the device key approach wherever it makes sense. It's used exclusively (save for kind 0 and WoT DMs) in Trackstr and
@npub1myv2...n5t5, and for
@npub1d0cs...zhlq we do a lot of signing with ephemeral keys to avoid the same problem
There's more we'd like to improve, such explaining why a permission is required post request / whilst waiting for the signed event
Users should never be expected to "accept all", steer clear of apps that require too many permissions.
daniele
I think a useful best-practice for Nostr apps would be including signing permissions check in the onboarding, instead of randomly when they need them.
This is already quite common on Android for other kind of permissions.
Just briefly explain why you need that specific signature and fire the permission request to the local signer or remote bunker.
It's a one time proces that will make the following app's usage smooth a frictionless.
This will also naturally bring to highlight mandatory and optional permissions, making apps more solid and resilient to possible rejections in the signing flow.
View quoted note →
a signature with an ephemeral key is meaningless.
the apps should be starting out with a thing to show ALL of the required/optional permissions and bam, done. this is partly an issue related to the permissions system. android even has this, where you have to permit like 4 different things on first startup. the signers could improve on this by allowing batch pre-authorizing these actions, you can exclude the ones you don't want (the signer should explain the implications) and never be asked again until the app is upgraded and needs new permissions.
also, another feature request for signers:
whitelist or blacklist based on relays
its not tho, its a bunch of app data that is meaningless to any user, like machine encoded last clicked this page timestamps and unread/read notifications .. it is not standardized at all and it all pops up under "nip44 encrypt/decrypt"
and if you reject any of them, the apps just spam the requests and break, they require you to blanket approve all of it.
yes, i think if apps want to continue to use nsecs and relays as their database, they either need to standardize it or use device keys.. amber must be able to parse out the content of an encrypt/decrypt.. and recognize what it is used for in the case of overloading a single key like this.
when i use PGP, the mail app doesn't use my PGP key for storing a last read UI notifications..
😅
there needs to be some API to tell amber what permission set the app needs, with reason texts for each of them, so you can approve them in one go. this should be a client side thing, also, but if amber had a batching API call to set permissions in one hit that would help a lot too. and app devs should think carefully before they add new ones.
actions it does are both signing events and as well for some, encrypting.
there is small things that would improve on amber side, but really, most of it is client devs responsibility.
ahaha, that's a relay access control issue. the purpose is so that other apps that recognise the data can have the settings without a further complication in syncing the settings. a lot of clients do this, jumble does it, for example. one of the first things i see when i log requests it sends.
its an area of no nips.. just encrypt/decrypt gobbltygook 10,000 times a second. 🦖 i only use this statistic cause thats what vitor said amethyst does.
yeah, there's a lot of areas that the nips are lagging way behind what is actually being used. the "gobbledygook" is regular JSON data. it should be simple to define a thing where there is an app identifier as the keys in the object and then that contains arbitrary json. then the apps wouldn't be clobbering each other's format.
it really needs a nip to at least explain this. but client devs are a bit dim and none of them have even thought for a moment about cross-client interop with this feature.
probably it would be a lot better if the events were addressable and the label was the app name.
i'm not gonna waste my time trying to explain this to either teh nip guardians or the app devs tho. when i make a client, i will define a protocol that is interoperable and then just sorta subtly POINT IT OUT a few times. ideally, i make several clients and then i make it so they interop to demonstrate the principle.
also, what is up with freaking out about signers signing and encrypting events anyway? a) nobody else can read it and b) outside the timing of the signals it leaks no information except maybe the app being used. the combined single event encrypted with object with multiple tags for different apps avoids that metadata leak.
i don't get what the paranoia is about encrypted events. sure, non-encrypted events being signed willy nilly ok, but if the event is encrypted, it's already one step lower on the risk level.
I like the way Nostrudel does it. You shouldn't need to be prompted for a signature until you're actually do something that requires a signature.
Cody
The real security is in keeping your keys safe and not signing events blindly, haha. When I use Jumble, every event (except AUTH) asks for my consent before it’s signed. I know that with this configuration, many apps become almost unusable.
yes, jumble is one of the best apps for the permissions mgmt. very clean, never had a problem.
currently, when i open any app (like jumble even) my fox2x pops up asking me to accept primal permissions and is slowly dying because i clicked someone's primal share link 2 months ago, they will not go away, and primal spammed nos2x to deth. eventually ill have to re-install it again to regain its functionality. from clicking one bad link!!! crazy.
That sounds like a nos2x bug 🤔
it is, its just another example of my eroded ability to manage perms. signers and apps have pushed me into accept all mode. it took 3 years, but yeah i can only report so many bugs and flaws before i just use the tested paths.
