Chrome 76 havis kaŝpasejo en la efektivigo de la FileSystem API, kiu ebligas al vi determini el TTT-apliko la uzon de inkognita reĝimo. Komencante kun Chrome 76, anstataŭ bloki aliron al la FileSystem API, kiu estis uzata kiel signo de Inkognita reĝima agado, la retumilo ne plu limigas la FileSystem API, sed purigas ŝanĝojn faritajn post la sesio. Kiel ĝi rezultas, la nova efektivigo malavantaĝoj, kiuj ebligas determini la agadon de inkognita reĝimo kiel antaŭe.
La esenco de la problemo estas, ke la sesio kun la FileSystem API en inkognita reĝimo estas provizora, kaj la datumoj ne estas konservitaj en disko kaj estas konservitaj en RAM. Respektive, la tempo de konservado de datumoj per la FileSystem API kaj la devioj kiuj ŝprucas (konservante en RAM, konstantaj karakterizaĵoj estas registritaj, dum skribante al disko, la prokrastoj ŝanĝiĝas) vi povas memfide juĝi ĉu la paĝo estas rigardata en inkognita reĝimo aŭ ne. . La malavantaĝo de ĉi tiu metodo estas la sufiĉe longa procezo de mezurado de devioj, kiu povas daŭri proksimume minuton ().
Samtempe, ankoraŭ unu afero restas nefiksita en Chrome 76 , kiu ebligas al vi juĝi la agadon de inkognita reĝimo surbaze de taksado de la limigoj fiksitaj per la API . Por provizora stokado uzata en inkognita reĝimo, malsamaj limoj estas fiksitaj ol por plena stokado sur disko.
Ni memorigu vin, ke retejoj funkciigantaj laŭ la modelo provizi plenan aliron per pagita abono (pagmuro) interesiĝas pri difini inkognitan reĝimon. Por altiri novan publikon, tiaj retejoj provizas novajn uzantojn kun demo-plena aliro dum iom da tempo, kiu estas aktive uzata por preterpasi pagmurojn. La plej facila maniero por aliri pagitan enhavon en tiaj sistemoj estas uzi inkognitan reĝimon, en kiu la retejo kredas, ke la uzanto malfermis la paĝon unuafoje. Eldonistoj ne ĝojas pri ĉi tiu konduto, do ili aktive uzis kaŝpasejon asociitan kun la FileSystem API por trudi postulon malŝalti inkognitan reĝimon por daŭrigi foliumi.
fonto: opennet.ru