Emails and Users not protected from spammers!

Have the Emails beens public on your site or are they [restricted] or lets say a potential profile where you see the email-adresses is visible for logged in users only?

all those mails are visible on THEIR site!
https://www.etoilewebdesign.com/front-end-only-users-demo/user-listing/

Some of those emails seem to be fake but a most seem to be even real email addresses as it looks like.

When you give in i.e. “gmail” it lists you all gmail addresses
https://www.etoilewebdesign.com/front-end-only-users-demo/user-search/#

and if you try the search with 12 a whole lot more pops up or try a simple “a” and you get a full list with usernames – IMHO a clear GDPR Problem!

GDPR is not matched also when it says to export all user submitted data. The users which have registered with this plugin can’t get this data out again as it is NOT connected to the Core Users Feature, which is great i.e. in Multisites but terrible when the plugin does not provide a way to fulfill the GDPR requirements.

I wished it would be possible that this plugin could be GDPR compliant as then it woudl be very useful in a Multisite surrounding where the users should NOT get stored in the general main Users database – especially NOT with their real name and Data (that could be a hint how to actually connect to the Main Users – by using encrypted User Names here, which again would make WP it self much more secure)

This plugin provides its own tables which is great and they are much easier to read then the original User Table. Another plus is that this plugin does NOT register a WordPress Backend User !!! which could enter into the Backend as a Subscriber or any other i.e. Author, Contributer etc.

Another Plus is that this plugin helps to keep the Frontend people solely on the frontend while having the maintainer and i.e. blog authors , shop-managers working in the backend.

BUT – how do plugins handle this Frontend Only Plugin? Is Woocommerce still registering a backend user in the Core user table – which means in Multisites in Table 1 and it could be read by the Site 1 owner even he would not be allowed to see the rest of the data on another site (if he is not the superadmin of the network)

If that would be possible – especially in Multisites the Frontend data woudl stay solely and clearly separated on the SiteID Tables which shoudl be different that site 1!!! – Unfortunately as far as I coudl test the core Users still get created and used by other plugins which need Frontend Users.

Just 3 Major examples:
WooCommerce – User registers and all data needs to get stored in the Frontend User Tables but NOT in the Core Tables – possible or not?

BuddyPress – a lot of sites are using BuddyPress and bbPress for social media like communities and LMS plugins – they really could benefit from such a plugin but again the question is in how to get that working that the users are stored solely in the Frontend User tables and not in the CORE Tables of site 1 (Multisite), If we would need both for the Frontend Users anyway than the question would be why this plugin actually exists!

General Multisite has always a SiteAdmin which is registered in the Multisite Core Network and Site 1 Main Users Table. Perhaps also a ShopManager and Author who need backend access is registered there, but all subscribers and Frontend Only Users, who visit the Blog, read restricted articles on the site, order in the shop and join a social community would not need to be registered in the CORE Table – How to avoid that both tables get filled up.

Thumbs up for the developers and I hope they get this plugin fully GDPR compliant i.e. by integrating probably even the GDPR request features inside the plugin as that would be where they belong too anyway and that some of the davs can explain or list all the plugins which actually woudl work together with this plugin so no double data entries will happen.

As the USERNAME is NOT registered as a WP CORE User it shoudl also easily be possible to actually HIDE all those User names and the Emails and instead present only the Real names (which hopefully differ from the login user Name and Email) or Nicknames (which also should differ from the User names.

In combination with Any other plugin it would be a real need to have also a USER Page, where i.e. LMS results, Orders, Bought Products, and other personal Data would get stored. All those USER PROFILE Pages could and should have a “slug” which does NOT match the email or username – perhaps even could be chosen. That also wodl solve a problem most social media community plugins have which are based on Buddypress as here always the username gets presented in the URL and only of the username contains i.e. a @ those parts would not show up and then the slug would NOT match the Username. Perhaps inserting #signs (haven’t tested other signs) into a username could help to make it more difficult to guess the correct username.

I dont understand your problem. On my site a member has to register. After that I as an admin prove the data and give this user my permission to log in or not.
Logged in users are able to search for other members and see personal information like first/last name phone number or email.

There is also content on the site which is [restricted] to non logged in visiters.

On the backend no one sees anything because contrary to most membership plugins users are just on the frontend as the name of the plugin says. Thats the reason i use it.

So first there is a kind of captcha code (unfortunately not the real reCAPTCHA), after that you can choose if an admin has to prove you. If yes you are able to log in and then you see personal data.

On the demosite everyone can see this stuff because I asume they want to. If you dont want to then implement those features I described and you, as a public visiter, can not see anything besides a message that you have to log in to see that stuff.

IMHO email addresses should always be secured and the major problem in using the plugin no matter if people log into the site or not is that people have to agree!!! according to GDPR that their data get shared or not but here we have no option.

Take as example a community plugin like “youzer” which is an addition to buddypress but here the user can choose if he wants to share his data in a very specific way (can define what data can be shared. The same process had been introduced to most social media platforms i.e. Facebook. It is not OK accoring to GDPR that i.e. email addresses get shared by default – no matter where – for logged in or even logged out users. Besides that all emails get listed in an unecrypted way which means anybody can simply copy and paste all data (i.e. after he has logged in it would be visible for him (all data without any option to filter out those who don’t allow that their email or usernames get seen by others) GDPR is a major problem here in EU and all sites visible in the EU have to be compliant!!!

The plugin has huge benefits but not being compliant to GDPR is a no go for any website which is not restricted to be seen in EU, most Asian States which meanwhile followed the EU, South Africa which had the EU restrictions applied even before the EU did so, and now even the US which introduced even more restrictions i.e. COPPA, ADA etc.

emails and usernames are a major target for both – hackers and law enforcers!
This means a 100% GDPR, COPPA, ADA compliance is a must for any website no matter where it is hosted or where it will show up in the world unless you run it on your private intranet or solely on your local server.