Email address obfuscation/truncating

[daniel]

When displaying email addresses in ticket views, Trac should obfuscate the addresses to fool spambots, goblins and evildoers.

• If logged in, the whole addresses should be shown.
• A good scheme (used by various list archivers) is translating some.one@… into some.one@…

[micke@…]

How would you then know who to contact (at least until email notifications are sent out).

[cap]

I started on a solution and ran in to problems with the cc field. These arose because I was trying to support multiple entries; if the intention of cc was to contain only a single user, or if that would be a reasonable restriction to impose, I can make my solution work.

Otherwise, as cc is open for editing, populating it with a value other than that in the database will cause an erroneous change unless save_changes filters for these values. But that's problematic: how do you match the altered version with the saved version? Since the altered versions may be ambiguous (abc@… and abc@… both map to abc@…, for instance), it seems a different solution is needed.

Making cc read- or add-only for non-authenticated users would clear this up. Any other ideas?

[moschny@…]

Why mangling E-Mail addresses at all?

There is some discussion of this topic here: ​http://c2.com/cgi/wiki?NameMangling.

Of course other, more efficient techniques are needed to fight against spam, but meanwhile we should not make it too easy for those address grabbers. Even the simplest mangling, e.g. replacing all non alphanumeric characters in an address (like '@' and '.') with human-readable equivalents (like 'at' and 'dot') will help. On-the-fly rendering it with a funny font into to an image is a possibility, too.

The mangling should be made in such a way that it is unambigous for a human reader.

[xris(a)siliconmechanics*com]

marked #1448 as a dupe.

I'd warn against using "at" or "dot" — the spam harvesters are surely smart enough to pick that up now. My personal preference lately is to replace @ with (a) and . with * or (o). Image-based is of course the best way to hide the address from spammers, but does cause trouble for people who like to copy/paste the address.

[anonymous]

Marked #1638 as a duplicate.

[Gunnar Wagenknecht <gunnar@…>]

I also don't like the idea of cutting the email address. I dislike the tools/newsgroup/list archives doing this. It's really difficult if you can't read the full email address and want to contact the person.

[Sean]

I also don't like the idea of cutting the email address. I dislike the tools/newsgroup/list archives doing this. It's really difficult if you can't read the full email address and want to contact the person.

As the original author implied, there are a number of browsing modes, and an ideal implementation would allow a per-installation configuration of which mode is used:

1. Emails obfuscated, except for people with permission to view them (developers), who see the emails fully expanded.
2. Emails obfuscated, except for people who are logged in.
3. Emails are not obfuscated

Personally, I refuse to give my email address to web sites that don't obfuscate email addresses, which means that it's going to be even more difficult for you to contact me than if my email were obfuscated :-)

Anyway, here's a big +1 vote for this feature.

[anonymous]

Easy solution is to provide two images, an . and an @. They would be set in the CSS files as something like:

.at {
  width: 8px;
  height: 1em;
  background: url( "images/dot.gif" ) no-repeat;
}
.dot {
  width: 3px;
  height: 1em;
  background: url( "images/dot.gif" ) no-repeat;
}

When you replace the e-mail address, it is done so as:

myuser<img src="blank.gif" class="at" alt="@" />myserver<img src="blank.gif" class="dot" alt="." />com

If a user copies it, most e-mail applications will use the alt="" text.

This doesn't solve clickable links, though. You'd need some kind of JS for that.

[Christian Boos]

For a possible Javascript solution, see r2200 (this was reverted in r2201, though).

[Barclay]

So, what about solving of this SPAM problem? If mangling is too complicated or more time is needed to choose proper solution for mangling, maybe it could be solved simpler. I.e. for me it could be enough to get new configuration option. If this option is set to true only usernames are shown for not authenticated users, but emails hidden. If it is set to false, everything works as it works now.

[Christian Boos]

Marked #2447 as duplicate of this one, among others.

[anonymous]

I agree with the sentiment of the original ticket:

• No changes to the database need to be made
• If a configuration parameter is enabled, then un-logged in users see abbreviated/munged versions of all the e-mail address. Logged in users can see the full addresses.
• If the configuration paramter is not enabled, then everything works just as it does now (i.e., e-mail addresses are not abbreviated or munged).
• Perhaps an additional configuration parameter can be provided to distinguish between:
  • abbreviated: "foo@…"
  • munged: "foo (at) bar (dot) com" (or pick your favorite munging style)

I have not looked into the trac source code at all, but I'm guessing that the final rendering of the e-mail address in can't be too hard…?

Per the point above that abbreviated addresses are annoying to random 3rd parties, consider the poster's bias: if the developers want feedback, they will provide a mechanism to get it. For example, they can allow anonymous posts to the ticket (which may result in mailing the poster anyway), or provide an alternate mechanism such as a support mailing list. My point: direct e-mail is one option for contacting someone; it may not be the only option (and depending on that someone, direct e-mail may not be the preferred method of contact). If Trac gets this feature, it gives the owners of the system the flexibilty to decide which model they want to use.

I too, try very hard not to give my e-mail address to web sites that publish it (which is why I didn't include my address on this report :-( ). We just started using Trac for our open source project (​http://www.open-mpi.org/) and just discovered that it's showing all the CC addresses to the world. Big bummer.

So here's my +10 vote for this feature. :-)

[Sid Wiesner]

One difficulty I see in solving this is how to handle the cc list. Currently, everyone just appends their email onto the list when they want to be cc'ed on a ticket. If mangling or obfuscating the list, what is shown in the Cc change ticket properties field? If the addresses are all mangled and I add mine, it will look very inconsistent, so I might be tempted to add "me (at) this (dot) com" instead of a valid address just to conform with the other addresses listed.

Another option is to hide the cc contents and the cc field then becomes a "add only" type of field. But then you have the problem that you cannot remove yourself from the list if you want to.

[quad]

An add-only field to add your email address, and a remove-only field to remove your email address. (Or only one text field with two buttons: Add, Remove; you click what you need.)

It has the extra security that someone cannot mess arbitrarily with other people's email addresses, which will be unknown anyway to non-authenticated addresses.

[sid <sid.wiesner@…>]

#1459 addresses a way to redesign the cc field that should address my concerns. The only email address that is editable will be your own. If that is the case, then it seems that this only becomes a problem of presentation of email addresses..

[jgoerzen@…]

This is not the only place where it is a problem.

I also see it popping up in changelog bodies. In darcs, the changelog author typically contains an email address, and it pops up there as well.

So whatever solution is devised should apply to more than just the ticket system.

[Emmanuel Blot]

See #4413 for a patch proposal.

[gunnar]

Replying to eblot:

See #4413 for a patch proposal.

Mhm. I'm not on the CC list of this bug. So why did I receive a notification mail for the last comment?

[sid]

I also got an email and I'm not in the cc list.

[Christian Boos]

I guess TracNotification always_notify_updater must be active on t.e.o.

[sid]

From TracNotification: always_notify_updater: (since 0.10) Always send a notification to the updater of a ticket.

So I should only get emails for my ticket updates. But I'm getting them for eblot and gunnar's comments as well..

[moschny]

Replying to sid:

From TracNotification: always_notify_updater: (since 0.10) Always send a notification to the updater of a ticket.

Got mails for all today's updates of this ticket, too. So maybe the description of always_notify_updater should read: "… to the updaters of a ticket", meaning that everyone who updated a ticket once will get mails from that moment on?

[Waldemar Kornewald <wkornewald>]

Replying to eblot:

See #4413 for a patch proposal.

That patch doesn't obfuscate addresses. It doesn't show emails in *RSS* feeds, at all (Cc field is untouched, though).

[Waldemar Kornewald <wkornewald>]

Now, I wanted to reopen my ticket, but more people are listening here. This is not about obfuscating emails. This is about not exposing them, at all.

If you expose emails in RSS feeds why do you hide them on normal HTML pages? I'm not talking about the Cc field, but the author.

Why do you want to expose email addresses, at all? Why do you not create wiki pages where you list emails for those who want it? You're making it far too easy for spammers and I'm sure that most Trac users don't even know that their email is accessible so easily via the RSS feed (and some will wonder why they get more spam…).

I think that it's absolutely not necessary to make the email visible (even obfuscated). If someone wants to talk about a ticket then he should add a comment. If someone wants to contact the developers then he should use IRC or the mailing list. That way, he reaches all developers instead of only one of them.

Ideally, with #2456 you could click on the username to get to the user's details page where you can send him a message (possibly secured with a captcha). That would provide what you need in IMHO *rare* cases.

[Emmanuel Blot]

Well, feel free to re-open your ticket, but again, the proposed patch is far too restrictive.

think that it's absolutely not necessary to make the email visible (even obfuscated).

• there are several public RSS feeds that contain real email address.

Why do you want to expose email addresses, at all?

• Trac is also used in private networks where hidding email address would be non sense. Any Trac installation which serves a company's intranet for example.

These are at least two reasons why obfuscating/truncating/hiding/… altering in any kind email addresses is not an acceptable option.

Trac does need a way to hide email addresses for sure. The way the email address is not made public does not really matter. Obfuscating, truncating, hiding, not resolving the login into the email address, … are several ways to achieve the same goal, IMHO

Email addresses could be hidden for ticket and/or for RSS feeds, that why I closed your initial ticket as a duplicate of #153, but if you think there are not related, feel free to re-open the original ticket.

A note about spam: as long as mailing lists, and mailing list archives exist, hidding email address from the RSS feed won't save you from being spammed - at least with on t.e.o. ;-) This does not invalidate the need for hiding email addresses, of course.

[Emmanuel Blot]

Replying to eblot:

These are at least two reasons why obfuscating/truncating/hiding/… altering in any kind email addresses is not an acceptable option.

This is confusing. I meant to force obfuscation. This should be an option.

[Waldemar Kornewald <wkornewald>]

patch against trunk (r4463)

[Waldemar Kornewald <wkornewald>]

Is this better? I haven't tested it, yet. I'm not sure whether I'm using the Genshi stuff very well. There must be a more elegant way to have an if-else case. Is that py:choose?

[Christian Boos]

Replying to wkornewald:

… There must be a more elegant way to have an if-else case. Is that py:choose?

See TracDev/PortingFromClearSilverToGenshi#if...then...else (pick the second form, of course).

About the patch: please pay attention to the users = [''] # for clearing assignment line that you removed. I'm quite sure it was there for a reason. Well, only testing could tell ;)

Also, you added <dc:creator> elements, I'm not sure whether that shouldn't rather be filled with the ticket reporter rather than the ticket updater (i.e. the resource creator vs. the resource editor).

Finally, you could take the opportunity of this patch to move the email map stuff in trac.util, while waiting for a better place (part of your suggested user refactorings?)

[Emmanuel Blot]

Replying to cboos:

Finally, you could take the opportunity of this patch to move the email map stuff in trac.util, while waiting for a better place (part of your suggested user refactorings?)

I think we should not rush to move email mapping related stuff in another file, as the IUserDirectory interface would probably have an impact on email mapping as well.

[Waldemar Kornewald <wkornewald>]

Replying to cboos:

Replying to wkornewald:

… There must be a more elegant way to have an if-else case. Is that py:choose?

See TracDev/PortingFromClearSilverToGenshi#if...then...else (pick the second form, of course).

Thanks! I'll try to fix it tomorrow.

About the patch: please pay attention to the users = [''] # for clearing assignment line that you removed. I'm quite sure it was there for a reason. Well, only testing could tell ;)

I enabled restrict_users and noticed that there were two empty entries. As you can see, field['optional'] = True, so this one will already add an empty entry.

Also, you added <dc:creator> elements, I'm not sure whether that shouldn't rather be filled with the ticket reporter rather than the ticket updater (i.e. the resource creator vs. the resource editor).

The comment and the changes are all created by the ticket updater, so IMHO it should be like that.

Finally, you could take the opportunity of this patch to move the email map stuff in trac.util, while waiting for a better place (part of your suggested user refactorings?)

Like eblot said, I plan to do this differently with the IUserStore interface. If you have a lot of users (e.g.: every user has to register) you'll get too many unnecessary DB lookups because you must retrieve the email address for each user (instead of each ticket change).

[Waldemar Kornewald <wkornewald>]

patch against trunk (r4466). this time I tested it

[Christian Boos]

Second patch looks good to me.

What was the rationale for doing that only at the RSS level, again? Maybe the approach could be extended to the .html templates as well.

[Waldemar Kornewald <wkornewald>]

Replying to cboos:

Second patch looks good to me.

What was the rationale for doing that only at the RSS level, again? Maybe the approach could be extended to the .html templates as well.

The email was only exposed at the RSS level which I found very strange. I wanted to fix that. Could you please commit my patch. I want to continue my work on IUserStore. The more I work on other patches the more work I'll have with adjusting the IUserStore patch.

[Christian Boos]

Ah, right, it was only at the RSS level that we tried to retrieve the e-mail if it wasn't already there. In .html templates, we simply show the e-mail if it's already part of the author information.

Still, we could do a simple check along the lines of if '@' in author ... to cut-off the remaining parts of the e-mail (as suggested above) when show_email_addresses is false.

Plus, I'd place that option in [trac] directly, as this should be a general policy; asking for a [ticket] config option from trac.versioncontrol.web_ui.log doesn't look correct.

[gunnar]

Replying to cboos:

I guess TracNotification always_notify_updater must be active on t.e.o.

Can you please turn this option off as long as Trac does not have proper user configurable options for this?

[Waldemar Kornewald <wkornewald>]

Replying to cboos:

Ah, right, it was only at the RSS level that we tried to retrieve the e-mail if it wasn't already there. In .html templates, we simply show the e-mail if it's already part of the author information.

Still, we could do a simple check along the lines of if '@' in author ... to cut-off the remaining parts of the e-mail (as suggested above) when show_email_addresses is false.

If at all, this should only happen for anonymous users. Otherwise admins will enable the option just to be able to see the user's email address.

Plus, I'd place that option in [trac] directly, as this should be a general policy; asking for a [ticket] config option from trac.versioncontrol.web_ui.log doesn't look correct.

Where should I place the BoolOption, then? Leave it in ticket/web_ui.py or somewhere else?

[Waldemar Kornewald <wkornewald>]

patch against trunk (r4475). tested, seems to work

[Waldemar Kornewald <wkornewald>]

argh! noticed an unnecessary import…

[Waldemar Kornewald <wkornewald>]

Please try it. This should work as expected. I also added a new permission 'EMAIL_VIEW' for people who still want to see addresses without obfuscation (when show_email_addresses is false).

[Christian Boos]

Thanks, looks really good now.

[Waldemar Kornewald <wkornewald>]

fixed an issue with the "Reply" function not obfuscating email addresses

[Waldemar Kornewald <wkornewald>]

I hope you still receive this. :)

[John Goerzen <jgoerzen@…>]

One thing I'm not clear on: does this patch also block emails that occur within changelogs and wiki pages, or is it only for the bug tracker?

[Waldemar Kornewald <wkornewald>]

Replying to John Goerzen <jgoerzen@complete.org>:

One thing I'm not clear on: does this patch also block emails that occur within changelogs and wiki pages, or is it only for the bug tracker?

If everything is correct, it should block everywhere. Wiki pages, changelogs, attachments, tickets, …

[Waldemar Kornewald <wkornewald>]

Oh, I misunderstood. The contents of wiki pages and changelogs aren't blocked…

[John Goerzen <jgoerzen@…>]

OK. This is a good step on the road then. I would suggest that this ticket shouldn't be closed until a patch is committed that addresses changelogs and wiki pages as well. Especially since some VCS (such as darcs) use an email address for the patch author.

[Waldemar Kornewald <wkornewald>]

It should be very easy to obfuscate the commit author. But is it really worth to obfuscate the commit message and wiki page contents? The developers could take care of this. I think that there are cases where content obfuscation is harmful (esp. on wiki pages).

[John Goerzen <jgoerzen@…>]

I could agree with you that wiki pages aren't as important.

Commit messages, though, I think are.

Some of my projects have change histories going back years before Trac even existed. It would be unfortunate to expose all those emails (as is currently happening, actually)

[Christian Boos]

I'm currently working on updating the patch.

What about moving the EMAIL_VIEW perm in the Chrome component, next to the config option?

[Waldemar Kornewald <wkornewald>]

Replying to cboos:

I'm currently working on updating the patch.

I'm just curious: What are you changing, exactly?

What about moving the EMAIL_VIEW perm in the Chrome component, next to the config option?

Feel free to move this around. I just followed the advice of Matt Good who said that I should probably put it into trac.perm.

[Waldemar Kornewald <wkornewald>]

Replying to John Goerzen <jgoerzen@complete.org>:

Commit messages, though, I think are.

Some of my projects have change histories going back years before Trac even existed. It would be unfortunate to expose all those emails (as is currently happening, actually)

Are you talking about the commit message or the commit author? In Darcs and Mercurial, for example, the commit author is of the form "Waldemar Kornewald <wkornewald@…>" and this could be easily obfuscated because it's stored in a separate field.

Or do you have email addresses in the commit message (i.e.: "Fixed bug #123, thanks tom@… for providing the patch.")? This would be more difficult to implement.

[Christian Boos]

Updated wkornewald's patch to use macros in templates

[Christian Boos]

So basically I simplified the templates by adding two macros, one to be used in .html documents, the other in .rss documents. Text documents can also make use directly of the helper function which encapsulates the basic author information presentation logic (i.e. format_author).

The macro for html documents is named authorinfo, for consistency with the sizeinfo and dateinfo macros which are often used nearby.

Then, I believe all occurrences of the author information in the system are now protected (well, except the CC: field, but that would be a second step). I've verified this for e.g. Mercurial, where the e-mails are indeed pervasive. Note that for obfuscating the e-mails in wiki content, we could add a regexp for the e-mail addresses and either transform that to a 'mailto:' link (if show_email_addresses set or to an obfuscated email).

I've not move the EMAIL_VIEW permission.

[John Goerzen <jgoerzen@…>]

Replying to Waldemar Kornewald <wkornewald>:

Replying to John Goerzen <jgoerzen@complete.org>:

Commit messages, though, I think are.

Some of my projects have change histories going back years before Trac even existed. It would be unfortunate to expose all those emails (as is currently happening, actually)

Are you talking about the commit message or the commit author? In Darcs and Mercurial, for example, the commit author is of the form "Waldemar Kornewald <wkornewald@…>" and this could be easily obfuscated because it's stored in a separate field.

Or do you have email addresses in the commit message (i.e.: "Fixed bug #123, thanks tom@… for providing the patch.")? This would be more difficult to implement.

I have both, your example is exactly why it would occur in the changelog. However, the author name — in exactly the form you suggest — is the primary concern. (I run Darcs with trac) In the last couple of years, I've tried to be careful about putting people's email addresses in the log messages, but I can't do anything about the author strings.

[Waldemar Kornewald <wkornewald>]

Will this not be committed?

[Christian Boos]

Well, I was waiting from some feedback, but otherwise looks good to me ;)

[Waldemar Kornewald <wkornewald>]

In versioncontrol/web_ui/log.py we could directly check for show_email_addresses in the if statement without defining a variable. That would save two lines of code. :)

Hmm, I think I found another issue: By using the "Download in other formats:" function you can still retrieve email addresses. I don't know how to solve this easily, though. This could be fixed with another (independent) patch. I think that we should commit the patch, now.

[Christian Boos]

For which "Download in other formats"? Not the revision log text format (ChangeLog) and none of the RSS formats, I presume?

[Waldemar Kornewald <wkornewald>]

"Comma-delimited Text" and "Tab-delimited Text"

[Matthew Good]

I haven't reviewed the whole patch, but at a minimum the calls to self.config.getbool should be replace with accessing the BoolOption property.

[Waldemar Kornewald <wkornewald>]

Replying to mgood:

I haven't reviewed the whole patch, but at a minimum the calls to self.config.getbool should be replace with accessing the BoolOption property.

Shouldn't this only be done once per config option (we have that BoolOption in web.chrome)?

[Matthew Good]

Replying to Waldemar Kornewald <wkornewald>:

Replying to mgood:

I haven't reviewed the whole patch, but at a minimum the calls to self.config.getbool should be replace with accessing the BoolOption property.

Shouldn't this only be done once per config option (we have that BoolOption in web.chrome)?

Yes, there should only be one instance of the BoolOption for that setting, but I was suggesting reusing it in other modules like: Chrome(self.env).show_email_addresses

[Christian Boos]

Replying to mgood:

… I was suggesting reusing it in other modules like: Chrome(self.env).show_email_addresses

Are you sure that Chrome is the right place for the show_email_addresses? I had a doubt about this, that's why I preferred to use getbool, for not having to add imports for Chrome that would have to be removed later…

So if you think it's fully OK with Chrome, I'll do the change.

[Christian Boos]

Ok, I've committed the patch, along with the Chrome(self.env).show_email_addresses change (but don't come later saying that Chrome is not the right place for that option! ;) ), and fixes for the unit tests.

We're nearly there, but I think there are a few remaining points open before we can close this ticket:

• e-mails in Wiki content, see comment:54
• e-mails in .csv (query and report module)

Obfuscation of the CC: fields should be addressed separately, in #1459.

[Waldemar Kornewald <wkornewald>]

Replying to cboos:

Ok, I've committed the patch, along with the Chrome(self.env).show_email_addresses change (but don't come later saying that Chrome is not the right place for that option! ;) ), and fixes for the unit tests.

Cool, thanks!

• e-mails in .csv (query and report module)

And ticket module (see at the bottom of this ticket ;).

Obfuscation of the CC: fields should be addressed separately, in #1459.

Desperately waiting for this to come in 0.12…

[Christian Boos]

Replying to Waldemar Kornewald <wkornewald>:

Replying to cboos:

Ok, I've committed the patch,

Forgot to add the reference, for the record that was r4488.

• e-mails in .csv (query and report module)

And ticket module (see at the bottom of this ticket ;).

Ok, this as well.

Obfuscation of the CC: fields should be addressed separately, in #1459.

Desperately waiting for this to come in 0.12…

Well, feel free to submit patches there as well ;) I'll follow-up there.

[Matthew Good]

#4491 has been marked as a duplicate.

[Emmanuel Blot]

#4799 has been marked as a duplicate

[fredck fckeditor net]

Replying to cboos:

Obfuscation of the CC: fields should be addressed separately, in #1459.

Let's not leave the CC field as is for the 0.11. For now we could at least go with the JavaScript way to not render the addresses as is (document.write… see #4799). It is a simple solution that works. In the mean time, the definitive solution will come with the 0.12.

[Frederico Caldeira Knabben <fredck fckeditor net>]

Also, as proposed at #4799, a note near e-mail related input fields saying "Your e-mail will be masked for protection against spam (learn more (link))" is also a good idea, so users will be ok to included their addresses, avoiding the "myname _AT_ mydomain _DOT_ com" entries.

[Frederico Caldeira Knabben <fredck fckeditor net>]

Replying to fredck fckeditor net:

Replying to cboos:

Obfuscation of the CC: fields should be addressed separately, in #1459.

Let's not leave the CC field as is for the 0.11. For now we could at least go with the JavaScript way to not render the addresses as is (document.write… see #4799). It is a simple solution that works. In the mean time, the definitive solution will come with the 0.12.

Well… I'm not a Python programmer, so unfortunately I'm not able to provide a ready to use patch for it, but the implementation could be quite simple. I can give some client side bits though.

Today the Cc field is rendered in this way (token from this ticket):

<input type="text" id="cc" name="cc" value="wkornewald, somekool@gmail.com, dkocher@cyberduck.ch, jgoerzen@complete.org" />

The same results can be achieved by simply replacing it with:

<script type="text/javascript">
var cc = 'wkornewald, somekool A gmail O com, dkocher A cyberduck O ch, jgoerzen A complete O org' ;
cc = cc.replace( / A /g, '@' ).replace( / O /g, '.' ) ;
document.write( '<input type="text" id="cc" name="cc" value="' + cc + '" />' ) ;
</script>

So, in the server side, it is just a matter of rendering the above snippet, replacing all "@" and "." in the Cc value with " A " and " O " respectively.

[anonymous]

Replying to Frederico Caldeira Knabben <fredck fckeditor net>:

So, in the server side, it is just a matter of rendering the above snippet, replacing all "@" and "." in the Cc value with " A " and " O " respectively.

I don't know. But, even if email addresses are rendered that way in HTML (using As and Os instead of @s and dots) who guarantees that SPAM bots aren't smart enough to deobfuscate it?

Maybe I don't get it but IMHO the only option to obfuscate it is to map it to user real names, nicks or other ids that are not email addresses. In the case of the CC field a redesign would be better, though.

[Frederico Caldeira Knabben <fredck fckeditor net>]

Replying to anonymous:

I don't know. But, even if email addresses are rendered that way in HTML (using As and Os instead of @s and dots) who guarantees that SPAM bots aren't smart enough to deobfuscate it?

You are right. Actually there are "levels of protection". Leaving the address as is means "no protection at all". With the above obfuscation we at least make bots lives more difficult.

I could come up with other js snippets that only "Trac dedicated bots" would be able to de-obfuscated. For example, reversing the Cc var:

<script type="text/javascript">
var cc = 'gro O etelpmoc A nezreogj ,hc O kcudrebyc A rehcokd ,moc O liamg A lookemos ,dlawenrokw' ;
cc = cc.split( '' ).reverse().join( '' ).replace( / A /g, '@' ).replace( / O /g, '.' ) ;
document.write( '<input type="text" id="cc" name="cc" value="' + cc + '" />' ) ;
</script>

The As and Os replacements could be even optional in this case.

Maybe I don't get it but IMHO the only option to obfuscate it is to map it to user real names, nicks or other ids that are not email addresses. In the case of the CC field a redesign would be better, though.

I agree… and this is planned for the 0.12, as far as I understood. The js solution would be just quick fix for "a first level of protection" in the 0.11.

[http://blog.somekool.net/]

I think these are very easy for spammer to parse. I would use something like base64

print "<script>s = decode64(\"#{escape_javascript(Base64.encode64(email_string))}\"); document.write(\"<a href='mailto:\" + s + \"'>\" + s + \"</a>\")</script>"

[Frederico Caldeira Knabben <fredck fckeditor net>]

Replying to http://blog.somekool.net/:

I think these are very easy for spammer to parse.

I'm not sure spammers are looking for reversed strings with As and Os.

I would use something like base64

base64 is a diffuse e-mail obfuscating system, so maybe spammers already handle it.

Let's have in mind that the address must not be "computer readable". No problem if they are human readable instead.

Anyway, I'm not here to defend one implementation or another. Anything is better than what we have today (nothing in other words).

[omry]

trac have became a very easy and popular target for spammers other other dirt eaters. I vote for this one, and for any fix that will improve the privacy of trac users. I understand that in many cases its a trade-off between ease of use and privacy (like when allowing users to enter a username or email in the ticket comments) - but its time to start taking privacy more seriously.

[Mathieu Jobin]

something that spammer does not do yet is submit through Ajax. for my blog, I use typo. which use Ajax for posting comments. I kill 100% of my spam simply by requesting all comments to be posted through Ajax. before, they were simply doing POST request. while regular user who visit my website is filling the form and the request is sent through Ajax.

I believe this is a nice way to eliminate spam, at least for a while.

[moschny]

Replying to Mathieu Jobin:

I believe this is a nice way to eliminate spam, at least for a while.

This ticket is not about preventing a trac installation itself being spammed (which one can get under control e.g. with the spamfilter plugin), but about protecting the email addresses of the legitimate users of that trac installation.

[Emmanuel Blot]

Replying to Mathieu Jobin:

something that spammer does not do yet is submit through Ajax.

Trac should be able to work without Javascript - in order to support light browsers such as Lynx - so a Javascript-based solution would be an issue here.

[Mathieu Jobin]

sorry if my previous comment was off-topic… the other comment before confused me with another ticket.

regarding the idea to encrypt the email from the html source,… all these solution requires javascript as far as I can think of.

I think new version of lynx, links, w3m, etc support javascript to some extent. it would just need to be tested about what works and what does not.

[Christian Boos]

See also #5126 for the handling of the CC: field.

[Christian Boos]

As it's 95% done, I'd like to see this finished for 0.11.

[ThurnerRupert]

its not a bug, so it seems to block 0.11 unecessarily …

[sid]

#6031 was marked as a duplicate of this ticket.

[Frederico Caldeira Knabben <fredck fckeditor net>]

Replying to ThurnerRupert:

its not a bug, so it seems to block 0.11 unecessarily …

While this is not a "code bug" it is a "concept bug". We are talking about privacy, spam, and so forth. This thing must be taken seriously. I strongly recommend targeting it back to 1.11.

[Christian Boos]

Sure, this was moved to milestone:0.11.1 a bit lightly.

Remaining points open before we can close this ticket:

• e-mails in Wiki content, see comment:54
• e-mails in .csv (ticket, query and report module)

Obfuscation of the CC is field is done (#5126).

[Christian Boos]

Finish the obfuscation of e-mails in the last places that needed it.

[Christian Boos]

I'd be interested in testing feedback for the patch attachment:last-steps-for-ticket153-r6139.diff​, which should implement the last points discussed above (comment:88).

[Christian Boos]

Above patch applied in r6172.

If there's any leak of e-mails information remaining for unauthorized users, please create a new ticket.

Of course, there's still the content of the CC input field itself and maybe without doing a big redesign like those discussed in #1459, it should be possible to have an Add me to CC:/Remove me from CC: checkbox instead of the CC: text input field containing every user. A new permission (TICKET_EDIT_CC) could be used in order to enable the old-style CC: editing, which can be useful for ticket owners or admins.

[philbar]

If the patch was applied, why is the ticket still open?

[Christian Boos]

Because of this: #1459, comment 49.

Now that each and every appearance of e-mails has been tracked down and filtered out, I felt it was really bad to still have the CC: field filled with e-mail addresses, as that would still allow the spammers to collect all the e-mail addresses, which is the primary concern of this ticket.

[Christian Boos]

Now that #1459 was also completed, I believe that this issue is now fully fixed.

Summary:

• by default, all e-mail addresses displayed by Trac will be obfuscated (cboos@... style).
• the old behavior (no obfuscation anywhere) can be restored by setting the [trac] show_email_addresses configuration option to true
• the email addresses can also be shown on a per-user basis, by granting the EMAIL_VIEW permission

Again, if you discover any leak of e-mails information remaining for unauthorized users, please create a new ticket.

[mika]

Just a question - will this work on the repository browser if an email has been used as a user name?

[Christian Boos]

Yes.

[Remy Blank]

(Posted on behalf of Andrew C. Martin)

From ticket:153#comment:93

Again, if you discover any leak of e-mails information remaining for unauthorized users, please create a new ticket.

A malicious user with a little motivation could easily harvest 100's of email addresses from Trac. This can be achieved through custom queries on user-fields, using popular domain names as search criteria.

Example: ​hotmail.com

By replacing "…" with the domain name in question, full email addresses can be collected from the query results by unauthorized users.

[Ryan J Ollos]

Replying to Waldemar Kornewald <wkornewald>:

What about moving the EMAIL_VIEW perm in the Chrome component, next to the config option?

Feel free to move this around. I just followed the advice of Matt Good who said that I should probably put it into trac.perm.

EMAIL_VIEW was moved to the Chrome class in #11474.