Unify contact email addresses for addon/extension #13755
Comments
|
@brainwane Or maybe -- counterargument -- we should have different email addresses for different contact points, as a sort of metadata about the user who is sending the email. For example https-everywhere-chrome@eff.org for the Chrome version, https-everywhere-firefox@eff.org for the Firefox version, https-everywhere-eff@eff.org for the EFF-hosted version. I'm not convinced this is better, in fact it probably isn't, but it's just an idea. Another email address we should unify, from https://www.eff.org/https-everywhere , is https-everywhere-rules@eff.org (written on the page as "https-everywhere-rules AT eff.org"). We should not have any Gmail addresses, because All project email addresses should have public GPG keys associated with them that are clearly published somewhere at https://eff.org/https-everywhere as well as the major keyservers. There shouldn't be the old-school "AT" obfuscation for email addresses when writing them on https://eff.org. The EFF should improve its spam catching functionality instead. |
|
I'm fine with having different email addresses for those different contact points to add metadata about how people got to the email address (although of course there'll be some noise, since some people will stumble across the address even though they aren't using that particular extension). I see https://lists.eff.org/mailman/listinfo/https-everywhere-rules has gotten zero new email since January 2017, so I would be fine with closing it down -- @Hainish, does it exist in order to provide a means of contributing rulesets for people who don't want to use GitHub? If so, I'm in favor of keeping it. Agreed that it'd be much better to have Ideally, yes, it would be great to have public GPG keys for each address. I'm happy to file a separate issue about that. While I agree that it would be great for EFF to improve its spam filtering, and thus to reduce the need to obfuscate email addresses, I'm also aware that an org like EFF gets a bunch of legitimate email that's weird on various axes in ways that confuse spam filters. So, as with the GPG key suggestion, I'd be happy to file a separate issue so rearranging the addresses doesn't have to wait for it. |
|
Hi everyone
The issue was opened by brainwane but I think I (brainwave) got included by
mistake. Just pointing it out because I don't think he is getting these
emails!
Cheers,
Brahm
…On Nov 28, 2017 5:12 AM, "Sumana Harihareswara" ***@***.***> wrote:
I'm fine with having different email addresses for those different contact
points to add metadata about how people got to the email address (although
of course there'll be some noise, since some people will stumble across the
address even though they aren't using that particular extension).
I see https://lists.eff.org/mailman/listinfo/https-everywhere-rules has
gotten zero new email since January 2017, so I would be fine with closing
it down -- @Hainish <https://github.com/hainish>, does it exist in order
to provide a means of contributing rulesets for people who don't want to
use GitHub? If so, I'm in favor of keeping it.
Agreed that it'd be much better to have @eff.org addresses and avoid @
gmail.com addresses.
Ideally, yes, it would be great to have public GPG keys for each address.
I'm happy to file a separate issue about that.
While I agree that it would be great for EFF to improve its spam
filtering, and thus to reduce the need to obfuscate email addresses, I'm
also aware that an org like EFF gets a bunch of legitimate email that's
weird on various axes in ways that confuse spam filters. So, as with the
GPG key suggestion, I'd be happy to file a separate issue so rearranging
the addresses doesn't have to wait for it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13755 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB_1GNp-1iDuO72ojnL9godngcuxhD4oks5s60j9gaJpZM4QqneD>
.
|
|
Hi, @brainwave. Thanks for the heads-up! I did get notification email regarding this issue; thanks. (I'm a woman, just so you know.) You can feel free to unsubscribe from notifications for this issue & anything else in this repository where you got pinged by mistake. :) |
|
@brainwave in 4db81ad, I did change the email address to an In d97d5ab, I had to change the email back. However, it looks like this is only used in the self-hosted Firefox UI. We should change the In the Chrome Web Store, I can change the display email address from |
|
Hi William,
I am being erroneously included, I think you want to tag brainwane and not
brainwave. I did remove myself from the thread but I get included again if
I am specifically tagged!
Have a good day!
Cheers,
Brahm
…On Nov 28, 2017 6:33 AM, "William Budington" ***@***.***> wrote:
@brainwave <https://github.com/brainwave> in 4db81ad
<4db81ad>,
I did change the email address to an @eff.org email in the author field
of manifest.json, but I encountered some problems while making a release
in the Chrome Web Store (CWS). ***@***.*** is the
email we use to make releases on CWS. Changing that to a different email
causes an error when uploading an updated crx file.
In d97d5ab
<d97d5ab>,
I had to change the email back. However, it looks like this is only used in
the self-hosted Firefox UI. We should change the make.sh script to modify
the author field email only for the Firefox build, not for Chrome.
In the Chrome Web Store, I can change the display email address from
***@***.***, but this is used for both Privacy Badger and HTTPS
Everywhere alike. If we do change this, it'll have to be to an email
commonly administrated by both projects.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13755 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB_1GKUUegVJeZhf9jLQN6q1czb0zlk5ks5s61vwgaJpZM4QqneD>
.
|
|
Sorry for the disturbance! @brainwane this time. |
|
(I also erroneously tagged |
|
The GPG question and this question are related, because each email address will need its own key, or multiple addresses will need to be added to the same key. So if the EFF doesn't want to do either of those things, then it should reduce the number of email addresses used. |
|
For the spam filter thing, the issue is that the EFF should make all its addresses available in some obvious way. The current approach of burying obfuscated addresses in a big paragraph midway down the main page is not obvious. |
|
In any case, this should also be added to the https://www.eff.org/about/contact page. That's the canonical place for non-personal points of contact. |
|
From https://www.eff.org/about/contact it looks like vulnerabilities@eff.org is also (partly) an HTTPS Everywhere address. |
Yes, kind of. It's the e-mail address to report vulnerabilities. Though I think the optics of setting that as our primary point of contact for the extension is less than ideal. |
|
I agree, but if @brainwane is making a comprehensive list of HTTPS Everywhere email addresses, it should probably go on that list. |
…rx should remain eff.software.projects@gmail.com (see #13755)
|
I've updated Chrome Web Store and AMO to have This should unify all points of contact for the extension. Closing this now. |
|
I also suggest that the GPG key be included in the "Feedback" section at https://www.eff.org/https-everywhere. |
Type: other
Right now, the contact email addresses for HTTPS Everywhere in the Chrome store, on addons.mozilla.org, and on eff.org differ.
The contact email in the Chrome web store is: info@eff.org
@Hainish looked at the self-hosted Firefox extension downloadable at http://eff.org/https-everywhere/ (and as included in the Tor Browser) and found that it uses the contact email address: eff.software.projects@gmail.com
On addons.mozilla.org, the contact email is https-everywhere@eff.org .
It's probably best to use one unified address, and I suggest it should be an eff.org address that's regularly forwarded to the team that maintains this repository; https-everywhere@eff.org seems most likely the right choice.
The text was updated successfully, but these errors were encountered: