Hi jhindo,
I appreciate that you try to provide some answers. However, I cannot be satisfied with the statement "personal information is defined fairly broadly".
Last Sunday (2018-05-27), I took the time to analyse the GDPR impact on WCG contribution exports. I don't claim that I made a perfect analysis, nevertheless I am still considering that the current situation is the result of a "quick & dirty" overreaction.
It is possible to implement a "smooth way" mainly relying on user "opt-in" settings without breaking everything, in particular regarding the connection to external web sites.
I would really appreciate that WCG (i.e. IBM) would be able to recognize the mistake and to change the compliance implementation approach, instead to persevere and to lose valuable contributors.
I am really concerned that the current situation would significantly damaged WCG computational power because of loosing some of the most dedicated contributors.
Yves

I looked up a copy of the GDPR and found this definition of 'personal data' on page33:


Just below that is the definition of 'pseudonymisation':


Then I looked up any relevant mentioning of 'pseudonymisation' and found this on page 5:

And this on page 29:


I am no legal expert, but it sounds to me that pseudonymisation should give room to work with.

Most of the time the newly modified script used to export my statistics works well...
However, every so often end up with an error in the logs. Here are a couple of samples...

Thu May 31 10:19:13 AEST 2018
Errors detected:
Access is denied. To request access, refer to https://www.worldcommunitygrid.org/help/viewTopic.do?shortName=api

Thu May 31 20:54:12 AEST 2018
Errors detected:
Access is denied. To request access, refer to https://www.worldcommunitygrid.org/help/viewTopic.do?shortName=api

AEST = Australian Eastern Standard Time
This would appear to not be an appropriate error message for whatever is failing at WCG...

That's a pity, Tony, when the script at times doesn't return what you expected. This way of retrieving results from WCG's website is all very new and until now, most of the time, my script has been relying on successful transfers and to forget about unsuccessful ones (since these problems almost always seem to be of a temporary nature). Also, I haven't noticed my script failing in this way yet in the past week and I'm running it each half hour to watch the queue (in a terminal) and once per hour to record all my results (via crontab).
Just right now I tried "for i in `seq 1 50`;do wcgresults -dqq;done" (requesting my current queue 50 times in a tight loop) and all went well.
The thing is that if something goes wrong somewhere, WCG will probably just return this error:

{
   "errors": [
      {
         "code": 401,
         "message": "Access is denied. To request access, refer to https://www.worldcommunitygrid.org/help/viewTopic.do?shortName=api"
      }
   ]
}

I have seen this error before in the past week without the 'code 401', they added that between 01:00 UTC and 02:00 UTC on 25th May, so I know WCG is working on it. When such an error occurs, it is possible to try and investigate the error if and only if any output or files during the running of the script have been saved. The script tries to be silent though. I could supply a version of 'wcgresults' that saves some files during each run and then, when such an error occurs, we could investigate further with the files that were saved during the errored run to see if we can do anything about it. Or else we could add more code to the script to find something useful of what went wrong. Or make the script more silent, so that you don't get to see the 'access denied' error in case of such events. Maybe new opportunities could arise when WCG's next planned maintenance will be carried out.

Also, 10:00 AEST is 00:00 UTC. So it could be that the statistics at the WCG site are being updated at 10:19:13 AEST so that your results have been unavailable for a short while.

@knreed

Thank you for thinking with me. I see what you mean. Yes, the login probably failed.

Another idea springs to mind: we could look at the cookie file. A successful login would look something like this:

	.worldcommunitygrid.org	TRUE	/	TRUE	1527946318	Setup	…
	.worldcommunitygrid.org	TRUE	/	TRUE	0	WCG-LtpaToken2	…
	.worldcommunitygrid.org	TRUE	/	TRUE	1527896318	WCG-SESSION	…

A login failure on the other hand is looking like this:

	.worldcommunitygrid.org	TRUE	/	TRUE	1527896270	WCG-SESSION	…

Do you think the script could learn something useful from the cookie file? For the moment I've implemented something in a test environment where I need "WCG-LtpaToken2" in the cookie file and if that string is absent, then login failed. I know something like "LtpaToken2" could change without any notice from WCG's administration, but I guess it will do for the time being. I've also added some code that Tony could use if there's a desire to further investigate (i.e. Tony would now only need to put a "#" in front of the line "DEVNULL=/dev/null" that I've put into the test-script).

Another way to look at it: the 'wcgresults' script never reported a login failure before 25-05-2018, so I could be trying to keep it that way.