Across the 8th Dimension

[Rob Seaman]

Some will have seen the thread in the Tech WG regarding the newly  
discovered Planet Ten:

>     From:       mjg at cacr.caltech.edu
>     Subject:     [nvo-techwg] Why security is necessary in service- 
> oriented astronomy
>     Date:     August 1, 2005 12:09:59 PM MST
>     To:       techwg at us-vo.org
>
> Hi,
>
> A lot of people have said that security should not be a big concern  
> for the astronomical community, after all what is the worst that  
> could happen: so have a look at the section entitled "Why the hasty  
> annoucement? What about the hacking? What is going on here?" on:
>
> http://www.gps.caltech.edu/~mbrown/planetlila/
>
> Rather sobering really.
>
>    Cheers,
>
>    Matthew

Certainly my own immediate reaction to the news was to worry about VO  
security.  (We all really have to get out more :-)

As we worry about the threat of the Lectroids from Planet Ten - or  
more frightening yet, about why Jeff Goldblum is dressed like a  
cowboy - we may want to consider the implications for VOEvent of  
activities similar to the harvesting of observing logs.  I've  
appended my own contribution to the techwg thread to get the ball  
rolling over here.  I'd like to see some cycles expended on VOEvent  
authentication prior to v1.1.  There are a lot of other issues we  
have to sort out, but nobody will use VOEvent if they don't trust the  
packets.

Our goal should be for the discovery of Planet Eleven to be announced  
via a VOEvent packet.  Just need to cook up a PressConference.xsl  
translator in anticipation.

Rob Seaman
NOAO
---

>     From:       seaman at noao.edu
>     Subject:     Re: [nvo-techwg] Why security is necessary in  
> service-oriented astronomy
>     Date:     August 2, 2005 2:44:45 PM MST
>     To:       techwg at us-vo.org
>
> On Aug 2, 2005, at 2:06 AM, Anita Richards wrote:
>
>> a) If data providers who have proprietary periods of restricted  
>> access or hold other confidential data have to chose between their  
>> mode of operation and becoming VO-enabled, the VO will lose out.
>
> Surely the ultimate responsibility for data access security lies  
> with the data providers?  A provider who wishes to restrict access  
> to proprietary data should refrain from making it visible via  
> whatever public interfaces, not just the VO.  This applies to  
> metadata as well as to bulk image or catalog data.
>
>> b) We will in any case have to persuade them that we do take  
>> essential security seriously
>
> Certainly a good idea in any case, but there is a difference  
> between relying on the VO to enforce a security policy (seems  
> unwise and unlikely) and the natural expectation that any VO  
> related security holes will be quickly identified and fixed.
>
> As far as Planet-10 style risks, restricting metadata access to the  
> point that the traffic analysis of observing logs and data holdings  
> is impossible has the potential to seriously degrade the quality of  
> the science resulting from the VO.  Googling the object name  
> suggested by the PIs will point you not only to target coordinates,  
> it will reveal the observing proposal ID.  Googling on that (or  
> otherwise doing a little detective work) will reveal the title and  
> perhaps abstract for that observing project.  Once you know a  
> project is ongoing (public knowledge by policy in many cases), all  
> sorts of ethically gray "monitoring" techniques suggest  
> themselves.  These are risks inherent in the way the astronomical  
> community functions - revealed by the technology, but not the fault  
> of the technology.
>
> The cure for a premature data release is to improve the collection,  
> preservation and presentation of the data's provenance.  The  
> Planet-10 article itself reveals that this is exactly what was used  
> to sort out the credit for the discovery of 2003 EL6.  This is a  
> question of document authentication techniques such as digital  
> signatures as much as access authorization techniques such as VO  
> user logins.  VO facilities such as VOEvent may require managed  
> secrecy for some applications, but will require managed trust for  
> all of them.
>
> It's also important to place these issues in the context of the  
> appropriate use cases.  Security requirements for KBOs are likely  
> quite different than security requirements for GRBs or SNe.  And as  
> was just pointed out during a discussion at our weekly staff  
> meeting, the data - let alone the metadata - that are associated  
> with 2003 EL6 and 2003 UB313 are likely well past their proprietary  
> periods already.
>
> The best defense of these projects against security violations is  
> to speed up the processing and publication of their data - this is  
> an even stronger motivating factor (potentially) for data providers  
> to become VO - and thus Grid - enabled.  The VO exists precisely to  
> make public access such as this easier and more efficient.
>
> One person's hacking is another's data mining.
>
> Rob Seaman
> NOAO
>