Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[Oliver Falk]

Hi!

Thanks for the fruitful discussions on this mail thread and today in IRC.
Highly appreciated.
For the moment, I'll leave the idea with API keys alone.
For those who have privacy concerns, we can redirect them to the following
example script now:

https://git.linux-kernel.at/oliver/ivatar/blob/devel/libravatarproxy.py

One can deploy this or something similar to their own servers, so the users
do not directly hit libravatar and therefore hide the users from us. Since
they proxy it in the background, one can also change the script to take as
input some user id, that queries some database and so on and so forth...
That would ultimately lead to also the possibility to hide the hash.

PRs to enhance this, are welcome.

Oliver




On Tue, Mar 12, 2019 at 6:17 PM Tristan Le Guern 
wrote:

> On 3/12/19 2:23 PM, Oliver Falk wrote:
> > Yes, federation wouldn't work - only if we do not encrypt the hash, but
> > instead the mail-address (makes sense, since it's anyway encrypted) and
> > Libravatar proxies the requests to the federated site. Which means, that
> > these sites would only need to trust Libravatar.
>
> This is problematic as it forces centralization. I don't have a better
> proposition for now but this is an interesting and important discussion
> to have.
>
> > BTW. That raises the question in my mind do we know how many sites
> > actually run their own Libravatar (compatible) service? I guess
> > no!? @Francois Marier  do you know
> anything?
>
> I guess it is impossible to find. You can count mine and tastytea's for
> sure. Debian, Mozilla and git.kernel.org use their own or do they use
> libravatar.org?
>
>
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[Tristan Le Guern]

On 3/12/19 2:23 PM, Oliver Falk wrote:
> Yes, federation wouldn't work - only if we do not encrypt the hash, but
> instead the mail-address (makes sense, since it's anyway encrypted) and
> Libravatar proxies the requests to the federated site. Which means, that
> these sites would only need to trust Libravatar.

This is problematic as it forces centralization. I don't have a better
proposition for now but this is an interesting and important discussion
to have.

> BTW. That raises the question in my mind do we know how many sites
> actually run their own Libravatar (compatible) service? I guess
> no!? @Francois Marier  do you know anything?

I guess it is impossible to find. You can count mine and tastytea's for
sure. Debian, Mozilla and git.kernel.org use their own or do they use
libravatar.org?



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[Francois Marier]

On 2019-03-12 at 15:23:31, Oliver Falk wrote:
> BTW. That raises the question in my mind do we know how many sites actually
> run their own Libravatar (compatible) service? I guess no!? @Francois Marier
>  do you know anything?

If you mean how many sites expose their own Libravatar endpoints via DNS, I
don't know and I'm not sure how to find out since we'd basically have to
enumerate the list of all registered domains :)

The closest thing we have to that is the list of third-party software
implementations on the wiki, but that's a very poor proxy as it doesn't tell
us how many users each piece of software has.

Francois

-- 
https://fmarier.org/

___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[clime]

On Tuesday, 12 March 2019, clime  wrote:

>
>
> On Tuesday, 12 March 2019, Oliver Falk  wrote:
>
>> Hey.
>>
>> Thanks Tristan for bringing it to the point. :-)
>> Yes, federation wouldn't work - only if we do not encrypt the hash, but
>> instead the mail-address (makes sense, since it's anyway encrypted) and
>> Libravatar proxies the requests to the federated site. Which means, that
>> these sites would only need to trust Libravatar.
>> BTW. That raises the question in my mind do we know how many sites
>> actually run their own Libravatar (compatible) service? I guess no!? 
>> @Francois
>> Marier  do you know anything?
>>
>> So in the end it boils down to the question if we want to build and offer
>> such a feature and if, we need to think about the implementation details -
>> what I built for the moment is only a raw PoC/idea.
>>
>
> Good luck.
>

Let me know if you need anything server-side!


>
>>
>> Oliver
>>
>>
>> On Tue, Mar 12, 2019 at 3:03 PM Tristan Le Guern 
>> wrote:
>>
>>> On 3/12/19 12:59 PM, clime wrote:
>>> > I am missing the point encrypting the hash. I could understand it for
>>> > md5, which is crackable nowdays but not quite for sha256. That hash
>>> > should be non-reversible in practical terms and then we can always just
>>> > jump to sha512 in a few years when hardware is stronger
>>>
>>> SHA256 is still susceptible to rainbow tables attack so in theory a
>>> dedicated spammer could still harvest libravatar users' hashes for his
>>> nefarious purpose and use them to validate email addresses. This issue
>>> has been raised since Gravatar's birth.
>>>
>>> Oliver proposes a mechanism to solve this issue but with a clear
>>> drawback: in it's current form it breaks federation.
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~libravatar-fans
>>> Post to : libravatar-fans@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~libravatar-fans
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[clime]

On Tuesday, 12 March 2019, Oliver Falk  wrote:

> Hey.
>
> Thanks Tristan for bringing it to the point. :-)
> Yes, federation wouldn't work - only if we do not encrypt the hash, but
> instead the mail-address (makes sense, since it's anyway encrypted) and
> Libravatar proxies the requests to the federated site. Which means, that
> these sites would only need to trust Libravatar.
> BTW. That raises the question in my mind do we know how many sites
> actually run their own Libravatar (compatible) service? I guess no!? @Francois
> Marier  do you know anything?
>
> So in the end it boils down to the question if we want to build and offer
> such a feature and if, we need to think about the implementation details -
> what I built for the moment is only a raw PoC/idea.
>

Good luck.


>
> Oliver
>
>
> On Tue, Mar 12, 2019 at 3:03 PM Tristan Le Guern 
> wrote:
>
>> On 3/12/19 12:59 PM, clime wrote:
>> > I am missing the point encrypting the hash. I could understand it for
>> > md5, which is crackable nowdays but not quite for sha256. That hash
>> > should be non-reversible in practical terms and then we can always just
>> > jump to sha512 in a few years when hardware is stronger
>>
>> SHA256 is still susceptible to rainbow tables attack so in theory a
>> dedicated spammer could still harvest libravatar users' hashes for his
>> nefarious purpose and use them to validate email addresses. This issue
>> has been raised since Gravatar's birth.
>>
>> Oliver proposes a mechanism to solve this issue but with a clear
>> drawback: in it's current form it breaks federation.
>>
>> ___
>> Mailing list: https://launchpad.net/~libravatar-fans
>> Post to : libravatar-fans@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~libravatar-fans
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[Oliver Falk]

Hey.

Thanks Tristan for bringing it to the point. :-)
Yes, federation wouldn't work - only if we do not encrypt the hash, but
instead the mail-address (makes sense, since it's anyway encrypted) and
Libravatar proxies the requests to the federated site. Which means, that
these sites would only need to trust Libravatar.
BTW. That raises the question in my mind do we know how many sites actually
run their own Libravatar (compatible) service? I guess no!? @Francois Marier
 do you know anything?

So in the end it boils down to the question if we want to build and offer
such a feature and if, we need to think about the implementation details -
what I built for the moment is only a raw PoC/idea.

Oliver


On Tue, Mar 12, 2019 at 3:03 PM Tristan Le Guern 
wrote:

> On 3/12/19 12:59 PM, clime wrote:
> > I am missing the point encrypting the hash. I could understand it for
> > md5, which is crackable nowdays but not quite for sha256. That hash
> > should be non-reversible in practical terms and then we can always just
> > jump to sha512 in a few years when hardware is stronger
>
> SHA256 is still susceptible to rainbow tables attack so in theory a
> dedicated spammer could still harvest libravatar users' hashes for his
> nefarious purpose and use them to validate email addresses. This issue
> has been raised since Gravatar's birth.
>
> Oliver proposes a mechanism to solve this issue but with a clear
> drawback: in it's current form it breaks federation.
>
> ___
> Mailing list: https://launchpad.net/~libravatar-fans
> Post to : libravatar-fans@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~libravatar-fans
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[Tristan Le Guern]

On 3/12/19 12:59 PM, clime wrote:
> I am missing the point encrypting the hash. I could understand it for
> md5, which is crackable nowdays but not quite for sha256. That hash
> should be non-reversible in practical terms and then we can always just
> jump to sha512 in a few years when hardware is stronger

SHA256 is still susceptible to rainbow tables attack so in theory a
dedicated spammer could still harvest libravatar users' hashes for his
nefarious purpose and use them to validate email addresses. This issue
has been raised since Gravatar's birth.

Oliver proposes a mechanism to solve this issue but with a clear
drawback: in it's current form it breaks federation.



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[Oliver Falk]

Hi!

OK. I forgot to add the reference:

https://bugs.launchpad.net/libravatar/+bug/1248456

I hope that clears things up! :-)

Basically, if all sites with security in mind would use keys to retrieve
the images, that would lead to the situation, where you cannot simply hash
an e-mail/openid and search for it on google in order to find out where the
users profile picture eventually pops up and may therefore leak information
about what services a specific user uses.

Oliver


On Tue, Mar 12, 2019 at 1:59 PM clime  wrote:

> On Tue, 12 Mar 2019 at 12:29, Oliver Falk  wrote:
>
>> Hi!
>>
>> So, the basic idea, that I already implemented as PoC, is. You request
>> API keys and get a public and a secret key. You use the secret key to
>> 'encrypt' the user hash. Eg.:
>>
>> ConfirmedEmail.objects.first().encrypted_digest(secret_key=APIKey.objects.first())
>> would return something like this:
>>
>>
>> b'736300027316f304ae86f4a3ea2f7dc6c1ac43a3165a27bc68d96d23e5f109354c1a98b7d00d404bd62bec30caf60ed98e8653385528b23ef27ac110db79ed0dddfcc7c241d98937dc89606e0cce7ca8fed9aa3b1b103fdfc8d61f4bd94b6990400df154'
>>
>> In order to to this manually, you'd have to create the hash from the mail
>> address, encrypt it with the secret key (I'm currently using simplecrypt
>> for this) and hexlify it.
>>
>> Since you don't know the secret key, you have no chance to say what hash
>> is behind that and absolutely no chance to guess the mail address from it.
>> You'd then request from libravatar something like this:
>>
>>
>> /avatar/736300027316f304ae86f4a3ea2f7dc6c1ac43a3165a27bc68d96d23e5f109354c1a98b7d00d404bd62bec30caf60ed98e8653385528b23ef27ac110db79ed0dddfcc7c241d98937dc89606e0cce7ca8fed9aa3b1b103fdfc8d61f4bd94b6990400df154=bgixjymiejsglc5j3aghw3b78qtp7wac
>>
>> And even if you now see the public key and the encrypted hash, you still
>> don't know anything :-)
>>
>> On Libravatar side, we find the corresponding secret key with the public
>> key 'bgixjymiejsglc5j3aghw3b78qtp7wac' and decrypt it. I leave the rest to
>> your imagination.
>>
>> So, now to the bad performance thing. I made some tests and this is the
>> result:
>>
>> Encrypt digest:1.9489854159983224
>> Encrypt digest_sha256: 1.8158956080005737
>> Decrypt digest:1.6850569540038123
>> Decrypt digest_sha256: 1.7364481180047733
>>
>> You see, it almost takes 2 seconds to encrypt or decrypt - that's
>> definitely not going to work on large scale.
>> I've tried to reduce the key length (currently 32) to only 10 or only 4
>> chars, but that's not changing a lot.
>>
>> That means, that I have to probably find a better/faster encryption
>> mechanism, but even if I find some, it will still hurt the performance and
>> shouldn't be used everywhere, but only on security sensitive sites.
>>
>> The next bad thing that comes to my mind is: What about sites that run
>> their own libravatar service? They wouldn't be able to handle this. And one
>> cannot get public/secret key on each of these services => This would be a
>> feature only available on our main instance.
>> The alternative would be, that those sites with some higher security
>> considerations, would encrypt the plain mail address and ask libravatar to
>> decrypt and libravatar would then proxy it back...
>>
>> I don't know... Brain dump end (my excuse if the mail might be
>> confusing...).
>>
>
> I am missing the point encrypting the hash. I could understand it for md5,
> which is crackable nowdays but not quite for sha256. That hash should be
> non-reversible in practical terms and then we can always just jump to
> sha512 in a few years when hardware is stronger
>
> clime
>
>
>>
>> Oliver
>>
>>
>>
>>
>> On Tue, Mar 12, 2019 at 8:00 AM clime  wrote:
>>
>>> On Mon, 11 Mar 2019 at 19:02, Oliver Falk 
>>> wrote:
>>>
 Hi!

 Since I got no reaction on IRC, I'm posting this here as well and would
 love to gather feedback:

  quick poll. fr the people who are eventually are around. if we
 implement something like api-keys (public/private key), that will be used
 for encryption and therefore no longer reveal the mail address hash, this
 will cost more cpu power and I'd therefore not open this feature to _all_
 users. how shall we give this feature to ppl? currently it's implemented as
 group/permission that you can assign to some specific user, but what should
 be the process of
  requesting it and how do we decide if we give this feature to
 someone?

>>>
>>> It sounds interesting but I, personally, would need a little bit more
>>> information how it would be used and for what use-case.
>>>
>>>

 Share you mind, public or private, as you wish :-)

 Thanks a lot,
  Oliver
 ___
 Mailing list: https://launchpad.net/~libravatar-fans
 Post to : libravatar-fans@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~libravatar-fans
 More help   : 

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[clime]

On Tue, 12 Mar 2019 at 12:29, Oliver Falk  wrote:

> Hi!
>
> So, the basic idea, that I already implemented as PoC, is. You request API
> keys and get a public and a secret key. You use the secret key to 'encrypt'
> the user hash. Eg.:
>
> ConfirmedEmail.objects.first().encrypted_digest(secret_key=APIKey.objects.first())
> would return something like this:
>
>
> b'736300027316f304ae86f4a3ea2f7dc6c1ac43a3165a27bc68d96d23e5f109354c1a98b7d00d404bd62bec30caf60ed98e8653385528b23ef27ac110db79ed0dddfcc7c241d98937dc89606e0cce7ca8fed9aa3b1b103fdfc8d61f4bd94b6990400df154'
>
> In order to to this manually, you'd have to create the hash from the mail
> address, encrypt it with the secret key (I'm currently using simplecrypt
> for this) and hexlify it.
>
> Since you don't know the secret key, you have no chance to say what hash
> is behind that and absolutely no chance to guess the mail address from it.
> You'd then request from libravatar something like this:
>
>
> /avatar/736300027316f304ae86f4a3ea2f7dc6c1ac43a3165a27bc68d96d23e5f109354c1a98b7d00d404bd62bec30caf60ed98e8653385528b23ef27ac110db79ed0dddfcc7c241d98937dc89606e0cce7ca8fed9aa3b1b103fdfc8d61f4bd94b6990400df154=bgixjymiejsglc5j3aghw3b78qtp7wac
>
> And even if you now see the public key and the encrypted hash, you still
> don't know anything :-)
>
> On Libravatar side, we find the corresponding secret key with the public
> key 'bgixjymiejsglc5j3aghw3b78qtp7wac' and decrypt it. I leave the rest to
> your imagination.
>
> So, now to the bad performance thing. I made some tests and this is the
> result:
>
> Encrypt digest:1.9489854159983224
> Encrypt digest_sha256: 1.8158956080005737
> Decrypt digest:1.6850569540038123
> Decrypt digest_sha256: 1.7364481180047733
>
> You see, it almost takes 2 seconds to encrypt or decrypt - that's
> definitely not going to work on large scale.
> I've tried to reduce the key length (currently 32) to only 10 or only 4
> chars, but that's not changing a lot.
>
> That means, that I have to probably find a better/faster encryption
> mechanism, but even if I find some, it will still hurt the performance and
> shouldn't be used everywhere, but only on security sensitive sites.
>
> The next bad thing that comes to my mind is: What about sites that run
> their own libravatar service? They wouldn't be able to handle this. And one
> cannot get public/secret key on each of these services => This would be a
> feature only available on our main instance.
> The alternative would be, that those sites with some higher security
> considerations, would encrypt the plain mail address and ask libravatar to
> decrypt and libravatar would then proxy it back...
>
> I don't know... Brain dump end (my excuse if the mail might be
> confusing...).
>

I am missing the point encrypting the hash. I could understand it for md5,
which is crackable nowdays but not quite for sha256. That hash should be
non-reversible in practical terms and then we can always just jump to
sha512 in a few years when hardware is stronger

clime


>
> Oliver
>
>
>
>
> On Tue, Mar 12, 2019 at 8:00 AM clime  wrote:
>
>> On Mon, 11 Mar 2019 at 19:02, Oliver Falk  wrote:
>>
>>> Hi!
>>>
>>> Since I got no reaction on IRC, I'm posting this here as well and would
>>> love to gather feedback:
>>>
>>>  quick poll. fr the people who are eventually are around. if we
>>> implement something like api-keys (public/private key), that will be used
>>> for encryption and therefore no longer reveal the mail address hash, this
>>> will cost more cpu power and I'd therefore not open this feature to _all_
>>> users. how shall we give this feature to ppl? currently it's implemented as
>>> group/permission that you can assign to some specific user, but what should
>>> be the process of
>>>  requesting it and how do we decide if we give this feature to
>>> someone?
>>>
>>
>> It sounds interesting but I, personally, would need a little bit more
>> information how it would be used and for what use-case.
>>
>>
>>>
>>> Share you mind, public or private, as you wish :-)
>>>
>>> Thanks a lot,
>>>  Oliver
>>> ___
>>> Mailing list: https://launchpad.net/~libravatar-fans
>>> Post to : libravatar-fans@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~libravatar-fans
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[Oliver Falk]

Hi!

So, the basic idea, that I already implemented as PoC, is. You request API
keys and get a public and a secret key. You use the secret key to 'encrypt'
the user hash. Eg.:

ConfirmedEmail.objects.first().encrypted_digest(secret_key=APIKey.objects.first())
would return something like this:


b'736300027316f304ae86f4a3ea2f7dc6c1ac43a3165a27bc68d96d23e5f109354c1a98b7d00d404bd62bec30caf60ed98e8653385528b23ef27ac110db79ed0dddfcc7c241d98937dc89606e0cce7ca8fed9aa3b1b103fdfc8d61f4bd94b6990400df154'

In order to to this manually, you'd have to create the hash from the mail
address, encrypt it with the secret key (I'm currently using simplecrypt
for this) and hexlify it.

Since you don't know the secret key, you have no chance to say what hash is
behind that and absolutely no chance to guess the mail address from it.
You'd then request from libravatar something like this:


/avatar/736300027316f304ae86f4a3ea2f7dc6c1ac43a3165a27bc68d96d23e5f109354c1a98b7d00d404bd62bec30caf60ed98e8653385528b23ef27ac110db79ed0dddfcc7c241d98937dc89606e0cce7ca8fed9aa3b1b103fdfc8d61f4bd94b6990400df154=bgixjymiejsglc5j3aghw3b78qtp7wac

And even if you now see the public key and the encrypted hash, you still
don't know anything :-)

On Libravatar side, we find the corresponding secret key with the public
key 'bgixjymiejsglc5j3aghw3b78qtp7wac' and decrypt it. I leave the rest to
your imagination.

So, now to the bad performance thing. I made some tests and this is the
result:

Encrypt digest:1.9489854159983224
Encrypt digest_sha256: 1.8158956080005737
Decrypt digest:1.6850569540038123
Decrypt digest_sha256: 1.7364481180047733

You see, it almost takes 2 seconds to encrypt or decrypt - that's
definitely not going to work on large scale.
I've tried to reduce the key length (currently 32) to only 10 or only 4
chars, but that's not changing a lot.

That means, that I have to probably find a better/faster encryption
mechanism, but even if I find some, it will still hurt the performance and
shouldn't be used everywhere, but only on security sensitive sites.

The next bad thing that comes to my mind is: What about sites that run
their own libravatar service? They wouldn't be able to handle this. And one
cannot get public/secret key on each of these services => This would be a
feature only available on our main instance.
The alternative would be, that those sites with some higher security
considerations, would encrypt the plain mail address and ask libravatar to
decrypt and libravatar would then proxy it back...

I don't know... Brain dump end (my excuse if the mail might be
confusing...).

Oliver




On Tue, Mar 12, 2019 at 8:00 AM clime  wrote:

> On Mon, 11 Mar 2019 at 19:02, Oliver Falk  wrote:
>
>> Hi!
>>
>> Since I got no reaction on IRC, I'm posting this here as well and would
>> love to gather feedback:
>>
>>  quick poll. fr the people who are eventually are around. if we
>> implement something like api-keys (public/private key), that will be used
>> for encryption and therefore no longer reveal the mail address hash, this
>> will cost more cpu power and I'd therefore not open this feature to _all_
>> users. how shall we give this feature to ppl? currently it's implemented as
>> group/permission that you can assign to some specific user, but what should
>> be the process of
>>  requesting it and how do we decide if we give this feature to
>> someone?
>>
>
> It sounds interesting but I, personally, would need a little bit more
> information how it would be used and for what use-case.
>
>
>>
>> Share you mind, public or private, as you wish :-)
>>
>> Thanks a lot,
>>  Oliver
>> ___
>> Mailing list: https://launchpad.net/~libravatar-fans
>> Post to : libravatar-fans@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~libravatar-fans
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

Re: [Libravatar-fans] Discussion: API keys - follow up from IRC

[clime]

On Mon, 11 Mar 2019 at 19:02, Oliver Falk  wrote:

> Hi!
>
> Since I got no reaction on IRC, I'm posting this here as well and would
> love to gather feedback:
>
>  quick poll. fr the people who are eventually are around. if we
> implement something like api-keys (public/private key), that will be used
> for encryption and therefore no longer reveal the mail address hash, this
> will cost more cpu power and I'd therefore not open this feature to _all_
> users. how shall we give this feature to ppl? currently it's implemented as
> group/permission that you can assign to some specific user, but what should
> be the process of
>  requesting it and how do we decide if we give this feature to
> someone?
>

It sounds interesting but I, personally, would need a little bit more
information how it would be used and for what use-case.


>
> Share you mind, public or private, as you wish :-)
>
> Thanks a lot,
>  Oliver
> ___
> Mailing list: https://launchpad.net/~libravatar-fans
> Post to : libravatar-fans@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~libravatar-fans
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp

[Libravatar-fans] Discussion: API keys - follow up from IRC

[Oliver Falk]

Hi!

Since I got no reaction on IRC, I'm posting this here as well and would
love to gather feedback:

 quick poll. fr the people who are eventually are around. if we
implement something like api-keys (public/private key), that will be used
for encryption and therefore no longer reveal the mail address hash, this
will cost more cpu power and I'd therefore not open this feature to _all_
users. how shall we give this feature to ppl? currently it's implemented as
group/permission that you can assign to some specific user, but what should
be the process of
 requesting it and how do we decide if we give this feature to
someone?

Share you mind, public or private, as you wish :-)

Thanks a lot,
 Oliver
___
Mailing list: https://launchpad.net/~libravatar-fans
Post to : libravatar-fans@lists.launchpad.net
Unsubscribe : https://launchpad.net/~libravatar-fans
More help   : https://help.launchpad.net/ListHelp