Windows 10 EULA - som zhrozeny

MD

Re:Windows 10 EULA - som zhrozeny
« Odpověď #615 kdy: 31. 08. 2015, 21:44:29 »
Citace
Laele - tohle nemá smysl. Je to prostě level pro který nemají pojmový aparát a úroveň abstrakce: škoda, protože ve skutečnosti nejsou hloupí, spíš naopak.

Myslím že už neni co dodat. Třeba jim to jednou dojde až budou mít víc zkušeností a míň testosteronu :-)

Co to nechat prostě být a propadnout za horizont událostí? I s ohledem na důstojnost všech zúčastněných…
Naprostý souhlas. Objektivní diskuze (pokud to, co je tady, lze tak nazvat) zřejmě nemá smysl.


ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #616 kdy: 31. 08. 2015, 21:49:06 »
Laele - tohle nemá smysl. Je to prostě level pro který nemají pojmový aparát a úroveň abstrakce: škoda, protože ve skutečnosti nejsou hloupí, spíš naopak.

Myslím že už neni co dodat. Třeba jim to jednou dojde až budou mít víc zkušeností a míň testosteronu :-)

Co to nechat prostě být a propadnout za horizont událostí? I s ohledem na důstojnost všech zúčastněných…

Jasně, my nemáme pojmový aparát pro zjevné chyby v implementacích, protože to nedokážeme vidět růžově a správně. Takže tady souhlasím. Neumím vidět něco co je už v návrhu špatně, jen proto, že to vytvořila údajně největší SW firma světa.

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #617 kdy: 31. 08. 2015, 21:51:43 »
Citace
Laele - tohle nemá smysl. Je to prostě level pro který nemají pojmový aparát a úroveň abstrakce: škoda, protože ve skutečnosti nejsou hloupí, spíš naopak.

Myslím že už neni co dodat. Třeba jim to jednou dojde až budou mít víc zkušeností a míň testosteronu :-)

Co to nechat prostě být a propadnout za horizont událostí? I s ohledem na důstojnost všech zúčastněných…
Naprostý souhlas. Objektivní diskuze (pokud to, co je tady, lze tak nazvat) zřejmě nemá smysl.

Taky neshledávám nic objektivního na tom, když diskutující jako je Lael a spol. mluví o něčem co vůbec neznají, ale o to víc to shazují :D

JardaP .

  • *****
  • 11 064
    • Zobrazit profil
    • E-mail
Re:Windows 10 EULA - som zhrozeny
« Odpověď #618 kdy: 31. 08. 2015, 22:06:07 »
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.
To ovšem vylučuje používání těch dat z webových aplikací, protože ty by ve vašem scénáři zřejmě ty klíče neměly.

Nerikal jsem, ze si naklikam, co se sifrovat ma a co ne?

Citace
To jestli je soubor například šifrovaný nebo komprimovaný na úrovni FS nemůžete určovat z obsahu souboru, protože tak vytváříte závislost na něčem co není nikde specifikované a nemáte to pod kontrolou. Například soubory šifrované EFS si můžete vydumpovat v RAW módu (tedy v šifrované podobě) a uložit do souboru; samozřejmě pak nechcete aby vám je FS dešifroval. Navíc stejnou hlavičkou souboru může použít kdokoliv náhodně nebo systematicky. Vizte co jsem psal o záměně ZIP, JAR, KMZ, KWD, ODT, ODP, OTT, SXC, SXD, SXI, SXW, SXC, WMZ, XPI, XPS a XPT (a nejspíš řady dalších formátů). Obsah souboru je prostě věc aplikace, může v něm být cokoliv včetně hlavičky EFS, a FS se podle toho nemůže a nesmí orientovat. Rozdělení na data souboru a metadata má velmi dobré důvody.

Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.

Citace
Samozřejmě starší verze FS neumí features novější verze. Tak už to u dopředné kompatibility bývá.

Jiste, nicmene byva zvykem, ze data treba sice neumi precist, ale aspon je nezkurvi. Nyni, kdyz Alois s W 10 prinese flashku Bedrichovi s Widlema 7, aby okopiroval porno pro Cyrila - opet s W 10, tak dojde k tomu, ze si Cyril moc nezaslimta.

Citace
MS by teoreticky mohl vydat patch pro starší verze Windows. Těžko ale vydá patche pro kamery, zvuková záznamová zařízení, MP3 přehrávače, televize, mobily, automobily a hromady dalších zařízení.

No, tak kamery asi nebudou sifrovat, tak je to jedno. A kdyby MS zvolil nejaky normalni zpusob znaceni sifrovanych souboru, problem by nebyl ani se zarizenimi z SD.

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #619 kdy: 31. 08. 2015, 22:13:36 »
Citace
To jestli je soubor například šifrovaný nebo komprimovaný na úrovni FS nemůžete určovat z obsahu souboru, protože tak vytváříte závislost na něčem co není nikde specifikované a nemáte to pod kontrolou. Například soubory šifrované EFS si můžete vydumpovat v RAW módu (tedy v šifrované podobě) a uložit do souboru; samozřejmě pak nechcete aby vám je FS dešifroval. Navíc stejnou hlavičkou souboru může použít kdokoliv náhodně nebo systematicky. Vizte co jsem psal o záměně ZIP, JAR, KMZ, KWD, ODT, ODP, OTT, SXC, SXD, SXI, SXW, SXC, WMZ, XPI, XPS a XPT (a nejspíš řady dalších formátů). Obsah souboru je prostě věc aplikace, může v něm být cokoliv včetně hlavičky EFS, a FS se podle toho nemůže a nesmí orientovat. Rozdělení na data souboru a metadata má velmi dobré důvody.

Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.

Citace
Samozřejmě starší verze FS neumí features novější verze. Tak už to u dopředné kompatibility bývá.

Jiste, nicmene byva zvykem, ze data treba sice neumi precist, ale aspon je nezkurvi. Nyni, kdyz Alois s W 10 prinese flashku Bedrichovi s Widlema 7, aby okopiroval porno pro Cyrila - opet s W 10, tak dojde k tomu, ze si Cyril moc nezaslimta.

Citace
MS by teoreticky mohl vydat patch pro starší verze Windows. Těžko ale vydá patche pro kamery, zvuková záznamová zařízení, MP3 přehrávače, televize, mobily, automobily a hromady dalších zařízení.

No, tak kamery asi nebudou sifrovat, tak je to jedno. A kdyby MS zvolil nejaky normalni zpusob znaceni sifrovanych souboru, problem by nebyl ani se zarizenimi z SD.

Koukám, že budete taky jeden z nás, co nemáme na takové věci pojmový aparát :D


MD

Re:Windows 10 EULA - som zhrozeny
« Odpověď #620 kdy: 31. 08. 2015, 22:28:42 »
Citace
Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.
Tam může vzniknout problém akorát v tom, když se někomu podaří navrhnout strukturu (např. datových) souborů své aplikace tak, že jejich počátek (hlavička) odpovídá šifrované variantě na daném oddílu/svazku používaného souborového systému. Pak minimálně při čtení takových dat může být člověk dost překvapen, co na něj vyleze (i když ta pravděpodobnost je malá). To teoreticky vyřeší použití bitu v metadatech.

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #621 kdy: 31. 08. 2015, 22:33:36 »
Citace
Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.
Tam může vzniknout problém akorát v tom, když se někomu podaří navrhnout strukturu (např. datových) souborů své aplikace tak, že jejich počátek (hlavička) odpovídá šifrované variantě na daném oddílu/svazku používaného souborového systému. Pak minimálně při čtení takových dat může být člověk dost překvapen, co na něj vyleze (i když ta pravděpodobnost je malá). To teoreticky vyřeší použití bitu v metadatech.

Pokud nejde zajistit, že ty bity nebudou vždy přítomny - nepodpora v jiných verzích specifikace stejné verze FS, jiné FS, jiné OS (dokonce i jiné verze OS stejného autora), jiná přenosová média, která tyto metadata nepřenesou (přenos po síti, přes emaily, cloudy...), archivační utility, které tato metadata neznají atd. je to řešení teoreticky i prakticky na 2 věci, protože příliš často to může selhat.

j

Re:Windows 10 EULA - som zhrozeny
« Odpověď #622 kdy: 31. 08. 2015, 22:45:32 »
Ono to zas tak jednoduche neni:

Vzhledem k tomo ze autoritativni zdroje ( LaelOphir ) rikaji, ze specifikace pozaduje pri vytvareni soboru nastavit reservovane bity na 0 a pak uz je nikdy nekontrolovat zksme tuhle hypotezu:

Dejme tomu ze firma SD napise program na spojovani souboru: ten vytvori, presne podle specifikace specifikace novy soubor s obema bity nastavenymi na 0 a postupne do nej zkopiruje data ze vstupnich souboru, ktere maji tyto bity != 0. Vysledek asi nebude fungovat ale bude podle specifikace.
Tím autoritativním zdrojem nejsem já, ale specifikace FAT32, kterou jsem opakovaně linkoval.

Samozřejmě staré implementace FAT32 nemohou umět to o co byly rozšířené nové specifikace. To je omezení dopředné kompatibility. Ext2 také neumí třeba přehrávat žurnál ext3. V případě FAT32 můžete už na Windows 95 OSR2 přečíst soubory zapsané na Windows 10, samozřejmě pokud nepoužijete věci které Windows 95 OSR2 neumí (třeba to šifrování). Nicméně šifrovaný soubor uvidíte na staré implementaci FAT32 s příponou .PFILE (tady děkuji MD že na to upozornil), takže by s tím neměl být problém.

S žurnálem Ext2 vs Ext3 je to zcela nerelevantní příklad. To nijak neovlivňuje uživatelovat data. Stejně jako neovlivňuje překopírování dat z FAT (bez žurnálu) na NTFS (s žurnálem) a následné čtení (tedy pokud ta data nebyla šifrovaná novým dementním systémem). :D

Problém s tím je, napsali jsme jaký. Ztrácejí se infromace, které způsobí, že stejný soubor s příponou .PFILE jednou rozšifrovat jde a po zkopírování nejde - EPIC FAIL!

A to ten tatar jeste nevi, ze pokud se ext3 primontuje v rezimu ext2 a zapise se na to, tak to nasledne neni zasadni problem, protoze tam nebudou jen prave ty zurnaly, s cimz si opravovator fs poradi. Ale rozhodne to nezmrvi data userovi.

Neblbni cece, to by nebyla M$ way, a dokonce by to i fungovalo. A dokonce to tak i funguje - teda pokud si nainstalujes non M$ appky ktery sifrujou jednotlivy soubory.
To by samozřejmě nefungovalo, protože obsah souborů je věc aplikace, může tam být cokoliv, a tedy je to nespolehlivý detekční mechanismus.

Mno dment jako ty samo nedokaze pochopit, ze kdyz mam nastroj na opravy disku, tak bit nastavenej do 1 tam, kde ma byt 0 je jaksi presne jedna z tech chyb, ktere by bylo zahodno opravit, ze.
Milý nedouku, ta specifikace zcela jasně říká, že máte na začátku nastavit bity na nulu a dál se o ně nestarat, protože jsou rezervované. Skoro ani nepřekvapí, že zrovna vy to čtete jako "tohle musí být vždy na nule". Čtete to samozřejmě úplně špatně.

Jasne, protoze M$ udela sifrovanej soubor a neumi si k nemu pridat dostatecne jednoznacnou hlavicku. Vis ty trotle, ze na hlavickach je zalozenej celej internet?
Jenže ty hlavičky jsou dané standardem, a nemohou být zaměněny s obsahem paketů, tedy uživatelskými daty. Naopak obsah souboru je zcela v režii aplikace, a mohou v něm být jakákoliv aplikační data, včetně libovolné hlavičky. Až pochopíte rozdíl mezi data a metadaty, přijďte zpátky si sypat popel na hlavu.

Kompatabilni zcela jiste neni, jak tu uz dobra duse dokazala experimentem, co na to rikas luliku? Hovno vid? Protoze ste mu prave zkurvili jeho zasifrovany data svoji nekompatabilni zmenou FS.
Stará implementace FS umí přečíst to co je zapsané bez nových features, tedy v tomto případě bez šifrování. Což je naprosto v pořádku.

Ano, imbecil tve kategorie samo nedokaze pochopit, ze aplikace vidi jen to, co ji predlozi system. Nevsim sem si, ze by si nejaka aplikace cetla sektory na disku. Stejne tak jako imbecil nedokaze pochopit, ze pomerne bezne M$ checkdisk (teky dokaze zcela spolelive zkurvit libovolna data i na disku kterej destiky nikdy nevidel) ZAPISUJE a to kupodivu tak, aby predevsim METAdata uvedl do souladu s tim, co se ocekava, a s tim, co vykalkuluje ze by tam asi tak mohlo byt. A jelikoz bit ma byt 0, tak tam taky tu 0 nastavi. (vrele doporucuju tenhle tool z widli odpreparovat predevsim, tem, kteri chteji pouziva zcela libovolne sifrovani - trebas i truecrypt).

Stejne tak trotl jako ty nedokaze pochopit, ze obsah paketu je dan hlavickou, kupodivu (jak prekvapive) se tak rozlisujou ruzny protokoly, a to dokonce na nekolika urovnich, kdy je (nejakym zazrakem) do ethernet ramce vlozej ip datagram a jeho ohsahem muze byt trebas tcp a v nem jeste muze byt vlozeno treba http a kdyz na tom prijde, v tom http muze byt klidanko dalsi tcp. A kupodivu, coz imbecil z M$ nemuze samozrejme nikda pochopit, z pohledu aplikace je to nejaky stream dat, a spousta hlavicek je ji zcela uzadeke, protoze je vzivote neuvidi, protoze ty hlevicky jsou starosti HW a OS. Zajimavy ze presne stejne se chovaji VSECHNY sifrujici kousky SW, KROME toho do M$.

Ve finale stara implementace nejen ze NIC cist neumi, maximane zobrazi jakysi binarni blob, ale se 100% jistotou data ZNICI, pri jakemkoli pokuu je kopirovat/presunovat/... coz je zcela bezna operace. A muzes tu napsat jeste klidne 100xty svy blaboly, na tom ze ses negramotnej kreten to nic nezmeni. O kdyz se obavam, ze definice kretenismu je v tomto pripade slaby kafe.

Tak ajťáci by mohli a měli vědět, že features z nové verze FS nejsou na staré verzi FS k dispozici. A když jim to nedojde, tak nejspíš následně budou schopni najít někoho, kdo nastaví dotyčný bit diskovým editorem. A když ne, tak dostanete padáka, protože jste měl důležité firemní informace pouze na přenosném médiu. Ale jinak je to moc pěkná pohádka :D
Jasne ty kretene, a meli se to dozvedet z neexistujici specifikace, ze?

Ne, závisí to na metadatech. Ale ne na metadatech FS. Metadata můžou být i ve struktuře souboru. Pár zpráv zpátky, jsem vám říkal, ať se to doučíte a vy se znovu ztrapníte.
Metadada v souboru jsou nutně nespolehlivá, protože každá aplikace může zapisovat do souboru cokoliv uzná za vhodné, včetně obsahu který je záměnný s metadaty. Pokud vám nedochází že je to v principu nespolehlivé, a chování volání read() se tím tedy nemůže řídit, tak prosím vylijte na základní desku svého stroje sklenici slané vody, a jiný počítač si nekupujte, protože byste mohl ublížit nejen sobě, ale kdybyste se nějakým omylem dostal k psaní kódu, tak i někomu jinému.

Ano imbecil co netusi jak funguje FS, a ze si na disk muze zapsat co chce. Zjevne neexistuje trebas zip. Divny, ze snim widle, sice blbe ale prece, umej fungovat tak, ze user vubec nemusi tusit, ze cte/zapisuje do zipu. Mno widle sice ten soubor detekujou podle pripony, coz je nahovno, protoze kdyz to nahodou neni zip, tak posilaj kravsky hlasky. Ale kupodivu, kvuli tomu nemusej kurvit userovi data. Divny co? A kupodivu i kdyz ten zip skopiruju pod DOSem, tak se nezkurvi. Divny co?

JAKEJ je rozdil mezi ZIPEM a tou sifrovaci srackou? Presne ZADNEJ. Jen tu sifrovaci sracku implementoval dement.

No, tak kamery asi nebudou sifrovat, tak je to jedno. A kdyby MS zvolil nejaky normalni zpusob znaceni sifrovanych souboru, problem by nebyl ani se zarizenimi z SD.

Jenze ono ti to zkurvi data i tak, ze vemes SDcko z telefonu, neco na nej pod widlema natlacis, a v tom telefonu si to pak trebas presunes do interni pameti a je to v <>.

Citace
Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.
Tam může vzniknout problém akorát v tom, když se někomu podaří navrhnout strukturu (např. datových) souborů své aplikace tak, že jejich počátek (hlavička) odpovídá šifrované variantě na daném oddílu/svazku používaného souborového systému. Pak minimálně při čtení takových dat může být člověk dost překvapen, co na něj vyleze (i když ta pravděpodobnost je malá). To teoreticky vyřeší použití bitu v metadatech.
Jasne, mel by sis rozsirit pojmovy aparat a jit se podivat jak funguje zip, a klidne si vyzkousej vyrobit textak a prejmenuj ho na zip ... divny co, dmentni hlasky, ale zadna katastrofa, narozdil od tohodle. Samo, kdyby widle fungovaly jako tux, mozna by i poznaly, ze to neni zip ale textovej soubor.

Re:Windows 10 EULA - som zhrozeny
« Odpověď #623 kdy: 31. 08. 2015, 22:50:45 »
Citace
Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.
Tam může vzniknout problém akorát v tom, když se někomu podaří navrhnout strukturu (např. datových) souborů své aplikace tak, že jejich počátek (hlavička) odpovídá šifrované variantě na daném oddílu/svazku používaného souborového systému. Pak minimálně při čtení takových dat může být člověk dost překvapen, co na něj vyleze (i když ta pravděpodobnost je malá). To teoreticky vyřeší použití bitu v metadatech.

Pokud nejde zajistit, že ty bity nebudou vždy přítomny - nepodpora v jiných verzích specifikace stejné verze FS, jiné FS, jiné OS (dokonce i jiné verze OS stejného autora), jiná přenosová média, která tyto metadata nepřenesou (přenos po síti, přes emaily, cloudy...), archivační utility, které tato metadata neznají atd. je to řešení teoreticky i prakticky na 2 věci, protože příliš často to může selhat.

Ach jo: ve všech těchto případech jsou data nejprve čtena z disku ovladačem filesystému který podle onoho bitu v metadatech rozpozná že jsou šifrovaná a poskytne je rozšifrovaná. Boha jeho chápete o čem se tu mluví?! A samozřejmě že pokud strčím do systému externí disk a soubor na něm zašifruju tak ho jinde nepřečtu, to je přece smysl téhle věci.

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #624 kdy: 31. 08. 2015, 23:08:22 »
Citace
Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.
Tam může vzniknout problém akorát v tom, když se někomu podaří navrhnout strukturu (např. datových) souborů své aplikace tak, že jejich počátek (hlavička) odpovídá šifrované variantě na daném oddílu/svazku používaného souborového systému. Pak minimálně při čtení takových dat může být člověk dost překvapen, co na něj vyleze (i když ta pravděpodobnost je malá). To teoreticky vyřeší použití bitu v metadatech.

Pokud nejde zajistit, že ty bity nebudou vždy přítomny - nepodpora v jiných verzích specifikace stejné verze FS, jiné FS, jiné OS (dokonce i jiné verze OS stejného autora), jiná přenosová média, která tyto metadata nepřenesou (přenos po síti, přes emaily, cloudy...), archivační utility, které tato metadata neznají atd. je to řešení teoreticky i prakticky na 2 věci, protože příliš často to může selhat.

Ach jo: ve všech těchto případech jsou data nejprve čtena z disku ovladačem filesystému který podle onoho bitu v metadatech rozpozná že jsou šifrovaná a poskytne je rozšifrovaná. Boha jeho chápete o čem se tu mluví?! A samozřejmě že pokud strčím do systému externí disk a soubor na něm zašifruju tak ho jinde nepřečtu, to je přece smysl téhle věci.

Ach jo, chápete, že jiné implementace tyhle problémy nemají? Ani když data přenášíte bez předešlého rozšifrování? Rozumíte tomu, že když v normálních implementacích přenesu kontejner s šifrovanými daty, bez jejich předchozího rozšifrování, tak ho i po násobném přenosu na cílové místo v případě správných dešifrovacích operací jeho obsah bez problémů přečtu? Kdežto u té přiblblé implementace se k obsahu dat v kontejneru EFS k nim už nedostanu?! Taková věc má jaký smysl, kromě hromady problémů, které odnese chudák uživatel?

Chápete, že kdyby tak fungovalo vše, tak by jste nemohli přenášet třeba ZIP soubor, bez explicitní podpory ZIP souboru ve FS?

Re:Windows 10 EULA - som zhrozeny
« Odpověď #625 kdy: 31. 08. 2015, 23:30:25 »
Citace
Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.
Tam může vzniknout problém akorát v tom, když se někomu podaří navrhnout strukturu (např. datových) souborů své aplikace tak, že jejich počátek (hlavička) odpovídá šifrované variantě na daném oddílu/svazku používaného souborového systému. Pak minimálně při čtení takových dat může být člověk dost překvapen, co na něj vyleze (i když ta pravděpodobnost je malá). To teoreticky vyřeší použití bitu v metadatech.

Pokud nejde zajistit, že ty bity nebudou vždy přítomny - nepodpora v jiných verzích specifikace stejné verze FS, jiné FS, jiné OS (dokonce i jiné verze OS stejného autora), jiná přenosová média, která tyto metadata nepřenesou (přenos po síti, přes emaily, cloudy...), archivační utility, které tato metadata neznají atd. je to řešení teoreticky i prakticky na 2 věci, protože příliš často to může selhat.

Ach jo: ve všech těchto případech jsou data nejprve čtena z disku ovladačem filesystému který podle onoho bitu v metadatech rozpozná že jsou šifrovaná a poskytne je rozšifrovaná. Boha jeho chápete o čem se tu mluví?! A samozřejmě že pokud strčím do systému externí disk a soubor na něm zašifruju tak ho jinde nepřečtu, to je přece smysl téhle věci.

Ach jo, chápete, že jiné implementace tyhle problémy nemají? Ani když data přenášíte bez předešlého rozšifrování? Rozumíte tomu, že když v normálních implementacích přenesu kontejner s šifrovanými daty, bez jejich předchozího rozšifrování, tak ho i po násobném přenosu na cílové místo v případě správných dešifrovacích operací jeho obsah bez problémů přečtu? Kdežto u té přiblblé implementace se k obsahu dat v kontejneru EFS k nim už nedostanu?! Taková věc má jaký smysl, kromě hromady problémů, které odnese chudák uživatel?

Chápete, že kdyby tak fungovalo vše, tak by jste nemohli přenášet třeba ZIP soubor, bez explicitní podpory ZIP souboru ve FS?

Jistěže chápu co popisujete. Bohužel vy odmítáte chápat co vám tu píšu já a někteří jiní. Odpovídat už mi nemusíte, toto je opravdu můj poslední post do této diskuse. Dobrou.

ByCzech

Re:Windows 10 EULA - som zhrozeny
« Odpověď #626 kdy: 31. 08. 2015, 23:38:01 »
Citace
Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.
Tam může vzniknout problém akorát v tom, když se někomu podaří navrhnout strukturu (např. datových) souborů své aplikace tak, že jejich počátek (hlavička) odpovídá šifrované variantě na daném oddílu/svazku používaného souborového systému. Pak minimálně při čtení takových dat může být člověk dost překvapen, co na něj vyleze (i když ta pravděpodobnost je malá). To teoreticky vyřeší použití bitu v metadatech.

Pokud nejde zajistit, že ty bity nebudou vždy přítomny - nepodpora v jiných verzích specifikace stejné verze FS, jiné FS, jiné OS (dokonce i jiné verze OS stejného autora), jiná přenosová média, která tyto metadata nepřenesou (přenos po síti, přes emaily, cloudy...), archivační utility, které tato metadata neznají atd. je to řešení teoreticky i prakticky na 2 věci, protože příliš často to může selhat.

Ach jo: ve všech těchto případech jsou data nejprve čtena z disku ovladačem filesystému který podle onoho bitu v metadatech rozpozná že jsou šifrovaná a poskytne je rozšifrovaná. Boha jeho chápete o čem se tu mluví?! A samozřejmě že pokud strčím do systému externí disk a soubor na něm zašifruju tak ho jinde nepřečtu, to je přece smysl téhle věci.

Ach jo, chápete, že jiné implementace tyhle problémy nemají? Ani když data přenášíte bez předešlého rozšifrování? Rozumíte tomu, že když v normálních implementacích přenesu kontejner s šifrovanými daty, bez jejich předchozího rozšifrování, tak ho i po násobném přenosu na cílové místo v případě správných dešifrovacích operací jeho obsah bez problémů přečtu? Kdežto u té přiblblé implementace se k obsahu dat v kontejneru EFS k nim už nedostanu?! Taková věc má jaký smysl, kromě hromady problémů, které odnese chudák uživatel?

Chápete, že kdyby tak fungovalo vše, tak by jste nemohli přenášet třeba ZIP soubor, bez explicitní podpory ZIP souboru ve FS?

Jistěže chápu co popisujete. Bohužel vy odmítáte chápat co vám tu píšu já a někteří jiní. Odpovídat už mi nemusíte, toto je opravdu můj poslední post do této diskuse. Dobrou.

Já chápu to co popisujete. Ale odmítám to vychvalovat, protože to je špatně. To je celé.

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #627 kdy: 31. 08. 2015, 23:40:27 »
Stejne tak trotl jako ty nedokaze pochopit, ze obsah paketu je dan hlavickou, kupodivu (jak prekvapive) se tak rozlisujou ruzny protokoly, a to dokonce na nekolika urovnich, kdy je (nejakym zazrakem) do ethernet ramce vlozej ip datagram a jeho ohsahem muze byt trebas tcp a v nem jeste muze byt vlozeno treba http a kdyz na tom prijde, v tom http muze byt klidanko dalsi tcp. A kupodivu, coz imbecil z M$ nemuze samozrejme nikda pochopit, z pohledu aplikace je to nejaky stream dat, a spousta hlavicek je ji zcela uzadeke, protoze je vzivote neuvidi, protoze ty hlevicky jsou starosti HW a OS. Zajimavy ze presne stejne se chovaji VSECHNY sifrujici kousky SW, KROME toho do M$.
Jistě. Jenže zatím co u packetu máte jasně daný formát hlavičky, u souboru je celý obsah definovaný aplikací, a může obsahovat cokoliv, včetně jakýchkoliv hlaviček, které by pak byly misidentifikované jako hlavičky. Aby vám to fungovalo s těmi vašimi hlavičkami na FS podobně jako u OSI, musel byste ukládat hlavičky (metadata) tak aby k nim aplikace nemohla přistupovat, a aby tedy nedošlo k záměně metadat a dat. To je nakonec důvod, proč na úrovni TCP socketu nevidíte headery z MAC layeru. Což je, návrat na začátek, přesně to co dělá položka adresáře (akorát je adresář z důvodu výkonu držený na jednom místě). Nedělám si samozřejmě iluze, že byste pochopil co jsem napsal.

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #628 kdy: 01. 09. 2015, 00:09:49 »
Ach jo, chápete, že jiné implementace tyhle problémy nemají? Ani když data přenášíte bez předešlého rozšifrování? Rozumíte tomu, že když v normálních implementacích přenesu kontejner s šifrovanými daty, bez jejich předchozího rozšifrování, tak ho i po násobném přenosu na cílové místo v případě správných dešifrovacích operací jeho obsah bez problémů přečtu? Kdežto u té přiblblé implementace se k obsahu dat v kontejneru EFS k nim už nedostanu?! Taková věc má jaký smysl, kromě hromady problémů, které odnese chudák uživatel?

Chápete, že kdyby tak fungovalo vše, tak by jste nemohli přenášet třeba ZIP soubor, bez explicitní podpory ZIP souboru ve FS?
Dosud jste zřejmě nepochopil, že obsah celého souboru může být naprosto libovolný, a může klidně z jakéhokoliv důvodu (náhodná shoda dat, formát dat používající stejnou či podobnou hlavičku, pokus o útok) začínat hlavičkou, kterou byste chtěl použít pro detekci toho že je soubor šifrovaný. Opravdu vám nedochází, že je to celkem zásadní problém, a také primární důvod proč se metadata souborového systému drží odděleně od vlastního obsahu souboru?

ZIP je úplně jiný případ. Řeší problematiku až úrovni aplikace, kdy manipuluje se soubory označenými konkrétními metadata (příponou ZIP). Pochopitelně proto není transparentní pro aplikace pracující s FS. Zatím co k transparentně komprimovanému nebo šifrovanému souboru může přistupovat jakákoliv aplikace jako k běžnému souboru pomocí funkcí read(), write(), mmap() a čehokoliv dalšího, a můžete tak klidně třeba provozovat databázi, u ZIPu to v principu nejde (i když se to můžeme snažit pro některé jednoduché scénáře zakrýt pomocí shelllu).

Transparentní šifrování a komprese na úrovni FS má prostě jiné výhody a nevýhody než řešení na aplikační úrovni. Jsou to různá řešení s různým určením.

Lael.Ophir

Re:Windows 10 EULA - som zhrozeny
« Odpověď #629 kdy: 01. 09. 2015, 00:10:44 »
Laele - tohle nemá smysl. Je to prostě level pro který nemají pojmový aparát a úroveň abstrakce: škoda, protože ve skutečnosti nejsou hloupí, spíš naopak.

Myslím že už neni co dodat. Třeba jim to jednou dojde až budou mít víc zkušeností a míň testosteronu :-)

Co to nechat prostě být a propadnout za horizont událostí? I s ohledem na důstojnost všech zúčastněných…

Naprostý souhlas. Objektivní diskuze (pokud to, co je tady, lze tak nazvat) zřejmě nemá smysl.

Pánové souhlas s oběma. Díky za konstruktivní příspěvky. Fakta byla myslím jasně řečena, další diskuse postrádá smysl.