Windows 10 EULA - som zhrozeny

[ByCzech]

Pokud je implementátor toho šifrování levej, tak určitě. Ono se to dá udělat tak, aby to hlavně nebylo závislé na FS a dá to se udělat tak, aby se nemuselo hrabat do specifikace a taky se to dá udělat tak, aby i když se drbu levou rukou za pravým uchem (=měním pod rukama specifikaci bez změny verze) neničil stávající data. Ale to by očividně museli v MS lépe programovat. Jeden z příkladů, proč jsou tak často Windows fail.

To mě zajímá. Jak uděláte transparentní šifrování na FS bez toho abyste měnil on-disk structures? Navíc FAT32 má pro podobné účely rezervované bity a popsané jejich chování, takže ve zvolené implementaci nevidím problém.

Aha, už to chápu. Vy prostě jen nejste dostatečným partnerem nám v diskuzi, protože si to neumíte ani představit, natož to navrhnout. Chápu, typický zaměstnanec MS.
Vzhledem k tomu není třeba vám vysvětlovat možnosti řešení, právě jste předvedl, že na tenhle level nemáte.

[Reklama]

[ByCzech]

Stačí na to poštvat implementaci fsck, která dodržuje specifikaci. A protože ve specifikaci se říká, že bity by měly být 0 (alespoň v té vydané, jinou nikdo nikdy neviděl), tak když je najde ve stavu 1, tak je vynuluje. To bude legrace, až se takové zařízení vrátí do Windows 10 a tam budou šifrované soubory rázem nečitelné, protože nemají ty bity v 1.

Kecáte, znovu cut-paste ze specifikace: "Reserved for use by Windows NT. Set value to 0 when a file is created and never modify or look at it after that." Z čeho usuzujete, že by tyhle bity měla "implementace fsck, která dodržuje specifikaci" vynulovat?

Proč? Právě jste si sám odpověděl. Zajděte si na ten kurz angličtiny a až to budete moci správně přeložit, zbude ještě správně překlad pochopit a pak vám to třeba dojde.

[ByCzech]

To by me ty imbecile zajimalo, co asi tak vsechny tyhle veci budou delat se souborem, kterej ma ten bit nastavenej widlema. Nj, POSEROU SE. Protoze je jim predlozeny cosi, co nesplnuje specifikaci.

Jeronýmku, vy ignorante, staré implementace FAT32 samozřejmě soubor nedešifrují a přečtou ho v RAW mode (tj. uvidí data v šifrovaném stavu).

To je právě ten problém, při překopírování budou atributy pryč a při návratu takové kopie do W10 bude problém. Proč máme opakovat to co už jsme napsali? Možná by jste měl přečíst všechny příspěvky, než začnete zase kravsky reagovat a třeba by vám důležité neušlo (i když u vás je větší pravděpodobnost, že to ignorujete naschvál, protože se vám to nehodí do krámu).

PS: Už teď je mi jasné, že buď tento příspěvek budete rovněž ignorovat a když ne, tak budete argumentovat nejspíše ve stylu, že uživatel nemá co kopírovat a že když to udělá, je blbej.
Já jsem tak rád, že jsem uživatelem svobodného OS a můžu si dělat co chci a ne co mi MS nakáže a dovolí

[ByCzech]

Hlavičky souborů jsou v principu nespolehlivé. To že má soubor na nějakém offsetu pár konkrétních bytů nijak jednoznačně neurčuje jeho typ. To že soubor začíná "Return-Path:" z něj nedělá EML, to že začáná na "SQLite format 3." z něj nedělá SQLite DB file. A například v nešifrovaném souboru .bin můžu mít z mnoha důvodů klidně uložený šifrovaný JPEG ve formátu EFS. Pokud budete používat hlavičky, automaticky ho dešifrujete, a bude to zcela špatně. Podobně můžu mít těch pár bytů, podle kterých byste chtěl rozeznat šifrovaný soubor, náhodou například ve video streamu nebo JPEGu.

To by mne zajimalo, jak to dela utilita file v Linuxu, ze podle hlavicek funguje spise spolehlive, urcite spolehliveji, nez to, co tvrdi Windoze Explorer.

Musíte pochopit, že když to MS neumí, tak to Lael nemůže přiznat. On musí napsat, že to nejde, je to nespolehlivé ap. Přece nečekáte, že on by řekl, že v MS nejsou schopní naimplementovat něco co jinde máme mraky let. Však jak dlouho jim trvala implementace virtuálních ploch? A jak ta jejich implementace vypadá?

[ByCzech]

Za takovou implementaci šifrování rádi opravdu nebudou, protože jak vidno, tak to není kompatibilní není.

Implementace šifrování na FAT32 je kompatibilní se všemi předchozími implementacemi FAT32, které se drží MS specifikací podle kterých měly být napsané. Jediný problém je u Sound Devices, a to díky tomu že se specifikace nedrželi.

Dostal jste 2 příklady, kdy to tak není. Dále díky tomu MS mrví uživatelům data. To už je dost důvodů pro popření vašeho nesmyslného tvrzení o kompatibilitě a také o kvalitě MS implementace.

PS: Lael prohlásil tmu za standard a proto se mu nerozsvítí a nerozsvítí

PS: Ale MS jde o to, aby dožduchali všechny uživatele starší verze Windows do desítek a tohle je jeden z háčků. A až bude hromada věcí v cloudu (jakože s Windows 10 to posunuli o několik levelů výš), tak se budou uživatelé (čti ovečky) ovládat zase o něco snadněji. 

Cloud přináší výhody. Například můžete mít ta samá data přístupná z desktopu, notebooku i telefonu. Samozřejmě k tomu ta data musíte uložit na nějaký server, a to obnáší rizika v oblasti bezpečnosti a ochrany soukromí. Pokud vám taková rizika nestojí za přidanou hodnotu (mě rozhodně nestojí), tak data do cloudu neukládejte.

Microsoftu výhody přináší určitě. Ale nevím proč bych já za to měl jako uživatel platit takovou cenu. Výhody MS cloudu nevýhody z toho plynoucí uživatelům nepřeváží. Dává to příliš moci MS nad uživateli a ještě je nechá, aby si to zaplatili v podobě nákupu W10

[Reklama]

[Lael.Ophir]

Aha, už to chápu. Vy prostě jen nejste dostatečným partnerem nám v diskuzi, protože si to neumíte ani představit, natož to navrhnout. Chápu, typický zaměstnanec MS.
Vzhledem k tomu není třeba vám vysvětlovat možnosti řešení, právě jste předvedl, že na tenhle level nemáte.

Ono neexistuje moc možností, jak to udělat dobře. Můžete jako Jeronýmek spoléhat na to že na nějakém offsetu souboru bude nějaká signature... a pak žehlit problém, až někdo náhodou bude mít soubory (případně rovnou formát souborů) se stejným obsahem na stejném offsetu. Zřejmě vám nedochází, že detekce šifrování souboru v závislosti na signatuře je v principu nespolehlivá. Jenže co čekat od člověka, který by při fsck "pro jistotu" znuloval rezervované bity

[Lael.Ophir]

Proč? Právě jste si sám odpověděl. Zajděte si na ten kurz angličtiny a až to budete moci správně přeložit, zbude ještě správně překlad pochopit a pak vám to třeba dojde.

Kde tam čtete, že byste měl rezervované bity znulovat? Zřejmě potřebujete kurz angličtiny vy.

[Lael.Ophir]

To je právě ten problém, při překopírování budou atributy pryč a při návratu takové kopie do W10 bude problém. Proč máme opakovat to co už jsme napsali? Možná by jste měl přečíst všechny příspěvky, než začnete zase kravsky reagovat a třeba by vám důležité neušlo (i když u vás je větší pravděpodobnost, že to ignorujete naschvál, protože se vám to nehodí do krámu).

To je celkem pochopitelné omezení dopředné kompatibility. Starý driver FS neumí features, které umí nový.

Já jsem tak rád, že jsem uživatelem svobodného OS a můžu si dělat co chci a ne co mi MS nakáže a dovolí

Jistě. Například si zmršit implementaci nějakého FS, a pak to házet na jeho autory . Ale překvapení: driver FS si můžete napsat i pro Windows.

[Lael.Ophir]

Musíte pochopit, že když to MS neumí, tak to Lael nemůže přiznat. On musí napsat, že to nejde, je to nespolehlivé ap. Přece nečekáte, že on by řekl, že v MS nejsou schopní naimplementovat něco co jinde máme mraky let. Však jak dlouho jim trvala implementace virtuálních ploch? A jak ta jejich implementace vypadá?

Jak už jsem psal, detekce podle obsahu souboru je v principu nespolehlivá. Pokud se orientujete podle flagu v directory entry, je výsledek jasně daný při zápisu souboru, a nemůže dojít k omylu. Naopak to že soubor obsahu nějakou sekvenci na určitém offsetu je věc která může mít řadu příčin: náhodou tak vyjde pár bytů JPEGu nebo video streamu, případně někdo zítra uvede formát souboru který má vždy stejný obsah na stejném offsetu. Příkladem může být třeba to že snadno zaměníte formáty ZIP, JAR, KMZ, KWD, ODT, ODP, OTT, SXC, SXD, SXI, SXW, SXC, WMZ, XPI, XPS a XPT.

[Lael.Ophir]

Dostal jste 2 příklady, kdy to tak není. Dále díky tomu MS mrví uživatelům data. To už je dost důvodů pro popření vašeho nesmyslného tvrzení o kompatibilitě a také o kvalitě MS implementace.

Zatím jsem si všiml jen omezení dopředné kompatibility, které je naprosto pochopitelné: staré verze FS neumí features uvedené v nové verzi FS. To že Windows 10 mrší uživatelům data je dané jen a pouze tím, že v Sound Devices nedodrželi specifikaci FAT32. Dostal jste dva příklady jak je možné při nedodržení specifikace zbourat jiné FS jen jejich přimountováním nebo vylistováním obsahu adresářů. Závěr: specifikace je potřeba dodržovat.

Microsoftu výhody přináší určitě. Ale nevím proč bych já za to měl jako uživatel platit takovou cenu. Výhody MS cloudu nevýhody z toho plynoucí uživatelům nepřeváží. Dává to příliš moci MS nad uživateli a ještě je nechá, aby si to zaplatili v podobě nákupu W10

To jestli přínosy převáží rizika je na posouzení každého uživatele. Jak můžete vidět například u Androidu, iOS a Google Chrome, uživatelům často nevadí cpát data do cloudu, a uvítají možnosti které jim to dává. My dva to máme jinak, a data do cloudu necpeme. Na rozdíl od vás ale nemám potřebu to rozhodovat za ostatní.

[MD]

Provedl jsem následující experiment:
1) ve Windows 10 jsem naformátoval flashku FAT32 (4 GB),
2) nakopíroval na ni soubor (log, cca 280 KB),
3) zašifroval,
4) odpojil flashku a připojil na Windows 8.1 (plně aktualizovaný).

Název souboru je obohacen sufixem .PFILE a obsah souboru je samozřejmě nečitelný (zdá se, že se tam objevila nějaká hlavička). Velikost souboru je cca o 4 KB větší.

5) vytvořil jsem adresář na flashce a zkopíroval do něj ten šifrovaný soubor,
6) prohlédl na Windows 10.

Původní soubor je bez problémů čitelný (samozřejmě za předpokladu, že uživatel disponuje příslušným klíčem). Je ale vidět, že FAT32 driver (fastfat.sys) ve Windows 8.1 dodržuje starší verzi specifikace (EFS bit je považován za reserved), takže při vytváření nového souboru nuluje reserved bity v jeho directoory entry. Tudíž zkopírovaný soubor dešifrovat nelze, neb není označen jako šifrovaný (nevím, zda by pomohlo, kdyby tak byl označen např. přímým přístupem na "disk").

Takže tak.

ByCzech:
Co se týče toho ničení dat, můžete se mrknout do zdrojových kódů ovladače fastfat, je součástí balíku Windows Driver Kit. Sice tam nebude nejaktuálnější verze, ale nemyslím, že by zapisování do struktur FS při čtení byla nějaká novinka. Samozřejmě to může být i tak, že dané zápisy provádí nějaký FS filter/minifilter nad instancní daného FS.

[JardaP .]

Cloud přináší výhody. Například můžete mít ta samá data přístupná z desktopu, notebooku i telefonu. Samozřejmě k tomu ta data musíte uložit na nějaký server, a to obnáší rizika v oblasti bezpečnosti a ochrany soukromí. Pokud vám taková rizika nestojí za přidanou hodnotu (mě rozhodně nestojí), tak data do cloudu neukládejte.

Tak on MS mohl udelat neco proto, aby se clovek mene obaval data do kloudu napchat. Data tam mohla jit sifrovana, clovek by si v nejakem onfiguratoru naklikal, ktera se budou sifrovat. Na vsechna zarizeni by si naimportoval klice a bylo by. Sice to neni bombenfest, protoze by se nasli lide, kteri by rekli, ze MS muze krast klice a posilat je do NSA. Ale byla by to aspon jakasi snaha, relativne duveryhodna.

Ono neexistuje moc možností, jak to udělat dobře. Můžete jako Jeronýmek spoléhat na to že na nějakém offsetu souboru bude nějaká signature... a pak žehlit problém, až někdo náhodou bude mít soubory (případně rovnou formát souborů) se stejným obsahem na stejném offsetu. Zřejmě vám nedochází, že detekce šifrování souboru v závislosti na signatuře je v principu nespolehlivá. Jenže co čekat od člověka, který by při fsck "pro jistotu" znuloval rezervované bity

Tak jo, predpokladejme, ze dam na disk binarni data, kde zrovna nahodou na zacatku bude kombinace, ktera odpovida hlavicce MS sifrovaneho souboru. No, vzhledem k tomu, ze dneska par bajtu nikdo neresi, co brani MS, aby si za tu hlavicku ulozil napriklad nejakou dalsi znacku (overeni hlavicky), podle ktereho by vznikla temer jistota, ze dat jsou bud binarni bordel nebo sifrovany soubor? Diskety uz nikdo nepouziva, tak treba deset nabo i dvacet bajtu nikoho nezabije. Jaka je pravdepodobnost, ze vytvorim binarni blob, kde treba 20 bajtu bude stejnych? Krome toho v takovem souboru muze byt treba kontrolni soucet nebo se treba pozna, ze to nejde rozsifrovat. A i kdyby, tak pokud MS do toho nebude zasahovat, nic se nestane. Pokud uzivatel neni zretelne blby, tak si vsimne, ze se soubor rozsifroval jako binarni bordel a vzpomene si, ze to neni sifrovany soubor.

Soucasna nova implementace je jaksi znacne suboptimalni. Jak uz bylo vyse poukazano, sifrovane soubory z Widli 10 asi nepreziji kopirovani na jine medium najinem OS, nez W 10. Uzivatel obdrzi medium s binarnim svincikem a bez diskeditoru se k tem datum uz nikdy nedostane. Predstavte si, jak si treba stara Blazkova koupi novou flashku. Tu da spolu se starou vnukovi, at ji prekopiruje data a starou flashku si necha. Vnuk data presype na Macu a puvodni flasku vymaze a prevalcuje pornem. Stara Blazkova pak zjisti, ze nemuze otevrit sifrovane soubory s recepty na babovku a moravske zeli. Nasledne si nasadi brejle, spusti diskeditor a jde to opravovat.

Jak už jsem psal, detekce podle obsahu souboru je v principu nespolehlivá. Pokud se orientujete podle flagu v directory entry, je výsledek jasně daný při zápisu souboru, a nemůže dojít k omylu.

K omylu dojit muze. Potiz je, ze FAT na nejake sifrovani nebyl od pocatku zalozeny a tak k tomu omylu pri trose stesti nemuze dojit pouze tehdy, kdyz vsichni pouzivaji Widle 10. Tak daleko nejsme a jeste nejakou dobu nebudeme. Tady by byvalo vhodnejsi, kdyby si MS prestal hrat na zpetnou kompatibilitu a prisel s novym FATem, ktery neni zpetne kompatibilni. Pro starsi podporovane Widle pak mohl vydat zaplatu, ktera by do nich podporu FATu s sifrovanim dotlacila. Pri trose slusnosti by vytvorili i zaplatu pro XP, protoze do prechodu na kachliky se lidem moc nechce. Pri formatovani na novy FAT by pak user mohl byt upozornen, ze tim ziska sifrovani, ale prijde o moznost cteni sifrovanych souboru na starych Widlich a eventuelne jinych OS. O tuto moznost strjne prichazi a jeste vznika nebezpeci ztraty dat diky nepodpore sifrovani jinde, nez na W 10, kdy clovek pak uz nic neprecte ani na nich.

[ByCzech]

Proč? Právě jste si sám odpověděl. Zajděte si na ten kurz angličtiny a až to budete moci správně přeložit, zbude ještě správně překlad pochopit a pak vám to třeba dojde.

Kde tam čtete, že byste měl rezervované bity znulovat? Zřejmě potřebujete kurz angličtiny vy.

LOL. Lael se opět proflákl. Nejdříve tvrdí, že když jsou bity v jedničce, je to špatně. A teď tvrdí, že by to fsck neměl opravovat ne nuly, když je jednička špatně .

[ByCzech]

To je právě ten problém, při překopírování budou atributy pryč a při návratu takové kopie do W10 bude problém. Proč máme opakovat to co už jsme napsali? Možná by jste měl přečíst všechny příspěvky, než začnete zase kravsky reagovat a třeba by vám důležité neušlo (i když u vás je větší pravděpodobnost, že to ignorujete naschvál, protože se vám to nehodí do krámu).

To je celkem pochopitelné omezení dopředné kompatibility. Starý driver FS neumí features, které umí nový.

Ale vy se tu pořád oháníte i zpětnou kompatibilitou. Očividně není zajištěna ani jedna . Že často popíráte i sám sebe je legrační.

Já jsem tak rád, že jsem uživatelem svobodného OS a můžu si dělat co chci a ne co mi MS nakáže a dovolí

Jistě. Například si zmršit implementaci nějakého FS, a pak to házet na jeho autory . Ale překvapení: driver FS si můžete napsat i pro Windows.

Cože? To je reakce na quote? Nějak mi to nedává smysl. Ale na to už jsem vás zvyklý. Já si nic nezmršil a vše mi funguje a data mi nikdo neničí, protože nemám Windows jakékoli verze .

[ByCzech]

Provedl jsem následující experiment:
1) ve Windows 10 jsem naformátoval flashku FAT32 (4 GB),
2) nakopíroval na ni soubor (log, cca 280 KB),
3) zašifroval,
4) odpojil flashku a připojil na Windows 8.1 (plně aktualizovaný).

Název souboru je obohacen sufixem .PFILE a obsah souboru je samozřejmě nečitelný (zdá se, že se tam objevila nějaká hlavička). Velikost souboru je cca o 4 KB větší.

5) vytvořil jsem adresář na flashce a zkopíroval do něj ten šifrovaný soubor,
6) prohlédl na Windows 10.

Původní soubor je bez problémů čitelný (samozřejmě za předpokladu, že uživatel disponuje příslušným klíčem). Je ale vidět, že FAT32 driver (fastfat.sys) ve Windows 8.1 dodržuje starší verzi specifikace (EFS bit je považován za reserved), takže při vytváření nového souboru nuluje reserved bity v jeho directoory entry. Tudíž zkopírovaný soubor dešifrovat nelze, neb není označen jako šifrovaný (nevím, zda by pomohlo, kdyby tak byl označen např. přímým přístupem na "disk").

Takže tak.

To jsme ale říkali. Děkuji za potvrzení, že implemetace šifrování je špatná i z tohoto pohledu.

ByCzech:
Co se týče toho ničení dat, můžete se mrknout do zdrojových kódů ovladače fastfat, je součástí balíku Windows Driver Kit. Sice tam nebude nejaktuálnější verze, ale nemyslím, že by zapisování do struktur FS při čtení byla nějaká novinka. Samozřejmě to může být i tak, že dané zápisy provádí nějaký FS filter/minifilter nad instancní daného FS.

Nedělejte ze mě hlupáka. Zapisování FS struktur (metadat) je něco jiného než hrabání se do vnitřku souboru uživatele (data), přestože ten soubor není otevřen pro zápis, ani není jakýkoli zápis do něj požadován.