search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 38 forks source link

[WP][SR] Add email obfuscator to core #3270

Open ghost opened 5 years ago

ghost commented 5 years ago

We have a contrib module that does this, but since WordPress has a function for this in core, I'm wondering if we could/should too...?

I'm guessing most users setting up a Backdrop site wouldn't know to install Invisimail to protect email addresses entered in textareas.

(Triaged as possible accessibility issue on 08/17/2921. Seems like we are looking for feedback on how to accomplish this without hurting accessibility.)

olafgrabienski commented 5 years ago

If people don't know of Invisimail, or just forget to install it, or install it too late, email addresses may already be grabbed by spambots. So it would be very useful to have an enabled email obfuscating feature ready when you start with a website. If we add it to core, I'd suggest to also set up the respective filter for the CKEditor Filtered HTML text format by default.

jenlampton commented 5 years ago

Yes, I was just thinking the same thing! One of the orgs I work with was the victim of a spear-phishing attack, and I expect it was the result of all the email addresses being scraped from the board member page. This caused me to reminisce about the days of static-html-website-building when I added crazy JS obfuscation to all my email addresses.

I was thinking that we should provide a checkbox (checked by default) on the email field display settings. But a helper function would be great too, because then it would be easy to implement anywhere! We could use it in when we automatically convert email addresses to links via text formats... so many ideas :) Yes please!

ghost commented 5 years ago

@jenlampton Ah, the good ol' days... :-D

Yeah, I think a reusable function in core, and then enabled-by-default checkboxes in the settings for link field formatters and the email link conversion filter (as opposed to a separate filter like Invisimail does) is the way to go.

ghost commented 5 years ago

Hmm, on second thought a separate filter might be better, since you could turn off the Convert URLs into links filter but still want plain text email addresses obfuscated.

Also, if/when we add a function to core for this, where should we use it?

  1. In a new Obfuscate email addresses filter
  2. In all Email fields
  3. In all Link fields
  4. In all fields of any type (e.g. Text, etc.)
  5. Across the whole site (e.g. block titles, Views headers, menu items, etc.)

Options 1, 2 and maybe 3 make sense if we want people to be able to turn it on and off in the most likely places, but that leaves them open to spam if inserting an email address in a not-so-likely place. Option 4 protects all fields, but only option 5 would protect the site as a whole.

I guess it depends on why we're doing this: to add Invisimail to core (and have it turned on by default) (i.e. give people options but ultimately leave the protection up to them), or to protect all email addresses as much as possible (with maybe only a global on/off switch).

To me option 5 seems to be the best, but I'm not sure of the performance impact this'll have, running all text through the obfuscation function to check for email addresses... Thoughts?

klonos commented 5 years ago

So it would be very useful to have an enabled email obfuscating feature ready when you start with a website.

... enabled-by-default checkboxes in the settings for link field formatters and the email link conversion filter (as opposed to a separate filter like Invisimail does) is the way to go.

Yes, that would be inline with what we did in #574 to prevent bots from registering accounts on freshly installed Backdrop sites.

...since you could turn off the Convert URLs into links filter but still want plain text email addresses obfuscated.

This situation would be great to be implemented as a warning in the status report page and/or in the dedicated security page we are planning to introduce in #3624.

ghost commented 3 years ago

I've been looking through my old feature requests for something to advocate for for the next release. This one looked good, until I started researching anti-spam techniques and discovered:

So... Is it even worth trying to add obfuscation functionality to core, or is it too old, ineffective or not-accessibility-friendly? Thoughts?

If it weren't for the accessibility factor, I'd say some protection is better than none. So I guess some accessability-expert advice would be good here.

indigoxela commented 3 years ago

FTR: there are currently two three different modules providing mail obfuscation in content:

My conclusion: the better the protection, the more impact on web accessibility.

So I guess some accessibility-expert advice would be good here.

I agree.

stpaultim commented 3 years ago

My first thought in looking at this issue was that this problem is not as big as it used to be, when it was much more common to have people enter their email addresses into forums or comments. I used to run into this a lot more than I do today.

My sense is that users are more careful about displaying their email these days and that there are fewer opportunities on Backdrop sites then there might have been in the past in the early days of blogging. In my view, this makes the problem a little less urgent.

Even without the urgency (and others may disagree with me on this point), it's still a common problem and hopefully not too difficult to solve (given that there are contrib solutions available).

Invismail is #71 (66 installs) on the current list of most popular modules for BackdropCMS. Maildisguise is #336 (7 installs) on the current list of most popular modules for BackdropCMS.

I think that is a significant display of interest in this functionality. I think a lot more people would use it if it were available in core.

I think it's a good candidate for core inclusion. But, I'd like to hear what others think.

klonos commented 3 years ago

but only option 5 would protect the site as a whole.

This may be another good candidate setting for #3624 ...we may be able to add a checkbox there, along with any notes re any known accessibility concerns/issues. That way, we'd allow site admins to enable disable this across the site as per their needs.

ghost commented 3 years ago

Oh yeah, I forgot to mention that I decided that if I were to implement this for core, I'd suggest doing options 1, 2 & 3 (from my post above). Options 4 & 5 are likely going to have a negative performance impact on the site for what is, I suspect, a <20% use case. And I think if options like that were desired, that's probably best left in contrib-land.

jenlampton commented 3 years ago

I think my preference for core would be for 1 and 2, but with 1 disabled by default, and 2 enabled by default.

edit: I'm also curious about the accessibility of wordpres. How did they solve that issue?

ghost commented 3 years ago

I tried searching for Wordpress and antispam accessibility, but couldn't find anything that talked about their core functionality...

I'm really not sure how to proceed with this issue. Do we even bother putting something in core that could have accessibility issues? If so, which of the 3 contrib modules that @indigoxela linked above should we take code from for inclusion in core?

ghost commented 2 years ago

I suspect there's no real need or interest in this anymore. It's an old technique that seems to have lost popularity over the years. So I'm gonna call it and close this issue.

jenlampton commented 2 years ago

I'm going to re-open this issue (perhaps temporarily) until I can get some feedback on...

If it weren't for the accessibility factor, I'd say some protection is better than none. So I guess some accessability-expert advice would be good here.

Since we now have a pretty good relationship with the Cetnter for Accessible technology, I'd like to ask them about mailto links and obfuscators, and see if they have any advice for us.

As the president of the board and the person who built my NP's website, I felt horrible knowing that our board members were being spear-phished because I put their addresses on the website. I would feel much better if I could also help find a solution :)

edit: the question has been passed along to the expert!

jenlampton commented 2 years ago

Lindsay did some testing for us with common obfuscaters, and none had any problems for screen readers: https://codepen.io/silverli/pen/GRygPqO. It's safe to proceed with this feature.

izmeez commented 5 months ago

Adding this to core is a good idea. It is one of the getting started features in our list and we installed https://github.com/backdrop-contrib/invisimail which works well. I forget the reasons for settling on that one. Maybe, I'll come across them and add them to this discussion.

indigoxela commented 5 months ago

Adding this to core is a good idea.

@izmeez there are several email obfuscators available in contrib. Different approaches, different solutions, it may depend on your use-case.

Available so far:

izmeez commented 5 months ago

Do you think the different use cases is a reason to keep this feature out of core and leave it in contrib?

indigoxela commented 5 months ago

Do you think the different use cases is a reason to keep this feature out of core and leave it in contrib?

@izmeez maybe, but I'm not the right person to ask, why something's in core or not. :wink: Personally, I'm usually fine with different options to choose from.