The following observations are extracted from comments I've read in this 
thread, but which I think could do with being made more explicit:

1. Job visibility: Sites care about what grid jobs are actually being 
run on their resources, even if they accept it is hard, in practice, to 
determine the "real" purpose (and result) of any particular job.

2. Economic models: As the computing grid expands (and it seems it is 
already big enough for this to be important), better accounting is 
essential, probably including an economic model for accounts, VOs, 
resource usage, and scheduling.  This would make VO managers more 
responsible, rather than the "free ride" some smaller VOs have now, 
which does not require them to take sufficient responsibility for their 
users usage levels.

3. User responsibility: Users need to take seriously their 
responsibility when using the grid.  With a growing base of grid users, 
and endemic misuse and illegal use of computing resources, particularly 
on University campuses, surely this problem will come up again.

4. Cycle-scavenging: Perhaps this highlights an *opportunity* for the 
EGEE infrastructure to incorporate cycle-scavenging daemons which will 
run when "regular" grid user jobs are not present.

For those who are interested, I extract from these points the following 
requirements or possible solutions:

1. Job visibility: this suggests a scenario where users are not allowed 
to run their own executables, but instead are only allowed to manage 
parameters/configuration, and input/output data.  Executable software is 
all deployed by sites or through the VO-specific software manager.

2. Economic models: A system of costing and charging (or balancing 
against VO-associated resource contributions to the grid) would quickly 
make all VOs pay attention to what jobs their members were running.  I 
see the two requirements from this being a charging model for resource 
usage, and user-level accounting.

3. User responsibility: As the grid grows (sites/resources/users), 
perhaps a community voting system is required: "As a site, I accept user 
Joe Bloggs if he has '5 votes for' or reject him if he has '3 votes 
against' from my list of trusted sites".  The same could be done by 
users for trusted sites.

4. Cycle-scavenging: If BOINC were a standard part of an EGEE 
deployment, site managers could decide what BOINC projects to commit 
time to.  This would make it more clear that it was not appropriate for 
grid-users to use their VO quota to do these kinds of tasks.

Cheers,

Ian

As a postscript, it seems to me that regardless of whatever 
"encouragement" was given for these particular jobs, it seems pretty 
obvious to me that they were not appropriate.  The user in question is 
not a maths or a computer security researcher, with a direct interest in 
large number factorization (in fact, one comment suggested the user was 
factoring numbers of a size which had already been computed, in which 
case it had *no* scientific value to anyone).  It is unclear what impact 
the result of a successful factorization would have had on their domain 
of research, and given their long-term involvement in EGEE it seems 
there is an important question to ask: "Why did you think it was 
appropriate to consume X-level of resources over several months for this 
particular end, at the expense of other jobs within your VO and at the 
expense of other grid VOs?".  If an experienced grid user (and 
developer/researcher) can make this mistake of judgement, then surely 
new users will be even more likely to.  Understanding the 
thinking/justification for it will allow us to make it more explicitly 
clear to users that this is not acceptable.

Cornwall, LA (Linda) wrote:
> So three matters,
> 
> 1) Policy. There is the policy issue of who can run what, including who
> is allowed to run programs to try and crack certificates. 
> 
> 2) Discovery. There is the issue that technically anyone can run
> anything they like, just by calling it what they like. So how do we find
> who is breaking the rules? 
> 
> 3) What action to take. I agree there has to be a consequence for
> breaking the rules. Just like anything else in this world otherwise it
> does not work.
> 
> I'll raise this all at this month's SCG. 
> 
> Linda
> 
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of Kostas Georgiou
>> Sent: 01 November 2007 13:25
>> To: [log in to unmask]
>> Subject: Re: Heinz' Challenge
>>
>> On Thu, Nov 01, 2007 at 11:30:06AM -0000, Cornwall, LA (Linda) wrote:
>>> Having said that, it is encouraging that when someone is trying to
> break
>>> RSA codes it got noticed by sites and the activity was stopped by
> many.
>>> This means I hope that if a user were to try and break codes in a
> more
>>> malicious way, e.g. to break a bank's certificate there is a fair
> chance
>>> it would be spotted. :-)
>> Being the one that noticed the job I can say that I don't see anything
>> encouraging :( I did notice the job *more than a month ago* and
> because
>> I got distracted with the security of it's pilot job nature I didn't
>> even look at what it was tryning to do. Then again nobody else noticed
>> anything either.
>>
>> I am very disappointed, if the user had taken some easy steps (just
>> changing the names of the binary/files) I don't think that it would
> have
>> been spotted *ever*.
>>
>> If I start sumbitting jobs tomorrow called CancerGeneSolveB3F910c with
>> inputs geneXXXXX for example who can tell that I am not cracking
>> certificates? Well since I am in dteam and not biomed I'll have to
>> think of a different name but believe me *nobody* will notice anything
>> wrong.
>>
>> Given this if we don't have hard penalties for a missuse we'll be
>> encouraging users to abuse the system.
>>
>> Kostas


-- 
Ian Stokes-Rees                 [log in to unmask]
Particle Physics, Oxford        http://grid.physics.ox.ac.uk/~stokes