Remove or provide method to disable "encrypt message" and "verify signature" functionality

duxsco commented

2022-11-14 16:39:12 +00:00

Currently, https://keyoxide.org allows for encryption and signature verification using the public key you searched for without any way for the keypair owner to disable this functionality. This may be alright with a credible service such as yours that uses OpenPGP.js and does every operation locally within the webbrowser.

Like online password generators, however, online encryption is a service that shouldn't be legitimised in any way (IMHO). Imagine other (possibly dubious) services coming around the corner with the same promise of encrypting confidential data for the visitor. Thus, I would prefer for this functionality to be removed entirely from your site. If that's not feasible for you, you could apply either of these two options:

A. Disable the service by default and allow for the public key owner to opt-in via notation.
B. Check whether the public key comes with an "encrypt" and "sign" capability. If that's not the case, the website doesn't show the "encrypt message" and "verify signature" buttons.

Of both options, I prefer the first one.

If it comes down to option B, I plan to create an additional keypair issued under my name and for the email address noreply@example.org with a primary key, that has only the "cert" capability, and without any subkeys. Said public key will be provided over self-hosted WKD. In contrast to my "main" public key, whose keypair has all capabilities and is used for daily work, this "noreply" key can also be queried without the "l" parameter and can thus be found by Keyoxide.

Currently, https://keyoxide.org allows for encryption and signature verification using the public key you searched for without any way for the keypair owner to disable this functionality. This may be alright with a credible service such as yours that uses OpenPGP.js and does every operation locally within the webbrowser. Like online password generators, however, online encryption is a service that shouldn't be legitimised in any way (IMHO). Imagine other (possibly dubious) services coming around the corner with the same promise of encrypting confidential data for the visitor. Thus, I would prefer for this functionality to be removed entirely from your site. If that's not feasible for you, you could apply either of these two options: A. Disable the service by default and allow for the public key owner to opt-in via notation. B. Check whether the public key comes with an "encrypt" and "sign" capability. If that's not the case, the website doesn't show the "encrypt message" and "verify signature" buttons. Of both options, I prefer the first one. If it comes down to option B, I plan to create an additional keypair issued under my name and for the email address noreply@example.org with a primary key, that has only the "cert" capability, and without any subkeys. Said public key will be provided over self-hosted WKD. In contrast to my "main" public key, whose keypair has all capabilities and is used for daily work, this "noreply" key can also be queried [without the "l" parameter](https://codeberg.org/keyoxide/keyoxide-web/src/commit/d6b9d5bec9c93a3299686bb5dc103bd3c90ab237/views/util/wkd.pug#L14) and can thus be found by Keyoxide.

👎 2

yarmo commented

2022-11-15 10:01:01 +00:00

Owner

Overall, I think your reasoning here is sound.

With each iteration of the Keyoxide web interface, the Encrypt/Verify functionality has taken a step back. Keyoxide should focus on identity verification. The rest is optional. And so should Encrypt/Verify be.

Overall, I prefer opt-in over opt-out and I think that should be the way to go here. Creating a profile is an active process so when doing that, one can make their own decisions on what functionality they want on their profile page or not.

I thank you for saying my service is credible but I always try to design it as if people did not think so. Therefore, Keyoxide servers should know as little as possible.

People have no say over what Keyoxide instances can verify their profile: all instances can! In that light, it makes especially sense to make Encrypt/Verify opt-in to avoid malicious people logging sensitive material. Instances could of course ignore the config and show Encrypt/Verify anyway but I don't believe that's a reason to do nothing on our end.

Overall, I think your reasoning here is sound. With each iteration of the Keyoxide web interface, the Encrypt/Verify functionality has taken a step back. Keyoxide should focus on identity verification. The rest is optional. And so should Encrypt/Verify be. Overall, I prefer opt-in over opt-out and I think that should be the way to go here. Creating a profile is an active process so when doing that, one can make their own decisions on what functionality they want on their profile page or not. I thank you for saying my service is credible but I always try to design it as if people did not think so. Therefore, Keyoxide servers should know as little as possible. People have no say over what Keyoxide instances can verify their profile: all instances can! In that light, it makes especially sense to make Encrypt/Verify opt-in to avoid malicious people logging sensitive material. Instances could of course ignore the config and show Encrypt/Verify anyway but I don't believe that's a reason to do nothing on our end.

👍 1

yarmo commented

2022-11-16 10:50:29 +00:00

Owner

There are multiple ways of accomplishing configurable profiles:

config@ariadne.id=enable-encrypt-button=true
config@ariadne.id=enable-encrypt-button
enable-encrypt-button@ariadne.id=true

I think solution 2 has my preference. Only works for on-off configuration though, we could fall back to solution 1 for config that needs more precise info, such as:

config@ariadne.id=theme-color=#4ab4ab

Solution 3 does not make it clear it's a configuration setting.

There are multiple ways of accomplishing configurable profiles: 1. `config@ariadne.id=enable-encrypt-button=true` 2. `config@ariadne.id=enable-encrypt-button` 3. `enable-encrypt-button@ariadne.id=true` I think solution 2 has my preference. Only works for on-off configuration though, we could fall back to solution 1 for config that needs more precise info, such as: - `config@ariadne.id=theme-color=#4ab4ab` Solution 3 does not make it clear it's a configuration setting.

duxsco commented

2022-11-16 12:41:32 +00:00

Poster

I would provide:

config@ariadne.id=enable-button=verify
config@ariadne.id=enable-button=encrypt
config@ariadne.id=enable-button=encrypt-and-verify

I dunno whether only ...=verify and ...=encrypt should be provided, and ...=encrypt implicitly enables the "verify" button. Perhaps, it's best to provide all three options as I don't know the plethora of use cases out there.

I would provide: - `config@ariadne.id=enable-button=verify` - `config@ariadne.id=enable-button=encrypt` - `config@ariadne.id=enable-button=encrypt-and-verify` I dunno whether only `...=verify` and `...=encrypt` should be provided, and `...=encrypt` implicitly enables the "verify" button. Perhaps, it's best to provide all three options as I don't know the plethora of use cases out there.

yarmo commented

2022-11-16 13:37:59 +00:00

Owner

Maybe we should think broader then and consider them "modules" or "functions" (or a better word I can't think of rn).

config@ariadne.id=enable-module=encrypt verify

This will of course allow us to add more modules in the future.

As for arrays, I would go with space separation.

Maybe we should think broader then and consider them "modules" or "functions" (or a better word I can't think of rn). - `config@ariadne.id=enable-module=encrypt verify` This will of course allow us to add more modules in the future. As for arrays, I would go with space separation.

👍 1

yarmo commented

2022-11-16 13:39:37 +00:00

Owner

Pinging @wiktor for his opinion. We had similar discussions a while ago.

duxsco commented

2022-11-16 20:42:29 +00:00

Poster

Independent of the profile config, it would be good to check the keypair's capabilities and disable the buttons if provided capabilities are insufficient, e.g. only primary key with "cert".

wiktor commented

2022-11-17 08:42:47 +00:00

Hi folks!

Of course this is internet so I also have a couple of opinions :)

B. Check whether the public key comes with an "encrypt" and "sign" capability. If that's not the case, the website doesn't show the "encrypt message" and "verify signature" buttons.

This definitely needs to be fixed. If the key doesn't have an encryption subkey the encryption will fail either way. Not sure if the button should be disabled or hidden (if it's hidden it's not obvious why it doesn't work, if it's disabled the reason can be added as title attribute).

config@ariadne.id=enable-module=encrypt verify

Looks dangerous if you add more directives (like enable-modules). If you want to go this route I'd suggest config@ariadne.id=enable-module=encrypt,verify (comma instead of space). Then the additional directives can be separated by spaces: config@ariadne.id=enable-module=encrypt,verify theme-color=#123456.

By the way maybe enable is superfluous? How about config@ariadne.id=modules=encrypt,verify?

I've mentioned that using two = can be confusing so config@ariadne.id=modules:encrypt,verify is also an option.

Also since this is about UI maybe make the notation ui@ariadne.id? (Not sure if there will be any non-ui settings :))

Phew, that's it for now I guess. Really interesting issue! 👋

Hi folks! Of course this is internet so I also have a couple of opinions :) > B. Check whether the public key comes with an "encrypt" and "sign" capability. If that's not the case, the website doesn't show the "encrypt message" and "verify signature" buttons. This definitely needs to be fixed. If the key doesn't have an encryption subkey the encryption will fail either way. Not sure if the button should be disabled or hidden (if it's hidden it's not obvious why it doesn't work, if it's disabled the reason can be added as `title` attribute). > `config@ariadne.id=enable-module=encrypt verify` Looks dangerous if you add more directives (like `enable-modules`). If you want to go this route I'd suggest `config@ariadne.id=enable-module=encrypt,verify` (comma instead of space). Then the additional directives can be separated by spaces: `config@ariadne.id=enable-module=encrypt,verify theme-color=#123456`. By the way maybe `enable` is superfluous? How about `config@ariadne.id=modules=encrypt,verify`? I've mentioned that using two `=` can be confusing so `config@ariadne.id=modules:encrypt,verify` is also an option. Also since this is about UI maybe make the notation `ui@ariadne.id`? (Not sure if there will be any non-ui settings :)) Phew, that's it for now I guess. Really interesting issue! 👋

yarmo commented

2022-11-17 10:00:38 +00:00

Owner

Agreed with ui@ariadne.id. Agreed with enable-module:encrypt,verify.

Not sure if modules alone will cut it, I prefer config to have action verbs. But then, shouldn't it be set-theme-color. All in all, working with notations is still annoying so let's keep it as short as possible. I'll go with modules as well.

Interesting you want to combine configs: ui@ariadne.id=modules:encrypt,verify theme-color:#123456. People can still put them in separate notations if they wish.

So, from all the feedback:

fix the public key capability detection
support ui@ariadne.id=modules:encrypt,verify theme-color=#123456

(not theme-color yet, that will require some more research and work)

Agreed with `ui@ariadne.id`. Agreed with `enable-module:encrypt,verify`. Not sure if `modules` alone will cut it, I prefer config to have action verbs. But then, shouldn't it be `set-theme-color`. All in all, working with notations is still annoying so let's keep it as short as possible. I'll go with `modules` as well. Interesting you want to combine configs: `ui@ariadne.id=modules:encrypt,verify theme-color:#123456`. People can still put them in separate notations if they wish. So, from all the feedback: - [ ] fix the public key capability detection - [ ] support `ui@ariadne.id=modules:encrypt,verify theme-color=#123456` (not theme-color yet, that will require some more research and work)

👍 1

yarmo added this to the Feature development project 2022-11-17 10:00:55 +00:00

yarmo added the

enhancement

label 2022-11-17 10:01:03 +00:00

duxsco commented

2022-11-17 12:02:34 +00:00

Poster

One thing that comes to mind for ui@ariadne.id=modules:...:

I prefer explicitly setting avatar images (for GitHub, Mastodon, etc.). Thus, I would love to have s.th. like ui@ariadne.id=modules:avatar-img=https://duxsco.de/avatar.png. That way, setting avatar images doesn't depend on a third-party service. But, that's a topic for another day 😉. I am fine with being able to disable the buttons in some way. Then, I can prepare my keypair for Keyoxide 🙂.

One thing that comes to mind for `ui@ariadne.id=modules:...`: I prefer explicitly setting avatar images (for GitHub, Mastodon, etc.). Thus, I would love to have s.th. like `ui@ariadne.id=modules:avatar-img=https://duxsco.de/avatar.png`. That way, setting avatar images doesn't depend on a third-party service. But, that's a topic for another day 😉. I am fine with being able to disable the buttons in some way. Then, I can prepare my keypair for Keyoxide 🙂.

wiktor commented

2022-11-17 12:07:44 +00:00

Setting the avatar is a great use-case to keep in mind when designing the notation IMO :)

The one thing to keep in mind is that allowing random URLs for avatars allows people to keep track on who's checking their profile (set the avatar URL to https://my-domain.com/track-viewer.php ;) ). This might have privacy implications.

Setting the avatar is a great use-case to keep in mind when designing the notation IMO :) The one thing to keep in mind is that allowing random URLs for avatars allows people to keep track on who's checking their profile (set the avatar URL to https://my-domain.com/track-viewer.php ;) ). This might have privacy implications.

yarmo commented

2022-11-17 12:34:09 +00:00

Owner

I'm not a big fan of random URLs for necessary things like avatars. We currently have a good system that deduces avatar URLs from the OpenPGP key's email address.

That being said, there is going to be more focus soon on Keyoxide profiles based on signatures. And then there won't be any email addresses to query libravatar. A configurable avatar URL is unavoidable.

We could fetch avatars through the proxy to limit tracking.

I'm not a big fan of random URLs for necessary things like avatars. We currently have a good system that deduces avatar URLs from the OpenPGP key's email address. That being said, there is going to be more focus soon on Keyoxide profiles based on signatures. And then there won't be any email addresses to query libravatar. A configurable avatar URL is unavoidable. We could fetch avatars through the proxy to limit tracking.

yarmo commented

2022-11-17 12:36:53 +00:00

Owner

As for the notation, I'd be ok to give it its own one: avatar@ariadne.id=URL, just as I hope bio@ariadne.id=Hey there, this is my key will become a thing. I don't think these should be part of ui@ariadne.id= but where to draw the line?

As for the notation, I'd be ok to give it its own one: `avatar@ariadne.id=URL`, just as I hope `bio@ariadne.id=Hey there, this is my key` will become a thing. I don't think these should be part of `ui@ariadne.id=` but where to draw the line?

yarmo commented

2022-11-17 18:52:08 +00:00

Owner

Actually, I might prefer:

profile@ariadne.id=avatar-img:URL
profile@ariadne.id=bio:"This is my key"

Actually, I might prefer: - `profile@ariadne.id=avatar-img:URL` - `profile@ariadne.id=bio:"This is my key"`

duxsco referenced this issue

2023-02-18 13:18:17 +00:00

Show UID comment #154

jcgruenhage commented

2023-04-24 15:21:50 +00:00

It's been two months since this has been removed from the profiles, and I've run into it three times since then. Being able to link my PGP key to people in a way where I'm sure that even the least tech competent people will be able to encrypt something for me was one of the most useful things in keyoxide (and keybase before it) for me. I could self host a keyoxide frontend for this where I enable those buttons again, but that is just too much maintenance overhead in the long run.

It's been two months since this has been removed from the profiles, and I've run into it three times since then. Being able to link my PGP key to people in a way where I'm sure that even the least tech competent people will be able to encrypt something for me was one of the most useful things in keyoxide (and keybase before it) for me. I *could* self host a keyoxide frontend for this where I enable those buttons again, but that is just too much maintenance overhead in the long run.

yarmo commented

2023-04-29 09:49:39 +00:00

Owner

@jcgruenhage would something like this suit your need? https://tencrypt.org/#hkp;9f0048ac0b23301e1f77e994909f6bd6f80f485d

One could imagine with some form of opt-in setting Keyoxide could link to tencrypt to enable message encryption for those that want it!

@jcgruenhage would something like this suit your need? https://tencrypt.org/#hkp;9f0048ac0b23301e1f77e994909f6bd6f80f485d One could imagine with some form of opt-in setting Keyoxide could link to tencrypt to enable message encryption for those that want it!

jcgruenhage commented

2023-04-29 20:22:47 +00:00

That's perfect. Thanks!

duxsco referenced this issue

2023-08-11 22:04:35 +00:00

Show UID comment #154

wiktor referenced this issue

2023-08-14 10:32:50 +00:00

Show UID comment #154

duxsco referenced this issue

2023-08-15 05:00:17 +00:00

Show UID comment #154

Remove or provide method to disable "encrypt message" and "verify signature" functionality #142