Zásady ochrany osobních údajů
Účinné od 29. září 2026 · Verze 1.0
Tento text popisuje, jak s osobními údaji zachází systém Simex Distribution Hub — nástroj, kterým společnost TRUCK SHOP SIMEX s.r.o. rozesílá obchodní sdělení svým zákazníkům a zveřejňuje letáky na svých firemních profilech na sociálních sítích.
Popisujeme skutečné chování programu, ne to, jak by to mělo být. Kde systém něco neumí, je to tady napsané také — včetně toho, že smazání kontaktu v administraci je jen měkké a že sledování otevření e-mailů je po instalaci zapnuté.
1. Kdo údaje zpracovává
Správce údajů: TRUCK SHOP SIMEX s.r.o., IČO 26479818, DIČ CZ26479818, se sídlem Za zastávkou 373, Dolní Měcholupy, 111 01 Praha 10, zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, oddíl C, vložka 84938 (zapsána 24. 9. 2001). Provozuje e-shop www.truckshopsimex.cz.
Kontakt pro žádosti a dotazy k osobním údajům: simex2@simex2.cz, nebo poštou na adresu sídla uvedenou výše.
Systém vytvořila společnost Quantiva (quantiva.cz).
2. Čích údajů se to týká
- Zákazníků e-shopu a dalších příjemců rozesílky — jejich údaje tvoří hlavní obsah systému.
- Návštěvníků úvodní stránky, kteří napíšou přes kontaktní formulář.
- Zaměstnanců a spolupracovníků provozovatele, kteří mají přístup do administrace.
Systém nemá žádný samoobslužný portál ani přihlášení pro příjemce. Do administrace se dostanou jen účty, které založil správce systému — veřejná registrace neexistuje.
Systém rozlišuje šest rolí — Admin (plný přístup včetně konfigurace a správy uživatelů), CampaignManager (správa a schvalování kampaní), Editor (tvorba textů a šablon bez práva odeslat), Operator (spouštění připravených kampaní), Auditor (pouze čtení historie a auditu) a Integration (strojový přístup přes API bez administrace).
Oprávnění zobrazit celou e-mailovou adresu mají jen role Admin a CampaignManager, oprávnění odebrat adresu ze seznamu blokovaných adres jen role Admin. Které osoby provozovatele mají který účet a jakou roli, určuje provozovatel.
3. Jaké údaje zpracováváme, proč a jak dlouho
3.1 E-mailová adresa příjemce
Proč: aby se dalo odeslat obchodní sdělení, poznat duplicitní záznam a porovnat adresu se seznamem blokovaných adres.
Jak dlouho: dokud kontakt v systému existuje. Upřímně: systém nemá žádnou lhůtu, po které by adresa z databáze zmizela sama. Smazání kontaktu v administraci je jen měkké — vyplní se datum smazání, kontakt zmizí z výpisů a z kampaní, ale řádek se zašifrovanou adresou v databázi zůstává. Noční úklid podle retenční politiky se kontaktů vůbec netýká. Tyto zásady proto neslibují žádnou lhůtu, po jejímž uplynutí by kontakt z databáze zmizel sám — taková lhůta v systému není. Kdo chce výmaz, napíše na kontakt uvedený v oddílu 1; jak výmaz technicky proběhne, popisuje oddíl 11.
Jak je zabezpečená: u kontaktu, u příjemce kampaně i v importní dávce leží adresa v databázi jen zašifrovaná (AES-256-GCM, autentizované šifrování; v každém záznamu je i verze klíče). Pro hledání a pro porovnání se seznamem blokovaných adres se používá klíčovaný otisk HMAC-SHA256 — ne holý hash, takže bez znalosti klíče z něj adresu zpětně zjistit nelze. V administraci se standardně ukazuje jen maskovaná podoba typu ja***@f***.cz. V celém programu existují jen čtyři místa, kde se adresa dešifruje: odesílání, import, příprava kampaně a zobrazení jedné adresy obsluhou.
Jedna výjimka existuje a patří sem, i když se netýká zákazníků: adresu pro zkušební odeslání, kterou obsluha napíše rukou, si systém uloží do frontové úlohy a do interní zprávy v otevřené podobě (viz oddíl 3.14).
3.2 Jméno, příjmení a název firmy
Proč: oslovení ve zprávě (slučovací pole {{FirstName}}, {{LastName}}, {{FullName}}, {{Company}}) a rozlišení kontaktů v administraci.
Jak dlouho: stejně jako adresa — dokud kontakt existuje. Měkké smazání je nemaže.
Zabezpečení: tyto údaje nejsou v databázi zašifrované, leží v otevřené podobě. Chrání je přístup do administrace (přihlášení, oprávnění) a to, že spojení k databázi se v nasazení nastavuje jako šifrované.
3.3 Jazyk kontaktu, poznámka obsluhy, identifikátor z jiného systému a volné atributy
Proč: výběr jazykové mutace šablony, doplňující slučovací pole a dohledatelnost, odkud kontakt vznikl. Ze synchronizace s e-shopem tyto údaje nepocházejí — vznikají jen z importovaného souboru, z ručního zadání nebo přes API. Ze synchronizace se přenáší pouze adresa, jméno, příjmení a firma.
Vedle toho se u kontaktu eviduje zařazení do skupin (podle nich se cílí kampaň). Synchronizace z e-shopu zakládá vlastní skupinu a nové kontakty do ní vkládá.
Jak dlouho: dokud kontakt existuje. Zabezpečení: otevřeně v databázi, za přihlášením.
3.4 Záznam o souhlasu
Ke každému kontaktu a kanálu se eviduje typ a stav souhlasu, jeho zdroj, datum udělení a odvolání, textový doklad a — pokud souhlas vznikl při webovém požadavku — také IP adresa toho požadavku. Pozor na to, čí adresa to je: u souhlasu zadaného rukou v administraci je to IP obsluhy, ne zákazníka. Běh na pozadí (například synchronizace z e-shopu) žádnou IP adresu nemá, takže se nezapíše.
Proč: aby bylo doložitelné, kdo, kdy a na jakém základě dostává obchodní sdělení a kdy si to zrušil.
Jak dlouho: trvale. Záznam se nemaže a nepřepisuje se novým souhlasem — odvolání jen doplní stav „odvolán“ a datum odvolání, zdroj, doklad i datum udělení zůstávají. Nový souhlas vzniká jako nový záznam, ne přepsáním starého. Retenční úklid souhlasy nemaže.
3.5 Seznam blokovaných adres
Adresy, na které se už nikdy nic neodešle. Vznikají z odhlášení z odběru, z odmítnutí schránky poštovním serverem (neexistuje nebo zprávu nepřijme), z hlášení poskytovatele o nedoručitelnosti nebo o stížnosti na spam, nebo z ručního zařazení obsluhou. Jiné trvalé chyby odesílání sem adresu nedostanou — s příjemcem nesouvisí.
Proč: aby odhlášení mělo trvalý účinek — a to i po smazání kontaktu nebo po jeho opětovném naimportování z jiného zdroje. Seznam se kontroluje při přípravě kampaně a znovu těsně před odesláním každé jednotlivé zprávy.
Jak dlouho: trvale, a to záměrně. Retenční úklid seznam nemaže. Odebrat záznam umí jen obsluha se zvláštním oprávněním a každé odebrání jde do auditu; hromadné odebrání systém neumí vůbec.
Zabezpečení: samotná adresa se tu neuchovává — jen klíčovaný otisk HMAC-SHA256 a maskovaná podoba.
3.6 Zamražený příjemce kampaně
Ve chvíli přípravy kampaně se z kontaktu udělá kopie: zašifrovaná adresa, její otisk, maskovaná podoba a hodnoty slučovacích polí.
Proč: aby pozdější úprava kontaktu nezměnila historii dávno odeslané kampaně a aby statistiky zůstaly platné. Unikátní index (kampaň plus otisk adresy) brání dvojímu odeslání.
Jak dlouho: dokud kampaň v systému je. Smazáním kampaně v administraci zmizí i její příjemci. Retenční úklid je nemaže.
Zabezpečení: adresa je i tady jen zašifrovaná. V zamražených slučovacích polích je jméno, příjmení, firma, název kampaně a atributy — e-mailová adresa v nich není, ta se dosazuje teprve při odesílání.
3.7 Statistika doručení a události doručení
U každého příjemce se eviduje stav, čas odeslání a doručení, čas prvního otevření a prvního kliknutí, počet otevření a kliknutí, identifikátor zprávy od poskytovatele a poslední chyba. Zdrojem pravdy je samostatná tabulka událostí, do které se jen přidává (typ události, čas, poskytovatel, identifikátor zprávy, a v doplňujících datech cílová adresa prokliku a údaj o prohlížeči nebo poštovním klientovi).
Proč: vyhodnocení kampaně (otevřenost, proklikovost, doručitelnost) a řešení reklamací „e-mail nedorazil“.
Jak dlouho: agregovaná čísla u příjemce žijí spolu s kampaní. Jednotlivé události maže noční úklid po 395 dnech — to je hodnota, kterou systém zapíše při instalaci. Lhůty jsou uložené v systémovém nastavení v databázi; administrace pro jejich změnu žádnou obrazovku nemá, mění se tedy zásahem do databáze. Nula znamená nemazat. Ke dni účinnosti těchto zásad se lhůty nastavené v provozní databázi shodují s hodnotami uvedenými v tomto oddílu 3, tedy s hodnotami zapsanými při instalaci.
Zabezpečení: IP adresa se do události záměrně neukládá — v programu je to výslovně napsané. Do události se nikdy nezapisuje e-mailová adresa. Cílová adresa prokliku se krátí na 2000 znaků, údaj o prohlížeči na 300 znaků.
3.8 Odhlašovací token
Ke každé odeslané zprávě systém vystaví vlastní odhlašovací odkaz. V databázi je uložen jen otisk tokenu (SHA-256 z 32 náhodných bajtů), vazba na kontakt, kanál a kampaň, platnost, čas použití a IP adresa, ze které se odhlášení provedlo.
Jak dlouho: token platí rok. Použité a prošlé tokeny maže noční úklid po 30 dnech (hodnota nastavená při instalaci) — a s nimi zmizí i uložená IP adresa. Token, který ještě nebyl použit a neprošel, se nemaže: je to živý odkaz v e-mailu ve schránce příjemce.
Zabezpečení: z obsahu tabulky nejde funkční odhlašovací odkaz sestavit, protože je v ní jen otisk.
3.9 Auditní záznam
U každé významné operace se eviduje kdo (identifikátor a jméno uživatele), co (akce, typ a identifikátor záznamu), stav před a po změně, IP adresa, údaj o prohlížeči, korelační identifikátor a výsledek. Zaznamenává se mimo jiné změna a smazání kontaktu, udělení a odvolání souhlasu, zobrazení celé e-mailové adresy, spuštění kampaně, běh synchronizace, úklid a změna nastavení.
Proč: doložitelnost, kdo co s údaji udělal.
Jak dlouho: 1095 dní, tedy tři roky (hodnota nastavená při instalaci). Starší záznamy maže noční úklid.
Zabezpečení: auditní záznam se po zapsání už nemění — aplikace do té tabulky nedělá UPDATE a jediné mazání je právě úklid po uplynutí retenční lhůty. Role Auditor má jen čtení. E-mailové adresy se do auditu zapisují maskované — audit nesmí být obchvatem šifrování.
3.10 Nahraná dávka importu
Při importu se uloží název souboru, jeho velikost a otisk SHA-256, souhrnné počty a u každého řádku zašifrovaný e-mail, jeho otisk, maskovaná podoba, jméno, firma, jazyk, cizí identifikátor a ostatní sloupce souboru. Data se nejdřív zvalidují, obsluha je schválí a teprve pak se přenesou mezi kontakty. Bez vyplněného dokladu o souhlasu (odkaz na formulář, znění souhlasu nebo číslo smlouvy) systém soubor vůbec nepřijme — platí to pro administraci i pro rozhraní API. Typ a zdroj souhlasu se k dávce zapisují vždy a vybírá je obsluha.
Jak dlouho: řádky dávky maže noční úklid po 90 dnech (hodnota nastavená při instalaci). Nahraný soubor se neukládá ani do databáze, ani do souborového úložiště aplikace — zpracuje se při nahrání z proudu a zůstane po něm jen otisk, velikost a název.
Zabezpečení: e-mail je zašifrovaný už při nahrání, ne až po schválení.
3.11 Zpráva z kontaktního formuláře na úvodní stránce
Do databáze se neukládá nic — ani jméno, ani e-mail, ani text. Zpráva se rovnou pošle e-mailem do schránky, kterou má provozovatel pro příjem zpráv z formuláře nastavenou; adresa tazatele jde do pole Reply-To, aby šlo odpovědět. Zpráva tedy zůstává jen v té poštovní schránce.
Do provozního logu aplikace se při úspěšném odeslání zapíše jméno, které tazatel vyplnil ve formuláři, a adresa cílové schránky, kam zpráva šla. Text zprávy ani e-mailová adresa tazatele se do logu nezapisují. IP adresa tazatele se drží hodinu v paměti serveru kvůli omezení tří zpráv za hodinu; při překročení limitu se zapíše do logu.
Zabezpečení: proti robotům má formulář skryté pole a strop tří zpráv za hodinu na jednu IP adresu. Bez šifrovaného spojení k poštovnímu serveru se neodešle nic. Když cílová schránka v nastavení chybí, formulář se přesto zobrazí; odeslaná zpráva se pak zahodí (nikam se neuloží) a tazatel dostane chybovou hlášku.
3.12 Uživatel administrace
Přihlašovací jméno, e-mail, jméno, otisk hesla, čas a IP posledního přihlášení, čas změny hesla, příznak aktivity, poznámka správce a nastavení druhého faktoru. Účty zakládá správce systému; jde o lidi provozovatele, ne o příjemce rozesílky.
Jak dlouho: dokud účet existuje. Systém účty sám nemaže ani nedeaktivuje.
Zabezpečení: heslo musí mít nejméně 14 znaků, číslici, malé i velké písmeno, nealfanumerický znak a šest různých znaků. Po pěti neúspěšných pokusech se účet na 15 minut zamkne. Nový účet i účet po resetu hesla musí heslo změnit. K dispozici je dvoufázové přihlášení. Přihlašovací endpoint má limit pět pokusů za minutu na kombinaci IP adresy a jména.
3.13 Hlášení od poskytovatele pošty (webhook)
Pokud je pro poskytovatele nastavené sdílené tajemství, ukládá se tělo jeho hlášení tak, jak přišlo (delší požadavek než 8000 znaků systém odmítne, nezkracuje ho). Pokud v něm poskytovatel pošle e-mailovou adresu, leží v databázi otevřeně. Bez ověřeného podpisu (HMAC-SHA256, porovnání v konstantním čase) systém hlášení odmítne; bez nastaveného tajemství nepřijme nic. Tajemství se čte z konfigurace serveru, ne z administrace.
Jak dlouho: 30 dní od přijetí (hodnota nastavená při instalaci), a to u zpracovaných a ignorovaných hlášení.
Ke dni účinnosti těchto zásad systém žádné takové hlášení nepřijal — tabulka přijatých hlášení je prázdná. Bez nastaveného sdíleného tajemství rozhraní nic nepřijme, takže se tento oddíl uplatní teprve tehdy, až provozovatel hlášení u svého poskytovatele pošty zapne.
3.14 Frontová úloha a interní zpráva (zkušební odeslání)
Odesílání běží přes frontu úloh. U běžné kampaně nese úloha jen odkazy do databáze — identifikátor kampaně a příjemce, žádnou adresu ani text.
Výjimkou je zkušební odeslání. Adresu, kterou obsluha napíše na obrazovce kampaně (nebo pošle přes API), systém uloží v otevřené podobě do interní zprávy (fronty událostí) a odtud do frontové úlohy, a to i do jejího klíče proti dvojímu odeslání. Nejsou to adresy zákazníků z rozesílky, ale adresy, které zadala obsluha (typicky vlastní nebo kolegů). Do auditu se zapisují maskované.
Jak dlouho: dokončené a zrušené úlohy včetně záznamů o jednotlivých pokusech maže noční úklid 30 dní po dokončení, zpracované interní zprávy po 7 dnech (hodnoty nastavené při instalaci). Úlohy neuzavřené kampaně zůstávají i po uplynutí lhůty, jinak by kampaň uvízla.
Zabezpečení: u záznamu o pokusu a u příjemce se uchovává poslední chyba. Odpověď poštovního serveru se před uložením upraví — e-mailové adresy v ní se maskují stejně jako v administraci a text se zkracuje na 300 znaků.
3.15 Provozní a přístupové logy
Soubory aplikačního logu se drží 31 dní (denní soubory, 31 posledních).
Do aplikačního logu se e-mailová adresa nepíše: u přeskočené adresy se loguje jen doména, odpověď poštovního serveru je maskovaná a sledovací token se do logu nezapisuje vůbec.
Do přístupového logu reverzní proxy (webový server, který stojí před aplikací) se zapisují IP adresy návštěvníků veřejných stránek — úvodní stránky, odhlašovací stránky, stránky letáku i webové verze zprávy — a mohou v něm být i požadavky na sledovací adresy, tedy otevření e-mailu a kliknutí na odkaz.
Tento log nevytváří ani nespravuje aplikace. Reverzní proxy patří k hostingu, její konfigurace se pořizuje mimo tento program, a jak dlouho se přístupové logy drží, určuje nastavení serveru, ne aplikace.
4. Odkud údaje máme
- Ze zákaznické databáze e-shopu. Čte se výhradně tabulka
dbo.EshopUsersa z ní jen sloupce e-mail, jméno, firma, datum registrace a příznak newsletteru. Telefon ani údaje o posledním přihlášení se nečtou. Do e-shopu systém nikdy nezapisuje — takovou operaci vůbec nemá. - Z importu souboru CSV nebo XLSX, který nahraje obsluha.
- Z ručního zadání v administraci.
- Přes API z nadřazeného systému.
Potvrzení odběru e-mailem (double opt-in) systém nemá a na veřejném webu není žádný formulář k přihlášení k odběru. Kontakty tedy nevznikají tím, že by se někdo na webu přihlásil.
5. Na jakém základě posíláme obchodní sdělení
Zákazníkům, kteří v e-shopu odběr newsletteru zaškrtli, posíláme na základě jejich souhlasu.
U vlastních zákazníků, kteří odběr nezaškrtli, posíláme podle § 7 odst. 3 zákona č. 480/2004 Sb. — obchodní sdělení vlastnímu zákazníkovi k podobnému zboží, s možností odmítnout ho v každé zprávě. Systém u nich souhlas s odkazem na toto ustanovení zapisuje.
Ať je to řečeno přímo: synchronizace ze zákaznické databáze e-shopu zapíše marketingový souhlas každému novému kontaktu. Zaškrtnutá volba v e-shopu nerozhoduje o tom, jestli souhlas vznikne, ale jen o tom, co se o jeho původu zapíše do dokladu — buď webový formulář e-shopu, nebo zákaznický vztah podle výše uvedeného paragrafu. Adresu, která má souhlas odvolaný nebo je na seznamu blokovaných adres, synchronizace přeskočí a souhlas jí nedá.
Auditní záznamy a seznam blokovaných adres vedeme proto, abychom uměli doložit, že se odhlášení respektuje, a abychom v rozesílání po odmítnutí nepokračovali. Bez těchto záznamů by odhlášení nešlo dodržet ani prokázat.
6. Komu údaje předáváme
Poskytovatel poštovního serveru (SMTP), přes který rozesíláme. Dostane celou zprávu: adresu příjemce, předmět, obsah i hlavičky pro odhlášení. Spojení je vždy šifrované, nešifrované systém odmítá. Je to zpracovatel osobních údajů; kdo to konkrétně je, určuje nastavení provozovatele — jeho jméno vám na žádost sdělíme na kontaktu v oddílu 1.
Poskytovatel hostingu a správce serverů, na kterých běží aplikace a databáze. Mají k serverům technický přístup, a jsou proto v postavení zpracovatele. Jejich jméno vám na žádost sdělíme na kontaktu v oddílu 1.
Facebook a Instagram (Meta). Posílá se text příspěvku a buď obrázek letáku, nebo text a odkaz. Když příloha nese veřejnou adresu letáku, posílá se jen ta adresa a Meta si obrázek stáhne sama; příloha bez veřejné adresy se na Facebook nahraje po bajtech. U příběhů na Instagramu se posílá vždy jen veřejná adresa obrázku. Žádné údaje kontaktů se nepředávají.
Google (rozhraní firemního profilu). Posílá se text příspěvku, veřejná adresa obrázku letáku, adresa tlačítka, typ příspěvku a jazyk. Žádné údaje kontaktů se nepředávají.
Meta Marketing API u placené reklamy na Facebooku. Posílá se text reklamy, obrázek a cílení. Cílení umí jen čtyři věci: seznam zemí, věk od, věk do a umístění (feed nebo příběh). Žádné vlastní publikum, žádný seznam zákazníků, žádné nahrávání e-mailových adres ani jejich otisků do Mety.
Databáze e-shopu — jen ke čtení, v rozsahu popsaném výše.
Po instalaci jsou všechny externí kanály (Facebook, Instagram, Google firemní profil i placená reklama na Facebooku) vypnuté a zapíná je správce v administraci. Co se opravdu používá, je tedy otázka nastavení, ne kódu. Ke dni účinnosti těchto zásad je zapnuté jen zveřejňování na Facebooku; Instagram, Google firemní profil a placená reklama na Facebooku jsou vypnuté a nic se přes ně nezveřejňuje.
Nikam nepředáváme údaje kontaktů žádné inzertní ani analytické síti. V programu neexistuje jediné místo, které by e-mailovou adresu, její otisk nebo seznam příjemců poslalo Facebooku, Instagramu, Googlu nebo reklamnímu rozhraní Mety.
Veřejně dostupná webová verze rozeslané zprávy (odkaz „zobrazit v prohlížeči“) se záměrně vykresluje bez slučovacích polí, takže jméno, firma ani adresa příjemce se do ní nedostanou ani tehdy, když někdo do šablony přidá další proměnnou. Stránka navíc nese hlavičku noindex a kampaň, která se ještě nezačala odesílat, veřejně neexistuje.
7. Zabezpečení — co platí a co netvrdíme
Co systém opravdu dělá:
- E-mailové adresy kontaktů, příjemců kampaní a importních dávek jsou v databázi zašifrované (AES-256-GCM), pro hledání se používá klíčovaný otisk HMAC-SHA256.
- V administraci se adresa ukazuje maskovaná. Zobrazení celé adresy má vlastní oprávnění a zapisuje se do auditu, i když se povede.
- Spojení k poštovnímu serveru je vždy šifrované — nešifrovanou variantu systém vůbec nemá. Spojení k databázi se v nasazení nastavuje jako šifrované.
- Veřejné rozhraní, přihlášení i kontaktní formulář mají omezení počtu požadavků.
- Přihlašovací cookie je nedostupná skriptům, v produkci se posílá jen přes HTTPS, má nastavení
SameSite=Stricta platí hodinu od poslední aktivity.
Co netvrdíme:
- Netvrdíme, že „všechna data v databázi jsou šifrovaná“. Šifrované jsou e-mailové adresy kontaktů a uložená tajemství. Jméno, firma, poznámky, souhlasy, auditní log, adresa zkušebního odeslání ve frontě i tělo hlášení od poskytovatele pošty leží v databázi otevřeně.
- Netvrdíme, že je na databázovém serveru zapnuté šifrování dat na disku. To je nastavení databázového serveru, které tento program neřídí.
- Netvrdíme, že jsou zálohy databáze šifrované. Postup pro šifrovanou zálohu je v provozní dokumentaci popsaný, ale zálohovací skript při nenastaveném certifikátu pořídí zálohu nešifrovanou a jen o tom napíše varování do logu. Je to tedy otázka nastavení serveru, ne programu.
8. Sledování otevření a prokliků v e-mailech
Po instalaci je sledování otevření i prokliků zapnuté a ke dni účinnosti těchto zásad zapnuté je. Vypnout se dá — obojí má vlastní přepínač v systémovém nastavení — ale obrazovku na to administrace nemá, mění se to zásahem do nastavení v databázi.
- Otevření: do zprávy se vloží průhledný obrázek 1×1; jeho stažení se započítá jako otevření.
- Prokliky: odkazy ve zprávě se přepíšou tak, aby vedly přes náš server, kliknutí se zaznamená a prohlížeč se hned přesměruje na původní adresu.
Co se zaznamená: zvýší se počítadlo otevření nebo kliknutí u příjemce, doplní se čas prvního otevření nebo prvního kliknutí, a k události se uloží cílová adresa prokliku a údaj o prohlížeči nebo poštovním klientovi. IP adresa se do události neukládá.
Sledování je spojené s konkrétním příjemcem — sledovací odkaz nese podepsaný identifikátor kampaně a příjemce. Podpis znamená, že si příjemce nemůže z vlastního odkazu odvodit odkaz někoho jiného a že přesměrování nejde odklonit jinam. Do logu se sledovací token nikdy nezapisuje, právě proto, že identifikuje příjemce.
Když sledování nefunguje nebo když poštovní klient obrázky blokuje, příjemci se tím nic nerozbije: sledovací adresy nikdy nevracejí chybu a kliknutí na odkaz přesměruje i tehdy, když se záznam nepodaří uložit.
Webová verze rozeslané zprávy ani stránka letáku nepatří do vyhledávačů — obě vracejí hlavičku noindex, nofollow.
9. Cookies
Veřejná úvodní stránka nenastavuje žádné cookies a nenahrává nic z cizích serverů. Písmo, styl i skript leží na vlastním serveru. Zásady zabezpečení obsahu povolují jen vlastní původ, takže by se analytický ani reklamní skript ani nespustil. Na stránce není Google Analytics, Meta Pixel ani jiný měřicí kód.
V administraci jsou jen technicky nezbytné cookies: přihlašovací, cookie ochrany proti podvrženému odeslání formuláře (antiforgery), kterou zakládá framework, a — jen když obsluha spustí přihlášení ke Googlu — krátkodobá cookie toho přihlašovacího toku. Ta je zašifrovaná, nedostupná skriptům, posílá se jen na obrazovku nastavení Googlu, platí deset minut a po návratu z Googlu se hned maže; drží náhodný stav, hodnotu PKCE a identifikátor přihlášené obsluhy, aby přihlášení dokončil jen ten, kdo ho začal. Žádná analytická, reklamní ani preferenční cookie v systému není — proto tu není ani cookie lišta, není co odsouhlasovat.
IP adresu používáme i tam, kde ji neukládáme do databáze: jako klíč pro omezení počtu požadavků v paměti serveru. Přístupový log webového serveru před aplikací ale IP adresy obsahuje.
10. Odhlášení z odběru
Každá zpráva nese vlastní odhlašovací odkaz a hlavičky List-Unsubscribe a List-Unsubscribe-Post, takže se dá odhlásit jedním kliknutím přímo v poštovním klientovi.
Odhlášení se projeví okamžitě. Odvolá souhlas, zařadí otisk adresy na seznam blokovaných adres a zruší i úlohy, které už čekají ve frontě — nečeká se na příští kampaň.
Odhlášení je běžným provozem nevratné. Synchronizace z e-shopu souhlasy jen uděluje, žádný neodvolává, a adresu s odvolaným souhlasem v každém dalším běhu přeskočí. Adresa na seznamu blokovaných se nezaloží, neoživí a nedostane souhlas žádného druhu, ani kdyby ho e-shop hlásil. Změna zaškrtnutí newsletteru v e-shopu už založený kontakt nijak nezmění.
Odkaz z e-mailu odhlašuje až po potvrzení, ne pouhým načtením adresy — aby příjemce neodhlásil antivirus nebo poštovní klient tím, že si odkaz na pozadí načte. Kdo na odkaz klikne rukou, dostane nejdřív potvrzovací stránku s tlačítkem. Opakované použití téhož odkazu se hlásí jako úspěch. Odkaz platí rok.
Z veřejné webové verze zprávy se odhlásit nelze — stránka neví, kdo si ji prohlíží, a vede proto na vysvětlení.
11. Vaše práva a jak je uplatnit
Máte práva podle obecného nařízení o ochraně osobních údajů: na přístup k údajům, na opravu, na výmaz, na omezení zpracování, na přenositelnost, na vznesení námitky a právo podat stížnost u dozorového úřadu. Uplatníte je u provozovatele na kontaktu uvedeném v oddílu 1. Podle nařízení vám musíme odpovědět do jednoho měsíce od doručení žádosti.
Abyste věděli, co od systému čekat, popisujeme rovnou, jak to technicky funguje:
Námitka proti obchodním sdělením je to nejrychlejší, co můžete udělat, a funguje sama: odhlášení podle oddílu 10 zabere okamžitě a je nevratné.
Přístup k údajům. Systém neumí vyexportovat kontakty do souboru. Souhrn všech údajů o jednom člověku proto sestavuje obsluha ručně z administrace. Oprávnění „export kontaktů“ v systému znamená jen to, že obsluha smí u jednoho kontaktu zobrazit celou e-mailovou adresu místo maskované — a i toto zobrazení se zapisuje do auditu.
Oprava údajů. Jméno, firmu, jazyk, poznámku a stav kontaktu umí změnit obsluha v administraci a každá změna jde do auditu. Sami za sebe to udělat nemůžete — samoobslužný portál pro příjemce v systému není.
Výmaz. Tady buďme přesní: smazání kontaktu obsluhou je jen měkké. Kontakt zmizí z výpisů a z kampaní, ale řádek se zašifrovanou adresou, jménem, firmou, poznámkou a souhlasy v databázi zůstává. Trvalý výmaz kontaktu aplikace neumí — žádná taková operace v ní není a noční úklid se kontaktů, kanálů, souhlasů, seznamu blokovaných adres ani příjemců kampaní vůbec netýká. Skutečný výmaz jde provést jen zásahem do databáze mimo aplikaci.
Žádost o výmaz proto vyřizuje provozovatel na kontaktu z oddílu 1: měkké smazání provede obsluha v administraci, trvalé odstranění řádku z databáze musí udělat správce zásahem mimo aplikaci. Systém sám na to žádnou lhůtu nevynucuje; lhůta pro odpověď na žádost vyplývá z nařízení a je uvedená na začátku tohoto oddílu.
Dvě věci k měkkému smazání, které je lepší vědět předem. Smazaný kontakt znovu neoživí synchronizace z e-shopu — ta ho záměrně přeskakuje, aby nevracela rozhodnutí obsluhy. Smazanou adresu ale může vrátit nový import souboru: kontrola duplicit smazané záznamy nevidí, takže vznikne nový kontakt. Před tím chrání jedině seznam blokovaných adres, tedy odhlášení z odběru.
Poznámka k výmazu a seznamu blokovaných adres: pokud se necháte odhlásit, zůstane na seznamu blokovaných adres klíčovaný otisk vaší adresy a její maskovaná podoba. Je to právě to, co brání tomu, aby vás příští import vrátil zpět mezi příjemce. Otisk sám adresu neprozradí — bez klíče z něj adresu zjistit nelze.
Doložitelnost souhlasů. U každého souhlasu je vidět kanál, typ, zdroj, datum udělení a odvolání, případná IP adresa a textový doklad. Odvolání jen doplní stav a datum odvolání, ostatní údaje záznamu zůstávají.
Stížnost: Úřad pro ochranu osobních údajů, Pplk. Sochora 27, 170 00 Praha 7, www.uoou.gov.cz.
12. Automatizované rozhodování
Systém nevytváří profily příjemců a nevyhodnocuje je automatizovaně způsobem, který by pro ně měl právní následky. Jediné automatické rozhodnutí, které dělá, je kontrola, zda adresa není na seznamu blokovaných adres — a jeho výsledkem je pouze to, že se na ni nic neodešle.
13. Údaje z účtu Google
Tento oddíl popisuje, co systém dělá s přihlášením účtem Google. Google vyžaduje, aby zásady odpovídaly skutečnému použití, a proto je tady rozepsaný zvlášť.
Ke dni účinnosti těchto zásad není přihlášení ke Googlu v systému provedené a kanál firemního profilu je vypnutý. Oddíl popisuje, co se stane, až ho obsluha zapne a přihlášení provede.
Koho se to týká. Přihlášení účtem Google se netýká příjemců rozesílky ani návštěvníků webu. Používá ho výhradně obsluha administrace, a to k jedinému účelu: aby systém mohl zveřejňovat letáky na firemní profil Google samotného provozovatele.
Do administrace se účtem Google přihlásit nelze. K tomu slouží vlastní účty v systému (jméno a heslo, volitelně druhý faktor). Přihlášení Googlem není přihlášení do aplikace, je to udělení oprávnění ke správě firemního profilu.
Jaké oprávnění žádáme. Jediné: https://www.googleapis.com/auth/business.manage — správa firemního profilu. Nic jiného. Nežádáme přístup ke jménu, e-mailové adrese ani fotce profilu, nežádáme Gmail, Disk, Kontakty ani Kalendář.
Co si z účtu Google ukládáme. Z odpovědi Googlu si bereme jen obnovovací token a údaj o platnosti tokenů; udělený rozsah oprávnění jen zkontrolujeme a neukládáme ho. Jméno, e-mailovou adresu ani identifikátor uživatele Google nečteme a neukládáme — žádný osobní údaj přihlášené osoby se neukládá.
V databázi systému tedy po přihlášení leží: obnovovací token (zašifrovaný), tajemství aplikace (zašifrované), client id, datum a čas udělení souhlasu, případný čas propadnutí tokenu, identifikátor účtu a provozovny a název provozovny (jen pro zobrazení v administraci).
Autorizační kód, který se z Googlu vrací v adrese, se do cookie ani do databáze neukládá: drží se nejvýš pět minut v paměti serveru, svázaný s přihlášeným uživatelem, a po výměně za token zmizí.
Kde to leží a jak dlouho. V databázi systému na serverech uvedených v oddílu 6, a to tak dlouho, dokud obsluha přihlášení nesmaže nebo nepřihlásí systém znovu. Žádná retenční lhůta se na tyhle hodnoty nevztahuje, protože je to nastavení, ne provozní záznam.
Jak s tím zacházíme. Tokeny se nikdy nevracejí do administrace ani do logu — obrazovka nastavení zobrazuje jen to, zda je token vyplněný. Přístupový token se do databáze neukládá vůbec, drží se jen v paměti procesu do vypršení a je svázaný s otiskem přihlašovacích údajů, takže výměna tajemství nebo tokenu ho okamžitě zneplatní. Adresa souhlasné obrazovky i adresa pro výměnu tokenu se čtou výhradně z konfigurace nasazení a nikdy z administrace, aby se výměna tajemství nedala odklonit na cizí server. Přihlašovací tok používá PKCE (metoda S256); vypnout ho jde jen v konfiguraci nasazení, z administrace ne.
Co Googlu posíláme. Text příspěvku, veřejnou adresu obrázku letáku (Google si obrázek stáhne sám, bajty neposíláme), adresu tlačítka, typ příspěvku a jazyk. Žádné údaje kontaktů, žádné adresy příjemců, žádnou statistiku rozesílky.
Omezené použití. Údaje získané přes rozhraní Googlu používáme výhradně k tomu, aby systém mohl zveřejňovat příspěvky na firemní profil provozovatele. Nepoužíváme je k trénování žádných modelů umělé inteligence ani strojového učení, nepředáváme je třetím stranám, neprodáváme je a nepoužíváme je k reklamě ani k profilování. Lidé k nim mají přístup jen tam, kde to systém pro tuto funkci potřebuje, nebo když to vyžaduje právní předpis.
Jak přístup odvoláte. Dvěma způsoby:
- V administraci lze uložený token smazat — s ním se maže i čas souhlasu a čas propadnutí. Systém pak nemá čím se ke Googlu přihlásit a na profil nic nepošle. Buďme přesní: je to zapomenutí přihlášení na naší straně, ne odvolání souhlasu u Googlu — systém Googlu žádný příkaz k odvolání neposílá. Identifikátor účtu a provozovny i název provozovny v nastavení zůstávají, aby se dalo přihlásit znovu. (Prázdná hodnota při běžném ukládání nastavení se za pokyn ke smazání nebere, aby se přihlášení nedalo zrušit omylem.)
- Přímo v účtu Google na adrese myaccount.google.com/permissions — tam se udělené oprávnění opravdu odebere. Systém pak dostane od Googlu odmítnutí a přihlášení musí obsluha provést znovu.
Poznámka k současnému stavu. Dokud Google aplikaci neschválí, je v režimu testování a udělené oprávnění platí jen 7 dní; systém si proto ukládá čas souhlasu, aby obsluha poznala, že se přihlášení blíží ke konci. Zveřejňování je navíc ve výchozím nastavení „nanečisto“ — dokud Google neschválí kvótu, nejde na Google nic.
14. Změny těchto zásad
Zásady můžeme změnit, když se změní systém nebo způsob jeho použití. Platí vždy verze zveřejněná na této stránce; datum účinnosti a verze jsou uvedené v záhlaví. Text je veřejně dostupný bez přihlášení.