[daip] Re: on-line FILLM

[Jim Ulvestad]

Hi all,

Some background on this, since most of you are probably in the dark.

Between Xmas and New Year's, a "magnetar" went off in
gamma rays--although we didn't know about the strength until
after New Year's, it was strong enough even to disturb the Earth's
ionosphere from a distance of several kiloparsecs.

Two groups wrote target of opportunity proposals.  The proposals
were not materially different, so we granted one group the right
to observe the source, with immediate data rights to both groups.
The two immediately set out trying to scoop each other, reducing
the data as fast as possible and trying to get GCN notices out
first.  One group (Gaensler's) complained to us about being
forced to race, and I told them that all they had to do was talk
to their competitors to get out of the situation they were in.
They declined to do so.

After the first ToO was expiring, and it was clear that the source
merited long-term monitoring, we asked both groups to write us
continuing proposals due in about two days, which we would have
refereed and then decide.  Most of the referees liked the proposal
from Gaensler's team better, so we gave their group the time and
exclusive data rights, but with a proprietary period shortened to
3 months.  The first observation on this proposal took place within
24 hours of our decision, and one of the co-Is from the other group
filled the data and put out a GCN on it, even though he wasn't
supposed to have rights to the data.  After he was informed of this,
he didn't do it again.

The most obvious interpretation is that we only communicated the
ToO results to the PIs of the ToO proposals, and one of the coIs
assumed the data rights were still "open," and hadn't been told that
there was a proprietary period for the new ToO.  Another possible
interpretation, probably of much lower probability, is that either
the PI deliberately didn't tell him or else the group just went ahead
anyway.

This is all complicated by the fact that the two groups hate each
other's guts, and we would not have had the problem if they
actually talked to each other and weren't inferring dastardly
motives to the other group and trying to drive them into the ground.
On the other hand, this is exactly the kind of situation where we
might have such a problem, so we need to consider how to prevent
non-collegial groups from getting into the situation where the "wrong"
group gets access to the data.

This week, I agreed with the UC chair that we would start notifying
all ToO authors of the proposal disposition, and not just the PI.
That will help take care of the accidental downloading issue, but
still leaves a big hole for someone who wants to deliberately ignore
the rules.  If we then want to do something about it, we will have to
see how much effort it would take.

Best,

Jim

Patrick P Murphy wrote:

>Hmm.  Given that I'm the Computer Security Manager for NRAO, I'm
>thinking this may merit our committee having a look and helping
>out... at the minimum, if there has been a breach, an incident report
>needs to be filed.
>
>Based on what Eric said below, it seems more like this incident is one
>where social engineering was applied, not necessarily cracking/hacking.
>
>It will probably look good (and be the right thing to do) if I give
>Bryan a call asking him for more specifics.
>
>				- Pat
>
>On Thu, 2 Jun 2005 11:09:38 -0600, Eric Greisen <egreisen at nrao.edu>
>   said: 
>
>  
>
>>Bryan Gaensler writes:
>>    
>>
>
>  
>
>>>I'm on the NRAO Users Committee and we're working on our annual report to
>>>the Director right now. One of things we are currently discussing is my
>>>own personal experience in the past year, in which some proprietary VLA
>>>data was (accidentally?)  stolen from me by someone running on-line FILLM
>>>at AOC before the data could be transferred and locked in the archive.
>>>      
>>>
>
>  
>
>>>We are trying to work out what we can say/recommend about this issue in
>>>our annual report.  Lisa Young told me you had some thoughts about some
>>>possible (simple?) changes to FILLM which might close this loophole?
>>>      
>>>
>
>  
>
>>Having not looked yet I am not sure how simple they will be:
>>    
>>
>
>  
>
>>1. FILLM has to know that it is the on-line version
>>2. It would then require that (a) the program code be specified
>>   and (b) prompt for a password
>>3. It would then pass those two on to the on-line open routine
>>4. The on-line open routine would have to compare the two with a
>>   data base of passwords and continue only if they match
>>    
>>
>
>  
>
>>The worst problem I suspect is the maintenance of the password data
>>base which would have to be current a day or more before the observing
>>run.  I guess it has to be more or less that already so it may not be
>>a problem.  The data base would have to be at the VLA as well as at
>>the AOC since miranda at the VLA is also expected to run on-line
>>FILLM.
>>    
>>
>
>  
>
>>Eric Greisen
>>    
>>
>
>  
>
>>_______________________________________________
>>Daip mailing list
>>Daip at listmgr.cv.nrao.edu
>>http://listmgr.cv.nrao.edu/mailman/listinfo/daip
>>    
>>
>
>_______________________________________________
>Daip mailing list
>Daip at listmgr.cv.nrao.edu
>http://listmgr.cv.nrao.edu/mailman/listinfo/daip
>  
>