Certifikát je platný pouze pro následující domény: 1xbet.com, www.1xbet.com, xbetsport.com, www.1x-bet.com, xbetsports.com, www.xbetsports.com, sport1xbet.com, kassabet.biz, 1-x-bet.com, 1x-bet.com, www.sport1xbet.com, www.1-x-bet.com, www.1-xbet.com, 1-xbet.com, www.xbetsport.com
Zítra bude asi dalších pár domén v nařízení
Podpis už prý sedí, viz https://www.root.cz/zpravicky/ministerstvo-financi-naridilo-blokaci-prvniho-hazardniho-webu/930767/ - nezkoušel jsem. Ověřoval to ještě někdo?
Ta adresa sa da z pdf vybrat asi aj teraz. Neskusal som to, ale ked ide oznacit text a urobit copy paste tak pojde aj nacitatat text cez nieco ako iTextSharp (neviem ci je pod linux asi nie). Potom treba urobit nepriestrelny algoritmus podla ktoreho najde adresy v tabulke. Kopec roboty ale malo by to ist :-)
@strepty: Tak pdftotext umím pustit taky. Akorát to má tu vadu, že pak v tom textu je např. další doména "mfcr.cz" :-) (v emailové adrese), takže kdybych z toho chtěl vytahovat domény, tak první bude zablokovaný i ten web s tímhle seznamem :D.
A myslím si, že každý ajták tohle za normálně strojově zpracovatelné nepovažuje, nemá to strukturu. Přijde jiný ouřada a hnedle další PDFko bude vypadat úplně jinak, včetně toho, co se pak převede na text.
Ta doména mfcr.cz není problém, prostě se explicitně vyřadí, např. takto:
pdftotext seznam-domen.pdf - | grep -E "[0-9A-Za-z]+\.(com|cz|net|sk|co\.uk|org)" | grep --invert-match "mfcr.cz"
Tato pipeline v současné verzi pdf souboru dá správný výstup
1xbet.com
Ale strukturu to fakt asi nemá, myslím že nebude mít žádný smysl psát na to nějaký skript (leda snad něco, co upozorní na novou verzi souboru) a bude se to dělat ručně.
Tato pipeline v současné verzi pdf souboru dá správný výstup
To je právě ten problém. Není dána struktura, takže co verze, to nový skript. To už je jednodušší to (zatím) sázet ručně.
Další problém nastane, až se v tom dokumentu budou také ty domény invalidovat (viz sloupec "Výmaz zveřejněných údajů"). Pak bude skript dost těžko domýšlet, jestli doména co vytáhl je k zablokování nebo k odblokování.
A to ne nebavím o tom, že v tom vašem "filtru" neprojde hromada jiných domén a navíc si udržujete ruční whitelist, který se třeba bude taky zvětšovat.
Tohle prostě nejsou strojově zpracovatelná data pro daný úkol.
Hledat v tom domény regulárním výrazem je nepoužitelné. Nejen, že můžete vytáhnout něco, co doména určená k blokaci není, ale klidně můžete minout doménu, která určená k blokaci je. Ono totiž to, co vidíte jako „1xbet.com“, může být klidně v PDF zapsané tak, že z toho po exportu do textového formátu vyjde:
t .com 1 x b e
A do toho klidně mohou být zamíchané znaky z jiných textů v dokumentu.
Obecné PDF prostě není strojově zpracovatelný formát. Aby byl ten seznam strojově zpracovatelný, musel by mít nějakou předem danou strukturu – a to dnes neplatí. Dalo by se to udělat i pomocí toho PDF, ale existují na to samozřejmě mnohem vhodnější formáty – ideální by bylo XML, kde by byla data jasně strukturovaná a pořád by to mohlo být elektronicky podepsané. A to XML se dá i vložit do PDF jako příloha, kdyby na to přišlo.
Obecné PDF prostě není strojově zpracovatelný formát.
Při kvalitě státní zprávy předpokládám, že úředník sousloví "strojově zpracovatelný formát" chápe tak, že jej stroj umí zpracovat. A vždyť PDF stroj zpracovat umí... Umí ho např. zobrazit a umí ho vytisknout. Schválně jaká je pravděpodobnost, že nejsem daleko od pravdy.
Každopádně souhlasím, že vyzobávat z toho domény pomocí regexp výrazů je kravina. To už mi přijde lepší při převodu na text pomocí pdftotext si pomoct parametry -layout -nopgbrk, pak je nemalá pravděpodobnost, že se řádky s požadovanými údaji budou dát vyzobat za sebou a nakonec z toho bude de-facto CSV oddělený (white)space znaky. Pořád to je ale pruda a bez záruky, nikdo při takovém podkladu nezaručí, že se to při další verzi dokumentu nerozpadne. Obzvlášť když ouřadové ani netuší, že když je dokument jednou elektronicky podepsaný, že rýpat do něj znamená narušení validity dokumentu, bylo by hloupé předpokládat, že by ho stejní patlalové byli schopni udržet ve stavu, kdy by byl vždy takový dokument konzistentní pro takové pokusy o převod do strukturovaných dat.
No me se libi, ze hned nahore na strance maji instrukce, jak blokaci obejit. Napr nabizi jejich sazeci aplikaci pro PC, iOS a Android, kanal na Telegramu, VPNky. Predpokladam, ze tvurce zakona nic netusi o internetovych protokolech, takze efektivne (ehm, ehm) blokuje jen www stranky. To blokovani je tak bezzube, az hloupe.
Tak po technické stránce středověky papírování, po byrokratické elektronický dokument digitálně zabezpečen podpisem. Jeden mlýn zapálili, nebo to je nová verze vládně-firemního marketingu, přece tyto domény mají od ministerstva reklamu, být tím samozvaným Rašínem, tak jim pošlu fakturu
Podařilo se někomu z vás validovat ten elektronický podpis v tom PDF? Já to už zkoušel na Windows 7, Ubuntu i Debianu, i jsem zkoušel nějaký online verifier (https://www.securedsigning.com/), ale zatím bez úspěchu. Mám pocit, že s tím podpisem něco není v pořádku, protože ty hlášky které při ověřování vidím mi přijdou neobvyklé.
Utilitou 'strings' jsem našel např. toto:
<</Author(Boka Richard Mgr.)/Company(Ministerstvo financ\355)/CreationDate(D:20170726101530+02'00')/Creator(Aspose Ltd.)/ModDate(D:20170726110554+02'00') (...)
Myslíte, že by mohlo jít o to, že PDF bylo podepsáno a o chvíli později pozměněno, ale jeho autor zapomněl dokument znovu podepsat? Něco v tom smyslu mi tuším ukazoval Adobe Reader na Windows 7...
Strojově špatně zpracovatelné PDF se špatným elektronickým podpisem. To se hoši z MFČR zase vyznamenali.
Vzhledem k tomu, že není možné ověřit pravost takového dokumentu (nemají HTTPS a podpis na PDF je rozbitý) doporučuji požadavek k blokaci ignorovat. Co kdyby vám někdo podstrčil fake seznam a vy zablokovali nesprávnou doménu.
Přesně toto mě napadlo také, protože ten elektronický podpis podle všeho není v pořádku - zkoušel jsem to taky. Co si vybavuji, tak příslušný zákon na možnost podvrženého seznamu blokovaných adres nijak nepamatuje. Jen do toho soudruzi, odněkud se ty náměty pro sitcomy brát musí.
Vzhledem k nevalidnimu podpisu na seznamu stranek k blokaci doporucuju web neblokovat. Je vysoce pravdepodobne ze dokument je podvrh (napriklad od jine - konkurencni sazkove kancelare), takze pri zablokovani hrozi riziko ze by si provozovatel webu mohl stezovat ze je blokovan poskytovateli neopravnene... :D :D :D
Ten seznam už se od první publikace nejméně jednou v tichosti změnil. Tohle je SHA256 verze stažená brzy po zveřejnění:
c44ff24b5148803d223d2d9495863993c0cfe0f37775583f2ff953e0427e528b Zverejnovane-udaje-ze-Seznamu-nepovolenych-internetovych-her_v1.pdf
Tohle je verze stažená nyní:
9fe23564be305ac7012690fbcf92b4a989459cb4fb2df12fb3d47db4314ba037 Zverejnovane-udaje-ze-Seznamu-nepovolenych-internetovych-her_v1.pdf
Ani nevím, které z těch vysvětlení mě víc znepokojuje.
Tak tady máš do sbírky: https://jenda.hrach.eu/minifin/ :-) Renderují se stejně, ale binárně jsou úplně jiné.
Ono to vypada vice-mene jasne. Klicem je, ze ve vsech tehle variantach nalezneme kvalifikovany timestamp se seriovym cislem 00AB2010. To znamena, ze pozorovana odlisna varianta nevznikla novym podepisovanim dokumentu.
Zakladem je patrne ten soucasne zverejneny dokument s hashem 9fe2...037. Ten je podepsan platnym podpisem (a je konformni s PDF/A-2b specifikaci).
Po podepsani ale dokument nekdo znovu otevrel a upravoval. Tyto modifikace zneplatnily podpis (a take poskodili format dokumentu tak, ze prestal byt PDF/A). Proc a kdo to oteviral muzeme jen hadat - ale vsimnul jsme si, ze z editovaneho dokumentu zmizela custom i XMP metadata. Editace tedy nejspis mela za cil tato metadata odstranit (obsahuji jmeno autora a nektere dalsi interni informace), jenze ten, kdo to delal si neuvedomil, ze na podepsany dokumentu bude mit takovy zasah fatalni dopad.
No, uz samotny par. 82 i metodicky pokyn k nemu vydany jasne ukazuje, ze MFCR sice ma silu protlacovat zakony, ale nema odbodniky, kteri by rozumeli problematice digitalnich dat a komunikaci. Takze to, ze nechapou zasady prace s digitalne podepsanymi dokumenty neni vlastne nijak prekvapivy.
Dlouho jsem se divil, jak to, že to muj provider neblokuje, až pak jsem si ale uvědomil, že používám Unbound na localhostu kvůli DNSSEC (přece nebudu věřit DNS serverům, které nemám pod kontrolou), což elegantně naši místní cenzuru obchází.
Když jsem se pak dotázal resolveru providera, dostal jsem 127.0.0.1 jako odpověď. Takže jim to fakt funguje.
Hm, někteří to dělají až moc poctivě. Dropují i pakety s dotazy na externí DNS, pokud je v nich 1xbet.com, co jsem si zkoušel pár ISP (takže neunášejí DNS, ale real time filtrují a dropují DNS dotazy, takže i ten, kdo má vlastní rekurzor, tak má smolík, pokud dotazy ven nejde přes TLS), ale větina ISP zatím spí a ignoruje. :-)
Asi nastává čas pro větší popularitu řešení DNS over TLS (RFC 7858) / DNScrypt a podobné...
Řekl bych, že je to dost nejisté. Plní to přesně požadovaný účel a např takto to dělají i někteří ISP v Rakousku (kde je taktéž blokace na úrovni DNS zahraničních sázkovek). Takže to by musel rozhodnout soud a u našich si spíše myslím, že to vezmou jako košer řešení problematiky... ISP bude arguemntovat, že vůbec neprovozuji DNS resolvery pro své zákazníky, takže zákazníkům nastavují kde co je právě npadne (Googla, CZ.NIC atd), takže filtrují procházející dotazy a dropuji ty závadné (a budou mávat tím MF pamfletem, který požaduje funkční filtraci i v případě, že ISP nemá vlastní resolvery a využívá resolvery třetích stran).
To by bylo rovnou i žalovatelné, že řada ISP (včetně O2) blokuje příchozí DNS dotazy na koncové linky klientů, takže nemůžu doma provozovat autoritativní DNS server a nehodlají se s tebou bavit.
1. Dej bacha na termin koser. Ten se v tomto kontextu vubec nepouziva. Urazi to moji viru. To je take napadnutelne:)))
2. V nasich podminkach to primarne jde na CTU. CTU a MFCR jsou jine subjekty s jinymi zajmy. Minimalne rypnout do hnizda jako neopravneny zasach do telekomunikacniho provozu.
3. Ano je zalovatelne ze blokuji prichozi DNS dotazy na linky klientu. Pokud takovou blokaci na pozadavek neodstani, tak je to na setreni CTU s pripadnou soudni dohrou. To ze se nikomu nevyplati ted momentalne do toho jit, neznamena ze to nejde.
Škoda že je to dělané spíš jako trolling (soudě podle Valid PDF signature, Valid source SSL, Trustful) a místo logování nesmyslů (a ještě nesmyslně pomocí celery) https://github.com/Salamek/blacklist/blob/16000f3ad65b5eab0cda8cdef674a5ac91538be8/controllers/Api.py#L72 by bylo užitečnější přidat task kterej by kontroloval jestli jsou nějaké změny, resp nové to jejich slavné PDF... Takhle je to na dvě věci, pro nějaké serioznější použití.
Ano, to jako VAZNE
MD5 tam neni pouzito na hesla nebo na cokoliv security related, ale pouze jako UUID souboru vcetne nazvu na FS... jakykoliv modernejsi sum na toto pouziti je zbytecny overkill
Sance kolize je stale minimalni
Pokud nekdo trpi nejakou cryptography uchylkou, muze si dane PDF stahnout a prohnat si jej cim se mu zachce
Samozrejme kdyz se nekdo bude snazit tak muze vyprodukovat PDF se stejnym MD5 sumem... ale kdyz se podivas do zdrojaku toho webu tak to neni problem, protoze se nic nestane :-D
pokud se stahne PDF s jiz existujicim MD5 v DB tak se proste ignoruje takze pripadna zamerna kolize nic nerozbije, a zpusobit MD5 kolizi PDF omylem... ehm
MD5 je v dnesni dobe nevhodne prakticky na cokoliv krome tohodle pouziti, clovek proste jen nesmi pri pohledu na 2101adc3aa7a359db51e08af0303e8f0 hned hystercit a uvedomit si k cemu je pouzite a pak pripadne hystercit :-D
Ten md5sum je tam zobrazen protoze se pouziva interne v app, ne pro to aby podle nej nekdo neco overoval...
Nemělo by se Ministerstvo financí zažalovat za maření úředního rozhodnutí? Jelikož způsob publikování onoho rozhodnutí lze chápat jako umyslné obstrukce komplikující uvedení onoho rozhodnutí do praxe. Není snad publikování ve strojově nečitelném, navíc nepodepsané formátu obstrukcí?