Show HN: Email encoder – protect your public emails from bots and crawlers(freetools.dev)
freetools.dev
Show HN: Email encoder – protect your public emails from bots and crawlers
https://freetools.dev/email-encoder
20 comments
Are bots not prepared to just decode this instead?
Yes, most bots will decode this easily. Some bots also decode various JavaScript based obfuscations and email addresses in images. But in contrast to those, this little obfuscator doesn't harm the usability (you can copy and paste it, screen reader compatible etc.).
For the last 10+ years I personally have not tried any more to hide my email address on the web. It's visible in thousands of places (mailing list archives, websites, git commits) and the volume of spam is absolutely manageable (~100 a day, 99+% filter rate with spamassassin and blocking some networks).
For the last 10+ years I personally have not tried any more to hide my email address on the web. It's visible in thousands of places (mailing list archives, websites, git commits) and the volume of spam is absolutely manageable (~100 a day, 99+% filter rate with spamassassin and blocking some networks).
Yeah it seems this would be easy to parse, but I have also seen things like:
USERNAME at that Googly Maily Thing
and other "creative" ways to hide it. I just know if I put an e-mail out on the web, I usually have it as a "mailing" list type of ID, so I'm not just placing mine out there.
Neat app though.
USERNAME at that Googly Maily Thing
and other "creative" ways to hide it. I just know if I put an e-mail out on the web, I usually have it as a "mailing" list type of ID, so I'm not just placing mine out there.
Neat app though.
But why? Unless you are targeting Linux users or devs in general, nobody will obfuscate like this. And to decode this you (your bot) need to run untrusted code. The upside has to justify the work securing your bot.
Are bots actually crawling for email addresses? I've had my email public on various websites for years and have yet to receive any spam from that. On the other hand, when that email was leaked in a data breach the spam started immediately and continues to this day.
I posted a “who wants to be hired” entry here on HN last week, using a one-off email from Firefox Relay. Within two days, I started receiving spam through it. So, yes, bots definitely still trawl the web to harvest email addresses.
I guess it's a matter of chance (unless you have a spam filter that filters them from you?). It was only hours after an otherwise unused email made it into AUTHORS.md for a major project that it started receiving spam and it's been a steady stream since.
[deleted]
I use server side excludes provided by cloudflare for free and have never had any issues getting spammed. That could be more thanks to gmail though.
https://support.cloudflare.com/hc/en-us/articles/200170036-W...
https://support.cloudflare.com/hc/en-us/articles/200170036-W...
Good way to collect some email addresses.
Here is an alternate method for an audience that uses a terminal. It might be -D on mac, can't remember.
Contact Me:
Contact Me:
echo 'c29tZS5lbWFpbEBzb21lLmFkZHJlc3MK' | base64 -dwould someone really run that randomly? couldnt it run a rm command?
Good question. If one piped that to `bash` or `sh` then that would certainly be a possibility. This is why I avoid curl piped to bash and instead curl to an output file, review it and then execute it. If one was unsure of the behavior of base64 they could redirect the output to a file as well.
echo `something` | base64 -d > ./some.file.txtThis is just saying "do not run untrusted code" with extra steps. If you don't trust the source the code came from you should not executed any line.
I disagree about the extra steps as it pertains to the original post.
The redirection of base64's output to a file is addressing the concern that the output from the program would trick the terminal into executing code.
What you are describing is the risk of sending a small string of ascii into base64 would cause a buffer overflow and trick a text decoding binary into executing code. This is of course a risk with parsing data especially if it were binary.
If we really wanted to go deep down a rabbit hole of theoretical risk then I would concede that if you did not force your character set of your terminal to something that could not possibly interpret extended character codes then there is a risk albeit highly unlikely that there could be hidden strings you are copy/pasting. This could occur with any executable and pasting of data to which I would partially mitigate by forcing my terminal to have a LANG/LC_ALL of C unless I specify otherwise and would probably even take care to be explicit with IFS. This is a deep rabbit hole and I would be surprised if a majority of people copy/pasting from sites like stackoverflow / stackexchange took these precautions. Further mitigations could include executing code as a AppArmor/SELinux confined user or pasting the code into a sandboxed environment. There are infinite rabbit holes we could go into here and would be happy to cover some of them.
More likely when copy and pasting text especially if from a web page would be that the site is malicious and using CSS or javascript to trick your system into copying entirely different contents into your copy/paste buffer. [1] This would also benefit from running in a highly sandboxed environment.
[1] - https://thejh.net/misc/website-terminal-copy-paste
The redirection of base64's output to a file is addressing the concern that the output from the program would trick the terminal into executing code.
What you are describing is the risk of sending a small string of ascii into base64 would cause a buffer overflow and trick a text decoding binary into executing code. This is of course a risk with parsing data especially if it were binary.
If we really wanted to go deep down a rabbit hole of theoretical risk then I would concede that if you did not force your character set of your terminal to something that could not possibly interpret extended character codes then there is a risk albeit highly unlikely that there could be hidden strings you are copy/pasting. This could occur with any executable and pasting of data to which I would partially mitigate by forcing my terminal to have a LANG/LC_ALL of C unless I specify otherwise and would probably even take care to be explicit with IFS. This is a deep rabbit hole and I would be surprised if a majority of people copy/pasting from sites like stackoverflow / stackexchange took these precautions. Further mitigations could include executing code as a AppArmor/SELinux confined user or pasting the code into a sandboxed environment. There are infinite rabbit holes we could go into here and would be happy to cover some of them.
More likely when copy and pasting text especially if from a web page would be that the site is malicious and using CSS or javascript to trick your system into copying entirely different contents into your copy/paste buffer. [1] This would also benefit from running in a highly sandboxed environment.
[1] - https://thejh.net/misc/website-terminal-copy-paste
Fair enough, and you seem to know more about character encoding than I do so I won't argue lol. I'm standing on a glass house anyway as I use password less sudo haha.
no. it's not executing any user-supplied data as code; the only commands running are echo and base64:
$ echo 'cm0gLXJmIC8K' | base64 -d
rm -rf /
$ # was echoed, but not runAh! Nice. I looked around and feel nice to find one of my early tool there too -- the HTML entities (pretty much the same as my earlier version).
How does the protection work? What technologies were used to create this product?