Teljes cookie védelemmel érkezett meg a Firefox 86

Címkék

A Mozilla bejelentette, hogy elérhető népszerű webböngészőjének legfrissebb verziója. A változásokról részletesen a kiadási megjegyzések weboldal számol be. Elérhető Windows, Linux és macOS platformokra számtalan nyelven, köztük természetesen magyarul is. Részletek - köztük a Total Cookie Protection leírása, magyarázata - a bejelentésben.

Hozzászólások

Szerkesztve: 2021. 02. 24., sze – 12:19

Most ismét elgondolkoztam. Milyen szép volt a világ 1995-ben. Voltak honlapok, de egyáltalán nem kellett ilyen parásan mindenféle alattomosságtól félni.

Egyúttal egy érdekesség arról, hogy milyen nyelveken írt sorok és milyen arányban vannak a Firefox kódbázisában: https://4e6.github.io/firefox-lang-stats/

Azon meglepődtem, hogy van benne assembly kód. Szép lehet ezt megannyi CPU architektúrára mind megírni. Mi az, amihez még a C sem elég alacsony szintű? Azért kérdem, mert MCU-ra írok épp hardware közeli kódot C-ben, regiszter szinten kell piszkálni a hardwert - nincs oprendszer -, s nincs szükség assembly programozásra. Ebbe tehát az interrupt service rutinok is beleértendők, meg a DMA kezelés is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Például vektorizációnál kockás papír - ceruza módszerrel mélyebben átgondolva kb. duplázni lehet a tempót. Személyes tapasztalat (RF jelfeldolgozás).
20 éve ez volt egy látványos példa, ami azóta még tovább ágazott: https://www.mpg123.de/cgi-bin/scm/mpg123/tags/1.26.4/src/libmpg123/
   * ott vannak a különböző CPU képességekre kihegyezett assembly-k
   * ha meg nincs pl. Sparc procira, akkor ott a C-ben írt "generic".

Olyan helyen is assembly van, ahol futásidőben akarja lekérdezni a CPU képességeit, hogy aszerinti utasításkészlettel rendelkező függvényt használjon a szoftver a gyors műveletekhez.

Firefox esetén konkrétan például:
   ./security/nss/lib/freebl/sha512-p8.s
   ./media/libtheora/lib/arm/armopts.s

   ./third_party/rust/sha-1/src/lib.rs --> sha1_asm https://crates.io/crates/sha1-asm
          És ide jutsz: https://github.com/RustCrypto/asm-hashes/tree/master/sha1/src
  

MCU: ha majd az ARM mikrovezérlőkben is benne lesz a NEON HELIUM, akkor ott is indulhat a kockás papír-ceruza módszer, amikor még egy picit tovább kell nyújtózkódni pl. a jelfeldolgozás számítási sebességével.

lehet, hogy egy C kódot váltasz ki, ami egy kritikus helyen van (dom tree keresés/rendezés/összeállítás) és másodpercenként ezerszám hívódik meg. Ha csak x64-en nyersz +10% -ot ami a vezető arch náluk, akkor megéri az asm betét

// Happy debugging, suckers
#define true (rand() > 10)

Én egyébként többet programoztam assembly-ben, mint bármilyen más nyelven, de azok jellemzően MCU-k, illetve régen még Z80. Szóval semmi bajom az assembly-vel, kedvelem, csak ilyen CPU architektúrákra, amelyből annyi van, mint csillag az égen, illetve igen bonyolult a hardware, meglehetősen kellemetlen ezeket a nagy vackokat assembly-ben piszkálni, ráadásul a C fordítok manapság jól optimalizálnak, meglehetősen célszerűtlennek tűnik egy felső rétegben futó alkalmazás egy-egy részét assembly-ben írni. Ha kernelről van szó, még megértem, a (g)libc esetén is esetleg indokolt lehet, de már ott is kérdéses, attól felfelé már nehezen hiszem el. Jó, persze aztán vannak az X-et megkerülő, az alkalmazást közvetlenül a videodriverrel összekötő, rétegeken átnyúló megoldások, amelyek gyorsak, de minden ésszerűséget, strukturáltságot nélkülöznek.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

én volt, hogy elkövettem asm betétet és csak 3%-ot nyertem az eredeti c kódhoz képest. Viszont ez egészen konkrétan egy adatbázis szerver volt, ahol a kérdéses kód minden query-nél lefutott, ha mindez másodpercenként 4m alkalommal történik, akkor ott már igen szignifikáns az a 3%

// Happy debugging, suckers
#define true (rand() > 10)

A C fordító (gcc, clang) normál esetben megdöbbentően jól fordít, kár hozzányúlni assembly szinten.
Akkor kell hozzányúlni, ha spéci dolgot szeretnénk elérni, amit a C fordító semmiképpen nem ért meg, és azzal nem +3%-ot, hanem akár +100%-ot is nyerünk és van eset, amikor ez szükséges.
Ilyen amikor valójában mélyebb optimalizáció kell. Például a fent írt vektorprocis témánál ott nyersz sokat, ha kockás papír - ceruza és ügyesen használod a 16 AVX regisztert vagy a 32 darab NEON regisztert, ezzel memóriaműveletet spórolva. Főleg ARM procikon jellemző, hogy a proci nagyon gyors de a RAM visszafog. Ezt az átfogó, már algoritmus átdolgozást is tartalmazó mutatványt nem lehet simán C fordítóval megoldani.

Tehát valójában nem az algoritmus fordítása, hanem az algoritmus és a regiszterszám (16 darab ill. 32 darab) összhangba hozása a varázslat. Lényeg, hogy az aritmetika során minél kevesebb legyen a RAM művelet.
Lásd még: https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Advanced_Vecto… ... AVX2 jellemző, AVX512 a procik kis arányában (főleg XEON-ok).
ARM Cortex A.. esetén: https://image.slidesharecdn.com/tphcc6ianrickardsneonopensymposia-14120… ... 64 bites módban dupla annyi NEON regiszter érhető el.

Mérd meg, hogy nélküle mennyivel lassabb a lefordított kód futása. Döbbenni fogsz.

A hitványabb fordítóknál a "register" szó tényleg segített, gcc és clang úgy tapasztaltam, hogy túllépett ezen.
Az  "uint_fast32_t" szintén hatástalan alapból 32 bites int-tel dolgozó architektúrán.

A python gondolom a buildhez/valami toolinghoz kell, de Java? Mi a fene. :D

Egyébként hogy kivágták a Mozillából a Rustos részleget gondolom a komponensek átírása sincs már annyira erőltetve C++ról. Sikerült magukat még jobban beszopatni az egésszel így, félig ebben van írva a böngésző, félig abban.

Java:
./mobile/android/
./third_party/libwebrtc/webrtc/sdk/android/

mappákban van a válasz.
Kiváncsi leszek én is, hogy mennyire vesznek vissza a Rust-beli törekvéssel. Ma az oldal szerint ( view-source:https://4e6.github.io/firefox-lang-stats/ )
  100 * 3048461 / (3048461 + 8491973) = 26.415 % Rust arányt mutat a [ Rust + C++ ] kódmennyiséget nézve.
Meg kell újra nézni hónapok múlva, hogy merre mozdul el ez a 25 éves múlttal rendelkező kódbázis.

Valami ilyet kellett volna az EU-nak is kiötlenie, nem azt a baromi idegesítő cookie-banner baromságot...

Na igen. Meg esetleg szabványosított kézfogást bevezetni, hogy lehessen alapértelmezett válaszom. És ha nem lehet azzal a választással használni az oldalt, akkor legyen popup, hogy biza itt dönteni kell, bemegyek-e vagy sem és addig ne is jelenítse meg a tartalmat. Olyan csoda jó a technológia, csak valamiért a zavarosban szeretnek halászni.

ühümm, kíváncsian várom hány elb*szott entrspájz management felület fog egycsapásra működésképtelenné válni...

Feltételezem, lehet kivételeket beállítani vagy kikapcsolni az egészet, ha több gondot okoz, mint amennyi hasznot hajt.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

En azt hittem a cookie eleve igy mukodik.

Mondjuk 2021-ben nem ártana, ha egy weboldal self-contained lehetne. Értsd: ne lehessen olyan tartalmat beágyazni (képek, js), ami más URL-ről származik. Egy rakat problémát megoldana.

... es pont ezektol olyan szajbakurt lassu az egesz interweb. Es meg nem is attol amit latsz (pofakonyv-lalykolos ikon meg ilyenek) hanem amit nem latsz. Kezdve az "ahany javascriptes library, annyi helyrol rantsuk le" mentalitastol az osszes adware-trackeren at a "lefuttatom az osszes fogadd-el-cookie-beallitasokat szkriptet akkoris ha a mar egyszer elfogadtad"-ig. 

>Kezdve az "ahany javascriptes library, annyi helyrol rantsuk le" mentalitastol

Ez nagyjából 10 éve nem divat már. Jellemzően használnak valami package + modulkezelőt fejlesztésnél és a kimenet egy (vagy mérettől/beállítástól függően több) JS bundle lesz, amit egy helyről hostolnak.

>az osszes adware-trackeren at

Ezek használata sajnos viszont az. De ha rászánsz kb. 2 perc munkát, akkor nevetségesen könnyen tilthatók (nem tiltja ezeket alapból a FF már egyébként?), onnantól pedig nem lassítanak semmit.

Hát ez jó vicc... Csak így gyorsan, hogy mi honnan jön egy átlag weboldalnál:

- js engine külső siteból, ami azért jó, mert 2MB js kóddal nagyon hatékonyan meg lehet oldani 2KB-nyi hasznos tartalombetöltését (hajbajzer lájkolja ezt)

- fontok google

- videók youtube

- képek random

- analitics google

- facebook, twitter, youtube a tracking és a hülye like meg share gombok miatt

És még a jó franc tudja. Szóval az oldalak úgy 95%-a be sem töltődne így rendesen.

"Sose a gép a hülye."

Mivel a funkcionalitásra szükség van, akkor max máshogy érik majd el a célt, legrosszabb esetben ugyan ezek a szarok valahogy keresztül lesznek proxyzva a célszerveren.

Tényleg sokkal faszább lenne, ha egy jól bekonfigolt böngészővel nem lehetne triviálisan kiszűrni az ilyen fosokat, meg magasabb költsége lenne (mondjuk a megnövekedett hálózati forgalom miatt) a weboldalak üzemeltetésnek. Biztosan mindenki nyerne rajta, de főleg a felhasználók...

Én jelenleg egy mezei FF installal + egy db. plugin (ublock) felrakásával mentesülök a webes szutymákok 90%-ától, köszönöm szépen, de nekem ez a rendszer így megfelel. Reálisan nézve kétlem, lehetne ennél kényelmesebb a helyzet számomra.

Szerkesztve: 2021. 02. 25., cs – 14:50

A Mozilla is ráfanyalodik a reklámokra:

https://bitport.hu/a-mozilla-is-rafanyalodik-a-reklamokra

Most éppen tesztjelleggel hirdetések értékesítésével próbálkoznak. Mint a vállalat weboldalán olvasható, egyelőre kísérletként kínálnak hirdetőknek ún. szponzorált top site-okat, melyeket a Firefox kezdőoldalán vagy egy új tab/ablak megnyitásakor jelenít meg a böngésző. A szolgáltatást egyelőre csak egy szűk tesztelői körnek tették elérhetővé.

A Mozilla azt ígéri, hogy itt olyan szponzorált oldalakat jelenít meg, ami az adott felhasználónak hasznosak lehetnek. A modell szerint pénze ebből a Mozillának akkor lesz, ha a felhasználók rákattintanak a szponzorált lapokra. Emiatt a vállalat alapvető érdeke, hogy valóban releváns site-okat jelenítsen meg ezeken a "csempéken".

Ez elég érdekes lesz Total Cookie Protection -al.

<insert födre köpős szmájli here>

Már így is tele van baszva fizetett - és a felhasználók szemszögéből kéretlen - szarokkal, mint:

- pocket

- lockwise

- sync

- kitörölhetetlen kereső motorok

- kitörölhetetlen Root CA-k.

- "opt-out"-os telemetria

 

Most még majd reklámot is tol az arcomba??

 

Ehhez képest a főoldalon még mindig ez áll:

Nincsenek kétes adatvédelmi irányelvek vagy hátsó ajtók a hirdetőknek. Csak egy villámgyors böngésző, ami nem bocsátja áruba.

 

Ez már kimeríti a pofátlan hazugság fogalmát??!

Egyrészt kikapcsolható, másrészt pl. a pocket (néhai readitlater) tök hasznos, én már sok éve használom.

Plusz továbbra is kérhető, hogy az új oldal teljesen üres legyen. Amúgy meg nem értem, hogy mi a problémád abból, hogy próbál önállóan pénzhez jutni.

Ismert hazai körökben az az általános nézet, hogy Orbán Viktor, mint minden elnök, szereti a pénzed.

Nekem van egy olyan kiegeszitom, hogy autosuspend tab.

Es be lehet allitani, hogyha 10 percig nem neztel meg egy tabot (vagy 20 vagy akarmennyi), akkor kilovi alola a javascriptet.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Most frissítettem... Más valaki nem tapasztalt olyan problémát, hogy a kerberos ticketeket eldobja/elrontja?

Simán kinit-tel kérek egy ticketet, amit használok site-okhoz történő auth-ra is.... És valahogy a frissítés óta random idő után, random site-oknál eltűnik a ticket (feljön a jelszóbekérés mint fallback), kinit -R pedig azt mondja hogy ticket expired, az pedig kizárt.

"Sose a gép a hülye."