Vlákno názorů k článku Když se operátor změní v útočníka na vaše soukromí od Bhua - > jediné, co uživatelé, kterým podobné praktiky vadí,...
-
No ne, pán má tady náhodou pravdu. Protože pokud trackování probíhá na úrovni requestu na server, tedy mezi vaším telefonem a cílovým serverem, jde to relativně snadno obejít. Prostě request na server neopustí váš mobil a tedy ho nemůže operátor, který ho nepřenáší, ani nijak upravit. Stačí směrovat ty reklamní weby na localhost.
Tohle by fungovalo jenom v případě, že označené jsou jenom requesty na reklamní servery. Což bohužel asi nejsou. Takže pokud nechcete provozovat VPN, do které operátor nevidí, máte smůlu. Je otázka, jestli placení VPN a směrování veškerého provozu přes ni je pro uživatele přijatelnější, než nechat svoji komunikaci značkovat.
-
adx (neregistrovaný)
Je otázka kdo značkování vyhodnocuje. Zda reklamní systémy (u těch se dá předpokládat že ano, neboť špiclování jejich záměr), nebo stránky co poskytuje obsah.
Každopádně je to hnus, neboť provozovatel drátů mění přenášená data. Dnes přepisuje hlavičky HTTP requestů, zítra bude měnit reklamu konkurence, pozítří zvyšovat ratingy filmů na IMDB (co si připlatí) nebo vymazávat z obsahu zakázaná slovíčka?
Snad se v USA najde dost lidí, co se složí na právníky a bude z toho nějaká fajn žalobička.
-
E-Ryc (neregistrovaný)
Ale tady nejde o to, ze neuvidim reklamu (tomu samozrejme zabranit jde), ale ze identifikator dostane server, ktery si chci prohlizet (treba lupa - a razem mi muze zacit zvyraznovat nejake clanky, o kterych si mysli, ze je chci cist) - a tady bez VPN sanci nemam, protoze bez odeslani requestu si stranku neprohlidnu a jinak ani https nepomuze (hlavicky zasifrovane nejsou a operator je muze menit dle libosti).
-
PavelM (neregistrovaný)
S tím HTTPs to snad nemyslíte vážně, to jste se asi upsal?
HTTPs samozřejmě šifruje komunikaci komplet, včetně hlaviček. Proto je také problém s více certifikáty na 1 IP adrese, pokud se nenasadí nějaké řešení, které to rozšifruje už před servery.
Ale na druhou stranu nebudu příliš optimista a raději budu rovnou předpokládat, že má operátor MitM proxy s vlastní CA s certifikátem podepsaným důvěryhodnou CA a může měnit i HTTPs provoz. Rozhodně by to stálo za test z jejich sítě u nějakého serveru, který není přímo kontrolován prohlížečem (viz kauza, kdy Google zjistil něco podobného protože měl v Chrome své certifikáty zadrátovány napevno).
-
fd (neregistrovaný)
Pokud kdokoli cestou disponuje CA, kterou prohlizec povazuje za "duveryhodnou", muze si vygenerovat certifikat pro zcela libovolnou domenu a prohlizec protestovat nebude.
Ve firemnim sektoru se prave presne toto a presne stejne vyuziva. Tu CA si provozuje firma, a jeji "duveryhodnost" na svem HW snadno zaridi. Klient pak v realu vubec nekomunikuje sifrovane se serverem, ale prave s proxy, o ktere si mysli, ze je to cilovy server.
-
E-Ryc (neregistrovaný)
Zkusil jsem to na Fiddleru s vypnutym dekodovanim HTTPS a stejne hlavicky vidim (ale nejsem sitar, treba Fiddler nejak podvadi a stejne to dekoduje):
GET https://www.seznam.cz/ HTTP/1.1
Host: www.seznam.cz
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie:**** -
PavelM (neregistrovaný)
No ono závisí na tom, co a jak používáte. Fiddler jako takový neznám, těch nástrojů je poměrně dost, takže netuším, jak to dělá. Ale z principu je šifrovaný celý kanál.
Pokud je to nějak integrováno s prohlížečem (viz třeba HttpFox), tak si prostě vezme hlavičky a případně i data z requestu v prohlížeči přímo.
Pak je varianta, že do prohlížeče přidáte certifikát proxy a ona si to dešifruje a šifruje k serveru (klasický MitM).
ČLÁNKY DO MAILU