3. On the user account, completely visible to all, logged in or not. Example in the field: https://setiathome.berkeley.edu/show_user.php?userid=20272
This account and its URL can be read by logged in and not logged in users. So one can link to this account to get people or things to follow the URL. A profile isn't required, even though the first example does have one. https://setiathome.berkeley.edu/show_user.php?userid=7833683 however does not. URL, yes. Profile, no. -- Jord van der Elst. On Mon, Nov 14, 2016 at 10:10 AM, Christian Beer <[email protected]> wrote: > On 11.11.2016 22:46, David Anderson wrote: > > The create-account RPC is used by > > - account managers (BAM!, etc.) > > - the BOINC client > > > > If it were just account managers we could add some kind of access control > > (i.e. accept RPCs only from known AMs). > > But this would break the client. > > > > What to do about this? > > Suggestions are welcome. > > I don't think account creation is the right place to fix it. Especially > since it will break older Clients. > > The question is what do the spammers want? They want to place links on > the webpage. There are currently only two ways to do this. > > 1. via a publicly accessible profile on a project that is not screening > profiles and does not have reCaptcha enabled for profile creation. The > Client does not do that. If reCaptcha is enabled this is secured. > > 2. via a forum post wether through the post or through the signature, we > already have measures against this, we should find out why they are not > effective anymore > > 3. through the URL attribute of the user table, which currently deems to > be not used by the spammers because it is not visible without a profile > (???) I didn't look in detail where this url is used. > > 4. By creating teams. This is currently also happening and I wonder if > creating the useless accounts should lure us away from the accounts that > create spam teams? > > I know this is an arms race but I also think that breaking old clients > would mean to nuke the battlefield instead of putting on more armor. We > are on the defensive here and can't really attack back. > > Regards > Christian > > _______________________________________________ > boinc_projects mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
