Patakaran sa Proteksyon ng Datos

1. Layunin at saklaw

Ipinapaliwanag ng patakarang ito kung paano dinisenyo ang Qstamp SDK upang suportahan ang pagsunod sa GDPR, sa UK GDPR at sa mga katulad na batas sa ibang mga hurisdiksyon, at kung aling mga responsibilidad ang nananatili sa organisasyong gumagamit nito. Isinulat ito para sa mga organisasyong nag-i-stamp ng mga rekord gamit ang SDK.

Inilalarawan ng Patakaran sa Privacy kung paano pinoproseso ng Quantova Inc ang personal na datos tungkol sa mga bisita ng website nito at tungkol sa mga sistemang gumagamit ng mga network endpoint nito. Pangkalahatang impormasyon ang patakarang ito at hindi ito legal na payo. Dapat kumuha ang bawat organisasyon ng sarili nitong payo tungkol sa pagproseso nito.

2. Mga tungkulin

Ang organisasyong nag-i-stamp ng mga rekord gamit ang SDK ang nagtatakda ng mga layunin at paraan ng pagprosesong iyon at ito ang controller ng mga rekord, fingerprint at resibo nito. Ibinibigay ng Quantova Inc ang SDK bilang software na tumatakbo sa sariling mga sistema ng controller. Hindi ito tumatanggap ng mga rekord, fingerprint o resibo, wala itong access sa mga ito at hindi nito pinoproseso ang mga ito sa ngalan ng controller.

Sa aming pagtatasa, kung gayon, ang Quantova Inc ay hindi controller o processor ng nilalaman ng rekord, at ang paggamit ng SDK sa ganang sarili nito ay hindi nangangailangan ng data processing agreement sa Quantova Inc. Kung saan nagpapadala ang SDK ng mga kahilingan sa isang network endpoint na pinapatakbo ng Quantova Inc, kumikilos ang Quantova Inc bilang independiyenteng controller ng teknikal na datos ng kahilingan, gaya ng IP address ng sistemang tumatawag, ayon sa inilalarawan sa Patakaran sa Privacy.

Ang controller ang nagpapasya kung ano ang isusulat nito sa Quantova network at ito ang responsable sa pasyang iyon. Nagiging pampubliko ang datos na isinulat sa network at permanente itong iniingatan ng network.

3. Daloy ng datos

• Binabasa at kinukuhanan ng fingerprint ang mga rekord sa sariling mga sistema ng controller.
• Pinagsasama ang mga fingerprint sa mga random na salt at binubuo bilang isang hash tree sa sariling mga sistema ng controller.
• Para sa bawat batch, isang salted na 32 byte na commitment at ang uri ng rekord ang isinusulat sa Quantova network sa isang transaksyong nilagdaan ng account ng controller. Dala rin ng transaksyon ang address ng account na lumagda, ang kontrata, ang block, ang oras at ang bayad.
• Isinusumite ang mga transaksyon sa pamamagitan ng isang network endpoint. Kung ang endpoint ay pinapatakbo ng Quantova Inc, dala ng kahilingan ang IP address ng sistemang tumatawag at itinatala ito sa aming mga server log.
• Ang mga resibong naglalaman ng digest, salt at inclusion path ng bawat rekord ay ibinabalik sa controller at iniimbak nito.
• Hindi kailanman ipinapadala sa Quantova Inc ang mga rekord, fingerprint at resibo. Umaalis lamang ang mga ito sa mga sistema ng controller kung pipiliin ng controller na ibahagi ang mga ito, halimbawa sa isang verifier.

4. Datos na inilalathala sa network

Kinakalkula ang commitment gamit ang isang one way function sa mga salted na input, at hindi mahahango mula rito ang nilalaman ng isang rekord. Pampubliko at permanente ang uri ng rekord, ang address ng account na lumagda at ang iba pang datos ng transaksyon.

Dapat tiyakin ng mga controller na walang personal na datos o kumpidensyal na impormasyon ang mga uri ng rekord na ginagamit nila. Dapat ding lumagda ang mga controller gamit ang mga account na hawak ng organisasyon sa halip na mga account na nauugnay sa isang indibidwal, dahil maaaring maging personal na datos ang address ng account kung maiuugnay ito sa isang tao.

5. Data minimisation at privacy by design

Inilalathala lamang ng disenyo ang pinakamababang halagang kailangan upang mapatunayang umiral ang isang rekord sa eksaktong anyo nang hindi lalampas sa isang tiyak na oras, alinsunod sa prinsipyo ng data minimisation sa Artikulo 5(1)(c) ng GDPR at sa tungkulin ng data protection by design and by default sa Artikulo 25. Nananatili sa controller ang mga rekord at fingerprint, at isang commitment ang inilalathala para sa bawat batch, gaano man karami ang rekord na nilalaman ng batch.

6. Katayuan ng mga inilathalang commitment

Walang ibinubunyag ang isang commitment tungkol sa nilalaman ng isang rekord. Gayunman, habang hawak ng controller ang isang rekord at ang resibo nito, maaari pa ring maiugnay ang commitment sa rekord na iyon. Kung ang isang rekord ay tumutukoy sa isang taong makikilala, dapat ituring ng mga controller ang commitment bilang pseudonymised na personal na datos, at hindi bilang anonymous na datos, hangga't umiiral ang ugnayang iyon.

Dapat isaalang-alang ang gabay mula sa mga awtoridad sa proteksyon ng datos tungkol sa mga teknolohiyang blockchain, kabilang ang mga alituntunin ng European Data Protection Board, sa pagtatasa kung at paano ilalathala ang mga commitment na tumutukoy sa personal na datos.

7. Pagbura at mga hindi nababagong rekord

Hindi pinahihintulutan ng Quantova network na baguhin o burahin ang inilathalang datos, at hindi ito maaaring alisin ng Quantova Inc. Dahil salted commitment lamang ang inilalathala, ang controller na nagbubura ng isang rekord kasama ang bawat kopya ng resibo nito ay nag-iiwan sa network ng isang halagang hindi na maiuugnay sa sinumang tao o sa anumang nilalaman.

Dapat isama ng mga controller ang hakbang na ito sa kanilang mga pamamaraan sa pagbura, at dapat nilang ipaliwanag ang permanenteng katangian ng mga inilathalang commitment sa impormasyong ibinibigay nila sa mga kinauukulang indibidwal.

8. Mga resibo

Naglalaman ang mga resibo ng digest at salt ng katumbas na rekord. Ang partidong may hawak ng resibo ay maaaring sumubok ng mga hula tungkol sa isang rekord na may mababang pagkakaiba-iba, gaya ng isang maikling code o isang halaga. Dapat iimbak ng mga controller ang mga resibo nang may parehong proteksyon gaya ng mga rekord na inilalarawan ng mga ito, ilapat ang parehong panahon ng pagpapanatili, at burahin ang mga resibo kasabay ng mga rekord na iyon.

9. Mga signing key

Ginagamit lamang ang mga signing seed sa mga sistema ng controller. Tumatanggap lamang ang SDK ng mga seed bilang byte buffer, lumalagda mula sa isang pribadong kopya at pinapatungan ang kopyang iyon pagkatapos lumagda. Nananatiling responsable ang mga controller sa paglikha, pag-iimbak at pagpapalit ng kanilang mga key, kabilang ang sa mga hardware security module kung naaangkop.

10. Mga responsibilidad ng controller

Nananatiling responsable ang organisasyong gumagamit ng SDK sa sarili nitong pagsunod, kabilang ang mga sumusunod.

• pagtukoy ng legal na batayan para sa pag-stamp ng bawat kategorya ng rekord
• pagbibigay-alam sa mga kinauukulang indibidwal, kabilang ang tungkol sa paglalathala ng mga commitment sa isang pampubliko at permanenteng network
• pagtatala ng pagproseso sa mga rekord nito ng mga aktibidad sa pagproseso
• pagtatasa kung kinakailangan ang isang data protection impact assessment, at pagsasagawa nito kung kinakailangan
• pagtatakda ng mga panahon ng pagpapanatili para sa mga rekord at resibo, at sabay na pagbura sa mga ito
• pagprotekta sa mga rekord, resibo at signing key gamit ang mga angkop na hakbang pangseguridad
• pangangasiwa sa mga kahilingan ng mga indibidwal na gamitin ang kanilang mga karapatan
• pagtiyak na sumusunod sa batas ang sarili nitong mga paglilipat ng mga rekord at resibo, at ang mga ginagawa ng mga service provider nito
• pagsunod sa mga batas sa pagtatala ng rekord at sa mga batas sa mga SI system, kabilang ang mga batas sa artificial intelligence, na umiiral dito

11. Mga data protection impact assessment

Karaniwang bahagi ang pag-stamp ng isang mas malawak na aktibidad sa pagproseso, gaya ng pagtatala ng mga aksyon ng isang SI system. Kung ang aktibidad na iyon ay nangangailangan ng data protection impact assessment sa ilalim ng Artikulo 35 ng GDPR o ng katulad na batas, dapat tugunan ng assessment ang mga puntong nasa ibaba.

• kung aling mga rekord ang ini-stamp at kung naglalaman ang mga ito ng personal na datos
• ang paglalathala ng mga salted commitment, uri ng rekord at address ng account na lumagda sa isang pampubliko at permanenteng network
• ang pag-iimbak, kontrol sa access at pagpapanatili ng mga resibo
• ang panganib na sumubok ang partidong may hawak ng resibo ng mga hula tungkol sa mga rekord na may mababang pagkakaiba-iba, at ang mga hakbang na ginagamit upang bawasan ang panganib na iyon
• ang proseso ng pagbura, kabilang ang pagbura ng mga rekord kasama ang kanilang mga resibo
• ang network endpoint na ginagamit upang magsumite ng mga transaksyon at ang datos na tinatanggap nito

Magbibigay ang Quantova Inc ng teknikal na dokumentasyon ng SDK kapag hiniling upang suportahan ang isang assessment.

12. Mga internasyonal na aspeto

Ang SDK mismo ay walang ipinapadalang rekord sa ibang bansa, dahil tumatakbo ito sa sariling mga sistema ng controller. Pampubliko ang datos na isinulat sa Quantova network at mababasa ito mula sa anumang bansa. Dapat isaalang-alang ng mga controller na dahil sa paglalathala ay naa-access sa buong mundo ang commitment, ang uri ng rekord at ang address ng account na lumagda.

Pinangangasiwaan ang mga kahilingan sa mga network endpoint na pinapatakbo ng Quantova Inc sa mga server na pinapatakbo ng Quantova at pinoprotektahan ng Cloudflare, at maaaring iproseso ang mga ito sa labas ng sariling bansa ng controller, kabilang sa Estados Unidos, gaya ng inilalarawan sa Patakaran sa Privacy.

13. Pakikipag-ugnayan

Maaaring ipadala ang mga tanong tungkol sa patakarang ito sa [email protected].