Disputable email address obfuscation for example.com &co


TL;DR: Cloudflare’s email address obfuscation hides addresses under standard documentational-purpose domains (example.com, example.net, example.org, example.edu, and .example), which affects clarity of such documentation.
:logo:Cloudflare can whitelist these domains by default. Not only bots fare with JavaScript disabled.

So far, I have encountered several pages like software documentation or articles on software development, where Cloudflare’s email obfuscation feature is enabled.

Without any further ado, the feature also obfuscates addresses under example.com domain, which is reserved for use in documentation, along with example.net, example.org, example.edu, and .example. Wikipedia says they are. That means such addresses should be exposed—for science!—not protected.

example.edu is a little questionable, as it is missing from IANA’s special list, while its frontpage is identical for the rest of the 2LD’s.

So, to me, most of these domains can be whitelisted.

:heavy_plus_sign: On the upside, it secures JS-disabled visitors’ experience on pages where authors do not know or do not care about the issue.
:heavy_minus_sign: On the downside, it complexifies the algorithm, as besides simple string comparation it now has to check against something like /((@|\.)example\.(com|net|org|edu)|\.example)$/.

Well, :logo: likes feedback? Here it is) :horse:

1 Like
<!--email_off-->[email protected]<!--/email_off-->

This obviously works fine, if the author is aware of the matter (and cares), and their platform allows them to put html <!-- --> on their page. And they do not have dozens of example emails there )

Questionable? Yes. Discussable? Well… )

upd: Googling cloudflare "[email protected]" shows at least something.

1 Like

Could you elaborate why obfuscation of these domains should be an issue?


Well, for people with JavaScript disabled (completely, or via whitelists), obfuscation of these domains decreases readability of software-related documentation in case its authors do not know about the feature enabled, or how to suppress it for selected addresses. Meanwhile, obfuscation of these domains does not protect anybody: there is simply nobody to protect in this case.

I’ve read people honestly surprised with emails on their sites turning into `[email protected]’. Does Cloudflare inform users about the feature is enabled and how it works? If yes, then they just do not read or care.

To say how big the impact is, I would need to know how many internet pages contain emails from the example set, and how many JS-disabled visitors they receive. Which information I don’t have.


upd: Personally, I keep JavaScript disabled by default to avoid needless experience with bad-behaving scripts in the Web. Then I usually whitelist sites that I visit regularly, or have any other reason to trust them in this context.

upd2: And certainly seeing [email protected] in documentation does not motivate me to stay there.


Trust is mutual.


Not sure I’m getting your point. “Trust strangers and enable your JS, and then they’ll show you their protected emails”?

Trust may be mutual, if all the parties trust each other. But “trust” does not mean “mutual trust” by default.

Why do I have to enable JS to read documentation w/o any personal data in it? The fact a site page contains software documentation, by itself, gives no reason to trust it, as well as the fact that a site visitor have JS enabled.