Google tungkol sa pagbabago ng diskarte sa pagproseso ng halo-halong nilalaman sa mga pahinang binuksan sa pamamagitan ng HTTPS. Dati, kung may mga bahagi sa mga pahinang binuksan sa pamamagitan ng HTTPS na na-load mula sa walang encryption (sa pamamagitan ng http:// protocol), isang espesyal na indicator ang ipinakita. Sa hinaharap, napagpasyahan na i-block ang pag-load ng mga naturang mapagkukunan bilang default. Kaya, ang mga pahinang binuksan sa pamamagitan ng "https://" ay ginagarantiyahan na naglalaman lamang ng mga mapagkukunang na-download sa pamamagitan ng isang secure na channel ng komunikasyon.
Napansin na sa kasalukuyan ay higit sa 90% ng mga site ang binubuksan ng mga user ng Chrome gamit ang HTTPS. Ang pagkakaroon ng mga pagsingit na na-load nang walang pag-encrypt ay lumilikha ng mga banta sa seguridad sa pamamagitan ng pagbabago ng hindi protektadong nilalaman kung may kontrol sa channel ng komunikasyon (halimbawa, kapag kumokonekta sa pamamagitan ng bukas na Wi-Fi). Napag-alamang hindi epektibo at nakakapanlinlang sa user ang mixed content indicator, dahil hindi ito nagbibigay ng malinaw na pagtatasa sa seguridad ng page.
Sa kasalukuyan, ang mga pinaka-mapanganib na uri ng pinaghalong nilalaman, tulad ng mga script at iframe, ay naka-block na bilang default, ngunit ang mga imahe, audio file at video ay maaari pa ring ma-download sa pamamagitan ng http://. Sa pamamagitan ng panggagaya ng larawan, maaaring palitan ng isang umaatake ang Cookies sa pagsubaybay ng user, subukang samantalahin ang mga kahinaan sa mga processor ng imahe, o gumawa ng pamemeke sa pamamagitan ng pagpapalit sa impormasyong ibinigay sa larawan.
Ang pagpapakilala ng pagharang ay nahahati sa maraming yugto. Ang Chrome 79, na nakatakda sa ika-10 ng Disyembre, ay magtatampok ng bagong setting na magbibigay-daan sa iyong i-disable ang pag-block para sa mga partikular na site. Ang setting na ito ay ilalapat sa halo-halong nilalaman na naka-block na, gaya ng mga script at iframe, at tatawagin sa pamamagitan ng menu na bumababa kapag nag-click ka sa simbolo ng lock, na pinapalitan ang dating iminungkahing indicator para sa hindi pagpapagana ng pag-block.
Ang Chrome 80, na inaasahang sa Pebrero 4, ay gagamit ng soft blocking scheme para sa mga audio at video file, na nagpapahiwatig ng awtomatikong pagpapalit ng http:// na mga link ng https://, na magpapanatili ng functionality kung ang problemadong mapagkukunan ay maa-access din sa pamamagitan ng HTTPS . Ang mga imahe ay patuloy na maglo-load nang walang pagbabago, ngunit kung na-download sa pamamagitan ng http://, ang https:// na mga pahina ay magpapakita ng hindi secure na tagapagpahiwatig ng koneksyon para sa buong pahina. Upang awtomatikong lumipat sa https o mag-block ng mga larawan, magagamit ng mga developer ng site ang mga pag-upgrade-hindi-secure-request ng mga katangian ng CSP at i-block-all-mixed-content. Ang Chrome 81, na naka-iskedyul para sa Marso 17, ay awtomatikong itatama ang http:// sa https:// para sa magkakahalong pag-upload ng larawan.
Bilang karagdagan, ang Google tungkol sa pagsasama sa isa sa mga susunod na release ng Chome browser ng bagong bahagi ng Password Checkup, dati sa form . Ang pagsasama ay hahantong sa paglitaw sa regular na Chrome password manager ng mga tool para sa pagsusuri sa pagiging maaasahan ng mga password na ginagamit ng user. Kapag sinubukan mong mag-log in sa anumang site, ang iyong login at password ay susuriin laban sa isang database ng mga nakompromisong account, na may babala na ipinapakita kung may nakitang mga problema. Isinasagawa ang pagsusuri laban sa isang database na sumasaklaw sa higit sa 4 bilyong nakompromisong account na lumabas sa mga leaked na database ng user. Isang babala din ang ipapakita kung susubukan mong gumamit ng mga walang kuwentang password gaya ng "abc123" (sa pamamagitan ng Google 23% ng mga Amerikano ay gumagamit ng mga katulad na password), o kapag gumagamit ng parehong password sa maraming site.
Upang mapanatili ang pagiging kumpidensyal, kapag nag-a-access sa isang panlabas na API, tanging ang unang dalawang byte ng hash ng login at password ang ipinadala (ang hashing algorithm ay ginagamit ). Ang buong hash ay naka-encrypt gamit ang isang key na nabuo sa gilid ng user. Ang orihinal na mga hash sa database ng Google ay karagdagang naka-encrypt at tanging ang unang dalawang byte ng hash ang natitira para sa pag-index. Ang panghuling pag-verify ng mga hash na nasa ilalim ng ipinadalang two-byte na prefix ay isinasagawa sa panig ng gumagamit gamit ang cryptographic na teknolohiya "β, kung saan hindi alam ng alinmang partido ang mga nilalaman ng data na sinusuri. Upang maprotektahan laban sa mga nilalaman ng isang database ng mga nakompromisong account na tinutukoy ng malupit na puwersa na may kahilingan para sa mga di-makatwirang prefix, ang ipinadalang data ay naka-encrypt na may kaugnayan sa isang susi na nabuo batay sa isang na-verify na kumbinasyon ng pag-login at password.
Pinagmulan: opennet.ru