CINXE.COM

<!DOCTYPE html> <html class='v2 list-page' dir='ltr' itemscope='' itemtype='http://schema.org/Blog' lang='en' xmlns='http://www.w3.org/1999/xhtml' xmlns:b='http://www.google.com/2005/gml/b' xmlns:data='http://www.google.com/2005/gml/data' xmlns:expr='http://www.google.com/2005/gml/expr'> <head> <link href='https://www.blogger.com/static/v1/widgets/3566091532-css_bundle_v2.css' rel='stylesheet' type='text/css'/> <title> Google Online Security Blog: chrome </title> <meta content='JPvErrROkJmNEh4Lr_QT6CD77GdfQr6cLFw6gIXg6kc' name='google-site-verification'/> <meta content='width=device-width, height=device-height, minimum-scale=1.0, initial-scale=1.0, user-scalable=0' name='viewport'/> <meta content='IE=Edge' http-equiv='X-UA-Compatible'/> <meta content='Google Online Security Blog' property='og:title'/> <meta content='en_US' property='og:locale'/> <meta content='https://security.googleblog.com/search/label/chrome' property='og:url'/> <meta content='Google Online Security Blog' property='og:site_name'/>  <meta content='Google Online Security Blog' property='og:title'/> <meta content='summary' name='twitter:card'/> <meta content='@google' name='twitter:creator'/> <link href='https://fonts.googleapis.com/css?family=Roboto:400italic,400,500,500italic,700,700italic' rel='stylesheet' type='text/css'/> <link href='https://fonts.googleapis.com/icon?family=Material+Icons' rel='stylesheet'/> <script src='https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js' type='text/javascript'></script>  <style id='page-skin-1' type='text/css'></style> <style id='template-skin-1' type='text/css'></style>  <meta content='text/html; charset=UTF-8' http-equiv='Content-Type'/> <meta content='blogger' name='generator'/> <link href='https://security.googleblog.com/favicon.ico' rel='icon' type='image/x-icon'/> <link href='https://security.googleblog.com/search/label/chrome' rel='canonical'/> <link rel="alternate" type="application/atom+xml" title="Google Online Security Blog - Atom" href="https://security.googleblog.com/feeds/posts/default" /> <link rel="alternate" type="application/rss+xml" title="Google Online Security Blog - RSS" href="https://security.googleblog.com/feeds/posts/default?alt=rss" /> <link rel="service.post" type="application/atom+xml" title="Google Online Security Blog - Atom" href="https://www.blogger.com/feeds/1176949257541686127/posts/default" />  <meta content='https://security.googleblog.com/search/label/chrome' property='og:url'/> <meta content='Google Online Security Blog' property='og:title'/> <meta content='The latest news and insights from Google on security and safety on the Internet' property='og:description'/>  <base target='_self'/> <style> html { font-family: Roboto, sans-serif; -moz-osx-font-smoothing: grayscale; -webkit-font-smoothing: antialiased; } body { padding: 0; /* This ensures that the scroll bar is always present, which is needed */ /* because content render happens after page load; otherwise the header */ /* would "bounce" in-between states. */ min-height: 150%; } h2 { font-size: 16px; } h1, h2, h3, h4, h5 { line-height: 2em; } html, h4, h5, h6 { font-size: 14px; } a, a:visited { color: #4184F3; text-decoration: none; } a:focus, a:hover, a:active { text-decoration: none; } .Header { margin-top: 15px; } .Header h1 { font-size: 32px; font-weight: 300; line-height: 32px; height: 42px; } .header-inner .Header .titlewrapper { padding: 0; margin-top: 30px; } .header-inner .Header .descriptionwrapper { padding: 0; margin: 0; } .cols-wrapper { margin-top: 56px; } .header-outer, .cols-wrapper, .footer-outer, .google-footer-outer { padding: 0 60px; } .header-inner { height: 256px; position: relative; } html, .header-inner a { color: #212121; color: rgba(0,0,0,.87); } .header-inner .google-logo { display: inline-block; background-size: contain; z-index: 1; height: 46px; overflow: hidden; margin-top: 4px; margin-right: 8px; } .header-left { position: absolute; top: 50%; -webkit-transform: translateY(-50%); transform: translateY(-50%); margin-top: 12px; width: 100%; } .google-logo { margin-left: -4px; } #google-footer { position: relative; font-size: 13px; list-style: none; text-align: right; } #google-footer a { color: #444; } #google-footer ul { margin: 0; padding: 0; height: 144px; line-height: 144px; } #google-footer ul li { display: inline; } #google-footer ul li:before { color: #999; content: "\00b7"; font-weight: bold; margin: 5px; } #google-footer ul li:first-child:before { content: ''; } #google-footer .google-logo-dark { left: 0; margin-top: -16px; position: absolute; top: 50%; } /** Sitemap links. **/ .footer-inner-2 { font-size: 14px; padding-top: 42px; padding-bottom: 74px; } .footer-inner-2 .HTML h2 { color: #212121; color: rgba(0,0,0,.87); font-size: 14px; font-weight: 500; padding-left: 0; margin: 10px 0; } .footer-inner-2 .HTML ul { font-weight: normal; list-style: none; padding-left: 0; } .footer-inner-2 .HTML li { line-height: 24px; padding: 0; } .footer-inner-2 li a { color: rgba(65,132,243,.87); } /** Archive widget. **/ .BlogArchive { font-size: 13px; font-weight: normal; } .BlogArchive .widget-content { display: none; } .BlogArchive h2, .Label h2 { color: #4184F3; text-decoration: none; } .BlogArchive .hierarchy li { display: inline-block; } /* Specificity needed here to override widget CSS defaults. */ .BlogArchive #ArchiveList ul li, .BlogArchive #ArchiveList ul ul li { margin: 0; padding-left: 0; text-indent: 0; } .BlogArchive .intervalToggle { cursor: pointer; } .BlogArchive .expanded .intervalToggle .new-toggle { -ms-transform: rotate(180deg); transform: rotate(180deg); } .BlogArchive .new-toggle { float: right; padding-top: 3px; opacity: 0.87; } #ArchiveList { text-transform: uppercase; } #ArchiveList .expanded > ul:last-child { margin-bottom: 16px; } #ArchiveList .archivedate { width: 100%; } /* Months */ .BlogArchive .items { max-width: 150px; margin-left: -4px; } .BlogArchive .expanded .items { margin-bottom: 10px; overflow: hidden; } .BlogArchive .items > ul { float: left; height: 32px; } .BlogArchive .items a { padding: 0 4px; } .Label { font-size: 13px; font-weight: normal; } .sidebar-icon { display: inline-block; width: 24px; height: 24px; vertical-align: middle; margin-right: 12px; margin-top: -1px } .Label a { margin-right: 4px; } .Label .widget-content { display: none; } .FollowByEmail { font-size: 13px; font-weight: normal; } .FollowByEmail h2 { background: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABEAAAALCAYAAACZIGYHAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAUBJREFUeNrMkSGLAlEUhb+ZB4JFi8mx2cz+ApvhRUGTcUCrNqNJDYIi+DO0GUwmQXDK2DSIoGgZcSaIjDrzwrK4ssvChj1w0733O+fdp+m6PozH4yQSCfb7Pa7r8pOi0SjJZBLP8zgej4gAIMvlMuPxmADIYrHger1+C6lUKmo+NJ/NZojb7SZDWiwWo1qtks1msW2bw+HwZdkwDHq9HvV6nel0SqvVYrvdIh6Ph3Qch+VyqRYLhQJSSjRNw7IsfN9XgGKxSLfbJZfL0e/3aTabrFYr7vc7IujLcOh8PqunrNdr0uk0pVKJVCpFJBJRgEajweVyod1uMxgM2O12BAGUgRbU8DV2JpOhVquRz+cRQii3+XxOp9NRN3jVR5LPOp1OjEYjlSL8hclkgmmabDabt4d+m+S30vkD/R/IU4ABAPTZgnZdmG/PAAAAAElFTkSuQmCC"); background-repeat: no-repeat; background-position: 0 50%; text-indent: 30px; } .FollowByEmail .widget-content { display: none; } .searchBox input { border: 1px solid #eee; color: #212121; color: rgba(0,0,0,.87); font-size: 14px; padding: 8px 8px 8px 40px; width: 164px; font-family: Roboto, sans-serif; background: url("https://www.gstatic.com/images/icons/material/system/1x/search_grey600_24dp.png") 8px center no-repeat; } .searchBox ::-webkit-input-placeholder { /* WebKit, Blink, Edge */ color: rgba(0,0,0,.54); } .searchBox :-moz-placeholder { /* Mozilla Firefox 4 to 18 */ color: #000; opacity: 0.54; } .searchBox ::-moz-placeholder { /* Mozilla Firefox 19+ */ color: #000; opacity: 0.54; } .searchBox :-ms-input-placeholder { /* Internet Explorer 10-11 */ color: #757575; } .widget-item-control { margin-top: 0px; } .section { margin: 0; padding: 0; } #sidebar-top { border: 1px solid #eee; } #sidebar-top > div { margin: 16px 0; } .widget ul { line-height: 1.6; } /*main post*/ .post { margin-bottom:30px; } #main .post .title { margin: 0; } #main .post .title a { color: #212121; color: rgba(0,0,0,.87); font-weight: normal; font-size: 24px; } #main .post .title a:hover { text-decoration:none; color:#4184F3; } .message, #main .post .post-header { margin: 0; padding: 0; } #main .post .post-header .caption, #main .post .post-header .labels-caption, #main .post .post-footer .caption, #main .post .post-footer .labels-caption { color: #444; font-weight: 500; } #main .tr-caption-container td { text-align: left; } #main .post .tr-caption { color: #757575; color: rgba(0,0,0,.54); display: block; max-width: 560px; padding-bottom: 20px; } #main .post .tr-caption-container { line-height: 24px; margin: -1px 0 0 0 !important; padding: 4px 0; text-align: left; } #main .post .post-header .published{ font-size:11px; font-weight:bold; } .post-header .publishdate { font-size: 17px; font-weight:normal; color: #757575; color: rgba(0,0,0,.54); } #main .post .post-footer{ font-size:12px; padding-bottom: 21px; } .label-footer { margin-bottom: 12px; margin-top: 12px; } .comment-img { margin-right: 16px; opacity: 0.54; vertical-align: middle; } #main .post .post-header .published { margin-bottom: 40px; margin-top: -2px; } .post .post-content { color: #212121; color: rgba(0,0,0,.87); font-size: 17px; margin: 25px 0 36px 0; line-height: 32px; } .post-body .post-content ul, .post-body .post-content ol { margin: 16px 0; padding: 0 48px; } .post-summary { display: none; } /* Another old-style caption. */ .post-content div i, .post-content div + i { font-size: 14px; font-style: normal; color: #757575; color: rgba(0,0,0,.54); display: block; line-height: 24px; margin-bottom: 16px; text-align: left; } /* Another old-style caption (with link) */ .post-content a > i { color: #4184F3 !important; } /* Old-style captions for images. */ .post-content .separator + div:not(.separator) { margin-top: -16px; } /* Capture section headers. */ .post-content br + br + b, .post-content .space + .space + b, .post-content .separator + b { display: inline-block; margin-bottom: 8px; margin-top: 24px; } .post-content li { line-height: 32px; } /* Override all post images/videos to left align. */ .post-content .separator > a, .post-content .separator > span { margin-left: 0 !important; } .post-content img { max-width: 100%; height: auto; width: auto; } .post-content .tr-caption-container img { margin-bottom: 12px; } .post-content iframe, .post-content embed { max-width: 100%; } .post-content .carousel-container { margin-bottom: 48px; } #main .post-content b { font-weight: 500; } /* These are the main paragraph spacing tweaks. */ #main .post-content br { content: ' '; display: block; padding: 4px; } .post-content .space { display: block; height: 8px; } .post-content iframe + .space, .post-content iframe + br { padding: 0 !important; } #main .post .jump-link { margin-bottom:10px; } .post-content img, .post-content iframe { margin: 30px 0 20px 0; } .post-content > img:first-child, .post-content > iframe:first-child { margin-top: 0; } .col-right .section { padding: 0 16px; } #aside { background:#fff; border:1px solid #eee; border-top: 0; } #aside .widget { margin:0; } #aside .widget h2, #ArchiveList .toggle + a.post-count-link { color: #212121; color: rgba(0,0,0,.87); font-weight: 400 !important; margin: 0; } #ArchiveList .toggle { float: right; } #ArchiveList .toggle .material-icons { padding-top: 4px; } #sidebar .tab { cursor: pointer; } #sidebar .tab .arrow { display: inline-block; float: right; } #sidebar .tab .icon { display: inline-block; vertical-align: top; height: 24px; width: 24px; margin-right: 13px; margin-left: -1px; margin-top: 1px; color: #757575; color: rgba(0,0,0,.54); } #sidebar .widget-content > :first-child { padding-top: 8px; } #sidebar .active .tab .arrow { -ms-transform: rotate(180deg); transform: rotate(180deg); } #sidebar .arrow { color: #757575; color: rgba(0,0,0,.54); } #sidebar .widget h2 { font-size: 14px; line-height: 24px; display: inline-block; } #sidebar .widget .BlogArchive { padding-bottom: 8px; } #sidebar .widget { border-bottom: 1px solid #eee; box-shadow: 0px 1px 0 white; margin-bottom: 0; padding: 14px 0; min-height: 20px; } #sidebar .widget:last-child { border-bottom: none; box-shadow: none; margin-bottom: 0; } #sidebar ul { margin: 0; padding: 0; } #sidebar ul li { list-style:none; padding:0; } #sidebar ul li a { line-height: 32px; } #sidebar .archive { background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAYCAYAAADzoH0MAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAE1JREFUeNpiNDY23s9AAWBioBCwYBM8c+YMVsUmJibEGYBNMS5DaeMFfDYSZQA2v9I3FrB5AZeriI4FmnrBccCT8mhmGs1MwyAzAQQYAKEWG9zm9QFEAAAAAElFTkSuQmCC"); height: 24px; line-height: 24px; padding-left: 30px; } #sidebar .labels { background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABEAAAARCAYAAAA7bUf6AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAUxJREFUeNpiNDY23s9AAMycOfM7UF05kHkZmzwTMkdSUhKrIcXFxZy3bt3qBjIN8RrS09PDsHnzZjCNDr58+cKQlpbGDjSoHcg1w2oIyAUODg5gARCNzUVIBrUCuVYYhjx//pzhwIEDYAEQDeJjA1CDWIAGNQK59jBxRuSABbkAlwHIgIeHh2HWrFn/1NTU2oDcvSgBS4wBSC5iArqoCsj1YGIgEyAZVMoEchqlBjEB/cZAiUHg2AEGznpKDAImxOeM////B4VLKtBvEUCngZ1ILKivr3/u6+ubBzJAGZQ9gC5aQoqLgAY8BhkAZL4BuQQkxgXE34A4BuiiZEIuAhrwEGhAEZD5DpzYoIaA2UAM4kQADUrHZRDUgAIg8wO2XAwzbQXQa5OweQ1owB10AyA6gS7BgX1u3ry5397eHow3bdo0EyjGi00tQIABANPgyAH1q1eaAAAAAElFTkSuQmCC"); height: 20px; line-height: 20px; padding-left: 30px; } #sidebar .rss a { background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABIAAAASCAYAAABWzo5XAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAX5JREFUeNqsVDGSgkAQHL2rIiIikohIc/EBRkbwAIwuwgfwAXiAD9AHSI7kEkECRCb6AIyINDLx7K0aa6kT7uq0q7YYtnZ7umdnt7darXbr9Zpegeu61DNNc0dvwCcH4/GYJpMJnc9nOhwOVJbl/4hAAokMECZJQtvt9k+kH7qufyEYDAakqqqYxFdRFBqNRmTbNg2HQ0rTlK7XayvR0xqBdDqdkuM4dE/0ULhYLOh4PHYrknG5XGi/31MYhuL/nkwonM1mlGUZ1XXdrsiyLGEDhY7juJEZ1u5tIixDGdYhmYw+B7CAzPP5nDabjdgIAgCksMX1832/3drtdqPT6SQWapomiGEFNkDEdpDMMAzK81ys/7XYy+XyoQgq2WoURSIJ2iIIgp/WZCCTvFm2wgeAU31aI3Q2GhIDMeB53qPYPIcm5VrxXIOIOxsDMStjVawAc1VViRgN22lNBiuQN3GR+SY07hpOoStmFQAKXRRFY93bnpG+fONfedi+BRgAbkS8Fxp7QQIAAAAASUVORK5CYII="); } #sidebar .subscription a { background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABEAAAALCAYAAACZIGYHAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAUBJREFUeNrMkSGLAlEUhb+ZB4JFi8mx2cz+ApvhRUGTcUCrNqNJDYIi+DO0GUwmQXDK2DSIoGgZcSaIjDrzwrK4ssvChj1w0733O+fdp+m6PozH4yQSCfb7Pa7r8pOi0SjJZBLP8zgej4gAIMvlMuPxmADIYrHger1+C6lUKmo+NJ/NZojb7SZDWiwWo1qtks1msW2bw+HwZdkwDHq9HvV6nel0SqvVYrvdIh6Ph3Qch+VyqRYLhQJSSjRNw7IsfN9XgGKxSLfbJZfL0e/3aTabrFYr7vc7IujLcOh8PqunrNdr0uk0pVKJVCpFJBJRgEajweVyod1uMxgM2O12BAGUgRbU8DV2JpOhVquRz+cRQii3+XxOp9NRN3jVR5LPOp1OjEYjlSL8hclkgmmabDabt4d+m+S30vkD/R/IU4ABAPTZgnZdmG/PAAAAAElFTkSuQmCC"); } #sidebar-bottom { background: #f5f5f5; border-top:1px solid #eee; } #sidebar-bottom .widget { border-bottom: 1px solid #e0e0e0; padding: 15px 0; text-align: center; } #sidebar-bottom > div:last-child { border-bottom: 0; } #sidebar-bottom .text { line-height: 20px; } /* Home, forward, and backward pagination. */ .blog-pager { border-top : 1px #e0e0e0 solid; padding-top: 10px; margin-top: 15px; text-align: right !important; } #blog-pager { margin-botom: 0; margin-top: -14px; padding: 16px 0 0 0; } #blog-pager a { display: inline-block; } .blog-pager i.disabled { opacity: 0.2 !important; } .blog-pager i { color: black; margin-left: 16px; opacity: 0.54; } .blog-pager i:hover, .blog-pager i:active { opacity: 0.87; } #blog-pager-older-link, #blog-pager-newer-link { float: none; } .gplus-profile { background-color: #fafafa; border: 1px solid #eee; overflow: hidden; width: 212px; } .gplus-profile-inner { margin-left: -1px; margin-top: -1px; } /* Sidebar follow buttons. */ .followgooglewrapper { padding: 12px 0 0 0; } .loading { visibility: hidden; } .detail-page .post-footer .cmt_iframe_holder { padding-top: 40px !important; } /** Desktop **/ @media (max-width: 900px) { .col-right { display: none; } .col-main { margin-right: 0; min-width: initial; } .footer-outer { display: none; } .cols-wrapper { min-width: initial; } .google-footer-outer { background-color: #f5f5f5; } } /** Tablet **/ @media (max-width: 712px) { .header-outer, .cols-wrapper, .footer-outer, .google-footer-outer { padding: 0 40px; } } /* An extra breakpoint accommodating for long blog titles. */ @media (max-width: 600px) { .header-left { height: 100%; top: inherit; margin-top: 0; -webkit-transform: initial; transform: initial; } .header-title { margin-top: 18px; } .header-inner .google-logo { height: 40px; margin-top: 3px; } .header-inner .google-logo img { height: 42px; } .header-title h2 { font-size: 32px; line-height: 40px; } .header-desc { bottom: 24px; position: absolute; } } /** Mobile/small desktop window; also landscape. **/ @media (max-width: 480px), (max-height: 480px) { .header-outer, .cols-wrapper, .footer-outer, .google-footer-outer { padding: 0 16px; } .cols-wrapper { margin-top: 0; } .post-header .publishdate, .post .post-content { font-size: 16px; } .post .post-content { line-height: 28px; margin-bottom: 30px; } .post { margin-top: 30px; } .byline-author { display: block; font-size: 12px; line-height: 24px; margin-top: 6px; } #main .post .title a { font-weight: 500; color: #4c4c4c; color: rgba(0,0,0,.70); } #main .post .post-header { padding-bottom: 12px; } #main .post .post-header .published { margin-bottom: -8px; margin-top: 3px; } .post .read-more { display: block; margin-top: 14px; } .post .tr-caption { font-size: 12px; } #main .post .title a { font-size: 20px; line-height: 30px; } .post-content iframe { /* iframe won't keep aspect ratio when scaled down. */ max-height: 240px; } .post-content .separator img, .post-content .tr-caption-container img, .post-content iframe { margin-left: -16px; max-width: inherit; width: calc(100% + 32px); } .post-content table, .post-content td { width: 100%; } #blog-pager { margin: 0; padding: 16px 0; } /** List page tweaks. **/ .list-page .post-original { display: none; } .list-page .post-summary { display: block; } .list-page .comment-container { display: none; } .list-page #blog-pager { padding-top: 0; border: 0; margin-top: -8px; } .list-page .label-footer { display: none; } .list-page #main .post .post-footer { border-bottom: 1px solid #eee; margin: -16px 0 0 0; padding: 0 0 20px 0; } .list-page .post .share { display: none; } /** Detail page tweaks. **/ .detail-page .post-footer .cmt_iframe_holder { padding-top: 32px !important; } .detail-page .label-footer { margin-bottom: 0; } .detail-page #main .post .post-footer { padding-bottom: 0; } .detail-page #comments { display: none; } } [data-about-pullquote], [data-is-preview], [data-about-syndication] { display: none; } </style> <noscript> <style> .loading { visibility: visible }</style> </noscript>  <script async='true' src='https://www.googletagmanager.com/gtag/js?id=G-K46T604G22'></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-K46T604G22'); </script> <link href='https://www.blogger.com/dyn-css/authorization.css?targetBlogID=1176949257541686127&zx=48c7e5f3-aafb-48f6-ab03-6967320a5986' media='none' onload='if(media!='all')media='all'' rel='stylesheet'/><noscript><link href='https://www.blogger.com/dyn-css/authorization.css?targetBlogID=1176949257541686127&zx=48c7e5f3-aafb-48f6-ab03-6967320a5986' rel='stylesheet'/></noscript> <meta name='google-adsense-platform-account' content='ca-host-pub-1556223355139109'/> <meta name='google-adsense-platform-domain' content='blogspot.com'/> </head> <body> <script type='text/javascript'> //<![CDATA[ var axel = Math.random() + ""; var a = axel * 10000000000000; document.write('<iframe src="https://2542116.fls.doubleclick.net/activityi;src=2542116;type=gblog;cat=googl0;ord=ord=' + a + '?" width="1" height="1" frameborder="0" style="display:none"></iframe>'); //]]> </script> <noscript> <img alt='' height='1' src='https://ad.doubleclick.net/ddm/activity/src=2542116;type=gblog;cat=googl0;ord=1?' width='1'/> </noscript>  <div class='header-outer'> <div class='header-inner'> <div class='section' id='header'><div class='widget Header' data-version='1' id='Header1'> <div class='header-left'> <div class='header-title'> <a class='google-logo' href='https://security.googleblog.com/'> <img height='50' src='https://www.gstatic.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png'/> </a> <a href='/.'> <h2> Security Blog </h2> </a> </div> <div class='header-desc'> The latest news and insights from Google on security and safety on the Internet </div> </div> </div></div> </div> </div>  <div class='cols-wrapper loading'> <div class='col-main-wrapper'> <div class='col-main'> <div class='section' id='main'><div class='widget Blog' data-version='1' id='Blog1'> <div class='post' data-id='2468964486723565280' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html' itemprop='url' title='Improving the security of Chrome cookies on Windows'> Improving the security of Chrome cookies on Windows </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> July 30, 2024 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Will Harris, Chrome Security Team</span> <p> Cybercriminals using cookie theft <a href="https://cloud.google.com/blog/products/identity-security/a-year-in-the-cybersecurity-trenches-with-mandiant-managed-defense">infostealer</a> malware continue to pose a risk to the safety and security of our users. We already have a number of initiatives in this area including <a href="https://security.googleblog.com/2024/07/building-security-into-redesigned.html">Chrome’s download protection</a> using Safe Browsing, <a href="https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html">Device Bound Session Credentials</a>, and Google’s account-based threat detection to flag the use of stolen cookies. Today, we’re announcing another layer of protection to make Windows users safer from this type of malware. </p> <p> Like other software that needs to store secrets, Chrome currently secures sensitive data like cookies and passwords using the strongest techniques the OS makes available to us - on macOS this is the <a href="https://developer.apple.com/documentation/security/keychain_services/">Keychain services</a>, and on Linux we use a system provided wallet such as kwallet or gnome-libsecret. On Windows, Chrome uses the Data Protection API (DPAPI) which protects the data at rest from other users on the system or cold boot attacks. However, the DPAPI does not protect against malicious applications able to execute code as the logged in user - which infostealers take advantage of. </p> <p> In Chrome 127 we are introducing a new protection on Windows that improves on the DPAPI by providing <strong>Application-Bound (App-Bound) </strong>Encryption primitives. Rather than allowing any app running as the logged in user to access this data, Chrome can now encrypt data tied to app identity, similar to how the Keychain operates on macOS. </p> <p> We will be migrating each type of secret to this new system starting with cookies in Chrome 127. In future releases we intend to expand this protection to passwords, payment data, and other persistent authentication tokens, further protecting users from infostealer malware. </p> <p> <strong>How it works</strong> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpjkAClX2VvgsIhLi2zAmvRwVMPEeJqUhqisKHIKxbfGAwh8p8-V7Ixct5azzn_jYfJYo2izWnGcbkVh3cabbCLVQQQsJAJagvFPCFJsx4MibauJqnLVymQYdhdGGc53q3wSJSeTPQ6vyxXosJ-tJRKuaaoV7_J_E2KB9glSZ1m3NSEwEBj-duevgROHlM/s1416/Screenshot%202024-07-26%202.15.06%20PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="919" data-original-width="1416" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpjkAClX2VvgsIhLi2zAmvRwVMPEeJqUhqisKHIKxbfGAwh8p8-V7Ixct5azzn_jYfJYo2izWnGcbkVh3cabbCLVQQQsJAJagvFPCFJsx4MibauJqnLVymQYdhdGGc53q3wSJSeTPQ6vyxXosJ-tJRKuaaoV7_J_E2KB9glSZ1m3NSEwEBj-duevgROHlM/s16000/Screenshot%202024-07-26%202.15.06%20PM.png" /></a></div><p> App-Bound Encryption relies on a privileged service to verify the identity of the requesting application. During encryption, the App-Bound Encryption service encodes the app's identity into the encrypted data, and then verifies this is valid when decryption is attempted. If another app on the system tries to decrypt the same data, it will fail. </p> <p> Because the App-Bound service is running with system privileges, attackers need to do more than just coax a user into running a malicious app. Now, the malware has to gain system privileges, or inject code into Chrome, something that legitimate software shouldn't be doing. This makes their actions more suspicious to antivirus software – and more likely to be detected. Our other recent initiatives such as providing <a href="https://security.googleblog.com/2024/04/detecting-browser-data-theft-using.html">event logs</a> for cookie decryption work in tandem with this protection, with the goal of further increasing the cost and risk of detection to attackers attempting to steal user data. </p> <p> <strong>Enterprise Considerations</strong> </p> <p> Since malware can bypass this protection by running elevated, enterprise environments that do not grant their users the ability to run downloaded files as Administrator are particularly helped by this protection - malware cannot simply request elevation privilege in these environments and is forced to use techniques such as injection that can be more easily detected by endpoint agents. </p> <p> App-Bound Encryption strongly binds the encryption key to the machine, so will not function correctly in environments where Chrome profiles roam between multiple machines. We encourage enterprises who wish to support roaming profiles to follow current <a href="https://support.google.com/chrome/a/answer/7349337">best practices</a>. If it becomes necessary, App-Bound encryption can be configured using the new <a href="https://chromeenterprise.google/policies/#ApplicationBoundEncryptionEnabled">ApplicationBoundEncryptionEnabled</a> policy. </p> <p> To further help detect any incompatibilities, Chrome emits an event when a failed verification occurs. The Event is ID 257 from 'Chrome' source in the Application log. </p> <p> <strong>Conclusion</strong> </p> <p> App-Bound Encryption increases the cost of data theft to attackers and also makes their actions far noisier on the system. It helps defenders draw a clear line in the sand for what is acceptable behavior for other apps on the system. As the malware landscape continually evolves we are keen to continue engaging with others in the security community on improving detections and strengthening operating system protections, such as stronger app isolation primitives, for any bypasses. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by Will Harris, Chrome Security Team</span> <p> Cybercriminals using cookie theft <a href="https://cloud.google.com/blog/products/identity-security/a-year-in-the-cybersecurity-trenches-with-mandiant-managed-defense">infostealer</a> malware continue to pose a risk to the safety and security of our users. We already have a number of initiatives in this area including <a href="https://security.googleblog.com/2024/07/building-security-into-redesigned.html">Chrome’s download protection</a> using Safe Browsing, <a href="https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html">Device Bound Session Credentials</a>, and Google’s account-based threat detection to flag the use of stolen cookies. Today, we’re announcing another layer of protection to make Windows users safer from this type of malware. </p> <p> Like other software that needs to store secrets, Chrome currently secures sensitive data like cookies and passwords using the strongest techniques the OS makes available to us - on macOS this is the <a href="https://developer.apple.com/documentation/security/keychain_services/">Keychain services</a>, and on Linux we use a system provided wallet such as kwallet or gnome-libsecret. On Windows, Chrome uses the Data Protection API (DPAPI) which protects the data at rest from other users on the system or cold boot attacks. However, the DPAPI does not protect against malicious applications able to execute code as the logged in user - which infostealers take advantage of. </p> <p> In Chrome 127 we are introducing a new protection on Windows that improves on the DPAPI by providing <strong>Application-Bound (App-Bound) </strong>Encryption primitives. Rather than allowing any app running as the logged in user to access this data, Chrome can now encrypt data tied to app identity, similar to how the Keychain operates on macOS. </p> <p> We will be migrating each type of secret to this new system starting with cookies in Chrome 127. In future releases we intend to expand this protection to passwords, payment data, and other persistent authentication tokens, further protecting users from infostealer malware. </p> <p> <strong>How it works</strong> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpjkAClX2VvgsIhLi2zAmvRwVMPEeJqUhqisKHIKxbfGAwh8p8-V7Ixct5azzn_jYfJYo2izWnGcbkVh3cabbCLVQQQsJAJagvFPCFJsx4MibauJqnLVymQYdhdGGc53q3wSJSeTPQ6vyxXosJ-tJRKuaaoV7_J_E2KB9glSZ1m3NSEwEBj-duevgROHlM/s1416/Screenshot%202024-07-26%202.15.06%20PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="919" data-original-width="1416" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpjkAClX2VvgsIhLi2zAmvRwVMPEeJqUhqisKHIKxbfGAwh8p8-V7Ixct5azzn_jYfJYo2izWnGcbkVh3cabbCLVQQQsJAJagvFPCFJsx4MibauJqnLVymQYdhdGGc53q3wSJSeTPQ6vyxXosJ-tJRKuaaoV7_J_E2KB9glSZ1m3NSEwEBj-duevgROHlM/s16000/Screenshot%202024-07-26%202.15.06%20PM.png" /></a></div><p> App-Bound Encryption relies on a privileged service to verify the identity of the requesting application. During encryption, the App-Bound Encryption service encodes the app's identity into the encrypted data, and then verifies this is valid when decryption is attempted. If another app on the system tries to decrypt the same data, it will fail. </p> <p> Because the App-Bound service is running with system privileges, attackers need to do more than just coax a user into running a malicious app. Now, the malware has to gain system privileges, or inject code into Chrome, something that legitimate software shouldn't be doing. This makes their actions more suspicious to antivirus software – and more likely to be detected. Our other recent initiatives such as providing <a href="https://security.googleblog.com/2024/04/detecting-browser-data-theft-using.html">event logs</a> for cookie decryption work in tandem with this protection, with the goal of further increasing the cost and risk of detection to attackers attempting to steal user data. </p> <p> <strong>Enterprise Considerations</strong> </p> <p> Since malware can bypass this protection by running elevated, enterprise environments that do not grant their users the ability to run downloaded files as Administrator are particularly helped by this protection - malware cannot simply request elevation privilege in these environments and is forced to use techniques such as injection that can be more easily detected by endpoint agents. </p> <p> App-Bound Encryption strongly binds the encryption key to the machine, so will not function correctly in environments where Chrome profiles roam between multiple machines. We encourage enterprises who wish to support roaming profiles to follow current <a href="https://support.google.com/chrome/a/answer/7349337">best practices</a>. If it becomes necessary, App-Bound encryption can be configured using the new <a href="https://chromeenterprise.google/policies/#ApplicationBoundEncryptionEnabled">ApplicationBoundEncryptionEnabled</a> policy. </p> <p> To further help detect any incompatibilities, Chrome emits an event when a failed verification occurs. The Event is ID 257 from 'Chrome' source in the Application log. </p> <p> <strong>Conclusion</strong> </p> <p> App-Bound Encryption increases the cost of data theft to attackers and also makes their actions far noisier on the system. It helps defenders draw a clear line in the sand for what is acceptable behavior for other apps on the system. As the malware landscape continually evolves we are keen to continue engaging with others in the security community on improving detections and strengthening operating system protections, such as stronger app isolation primitives, for any bypasses. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Improving the security of Chrome cookies on Windows&url=https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html' data-url='https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='50103144824717859' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html' itemprop='url' title='Making Chrome more secure by bringing Key Pinning to Android'> Making Chrome more secure by bringing Key Pinning to Android </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> August 10, 2023 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by David Adrian, Joe DeBlasio and Carlos Joan Rafael Ibarra Lopez, Chrome Security</span> <p> Chrome 106 added support for enforcing key pins on Android by default, bringing Android to parity with Chrome on desktop platforms. But what is key pinning anyway? </p> <p> One of the reasons Chrome implements key pinning is the “<a href="https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md">rule of two</a>”. This rule is part of Chrome’s holistic secure development <a href="https://security.googleblog.com/2023/07/a-look-at-chromes-security-review.html">process</a>. It says that when you are writing code for Chrome, you can pick no more than two of: code written in an unsafe language, processing untrustworthy inputs, and running without a sandbox. This blog post explains how key pinning and the rule of two are related. </p> <p> <strong>The Rule of Two</strong> </p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkMCAZIV-7_1mjIhy60O5r_rMLsVIuYaojpukxs79U78aJZyMLGyIIA_0B_Ead2UNrzer1ij6etVoV9wuLzih5Izndu44rd-HEyOh3SsSEc1CKLfqaTxp43UJDewbIIbVdO2HLmQM10BlFpljOOCBxlDw0rPf-zA1BhRrxoO74ZHgcJB2lmb15Hbg78aJB/s1600/image1.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="450" data-original-width="600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkMCAZIV-7_1mjIhy60O5r_rMLsVIuYaojpukxs79U78aJZyMLGyIIA_0B_Ead2UNrzer1ij6etVoV9wuLzih5Izndu44rd-HEyOh3SsSEc1CKLfqaTxp43UJDewbIIbVdO2HLmQM10BlFpljOOCBxlDw0rPf-zA1BhRrxoO74ZHgcJB2lmb15Hbg78aJB/s1600/image1.png"/></a></div> <p> Chrome is primarily written in the C and C++ languages, which are vulnerable to memory safety bugs. Mistakes with pointers in these languages can lead to memory being misinterpreted. Chrome invests in an ever-stronger multi-process architecture built on sandboxing and site isolation to help defend against memory safety problems. Android-specific features can be written in Java or Kotlin. These languages are memory-safe in the common case. Similarly, we’re working on adding support to <a href="https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html">write Chrome code in Rust</a>, which is also memory-safe. </p> <p> Much of Chrome is <a href="https://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html">sandboxed</a>, but the sandbox still requires a core high-privilege “broker” process to coordinate communication and launch sandboxed processes. In Chrome, the broker is the <a href="https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/design/sandbox.md">browser process</a>. The browser process is the source of truth that allows the rest of Chrome to be sandboxed and coordinates communication between the rest of the processes. </p> <p> If an attacker is able to craft a malicious input to the browser process that exploits a bug and allows the attacker to achieve remote code execution (RCE) in the browser process, that would effectively give the attacker full control of the victim’s Chrome browser and potentially the rest of the device. Conversely, if an attacker achieves RCE in a sandboxed process, such as a renderer, the attacker's capabilities are extremely limited. The attacker cannot reach outside of the sandbox unless they can additionally exploit the sandbox itself. </p> <p> Without sandboxing, which limits the actions an attacker can take, and without memory safety, which removes the ability of a bug to disrupt the intended control flow of the program, the rule of two requires that the browser process does not handle untrustworthy inputs. The relative risks between sandboxed processes and the browser process are why the browser process is only allowed to parse trustworthy inputs and specific IPC messages. </p> <p> Trustworthy inputs are defined extremely strictly: A “trustworthy source” means that Chrome can prove that the data comes from Google. Effectively, this means that in situations where the browser process needs access to data from external sources, it must be read from Google servers. We can cryptographically prove that data came from Google servers if that data comes from: </p> <ul> <li>The <a href="https://chromium.googlesource.com/chromium/src/+/lkgr/components/component_updater/README.md">component updater</a> (Omaha) <li>The <a href="https://developer.chrome.com/docs/web-platform/chrome-variations/">variations framework</a> (Finch) <li>A pinned HTTPS server </li> </ul> <p> The component updater and the variations framework are services specific to Chrome used to ship data-only updates and configuration information. These services both use asymmetric cryptography to authenticate their data, and the public key used to verify data sent by these services is shipped in Chrome. </p> <p> However, Chrome is a feature-filled browser with many different use cases, and many different features beyond just updating itself. Certain features, such as Sign-In and the Discover Feed, need to communicate with Google. For features like this, that communication can be considered trustworthy if it comes from a pinned HTTPS server. </p> <p> When Chrome connects to an HTTPS server, the server says “a 3rd party you trust (a certification authority; CA) has vouched for my identity.” It does this by presenting a certificate issued by a trusted certification authority. Chrome verifies the certificate before continuing. The modern web necessarily has a lot of CAs, all of whom can provide authentication for any website. To further ensure that the Chrome browser process is communicating with a trustworthy Google server we want to verify something more: whether a <em>specific</em> CA is vouching for the server. We do this by building a map of sites → expected CAs directly into Chrome. We call this <em>key pinning</em>. We call the map the <em>pin set</em>. </p> <p> <strong>What is Key Pinning?</strong> </p> <p> Key pinning was born as a defense against real attacks seen in the wild: attackers who can trick a CA to issue a seemingly-valid certificate for a server, and then the attacker can impersonate that server. This <a href="https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html">happened to Google</a> in 2011, when the DigiNotar certification authority was compromised and used to issue malicious certificates for Google services. To defend against this risk, Chrome contains a pin set for all Google properties, and we only consider an HTTPS input trustworthy if it’s authenticated using a key in this pin set. This protects against malicious certificate issuance by third parties. </p> <p> Key pinning can be brittle, and is rarely worth the risks. Allowing the pin set to get out of date can lead to locking users out of a website or other services, potentially permanently. Whenever pinning, it’s important to have safety-valves such as not enforcing pinning (i.e. failing open) when the pins haven't been updated recently, including a “backup” key pin, and having fallback mechanisms for bootstrapping. It's hard for individual sites to manage all of these mechanisms, which is why <a href="https://datatracker.ietf.org/doc/html/rfc7469">dynamic pinning over HTTPS (HPKP)</a> was <a href="https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMwKPmUBAAJ">deprecated</a>. Key pinning is still an important tool for some use cases, however, where there's high-privilege communication that needs to happen between a client and server that are operated by the same entity, such as web browsers, automatic software updates, and package managers. </p> <p> <strong>Security Benefits of Key Pinning in Chrome, Now on Android</strong> </p> <p> By pinning in Chrome, we can protect users from CA compromise. We take steps to prevent an out-of-date pinset from unnecessarily blocking users from accessing Google or Google's services. As both a browser vendor and site operator, however, we have additional tools to ensure we keep our pin sets up to date—if we use a new key or a new domain, we can add it to the pin set in Chrome at the same time. In our original implementation of pinning, the pin set is directly compiled into Chrome and updating the pin set requires updating the entire Chrome binary. To make sure that users of old versions of Chrome can still talk to Google, pinning isn't enforced if Chrome detects that it is more than 10 weeks old. </p> <p> Historically, Chrome enforced the age limit by comparing the current time to the build timestamp in the Chrome binary. Chrome did not enforce pinning on Android because the build timestamp on Android wasn’t always reflective of the age of the Chrome pinset, which meant that the chance of a false positive pin mismatch was higher. </p> <p> Without enforcing pins on Android, Chrome was limiting the ways engineers could build features that comply with the rule of two. To remove this limitation, we built an improved mechanism for distributing the built-in pin set to Chrome installs, including Android devices. Chrome still contains a built-in pin set compiled into the binary. However, we now additionally distribute the pin set via the component updater, which is a mechanism for Chrome to dynamically push out data-only updates to all Chrome installs without requiring a full Chrome update or restart. The component contains the latest version of the built-in pin set, as well as the certificate transparency log list and the contents of the <a href="https://g.co/chrome/root-policy">Chrome Root Store</a>. This means that even if Chrome is out of date, it can still receive updates to the pin set. The component also includes the timestamp the pin list was last updated, rather than relying on build timestamp.<strong> </strong>This drastically reduces the false positive risk of enabling key pinning on Android. </p> <p> After we moved the pin set to component updater, we were able to do a slow rollout of pinning enforcement on Android. We determined that the false positive risk was now in line with desktop platforms, and enabled key pinning enforcement by default since Chrome 106, released in September 2022. </p> <p> This change has been entirely invisible to users of Chrome. While not all of the changes we make in Chrome are flashy, we're constantly working behind the scenes to keep Chrome as secure as possible and we're excited to bring this protection to Android. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by David Adrian, Joe DeBlasio and Carlos Joan Rafael Ibarra Lopez, Chrome Security</span> <p> Chrome 106 added support for enforcing key pins on Android by default, bringing Android to parity with Chrome on desktop platforms. But what is key pinning anyway? </p> <p> One of the reasons Chrome implements key pinning is the “<a href="https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md">rule of two</a>”. This rule is part of Chrome’s holistic secure development <a href="https://security.googleblog.com/2023/07/a-look-at-chromes-security-review.html">process</a>. It says that when you are writing code for Chrome, you can pick no more than two of: code written in an unsafe language, processing untrustworthy inputs, and running without a sandbox. This blog post explains how key pinning and the rule of two are related. </p> <p> <strong>The Rule of Two</strong> </p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkMCAZIV-7_1mjIhy60O5r_rMLsVIuYaojpukxs79U78aJZyMLGyIIA_0B_Ead2UNrzer1ij6etVoV9wuLzih5Izndu44rd-HEyOh3SsSEc1CKLfqaTxp43UJDewbIIbVdO2HLmQM10BlFpljOOCBxlDw0rPf-zA1BhRrxoO74ZHgcJB2lmb15Hbg78aJB/s1600/image1.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="450" data-original-width="600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkMCAZIV-7_1mjIhy60O5r_rMLsVIuYaojpukxs79U78aJZyMLGyIIA_0B_Ead2UNrzer1ij6etVoV9wuLzih5Izndu44rd-HEyOh3SsSEc1CKLfqaTxp43UJDewbIIbVdO2HLmQM10BlFpljOOCBxlDw0rPf-zA1BhRrxoO74ZHgcJB2lmb15Hbg78aJB/s1600/image1.png"/></a></div> <p> Chrome is primarily written in the C and C++ languages, which are vulnerable to memory safety bugs. Mistakes with pointers in these languages can lead to memory being misinterpreted. Chrome invests in an ever-stronger multi-process architecture built on sandboxing and site isolation to help defend against memory safety problems. Android-specific features can be written in Java or Kotlin. These languages are memory-safe in the common case. Similarly, we’re working on adding support to <a href="https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html">write Chrome code in Rust</a>, which is also memory-safe. </p> <p> Much of Chrome is <a href="https://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html">sandboxed</a>, but the sandbox still requires a core high-privilege “broker” process to coordinate communication and launch sandboxed processes. In Chrome, the broker is the <a href="https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/design/sandbox.md">browser process</a>. The browser process is the source of truth that allows the rest of Chrome to be sandboxed and coordinates communication between the rest of the processes. </p> <p> If an attacker is able to craft a malicious input to the browser process that exploits a bug and allows the attacker to achieve remote code execution (RCE) in the browser process, that would effectively give the attacker full control of the victim’s Chrome browser and potentially the rest of the device. Conversely, if an attacker achieves RCE in a sandboxed process, such as a renderer, the attacker's capabilities are extremely limited. The attacker cannot reach outside of the sandbox unless they can additionally exploit the sandbox itself. </p> <p> Without sandboxing, which limits the actions an attacker can take, and without memory safety, which removes the ability of a bug to disrupt the intended control flow of the program, the rule of two requires that the browser process does not handle untrustworthy inputs. The relative risks between sandboxed processes and the browser process are why the browser process is only allowed to parse trustworthy inputs and specific IPC messages. </p> <p> Trustworthy inputs are defined extremely strictly: A “trustworthy source” means that Chrome can prove that the data comes from Google. Effectively, this means that in situations where the browser process needs access to data from external sources, it must be read from Google servers. We can cryptographically prove that data came from Google servers if that data comes from: </p> <ul> <li>The <a href="https://chromium.googlesource.com/chromium/src/+/lkgr/components/component_updater/README.md">component updater</a> (Omaha) <li>The <a href="https://developer.chrome.com/docs/web-platform/chrome-variations/">variations framework</a> (Finch) <li>A pinned HTTPS server </li> </ul> <p> The component updater and the variations framework are services specific to Chrome used to ship data-only updates and configuration information. These services both use asymmetric cryptography to authenticate their data, and the public key used to verify data sent by these services is shipped in Chrome. </p> <p> However, Chrome is a feature-filled browser with many different use cases, and many different features beyond just updating itself. Certain features, such as Sign-In and the Discover Feed, need to communicate with Google. For features like this, that communication can be considered trustworthy if it comes from a pinned HTTPS server. </p> <p> When Chrome connects to an HTTPS server, the server says “a 3rd party you trust (a certification authority; CA) has vouched for my identity.” It does this by presenting a certificate issued by a trusted certification authority. Chrome verifies the certificate before continuing. The modern web necessarily has a lot of CAs, all of whom can provide authentication for any website. To further ensure that the Chrome browser process is communicating with a trustworthy Google server we want to verify something more: whether a <em>specific</em> CA is vouching for the server. We do this by building a map of sites → expected CAs directly into Chrome. We call this <em>key pinning</em>. We call the map the <em>pin set</em>. </p> <p> <strong>What is Key Pinning?</strong> </p> <p> Key pinning was born as a defense against real attacks seen in the wild: attackers who can trick a CA to issue a seemingly-valid certificate for a server, and then the attacker can impersonate that server. This <a href="https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html">happened to Google</a> in 2011, when the DigiNotar certification authority was compromised and used to issue malicious certificates for Google services. To defend against this risk, Chrome contains a pin set for all Google properties, and we only consider an HTTPS input trustworthy if it’s authenticated using a key in this pin set. This protects against malicious certificate issuance by third parties. </p> <p> Key pinning can be brittle, and is rarely worth the risks. Allowing the pin set to get out of date can lead to locking users out of a website or other services, potentially permanently. Whenever pinning, it’s important to have safety-valves such as not enforcing pinning (i.e. failing open) when the pins haven't been updated recently, including a “backup” key pin, and having fallback mechanisms for bootstrapping. It's hard for individual sites to manage all of these mechanisms, which is why <a href="https://datatracker.ietf.org/doc/html/rfc7469">dynamic pinning over HTTPS (HPKP)</a> was <a href="https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMwKPmUBAAJ">deprecated</a>. Key pinning is still an important tool for some use cases, however, where there's high-privilege communication that needs to happen between a client and server that are operated by the same entity, such as web browsers, automatic software updates, and package managers. </p> <p> <strong>Security Benefits of Key Pinning in Chrome, Now on Android</strong> </p> <p> By pinning in Chrome, we can protect users from CA compromise. We take steps to prevent an out-of-date pinset from unnecessarily blocking users from accessing Google or Google's services. As both a browser vendor and site operator, however, we have additional tools to ensure we keep our pin sets up to date—if we use a new key or a new domain, we can add it to the pin set in Chrome at the same time. In our original implementation of pinning, the pin set is directly compiled into Chrome and updating the pin set requires updating the entire Chrome binary. To make sure that users of old versions of Chrome can still talk to Google, pinning isn't enforced if Chrome detects that it is more than 10 weeks old. </p> <p> Historically, Chrome enforced the age limit by comparing the current time to the build timestamp in the Chrome binary. Chrome did not enforce pinning on Android because the build timestamp on Android wasn’t always reflective of the age of the Chrome pinset, which meant that the chance of a false positive pin mismatch was higher. </p> <p> Without enforcing pins on Android, Chrome was limiting the ways engineers could build features that comply with the rule of two. To remove this limitation, we built an improved mechanism for distributing the built-in pin set to Chrome installs, including Android devices. Chrome still contains a built-in pin set compiled into the binary. However, we now additionally distribute the pin set via the component updater, which is a mechanism for Chrome to dynamically push out data-only updates to all Chrome installs without requiring a full Chrome update or restart. The component contains the latest version of the built-in pin set, as well as the certificate transparency log list and the contents of the <a href="https://g.co/chrome/root-policy">Chrome Root Store</a>. This means that even if Chrome is out of date, it can still receive updates to the pin set. The component also includes the timestamp the pin list was last updated, rather than relying on build timestamp.<strong> </strong>This drastically reduces the false positive risk of enabling key pinning on Android. </p> <p> After we moved the pin set to component updater, we were able to do a slow rollout of pinning enforcement on Android. We determined that the false positive risk was now in line with desktop platforms, and enabled key pinning enforcement by default since Chrome 106, released in September 2022. </p> <p> This change has been entirely invisible to users of Chrome. While not all of the changes we make in Chrome are flashy, we're constantly working behind the scenes to keep Chrome as secure as possible and we're excited to bring this protection to Android. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Making Chrome more secure by bringing Key Pinning to Android&url=https://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html' data-url='https://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='4130886266134219591' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2023/08/an-update-on-chrome-security-updates.html' itemprop='url' title='An update on Chrome Security updates – shipping security fixes to you faster'> An update on Chrome Security updates – shipping security fixes to you faster </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> August 8, 2023 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Amy Ressler, Chrome Security Team</span> <p> To get security fixes to you faster, starting now in Chrome 116, Chrome is shipping weekly Stable channel updates. </p> <p> Chrome ships a new milestone release <a href="https://chromiumdash.appspot.com/schedule">every four weeks</a>. In between those major releases, we ship updates to address security and other high impact bugs. We currently schedule one of these Stable channel updates (or “<em>Stable Refresh</em>”) between each milestone. Starting in Chrome 116, Stable updates will be released every week between milestones. </p> <p> This should not change how you use or update Chrome, nor is the frequency of milestone releases changing, but it does mean security fixes will get to you faster. </p> <h3>Reducing the Patch Gap</h3> <p> <a href="https://www.chromium.org/Home/">Chromium</a> is the open source project which powers Chrome and many other browsers. Anyone can view the <a href="https://source.chromium.org/">source code</a>, submit changes for review, and see the changes made by anyone else, even security bug fixes. Users of our Canary (and Beta) channels receive those fixes and can sometimes give us early warning of unexpected stability, compatibility, or performance problems in advance of the fix reaching the Stable channel. </p> <p> This openness has benefits in testing fixes and discovering bugs, but comes at a cost: bad actors could possibly take advantage of the visibility into these fixes and develop exploits to apply against browser users who haven’t yet received the fix. This exploitation of a known and patched security issue is referred to as n-day exploitation. </p> <p> That’s why we believe it’s really important to ship security fixes as soon as possible, to minimize this “patch gap”. </p> <p> When a Chrome security bug is fixed, the fix is <em>landed</em> in the public Chromium source code repository. The fix is then publicly accessible and discoverable. After the patch is landed, individuals across Chrome are working to test and verify the patch, and evaluate security bug fixes for backporting to affected release branches. Security fixes impacting Stable channel then await the next Stable channel update once they have been backported. The time between the patch being landed and shipped in a Stable channel update is the patch gap. </p> <p> Chrome began releasing Stable channel updates every two weeks in 2020, with Chrome 77, as a way to help reduce the patch gap. Before Chrome 77, our patch gap averaged 35 days. Since moving the biweekly release cadence, the patch gap has been reduced to around 15 days. The switch to weekly updates allows us to ship security fixes even faster, and further reduce the patch gap. </p> <p> While we can’t fully remove the potential for n-day exploitation, a weekly Chrome security update cadence allows up to ship security fixes 3.5 days sooner on average, <em>greatly reducing </em>the already small window for n-day attackers to develop and use an exploit against potential victims and making their lives much more difficult. </p> <h3>Getting Fixes to You Faster</h3> <p> Not all security bug fixes are used for n-day exploitation. But we don’t know which bugs are exploited in practice, and which aren't, so we treat all critical and high severity bugs as if they will be exploited. A lot of work goes into making sure these bugs get triaged and fixed as soon as possible. Rather than having fixes sitting and waiting to be included in the next bi-weekly update, weekly updates will allow us to get important security bug fixes to you sooner, and better protect you and your most sensitive data. </p> <h3>Reducing Unplanned Updates</h3> <p> As always, we treat any Chrome bug with a <a href="https://www.youtube.com/watch?v=VN-3-ov8uMM">known in-the-wild exploit as a security incident of the highest priority</a> and set about fixing the bug and getting a fix out to users as soon as possible. This has meant shipping the fix in an unscheduled update, so that you are protected immediately. By now shipping stable updates weekly, we expect the number of unplanned updates to decrease since we’ll be shipping updates more frequently. </p> <h3>What You Can Do</h3> <p> Keep a lookout for notifications from your desktop or mobile device letting you know an <a href="https://www.google.com/chrome/update/">update of Chrome is available</a>. If an update is available, please update immediately each time! </p> <p> If you are concerned that updating Chrome will interrupt your work or result in lost tabs, not to worry – when relaunching Chrome to update, <a href="https://support.google.com/chrome/answer/95414">your open tabs and windows are saved</a> and Chrome re-opens them after restart. If you are browsing in Incognito mode, your tabs will not be saved. You can simply choose to delay restarting by selecting <strong>Not now</strong>, and the updates will be applied the next time you restart Chrome. </p> <p> We are exploring improved ways of informing you a new Chrome update is available. Keep a lookout for these new notifications which have been rolled out for Stable experimentation to 1% of users. </p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7DXfKiWJIcqdFBvPlg_ZGnnR6qrzIsunDS_IlkClc1TpP_4oXJxAtDjcrE2AL-ommP_5Yn_2MEGT0xta9ycIOZu1SBOM4xhCfzfS-t9i8dzKTTzJ_cxBcnO3xyu7K5uQbhoAYex6VTiyG0p_urQjVx-QksmAMrzJGeggIO8RO3KAgYuoGaxzGOTBMVD6z/s1600/Screenshot%202023-08-07%2010.25.24%20PM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="149" data-original-width="742" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7DXfKiWJIcqdFBvPlg_ZGnnR6qrzIsunDS_IlkClc1TpP_4oXJxAtDjcrE2AL-ommP_5Yn_2MEGT0xta9ycIOZu1SBOM4xhCfzfS-t9i8dzKTTzJ_cxBcnO3xyu7K5uQbhoAYex6VTiyG0p_urQjVx-QksmAMrzJGeggIO8RO3KAgYuoGaxzGOTBMVD6z/s1600/Screenshot%202023-08-07%2010.25.24%20PM.png"/></a></div> <p> Other Chromium-based browsers have varying patch gaps. Chrome does not control the update cadence of other Chromium browsers. The change described here is only applicable to Chrome. If you are using other Chromium browsers, you may want to explore the security update cadence of those browsers. </p> <p> The rest is on us – with this change we’re dedicated to continuing to work to get security fixes to you as fast as possible. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by Amy Ressler, Chrome Security Team</span> <p> To get security fixes to you faster, starting now in Chrome 116, Chrome is shipping weekly Stable channel updates. </p> <p> Chrome ships a new milestone release <a href="https://chromiumdash.appspot.com/schedule">every four weeks</a>. In between those major releases, we ship updates to address security and other high impact bugs. We currently schedule one of these Stable channel updates (or “<em>Stable Refresh</em>”) between each milestone. Starting in Chrome 116, Stable updates will be released every week between milestones. </p> <p> This should not change how you use or update Chrome, nor is the frequency of milestone releases changing, but it does mean security fixes will get to you faster. </p> <h3>Reducing the Patch Gap</h3> <p> <a href="https://www.chromium.org/Home/">Chromium</a> is the open source project which powers Chrome and many other browsers. Anyone can view the <a href="https://source.chromium.org/">source code</a>, submit changes for review, and see the changes made by anyone else, even security bug fixes. Users of our Canary (and Beta) channels receive those fixes and can sometimes give us early warning of unexpected stability, compatibility, or performance problems in advance of the fix reaching the Stable channel. </p> <p> This openness has benefits in testing fixes and discovering bugs, but comes at a cost: bad actors could possibly take advantage of the visibility into these fixes and develop exploits to apply against browser users who haven’t yet received the fix. This exploitation of a known and patched security issue is referred to as n-day exploitation. </p> <p> That’s why we believe it’s really important to ship security fixes as soon as possible, to minimize this “patch gap”. </p> <p> When a Chrome security bug is fixed, the fix is <em>landed</em> in the public Chromium source code repository. The fix is then publicly accessible and discoverable. After the patch is landed, individuals across Chrome are working to test and verify the patch, and evaluate security bug fixes for backporting to affected release branches. Security fixes impacting Stable channel then await the next Stable channel update once they have been backported. The time between the patch being landed and shipped in a Stable channel update is the patch gap. </p> <p> Chrome began releasing Stable channel updates every two weeks in 2020, with Chrome 77, as a way to help reduce the patch gap. Before Chrome 77, our patch gap averaged 35 days. Since moving the biweekly release cadence, the patch gap has been reduced to around 15 days. The switch to weekly updates allows us to ship security fixes even faster, and further reduce the patch gap. </p> <p> While we can’t fully remove the potential for n-day exploitation, a weekly Chrome security update cadence allows up to ship security fixes 3.5 days sooner on average, <em>greatly reducing </em>the already small window for n-day attackers to develop and use an exploit against potential victims and making their lives much more difficult. </p> <h3>Getting Fixes to You Faster</h3> <p> Not all security bug fixes are used for n-day exploitation. But we don’t know which bugs are exploited in practice, and which aren't, so we treat all critical and high severity bugs as if they will be exploited. A lot of work goes into making sure these bugs get triaged and fixed as soon as possible. Rather than having fixes sitting and waiting to be included in the next bi-weekly update, weekly updates will allow us to get important security bug fixes to you sooner, and better protect you and your most sensitive data. </p> <h3>Reducing Unplanned Updates</h3> <p> As always, we treat any Chrome bug with a <a href="https://www.youtube.com/watch?v=VN-3-ov8uMM">known in-the-wild exploit as a security incident of the highest priority</a> and set about fixing the bug and getting a fix out to users as soon as possible. This has meant shipping the fix in an unscheduled update, so that you are protected immediately. By now shipping stable updates weekly, we expect the number of unplanned updates to decrease since we’ll be shipping updates more frequently. </p> <h3>What You Can Do</h3> <p> Keep a lookout for notifications from your desktop or mobile device letting you know an <a href="https://www.google.com/chrome/update/">update of Chrome is available</a>. If an update is available, please update immediately each time! </p> <p> If you are concerned that updating Chrome will interrupt your work or result in lost tabs, not to worry – when relaunching Chrome to update, <a href="https://support.google.com/chrome/answer/95414">your open tabs and windows are saved</a> and Chrome re-opens them after restart. If you are browsing in Incognito mode, your tabs will not be saved. You can simply choose to delay restarting by selecting <strong>Not now</strong>, and the updates will be applied the next time you restart Chrome. </p> <p> We are exploring improved ways of informing you a new Chrome update is available. Keep a lookout for these new notifications which have been rolled out for Stable experimentation to 1% of users. </p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7DXfKiWJIcqdFBvPlg_ZGnnR6qrzIsunDS_IlkClc1TpP_4oXJxAtDjcrE2AL-ommP_5Yn_2MEGT0xta9ycIOZu1SBOM4xhCfzfS-t9i8dzKTTzJ_cxBcnO3xyu7K5uQbhoAYex6VTiyG0p_urQjVx-QksmAMrzJGeggIO8RO3KAgYuoGaxzGOTBMVD6z/s1600/Screenshot%202023-08-07%2010.25.24%20PM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="149" data-original-width="742" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7DXfKiWJIcqdFBvPlg_ZGnnR6qrzIsunDS_IlkClc1TpP_4oXJxAtDjcrE2AL-ommP_5Yn_2MEGT0xta9ycIOZu1SBOM4xhCfzfS-t9i8dzKTTzJ_cxBcnO3xyu7K5uQbhoAYex6VTiyG0p_urQjVx-QksmAMrzJGeggIO8RO3KAgYuoGaxzGOTBMVD6z/s1600/Screenshot%202023-08-07%2010.25.24%20PM.png"/></a></div> <p> Other Chromium-based browsers have varying patch gaps. Chrome does not control the update cadence of other Chromium browsers. The change described here is only applicable to Chrome. If you are using other Chromium browsers, you may want to explore the security update cadence of those browsers. </p> <p> The rest is on us – with this change we’re dedicated to continuing to work to get security fixes to you as fast as possible. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:An update on Chrome Security updates – shipping security fixes to you faster&url=https://security.googleblog.com/2023/08/an-update-on-chrome-security-updates.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2023/08/an-update-on-chrome-security-updates.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2023/08/an-update-on-chrome-security-updates.html' data-url='https://security.googleblog.com/2023/08/an-update-on-chrome-security-updates.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2023/08/an-update-on-chrome-security-updates.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='4913282074145799445' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2023/06/protect-and-manage-browser-extensions.html' itemprop='url' title='Protect and manage browser extensions using Chrome Browser Cloud Management'> Protect and manage browser extensions using Chrome Browser Cloud Management </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> June 20, 2023 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Anuj Goyal, Product Manager, Chrome Browser</span><p> Browser extensions, while offering valuable functionalities, can seem risky to organizations. One major concern is the potential for security vulnerabilities. Poorly designed or malicious extensions could compromise data integrity and expose sensitive information to unauthorized access. Moreover, certain extensions may introduce performance issues or conflicts with other software, leading to system instability. Therefore, many organizations find it crucial to have visibility into the usage of extensions and the ability to control them. Chrome browser offers these extension management capabilities and reporting via <a href="https://chromeenterprise.google/browser/management/">Chrome Browser Cloud Management</a>. In this blog post, we will walk you through how to utilize these features to keep your data and users safe. </p> <p> <strong>Visibility into Extensions being used in your environment</strong> </p> <p> Having visibility into what and how extensions are being used enables IT and security teams to assess potential security implications, ensure compliance with organizational policies, and mitigate potential risks. There are three ways you can get critical information about extensions in your organization:</p><p>1. <a href="https://support.google.com/chrome/a/answer/9902456?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">App and extension usage reporting</a><br /><br />Organizations can gain visibility into every Chrome extension that is installed across an enterprise’s fleet in <a href="https://support.google.com/chrome/a/answer/10836225?hl=en">Chrome App and Extension Usage Reporting</a>.<br /><br />2. <a href="https://cloud.google.com/blog/products/chrome-enterprise/secure-enterprise-browsing-more-data-protections-visibility-and-insights" style="font-weight: bold;">Extension Risk Assessment</a><br /><br />CRXcavator and Spin.AI Risk Assessment are tools used to assess the risks of browser extensions and minimize the risks associated with them. We are making extension scores via these two platforms available directly in Chrome Browser Cloud Management, so security teams can have an at-a-glance view of risk scores of the extensions being used in their browser environment.</p> <p> </p><div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2y_MUYbD67bgvLv3qfIYnviVa6lTnd5Hly6R3XMQ8TBvDCtaQF5Gn3GwboTUCLSyG2xh7dzxcSQFeSPQW_L2h1-GYHjEaWvykP8o2gX17mOLhLyo1t-wZvbf84fXQYcCqwYQLHG7xnar-_qD0Q0lpC-lnbiwf2u5WTM098AtZXoEil6Zt0Dd-LxPfw5HC/s1600/extension%201.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="268" data-original-width="900" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2y_MUYbD67bgvLv3qfIYnviVa6lTnd5Hly6R3XMQ8TBvDCtaQF5Gn3GwboTUCLSyG2xh7dzxcSQFeSPQW_L2h1-GYHjEaWvykP8o2gX17mOLhLyo1t-wZvbf84fXQYcCqwYQLHG7xnar-_qD0Q0lpC-lnbiwf2u5WTM098AtZXoEil6Zt0Dd-LxPfw5HC/s1600/extension%201.png" /><strong style="text-align: left;"></strong></a><span style="text-align: left;"><b>3. </b><a href="https://support.google.com/chrome/a/answer/11375053?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">Extension event reporting</a><b><br /></b></span><b><br /></b>Extension installs events are now available to alert IT and security teams of new extension usage in their environment.<br /><br />Organizations can send critical browser security events to their chosen solution providers, such as Splunk, Crowdstrike, Palo Alto Networks, and Google solutions, including Chronicle, Cloud PubSub, and Google Workspace, for further analysis. You can also view the event logs directly in Chrome Browser Cloud Management.<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrNWm-UMe_Tsz3SCwGx_cBVteyqePjWntU7Vm0CgVV_tTjC8WFDb5zPcLEFiGpJM53nqltaAXTEk4VmpKqfS2i3hacbbvB26ihM3eyH6fexxBb3wg9TfS_GsxBFzm94kHNxbAE27R69g_7gt_KfdHTbEtlZ1fWgoy7dG6RGB1J8jPMSbMwOW3JzSzyb-LR/s1600/extension%202.png" style="display: inline !important; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="975" data-original-width="912" height="734" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrNWm-UMe_Tsz3SCwGx_cBVteyqePjWntU7Vm0CgVV_tTjC8WFDb5zPcLEFiGpJM53nqltaAXTEk4VmpKqfS2i3hacbbvB26ihM3eyH6fexxBb3wg9TfS_GsxBFzm94kHNxbAE27R69g_7gt_KfdHTbEtlZ1fWgoy7dG6RGB1J8jPMSbMwOW3JzSzyb-LR/w687-h734/extension%202.png" width="687" /></a></div> <p></p> <p> <strong>Extension controls for added security </strong> </p> <p> By having control over extensions, organizations can maintain a secure and stable browsing environment, safeguard sensitive data, and protect their overall digital infrastructure. There are several ways IT and security teams can set and enforce controls over extensions:</p><p>1. <a href="https://support.google.com/chrome/a/answer/7515036?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">Extension permission</a><br /><br />Organizations can control whether users can install apps or extensions based on the information an extension can access—also known as permissions. For example, you might want to prevent users from installing any extension that wants permission to see a device location.</p><p>2. <a href="https://support.google.com/chrome/a/answer/10405494?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">Extension workflow</a><br /><br />Extension workflow allows end users to request extensions for review. From there, IT can either approve or deny them. This is a great approach for teams that want to control the extensions in their environment, but allow end users to have some say over the extensions they use. </p><div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBRYpbzjk0i0eWlbRgxy5u36t8M1fq-saZVt2eCKV74kIREjr87AIzdRJM9rtwyCumc1LNV2uwcWqU662jiJE9Ku6Kwq76vwWD5m6x_JeDpFSImp6JzWUASdSu8uYD6NCHSwT8PDknN4zXeIlPiB84gXTBkbaDsBiYJjUTgvpjrFRnxB7N0RmQVLq5VOFc/s1600/extension%203.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="330" data-original-width="529" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBRYpbzjk0i0eWlbRgxy5u36t8M1fq-saZVt2eCKV74kIREjr87AIzdRJM9rtwyCumc1LNV2uwcWqU662jiJE9Ku6Kwq76vwWD5m6x_JeDpFSImp6JzWUASdSu8uYD6NCHSwT8PDknN4zXeIlPiB84gXTBkbaDsBiYJjUTgvpjrFRnxB7N0RmQVLq5VOFc/s1600/extension%203.png" /></a></div> <p></p> <p> We <a href="https://cloud.google.com/blog/products/chrome-enterprise/making-chrome-better-your-enterprise-users-chrome-browser-cloud-management">recently added a prompt for business justification</a> for documenting why users are requesting the extension. This gives admins more information as to why the extension may or may not be helpful for their workforce, and can help speed approvals for business users. </p> <p> </p><div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWKN7NQatRzGATIZbc5YAqqZuysJuWRyoDjQrIxc63TrkcUe_x37f5JQxxeo5MhYKUptBLh1s2Vvuz4EzWjVHoHmWI0_tgd5qZXt5wNiJMuD7KmYq6ZLlxCtn4L-NSjRRSWXdLdaeulaiU0sVNzCyhBMZJpehpvzddH8rIiuQO6LKz99E3ce587koRL9NR/s1600/extension%204.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="464" data-original-width="714" height="306" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWKN7NQatRzGATIZbc5YAqqZuysJuWRyoDjQrIxc63TrkcUe_x37f5JQxxeo5MhYKUptBLh1s2Vvuz4EzWjVHoHmWI0_tgd5qZXt5wNiJMuD7KmYq6ZLlxCtn4L-NSjRRSWXdLdaeulaiU0sVNzCyhBMZJpehpvzddH8rIiuQO6LKz99E3ce587koRL9NR/w471-h306/extension%204.png" width="471" /></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWKN7NQatRzGATIZbc5YAqqZuysJuWRyoDjQrIxc63TrkcUe_x37f5JQxxeo5MhYKUptBLh1s2Vvuz4EzWjVHoHmWI0_tgd5qZXt5wNiJMuD7KmYq6ZLlxCtn4L-NSjRRSWXdLdaeulaiU0sVNzCyhBMZJpehpvzddH8rIiuQO6LKz99E3ce587koRL9NR/s1600/extension%204.png" style="display: inline !important; padding: 1em 0px;"><strong style="text-align: left;"></strong></a><span style="text-align: left;"><b>3. </b><a href="https://support.google.com/chrome/a/answer/6177431?hl=en#zippy=%2Callow-or-block-all-apps-and-extensions-except-the-ones-you-specify" style="font-weight: bold;">Force install/block extensions</a><b><br /></b></span><b><br /></b><span style="text-align: left;">In the requests tab, you can select a requested extension, and approve that extension request and force install it, so the extension shows up automatically on all the managed browsers in that specific Organizational Unit or group.<br /></span><br />Admins also have the ability to block extensions in their browser environment.<br /><br />4. <a href="https://support.google.com/chrome/a/answer/11190170?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">Extension version pinning</a><br /><br />Admins have the ability to pin extensions to specific versions. As a result, the pinned extensions will not be upgraded unless the admin explicitly changes the version. This gives organizations the ability to evaluate new extension versions before they decide to allow them in their environment.<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5Is7aTaWVjW1oaXYZBWZTOEfwfjvVc98-BHMudmo5pZ8z45QIwmieiMcayX8fBL2FNOqXi0OOiDheby9r3nZgXxRroH7Ze56AR34hUwt5XzMwkRxOgiLTI9SCqbieNYiFnYoTCer598E14wlNE8fsaJCXz6Y8beesrxXY3Yekr4vZ0F1ZF6_Gb8bEhprW/s1600/extension%205.png" style="display: inline !important; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="651" data-original-width="1498" height="491" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5Is7aTaWVjW1oaXYZBWZTOEfwfjvVc98-BHMudmo5pZ8z45QIwmieiMcayX8fBL2FNOqXi0OOiDheby9r3nZgXxRroH7Ze56AR34hUwt5XzMwkRxOgiLTI9SCqbieNYiFnYoTCer598E14wlNE8fsaJCXz6Y8beesrxXY3Yekr4vZ0F1ZF6_Gb8bEhprW/w1131-h491/extension%205.png" width="1131" /></a><br /><br />Extensions play a huge role in user productivity for many organizations, and Chrome is committed to help enterprises securely take advantage of them. If you haven’t already, you can <a href="https://chromeenterprise.google/browser/management/">sign up for Chrome Browser Cloud Management</a> and start managing extensions being used in your organizations at no additional cost.<br /><br />If you’re already using Chrome Browser Cloud Management, but want to see how you can get the most out of it, check out our newly released <a href="https://www.youtube.com/watch?v=iczFTCmYJlw&list=PL_M98aVzfIjrQAlyzuNC6tSvI2ikGq7qn&app=desktop">Beyond Browsing demo series</a> where Chrome experts share demos on some of our frequently asked management questions.</div><p></p><p></p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by Anuj Goyal, Product Manager, Chrome Browser</span><p> Browser extensions, while offering valuable functionalities, can seem risky to organizations. One major concern is the potential for security vulnerabilities. Poorly designed or malicious extensions could compromise data integrity and expose sensitive information to unauthorized access. Moreover, certain extensions may introduce performance issues or conflicts with other software, leading to system instability. Therefore, many organizations find it crucial to have visibility into the usage of extensions and the ability to control them. Chrome browser offers these extension management capabilities and reporting via <a href="https://chromeenterprise.google/browser/management/">Chrome Browser Cloud Management</a>. In this blog post, we will walk you through how to utilize these features to keep your data and users safe. </p> <p> <strong>Visibility into Extensions being used in your environment</strong> </p> <p> Having visibility into what and how extensions are being used enables IT and security teams to assess potential security implications, ensure compliance with organizational policies, and mitigate potential risks. There are three ways you can get critical information about extensions in your organization:</p><p>1. <a href="https://support.google.com/chrome/a/answer/9902456?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">App and extension usage reporting</a><br /><br />Organizations can gain visibility into every Chrome extension that is installed across an enterprise’s fleet in <a href="https://support.google.com/chrome/a/answer/10836225?hl=en">Chrome App and Extension Usage Reporting</a>.<br /><br />2. <a href="https://cloud.google.com/blog/products/chrome-enterprise/secure-enterprise-browsing-more-data-protections-visibility-and-insights" style="font-weight: bold;">Extension Risk Assessment</a><br /><br />CRXcavator and Spin.AI Risk Assessment are tools used to assess the risks of browser extensions and minimize the risks associated with them. We are making extension scores via these two platforms available directly in Chrome Browser Cloud Management, so security teams can have an at-a-glance view of risk scores of the extensions being used in their browser environment.</p> <p> </p><div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2y_MUYbD67bgvLv3qfIYnviVa6lTnd5Hly6R3XMQ8TBvDCtaQF5Gn3GwboTUCLSyG2xh7dzxcSQFeSPQW_L2h1-GYHjEaWvykP8o2gX17mOLhLyo1t-wZvbf84fXQYcCqwYQLHG7xnar-_qD0Q0lpC-lnbiwf2u5WTM098AtZXoEil6Zt0Dd-LxPfw5HC/s1600/extension%201.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="268" data-original-width="900" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2y_MUYbD67bgvLv3qfIYnviVa6lTnd5Hly6R3XMQ8TBvDCtaQF5Gn3GwboTUCLSyG2xh7dzxcSQFeSPQW_L2h1-GYHjEaWvykP8o2gX17mOLhLyo1t-wZvbf84fXQYcCqwYQLHG7xnar-_qD0Q0lpC-lnbiwf2u5WTM098AtZXoEil6Zt0Dd-LxPfw5HC/s1600/extension%201.png" /><strong style="text-align: left;"></strong></a><span style="text-align: left;"><b>3. </b><a href="https://support.google.com/chrome/a/answer/11375053?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">Extension event reporting</a><b><br /></b></span><b><br /></b>Extension installs events are now available to alert IT and security teams of new extension usage in their environment.<br /><br />Organizations can send critical browser security events to their chosen solution providers, such as Splunk, Crowdstrike, Palo Alto Networks, and Google solutions, including Chronicle, Cloud PubSub, and Google Workspace, for further analysis. You can also view the event logs directly in Chrome Browser Cloud Management.<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrNWm-UMe_Tsz3SCwGx_cBVteyqePjWntU7Vm0CgVV_tTjC8WFDb5zPcLEFiGpJM53nqltaAXTEk4VmpKqfS2i3hacbbvB26ihM3eyH6fexxBb3wg9TfS_GsxBFzm94kHNxbAE27R69g_7gt_KfdHTbEtlZ1fWgoy7dG6RGB1J8jPMSbMwOW3JzSzyb-LR/s1600/extension%202.png" style="display: inline !important; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="975" data-original-width="912" height="734" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrNWm-UMe_Tsz3SCwGx_cBVteyqePjWntU7Vm0CgVV_tTjC8WFDb5zPcLEFiGpJM53nqltaAXTEk4VmpKqfS2i3hacbbvB26ihM3eyH6fexxBb3wg9TfS_GsxBFzm94kHNxbAE27R69g_7gt_KfdHTbEtlZ1fWgoy7dG6RGB1J8jPMSbMwOW3JzSzyb-LR/w687-h734/extension%202.png" width="687" /></a></div> <p></p> <p> <strong>Extension controls for added security </strong> </p> <p> By having control over extensions, organizations can maintain a secure and stable browsing environment, safeguard sensitive data, and protect their overall digital infrastructure. There are several ways IT and security teams can set and enforce controls over extensions:</p><p>1. <a href="https://support.google.com/chrome/a/answer/7515036?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">Extension permission</a><br /><br />Organizations can control whether users can install apps or extensions based on the information an extension can access—also known as permissions. For example, you might want to prevent users from installing any extension that wants permission to see a device location.</p><p>2. <a href="https://support.google.com/chrome/a/answer/10405494?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">Extension workflow</a><br /><br />Extension workflow allows end users to request extensions for review. From there, IT can either approve or deny them. This is a great approach for teams that want to control the extensions in their environment, but allow end users to have some say over the extensions they use. </p><div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBRYpbzjk0i0eWlbRgxy5u36t8M1fq-saZVt2eCKV74kIREjr87AIzdRJM9rtwyCumc1LNV2uwcWqU662jiJE9Ku6Kwq76vwWD5m6x_JeDpFSImp6JzWUASdSu8uYD6NCHSwT8PDknN4zXeIlPiB84gXTBkbaDsBiYJjUTgvpjrFRnxB7N0RmQVLq5VOFc/s1600/extension%203.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="330" data-original-width="529" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBRYpbzjk0i0eWlbRgxy5u36t8M1fq-saZVt2eCKV74kIREjr87AIzdRJM9rtwyCumc1LNV2uwcWqU662jiJE9Ku6Kwq76vwWD5m6x_JeDpFSImp6JzWUASdSu8uYD6NCHSwT8PDknN4zXeIlPiB84gXTBkbaDsBiYJjUTgvpjrFRnxB7N0RmQVLq5VOFc/s1600/extension%203.png" /></a></div> <p></p> <p> We <a href="https://cloud.google.com/blog/products/chrome-enterprise/making-chrome-better-your-enterprise-users-chrome-browser-cloud-management">recently added a prompt for business justification</a> for documenting why users are requesting the extension. This gives admins more information as to why the extension may or may not be helpful for their workforce, and can help speed approvals for business users. </p> <p> </p><div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWKN7NQatRzGATIZbc5YAqqZuysJuWRyoDjQrIxc63TrkcUe_x37f5JQxxeo5MhYKUptBLh1s2Vvuz4EzWjVHoHmWI0_tgd5qZXt5wNiJMuD7KmYq6ZLlxCtn4L-NSjRRSWXdLdaeulaiU0sVNzCyhBMZJpehpvzddH8rIiuQO6LKz99E3ce587koRL9NR/s1600/extension%204.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="464" data-original-width="714" height="306" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWKN7NQatRzGATIZbc5YAqqZuysJuWRyoDjQrIxc63TrkcUe_x37f5JQxxeo5MhYKUptBLh1s2Vvuz4EzWjVHoHmWI0_tgd5qZXt5wNiJMuD7KmYq6ZLlxCtn4L-NSjRRSWXdLdaeulaiU0sVNzCyhBMZJpehpvzddH8rIiuQO6LKz99E3ce587koRL9NR/w471-h306/extension%204.png" width="471" /></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWKN7NQatRzGATIZbc5YAqqZuysJuWRyoDjQrIxc63TrkcUe_x37f5JQxxeo5MhYKUptBLh1s2Vvuz4EzWjVHoHmWI0_tgd5qZXt5wNiJMuD7KmYq6ZLlxCtn4L-NSjRRSWXdLdaeulaiU0sVNzCyhBMZJpehpvzddH8rIiuQO6LKz99E3ce587koRL9NR/s1600/extension%204.png" style="display: inline !important; padding: 1em 0px;"><strong style="text-align: left;"></strong></a><span style="text-align: left;"><b>3. </b><a href="https://support.google.com/chrome/a/answer/6177431?hl=en#zippy=%2Callow-or-block-all-apps-and-extensions-except-the-ones-you-specify" style="font-weight: bold;">Force install/block extensions</a><b><br /></b></span><b><br /></b><span style="text-align: left;">In the requests tab, you can select a requested extension, and approve that extension request and force install it, so the extension shows up automatically on all the managed browsers in that specific Organizational Unit or group.<br /></span><br />Admins also have the ability to block extensions in their browser environment.<br /><br />4. <a href="https://support.google.com/chrome/a/answer/11190170?hl=en&sjid=1526346812622298510-NA" style="font-weight: bold;">Extension version pinning</a><br /><br />Admins have the ability to pin extensions to specific versions. As a result, the pinned extensions will not be upgraded unless the admin explicitly changes the version. This gives organizations the ability to evaluate new extension versions before they decide to allow them in their environment.<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5Is7aTaWVjW1oaXYZBWZTOEfwfjvVc98-BHMudmo5pZ8z45QIwmieiMcayX8fBL2FNOqXi0OOiDheby9r3nZgXxRroH7Ze56AR34hUwt5XzMwkRxOgiLTI9SCqbieNYiFnYoTCer598E14wlNE8fsaJCXz6Y8beesrxXY3Yekr4vZ0F1ZF6_Gb8bEhprW/s1600/extension%205.png" style="display: inline !important; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="651" data-original-width="1498" height="491" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5Is7aTaWVjW1oaXYZBWZTOEfwfjvVc98-BHMudmo5pZ8z45QIwmieiMcayX8fBL2FNOqXi0OOiDheby9r3nZgXxRroH7Ze56AR34hUwt5XzMwkRxOgiLTI9SCqbieNYiFnYoTCer598E14wlNE8fsaJCXz6Y8beesrxXY3Yekr4vZ0F1ZF6_Gb8bEhprW/w1131-h491/extension%205.png" width="1131" /></a><br /><br />Extensions play a huge role in user productivity for many organizations, and Chrome is committed to help enterprises securely take advantage of them. If you haven’t already, you can <a href="https://chromeenterprise.google/browser/management/">sign up for Chrome Browser Cloud Management</a> and start managing extensions being used in your organizations at no additional cost.<br /><br />If you’re already using Chrome Browser Cloud Management, but want to see how you can get the most out of it, check out our newly released <a href="https://www.youtube.com/watch?v=iczFTCmYJlw&list=PL_M98aVzfIjrQAlyzuNC6tSvI2ikGq7qn&app=desktop">Beyond Browsing demo series</a> where Chrome experts share demos on some of our frequently asked management questions.</div><p></p><p></p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Protect and manage browser extensions using Chrome Browser Cloud Management&url=https://security.googleblog.com/2023/06/protect-and-manage-browser-extensions.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2023/06/protect-and-manage-browser-extensions.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2023/06/protect-and-manage-browser-extensions.html' data-url='https://security.googleblog.com/2023/06/protect-and-manage-browser-extensions.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2023/06/protect-and-manage-browser-extensions.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='2326763818745663622' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2023/06/announcing-chrome-browser-full-chain.html' itemprop='url' title='Announcing the Chrome Browser Full Chain Exploit Bonus'> Announcing the Chrome Browser Full Chain Exploit Bonus </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> June 1, 2023 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Amy Ressler, Chrome Security Team on behalf of the Chrome VRP</span> <p> For 13 years, a key pillar of the Chrome Security ecosystem has included encouraging security researchers to find security vulnerabilities in Chrome browser and report them to us, through the <a href="https://g.co/chrome/vrp">Chrome Vulnerability Rewards Program</a>. </p> <p> Starting today and until 1 December 2023, the first security bug report we receive with a functional full chain exploit, resulting in a Chrome sandbox escape, is eligible for <strong>triple the full reward amount</strong>. Your full chain exploit could result in a reward up to $180,000 (potentially more with other bonuses). </p> <p> </p> <p> Any subsequent full chains submitted during this time are eligible for <strong>double the full reward amount</strong>! </p> <p> We have historically put a premium on reports with exploits – “high quality reports with a functional exploit” is the highest tier of reward amounts in our Vulnerability Rewards Program. Over the years, the threat model of Chrome browser has evolved as features have matured and new features and new mitigations, such a <a href="https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html">MiraclePtr</a>, have been introduced. Given these evolutions, we’re always interested in explorations of new and novel approaches to fully exploit Chrome browser and we want to provide opportunities to better incentivize this type of research. These exploits provide us valuable insight into the potential attack vectors for exploiting Chrome, and allow us to identify strategies for better hardening specific Chrome features and ideas for future broad-scale mitigation strategies. </p> <p> The full details of this bonus opportunity are available on the <a href="https://g.co/chrome/vrp">Chrome VRP rules and rewards page</a>. The summary is as follows: </p> <ul> <li>The bug reports may be submitted in advance while exploit development continues during this 180-day window. The functional exploits must be submitted to Chrome by the end of the 180-day window to be eligible for the triple or double reward. <ul> <li>The first functional full chain exploit we receive is eligible for the triple reward amount. </li> </ul> <li>The full chain exploit must result in a Chrome browser sandbox escape, with a demonstration of attacker control / code execution outside of the sandbox. <li>Exploitation must be able to be performed remotely and no or very limited reliance on user interaction. <li>The exploit must have been functional in an active release channel of Chrome (Dev, Beta, Stable, Extended Stable) at the time of the initial reports of the bugs in that chain. Please do not submit exploits developed from publicly disclosed security bugs or other artifacts in old, past versions of Chrome. </li> </ul> <p> As is consistent with our general rewards policy, if the exploit allows for remote code execution (RCE) in the browser or other highly-privileged process, such as network or GPU process, to result in a sandbox escape without the need of a first stage bug, the reward amount for renderer RCE “high quality report with functional exploit” would be granted and included in the calculation of the bonus reward total. </p> <p> Based on our current <a href="https://bughunters.google.com/about/rules/5745167867576320/chrome-vulnerability-reward-program-rules#reward-amounts">Chrome VRP reward matrix</a>, your full chain exploit could result in a total reward of over $165,000 -$180,000 for the first full chain exploit and over $110,000 - $120,000 for subsequent full chain exploits we receive in the six month window of this reward opportunity. </p> <p> We’d like to thank our entire Chrome researcher community for your past and ongoing efforts and security bug submissions! You’ve truly helped us make Chrome more secure for all users. </p> <p> Happy Hunting! </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Amy Ressler, Chrome Security Team on behalf of the Chrome VRP</span> <p> For 13 years, a key pillar of the Chrome Security ecosystem has included encouraging security researchers to find security vulnerabilities in Chrome browser and report them to us, through the <a href="https://g.co/chrome/vrp">Chrome Vulnerability Rewards Program</a>. </p> <p> Starting today and until 1 December 2023, the first security bug report we receive with a functional full chain exploit, resulting in a Chrome sandbox escape, is eligible for <strong>triple the full reward amount</strong>. Your full chain exploit could result in a reward up to $180,000 (potentially more with other bonuses). </p> <p> </p> <p> Any subsequent full chains submitted during this time are eligible for <strong>double the full reward amount</strong>! </p> <p> We have historically put a premium on reports with exploits – “high quality reports with a functional exploit” is the highest tier of reward amounts in our Vulnerability Rewards Program. Over the years, the threat model of Chrome browser has evolved as features have matured and new features and new mitigations, such a <a href="https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html">MiraclePtr</a>, have been introduced. Given these evolutions, we’re always interested in explorations of new and novel approaches to fully exploit Chrome browser and we want to provide opportunities to better incentivize this type of research. These exploits provide us valuable insight into the potential attack vectors for exploiting Chrome, and allow us to identify strategies for better hardening specific Chrome features and ideas for future broad-scale mitigation strategies. </p> <p> The full details of this bonus opportunity are available on the <a href="https://g.co/chrome/vrp">Chrome VRP rules and rewards page</a>. The summary is as follows: </p> <ul> <li>The bug reports may be submitted in advance while exploit development continues during this 180-day window. The functional exploits must be submitted to Chrome by the end of the 180-day window to be eligible for the triple or double reward. <ul> <li>The first functional full chain exploit we receive is eligible for the triple reward amount. </li> </ul> <li>The full chain exploit must result in a Chrome browser sandbox escape, with a demonstration of attacker control / code execution outside of the sandbox. <li>Exploitation must be able to be performed remotely and no or very limited reliance on user interaction. <li>The exploit must have been functional in an active release channel of Chrome (Dev, Beta, Stable, Extended Stable) at the time of the initial reports of the bugs in that chain. Please do not submit exploits developed from publicly disclosed security bugs or other artifacts in old, past versions of Chrome. </li> </ul> <p> As is consistent with our general rewards policy, if the exploit allows for remote code execution (RCE) in the browser or other highly-privileged process, such as network or GPU process, to result in a sandbox escape without the need of a first stage bug, the reward amount for renderer RCE “high quality report with functional exploit” would be granted and included in the calculation of the bonus reward total. </p> <p> Based on our current <a href="https://bughunters.google.com/about/rules/5745167867576320/chrome-vulnerability-reward-program-rules#reward-amounts">Chrome VRP reward matrix</a>, your full chain exploit could result in a total reward of over $165,000 -$180,000 for the first full chain exploit and over $110,000 - $120,000 for subsequent full chain exploits we receive in the six month window of this reward opportunity. </p> <p> We’d like to thank our entire Chrome researcher community for your past and ongoing efforts and security bug submissions! You’ve truly helped us make Chrome more secure for all users. </p> <p> Happy Hunting! </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Announcing the Chrome Browser Full Chain Exploit Bonus&url=https://security.googleblog.com/2023/06/announcing-chrome-browser-full-chain.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2023/06/announcing-chrome-browser-full-chain.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2023/06/announcing-chrome-browser-full-chain.html' data-url='https://security.googleblog.com/2023/06/announcing-chrome-browser-full-chain.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2023/06/announcing-chrome-browser-full-chain.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='35423650340414820' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2023/05/adding-chrome-browser-cloud-management.html' itemprop='url' title='Adding Chrome Browser Cloud Management remediation actions in Splunk using Alert Actions'> Adding Chrome Browser Cloud Management remediation actions in Splunk using Alert Actions </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> May 31, 2023 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Ashish Pujari, Chrome Enterprise Security Team</span> <p> <strong>Introduction</strong> </p> <p> Chrome is trusted by millions of business users as a secure enterprise browser. Organizations can use <a href="https://chromeenterprise.google/browser/management/">Chrome Browser Cloud Management</a> to help manage Chrome browsers more effectively. As an admin, they can use the Google Admin console to get Chrome to report critical security events to third-party service providers such as <a href="https://splunk.com/">Splunk</a>® to create custom enterprise security remediation workflows. </p> <p> Security remediation is the process of responding to security events that have been triggered by a system or a user. Remediation can be done manually or automatically, and it is an important part of an enterprise security program. </p> <p> <strong>Why is Automated Security Remediation Important?</strong> </p> <p> When a security event is identified, it is imperative to respond as soon as possible to prevent data exfiltration and to prevent the attacker from gaining a foothold in the enterprise. Organizations with mature security processes utilize automated remediation to improve the security posture by reducing the time it takes to respond to security events. This allows the usually over burdened Security Operations Center (SOC) teams to avoid alert fatigue. </p> <p> <strong>Automated Security Remediation using Chrome Browser Cloud Management and Splunk</strong> </p> <p> Chrome integrates with <a href="https://chromeenterprise.google/recommended/#security-&-trust">Chrome Enterprise Recommended </a>partners such as Splunk® using <a href="https://support.google.com/chrome/a/answer/11375053">Chrome Enterprise Connectors</a> to report security events such as malware transfer, unsafe site visits, password reuse. Other supported events can be found on our <a href="https://support.google.com/a/answer/9393909?hl=en">support page</a>. </p> <p> The Splunk integration with Chrome browser allows organizations to collect, analyze, and extract insights from security events. The extended security insights into managed browsers will enable SOC teams to perform better informed automated security remediations using <a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/Setupalertactions">Splunk</a>®<a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/Setupalertactions"> Alert Actions</a>. </p> <p> Splunk Alert Actions are a great capability for automating security remediation tasks. By creating alert actions, enterprises can automate the process of identifying, prioritizing, and remediating security threats. </p> <p> In Splunk®, SOC teams can use alerts to monitor for and respond to specific Chrome Browser Cloud Management events. Alerts use a saved search to look for events in real time or on a schedule and can trigger an Alert Action when search results meet specific conditions as outlined in the diagram below. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg34lHUTbNNIH8t4iYgFpu-xVc6UW7jk0GhWXlKnOF9rSvFxU9UJD_-2Jty66udUYSXHBtXpaccgU40yGfWPTejxHudNbSYJs632frxmVshuE6Va24SO5SbuIlus2yyFSjhmzaf9Z0YAxoyv80KmPOMFH5NANh6J8z5XALwf2XN7FyMfZFjYhCx7SWi7Q/s1600/1.jpeg" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1123" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg34lHUTbNNIH8t4iYgFpu-xVc6UW7jk0GhWXlKnOF9rSvFxU9UJD_-2Jty66udUYSXHBtXpaccgU40yGfWPTejxHudNbSYJs632frxmVshuE6Va24SO5SbuIlus2yyFSjhmzaf9Z0YAxoyv80KmPOMFH5NANh6J8z5XALwf2XN7FyMfZFjYhCx7SWi7Q/s1600/1.jpeg"/></a></div> </p> <p> <strong>Use Case</strong> </p> <p> If a user downloads a malicious file after bypassing a Chrome “Dangerous File” message their managed browser/managed CrOS device should be quarantined. </p> <p> <strong>Prerequisites</strong> </p> <ul> <li>Create a <a href="https://support.google.com/chrome/a/topic/9025410">Chrome Browser Cloud Management</a> account at no additional costs <li><a href="https://www.splunk.com/en_us/products/splunk-enterprise.html">Splunk</a>®<a href="https://www.splunk.com/en_us/products/splunk-enterprise.html"> Enterprise</a> v9.0.* or <a href="https://www.splunk.com/en_us/products/splunk-cloud-platform.html">Splunk® Cloud Platform</a> (Cost: Please refer to Splunk’s website) <li>Understanding of the <a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/AlertWorkflowOverview">Splunk alerting workflow</a> <li>Understanding of how to <a href="https://dev.splunk.com/enterprise/docs/devtools/customalertactions/createuicaa">create custom alert actions</a> in Splunk®. </li> </ul> <p> <strong>Setup</strong> </p> <ol type="A"> <li><strong>Install the Google Chrome Add-on for Splunk App</strong> <p> Please follow installation instructions <a href="https://docs.splunk.com/Documentation/AddOns/released/Overview/Installingadd-ons">here</a> depending on your Splunk Installation to install the <a href="https://splunkbase.splunk.com/app/5607">Google Chrome Add-on for Splunk App</a>. </p> <li><strong>Setting up Chrome Browser Cloud Management and Splunk Integration</strong> <p> Please follow the guide <a href="https://support.google.com/chrome/a/answer/11375053">here</a> to set up Chrome Browser Cloud Management and Splunk® integration. </p> <li><strong>Setting up Chrome Browser Cloud Management API access</strong> <p> To call the Chrome Browser Cloud Management<a href="https://support.google.com/chrome/a/answer/9681204?hl=en"> API</a>, use a service account properly configured in the Google admin console. <a href="https://support.google.com/a/answer/7378726?hl=en">Create</a> a (or use an existing) service account and download the JSON representation of the key. </p> <p> <a href="https://support.google.com/a/answer/2406043?hl=en">Create</a> a (or use an existing) role in the admin console with all the “Chrome Management” privileges as shown below. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0T1_pN37GXfoqzSrfVsfHO7nQoKHHUxNQc3sMghPxyxNajP5RSzPC9NCWHMb2V1F0QA2GzS2ml4Y9ET-NJe54uGc1nFTI9LWFrn_jKwS1EMRfgGNzoly7EmQJJyLLnwyJt1AmaWjy_7R6H_vRQesF7BLaR4HxHaePdU8q2SCkOz-nKZIrniWPIAl-yA/s1600/2.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="781" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0T1_pN37GXfoqzSrfVsfHO7nQoKHHUxNQc3sMghPxyxNajP5RSzPC9NCWHMb2V1F0QA2GzS2ml4Y9ET-NJe54uGc1nFTI9LWFrn_jKwS1EMRfgGNzoly7EmQJJyLLnwyJt1AmaWjy_7R6H_vRQesF7BLaR4HxHaePdU8q2SCkOz-nKZIrniWPIAl-yA/s1600/2.png"/></a></div> </p> <p> Assign the created role to the service account using the “Assign service accounts” button.<br> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq3Km9s3Ng34N4tS76wg6Ji1iLChlC8Njq_AmxtC68s23Q6Vfxz8nGTCjNIE4fwMd8VkPPUTWhrmWhYjDGJuipuXInrBMFVfRqjnTC09Disr54CvP_E5SpbjAIRM6fwWxXg0b9kdKpoIpwiqa18bTjSFj1YtLhF36qXGWH7-sz-nBKLLUbhqWLHfrkQg/s1600/3.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="558" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq3Km9s3Ng34N4tS76wg6Ji1iLChlC8Njq_AmxtC68s23Q6Vfxz8nGTCjNIE4fwMd8VkPPUTWhrmWhYjDGJuipuXInrBMFVfRqjnTC09Disr54CvP_E5SpbjAIRM6fwWxXg0b9kdKpoIpwiqa18bTjSFj1YtLhF36qXGWH7-sz-nBKLLUbhqWLHfrkQg/s1600/3.png"/></a></div> <li><strong>Setting up Chrome Browser Cloud Management App in Splunk</strong>® <p> Install the App i.e. Alert Action from our <a href="https://github.com/google/ChromeBrowserEnterprise/tree/main/Python/connectors">Github page</a>. You will notice that the Splunk App uses the below <a href="https://dev.splunk.com/enterprise/docs/developapps/createapps/appanatomy/">directory structure</a>. Please take some time to understand the directory structure layout. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGURf5HGcMLTjRYgFjtUO091RgY252bofGKmeF6VAEyhjkEWt4HIbuKdwaD2wJsyOfn70FryjTTMOrbeQ084SA_LPvUvZdEGoCPWmGPtT3lppUg-iMN7pve9e8GGvRMGt5xce9TPI8KTaYCbKD6BHHuAhgsDXSaaikThcg9e_ma3Er4AGOq6PwN_VemA/s1600/4.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="810" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGURf5HGcMLTjRYgFjtUO091RgY252bofGKmeF6VAEyhjkEWt4HIbuKdwaD2wJsyOfn70FryjTTMOrbeQ084SA_LPvUvZdEGoCPWmGPtT3lppUg-iMN7pve9e8GGvRMGt5xce9TPI8KTaYCbKD6BHHuAhgsDXSaaikThcg9e_ma3Er4AGOq6PwN_VemA/s1600/4.png"/></a></div> <li><strong>Setting up a Quarantine OU in Chrome Browser Cloud Management</strong> <p> <a href="https://support.google.com/a/answer/182537?hl=en">Create</a> a “Quarantine” OU to move managed browsers into. Apply restrictive <a href="https://support.google.com/chrome/a/answer/2657289?hl=en&ref_topic=9027936">policies</a> to this OU which will then be applied to managed browsers and managed CrOS devices that are moved to this OU. In our case we set the below policies for our “Quarantine” OU called <code>Investigate.</code>These policies ensure that the quarantined CrOS device/browser can only open a limited set of approved URLS. </p> <ul> <li><code><a href="https://chromeenterprise.google/policies/#URLBlocklist">URL Blocklist</a> - Block access to all URLs</code> <li><code><a href="https://chromeenterprise.google/policies/#URLAllowlist">URL Allowlist</a> - Allow only approved URLs for e.g. IT Helpdesk website</code> <li><code><a href="https://chromeenterprise.google/policies/#NewTabPageLocation">New Tab Page Location</a> - Set New tab page URL to an internal website asking the user to contact IT Helpdesk.</code> <li><code><a href="https://chromeenterprise.google/policies/#HomepageIsNewTabPage">Home Page is New Tab Page</a> - Use the </code>New Tab page as the user's homepage. </li> </ul> </li> </ol> <p> <strong>Configuration</strong> </p> <ol type ="1"> <li>Start with a search for the <strong>Chrome Browser Cloud Management</strong> events in the Google Chrome Add-on for Splunk App. For our instance we used the below search query to search for known malicious file download events. </li> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEij_LINbx2prdQuoQvRBiOw4JUDqR_g66In9J5HwOt2SlgKehA2aMe-6TVh5Y4m7LltnGGVe0Fr12pVRCblXqFzXH2JiUi8r7slPP5HeFGN0H-mHalV3VWpxy1MUfpUIo6tuptd5334hrqeq3uOk-mteFeifxhCKowQxKQpHmiUPiVpuv1Wvu-O3VaI2w/s1600/Screenshot%202023-05-30%2011.11.51%20PM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="111" data-original-width="766" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEij_LINbx2prdQuoQvRBiOw4JUDqR_g66In9J5HwOt2SlgKehA2aMe-6TVh5Y4m7LltnGGVe0Fr12pVRCblXqFzXH2JiUi8r7slPP5HeFGN0H-mHalV3VWpxy1MUfpUIo6tuptd5334hrqeq3uOk-mteFeifxhCKowQxKQpHmiUPiVpuv1Wvu-O3VaI2w/s1600/Screenshot%202023-05-30%2011.11.51%20PM.png"/></a></div> <li>Save the search as an alert. The alert uses the saved search to check for events. Adjust the alert type to configure how often the search runs. Use a <a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/Definescheduledalerts">scheduled alert</a> to check for events on a regular basis. Use a <a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/DefineRealTimeAlerts">real-time alert</a> to monitor for events continuously. An alert does not have to trigger every time it generates search results. Set trigger conditions to manage when the alert triggers. Customize the alert settings as per enterprise security policies. For our example we used a real time alert with a per-result trigger. The setup we used is as shown below. <p> </li> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJRbLV61SN3AQEgcH3_k85eeFy-kSiYANl_Y6ukEcQei8P55Zc3hO6JA6UyiNuiBuKKtliMjqKGx5GZUfKcItgTmYFfgIMFqOo7ou4YRJ2OOjGbD2sr5OYuWUluwS-LC2shdjn3JOcvfhp95zeUd9pEGLmcbdQ0YWrD4raH44XVqAWC98fuzksc7UcZw/s1600/5.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1526" data-original-width="1550" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJRbLV61SN3AQEgcH3_k85eeFy-kSiYANl_Y6ukEcQei8P55Zc3hO6JA6UyiNuiBuKKtliMjqKGx5GZUfKcItgTmYFfgIMFqOo7ou4YRJ2OOjGbD2sr5OYuWUluwS-LC2shdjn3JOcvfhp95zeUd9pEGLmcbdQ0YWrD4raH44XVqAWC98fuzksc7UcZw/s1600/5.png"/></a></div> <p> As seen in the screenshot we have configured the Chrome Browser Cloud Management Remediation Alert Action App with </p> <ul> <li>The OU Path of the Quarantine OU i.e. <code>/Investigate</code> <li>The Customer Id of the workspace domain <li>Service Account Key JSON value </li> </ul> <p> <strong>Test the setup</strong> </p> <p> Use the <a href="http://testsafebrowsing.appspot.com/">testsafebrowsing</a> website to generate sample security events to test the setup. </p> <ol> <li>Open the <a href="http://testsafebrowsing.appspot.com/">testsafebrowsing</a> website <li>Click the link for line item 4 under the <code>Desktop Download Warnings</code> section i.e. “Should show an "uncommon" warning, for .exe” <li>You will see a <code>Dangerous Download blocked</code> warning giving you two options to either <code>Discard</code> or <code>Keep</code> the downloaded file. Click on <code>Keep</code> <li>This will trigger the alert action and move your managed browser or managed CrOS device to the “Quarantine” OU (OU name Investigate in our example) with restricted policies. </li> </ol> <p> <strong>Conclusion</strong> </p> <p> Security remediation is vital to any organization’s security program. In this blog we discussed configuring automated security remediation of Chrome Browser Cloud Management security events using Splunk alert actions. This scalable approach can be used to protect a company from online security threats by detecting and quickly responding to high fidelity Chrome Browser Cloud Management security events thereby greatly reducing the time to respond. </p> <p> Our team will be at the <a href="https://www.gartner.com/en/conferences/na/security-risk-management-us">Gartner Security and Risk Management Summit</a> in National Harbor, MD, next week. Come see us in action if you’re attending the summit. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by Ashish Pujari, Chrome Enterprise Security Team</span> <p> <strong>Introduction</strong> </p> <p> Chrome is trusted by millions of business users as a secure enterprise browser. Organizations can use <a href="https://chromeenterprise.google/browser/management/">Chrome Browser Cloud Management</a> to help manage Chrome browsers more effectively. As an admin, they can use the Google Admin console to get Chrome to report critical security events to third-party service providers such as <a href="https://splunk.com/">Splunk</a>® to create custom enterprise security remediation workflows. </p> <p> Security remediation is the process of responding to security events that have been triggered by a system or a user. Remediation can be done manually or automatically, and it is an important part of an enterprise security program. </p> <p> <strong>Why is Automated Security Remediation Important?</strong> </p> <p> When a security event is identified, it is imperative to respond as soon as possible to prevent data exfiltration and to prevent the attacker from gaining a foothold in the enterprise. Organizations with mature security processes utilize automated remediation to improve the security posture by reducing the time it takes to respond to security events. This allows the usually over burdened Security Operations Center (SOC) teams to avoid alert fatigue. </p> <p> <strong>Automated Security Remediation using Chrome Browser Cloud Management and Splunk</strong> </p> <p> Chrome integrates with <a href="https://chromeenterprise.google/recommended/#security-&-trust">Chrome Enterprise Recommended </a>partners such as Splunk® using <a href="https://support.google.com/chrome/a/answer/11375053">Chrome Enterprise Connectors</a> to report security events such as malware transfer, unsafe site visits, password reuse. Other supported events can be found on our <a href="https://support.google.com/a/answer/9393909?hl=en">support page</a>. </p> <p> The Splunk integration with Chrome browser allows organizations to collect, analyze, and extract insights from security events. The extended security insights into managed browsers will enable SOC teams to perform better informed automated security remediations using <a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/Setupalertactions">Splunk</a>®<a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/Setupalertactions"> Alert Actions</a>. </p> <p> Splunk Alert Actions are a great capability for automating security remediation tasks. By creating alert actions, enterprises can automate the process of identifying, prioritizing, and remediating security threats. </p> <p> In Splunk®, SOC teams can use alerts to monitor for and respond to specific Chrome Browser Cloud Management events. Alerts use a saved search to look for events in real time or on a schedule and can trigger an Alert Action when search results meet specific conditions as outlined in the diagram below. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg34lHUTbNNIH8t4iYgFpu-xVc6UW7jk0GhWXlKnOF9rSvFxU9UJD_-2Jty66udUYSXHBtXpaccgU40yGfWPTejxHudNbSYJs632frxmVshuE6Va24SO5SbuIlus2yyFSjhmzaf9Z0YAxoyv80KmPOMFH5NANh6J8z5XALwf2XN7FyMfZFjYhCx7SWi7Q/s1600/1.jpeg" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1123" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg34lHUTbNNIH8t4iYgFpu-xVc6UW7jk0GhWXlKnOF9rSvFxU9UJD_-2Jty66udUYSXHBtXpaccgU40yGfWPTejxHudNbSYJs632frxmVshuE6Va24SO5SbuIlus2yyFSjhmzaf9Z0YAxoyv80KmPOMFH5NANh6J8z5XALwf2XN7FyMfZFjYhCx7SWi7Q/s1600/1.jpeg"/></a></div> </p> <p> <strong>Use Case</strong> </p> <p> If a user downloads a malicious file after bypassing a Chrome “Dangerous File” message their managed browser/managed CrOS device should be quarantined. </p> <p> <strong>Prerequisites</strong> </p> <ul> <li>Create a <a href="https://support.google.com/chrome/a/topic/9025410">Chrome Browser Cloud Management</a> account at no additional costs <li><a href="https://www.splunk.com/en_us/products/splunk-enterprise.html">Splunk</a>®<a href="https://www.splunk.com/en_us/products/splunk-enterprise.html"> Enterprise</a> v9.0.* or <a href="https://www.splunk.com/en_us/products/splunk-cloud-platform.html">Splunk® Cloud Platform</a> (Cost: Please refer to Splunk’s website) <li>Understanding of the <a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/AlertWorkflowOverview">Splunk alerting workflow</a> <li>Understanding of how to <a href="https://dev.splunk.com/enterprise/docs/devtools/customalertactions/createuicaa">create custom alert actions</a> in Splunk®. </li> </ul> <p> <strong>Setup</strong> </p> <ol type="A"> <li><strong>Install the Google Chrome Add-on for Splunk App</strong> <p> Please follow installation instructions <a href="https://docs.splunk.com/Documentation/AddOns/released/Overview/Installingadd-ons">here</a> depending on your Splunk Installation to install the <a href="https://splunkbase.splunk.com/app/5607">Google Chrome Add-on for Splunk App</a>. </p> <li><strong>Setting up Chrome Browser Cloud Management and Splunk Integration</strong> <p> Please follow the guide <a href="https://support.google.com/chrome/a/answer/11375053">here</a> to set up Chrome Browser Cloud Management and Splunk® integration. </p> <li><strong>Setting up Chrome Browser Cloud Management API access</strong> <p> To call the Chrome Browser Cloud Management<a href="https://support.google.com/chrome/a/answer/9681204?hl=en"> API</a>, use a service account properly configured in the Google admin console. <a href="https://support.google.com/a/answer/7378726?hl=en">Create</a> a (or use an existing) service account and download the JSON representation of the key. </p> <p> <a href="https://support.google.com/a/answer/2406043?hl=en">Create</a> a (or use an existing) role in the admin console with all the “Chrome Management” privileges as shown below. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0T1_pN37GXfoqzSrfVsfHO7nQoKHHUxNQc3sMghPxyxNajP5RSzPC9NCWHMb2V1F0QA2GzS2ml4Y9ET-NJe54uGc1nFTI9LWFrn_jKwS1EMRfgGNzoly7EmQJJyLLnwyJt1AmaWjy_7R6H_vRQesF7BLaR4HxHaePdU8q2SCkOz-nKZIrniWPIAl-yA/s1600/2.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="781" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0T1_pN37GXfoqzSrfVsfHO7nQoKHHUxNQc3sMghPxyxNajP5RSzPC9NCWHMb2V1F0QA2GzS2ml4Y9ET-NJe54uGc1nFTI9LWFrn_jKwS1EMRfgGNzoly7EmQJJyLLnwyJt1AmaWjy_7R6H_vRQesF7BLaR4HxHaePdU8q2SCkOz-nKZIrniWPIAl-yA/s1600/2.png"/></a></div> </p> <p> Assign the created role to the service account using the “Assign service accounts” button.<br> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq3Km9s3Ng34N4tS76wg6Ji1iLChlC8Njq_AmxtC68s23Q6Vfxz8nGTCjNIE4fwMd8VkPPUTWhrmWhYjDGJuipuXInrBMFVfRqjnTC09Disr54CvP_E5SpbjAIRM6fwWxXg0b9kdKpoIpwiqa18bTjSFj1YtLhF36qXGWH7-sz-nBKLLUbhqWLHfrkQg/s1600/3.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="558" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq3Km9s3Ng34N4tS76wg6Ji1iLChlC8Njq_AmxtC68s23Q6Vfxz8nGTCjNIE4fwMd8VkPPUTWhrmWhYjDGJuipuXInrBMFVfRqjnTC09Disr54CvP_E5SpbjAIRM6fwWxXg0b9kdKpoIpwiqa18bTjSFj1YtLhF36qXGWH7-sz-nBKLLUbhqWLHfrkQg/s1600/3.png"/></a></div> <li><strong>Setting up Chrome Browser Cloud Management App in Splunk</strong>® <p> Install the App i.e. Alert Action from our <a href="https://github.com/google/ChromeBrowserEnterprise/tree/main/Python/connectors">Github page</a>. You will notice that the Splunk App uses the below <a href="https://dev.splunk.com/enterprise/docs/developapps/createapps/appanatomy/">directory structure</a>. Please take some time to understand the directory structure layout. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGURf5HGcMLTjRYgFjtUO091RgY252bofGKmeF6VAEyhjkEWt4HIbuKdwaD2wJsyOfn70FryjTTMOrbeQ084SA_LPvUvZdEGoCPWmGPtT3lppUg-iMN7pve9e8GGvRMGt5xce9TPI8KTaYCbKD6BHHuAhgsDXSaaikThcg9e_ma3Er4AGOq6PwN_VemA/s1600/4.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="810" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGURf5HGcMLTjRYgFjtUO091RgY252bofGKmeF6VAEyhjkEWt4HIbuKdwaD2wJsyOfn70FryjTTMOrbeQ084SA_LPvUvZdEGoCPWmGPtT3lppUg-iMN7pve9e8GGvRMGt5xce9TPI8KTaYCbKD6BHHuAhgsDXSaaikThcg9e_ma3Er4AGOq6PwN_VemA/s1600/4.png"/></a></div> <li><strong>Setting up a Quarantine OU in Chrome Browser Cloud Management</strong> <p> <a href="https://support.google.com/a/answer/182537?hl=en">Create</a> a “Quarantine” OU to move managed browsers into. Apply restrictive <a href="https://support.google.com/chrome/a/answer/2657289?hl=en&ref_topic=9027936">policies</a> to this OU which will then be applied to managed browsers and managed CrOS devices that are moved to this OU. In our case we set the below policies for our “Quarantine” OU called <code>Investigate.</code>These policies ensure that the quarantined CrOS device/browser can only open a limited set of approved URLS. </p> <ul> <li><code><a href="https://chromeenterprise.google/policies/#URLBlocklist">URL Blocklist</a> - Block access to all URLs</code> <li><code><a href="https://chromeenterprise.google/policies/#URLAllowlist">URL Allowlist</a> - Allow only approved URLs for e.g. IT Helpdesk website</code> <li><code><a href="https://chromeenterprise.google/policies/#NewTabPageLocation">New Tab Page Location</a> - Set New tab page URL to an internal website asking the user to contact IT Helpdesk.</code> <li><code><a href="https://chromeenterprise.google/policies/#HomepageIsNewTabPage">Home Page is New Tab Page</a> - Use the </code>New Tab page as the user's homepage. </li> </ul> </li> </ol> <p> <strong>Configuration</strong> </p> <ol type ="1"> <li>Start with a search for the <strong>Chrome Browser Cloud Management</strong> events in the Google Chrome Add-on for Splunk App. For our instance we used the below search query to search for known malicious file download events. </li> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEij_LINbx2prdQuoQvRBiOw4JUDqR_g66In9J5HwOt2SlgKehA2aMe-6TVh5Y4m7LltnGGVe0Fr12pVRCblXqFzXH2JiUi8r7slPP5HeFGN0H-mHalV3VWpxy1MUfpUIo6tuptd5334hrqeq3uOk-mteFeifxhCKowQxKQpHmiUPiVpuv1Wvu-O3VaI2w/s1600/Screenshot%202023-05-30%2011.11.51%20PM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="111" data-original-width="766" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEij_LINbx2prdQuoQvRBiOw4JUDqR_g66In9J5HwOt2SlgKehA2aMe-6TVh5Y4m7LltnGGVe0Fr12pVRCblXqFzXH2JiUi8r7slPP5HeFGN0H-mHalV3VWpxy1MUfpUIo6tuptd5334hrqeq3uOk-mteFeifxhCKowQxKQpHmiUPiVpuv1Wvu-O3VaI2w/s1600/Screenshot%202023-05-30%2011.11.51%20PM.png"/></a></div> <li>Save the search as an alert. The alert uses the saved search to check for events. Adjust the alert type to configure how often the search runs. Use a <a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/Definescheduledalerts">scheduled alert</a> to check for events on a regular basis. Use a <a href="https://docs.splunk.com/Documentation/Splunk/9.0.4/Alert/DefineRealTimeAlerts">real-time alert</a> to monitor for events continuously. An alert does not have to trigger every time it generates search results. Set trigger conditions to manage when the alert triggers. Customize the alert settings as per enterprise security policies. For our example we used a real time alert with a per-result trigger. The setup we used is as shown below. <p> </li> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJRbLV61SN3AQEgcH3_k85eeFy-kSiYANl_Y6ukEcQei8P55Zc3hO6JA6UyiNuiBuKKtliMjqKGx5GZUfKcItgTmYFfgIMFqOo7ou4YRJ2OOjGbD2sr5OYuWUluwS-LC2shdjn3JOcvfhp95zeUd9pEGLmcbdQ0YWrD4raH44XVqAWC98fuzksc7UcZw/s1600/5.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1526" data-original-width="1550" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJRbLV61SN3AQEgcH3_k85eeFy-kSiYANl_Y6ukEcQei8P55Zc3hO6JA6UyiNuiBuKKtliMjqKGx5GZUfKcItgTmYFfgIMFqOo7ou4YRJ2OOjGbD2sr5OYuWUluwS-LC2shdjn3JOcvfhp95zeUd9pEGLmcbdQ0YWrD4raH44XVqAWC98fuzksc7UcZw/s1600/5.png"/></a></div> <p> As seen in the screenshot we have configured the Chrome Browser Cloud Management Remediation Alert Action App with </p> <ul> <li>The OU Path of the Quarantine OU i.e. <code>/Investigate</code> <li>The Customer Id of the workspace domain <li>Service Account Key JSON value </li> </ul> <p> <strong>Test the setup</strong> </p> <p> Use the <a href="http://testsafebrowsing.appspot.com/">testsafebrowsing</a> website to generate sample security events to test the setup. </p> <ol> <li>Open the <a href="http://testsafebrowsing.appspot.com/">testsafebrowsing</a> website <li>Click the link for line item 4 under the <code>Desktop Download Warnings</code> section i.e. “Should show an "uncommon" warning, for .exe” <li>You will see a <code>Dangerous Download blocked</code> warning giving you two options to either <code>Discard</code> or <code>Keep</code> the downloaded file. Click on <code>Keep</code> <li>This will trigger the alert action and move your managed browser or managed CrOS device to the “Quarantine” OU (OU name Investigate in our example) with restricted policies. </li> </ol> <p> <strong>Conclusion</strong> </p> <p> Security remediation is vital to any organization’s security program. In this blog we discussed configuring automated security remediation of Chrome Browser Cloud Management security events using Splunk alert actions. This scalable approach can be used to protect a company from online security threats by detecting and quickly responding to high fidelity Chrome Browser Cloud Management security events thereby greatly reducing the time to respond. </p> <p> Our team will be at the <a href="https://www.gartner.com/en/conferences/na/security-risk-management-us">Gartner Security and Risk Management Summit</a> in National Harbor, MD, next week. Come see us in action if you’re attending the summit. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Adding Chrome Browser Cloud Management remediation actions in Splunk using Alert Actions&url=https://security.googleblog.com/2023/05/adding-chrome-browser-cloud-management.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2023/05/adding-chrome-browser-cloud-management.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2023/05/adding-chrome-browser-cloud-management.html' data-url='https://security.googleblog.com/2023/05/adding-chrome-browser-cloud-management.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2023/05/adding-chrome-browser-cloud-management.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20enterprise' rel='tag'> chrome enterprise </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='1446278575177326265' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2023/03/thank-you-and-goodbye-to-chrome-cleanup.html' itemprop='url' title='Thank you and goodbye to the Chrome Cleanup Tool'> Thank you and goodbye to the Chrome Cleanup Tool </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> March 8, 2023 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Jasika Bawa, Chrome Security Team </span> <p> Starting in Chrome 111 we will begin to turn down the Chrome Cleanup Tool, an application distributed to Chrome users on Windows to help find and remove unwanted software (UwS). </p> <h2>Origin story</h2> <p> The Chrome Cleanup Tool was introduced in 2015 to help users recover from unexpected settings changes, and to detect and remove unwanted software. To date, it has performed more than 80 million cleanups, helping to pave the way for a cleaner, safer web. </p> <h2>A changing landscape</h2> <p> In recent years, several factors have led us to reevaluate the need for this application to keep Chrome users on Windows safe. </p> <p> First, the user perspective – Chrome user complaints about UwS have continued to fall over the years, averaging out to around 3% of total complaints in the past year. Commensurate with this, we have observed a steady decline in UwS findings on users' machines. For example, last month just 0.06% of Chrome Cleanup Tool scans run by users detected known UwS. </p> <p> Next, several positive changes in the platform ecosystem have contributed to a more proactive safety stance than a reactive one. For example, <a href="https://safebrowsing.google.com/">Google Safe Browsing</a> as well as antivirus software both block file-based UwS more effectively now, which was originally the goal of the Chrome Cleanup Tool. Where file-based UwS migrated over to extensions, our substantial investments in the Chrome Web Store <a href="https://developer.chrome.com/docs/webstore/review-process/">review process</a> have helped catch malicious extensions that violate the Chrome Web Store's policies. </p> <p> Finally, we've observed changing trends in the malware space with techniques such as <a href="https://blog.google/threat-analysis-group/phishing-campaign-targets-youtube-creators-cookie-theft-malware/">Cookie Theft</a> on the rise – as such, we've doubled down on defenses against such malware via a variety of improvements including hardened authentication workflows and advanced heuristics for blocking phishing and social engineering emails, malware landing pages, and downloads. </p> <h2>What to expect</h2> <p> Starting in Chrome 111, users will no longer be able to request a Chrome Cleanup Tool scan through Safety Check or leverage the "Reset settings and cleanup" option offered in chrome://settings on Windows. Chrome will also remove the component that periodically scans Windows machines and prompts users for cleanup should it find anything suspicious. </p> <p> Even without the Chrome Cleanup Tool, users are automatically protected by <a href="https://support.google.com/chrome/answer/9890866?hl=en&co=GENIE.Platform%3DDesktop&oco=0">Safe Browsing in Chrome</a>. Users also have the option to turn on <a href="https://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html">Enhanced protection</a> by navigating to chrome://settings/security – this mode substantially increases protection from dangerous websites and downloads by sharing real-time data with Safe Browsing. </p> <p> While we'll miss the Chrome Cleanup Tool, we wanted to take this opportunity to acknowledge its role in combating UwS for the past 8 years. We'll continue to monitor user feedback and trends in the malware ecosystem, and when adversaries adapt their techniques again – which they will – we'll be at the ready. </p> <p> As always, please feel free to send us <a href="https://bugs.chromium.org/p/chromium/issues/list">feedback</a> or find us on Twitter <a href="https://twitter.com/googlechrome">@googlechrome</a>. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by Jasika Bawa, Chrome Security Team </span> <p> Starting in Chrome 111 we will begin to turn down the Chrome Cleanup Tool, an application distributed to Chrome users on Windows to help find and remove unwanted software (UwS). </p> <h2>Origin story</h2> <p> The Chrome Cleanup Tool was introduced in 2015 to help users recover from unexpected settings changes, and to detect and remove unwanted software. To date, it has performed more than 80 million cleanups, helping to pave the way for a cleaner, safer web. </p> <h2>A changing landscape</h2> <p> In recent years, several factors have led us to reevaluate the need for this application to keep Chrome users on Windows safe. </p> <p> First, the user perspective – Chrome user complaints about UwS have continued to fall over the years, averaging out to around 3% of total complaints in the past year. Commensurate with this, we have observed a steady decline in UwS findings on users' machines. For example, last month just 0.06% of Chrome Cleanup Tool scans run by users detected known UwS. </p> <p> Next, several positive changes in the platform ecosystem have contributed to a more proactive safety stance than a reactive one. For example, <a href="https://safebrowsing.google.com/">Google Safe Browsing</a> as well as antivirus software both block file-based UwS more effectively now, which was originally the goal of the Chrome Cleanup Tool. Where file-based UwS migrated over to extensions, our substantial investments in the Chrome Web Store <a href="https://developer.chrome.com/docs/webstore/review-process/">review process</a> have helped catch malicious extensions that violate the Chrome Web Store's policies. </p> <p> Finally, we've observed changing trends in the malware space with techniques such as <a href="https://blog.google/threat-analysis-group/phishing-campaign-targets-youtube-creators-cookie-theft-malware/">Cookie Theft</a> on the rise – as such, we've doubled down on defenses against such malware via a variety of improvements including hardened authentication workflows and advanced heuristics for blocking phishing and social engineering emails, malware landing pages, and downloads. </p> <h2>What to expect</h2> <p> Starting in Chrome 111, users will no longer be able to request a Chrome Cleanup Tool scan through Safety Check or leverage the "Reset settings and cleanup" option offered in chrome://settings on Windows. Chrome will also remove the component that periodically scans Windows machines and prompts users for cleanup should it find anything suspicious. </p> <p> Even without the Chrome Cleanup Tool, users are automatically protected by <a href="https://support.google.com/chrome/answer/9890866?hl=en&co=GENIE.Platform%3DDesktop&oco=0">Safe Browsing in Chrome</a>. Users also have the option to turn on <a href="https://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html">Enhanced protection</a> by navigating to chrome://settings/security – this mode substantially increases protection from dangerous websites and downloads by sharing real-time data with Safe Browsing. </p> <p> While we'll miss the Chrome Cleanup Tool, we wanted to take this opportunity to acknowledge its role in combating UwS for the past 8 years. We'll continue to monitor user feedback and trends in the malware ecosystem, and when adversaries adapt their techniques again – which they will – we'll be at the ready. </p> <p> As always, please feel free to send us <a href="https://bugs.chromium.org/p/chromium/issues/list">feedback</a> or find us on Twitter <a href="https://twitter.com/googlechrome">@googlechrome</a>. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Thank you and goodbye to the Chrome Cleanup Tool&url=https://security.googleblog.com/2023/03/thank-you-and-goodbye-to-chrome-cleanup.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2023/03/thank-you-and-goodbye-to-chrome-cleanup.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2023/03/thank-you-and-goodbye-to-chrome-cleanup.html' data-url='https://security.googleblog.com/2023/03/thank-you-and-goodbye-to-chrome-cleanup.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2023/03/thank-you-and-goodbye-to-chrome-cleanup.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='976481015804218737' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2023/01/sustaining-digital-certificate-security_13.html' itemprop='url' title='Sustaining Digital Certificate Security - TrustCor Certificate Distrust'> Sustaining Digital Certificate Security - TrustCor Certificate Distrust </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> January 13, 2023 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Chrome Root Program, Chrome Security Team</span> <p> <em>Note: This post is a follow-up to discussions carried out on the Mozilla “<a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy">Dev Security Policy</a>” Web PKI public discussion forum Google Group in December 2022. Google Chrome communicated its distrust of TrustCor in the public forum on December 15, 2022.</em> </p> <p> The Chrome Security Team prioritizes the security and privacy of Chrome’s users, and we are unwilling to compromise on these values. </p> <p> Google includes or removes CA certificates within the <a href="https://blog.chromium.org/2022/09/announcing-launch-of-chrome-root-program.html">Chrome Root Store</a> as it deems appropriate for user safety in accordance with our policies. The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome and promote interoperability. </p> <p> Behavior that attempts to degrade or subvert security and privacy on the web is incompatible with organizations whose CA certificates are included in the Chrome Root Store. Due to a loss of confidence in its ability to uphold these fundamental principles and to protect and safeguard Chrome’s users, certificates issued by TrustCor Systems will no longer be recognized as trusted by: </p> <ul> <li>Chrome versions 111 (landing in Beta approximately February 9, 2023 and Stable approximately March 7, 2023) and greater; and <li>Older versions of Chrome capable of receiving <a href="https://chromium.googlesource.com/chromium/src/+/lkgr/components/component_updater/README.md">Component Updates</a> after Chrome 111’s Stable release date. </li> </ul> <p> This change was <a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/PKpJf5W6AQAJ">first communicated</a> in the Mozilla “Dev Security Policy” Web PKI public discussion forum Google Group on December 15, 2022. </p> <p> This change will be implemented via our existing mechanisms to respond to CA incidents via: </p> <ul> <li>An integrated certificate blocklist, and <li>Removal of certificates included in the Chrome Root Store. </li> </ul> <p> Beginning approximately March 7, 2023, navigations to websites that use a certificate that chains to one of the roots detailed below will be considered insecure and result in a full page certificate error interstitial. </p> <p> Affected Certificates (SHA-256 fingerprint): </p> <ul> <li><a href="https://crt.sh/?q=d40e9c86cd8fe468c1776959f49ea774fa548684b6c406f3909261f4dce2575c">d40e9c86cd8fe468c1776959f49ea774fa548684b6c406f3909261f4dce2575c</a> <li><a href="https://crt.sh/?q=0753e940378c1bd5e3836e395daea5cb839e5046f1bd0eae1951cf10fec7c965">0753e940378c1bd5e3836e395daea5cb839e5046f1bd0eae1951cf10fec7c965</a> <li><a href="https://crt.sh/?q=5a885db19c01d912c5759388938cafbbdf031ab2d48e91ee15589b42971d039c">5a885db19c01d912c5759388938cafbbdf031ab2d48e91ee15589b42971d039c</a> </li> </ul> <p> This change will be integrated into the Chromium open-source project as part of a default build. Questions about the expected behavior in specific Chromium-based browsers should be directed to their maintainers. </p> <p> This change will be incorporated as part of the regular Chrome release process to ensure sufficient time for testing and replacing affected certificates by website operators. Information about release timetables and milestones is available at <a href="https://chromiumdash.appspot.com/schedule">https://chromiumdash.appspot.com/schedule</a>. </p> <p> Beginning approximately February 9, 2023, website operators can preview these changes in Chrome 111 Beta. Website operators will also be able to preview the change sooner, using our Dev and Canary channels. The majority of users will not encounter behavior changes until the release of Chrome 111 to the Stable channel, approximately March 7, 2023. </p> <p> <span style="text-decoration:underline;">Summarizing security response of other Google products:</span> </p> <ul> <li><strong>Android</strong> has removed TrustCor’s root CA certificates from the set of platform trusted certificates shipping with future operating system versions. Existing versions of Android will distrust TrustCor’s root CA certificates on a similar timeline as described above for Chrome. <li><strong>Gmail </strong>is finalizing its action plan and updates will be made available in the future. <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by Chrome Root Program, Chrome Security Team</span> <p> <em>Note: This post is a follow-up to discussions carried out on the Mozilla “<a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy">Dev Security Policy</a>” Web PKI public discussion forum Google Group in December 2022. Google Chrome communicated its distrust of TrustCor in the public forum on December 15, 2022.</em> </p> <p> The Chrome Security Team prioritizes the security and privacy of Chrome’s users, and we are unwilling to compromise on these values. </p> <p> Google includes or removes CA certificates within the <a href="https://blog.chromium.org/2022/09/announcing-launch-of-chrome-root-program.html">Chrome Root Store</a> as it deems appropriate for user safety in accordance with our policies. The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome and promote interoperability. </p> <p> Behavior that attempts to degrade or subvert security and privacy on the web is incompatible with organizations whose CA certificates are included in the Chrome Root Store. Due to a loss of confidence in its ability to uphold these fundamental principles and to protect and safeguard Chrome’s users, certificates issued by TrustCor Systems will no longer be recognized as trusted by: </p> <ul> <li>Chrome versions 111 (landing in Beta approximately February 9, 2023 and Stable approximately March 7, 2023) and greater; and <li>Older versions of Chrome capable of receiving <a href="https://chromium.googlesource.com/chromium/src/+/lkgr/components/component_updater/README.md">Component Updates</a> after Chrome 111’s Stable release date. </li> </ul> <p> This change was <a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/PKpJf5W6AQAJ">first communicated</a> in the Mozilla “Dev Security Policy” Web PKI public discussion forum Google Group on December 15, 2022. </p> <p> This change will be implemented via our existing mechanisms to respond to CA incidents via: </p> <ul> <li>An integrated certificate blocklist, and <li>Removal of certificates included in the Chrome Root Store. </li> </ul> <p> Beginning approximately March 7, 2023, navigations to websites that use a certificate that chains to one of the roots detailed below will be considered insecure and result in a full page certificate error interstitial. </p> <p> Affected Certificates (SHA-256 fingerprint): </p> <ul> <li><a href="https://crt.sh/?q=d40e9c86cd8fe468c1776959f49ea774fa548684b6c406f3909261f4dce2575c">d40e9c86cd8fe468c1776959f49ea774fa548684b6c406f3909261f4dce2575c</a> <li><a href="https://crt.sh/?q=0753e940378c1bd5e3836e395daea5cb839e5046f1bd0eae1951cf10fec7c965">0753e940378c1bd5e3836e395daea5cb839e5046f1bd0eae1951cf10fec7c965</a> <li><a href="https://crt.sh/?q=5a885db19c01d912c5759388938cafbbdf031ab2d48e91ee15589b42971d039c">5a885db19c01d912c5759388938cafbbdf031ab2d48e91ee15589b42971d039c</a> </li> </ul> <p> This change will be integrated into the Chromium open-source project as part of a default build. Questions about the expected behavior in specific Chromium-based browsers should be directed to their maintainers. </p> <p> This change will be incorporated as part of the regular Chrome release process to ensure sufficient time for testing and replacing affected certificates by website operators. Information about release timetables and milestones is available at <a href="https://chromiumdash.appspot.com/schedule">https://chromiumdash.appspot.com/schedule</a>. </p> <p> Beginning approximately February 9, 2023, website operators can preview these changes in Chrome 111 Beta. Website operators will also be able to preview the change sooner, using our Dev and Canary channels. The majority of users will not encounter behavior changes until the release of Chrome 111 to the Stable channel, approximately March 7, 2023. </p> <p> <span style="text-decoration:underline;">Summarizing security response of other Google products:</span> </p> <ul> <li><strong>Android</strong> has removed TrustCor’s root CA certificates from the set of platform trusted certificates shipping with future operating system versions. Existing versions of Android will distrust TrustCor’s root CA certificates on a similar timeline as described above for Chrome. <li><strong>Gmail </strong>is finalizing its action plan and updates will be made available in the future. <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Sustaining Digital Certificate Security - TrustCor Certificate Distrust&url=https://security.googleblog.com/2023/01/sustaining-digital-certificate-security_13.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2023/01/sustaining-digital-certificate-security_13.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2023/01/sustaining-digital-certificate-security_13.html' data-url='https://security.googleblog.com/2023/01/sustaining-digital-certificate-security_13.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2023/01/sustaining-digital-certificate-security_13.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='335024895422944819' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html' itemprop='url' title='Supporting the Use of Rust in the Chromium Project'> Supporting the Use of Rust in the Chromium Project </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> January 12, 2023 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Dana Jansens (she/her), Chrome Security Team </span> <p> We are pleased to announce that moving forward, the Chromium project is going to support the use of third-party Rust libraries from C++ in Chromium. To do so, we are now actively pursuing adding a <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1292038">production Rust toolchain</a> to our build system. This will enable us to include Rust code in the Chrome binary within the next year. We’re starting slow and setting clear expectations on <a href="https://chromium.googlesource.com/chromium/src/+/main/docs/adding_to_third_party.md#Rust">what libraries we will consider</a> once we’re ready. </p> <p> In this blog post, we will discuss how we arrived at the decision to support third-party Rust libraries at this time, and not broader usage of Rust in Chromium. </p> <p> <strong>Why We Chose to Bring Rust into Chromium</strong> </p> <p> Our goal in bringing Rust into Chromium is to <strong>provide a simpler</strong> (no IPC) and<strong> safer</strong> (less complex C++ overall, no memory safety bugs in a sandbox either) <strong>way to satisfy <a href="https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md">the rule of two</a>, in order to speed up development</strong> (less code to write, less design docs, less security review) <strong>and improve the security</strong> (increasing the number of lines of code without memory safety bugs, decreasing the bug density of code)<strong> of Chrome</strong>. And we believe that we can use third-party Rust libraries to work toward this goal. </p> <p> Rust was developed by Mozilla specifically for use in writing a browser, so it’s very fitting that Chromium would finally begin to rely on this technology too. Thank you Mozilla for your huge contribution to the systems software industry. Rust has been an incredible proof that we should be able to expect a language to provide safety while also being performant. </p> <p> <p> We know that C++ and Rust can play together nicely, through tools like <a href="https://github.com/dtolnay/cxx">cxx</a>, <a href="https://github.com/google/autocxx">autocxx</a> <a href="https://rust-lang.github.io/rust-bindgen/">bindgen</a>, <a href="https://github.com/eqrion/cbindgen">cbindgen</a>, <a href="https://github.com/rust-diplomat/diplomat">diplomat</a>, and (experimental) <a href="https://github.com/google/crubit">crubit</a>. However there are also limitations. We can expect that the shape of these limitations will change in time through new or improved tools, but the decisions and descriptions here are based on the current state of technology. </p> </p> <p> <strong>How Chromium Will Support the Use of Rust</strong> </p> <p> The Chrome Security team has been investing time into researching how we should approach using Rust alongside our C++ code. Understanding the implications of incrementally moving to writing Rust instead of C++, even in the middle of our software stack. What <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1296314">the limits</a> of safe, simple, and reliable interop might be. </p> <p> Based on our research, we landed on two outcomes for Chromium. </p> <ol> <li>We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++. <li>We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation. </li> </ol> <p> <strong>The Interop Between Rust and C++ in Chromium</strong> </p> <p> We have observed that most successful C/C++ and Rust interop stories to date have been built around interop through narrow APIs (e.g. libraries for <a href="https://github.com/cloudflare/quiche#calling-quiche-from-cc">QUIC</a> or <a href="https://cs.android.com/android/platform/superproject/+/master:packages/modules/Bluetooth/system/gd/rust/shim/src/bridge.rs">bluetooth</a>, Linux drivers) or through clearly isolated components (e.g. IDLs, IPCs). Chrome is built on foundational but <a href="https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/web_contents_observer.h">really wide C++ APIs</a>, such as the //content/public layer. We examined what it would mean for us to build Rust components against these types of APIs. At a high level what we found was that because C++ and Rust play by different rules, things can go sideways very easily. </p> <p> For example, Rust guarantees temporal memory safety with static analysis that relies on two inputs: <a href="https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html">lifetimes</a> (<a href="https://doc.rust-lang.org/reference/lifetime-elision.html">inferred</a> or explicitly written) and <a href="https://doc.rust-lang.org/rust-by-example/scope/borrow/alias.html">exclusive mutability</a>. The latter is incompatible with how the majority of Chromium’s C++ is written. We hold redundant mutable pointers throughout the system, and pointers that provide multiple paths to reach mutable pointers. We have <a href="https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/frame_tree_node.h;l=667;drc=1e6c1a39cbbc1dcad6e7828661d74d76463465ed">cyclical</a> <a href="https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.h;l=3714;drc=1e6c1a39cbbc1dcad6e7828661d74d76463465ed">mutable</a> data structures. This is especially true in our browser process, which contains a giant interconnected system of (mutable) pointers. If these C++ pointers were also used as Rust references in a complex or long-lived way, it would require our C++ authors to understand the aliasing rules of Rust and prevent the possibility of violating them, such as by: </p> <ul> <li>Returning the same mutable pointer from a function twice, where the first may still be held. <li>Passing overlapping pointers where one is mutable into Rust, in a way that they may be held as references at the same time. <li>Mutating state that is visible to Rust through a shared or mutable reference. </li> </ul> <p> Without interop tools providing support via the compiler and the type system, developers would need to understand all of the assumptions being made by Rust compiler, in order to not violate them from C++. In this framing, C++ is much like unsafe Rust. And while unsafe Rust is very costly to a project, its cost is managed by keeping it <a href="https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md#unsafe-code-in-safe-languages">encapsulated and to the minimum possible</a>. In the same way, the full complexity of C++ would need to be encapsulated from safe Rust. Narrow APIs designed for interop can provide similar encapsulation, and we hope that interop tools can provide encapsulation in other ways that allow wider APIs between the languages. </p> <p> The high-level summary is that without additional interop tooling support: </p> <ul> <li>Passing pointers/references across languages is risky. <li>Narrow interfaces between the languages is critical to make it feasible to write code correctly. </li> </ul> <p> Any cross-language interop between arbitrary code introduces difficulties where concepts in one language are not found in the other. For Rust calling into C++, support for language features like templates or inheritance can be difficult for a binding generator to support. For C++ calling into Rust, proc macros, and traits are examples that provide similar challenges. At times, the impedance mismatch represents intentional design choices made for either language, however they also imply limits on FFI (interop) between the languages. We rely on interop tools to model the ideas of each language in a way that makes sense to the other, or to disallow them. </p> <p> <strong>Accessing the Rust Ecosystem from Chromium</strong> </p> <p> These challenges present an opportunity, both to make interop easier and more seamless, but also to get access to a wider range of libraries from either language. Google is investing in <a href="https://github.com/google/crubit">Crubit</a>, an experiment in how to increase the fidelity of interop between C++ and Rust and express or encapsulate the requirements of each language to the other. </p> <p> The Rust ecosystem is incredibly important, especially to a security-focused open source project like Chromium. The ecosystem is enormous (96k+ crates on <a href="https://crates.io/">crates.io</a>) and growing, with <a href="https://www.abetterinternet.org/documents/2022-ISRG-Annual-Report.pdf">investment</a> from the systems development industry at large, including Google. Chrome relies heavily on third-party code, and we need to keep up with where that third-party investment is happening. It is critical that we build out support for including Rust into the Chromium project. </p> <p> We will be following this strategy to establish norms, and to maintain a level of API review through the third-party process, while we look to the future of interop support pushing the boundaries of what is possible and reasonable to do between Rust and C++. </p> <p> <br><strong>Some Other Related Content</strong> </p> <p> Memory unsafety is an industry-wide problem, and making use of Rust is one part of a strategy to move the needle in this area. Recently, <a href="https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html">Android</a> and <a href="https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/">Apple</a> have each published a great blog post on the subject if you’re interested in learning more. With Chrome’s millions of lines of C++, we’re still working hard to improve the safety of our C++ too, through projects such as <a href="https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html">MiraclePtr</a>. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by Dana Jansens (she/her), Chrome Security Team </span> <p> We are pleased to announce that moving forward, the Chromium project is going to support the use of third-party Rust libraries from C++ in Chromium. To do so, we are now actively pursuing adding a <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1292038">production Rust toolchain</a> to our build system. This will enable us to include Rust code in the Chrome binary within the next year. We’re starting slow and setting clear expectations on <a href="https://chromium.googlesource.com/chromium/src/+/main/docs/adding_to_third_party.md#Rust">what libraries we will consider</a> once we’re ready. </p> <p> In this blog post, we will discuss how we arrived at the decision to support third-party Rust libraries at this time, and not broader usage of Rust in Chromium. </p> <p> <strong>Why We Chose to Bring Rust into Chromium</strong> </p> <p> Our goal in bringing Rust into Chromium is to <strong>provide a simpler</strong> (no IPC) and<strong> safer</strong> (less complex C++ overall, no memory safety bugs in a sandbox either) <strong>way to satisfy <a href="https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md">the rule of two</a>, in order to speed up development</strong> (less code to write, less design docs, less security review) <strong>and improve the security</strong> (increasing the number of lines of code without memory safety bugs, decreasing the bug density of code)<strong> of Chrome</strong>. And we believe that we can use third-party Rust libraries to work toward this goal. </p> <p> Rust was developed by Mozilla specifically for use in writing a browser, so it’s very fitting that Chromium would finally begin to rely on this technology too. Thank you Mozilla for your huge contribution to the systems software industry. Rust has been an incredible proof that we should be able to expect a language to provide safety while also being performant. </p> <p> <p> We know that C++ and Rust can play together nicely, through tools like <a href="https://github.com/dtolnay/cxx">cxx</a>, <a href="https://github.com/google/autocxx">autocxx</a> <a href="https://rust-lang.github.io/rust-bindgen/">bindgen</a>, <a href="https://github.com/eqrion/cbindgen">cbindgen</a>, <a href="https://github.com/rust-diplomat/diplomat">diplomat</a>, and (experimental) <a href="https://github.com/google/crubit">crubit</a>. However there are also limitations. We can expect that the shape of these limitations will change in time through new or improved tools, but the decisions and descriptions here are based on the current state of technology. </p> </p> <p> <strong>How Chromium Will Support the Use of Rust</strong> </p> <p> The Chrome Security team has been investing time into researching how we should approach using Rust alongside our C++ code. Understanding the implications of incrementally moving to writing Rust instead of C++, even in the middle of our software stack. What <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1296314">the limits</a> of safe, simple, and reliable interop might be. </p> <p> Based on our research, we landed on two outcomes for Chromium. </p> <ol> <li>We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++. <li>We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation. </li> </ol> <p> <strong>The Interop Between Rust and C++ in Chromium</strong> </p> <p> We have observed that most successful C/C++ and Rust interop stories to date have been built around interop through narrow APIs (e.g. libraries for <a href="https://github.com/cloudflare/quiche#calling-quiche-from-cc">QUIC</a> or <a href="https://cs.android.com/android/platform/superproject/+/master:packages/modules/Bluetooth/system/gd/rust/shim/src/bridge.rs">bluetooth</a>, Linux drivers) or through clearly isolated components (e.g. IDLs, IPCs). Chrome is built on foundational but <a href="https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/web_contents_observer.h">really wide C++ APIs</a>, such as the //content/public layer. We examined what it would mean for us to build Rust components against these types of APIs. At a high level what we found was that because C++ and Rust play by different rules, things can go sideways very easily. </p> <p> For example, Rust guarantees temporal memory safety with static analysis that relies on two inputs: <a href="https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html">lifetimes</a> (<a href="https://doc.rust-lang.org/reference/lifetime-elision.html">inferred</a> or explicitly written) and <a href="https://doc.rust-lang.org/rust-by-example/scope/borrow/alias.html">exclusive mutability</a>. The latter is incompatible with how the majority of Chromium’s C++ is written. We hold redundant mutable pointers throughout the system, and pointers that provide multiple paths to reach mutable pointers. We have <a href="https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/frame_tree_node.h;l=667;drc=1e6c1a39cbbc1dcad6e7828661d74d76463465ed">cyclical</a> <a href="https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.h;l=3714;drc=1e6c1a39cbbc1dcad6e7828661d74d76463465ed">mutable</a> data structures. This is especially true in our browser process, which contains a giant interconnected system of (mutable) pointers. If these C++ pointers were also used as Rust references in a complex or long-lived way, it would require our C++ authors to understand the aliasing rules of Rust and prevent the possibility of violating them, such as by: </p> <ul> <li>Returning the same mutable pointer from a function twice, where the first may still be held. <li>Passing overlapping pointers where one is mutable into Rust, in a way that they may be held as references at the same time. <li>Mutating state that is visible to Rust through a shared or mutable reference. </li> </ul> <p> Without interop tools providing support via the compiler and the type system, developers would need to understand all of the assumptions being made by Rust compiler, in order to not violate them from C++. In this framing, C++ is much like unsafe Rust. And while unsafe Rust is very costly to a project, its cost is managed by keeping it <a href="https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md#unsafe-code-in-safe-languages">encapsulated and to the minimum possible</a>. In the same way, the full complexity of C++ would need to be encapsulated from safe Rust. Narrow APIs designed for interop can provide similar encapsulation, and we hope that interop tools can provide encapsulation in other ways that allow wider APIs between the languages. </p> <p> The high-level summary is that without additional interop tooling support: </p> <ul> <li>Passing pointers/references across languages is risky. <li>Narrow interfaces between the languages is critical to make it feasible to write code correctly. </li> </ul> <p> Any cross-language interop between arbitrary code introduces difficulties where concepts in one language are not found in the other. For Rust calling into C++, support for language features like templates or inheritance can be difficult for a binding generator to support. For C++ calling into Rust, proc macros, and traits are examples that provide similar challenges. At times, the impedance mismatch represents intentional design choices made for either language, however they also imply limits on FFI (interop) between the languages. We rely on interop tools to model the ideas of each language in a way that makes sense to the other, or to disallow them. </p> <p> <strong>Accessing the Rust Ecosystem from Chromium</strong> </p> <p> These challenges present an opportunity, both to make interop easier and more seamless, but also to get access to a wider range of libraries from either language. Google is investing in <a href="https://github.com/google/crubit">Crubit</a>, an experiment in how to increase the fidelity of interop between C++ and Rust and express or encapsulate the requirements of each language to the other. </p> <p> The Rust ecosystem is incredibly important, especially to a security-focused open source project like Chromium. The ecosystem is enormous (96k+ crates on <a href="https://crates.io/">crates.io</a>) and growing, with <a href="https://www.abetterinternet.org/documents/2022-ISRG-Annual-Report.pdf">investment</a> from the systems development industry at large, including Google. Chrome relies heavily on third-party code, and we need to keep up with where that third-party investment is happening. It is critical that we build out support for including Rust into the Chromium project. </p> <p> We will be following this strategy to establish norms, and to maintain a level of API review through the third-party process, while we look to the future of interop support pushing the boundaries of what is possible and reasonable to do between Rust and C++. </p> <p> <br><strong>Some Other Related Content</strong> </p> <p> Memory unsafety is an industry-wide problem, and making use of Rust is one part of a strategy to move the needle in this area. Recently, <a href="https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html">Android</a> and <a href="https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/">Apple</a> have each published a great blog post on the subject if you’re interested in learning more. With Chrome’s millions of lines of C++, we’re still working hard to improve the safety of our C++ too, through projects such as <a href="https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html">MiraclePtr</a>. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Supporting the Use of Rust in the Chromium Project&url=https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html' data-url='https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='5921013497020816147' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html' itemprop='url' title='Enhanced Protection - The strongest level of Safe Browsing protection Google Chrome has to offer'> Enhanced Protection - The strongest level of Safe Browsing protection Google Chrome has to offer </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> December 5, 2022 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Benjamin Ackerman, Chrome Security and Jonathan Li, Safe Browsing </span> <p> As a follow-up to a previous blog post about <a href="https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-works-in.html">How Hash-Based Safe Browsing Works in Google Chrome</a>, we wanted to provide more details about Safe Browsing’s Enhanced Protection mode in Chrome. Specifically, how it came about, the protections that are offered and what it means for your data. </p> <p> Security and privacy have always been top of mind for Chrome. Our goal is to make security effortless for you while browsing the web, so that you can go about your day without having to worry about the links that you click on or the files that you download. This is why <a href="https://safebrowsing.google.com/">Safe Browsing</a>’s phishing and malware protections have been a core part of Chrome since 2007. You may have seen these in action if you have ever come across one of our red warning pages. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuXzAK2S5bUWwetyCEnMg0OAiHPx5eknMyaQuPmFbx4lks-Vns4Ih0tLS5NNgAiTXvqFDwFSjcv0kDdePKdYY3_r86llYn4XL1hVdU0-sOUvnpDf-nMaw7F1Z5k_rsZm_Dsh5YAykKD4DBl3tSOMGwW2vxrqFIpgAi9NErU1gEP0-ekigIG5wBFm-8QQ/s1600/Enhanced%20Safe%20Browsing_Warning%20page%28iOS%29%20Mobile%20and%20Desktop.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="2250" data-original-width="4101" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuXzAK2S5bUWwetyCEnMg0OAiHPx5eknMyaQuPmFbx4lks-Vns4Ih0tLS5NNgAiTXvqFDwFSjcv0kDdePKdYY3_r86llYn4XL1hVdU0-sOUvnpDf-nMaw7F1Z5k_rsZm_Dsh5YAykKD4DBl3tSOMGwW2vxrqFIpgAi9NErU1gEP0-ekigIG5wBFm-8QQ/s1600/Enhanced%20Safe%20Browsing_Warning%20page%28iOS%29%20Mobile%20and%20Desktop.png"/></a></div> </p> <p> We show these warnings whenever we believe a site that you are trying to visit or file that you are trying to download might put you at risk for an attack. To give you a better understanding of how the Enhanced Protection mode in Safe Browsing provides the strongest level of defense it’s useful to know what is offered in Standard Protection. </p> <h2>Standard Protection</h2> <p> Enabled by default in Chrome, Standard Protection was designed to be privacy preserving at its core by using hash-based checks. This has been effective at protecting users by warning millions of users about dangerous websites. However, hash-based checks are inherently limited as they rely on lookups to a list of known bad sites. We see malicious actors moving fast and constantly evolving their tactics to avoid detection using sophisticated techniques. To counter this, we created a stronger and more customized level of protection that we could offer to users. To this end, we launched <a href="https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html">Enhanced Protection</a> in 2020, which builds upon the Standard Protection mode in Safe Browsing to keep you safer. </p> <h2>Enhanced Protection</h2> <p> This is the fastest and strongest level of protection against dangerous sites and downloads that Safe Browsing offers in Chrome. It enables more advanced detection techniques that adapt quickly as malicious activity evolves. As a result, Enhanced Protection users are phished 20-35% less than users on Standard Protection. A few of these features include: </p> <ul> <li><strong>Real time URL checks: </strong>By checking with Google Safe Browsing’s servers in real time before navigating to an uncommon site you’re visiting, Chrome provides the best protection against dangerous sites and uses advanced machine learning models to continuously stay up to date. <li><strong>File checks before downloading:</strong> In addition to Chrome’s standard checks of downloaded files, Enhanced Protection users can choose to upload suspicious files to be scanned by Google Safe Browsing’s full suite of malware detection technology before opening the file. This helps catch brand new malware that Safe Browsing has not scanned before or dangerous files hosted on a brand new site. <li><strong>More advanced vision-based phishing detection:</strong> To better detect phishing and dangerous sites for Enhanced Protection users, Chrome performs basic client-side checks on the web page to determine if it is suspicious. For pages deemed suspicious, Chrome sends a small set of visual features derived from the page to Google’s Safe Browsing servers for additional phishing classification using computer vision. This helps Chrome more accurately recognize dangerous sites, and can warn other users before they visit the site. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYKo2fmjwtsXgO5jCijjCDsC-xoVAObaHe1InslUraHyxbv6UmccdJb0ARkCsGpFiWzMMqUTUyiZwjnOIBdqfdKQ-2FswDlqirTtscoq817LsKEnmQTAETtJvnFYMs1fJ5f7SqCCxagAaF9DiIhUiKfqzfo9XGv6pY-CutpyioyTFYca1FsYIPKYZbog/s1600/last%20gif.gif" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1080" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYKo2fmjwtsXgO5jCijjCDsC-xoVAObaHe1InslUraHyxbv6UmccdJb0ARkCsGpFiWzMMqUTUyiZwjnOIBdqfdKQ-2FswDlqirTtscoq817LsKEnmQTAETtJvnFYMs1fJ5f7SqCCxagAaF9DiIhUiKfqzfo9XGv6pY-CutpyioyTFYca1FsYIPKYZbog/s1600/last%20gif.gif"/></a></div> <h2>User data privacy and security</h2> <p> By opting into Enhanced Protection, you are sharing additional data with Safe Browsing systems that allow us to offer better and faster security both for you, and for all users online. Ensuring user privacy is of utmost importance for us and we go through great lengths to anonymize as much of the data as possible. This data is only used for security purposes and only retained for a short period of time. As threats evolve we will continuously add and improve our existing protections for Enhanced Protection users. These features go through extensive privacy reviews to ensure that your privacy continues to be prioritized while still providing you the highest level of security possible. </p> <h2>How to enable</h2> <p> Safe Browsing’s Enhanced Protection is currently available for all desktop platforms, Android devices and now iOS mobile devices. It can be enabled by navigating to the Privacy and Security option located in Chrome settings. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2xYRWujcy2-WH0OiDhrb6uKtVm13Hkhe2Dbn1jaq1kra0aSGsbCwg9TcIhctg63sKhL4S12kKWrAON2o2TZzaUnIes1fWp8g0J6RqvzJTV8ReAI91cKt4pfuK3FG_1f7zujifo0N5kPLky81fnhsdTaKQsliAeF_08MKmp7ep-7z3bzPdDQb80J-dPA/s1600/Chrome_Enhance%20Safe%20Browsing_iOS_Opt%20in.gif" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1080" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2xYRWujcy2-WH0OiDhrb6uKtVm13Hkhe2Dbn1jaq1kra0aSGsbCwg9TcIhctg63sKhL4S12kKWrAON2o2TZzaUnIes1fWp8g0J6RqvzJTV8ReAI91cKt4pfuK3FG_1f7zujifo0N5kPLky81fnhsdTaKQsliAeF_08MKmp7ep-7z3bzPdDQb80J-dPA/s1600/Chrome_Enhance%20Safe%20Browsing_iOS_Opt%20in.gif"/></a></div> <p> For enterprise admins, you have the option of enabling Enhanced Safe Browsing on your managed devices using the<a href="https://chromeenterprise.google/policies/#SafeBrowsingProtectionLevel"> SafeBrowsingProtectionLevel</a> policy and in the Admin Console. </p> <p> For more details and updates about Safe Browsing and its Enhanced Protection mode, please visit our <a href="http://safebrowsing.google.com">Google Safe Browsing</a> website and follow the Google Security Blog for updates on new features. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author">Posted by Benjamin Ackerman, Chrome Security and Jonathan Li, Safe Browsing </span> <p> As a follow-up to a previous blog post about <a href="https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-works-in.html">How Hash-Based Safe Browsing Works in Google Chrome</a>, we wanted to provide more details about Safe Browsing’s Enhanced Protection mode in Chrome. Specifically, how it came about, the protections that are offered and what it means for your data. </p> <p> Security and privacy have always been top of mind for Chrome. Our goal is to make security effortless for you while browsing the web, so that you can go about your day without having to worry about the links that you click on or the files that you download. This is why <a href="https://safebrowsing.google.com/">Safe Browsing</a>’s phishing and malware protections have been a core part of Chrome since 2007. You may have seen these in action if you have ever come across one of our red warning pages. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuXzAK2S5bUWwetyCEnMg0OAiHPx5eknMyaQuPmFbx4lks-Vns4Ih0tLS5NNgAiTXvqFDwFSjcv0kDdePKdYY3_r86llYn4XL1hVdU0-sOUvnpDf-nMaw7F1Z5k_rsZm_Dsh5YAykKD4DBl3tSOMGwW2vxrqFIpgAi9NErU1gEP0-ekigIG5wBFm-8QQ/s1600/Enhanced%20Safe%20Browsing_Warning%20page%28iOS%29%20Mobile%20and%20Desktop.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="2250" data-original-width="4101" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuXzAK2S5bUWwetyCEnMg0OAiHPx5eknMyaQuPmFbx4lks-Vns4Ih0tLS5NNgAiTXvqFDwFSjcv0kDdePKdYY3_r86llYn4XL1hVdU0-sOUvnpDf-nMaw7F1Z5k_rsZm_Dsh5YAykKD4DBl3tSOMGwW2vxrqFIpgAi9NErU1gEP0-ekigIG5wBFm-8QQ/s1600/Enhanced%20Safe%20Browsing_Warning%20page%28iOS%29%20Mobile%20and%20Desktop.png"/></a></div> </p> <p> We show these warnings whenever we believe a site that you are trying to visit or file that you are trying to download might put you at risk for an attack. To give you a better understanding of how the Enhanced Protection mode in Safe Browsing provides the strongest level of defense it’s useful to know what is offered in Standard Protection. </p> <h2>Standard Protection</h2> <p> Enabled by default in Chrome, Standard Protection was designed to be privacy preserving at its core by using hash-based checks. This has been effective at protecting users by warning millions of users about dangerous websites. However, hash-based checks are inherently limited as they rely on lookups to a list of known bad sites. We see malicious actors moving fast and constantly evolving their tactics to avoid detection using sophisticated techniques. To counter this, we created a stronger and more customized level of protection that we could offer to users. To this end, we launched <a href="https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html">Enhanced Protection</a> in 2020, which builds upon the Standard Protection mode in Safe Browsing to keep you safer. </p> <h2>Enhanced Protection</h2> <p> This is the fastest and strongest level of protection against dangerous sites and downloads that Safe Browsing offers in Chrome. It enables more advanced detection techniques that adapt quickly as malicious activity evolves. As a result, Enhanced Protection users are phished 20-35% less than users on Standard Protection. A few of these features include: </p> <ul> <li><strong>Real time URL checks: </strong>By checking with Google Safe Browsing’s servers in real time before navigating to an uncommon site you’re visiting, Chrome provides the best protection against dangerous sites and uses advanced machine learning models to continuously stay up to date. <li><strong>File checks before downloading:</strong> In addition to Chrome’s standard checks of downloaded files, Enhanced Protection users can choose to upload suspicious files to be scanned by Google Safe Browsing’s full suite of malware detection technology before opening the file. This helps catch brand new malware that Safe Browsing has not scanned before or dangerous files hosted on a brand new site. <li><strong>More advanced vision-based phishing detection:</strong> To better detect phishing and dangerous sites for Enhanced Protection users, Chrome performs basic client-side checks on the web page to determine if it is suspicious. For pages deemed suspicious, Chrome sends a small set of visual features derived from the page to Google’s Safe Browsing servers for additional phishing classification using computer vision. This helps Chrome more accurately recognize dangerous sites, and can warn other users before they visit the site. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYKo2fmjwtsXgO5jCijjCDsC-xoVAObaHe1InslUraHyxbv6UmccdJb0ARkCsGpFiWzMMqUTUyiZwjnOIBdqfdKQ-2FswDlqirTtscoq817LsKEnmQTAETtJvnFYMs1fJ5f7SqCCxagAaF9DiIhUiKfqzfo9XGv6pY-CutpyioyTFYca1FsYIPKYZbog/s1600/last%20gif.gif" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1080" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYKo2fmjwtsXgO5jCijjCDsC-xoVAObaHe1InslUraHyxbv6UmccdJb0ARkCsGpFiWzMMqUTUyiZwjnOIBdqfdKQ-2FswDlqirTtscoq817LsKEnmQTAETtJvnFYMs1fJ5f7SqCCxagAaF9DiIhUiKfqzfo9XGv6pY-CutpyioyTFYca1FsYIPKYZbog/s1600/last%20gif.gif"/></a></div> <h2>User data privacy and security</h2> <p> By opting into Enhanced Protection, you are sharing additional data with Safe Browsing systems that allow us to offer better and faster security both for you, and for all users online. Ensuring user privacy is of utmost importance for us and we go through great lengths to anonymize as much of the data as possible. This data is only used for security purposes and only retained for a short period of time. As threats evolve we will continuously add and improve our existing protections for Enhanced Protection users. These features go through extensive privacy reviews to ensure that your privacy continues to be prioritized while still providing you the highest level of security possible. </p> <h2>How to enable</h2> <p> Safe Browsing’s Enhanced Protection is currently available for all desktop platforms, Android devices and now iOS mobile devices. It can be enabled by navigating to the Privacy and Security option located in Chrome settings. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2xYRWujcy2-WH0OiDhrb6uKtVm13Hkhe2Dbn1jaq1kra0aSGsbCwg9TcIhctg63sKhL4S12kKWrAON2o2TZzaUnIes1fWp8g0J6RqvzJTV8ReAI91cKt4pfuK3FG_1f7zujifo0N5kPLky81fnhsdTaKQsliAeF_08MKmp7ep-7z3bzPdDQb80J-dPA/s1600/Chrome_Enhance%20Safe%20Browsing_iOS_Opt%20in.gif" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1080" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2xYRWujcy2-WH0OiDhrb6uKtVm13Hkhe2Dbn1jaq1kra0aSGsbCwg9TcIhctg63sKhL4S12kKWrAON2o2TZzaUnIes1fWp8g0J6RqvzJTV8ReAI91cKt4pfuK3FG_1f7zujifo0N5kPLky81fnhsdTaKQsliAeF_08MKmp7ep-7z3bzPdDQb80J-dPA/s1600/Chrome_Enhance%20Safe%20Browsing_iOS_Opt%20in.gif"/></a></div> <p> For enterprise admins, you have the option of enabling Enhanced Safe Browsing on your managed devices using the<a href="https://chromeenterprise.google/policies/#SafeBrowsingProtectionLevel"> SafeBrowsingProtectionLevel</a> policy and in the Admin Console. </p> <p> For more details and updates about Safe Browsing and its Enhanced Protection mode, please visit our <a href="http://safebrowsing.google.com">Google Safe Browsing</a> website and follow the Google Security Blog for updates on new features. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Enhanced Protection - The strongest level of Safe Browsing protection Google Chrome has to offer&url=https://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html' data-url='https://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='3294366029953017136' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html' itemprop='url' title='Use-after-freedom: MiraclePtr'> Use-after-freedom: MiraclePtr </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> September 13, 2022 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author"> Posted by Adrian Taylor, Bartek Nowierski and Kentaro Hara on behalf of the MiraclePtr team</span> <p> Memory safety bugs are the most numerous category of Chrome security issues and we’re continuing to <a href="https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html">investigate many solutions</a> – both in C++ and in new programming languages. The most common type of memory safety bug is the “use-after-free”. We <a href="https://security.googleblog.com/2022/05/retrofitting-temporal-memory-safety-on-c.html">recently posted about</a> an exciting series of technologies designed to prevent these. Those technologies (collectively, *Scan, pronounced “star scan”) are very powerful but likely require hardware support for sufficient performance. </p> <p> Today we’re going to talk about a different approach to solving the same type of bugs. </p> <p> It’s hard, if not impossible, to avoid use-after-frees in a non-trivial codebase. It’s rarely a mistake by a single programmer. Instead, one programmer makes reasonable assumptions about how a bit of code will work, then a later change invalidates those assumptions. Suddenly, the data isn’t valid as long as the original programmer expected, and an exploitable bug results. </p> <p> These bugs have real consequences. For example, according to Google Threat Analysis Group, a <a href="https://crbug.com/1296150">use-after-free in the ChromeHTML engine</a> was <a href="https://blog.google/threat-analysis-group/countering-threats-north-korea/">exploited this year</a> by North Korea. </p> <p> Half of the known exploitable bugs in Chrome are use-after-frees: <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjol0tDHrKfloO3-RsAhVwMGPRBFmg8FmM2nMbHfA4kPTHu4PVaoqFAkdKXkE63ePSIC4U4rH8pMSa8FfLYY-0CdahMPzcP_GqoILj0bBtquIwVuf-oLRpnZqe6cNBgTHv6LPnM_l1YrkqPHote0DMbIkYy7BZjDiZITG2u05T9YoxV6OqhnonD1TlY9g/s512/bug%20types.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="317" data-original-width="512" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjol0tDHrKfloO3-RsAhVwMGPRBFmg8FmM2nMbHfA4kPTHu4PVaoqFAkdKXkE63ePSIC4U4rH8pMSa8FfLYY-0CdahMPzcP_GqoILj0bBtquIwVuf-oLRpnZqe6cNBgTHv6LPnM_l1YrkqPHote0DMbIkYy7BZjDiZITG2u05T9YoxV6OqhnonD1TlY9g/s600/bug%20types.png" width="600"/></a></div> <p> <strong>Diving Deeper: Not All Use-After-Free Bugs Are Equal</strong> </p> <p> Chrome has a <a href="https://www.chromium.org/developers/design-documents/multi-process-architecture/">multi-process architecture</a>, partly to ensure that web content is isolated into a sandboxed “renderer” process where little harm can occur. An attacker therefore usually needs to find and exploit <em>two</em> vulnerabilities - one to achieve code execution in the renderer process, and another bug to break out of the sandbox. </p> <p> The first stage is often the easier one. The attacker has lots of influence in the renderer process. It’s easy to arrange memory in a specific way, and the renderer process acts upon many different kinds of web content, giving a large “attack surface” that could potentially be exploited. </p> <p> The second stage, escaping the renderer sandbox, is trickier. Attackers have two options how to do this: </p> <ol> <li>They can exploit a bug in the underlying operating system (OS) through the limited interfaces available inside Chrome’s sandbox. <li>Or, they can exploit a bug in a more powerful, privileged part of Chrome - like the “browser” process. This process coordinates all the other bits of Chrome, so fundamentally <em>has</em> to be all-powerful. </li> </ol> <p> We imagine the attackers squeezing through the narrow part of a funnel: <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrD_PVCwSIrVn0tVWBs7b0PueDknbg8BrwznIfKHmYqgNFlGuVupFVZaPMSO9uoj4QawGujzyOS42-Nsemdl9AXD3gOaUFeqnBkhVd0Aem99UK5C9bt6trfnF_4UplnWFdXUrXfM-P4QvnZq81lrsz8o7M6QLZaKzSSLm7_ni10BPT2xaLSyhITCHE9A/s1600/Screenshot%202022-09-13%207.28.31%20AM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="405" data-original-width="646" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrD_PVCwSIrVn0tVWBs7b0PueDknbg8BrwznIfKHmYqgNFlGuVupFVZaPMSO9uoj4QawGujzyOS42-Nsemdl9AXD3gOaUFeqnBkhVd0Aem99UK5C9bt6trfnF_4UplnWFdXUrXfM-P4QvnZq81lrsz8o7M6QLZaKzSSLm7_ni10BPT2xaLSyhITCHE9A/s1600/Screenshot%202022-09-13%207.28.31%20AM.png"/></a></div> If we can reduce the size of the narrow part of the funnel, we will make it as hard as possible for attackers to assemble a full exploit chain. We can reduce the size of the orange slice by removing access to more OS interfaces within the renderer process sandbox, and we’re continuously working on that. The MiraclePtr project aims to reduce the size of the blue slice. </p> <p> Here’s a sample of 100 recent high severity Chrome security bugs that made it to the stable channel, divided by root cause and by the process they affect. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNa-V0mokSe10I_waRxQNuH_GNg6kqPyAszlWZ2EqMIgiySJcLWQ_FQQYSCl5dnF-u7acqGaqNE1bKXKJGG9b2GKKzIDMrKQWPhJWdp-0Te2HZYOecDVpLJXamMCzdO8ErcezDkFly1D19YlPrPHDHDf01O8GisMqoCOnfsAK8jWl9W8_JeUDJglHLNw/s512/bugs%20chart%202.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="317" data-original-width="512" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNa-V0mokSe10I_waRxQNuH_GNg6kqPyAszlWZ2EqMIgiySJcLWQ_FQQYSCl5dnF-u7acqGaqNE1bKXKJGG9b2GKKzIDMrKQWPhJWdp-0Te2HZYOecDVpLJXamMCzdO8ErcezDkFly1D19YlPrPHDHDf01O8GisMqoCOnfsAK8jWl9W8_JeUDJglHLNw/s600/bugs%20chart%202.png" width="600"/></a></div> </p> <p> You might notice: </p> <ul> <li>This doesn’t quite add up to 100 - that’s because a few bugs were in other processes beyond the renderer or browser. <li>We claimed that the browser process is the more difficult part to exploit, yet there are more potentially-exploitable bugs! That may be so, but we believe they are typically harder to exploit because the attacker has less control over memory layout. </li> </ul> <p> As you can see, the biggest category of bugs in each process is: V8 in the renderer process (JavaScript engine logic bugs - <a href="https://docs.google.com/document/d/1FM4fQmIhEqPG8uGp5o9A-mnPB5BOeScZYpkHjo0KKA8/edit">work in progress</a>) and use-after-free bugs in the browser process. If we can make that “thin” bit thinner still by removing some of those use-after-free bugs, we make the whole job of Chrome exploitation markedly harder. </p> <p> <strong>MiraclePtr: Preventing Exploitation of Use-After-Free Bugs</strong> </p> <p> This is where <a href="https://docs.google.com/document/d/1pnnOAIz_DMWDI4oIOFoMAqLnf_MZ2GsrJNb_dbQ3ZBg/edit">MiraclePtr</a> comes in. It is a technology to prevent exploitation of use-after-free bugs. Unlike aforementioned *Scan technologies that offer a non-invasive approach to this problem, MiraclePtr relies on rewriting the codebase to use a new smart pointer type, <a href="https://chromium.googlesource.com/chromium/src/+/main/base/memory/raw_ptr.md">raw_ptr<T></a>. There are multiple ways to implement MiraclePtr. We came up with <a href="https://docs.google.com/document/d/1qsPh8Bcrma7S-5fobbCkBkXWaAijXOnorEqvIIGKzc0/edit">~10 algorithms</a> and compared the pros and cons. After analyzing their performance overhead, memory overhead, security protection guarantees, developer ergonomics, etc., we concluded that BackupRefPtr was the most promising solution. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqjNDqH-vs-iOJi4MZ8xgPNPFQin31tNdn0Ixh2w9wEKgTWB0KDsRBFg47IRrLsZ1BMSFAY0a1rmCUf5ETwzhUicglI4S9Lq6ue9h0UiK9vXX5WF6ZPVdEFSvDMGQOsLJ6MI0ZlyRbMCkd58hLxNBOy5FobolQUuyj7o6gYA2lZFDLt9QO_VLTpLJ1cA/s512/raw1.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="484" data-original-width="512" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqjNDqH-vs-iOJi4MZ8xgPNPFQin31tNdn0Ixh2w9wEKgTWB0KDsRBFg47IRrLsZ1BMSFAY0a1rmCUf5ETwzhUicglI4S9Lq6ue9h0UiK9vXX5WF6ZPVdEFSvDMGQOsLJ6MI0ZlyRbMCkd58hLxNBOy5FobolQUuyj7o6gYA2lZFDLt9QO_VLTpLJ1cA/s200/raw1.png" width="200"/></a></div> The BackupRefPtr algorithm is based on reference counting. It uses support of Chrome's own heap allocator, <a href="https://chromium.googlesource.com/chromium/src/+/main/base/allocator/partition_allocator/PartitionAlloc.md">PartitionAlloc</a>, which carves out a little extra space for a hidden reference count for each allocation. raw_ptr<T> increments or decrements the reference count when it’s constructed, destroyed or modified. When the application calls free/delete and the reference count is greater than 0, PartitionAlloc quarantines that memory region instead of immediately releasing it. The memory region is then only made available for reuse once the reference count reaches 0. Quarantined memory is poisoned to further reduce the likelihood that use-after-free accesses will result in exploitable conditions, and in hope that future accesses lead to an easy-to-debug crash, turning these security issues into less-dangerous ones. </p> <pre class="prettyprint">class A { ... }; class B { B(A* a) : a_(a) {} void doSomething() { a_->doSomething(); } raw_ptr<A> a_; // MiraclePtr }; std::unique_ptr<A> a = std::make_unique<A>(); std::unique_ptr<B> b = std::make_unique<B>(a.get()); […] a = nullptr; // The free is delayed because the MiraclePtr is still pointing to the object. b->doSomething(); // Use-after-free is neutralized.</pre> <p> We successfully <a href="https://chromium-review.googlesource.com/c/chromium/src/+/3305132">rewrote more than 15,000 raw pointers</a> in the Chrome codebase into raw_ptr<T>, then enabled BackupRefPtr for the browser process on Windows and Android (both 64 bit and 32 bit) in Chrome 102 Stable. We anticipate that MiraclePtr meaningfully reduces the browser process attack surface of Chrome by protecting ~50% of use-after-free issues against exploitation. We are now working on enabling BackupRefPtr in the network, utility and GPU processes, and for other platforms. In the end state, our goal is to enable BackupRefPtr on <em>all</em> platforms because that ensures that a given pointer is protected for <em>all</em> users of Chrome. </p> <p> <strong>Balancing Security and Performance</strong> </p> <p> There is no free lunch, however. This security protection comes at a cost, which we have carefully weighed in our decision making. </p> <p> Unsurprisingly, the main cost is memory. Luckily, related investments into PartitionAlloc over the past year led to 10-25% total memory savings, depending on usage patterns and platforms. So we were able to spend some of those savings on security: MiraclePtr increased the memory usage of the browser process 4.5-6.5% on Windows and 3.5-5% on Android<sup>1</sup>, still well below their previous levels. While we were worried about quarantined memory, in practice this is a tiny fraction (0.01%) of the browser process usage. By far the bigger culprit is the additional memory needed to store the reference count. One might think that adding 4 bytes to each allocation wouldn’t be a big deal. However, there are many small allocations in Chrome, so even the 4B overhead is not negligible. PartitionAlloc also uses pre-defined bucket sizes, so this extra 4B pushes certain allocations (particularly power-of-2 sized) into a larger bucket, e.g. 4096B->5120B. </p> <p> We also considered the performance cost. Adding an atomic increment/decrement on common operations such as pointer assignment has unavoidable overhead. Having excluded a number of performance-critical pointers, we drove this overhead down until we could gain back the same margin through other performance optimizations. On Windows, no statistically significant performance regressions were observed on most of our top-level performance metrics like Largest Contentful Paint, First Input Delay, etc. The only adverse change there<sup>1</sup> is an increase of the main thread contention (~7%). On Android<sup>1</sup>, in addition to a similar increase in the main thread contention (~6%), there were small regressions in First Input Delay (~1%), Input Delay (~3%) and First Contentful Paint (~0.5%). We don't anticipate these regressions to have a noticeable impact on user experience, and are confident that they are strongly outweighed by the additional safety for our users. </p> <p> We should emphasize that MiraclePtr currently protects only class/struct pointer fields, to minimize the overhead. As future work, we are exploring options to expand the pointer coverage to on-stack pointers so that we can protect against more use-after-free bugs. </p> <p> Note that the primary goal of MiraclePtr is to prevent exploitation of use-after-free bugs. Although it wasn’t designed for diagnosability, it already helped us find and fix a number of bugs that were previously undetected. We have ongoing efforts to make MiraclePtr crash reports even more informative and actionable. </p> <p> <strong>Continue to Provide Us Feedback</strong> </p> <p> Last but not least, we’d like to encourage security researchers to continue to report issues through the <a href="https://g.co/ChromeBugRewards">Chrome Vulnerability Reward Program</a>, even if those issues are mitigated by MiraclePtr. We still need to make MiraclePtr available to all users, collect more data on its impact through reported issues, and further refine our processes and tooling. Until that is done, we will not consider MiraclePtr when determining the severity of a bug or the reward amount. </p> <p> <sup>1</sup> Measured in Chrome 99. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <span class="byline-author"> Posted by Adrian Taylor, Bartek Nowierski and Kentaro Hara on behalf of the MiraclePtr team</span> <p> Memory safety bugs are the most numerous category of Chrome security issues and we’re continuing to <a href="https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html">investigate many solutions</a> – both in C++ and in new programming languages. The most common type of memory safety bug is the “use-after-free”. We <a href="https://security.googleblog.com/2022/05/retrofitting-temporal-memory-safety-on-c.html">recently posted about</a> an exciting series of technologies designed to prevent these. Those technologies (collectively, *Scan, pronounced “star scan”) are very powerful but likely require hardware support for sufficient performance. </p> <p> Today we’re going to talk about a different approach to solving the same type of bugs. </p> <p> It’s hard, if not impossible, to avoid use-after-frees in a non-trivial codebase. It’s rarely a mistake by a single programmer. Instead, one programmer makes reasonable assumptions about how a bit of code will work, then a later change invalidates those assumptions. Suddenly, the data isn’t valid as long as the original programmer expected, and an exploitable bug results. </p> <p> These bugs have real consequences. For example, according to Google Threat Analysis Group, a <a href="https://crbug.com/1296150">use-after-free in the ChromeHTML engine</a> was <a href="https://blog.google/threat-analysis-group/countering-threats-north-korea/">exploited this year</a> by North Korea. </p> <p> Half of the known exploitable bugs in Chrome are use-after-frees: <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjol0tDHrKfloO3-RsAhVwMGPRBFmg8FmM2nMbHfA4kPTHu4PVaoqFAkdKXkE63ePSIC4U4rH8pMSa8FfLYY-0CdahMPzcP_GqoILj0bBtquIwVuf-oLRpnZqe6cNBgTHv6LPnM_l1YrkqPHote0DMbIkYy7BZjDiZITG2u05T9YoxV6OqhnonD1TlY9g/s512/bug%20types.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="317" data-original-width="512" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjol0tDHrKfloO3-RsAhVwMGPRBFmg8FmM2nMbHfA4kPTHu4PVaoqFAkdKXkE63ePSIC4U4rH8pMSa8FfLYY-0CdahMPzcP_GqoILj0bBtquIwVuf-oLRpnZqe6cNBgTHv6LPnM_l1YrkqPHote0DMbIkYy7BZjDiZITG2u05T9YoxV6OqhnonD1TlY9g/s600/bug%20types.png" width="600"/></a></div> <p> <strong>Diving Deeper: Not All Use-After-Free Bugs Are Equal</strong> </p> <p> Chrome has a <a href="https://www.chromium.org/developers/design-documents/multi-process-architecture/">multi-process architecture</a>, partly to ensure that web content is isolated into a sandboxed “renderer” process where little harm can occur. An attacker therefore usually needs to find and exploit <em>two</em> vulnerabilities - one to achieve code execution in the renderer process, and another bug to break out of the sandbox. </p> <p> The first stage is often the easier one. The attacker has lots of influence in the renderer process. It’s easy to arrange memory in a specific way, and the renderer process acts upon many different kinds of web content, giving a large “attack surface” that could potentially be exploited. </p> <p> The second stage, escaping the renderer sandbox, is trickier. Attackers have two options how to do this: </p> <ol> <li>They can exploit a bug in the underlying operating system (OS) through the limited interfaces available inside Chrome’s sandbox. <li>Or, they can exploit a bug in a more powerful, privileged part of Chrome - like the “browser” process. This process coordinates all the other bits of Chrome, so fundamentally <em>has</em> to be all-powerful. </li> </ol> <p> We imagine the attackers squeezing through the narrow part of a funnel: <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrD_PVCwSIrVn0tVWBs7b0PueDknbg8BrwznIfKHmYqgNFlGuVupFVZaPMSO9uoj4QawGujzyOS42-Nsemdl9AXD3gOaUFeqnBkhVd0Aem99UK5C9bt6trfnF_4UplnWFdXUrXfM-P4QvnZq81lrsz8o7M6QLZaKzSSLm7_ni10BPT2xaLSyhITCHE9A/s1600/Screenshot%202022-09-13%207.28.31%20AM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="405" data-original-width="646" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrD_PVCwSIrVn0tVWBs7b0PueDknbg8BrwznIfKHmYqgNFlGuVupFVZaPMSO9uoj4QawGujzyOS42-Nsemdl9AXD3gOaUFeqnBkhVd0Aem99UK5C9bt6trfnF_4UplnWFdXUrXfM-P4QvnZq81lrsz8o7M6QLZaKzSSLm7_ni10BPT2xaLSyhITCHE9A/s1600/Screenshot%202022-09-13%207.28.31%20AM.png"/></a></div> If we can reduce the size of the narrow part of the funnel, we will make it as hard as possible for attackers to assemble a full exploit chain. We can reduce the size of the orange slice by removing access to more OS interfaces within the renderer process sandbox, and we’re continuously working on that. The MiraclePtr project aims to reduce the size of the blue slice. </p> <p> Here’s a sample of 100 recent high severity Chrome security bugs that made it to the stable channel, divided by root cause and by the process they affect. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNa-V0mokSe10I_waRxQNuH_GNg6kqPyAszlWZ2EqMIgiySJcLWQ_FQQYSCl5dnF-u7acqGaqNE1bKXKJGG9b2GKKzIDMrKQWPhJWdp-0Te2HZYOecDVpLJXamMCzdO8ErcezDkFly1D19YlPrPHDHDf01O8GisMqoCOnfsAK8jWl9W8_JeUDJglHLNw/s512/bugs%20chart%202.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="317" data-original-width="512" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNa-V0mokSe10I_waRxQNuH_GNg6kqPyAszlWZ2EqMIgiySJcLWQ_FQQYSCl5dnF-u7acqGaqNE1bKXKJGG9b2GKKzIDMrKQWPhJWdp-0Te2HZYOecDVpLJXamMCzdO8ErcezDkFly1D19YlPrPHDHDf01O8GisMqoCOnfsAK8jWl9W8_JeUDJglHLNw/s600/bugs%20chart%202.png" width="600"/></a></div> </p> <p> You might notice: </p> <ul> <li>This doesn’t quite add up to 100 - that’s because a few bugs were in other processes beyond the renderer or browser. <li>We claimed that the browser process is the more difficult part to exploit, yet there are more potentially-exploitable bugs! That may be so, but we believe they are typically harder to exploit because the attacker has less control over memory layout. </li> </ul> <p> As you can see, the biggest category of bugs in each process is: V8 in the renderer process (JavaScript engine logic bugs - <a href="https://docs.google.com/document/d/1FM4fQmIhEqPG8uGp5o9A-mnPB5BOeScZYpkHjo0KKA8/edit">work in progress</a>) and use-after-free bugs in the browser process. If we can make that “thin” bit thinner still by removing some of those use-after-free bugs, we make the whole job of Chrome exploitation markedly harder. </p> <p> <strong>MiraclePtr: Preventing Exploitation of Use-After-Free Bugs</strong> </p> <p> This is where <a href="https://docs.google.com/document/d/1pnnOAIz_DMWDI4oIOFoMAqLnf_MZ2GsrJNb_dbQ3ZBg/edit">MiraclePtr</a> comes in. It is a technology to prevent exploitation of use-after-free bugs. Unlike aforementioned *Scan technologies that offer a non-invasive approach to this problem, MiraclePtr relies on rewriting the codebase to use a new smart pointer type, <a href="https://chromium.googlesource.com/chromium/src/+/main/base/memory/raw_ptr.md">raw_ptr<T></a>. There are multiple ways to implement MiraclePtr. We came up with <a href="https://docs.google.com/document/d/1qsPh8Bcrma7S-5fobbCkBkXWaAijXOnorEqvIIGKzc0/edit">~10 algorithms</a> and compared the pros and cons. After analyzing their performance overhead, memory overhead, security protection guarantees, developer ergonomics, etc., we concluded that BackupRefPtr was the most promising solution. </p> <p> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqjNDqH-vs-iOJi4MZ8xgPNPFQin31tNdn0Ixh2w9wEKgTWB0KDsRBFg47IRrLsZ1BMSFAY0a1rmCUf5ETwzhUicglI4S9Lq6ue9h0UiK9vXX5WF6ZPVdEFSvDMGQOsLJ6MI0ZlyRbMCkd58hLxNBOy5FobolQUuyj7o6gYA2lZFDLt9QO_VLTpLJ1cA/s512/raw1.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="484" data-original-width="512" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqjNDqH-vs-iOJi4MZ8xgPNPFQin31tNdn0Ixh2w9wEKgTWB0KDsRBFg47IRrLsZ1BMSFAY0a1rmCUf5ETwzhUicglI4S9Lq6ue9h0UiK9vXX5WF6ZPVdEFSvDMGQOsLJ6MI0ZlyRbMCkd58hLxNBOy5FobolQUuyj7o6gYA2lZFDLt9QO_VLTpLJ1cA/s200/raw1.png" width="200"/></a></div> The BackupRefPtr algorithm is based on reference counting. It uses support of Chrome's own heap allocator, <a href="https://chromium.googlesource.com/chromium/src/+/main/base/allocator/partition_allocator/PartitionAlloc.md">PartitionAlloc</a>, which carves out a little extra space for a hidden reference count for each allocation. raw_ptr<T> increments or decrements the reference count when it’s constructed, destroyed or modified. When the application calls free/delete and the reference count is greater than 0, PartitionAlloc quarantines that memory region instead of immediately releasing it. The memory region is then only made available for reuse once the reference count reaches 0. Quarantined memory is poisoned to further reduce the likelihood that use-after-free accesses will result in exploitable conditions, and in hope that future accesses lead to an easy-to-debug crash, turning these security issues into less-dangerous ones. </p> <pre class="prettyprint">class A { ... }; class B { B(A* a) : a_(a) {} void doSomething() { a_->doSomething(); } raw_ptr<A> a_; // MiraclePtr }; std::unique_ptr<A> a = std::make_unique<A>(); std::unique_ptr<B> b = std::make_unique<B>(a.get()); […] a = nullptr; // The free is delayed because the MiraclePtr is still pointing to the object. b->doSomething(); // Use-after-free is neutralized.</pre> <p> We successfully <a href="https://chromium-review.googlesource.com/c/chromium/src/+/3305132">rewrote more than 15,000 raw pointers</a> in the Chrome codebase into raw_ptr<T>, then enabled BackupRefPtr for the browser process on Windows and Android (both 64 bit and 32 bit) in Chrome 102 Stable. We anticipate that MiraclePtr meaningfully reduces the browser process attack surface of Chrome by protecting ~50% of use-after-free issues against exploitation. We are now working on enabling BackupRefPtr in the network, utility and GPU processes, and for other platforms. In the end state, our goal is to enable BackupRefPtr on <em>all</em> platforms because that ensures that a given pointer is protected for <em>all</em> users of Chrome. </p> <p> <strong>Balancing Security and Performance</strong> </p> <p> There is no free lunch, however. This security protection comes at a cost, which we have carefully weighed in our decision making. </p> <p> Unsurprisingly, the main cost is memory. Luckily, related investments into PartitionAlloc over the past year led to 10-25% total memory savings, depending on usage patterns and platforms. So we were able to spend some of those savings on security: MiraclePtr increased the memory usage of the browser process 4.5-6.5% on Windows and 3.5-5% on Android<sup>1</sup>, still well below their previous levels. While we were worried about quarantined memory, in practice this is a tiny fraction (0.01%) of the browser process usage. By far the bigger culprit is the additional memory needed to store the reference count. One might think that adding 4 bytes to each allocation wouldn’t be a big deal. However, there are many small allocations in Chrome, so even the 4B overhead is not negligible. PartitionAlloc also uses pre-defined bucket sizes, so this extra 4B pushes certain allocations (particularly power-of-2 sized) into a larger bucket, e.g. 4096B->5120B. </p> <p> We also considered the performance cost. Adding an atomic increment/decrement on common operations such as pointer assignment has unavoidable overhead. Having excluded a number of performance-critical pointers, we drove this overhead down until we could gain back the same margin through other performance optimizations. On Windows, no statistically significant performance regressions were observed on most of our top-level performance metrics like Largest Contentful Paint, First Input Delay, etc. The only adverse change there<sup>1</sup> is an increase of the main thread contention (~7%). On Android<sup>1</sup>, in addition to a similar increase in the main thread contention (~6%), there were small regressions in First Input Delay (~1%), Input Delay (~3%) and First Contentful Paint (~0.5%). We don't anticipate these regressions to have a noticeable impact on user experience, and are confident that they are strongly outweighed by the additional safety for our users. </p> <p> We should emphasize that MiraclePtr currently protects only class/struct pointer fields, to minimize the overhead. As future work, we are exploring options to expand the pointer coverage to on-stack pointers so that we can protect against more use-after-free bugs. </p> <p> Note that the primary goal of MiraclePtr is to prevent exploitation of use-after-free bugs. Although it wasn’t designed for diagnosability, it already helped us find and fix a number of bugs that were previously undetected. We have ongoing efforts to make MiraclePtr crash reports even more informative and actionable. </p> <p> <strong>Continue to Provide Us Feedback</strong> </p> <p> Last but not least, we’d like to encourage security researchers to continue to report issues through the <a href="https://g.co/ChromeBugRewards">Chrome Vulnerability Reward Program</a>, even if those issues are mitigated by MiraclePtr. We still need to make MiraclePtr available to all users, collect more data on its impact through reported issues, and further refine our processes and tooling. Until that is done, we will not consider MiraclePtr when determining the severity of a bug or the reward amount. </p> <p> <sup>1</sup> Measured in Chrome 99. </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:Use-after-freedom: MiraclePtr&url=https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html' data-url='https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> </span> </div> </div> </div> <div class='post' data-id='2552432823877555157' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-works-in.html' itemprop='url' title='How Hash-Based Safe Browsing Works in Google Chrome'> How Hash-Based Safe Browsing Works in Google Chrome </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> August 8, 2022 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> </i></p>By Rohit Bhatia, Mollie Bates, Google Chrome Security</i></p> <p> There are various threats a user faces when browsing the web. Users may be tricked into sharing sensitive information like their passwords with a misleading or fake website, also called phishing. They may also be led into installing malicious software on their machines, called malware, which can collect personal data and also hold it for ransom. Google Chrome, henceforth called Chrome, enables its users to protect themselves from such threats on the internet. When Chrome users browse the web with Safe Browsing protections, Chrome uses the Safe Browsing service from Google to identify and ward off various threats. </p> <p> Safe Browsing works in different ways depending on the user's preferences. In the most common case, Chrome uses the privacy-conscious <a href="https://developers.google.com/safe-browsing/v4/update-api">Update API</a> (Application Programming Interface) from the Safe Browsing service. <a href="https://www.google.com/url?q=https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html&sa=D&source=docs&ust=1659535320580416&usg=AOvVaw1N9HMoW55mmIVlhzcWnz_0">This API</a> was developed with user privacy in mind and ensures Google gets as little information about the user's browsing history as possible. If the user has opted-in to "<a href="https://support.google.com/chrome/answer/9890866">Enhanced Protection</a>" (covered in an <a href="https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html">earlier post</a>) or "<a href="https://support.google.com/chrome/answer/9116376">Make Searches and Browsing Better</a>", Chrome shares limited additional data with Safe Browsing only to further improve user protection. </p> <p> This post describes how Chrome implements the Update API, with appropriate pointers to the technical implementation and details about the privacy-conscious aspects of the Update API. This should be useful for users to understand how Safe Browsing protects them, and for interested developers to browse through and understand the implementation. We will cover the APIs used for Enhanced Protection users in a future post. </p> <h3>Threats on the Internet</h3> <p> When a user navigates to a webpage on the internet, their browser fetches objects hosted on the internet. These objects include the structure of the webpage (HTML), the styling (CSS), dynamic behavior in the browser (Javascript), images, downloads initiated by the navigation, and other webpages embedded in the main webpage. These objects, also called resources, have a web address which is called their URL (Uniform Resource Locator). Further, URLs may redirect to other URLs when being loaded. Each of these URLs can potentially host threats such as phishing websites, malware, unwanted downloads, malicious software, unfair billing practices, and more. Chrome with Safe Browsing checks all URLs, redirects or included resources, to identify such threats and protect users. </p> <h3>Safe Browsing Lists</h3> <p> Safe Browsing provides a list for each threat it protects users against on the internet. A full catalog of lists that are used in Chrome can be found by visiting <code>chrome://safe-browsing/#tab-db-manager</code> on desktop platforms. </p> <p> A list does not contain unsafe web addresses, also referred to as URLs, in entirety; it would be prohibitively expensive to keep all of them in a device’s limited memory. Instead it maps a URL, which can be very long, through a cryptographic hash function (SHA-256), to a unique fixed size string. This distinct fixed size string, called a hash, allows a list to be stored efficiently in limited memory. The Update API handles URLs only in the form of hashes and is also called hash-based API in this post. </p> <p> Further, a list does not store hashes in entirety either, as even that would be too memory intensive. Instead, barring a case where data is not shared with Google and the list is small, it contains prefixes of the hashes. We refer to the original hash as a full hash, and a hash prefix as a partial hash.<br /><br />A list is updated following the Update API’s <a href="https://developers.google.com/safe-browsing/v4/request-frequency">request frequency</a> section. Chrome also follows a back-off mode in case of an unsuccessful response. These updates happen roughly every 30 minutes, following the minimum wait duration set by the server in the list update response. </p> <p> For those interested in browsing relevant source code, here’s where to look: </p> <h3>Source Code</h3> <ol> <li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_local_database_manager.cc;l=61;drc=c4d0e9c06b437234e8fb297ce3273dad1891e8d4">GetListInfos()</a> contains all the lists, along with their associated threat types, the platforms they are used on, and their file names on disk. </li><li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_store.h;l=33;drc=c4d0e9c06b437234e8fb297ce3273dad1891e8d4">HashPrefixMap</a> shows how the lists are stored and maintained. They are grouped by the size of prefixes, and appended together to allow quick binary search based lookups. </li> </ol> <h3>How is hash-based URL lookup done</h3> <p> As an example of a Safe Browsing list, let's say that we have one for malware, containing partial hashes of URLs known to host malware. These partial hashes are generally 4 bytes long, but for illustrative purposes, we show only 2 bytes. </p> <pre class="prettyprint">['036b', '1a02', 'bac8', 'bb90'] </pre> <p> Whenever Chrome needs to check the reputation of a resource with the Update API, for example when navigating to a URL, it <strong>does not share the raw URL (or any piece of it)</strong> with Safe Browsing to perform the lookup. Instead, Chrome uses full hashes of the URL (and some combinations) to look up the partial hashes in the locally maintained Safe Browsing list. Chrome sends only these matched partial hashes to the Safe Browsing service. This ensures that Chrome provides these protections while respecting the user’s privacy. This hash-based lookup happens in three steps in Chrome: </p> <h3>Step 1: Generate URL Combinations and Full Hashes</h3> <p> When Google blocks URLs that host potentially unsafe resources by placing them on a Safe Browsing list, the malicious actor can host the resource on a different URL. A malicious actor can cycle through various subdomains to generate new URLs. Safe Browsing uses host suffixes to identify malicious domains that host malware in their subdomains. Similarly, malicious actors can also cycle through various subpaths to generate new URLs. So Safe Browsing also uses path prefixes to identify websites that host malware at various subpaths. This prevents malicious actors from cycling through subdomains or paths for new malicious URLs, allowing robust and efficient identification of threats.<br /><br /> </p> <p> To incorporate these host suffixes and path prefixes, Chrome first computes the full hashes of the URL and some patterns derived from the URL. Following Safe Browsing API's <a href="https://developers.google.com/safe-browsing/v4/urls-hashing">URLs and Hashing</a> specification, Chrome computes the full hashes of URL combinations by following these steps: </p> <ol> <li>First, Chrome converts the URL into a canonical format, as defined in the specification. </li><li>Then, Chrome generates up to 5 host suffixes/variants for the URL. </li><li>Then, Chrome generates up to 6 path prefixes/variants for the URL. </li><li>Then, for the combined 30 host suffixes and path prefixes combinations, Chrome generates the full hash for each combination. </li> </ol> <h3>Source Code</h3> <ol> <li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_local_database_manager.cc;l=433;drc=c4d0e9c06b437234e8fb297ce3273dad1891e8d4">V4LocalDatabaseManager::CheckBrowseURL</a> is an example which performs a hash-based lookup. </li><li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_protocol_manager_util.cc;l=371;drc=ecfeecdc62ce1aca4675742b67ac439ff988f225">V4ProtocolManagerUtil::UrlToFullHashes</a> creates the various URL combinations for a URL, and computes their full hashes. </li> </ol> <h3>Example</h3> <p> For instance, let's say that a user is trying to visit <code>https://evil.example.com/blah#frag</code>. The canonical url is <code>https://evil.example.com/blah</code>. The host suffixes to be tried are <code>evil.example.com</code>, and <code>example.com</code>. The path prefixes are <code>/</code> and <code>/blah</code>. The four combined URL combinations are <code>evil.example.com/</code>, <code>evil.example.com/blah</code>, <code>example.com/</code>, and <code>example.com/blah</code>. </p> <pre class="prettyprint">url_combinations = ["evil.example.com/", "evil.example.com/blah","example.com/", "example.com/blah"] full_hashes = ['1a02…28', 'bb90…9f', '7a9e…67', 'bac8…fa'] </pre> <h3>Step 2: Search Partial Hashes in Local Lists</h3> <p> Chrome then checks the full hashes of the URL combinations against the locally maintained Safe Browsing lists. These lists, which contain partial hashes, do not provide a decisive malicious verdict, but can quickly identify if the URL is considered not malicious. If the full hash of the URL does not match any of the partial hashes from the local lists, the URL is considered safe and Chrome proceeds to load it. This happens for more than 99% of the URLs checked. </p> <h3>Source Code</h3> <ol> <li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_local_database_manager.cc;l=783;drc=ecfeecdc62ce1aca4675742b67ac439ff988f225">V4LocalDatabaseManager::GetPrefixMatches</a> gets the matching partial hashes for the full hashes of the URL and its combinations. </li> </ol> <h3>Example</h3> <p> Chrome finds that three full hashes <code>1a02…28</code>, <code>bb90…9f</code>, and <code>bac8…fa</code> match local partial hashes. We note that this is for demonstration purposes, and a match here is rare.</p> <p></p> <h3><span id="docs-internal-guid-82f4de32-7fff-e845-074f-be79fa07c0d1" style="font-weight: normal;"><span style="font-family: Arial; font-size: 13pt; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;"><span style="border: none; display: inline-block; height: 624px; overflow: hidden; width: 624px;"><img height="624" src="https://lh3.googleusercontent.com/8ZcL0YugCY2d24_K3O6Jsewt3iaPkzNJ_LwQIsGfWNDdarXWMjKjtAjxWnNAnIEvhHitFyLRGQXp-4_Z3jAc2Q_IX68UFA8f6WI4PaKg4EbEsMov-OJdVsMXN8nxpfEEcKc3H7aYnZ6PkHluQEnv0U8Sh36QFvaNQLBZTlVSSM4dmwCKu6vVACwnpDOmHw" style="margin-left: 0px; margin-top: 0px;" width="624" /></span></span></span></h3><h3>Step 3: Fetch Matching Full Hashes</h3> <p> Next, Chrome sends <strong>only</strong> the matching partial hash (not the full URL or any particular part of the URL, or even their full hashes), to the Safe Browsing service's <code><a href="https://developers.google.com/safe-browsing/v4/update-api#example-fullHashesfind">fullHashes.find</a></code> method. In response, it receives the full hashes of all malicious URLs for which the full hash begins with one of the partial hashes sent by Chrome. Chrome checks the fetched full hashes with the generated full hashes of the URL combinations. If any match is found, it identifies the URL with various threats and their severities inferred from the matched full hashes. </p><h3>Source Code</h3> <ol> <li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_get_hash_protocol_manager.cc;l=270;drc=ecfeecdc62ce1aca4675742b67ac439ff988f225">V4GetHashProtocolManager::GetFullHashes</a> performs the lookup for the full hashes for the matched partial hashes. </li> </ol> <h3>Example</h3> <p> Chrome sends the matched partial hashes 1a02, bb90, and bac8 to fetch the full hashes. The server returns full hashes that match these partial hashes, <code>1a02…28, bb90…ce,</code> and <code>bac8…01</code>. Chrome finds that one of the full hashes matches with the full hash of the URL combination being checked, and identifies the malicious URL as hosting malware. </p> <h3>Conclusion</h3> <p> Safe Browsing protects Chrome users from various malicious threats on the internet. While providing these protections, Chrome faces challenges such as constraints in memory capacity, network bandwidth usage, and a dynamic threat landscape. Chrome is also mindful of the users’ privacy choices, and shares little data with Google. </p> <p> In a follow up post, we will cover the more advanced protections Chrome provides to its users who have opted in to “Enhanced Protection”. </p><p></p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> </i></p>By Rohit Bhatia, Mollie Bates, Google Chrome Security</i></p> <p> There are various threats a user faces when browsing the web. Users may be tricked into sharing sensitive information like their passwords with a misleading or fake website, also called phishing. They may also be led into installing malicious software on their machines, called malware, which can collect personal data and also hold it for ransom. Google Chrome, henceforth called Chrome, enables its users to protect themselves from such threats on the internet. When Chrome users browse the web with Safe Browsing protections, Chrome uses the Safe Browsing service from Google to identify and ward off various threats. </p> <p> Safe Browsing works in different ways depending on the user's preferences. In the most common case, Chrome uses the privacy-conscious <a href="https://developers.google.com/safe-browsing/v4/update-api">Update API</a> (Application Programming Interface) from the Safe Browsing service. <a href="https://www.google.com/url?q=https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html&sa=D&source=docs&ust=1659535320580416&usg=AOvVaw1N9HMoW55mmIVlhzcWnz_0">This API</a> was developed with user privacy in mind and ensures Google gets as little information about the user's browsing history as possible. If the user has opted-in to "<a href="https://support.google.com/chrome/answer/9890866">Enhanced Protection</a>" (covered in an <a href="https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html">earlier post</a>) or "<a href="https://support.google.com/chrome/answer/9116376">Make Searches and Browsing Better</a>", Chrome shares limited additional data with Safe Browsing only to further improve user protection. </p> <p> This post describes how Chrome implements the Update API, with appropriate pointers to the technical implementation and details about the privacy-conscious aspects of the Update API. This should be useful for users to understand how Safe Browsing protects them, and for interested developers to browse through and understand the implementation. We will cover the APIs used for Enhanced Protection users in a future post. </p> <h3>Threats on the Internet</h3> <p> When a user navigates to a webpage on the internet, their browser fetches objects hosted on the internet. These objects include the structure of the webpage (HTML), the styling (CSS), dynamic behavior in the browser (Javascript), images, downloads initiated by the navigation, and other webpages embedded in the main webpage. These objects, also called resources, have a web address which is called their URL (Uniform Resource Locator). Further, URLs may redirect to other URLs when being loaded. Each of these URLs can potentially host threats such as phishing websites, malware, unwanted downloads, malicious software, unfair billing practices, and more. Chrome with Safe Browsing checks all URLs, redirects or included resources, to identify such threats and protect users. </p> <h3>Safe Browsing Lists</h3> <p> Safe Browsing provides a list for each threat it protects users against on the internet. A full catalog of lists that are used in Chrome can be found by visiting <code>chrome://safe-browsing/#tab-db-manager</code> on desktop platforms. </p> <p> A list does not contain unsafe web addresses, also referred to as URLs, in entirety; it would be prohibitively expensive to keep all of them in a device’s limited memory. Instead it maps a URL, which can be very long, through a cryptographic hash function (SHA-256), to a unique fixed size string. This distinct fixed size string, called a hash, allows a list to be stored efficiently in limited memory. The Update API handles URLs only in the form of hashes and is also called hash-based API in this post. </p> <p> Further, a list does not store hashes in entirety either, as even that would be too memory intensive. Instead, barring a case where data is not shared with Google and the list is small, it contains prefixes of the hashes. We refer to the original hash as a full hash, and a hash prefix as a partial hash.<br /><br />A list is updated following the Update API’s <a href="https://developers.google.com/safe-browsing/v4/request-frequency">request frequency</a> section. Chrome also follows a back-off mode in case of an unsuccessful response. These updates happen roughly every 30 minutes, following the minimum wait duration set by the server in the list update response. </p> <p> For those interested in browsing relevant source code, here’s where to look: </p> <h3>Source Code</h3> <ol> <li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_local_database_manager.cc;l=61;drc=c4d0e9c06b437234e8fb297ce3273dad1891e8d4">GetListInfos()</a> contains all the lists, along with their associated threat types, the platforms they are used on, and their file names on disk. </li><li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_store.h;l=33;drc=c4d0e9c06b437234e8fb297ce3273dad1891e8d4">HashPrefixMap</a> shows how the lists are stored and maintained. They are grouped by the size of prefixes, and appended together to allow quick binary search based lookups. </li> </ol> <h3>How is hash-based URL lookup done</h3> <p> As an example of a Safe Browsing list, let's say that we have one for malware, containing partial hashes of URLs known to host malware. These partial hashes are generally 4 bytes long, but for illustrative purposes, we show only 2 bytes. </p> <pre class="prettyprint">['036b', '1a02', 'bac8', 'bb90'] </pre> <p> Whenever Chrome needs to check the reputation of a resource with the Update API, for example when navigating to a URL, it <strong>does not share the raw URL (or any piece of it)</strong> with Safe Browsing to perform the lookup. Instead, Chrome uses full hashes of the URL (and some combinations) to look up the partial hashes in the locally maintained Safe Browsing list. Chrome sends only these matched partial hashes to the Safe Browsing service. This ensures that Chrome provides these protections while respecting the user’s privacy. This hash-based lookup happens in three steps in Chrome: </p> <h3>Step 1: Generate URL Combinations and Full Hashes</h3> <p> When Google blocks URLs that host potentially unsafe resources by placing them on a Safe Browsing list, the malicious actor can host the resource on a different URL. A malicious actor can cycle through various subdomains to generate new URLs. Safe Browsing uses host suffixes to identify malicious domains that host malware in their subdomains. Similarly, malicious actors can also cycle through various subpaths to generate new URLs. So Safe Browsing also uses path prefixes to identify websites that host malware at various subpaths. This prevents malicious actors from cycling through subdomains or paths for new malicious URLs, allowing robust and efficient identification of threats.<br /><br /> </p> <p> To incorporate these host suffixes and path prefixes, Chrome first computes the full hashes of the URL and some patterns derived from the URL. Following Safe Browsing API's <a href="https://developers.google.com/safe-browsing/v4/urls-hashing">URLs and Hashing</a> specification, Chrome computes the full hashes of URL combinations by following these steps: </p> <ol> <li>First, Chrome converts the URL into a canonical format, as defined in the specification. </li><li>Then, Chrome generates up to 5 host suffixes/variants for the URL. </li><li>Then, Chrome generates up to 6 path prefixes/variants for the URL. </li><li>Then, for the combined 30 host suffixes and path prefixes combinations, Chrome generates the full hash for each combination. </li> </ol> <h3>Source Code</h3> <ol> <li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_local_database_manager.cc;l=433;drc=c4d0e9c06b437234e8fb297ce3273dad1891e8d4">V4LocalDatabaseManager::CheckBrowseURL</a> is an example which performs a hash-based lookup. </li><li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_protocol_manager_util.cc;l=371;drc=ecfeecdc62ce1aca4675742b67ac439ff988f225">V4ProtocolManagerUtil::UrlToFullHashes</a> creates the various URL combinations for a URL, and computes their full hashes. </li> </ol> <h3>Example</h3> <p> For instance, let's say that a user is trying to visit <code>https://evil.example.com/blah#frag</code>. The canonical url is <code>https://evil.example.com/blah</code>. The host suffixes to be tried are <code>evil.example.com</code>, and <code>example.com</code>. The path prefixes are <code>/</code> and <code>/blah</code>. The four combined URL combinations are <code>evil.example.com/</code>, <code>evil.example.com/blah</code>, <code>example.com/</code>, and <code>example.com/blah</code>. </p> <pre class="prettyprint">url_combinations = ["evil.example.com/", "evil.example.com/blah","example.com/", "example.com/blah"] full_hashes = ['1a02…28', 'bb90…9f', '7a9e…67', 'bac8…fa'] </pre> <h3>Step 2: Search Partial Hashes in Local Lists</h3> <p> Chrome then checks the full hashes of the URL combinations against the locally maintained Safe Browsing lists. These lists, which contain partial hashes, do not provide a decisive malicious verdict, but can quickly identify if the URL is considered not malicious. If the full hash of the URL does not match any of the partial hashes from the local lists, the URL is considered safe and Chrome proceeds to load it. This happens for more than 99% of the URLs checked. </p> <h3>Source Code</h3> <ol> <li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_local_database_manager.cc;l=783;drc=ecfeecdc62ce1aca4675742b67ac439ff988f225">V4LocalDatabaseManager::GetPrefixMatches</a> gets the matching partial hashes for the full hashes of the URL and its combinations. </li> </ol> <h3>Example</h3> <p> Chrome finds that three full hashes <code>1a02…28</code>, <code>bb90…9f</code>, and <code>bac8…fa</code> match local partial hashes. We note that this is for demonstration purposes, and a match here is rare.</p> <p></p> <h3><span id="docs-internal-guid-82f4de32-7fff-e845-074f-be79fa07c0d1" style="font-weight: normal;"><span style="font-family: Arial; font-size: 13pt; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;"><span style="border: none; display: inline-block; height: 624px; overflow: hidden; width: 624px;"><img height="624" src="https://lh3.googleusercontent.com/8ZcL0YugCY2d24_K3O6Jsewt3iaPkzNJ_LwQIsGfWNDdarXWMjKjtAjxWnNAnIEvhHitFyLRGQXp-4_Z3jAc2Q_IX68UFA8f6WI4PaKg4EbEsMov-OJdVsMXN8nxpfEEcKc3H7aYnZ6PkHluQEnv0U8Sh36QFvaNQLBZTlVSSM4dmwCKu6vVACwnpDOmHw" style="margin-left: 0px; margin-top: 0px;" width="624" /></span></span></span></h3><h3>Step 3: Fetch Matching Full Hashes</h3> <p> Next, Chrome sends <strong>only</strong> the matching partial hash (not the full URL or any particular part of the URL, or even their full hashes), to the Safe Browsing service's <code><a href="https://developers.google.com/safe-browsing/v4/update-api#example-fullHashesfind">fullHashes.find</a></code> method. In response, it receives the full hashes of all malicious URLs for which the full hash begins with one of the partial hashes sent by Chrome. Chrome checks the fetched full hashes with the generated full hashes of the URL combinations. If any match is found, it identifies the URL with various threats and their severities inferred from the matched full hashes. </p><h3>Source Code</h3> <ol> <li><a href="https://source.chromium.org/chromium/chromium/src/+/master:components/safe_browsing/core/browser/db/v4_get_hash_protocol_manager.cc;l=270;drc=ecfeecdc62ce1aca4675742b67ac439ff988f225">V4GetHashProtocolManager::GetFullHashes</a> performs the lookup for the full hashes for the matched partial hashes. </li> </ol> <h3>Example</h3> <p> Chrome sends the matched partial hashes 1a02, bb90, and bac8 to fetch the full hashes. The server returns full hashes that match these partial hashes, <code>1a02…28, bb90…ce,</code> and <code>bac8…01</code>. Chrome finds that one of the full hashes matches with the full hash of the URL combination being checked, and identifies the malicious URL as hosting malware. </p> <h3>Conclusion</h3> <p> Safe Browsing protects Chrome users from various malicious threats on the internet. While providing these protections, Chrome faces challenges such as constraints in memory capacity, network bandwidth usage, and a dynamic threat landscape. Chrome is also mindful of the users’ privacy choices, and shares little data with Google. </p> <p> In a follow up post, we will cover the more advanced protections Chrome provides to its users who have opted in to “Enhanced Protection”. </p><p></p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </noscript> </div> </div> <div class='share'> <span class='twitter-custom social-wrapper' data-href='http://twitter.com/share?text=Google Online Security Blog:How Hash-Based Safe Browsing Works in Google Chrome&url=https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-works-in.html&via=google'> <img alt='Share on Twitter' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_twitter_black_24dp.png' width='24'/> </span> <span class='fb-custom social-wrapper' data-href='https://www.facebook.com/sharer.php?u=https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-works-in.html'> <img alt='Share on Facebook' height='24' src='https://www.gstatic.com/images/icons/material/system/2x/post_facebook_black_24dp.png' width='24'/> </span> </div> <div class='comment-container'> <i class='comment-img material-icons'>  </i> <span class='cmt_count_iframe_holder' data-count='0' data-onclick='javascript:window.open(this.href, "bloggerPopup", "toolbar=0,location=0,statusbar=1,menubar=0,scrollbars=yes,width=640,height=500"); return false;' data-post-url='https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-works-in.html' data-url='https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-works-in.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-works-in.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> <span class='labels-caption'> Labels: </span> <span class='labels'> <a class='label' href='https://security.googleblog.com/search/label/chrome' rel='tag'> chrome </a> , <a class='label' href='https://security.googleblog.com/search/label/chrome%20security' rel='tag'> chrome security </a> , <a class='label' href='https://security.googleblog.com/search/label/privacy' rel='tag'> privacy </a> </span> </div> </div> </div> <div class='blog-pager' id='blog-pager'> <a class='home-link' href='https://security.googleblog.com/'> <i class='material-icons'>  </i> </a> <i class='material-icons disabled'>  </i> <span id='blog-pager-older-link'> <a class='blog-pager-older-link' href='https://security.googleblog.com/search/label/chrome?updated-max=2022-08-08T11:55:00-04:00&max-results=20&start=12&by-date=false' id='Blog1_blog-pager-older-link' title='Older Posts'> <i class='material-icons'>  </i> </a> </span> </div> <div class='clear'></div> </div></div> </div> </div> <div class='col-right'> <div class='section' id='sidebar-top'><div class='widget HTML' data-version='1' id='HTML8'> <div class='widget-content'> <div class='searchBox'> <input type='text' title='Search This Blog' placeholder='Search blog ...' /> </div> </div> <div class='clear'></div> </div></div> <div id='aside'> <div class='section' id='sidebar'><div class='widget Label' data-version='1' id='Label1'> <div class='tab'> <img class='sidebar-icon' src='data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAYpJREFUeNrs2aFuwzAQBmAvKRkMKRjZA4QMDJaWFgyMjuzFRg37DIUlA3uFkoGQSaWzJU+tpri5O9+l/zSfdFJlpe59yTmyVedq1PjfcZMZ70NuQnaF8w8htyE/rABtpviXkLcK88c5HhLkMBfgVan43zfFBNGMjHVGT/s55KP2pAvidbGHd+nzKt1RKSLG3rKF1iPFv6UWiPke8i7kEqGdGsI1O+LYVdqJAjgirwkKYD0ytkJBUNbAMvX8V3q9PhUsYvU1sWD8SO/sQvx2ahxOiNoJCSBCoAHYCEQAC4EKICOQASQEOmAS8RcAFxFN5hiIiugpgC3wk9hQAHH/70EBHXUN7IER5EWMiBgo2+nzOKQv9SCAeEM/OQAkhE/ncccFICB87qzQMia5FsJfOui0zMnmRvipU1ormHQuxGTxUsAcCFLxJQBLBLn4UoAFglW8BkATwS5eC6CBEBWvCShBiIvXBkgQRcVbADiI4uKtABSESvGWgB9EzHt3+tNwyO0qa9SoIYtvAQYAqDJhaWWeMecAAAAASUVORK5CYII='/> <h2> Labels </h2> <i class='material-icons arrow'>  </i> </div> <div class='widget-content list-label-widget-content'> <ul> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/%23sharethemicincyber'> #sharethemicincyber </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/%23supplychain%20%23security%20%23opensource'> #supplychain #security #opensource </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/android'> android </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/android%20security'> android security </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/android%20tr'> android tr </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/app%20security'> app security </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/big%20data'> big data </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/biometrics'> biometrics </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/blackhat'> blackhat </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/C%2B%2B'> C++ </a> </li> <li> <span dir='ltr'> chrome </span> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/chrome%20enterprise'> chrome enterprise </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/chrome%20security'> chrome security </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/connected%20devices'> connected devices </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/CTF'> CTF </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/diversity'> diversity </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/encryption'> encryption </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/federated%20learning'> federated learning </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/fuzzing'> fuzzing </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/Gboard'> Gboard </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/google%20play'> google play </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/google%20play%20protect'> google play protect </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/hacking'> hacking </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/interoperability'> interoperability </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/iot%20security'> iot security </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/kubernetes'> kubernetes </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/linux%20kernel'> linux kernel </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/memory%20safety'> memory safety </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/Open%20Source'> Open Source </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/pha%20family%20highlights'> pha family highlights </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/pixel'> pixel </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/privacy'> privacy </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/private%20compute%20core'> private compute core </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/Rowhammer'> Rowhammer </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/rust'> rust </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/Security'> Security </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/security%20rewards%20program'> security rewards program </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/sigstore'> sigstore </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/spyware'> spyware </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/supply%20chain'> supply chain </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/targeted%20spyware'> targeted spyware </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/tensor'> tensor </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/Titan%20M2'> Titan M2 </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/VDP'> VDP </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/vulnerabilities'> vulnerabilities </a> </li> <li> <a dir='ltr' href='https://security.googleblog.com/search/label/workshop'> workshop </a> </li> </ul> <div class='clear'></div> </div> </div><div class='widget BlogArchive' data-version='1' id='BlogArchive1'> <div class='tab'> <i class='material-icons icon'>  </i> <h2> Archive </h2> <i class='material-icons arrow'>  </i> </div> <div class='widget-content'> <div id='ArchiveList'> <div id='BlogArchive1_ArchiveList'> <ul class='hierarchy'> <li class='archivedate expanded'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy toggle-open'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2024/'> 2024 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate expanded'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2024/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2023/'> 2023 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2023/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2022/'> 2022 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2022/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2021/'> 2021 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2021/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2020/'> 2020 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2020/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2019/'> 2019 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2019/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2018/'> 2018 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2018/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2017/'> 2017 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2017/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2016/'> 2016 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2016/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2015/'> 2015 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2015/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2014/'> 2014 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2014/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2013/'> 2013 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2013/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2012/'> 2012 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2012/01/'> Jan </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2011/'> 2011 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2011/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2010/'> 2010 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2010/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2010/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2010/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2010/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2010/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2010/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2010/04/'> Apr </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2010/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2009/'> 2009 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2009/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2009/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2009/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2009/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2009/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2009/03/'> Mar </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2008/'> 2008 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2008/12/'> Dec </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2008/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2008/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2008/08/'> Aug </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2008/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2008/05/'> May </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2008/02/'> Feb </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class='intervalToggle'> <span class='new-toggle' href='javascript:void(0)'> <i class='material-icons arrow'>  </i> </span> <a class='toggle' href='javascript:void(0)' style='display: none'> <span class='zippy'> <i class='material-icons'>  </i>   </span> </a> <a class='post-count-link' href='https://security.googleblog.com/2007/'> 2007 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2007/11/'> Nov </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2007/10/'> Oct </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2007/09/'> Sep </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2007/07/'> Jul </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2007/06/'> Jun </a> </div> <div class='items'> </div> </li> </ul> <ul class='hierarchy'> <li class='archivedate collapsed'> <div class=''> <a class='post-count-link' href='https://security.googleblog.com/2007/05/'> May </a> </div> <div class='items'> </div> </li> </ul> </div> </li> </ul> </div> </div> <div class='clear'></div> </div> </div><div class='widget HTML' data-version='1' id='HTML6'> <div class='widget-content'> <a href="https://googleonlinesecurity.blogspot.com/atom.xml"> <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAihJREFUeNrsWa9Pw0AU7viRMDFRBAkzJDMIBIhJJhCzk7NILIqMv4AEhdz+BCY3OYssAlGBoAJREpZwAlHEBO8lr8nSvNeVbu1dyX3JlzTrXfa+u/e9d7c5joWFhYVO1Fa8PwH2gK6m+BRwAvSlAdsrgr8E1jUuMH73GTAEzrkBWymTewZlihhLmgDXIAFuHgGVQOUF7OSYM1p6PgTuA1vAZlUEvAnPdapcMY0VICECekQ0XRfYrqoHsAGNgXfAoMomRiFDEhOZkkL3S88hMaB2LwXp0bj+ps2edpToZpjfoIDQtBeU+xjoDzP2G/gCPKZ5f8WsCAFJoJgOCcFdWSTeL9YQMSvTA1h9BkI5jaiXhLpSCL/8mVZY0UpyJ9ZdOkniu1dmJ96BpzQu9w6s28gcOq9j6pwLdR8/36NK5CQKwJSMrb2MhhSglBpt4UjsrdsnNu0B3J0HCozbCc4TjyY2srEgos/4RQljCzNxl4ireQD8FOq+T+W0mTB2g7njhlR+Sy2jsXFvU658U8YTbeaGpdIu7mWkEAq5ZtIjIhFZdtfX7QHckSvB2B6zC3VdAkZk0kAQwaXTk/CzTXK3wjIExCs6ZJpTnE4uY1KV+KzFzA3KTiFPENHJkOPcsfpLhwe4btoSuvUqAR+6TOxlCE6ZfKUsJLgsqGW8OpqAGx2X+sLxrwUog+JUeQRMDBIwyXOcnlPtPnL0/UsT/8LnOxYWFhZG4leAAQAAQHEaYuzHbAAAAABJRU5ErkJggg==" class="sidebar-icon" /> <h2>Feed</h2> </a> </div> <div class='clear'></div> </div></div> <div class='section' id='sidebar-bottom'><div class='widget HTML' data-version='1' id='HTML5'> <div class='widget-content'> <div class='followgooglewrapper'> <script src="https://apis.google.com/js/plusone.js"></script> <div class="g-ytsubscribe" data-channel="Google" data-layout="full"></div> </div> <div class="share followgooglewrapper"> <button data-href="https://twitter.com/intent/follow?original_referer=http://googleonlinesecurity.blogspot.in/&screen_name=google" onclick='sharingPopup(this);' id='twitter-share'><span class="twitter-follow">Follow @google</span></button> <script> function sharingPopup (button) { var url = button.getAttribute("data-href"); window.open( url,'popUpWindow','height=500,width=500,left=10,top=10,resizable=yes,scrollbars=yes,toolbar=yes,menubar=no,location=no,directories=no,status=yes'); } </script> </div> <div class="fb-follow-button"> <a href="https://www.facebook.com/google" target="_blank"><img class="fb-follow" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmruMUNSjAUsU-iCQjxgiqufl2u1wHJfiVTn3wuiIZAK1VUSRsexREPAOLV0N4-4VVtaYbZL18UsVh5CUlUJWH5UurFiQKMkHlNnj3YYw-2UiYtbNbvBE7VsAhdtw9rwNuOc-riC1exNkp/s1600/facebook-logo.png" />Follow</a> </div> </div> <div class='clear'></div> </div><div class='widget HTML' data-version='1' id='HTML1'> <div class='widget-content'> Give us feedback in our <a href="https://support.google.com/bin/static.py?hl=en&page=portal_groups.cs">Product Forums</a>. </div> <div class='clear'></div> </div></div> </div> </div> <div style='clear:both;'></div> </div>  <div class='google-footer-outer loading'> <div id='google-footer'> <a href='//www.google.com/'> <img class='google-logo-dark' height='36' src='data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALgAAABICAYAAABFoT/eAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAACLVJREFUeNrsXd+L20YQ3vOprdLqiMXFXE2qB7dcwEcTSB7ykIc+9A/PQx/yEMq1TWhNuYIpJriNr7XpmZ5IxFEvmW2EKs3Ornb1w50PxIFP0kiz387OzM6uhGAwGAxGP3Ho+f7x7ri1O7LdccPqZjSNA4dEHsLfaHcEFedJom93x9Xu2OyOFTcBo6sED3fHZHeMEELrkAHJF0B8Rr+gDFsZ5n0luLTQ95AXs4W06D/tjpR50xtM4CjD0y48YGB4rnyZxNOzyA7zBHr+nLnDaJLg0mo/ALekCasg3Z4XbM0ZdTEgnDPeHY8bIne+Qz2GvwyGNwsuyT218KWvIIBMcwGpLiipcolecjMxfBDchNyS1EvxLiOSIecp31q6IJ/C3yrIrMqMm4jhg+AxkdwbIO3aUO4KjqqMjCT3uaazMBhWBJfuxH3CtRfiXf66DhSRZWbmlMnNaILgZxrXJQO/eO3wORZwvwm4JUxuhheCjzVBYAbW1ces45YDSoZrFNOEE835M8FT6oyeEnws8Fz3QnBxFKPHBMem4GU+m6fPGb0leCTwWcM5B36MPgeZI01gudyDdw3hPeXfo8L/rmCUWnuMMdqUL2WqWeRbhf+twfVsO7YagZGNC79fw7OthEVtkiJ4jJzTd3KPwf3CRqhhiTu23AP5sl0/0xiwISQXpNwLIJK87mHF+U8ddzzdmgKlGzlPYjyxGJQouIhNT4k9AqWEFkqfguIvagTWbcq3KW1WE3xS3m8NtA9WS451xofwjKT5kkDoK/b6mDk5FfXr1lWDL4BofZEv2/SRsK/EHGlGdBdu8QNRb8HMCFwt7Yy3DDI/QP7fx5z3VLhdlJEIs4rKNuXXJXdxZPdB7kfCzWqwCO4V1LHgLjInX3tQ1KzCR52Cz+vDj1dydeRuS74rcvs2Pi6fT5H8OaaUQPQPYcWwRSGXyhhscn5dpAnEFMkuEZetbfkTAnlSuH4DxisE+aMGeJAQ3lFl7C4LJE6QWCaCd583ORQ1jYAwjFctal7nOs2ZZvicwvlZx+RHGrcoAwKUVX8uwcc/9TT65INeDOr5shL9LDRB6QTeIy3zwfdh3WOi6axLCEhSjXU7F3h6LqggUtvyJxpynwu8tDkD98fXApOxRj8zoZ9MnGveYVIVZKaGrkBXCY65BCYNN9NkjpKOyQ81Q79JgdxS+Jn3SDTEXRI7SWzaiSTB32oI3nU3BvMfM0urhOVYgwKhuiAfc4tM07wXwm1ZRoQYSl2NUwiu01fEAHVcpixd745FvVz4dzUUc0o8rwoLy8ZSwU6CyFx1RP5II9+1bFPEFs9HWbNLiimDXE+vCm7u1CS47cofzD3aEhVY57mxRo5zlqdt+RFC1JUH2S7bcVXg4liTMakaBZZVxiTICRoivcn1sEUBlk24JmaC6kxUbYmWoqvyfck2xZGGnDFYa9MMzkYQ1ijkCX6qidybrgePiQ0QIQqoi6qRLeqQfIoRsEHaQJLBdHOnLGetSdm/IPcymJuS1PAnbQPH0MOw/39C1vL11DiLOqIsbDI8QcHvGiLnySi2qUXBicaqUSxN5LEB0g7Jt3ENXJLPJ5S1tnaZBoWbpRqrmjRE7qHmpSmNHdQcYrEUadoh+TbBnc9ri7iycI1kzPeNcLDIvbiqXpez9Tmdq6zGREPuzECBoxrPMiI2WtvyNwhJba2wy3JZ6ky5dD1lSvmZS3e4SPA1wcf1VTFHKX+cGwZzdUYcqpvUtvwrD/InDttVlyZeAKlNN5MKbAiurHhKIPlUuJvlTCCiDjSKSCsUmCFWbGLZwCESfK07JB8LvMYWVtw0D00JEHV8Mq2HkqPbE0oHLvvK2g0o8ETg+4cfwTlZDT9JDoWygu4uQQE/ivIvtcnfPkaCqhiupz7jWOAzqL/vjtcdkv9G4MVMt+EaylfuImiPAXEUjRF3pjjaHiPPZ6If9TGGAO4ZY0am6jOCb+DQ+ZCqLkIpOIPrdNfIjnFPY6nyFut7TS/fanrziOBOKMupKw94WaLMtuVnSFt9CPrWWdJE6PeltCX432DEBoh+5Dv8RRhdis8YAv9uyq4/JAwtlEApgBe9Cw9xDD3tdk4Jn0MDfiHwPHcRPxBePCMER3GuIx7kGlv9fkZ4V9lolx2Uv4X7hEj7qJ3LDoAMGbTRMRibu4L2xQ8bgt8AyU+Q+x7nYrvDnH4iuO5LxKsYwPVbkPMvKF9Zky9wXzRfVWizi62r9X5VHf55h+WHhDjGBZ4WRhyTr6z5SlCoLMxLSpBZFsQ9F80uQFbF/6aFWi+Ev51vzzsuX+msyzuQXXjUz8zEBy+zpq9yweXAoxJW4JbYrDS6gYDqGHxPl+TKeiBfxj9/EBIElPYeOA4y8/qRQfknjvSzgRgtq0Pw/M1eQeMdOSb2Bnrhr6Led+1vcp2x7oTFHMnedFW+Ivlty062BUt74oHgSj+vHepnhunn0JJAMtBZgDI/qmGtMujRv8DDpo47zBJ8UtPOuAR/7rKn8t9AJ0tBdmBAmJ/Fu71yxp4I3qh+DhyRqbi5Y1ShVPlSb8X7bRNcfgZFl+WRGYo7uecrWq1r8X5bhmzP5OdlDwsGRm1suSxkg5rYm7ConyGQ3Zl+DgSD8V/kPwrWBMG9YcBtyShBnTLdTiHgttw7qAW7cqh/ZnmPKr/6ignOaKsdyxbsToT5UkPsW00bJjijDXficcX/JsLs6w2BwGtherdckH3w/kNXRPVI0OqJQoHX42/66IMfMj/2huRjxIidgKV/W0JS+bsstDoTeAHcrI8E5zTh/sDkqxL5rZup55/3USlswfcHf4IrQplVDgW9XFlOqnwr6pVPMMEZTuC60EttvdzbLbaZ4PsFVa3nohhO+vW+yn/ZB2fUhpysmQrzBcTSai9EszuZMcEZ1lCFVrp9zGXhm69iLyY4oxFIa178lPe12I/P2DAYDAaDwWAwGAwGg8FgMBgMBoPBYDD2Cf8IMADDRGoQTe+E9AAAAABJRU5ErkJggg==' style='margin-top: -16px;' width='92'/> </a> <ul> <li> <a href='//www.google.com/'> Google </a> </li> <li> <a href='//www.google.com/policies/privacy/'> Privacy </a> </li> <li> <a href='//www.google.com/policies/terms/'> Terms </a> </li> </ul> </div> </div> <script type='text/javascript'> //<![CDATA[ // Social sharing popups. var postEl = document.getElementsByClassName('social-wrapper'); var postCount = postEl.length; for(i=0; i<postCount;i++){ postEl[i].addEventListener("click", function(event){ var postUrl = this.getAttribute("data-href"); window.open( postUrl,'popUpWindow','height=500,width=500,left=10,top=10,resizable=yes,scrollbars=yes,toolbar=yes,menubar=no,location=no,directories=no,status=yes'); });} //]]> </script> <script type='text/javascript'> //<![CDATA[ var BreakpointHandler = function() { this.initted = false; this.isHomePage = false; this.isMobile = false; }; BreakpointHandler.prototype.finalizeSummary = function(summaryHtml, lastNode) { // Use $.trim for IE8 compatibility summaryHtml = $.trim(summaryHtml).replace(/(<br>|\s)+$/,''); if (lastNode.nodeType == 3) { var lastChar = summaryHtml.slice(-1); if (!lastChar.match(/[.”"?]/)) { if (!lastChar.match(/[A-Za-z]/)) { summaryHtml = summaryHtml.slice(0, -1); } summaryHtml += ' ...'; } } else if (lastNode.nodeType == 1 && (lastNode.nodeName == 'I' || lastNode.nodeName == 'A')) { summaryHtml += ' ...'; } return summaryHtml; }; BreakpointHandler.prototype.generateSummaryFromContent = function(content, numWords) { var seenWords = 0; var summaryHtml = ''; for (var i=0; i < content.childNodes.length; i++) { var node = content.childNodes[i]; var nodeText; if (node.nodeType == 1) { if (node.hasAttribute('data-about-pullquote')) { continue; } nodeText = node.textContent; if (nodeText === undefined) { // innerText for IE8 nodeText = node.innerText; } if (node.nodeName == 'DIV' || node.nodeName == 'B') { // Don't end early if we haven't seen enough words. if (seenWords < 10) { continue; } if (i > 0) { summaryHtml = this.finalizeSummary(summaryHtml, content.childNodes[i-1]); } break; } summaryHtml += node.outerHTML; } else if (node.nodeType == 3) { nodeText = node.nodeValue; summaryHtml += nodeText + ' '; } var words = nodeText.match(/\S+\s*/g); if (!words) { continue; } var remain = numWords - seenWords; if (words.length >= remain) { summaryHtml = this.finalizeSummary(summaryHtml, node); break; } seenWords += words.length; } return summaryHtml; }; BreakpointHandler.prototype.detect = function() { var match, pl = /\+/g, search = /([^&=]+)=?([^&]*)/g, decode = function (s) { return decodeURIComponent(s.replace(pl, " ")); }, query = window.location.search.substring(1); var urlParams = {}; while (match = search.exec(query)) urlParams[decode(match[1])] = decode(match[2]); this.isListPage = $('html').hasClass('list-page'); this.isMobile = urlParams['m'] === '1'; this.isHomePage = window.location.pathname == '/'; }; BreakpointHandler.prototype.initContent = function() { var self = this; $('.post').each(function(index) { var body = $(this).children('.post-body')[0]; var content = $(body).children('.post-content')[0]; $(content).addClass('post-original'); var data = $(content).children('script').html(); data = self.rewriteForSSL(data); if (document.body.className.indexOf('is-preview') !== -1) { // If exists, extract specified editor's preview. var match = data.match(/([\s\S]+?)<div data-is-preview.+?>([\s\S]+)<\/div>/m); if (match) { data = match[1]; } } // Prevent big images from loading when they aren't needed. // This must be done as a pre-injection step, since image loading can't be // canceled once embedded into the DOM. if (self.isListPage && self.isMobile) { data = data.replace(/<(img|iframe) .+?>/g, ''); } // Insert template to be rendered as nodes. content.innerHTML = data; if (self.isListPage) { var summary = document.createElement('div'); $(summary).addClass('post-content'); $(summary).addClass('post-summary'); body.insertBefore(summary, content); if (match) { // Use provided summary. summary.innerHTML = match[2]; } else { // Generate a summary. // Summary generation relies on DOM, so it must occur after content is // inserted into the page. summary.innerHTML = self.generateSummaryFromContent(content, 30); } // Add read more link to summary. var titleAnchor = $(this).find('.title a')[0]; var link = titleAnchor.cloneNode(true); link.innerHTML = 'Read More'; $(link).addClass('read-more'); summary.appendChild(link); } }); // Firefox does not allow for proper styling of BR. if (navigator.userAgent.indexOf('Firefox') > -1) { $('.post-content br').replaceWith('<span class="space"></span>'); } $('.loading').removeClass('loading'); }; BreakpointHandler.prototype.process = function() { if (!this.initted) { var makeInsecureImageRegex = function(hosts) { var whitelist = hosts.join('|').replace(/\./g,'\\.'); // Normal image tags, plus input images (yes, this is possible!) return new RegExp('(<(img|input)[^>]+?src=("|\'))http:\/\/(' + whitelist +')', 'g'); }; this.sslImageRegex = makeInsecureImageRegex(BreakpointHandler.KNOWN_HTTPS_HOSTS); this.sslImageCurrentDomainRegex = makeInsecureImageRegex([window.location.hostname]); this.detect(); this.initContent(); this.initted = true; } }; BreakpointHandler.KNOWN_HTTPS_HOSTS = [ "www.google.org", "www.google.com", "services.google.com", "blogger.com", "draft.blogger.com", "www.blogger.com", "photos1.blogger.com", "photos2.blogger.com", "photos3.blogger.com", "blogblog.com", "img1.blogblog.com", "img2.blogblog.com", "www.blogblog.com", "www1.blogblog.com", "www2.blogblog.com", "0.bp.blogspot.com", "1.bp.blogspot.com", "2.bp.blogspot.com", "3.bp.blogspot.com", "4.bp.blogspot.com", "lh3.googleusercontent.com", "lh4.googleusercontent.com", "lh5.googleusercontent.com", "lh6.googleusercontent.com", "themes.googleusercontent.com", ]; BreakpointHandler.prototype.rewriteForSSL = function(html) { // Handle HTTP -> HTTPS source replacement of images, movies, and other embedded content. return html.replace(this.sslImageRegex, '$1https://$4') .replace(this.sslImageCurrentDomainRegex, '$1//$4') .replace(/(<(embed|iframe)[^>]+?src=("|'))http:\/\/([^"']*?(youtube|picasaweb\.google)\.com)/g, '$1https://$4') // Slideshow SWF takes a image host, so we need to rewrite that parameter. .replace(/(<embed[^>]+?feed=http(?=[^s]))/g, '$1s'); }; $(document).ready(function() { var handler = new BreakpointHandler(); handler.process(); // Top-level navigation. $(".BlogArchive .tab").click(function(ev) { ev.preventDefault(); $(this).parent().toggleClass('active'); $(this).siblings().slideToggle(300); }); $(".Label .tab").click(function(ev) { ev.preventDefault(); $(this).parent().toggleClass('active'); $(this).siblings().slideToggle(300); }); // Blog archive year expansion. $('.BlogArchive .intervalToggle').click(function(ev) { ev.preventDefault(); if ($(this).parent().hasClass('collapsed')) { $(this).parent().removeClass('collapsed'); $(this).parent().addClass('expanded'); } else { $(this).parent().removeClass('expanded'); $(this).parent().addClass('collapsed'); } }); // Reverse order of months. $('.BlogArchive .intervalToggle + div').each(function(_, items) { var year = $(this); year.children().each(function(_, month) { year.prepend(month); }); }); // Set anchors to open in new tab. $('.post-content img').parent().each(function(_, node) { if (node.nodeName == 'A') { $(this).attr('target', '_blank'); } }); // Process search requests. $('.searchBox input').on("keypress", function(ev) { if (ev.which == 13) { window.location.href = 'https://www.google.com/search?q=site%3A' + window.location.hostname + '%20' + encodeURIComponent ($(this).val()); } }); }); //]]> </script> <script type="text/javascript" src="https://www.blogger.com/static/v1/widgets/984859869-widgets.js"></script> <script type='text/javascript'> window['__wavt'] = 'AOuZoY4G3vlH45by2BhpDhz1aa_NzSmSbQ:1732796301322';_WidgetManager._Init('//www.blogger.com/rearrange?blogID\x3d1176949257541686127','//security.googleblog.com/search/label/chrome','1176949257541686127'); _WidgetManager._SetDataContext([{'name': 'blog', 'data': {'blogId': '1176949257541686127', 'title': 'Google Online Security Blog', 'url': 'https://security.googleblog.com/search/label/chrome', 'canonicalUrl': 'https://security.googleblog.com/search/label/chrome', 'homepageUrl': 'https://security.googleblog.com/', 'searchUrl': 'https://security.googleblog.com/search', 'canonicalHomepageUrl': 'https://security.googleblog.com/', 'blogspotFaviconUrl': 'https://security.googleblog.com/favicon.ico', 'bloggerUrl': 'https://www.blogger.com', 'hasCustomDomain': true, 'httpsEnabled': true, 'enabledCommentProfileImages': false, 'gPlusViewType': 'FILTERED_POSTMOD', 'adultContent': false, 'analyticsAccountNumber': 'G-K46T604G22', 'analytics4': true, 'encoding': 'UTF-8', 'locale': 'en', 'localeUnderscoreDelimited': 'en', 'languageDirection': 'ltr', 'isPrivate': false, 'isMobile': false, 'isMobileRequest': false, 'mobileClass': '', 'isPrivateBlog': false, 'isDynamicViewsAvailable': true, 'feedLinks': '\x3clink rel\x3d\x22alternate\x22 type\x3d\x22application/atom+xml\x22 title\x3d\x22Google Online Security Blog - Atom\x22 href\x3d\x22https://security.googleblog.com/feeds/posts/default\x22 /\x3e\n\x3clink rel\x3d\x22alternate\x22 type\x3d\x22application/rss+xml\x22 title\x3d\x22Google Online Security Blog - RSS\x22 href\x3d\x22https://security.googleblog.com/feeds/posts/default?alt\x3drss\x22 /\x3e\n\x3clink rel\x3d\x22service.post\x22 type\x3d\x22application/atom+xml\x22 title\x3d\x22Google Online Security Blog - Atom\x22 href\x3d\x22https://www.blogger.com/feeds/1176949257541686127/posts/default\x22 /\x3e\n', 'meTag': '', 'adsenseHostId': 'ca-host-pub-1556223355139109', 'adsenseHasAds': false, 'adsenseAutoAds': false, 'boqCommentIframeForm': true, 'loginRedirectParam': '', 'view': '', 'dynamicViewsCommentsSrc': '//www.blogblog.com/dynamicviews/4224c15c4e7c9321/js/comments.js', 'dynamicViewsScriptSrc': '//www.blogblog.com/dynamicviews/2fafd358a4bcb2b4', 'plusOneApiSrc': 'https://apis.google.com/js/platform.js', 'disableGComments': true, 'interstitialAccepted': false, 'sharing': {'platforms': [{'name': 'Get link', 'key': 'link', 'shareMessage': 'Get link', 'target': ''}, {'name': 'Facebook', 'key': 'facebook', 'shareMessage': 'Share to Facebook', 'target': 'facebook'}, {'name': 'BlogThis!', 'key': 'blogThis', 'shareMessage': 'BlogThis!', 'target': 'blog'}, {'name': 'X', 'key': 'twitter', 'shareMessage': 'Share to X', 'target': 'twitter'}, {'name': 'Pinterest', 'key': 'pinterest', 'shareMessage': 'Share to Pinterest', 'target': 'pinterest'}, {'name': 'Email', 'key': 'email', 'shareMessage': 'Email', 'target': 'email'}], 'disableGooglePlus': true, 'googlePlusShareButtonWidth': 0, 'googlePlusBootstrap': '\x3cscript type\x3d\x22text/javascript\x22\x3ewindow.___gcfg \x3d {\x27lang\x27: \x27en\x27};\x3c/script\x3e'}, 'hasCustomJumpLinkMessage': false, 'jumpLinkMessage': 'Read more', 'pageType': 'index', 'searchLabel': 'chrome', 'pageName': 'chrome', 'pageTitle': 'Google Online Security Blog: chrome'}}, {'name': 'features', 'data': {}}, {'name': 'messages', 'data': {'edit': 'Edit', 'linkCopiedToClipboard': 'Link copied to clipboard!', 'ok': 'Ok', 'postLink': 'Post Link'}}, {'name': 'template', 'data': {'name': 'custom', 'localizedName': 'Custom', 'isResponsive': false, 'isAlternateRendering': false, 'isCustom': true}}, {'name': 'view', 'data': {'classic': {'name': 'classic', 'url': '?view\x3dclassic'}, 'flipcard': {'name': 'flipcard', 'url': '?view\x3dflipcard'}, 'magazine': {'name': 'magazine', 'url': '?view\x3dmagazine'}, 'mosaic': {'name': 'mosaic', 'url': '?view\x3dmosaic'}, 'sidebar': {'name': 'sidebar', 'url': '?view\x3dsidebar'}, 'snapshot': {'name': 'snapshot', 'url': '?view\x3dsnapshot'}, 'timeslide': {'name': 'timeslide', 'url': '?view\x3dtimeslide'}, 'isMobile': false, 'title': 'Google Online Security Blog', 'description': 'The latest news and insights from Google on security and safety on the Internet', 'url': 'https://security.googleblog.com/search/label/chrome', 'type': 'feed', 'isSingleItem': false, 'isMultipleItems': true, 'isError': false, 'isPage': false, 'isPost': false, 'isHomepage': false, 'isArchive': false, 'isSearch': true, 'isLabelSearch': true, 'search': {'label': 'chrome', 'resultsMessage': 'Showing posts with the label chrome', 'resultsMessageHtml': 'Showing posts with the label \x3cspan class\x3d\x27search-label\x27\x3echrome\x3c/span\x3e'}}}]); _WidgetManager._RegisterWidget('_HeaderView', new _WidgetInfo('Header1', 'header', document.getElementById('Header1'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_BlogView', new _WidgetInfo('Blog1', 'main', document.getElementById('Blog1'), {'cmtInteractionsEnabled': false, 'navMessage': 'Showing posts with label \x3cb\x3echrome\x3c/b\x3e. \x3ca href\x3d\x22https://security.googleblog.com/\x22\x3eShow all posts\x3c/a\x3e'}, 'displayModeFull')); _WidgetManager._RegisterWidget('_HTMLView', new _WidgetInfo('HTML8', 'sidebar-top', document.getElementById('HTML8'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_LabelView', new _WidgetInfo('Label1', 'sidebar', document.getElementById('Label1'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_BlogArchiveView', new _WidgetInfo('BlogArchive1', 'sidebar', document.getElementById('BlogArchive1'), {'languageDirection': 'ltr', 'loadingMessage': 'Loading\x26hellip;'}, 'displayModeFull')); _WidgetManager._RegisterWidget('_HTMLView', new _WidgetInfo('HTML6', 'sidebar', document.getElementById('HTML6'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_HTMLView', new _WidgetInfo('HTML5', 'sidebar-bottom', document.getElementById('HTML5'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_HTMLView', new _WidgetInfo('HTML1', 'sidebar-bottom', document.getElementById('HTML1'), {}, 'displayModeFull')); </script> </body> </html>