Henri Sivonen, korkeakouluharjoittelija, Kansallisarkisto
Henri Sivonen on laatinut tämän dokumentin Kansallisarkistossa kesällä 2002. Dokumentti sisältää Sivosen Kansallisarkistolle esittämän näkemyksen. Dokumentti ei välttämättä edusta Kansallisarkiston kantaa (eikä välttämättä edes Sivosen nykyistä kantaa).
Säädökset saattava edellyttää joidenkin dokumenttien käsittelyä osittain salaisina. Tästä syystä arkiston pitää kyetä esittämään dokumenteista versioita, joista salaiset osat on poistettu [IU Funtional Req, MoReq 9.3.10]. Niinpä tarvitaan menetelmiä salaisten osien merkitsemiseen.
XML:n sovelluksia on suhteellisen helppoa laajentaa elementeillä tai attribuuteilla, joilla voidaan merkitä jokin dokumentin osa (dokumenttipuun alipuu) salaiseksi. Kansallisarkisto voisi perustaa oman XML-nimiavaruuden, jossa olisi yksi salaisuusasteen ilmaiseva attribuutti. Kaikki elementit, jotka on ilmaistu attribuutilla salaisiksi, korvattaisiin paikanpitäjäelementillä. Muunnoksen tekevän ohjelman ei tarvitsisi ymmärtää käytettyä XML-sanastoa. Kansallisarkiston oman nimiavaruuden attribuutin ja paikanpitäjäelementin tukeminen yleisen XML:n jäsentämisen lisäksi riittäisi. Samaa ohjelmaa voisi siis käyttää kaikkien tuettujen XML-pohjaisten muotojen salaisten osien poistoon.
Jos salaisuus on määritelty sivuittain, voidaan bittikarttatiedostoihin kehittää yksinkertaisesti merkintä koko tiedoston salaisuudesta. Tällöin salaiset sivut voidaan jättää näyttämättä tai, jos dokumentti toimitetaan asiakkaan haltuun, toimittamatta asiakkaalle. Jos kuitenkin jotkin sivut ovat vain osittain salaisia, tarvitaan menettelyjä salaisten alueiden merkitsemiseen.
Kummassakin tapauksessa tarvitaan laajennuksia valittuihin bittikarttaformaatteihin ja siten myös muunnettuja ohjelmia kuvien esittämiseen tai konvertointiin sellaisiksi versioiksi, joissa salaiset alueet on korvattu jollain muulla sisällöllä (esim. kuviolla, jossa toistuu teksti ”salainen”).
Jokaisen salaisen alueen ilmaisemiseen tarvitaan neljä lukua: suorakaiteen vasemman yläkulman ja oikean alakulman koordinaatit. Ehdotan, että jokainen luku tallennetaan 32 bitillä, koska teoriassa kuvien ulottuvuudet voisivat ylittää 16 bitillä ilmaistavat mitat. (Tosin vain teoriassa, mutta näin ei ainakaan tule Y2K-ongelmaa vastaavia rajoitteita.) Jokainen salainen alue vie siis tilaa 128 bittiä. Ehdotan, että kaikissa kuvaformaattitapauksissa numerot tallennetaan järjesteyksessä x1, y1, x2, y2. Lukunelikoille ei tarvita erottimia, koska kunkin sanan rooli voidaan päätellä sijainnista jonossa. Niinpä seuraavan suorakaiteen ilmaisevat 128 bittiä voidaan kirjoittaa suoraan edellisen perään.
Koko sivun salaisuus voitaisiin ilmaista yhdellä koko sivun peittävällä suorakaiteella. Jos kuitenkin halutaan helppo tapa kokonaan salaisten sivujen pois suodattamiseen, voidaan määritellä tapaus, jossa salaisuuskenttä on käytössä, mutta suorakaiteita on 0 kpl, tarkoittamaan sitä, että koko sivu on salainen.
Tämän yleisen formaatin lisäksi tarvitaan menetelmät bittijonon paketoimiseen PNG-chunkiin, TIFF-tägiin tai JFIF-markeriin.
Ehdotus nimeksi: naRc (Isojen ja pienten kirjainten merkitys selviää [PNG]:stä.)
Pieni n: Salaisuustieto ei ole [PNG]:n tarkoittamalla tavalla kriittistä tiedoston renderoimisen kannalta, eli tapauksessa, jossa salaiset osat saavat näkyä, salaisuuden ilmaiseva chunk voidaan vain jättää huomiotta. Jos salaiset alueet ilmaiseva chunk olisi kriittiseksi luokiteltu, PNG-määritystä noudattavaa katseluohjelmaa, joka ei tue Kansallisarkiston omaa chunk-tyyppiä, ei voisi käyttää kuvan katseluun edes siten, ettei salaisia osia ole poistettu näkyvistä. Tietenkään salaisia osia sisältäviä tiedostoja ei saa antaa renderoitavaksi tavallisella PNG-katseluohjelmalla, jos ohjelman käyttäjällä ei ole lupaa nähdä salaisia osia. Chunkin määrittely kriittiseksi ei kuitenkaan olisi mikään todellisen suojaus salaisten osien lukua vastaan, jos tiedosto on jo hallussa, koska mahdollinen luvaton käyttäjä voisi poistaa chunkin tiedostosta varsin helposti. (Siispä tilanteessa, jossa salaiset osat eivät saa näkyä, salaisten osien poisto täytyy tehdä joka tapauksessa arkiston omalla ohjelmalla ennen kuin tiedosto toimitetaan asiakkaalle.)
Pieni a: Chunk-tyyppi on yksityinen. Se on siis tarkoitettu Kansallisarkiston omaan käyttöön.
Iso R: Kolmannen kirjaimen on PNG:n nykyversioissa aina pakko olla iso kirjain.
Pieni c: Chunkin saa kopioida. Sallitaan chunkin kopiointi uuteen tiedostoon vaikkapa siinä tilanteessa, että kuvadata pakataan uudestaan PNG-optimointiohjelmalla.
Koska ei voida olla varmoja siitä, ettei joku muu ole keksinyt käyttää naRc-nimistä chunkia, olisi varovaista (ja tavan mukaista) kirjoittaa chunkin data-alueelle jokin vakiotavujono, jonka löytäminen nostaa todennäköisyyttä, että naRc-chunk on juuri Kansallisarkiston naRc-chunk. Data-alueen alkuun voidaan kirjoittaa vaikka merkkijono ”sala” ASCII-koodattuna (eli sitä voidaan tarkastella neljänä vakiotavuna).
Vakiotavujonon perään data-alueelle tallennetaan yllä kuvattu suorakaidekoordinaateista koostuva tavujono. Jonon pituutta ei tarvitse ilmaista data-alueella, koska chunkin pituus kuuluu chunkiin joka tapauksessa. Suorakaiteiden määrä on siis (chunkin_pituus – 4) / 16. Jos em. kaavan tulos ei ole positiivinen kokonaisluku tai 0, chunk on virheellinen.
32-bittiset luvut tallennetaan enemmän merkitsevä tavu ensin, kuten muutkin monitavuiset arvot PNG:ssä.
(Arkistoon oton yhteydessä on syytä tarkistaa, että naRc-chunkit ovat uskottavan mittaisia ja alkavat oikealla vakiotavujonolla.)
Lisätietoja [PNG]:stä.
Pyydetään Adobelta yksityinen täginumero. Kentän tyyppiksi sopii LONG-taulukko. (LONG on TIFF:issä 32-bittinen kokonaisluku.)
Yllä kuvattu koordinaattijono tallennetaan kentän arvona. Tavujärjestys riippuu tiedoston tavujärjestyksestä.
Lisätietoja [TIFF]:stä.
JFIF-tiedostossa on 17 erilaista markeria: kommenttimarker ja 16 markeria sovelluskäyttöön (APP0-APP15). Näistä APP0 on varattu JFIF-formaatille itselleen. APP14 on käytännössä varattu Adoben määrittelemälle datalle. SPIFF-formaatti varaa markerin APP8.
Jäljelle jäävistä markereista valitaan jokin Kansallisarkiston käyttöön: esim. APP1.
Kuten PNG:n kohdalla, markerin data-arvoon kannattaa liittää jokin vakiotavujono, jotta voidaan hyvällä todennäköisyydellä tarkistaa, onko marker Kansallisarkiston järjestelmän kanssa yhteensopivan ohjelman kirjottama vai jokin muu marker. Ehdotan, että markerin data-arvoksi kirjoitetaan ”narcsala” ASCII-koodattuna ja sitten aiemmin kuvattu koordinaattijono siten, että eniten merkitsevä tavu tulee ensin (network byte order). Kentän pituuden ilmaisu sisältyy yleiseen marker-formaattiin.
Lisätietoja [IJG]:stä.
PDF:n kohdalla salaisten alueiden merkitseminen riittäisi vain siinä tapauksessa, että dokumenttia katseltaisiin Kansallisarkiston omalla muunnellulla katseluohjelmalla. PDF-tiedostosta olisi vaikeaa poistaa salaisia osia suorakaidedatan perusteella, joten suorakaiteen koodaaminen ei kelpaa siihen, että tiedostosta tehtäisiin toinen versio. Lisäksi dokumentin muunteluun liittyy fonttilisenssiongelmia, koska monesti upotus on sallittu vain siinä tapauksessa, ettei dokumenttia editoida.
Teoreettinen vaihtoehto olisi se, että PDF-olioihin merkittäisiin, ovatko ne salaisia. Tämän järjestäminen luotettavasti PDF:n luontivaiheessa olisi kuitenkin niin vaikeaa, ettei tämä oli realistinen vaihtoehto.
Jos PDF:ssä on salaisia osia, on varmempaa luoda alunperin PDF:stä vaihtoehtoinen versio, josta salaiset osat on poistettu lähtödokumentista ennen PDF:n generointia (ei ainoastaan peitetty toisilla grafiikkaolioilla!). Varmin tapa on se, että vaihtoehtoinen versio, josta salaiset osat on poistettu, on jossain yksinkertaisemmassa formaatissa, esim. bittikarttana.
Ääni- ja videotiedostojen yhteyteen voitaisiin periaatteessa määritellä salaisia ajanjaksoja ja videohin aikariippuvaisia salaisia kuva-alueita. Tällaisten ominaisuuksien tukeminen voi kuitenkin olla työlästä.
Salaisten osien merkitseminen pelkkään tekstiin edellyttäisiä joko salaiset osat ilmaisevien osoittimien tallentamista tai vaihtoehtoisesti salaisten osien tägitystä. Ehkä helpoimmin toteutettava vaihtehto on se, että tekstistä tallennetaan kaksi versiota.
Toiseksi helpoin menettely lienee se, että määritellään XML-pohjainen kieli, jossa on vain jokin juurielementti ja toinen elementti salaisten osien merkkaamiseen (kummallakin attribuutti xml:space="preserve").
[IU Funtional Req] Functional Requirements for Recordkeeping Systems (luonnos). IU Electoric Records Project. Indiana University. 2001.
[MoReq] Model Requirements for the Management of Electronic Records. (”MoReq Specification”.) Marc Fresko (toim.) ja Martin Waldron (toim.). Euroopan komissio. 2001.
[PNG] PNG (Portable Network Graphics) Specification Version 1.0. Thomas Boutell (toim.). W3C. 1996. URL: http://www.w3.org/TR/REC-png.html
[TIFF] TIFF Revision 6.0. Adobe Systems, Inc. 1992. URL: http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf
[IJG] Using the IJG JPEG Library. Thomas G. Lane. The Independent JPEG Group. 1998.(Dokumentti sisältyy IJG:n JPEG-kirjaston levityspakettiin, joka on saatvilla palvelimelta http://www.ijg.org/)