215439 - Provide alternate method for bugzilla users to contact each other, prevent spam by not showing email addresses

Status: NEW

(Bugzilla :: User Interface, enhancement)

Description

[Stephen Ostermiller]

This bug is a spinoff of bug 120030 which is going to be solved by obfuscating
email addresses to make them harder to harvest.

I intend to provide a patch for this bug.

Comment 1

[Stephen Ostermiller]

I proposed a patch for this with attachment 129331 [details] [diff] [review].

Timeless found some problems with the proposed patch and I would like to examine
them:

> first, if you used this feature to contact me based on 
> the contact info for the comment which i'm writing now 
> you'll trigger mail to somewhere that doesn't exist.
> 
> This is actually typical for me. And I don't intend to 
> change it just because you think you've 'solved' 'the 
> problem'. The reason my accounts are setup as
> they are has very little to do with spam.
> 
> second, try contacting [e-mail] or 
> [e-mail] There's absolutely no person who 
> owns these accounts, and there's certainly no
> maildrop for them.

If you have an email address that cannot recieve email:
1) That is fairly useless
2) How did you set up a bugzilla account with it since you would have had to
reply to an email.
3) How is it any different if a user sends email from a form or from their mail
client?

> third, the correct way to contact me is by triggering mail 
> to my shadow(s), this is how you should contact the 
> .bugs accounts too.
>
> Yes I know that requests are broken and don't do this. That's 
> a bug and if I controlled bugzilla I would have blocked their 
> landing until they included correct mail generation. 

Please expand upon this point, I do not know what a shadow is in the context of
an email account.

> fourth, you don't honor any pref so that people can refuse 
> to get mail from this thing (sending mail to any of the .bugs 
> accounts which i setup is a violation of their configuration 
> which explicitly says that they don't want mail). everything 
> except requests does and again see caveat about requests
> being evil and broken and ...

A pref to say that a user does not want to be contacted by other users
would be useful.  I did not examine the existing preferences to see
if there were one that I could use.  If so I will use it, if not
I will not use it.

> fifth, 
> the email has no bounce information and doesn't appear 
> to implicate bugzilla-daemon. 
>
> sixth,
> how does someone who generates an email find out if the email bounced?

The email comes from the user that sent the email, not from bugzilla.
A bounce would be returned to the sender.  The email does say that bugzilla
generated the mail in the headers.  It lists plenty of information such
as the version of bugzilla, the bugzilla server, the script path, and
the server administrator.

> technical nit about the patch:
> we aren't living in 1998 anymore:
> +  # The Initial Developer of the Original Code is Netscape Communications
> +  # Corporation. Portions created by Netscape are
> +  # Copyright (C) 1998 Netscape Communications Corporation. All
> +  # Rights Reserved.
> 
> In fact, NSCP doesn't exist either. please use a correct MPL template and fill
> in a valid date.
> 
> http://www.mozilla.org/MPL/boilerplate-1.1/mpl-sh

Will fix this.

> What should you do?
> see one of the features described in my votes proposal since the preceding are
> addressed by it.

Where can I fond your votes proposal?

Comment 2

[Stephen Ostermiller]

Attachment: Proposed Patch, provides contact.cgi

Proposed patch against the CVS tip that provides contact.cgi.
This patch replaces attachment 129331 [details] [diff] [review].	This version corrects two issues raised
by timeless:
1) License Boilerplate.
2) Preference to disable email.

Comment 3

[Christian Reis]

Is there a live version of this somewhere?

Comment 4

[Stephen Ostermiller]

I only have a machine that is behind NAT, so I can't accept incoming connections
from the outside world.  I don't have a working version up that you can access.

Comment 5

[timeless]

1) That is fairly useless
Not at all.
2) How did you set up a bugzilla account with it since you would have had to
reply to an email.
For [e-mail] (long dead) and [e-mail] (dead) the accounts
/were/ valid at the time when they were created. In the case of mac.com apple
changed its policy and asked for money after a time the account was deleted.

I think bemail.org just stopped servicing mail entirely. i didn't bother to look.

for .bugs accounts an admin renamed the account. At some future point I might
actually be able to create local .bugs. domains so they are legal/valid, but
again no one should try to directly contact them as nothing useful will happen.

3) How is it any different if a user sends email from a form or from their mail
client?
Hrm, your response to point six solves one problem, but replaces it with
another, i'll address it there.

well, if someone wants to contact me (and you can tell that i got bugmail for
this bug) they simply cc the account and it goes to the shadows. pay attn to the
bug comments sent to page and you'll at least see the shadow i use.

shadows are technically 'watch' fields, you can find them in the bugmail
preferences if they're enabled.

fifth/sixth, ok. so that means that if /I/ want to send mail to another person
like me (perhaps a .bugs account) then /I/ won't get a bounce notification
because it'll go to @bemail.org which doesn't exist. That's not very nice.

fwiw my vote proposal is bug 214018.

Here's a simple way to handle email conversations:
enter_bug.cgi?type=discussion
each discussion gets a random id and is stored in bugzilla. discussions can be
deleted and rely on groupsets and stuff to handle confidentiality, they default
to allowing only people who would get mail from them to see them. discussions
are automatically deleted after three months of inactivity. A notice is sent to
all addressed people one month before the discussion is deleted. For people who
log in during the one month interval before a discussion will be deleted there
will be an item in the status bar "dying discussions" or something. This allows
people who don't use bugmail but who do use bugzilla to see discussions they
might want to archive. because a discussion uses a random id there is no problem
with deleting it. whether discussions could be linked to bugs would be
negotiable. (iow i don't care and haven't considered it.) discussions of course
act like bugs wrt mail generation (although an additional mail pref[s] about
discussions could be added). Discussions would probably require editbugs to
create, although the required priv should be installation configurable. the
hazard is that we start competing with slash or forums or whatever.

i'm on vacation and i'd like my points addressed before i do a review.

Comment 6

[Stephen Ostermiller]

Existing methods of contacting people (except mailto links) will remain after
this bug is fixed.  Posting a bug comment or otherwise modifying something in
bugzilla will send out email in the same manner that it always has.

Similarly, discussion systems could coexist nicely with this patch.  Currently
if you want to contact somebody you have two options:
1) Comment on a bug they are watching
2) Click on a mailto: link and send them email.

In the future the options might be more varied.
1) Comment on a bug they are watching (if they have permission)
2) Click on the contact link to contact them directly (if the user wants to be
contacted).
3) Start a discussion and invite them.

The only method that I want to replace is the mailto link which shows the world
(and hence spammers) my email address.  Spam that comes in the form of "me too"
comments on bugs will have to be addressed by a different patch.

Again, this patch is designed soley to prevent the harvesting of email
addresses.  It is not designed to prevent people from writing inane bug comments
or from whining that a bug isn't fixed yet.

As for folks that have bugzilla login ids that are no longer working email
address, for the most part, having somebody contact that address is little
different than having a mailto: address that somebody uses.  In either case the
person trying to contact them will get a bounce message.

As for folks who's login is no longer a working email address, but want to
recieve bounce messages when bugzilla sends out mail on their behalf, there is a
work around.  Change the login name so to some valid email address.  Bugzilla
now has the ability to change login name.

This patch is designed to be an eventual replacement for mailto links.  If I
click on a mailto link, I expect that mail to go to a specific address, and not
be broadcast to others.  Conversely, if I sign up for a bugzilla account, I
expect that others cannot snoop private messages sent to me by watching my
account.  As such, I would expect contact.cgi not to send out additional email
to watchers.

Comment 7

[Matthew Elvey]

"Again, this patch is designed soley to prevent the harvesting of email
addresses.  It is not designed to prevent people from writing inane bug comments
or from whining that a bug isn't fixed yet"

Ah, so timeless was making comments that made no sense (to me either) because he
didn't realize this!

Now that that's cleared up: Anyone still have objections?

What about http://bugzilla.mozilla.org/show_bug.cgi?id=120030#c108? (A comment
on the parent bug.) I'm not clear on whether the enhacements addressed the
performance concerns.

Comment 8

[timeless]

my objections still stand. contact me on irc sometime next week.

Comment 9

[Gervase Markham [:gerv]]

I object to the removal of email addresses, as they are (on occasion) a useful
way of sending someone a private message, and I want to use my fully-featured
email client, not some poxy web form. :-)

Obfuscation (bug 120030) should be fine.

Gerv

Comment 10

[Stephen Ostermiller]

> Obfuscation (bug 120030) should be fine.

Recent studies have shown that this reduces spam, but it does not eliminate it.
 The solution to that bug is only a stopgap measure.  Given the number of people
that are now using that technique, spammers are updating their spiders to be
more insidious.

This patch provides a backend mechanism for the web proxy, but it does not
prescibe its use.  I envision that users may have options for who they want to
hide their from.  IE, hide from all, hide from those who are not logged in, hide
from all except those in a list, etc.

In any case, after you send a message to somebody and they reply to you, your
full featured email client will take over from there.

Comment 11

[JoSH Lehan]

This would be a long shot, but a possible solution to the problem of Bugzilla
email address harvesting would be to use a captcha.

http://www.captcha.net/

Email addresses would be hidden by default, but any user can request to see an
email address at any time.  The catch is that the user would then have to pass a
captcha test in order to view the email address.

A captcha is another way of doing email address obfuscation, but with graphics
instead of text.  It is much more difficult for spammers to break, and if the
captcha is passed, the email address can then be shown in the clear (so
clickable links will still work).

A good captcha is easy for a human to read, but almost impossible for a computer
OCR program to read.  This will still allow people to have easy access to email
addresses, but prevent spammers from harvesting them in bulk.

There are 2 big problems with this, though: it might be difficult to integrate a
captcha into Bugzilla, and it would deny service to blind people and others who
can't view images.  However, I wanted to make sure that all people reading this
bug are aware of what a captcha is and what it can do.

Comment 12

[Jeroen Besse]

Obfucating as it is now, clearly isn't enough. After changing my email-address 2
weeks ago, I today received spam to that address. Note: this address was new and
isn't used anywhere else.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

Jeroen: bugzilla.mozilla.org, at least, does not do any obfuscation...

Comment 14

[Patrick]

Admittedly having not read the entire conversation, but will this bug [the
"prevent spam" part of the summary] not be explicitly fixed by bug 219021?

Comment 15

[timeless]

Comment on attachment 129400 [details] [diff] [review]
Proposed Patch, provides contact.cgi

per comment 5 and comment 8
this r- was taken to make vladd happy.

Comment 16

[Dave Miller [:justdave]]

*** Bug 229825 has been marked as a duplicate of this bug. ***

Comment 17

[Dave Miller [:justdave]]

*** Bug 253602 has been marked as a duplicate of this bug. ***

Comment 18

[Thomas D. (:thomas8)]

Stephen, are you still working on this bug?

Otherwise, assigned-to should be set to nobody.
More than 6 years later, and we still need a fix for this!!!

Comment 19

[Frédéric Buclin]

Leave the severity of this bug alone. This is not a critical problem but a RFE.

Comment 20

[Stephen Ostermiller]

I provided a patch, however I'm not willing to put more work into it because I get the impression that some maintainers do not support this enhancement, and the patch will never be good enough.

Comment 21

[Jérôme Bouat]

I think this bug is critical because it makes a security hole into the worlwide mail system.

Comment 23

[srareczek]

I voted for this bug to bring more attention to it. It's especially important since the biggest open source projects use Bugzilla as their bug tracker, for instance KDE, Firefox and Wine.

Comment 24

[Yuri]

I don't really get the situation with this bug.

JavaScript fix would probably be quite minor change which will fix maybe 95% of the issue since most e-mail harvesters can't really run JavaScripts I would assume due to technical difficulty of doing this. And patch already exists for about a year. And later additional solutions/improvements can be added as well, they aren't mutually exclusive.

Yet nothing is done with this PR for 78 years (OP date is 2003-08-07) and Bugzillas in many places keep exposing people's e-mails and attracting spam.

Comment 25

[Yuri]

Sorry for typo above, 7 years, not as bad as 78 years would be :-)

Comment 26

[Frédéric Buclin]

I personally think hiding email addresses would slow down or even prevent communication between developers. I want to send emails from my email client (to easily keep track of emails I sent, and to easily tag them), not from some web form. I want to be able to easily reply *by email* to someone else, without having to open my web browser and file some form again to reply.

Since Bugzilla 3.4, email addresses are *not* displayed to logged out users. So this severely decreases the risk to spam your email address. I'm personally a heavy user of several Bugzilla, and I get mostly *no* spam on the addresses I use. Probably a lot of spam is sent, but they are filtered by e.g. Gmail and other providers.

So I would be against a solution that reduces productivity.

Comment 27

[Yuri]

Frédéric, JavaScript solution *doesn't hurt productivity* at all. You will see the addresses, but almost all spammers scripts won't.

Also allowing only logged in users to see e-mails is a very weak protection since bugzilla only asks for e-mail confirmation. It doesn't even show any pictures with words to check if this is human that is creating an account. Account creation can be completely automated and this is another bugzilla vulnerability.

Comment 28

[Frédéric Buclin]

(In reply to comment #27)
> Account creation can be completely automated and this is another bugzilla
> vulnerability.

This is not a *vulnerability*. We already had other discussions about captchas and their pros and cons. But that's unrelated to this bug.

Comment 29

[Gunnar Wagenknecht]

(In reply to comment #26)
> So I would be against a solution that reduces productivity.

+1.

It's a catch-22. The JavaScript adds additional complexity. Robots will be able to parse that. It's just a matter of time. IMHO any kind of SPAM really is best addressed at the mail server/inbox level.

Comment 30

[Guy Pyrzak]

Something that Frederic brought up is that we now have web-services and XML bug formats, both of which expose emails to users that are logged in. 

Since Javascript and captchas are not very useful for either of those formats. I'm not sure if obfuscating the HTML really helps anything unless we remove emails from anything but the html format, which would hurt XML format and web-services.

I do like the idea of adding a captcha or captcha extension to make automated user creation harder. The only other option that seems reasonable is what justdave mentioned, which have the option to treat logged in users like logged out users unless they have a particular security level.

Comment 31

[Jérôme Bouat]

Spam has to be fight by simultaneous and complementary ways :
- application level filters
- net address filter according to black-listed networks (spamcop.net, signal-spam.fr, ...)
- ...
- and avoid to show a private emails on any web server

For example, Openoffice is actually hidding emails by using fake emails ([e-mail]). With such solution they can filter possible spam with several methods (application, net address filters, etc).

I think spam fighting has to be handled into Bugzilla. The first step would be to hide the private email address (even to logged in user, possibly spammers). A web form could relay private communication between the Bugzilla users. Into this form, each user could give its private email address. But please keep the choice to the user.

Comment 32

[Jean-Marie COUPRIE]

12 years after and no solution to hide email address !
Most forums (except Mozilla distribution lists) hide emails and give just a form called Personal Message.
If you have frequent contacts and wish to use Thunderbird use just once the PM to obtain the email !