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: 2019 </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/2019/' 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/2019/' 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/2019/' 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=596b78ee-5116-448a-9fd6-d00c96bcea49' media='none' onload='if(media!='all')media='all'' rel='stylesheet'/><noscript><link href='https://www.blogger.com/dyn-css/authorization.css?targetBlogID=1176949257541686127&zx=596b78ee-5116-448a-9fd6-d00c96bcea49' 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='3662411416864313008' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html' itemprop='url' title='Announcing updates to our Patch Rewards program in 2020 '> Announcing updates to our Patch Rewards program in 2020 </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> December 18, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Jan Keller, Technical Program Manager, Security </span><br /> <span class="byline-author"><br /></span> At Google, we strive to make the internet safer and that includes recognizing and rewarding security improvements that are vital to the health of the entire web. In 2020, we are building on this commitment by launching a new iteration of our <a href="http://goo.gle/patchz">Patch Rewards program</a> for third-party open source projects.<br /> <br /> Over the last six years, we have rewarded open source projects for security improvements after they have been implemented. While this has led to overall improved security, we want to take this one step further.<br /> <br /> <b>Introducing upfront financial help</b><br /> Starting on January 1, 2020, we’re not only going to reward proactive security improvements <a href="https://www.google.com/about/appsecurity/patch-rewards/">after the work is completed</a>, but we will also complement the program with upfront financial support to provide an additional resource for open source developers to prioritize security work. For example, if you are a small open source project and you want to improve security, but don’t have the necessary resources, this new reward can help you acquire additional development capacity.<br /> <div> <div> <div> <br /> We will start off with two support levels : <br /> <ul> <li><b>Small ($5,000):</b> Meant to motivate and reward a project for fixing a small number of security issues. Examples: improvements to privilege separation or sandboxing, cleanup of integer artimetrics, or more generally fixing vulnerabilities identified in open source software by bug bounty programs such as <a href="https://ec.europa.eu/info/departments/informatics/eu-fossa-2_en">EU-FOSSA 2</a> (see ‘Qualifying submissions’ <a href="http://goo.gle/patchz">here</a> for more examples).</li> <li><b>Large ($30,000): </b>Meant to incentivize a larger project to invest heavily in security, e.g. providing support to find additional developers, or implement a significant new security feature (e.g. new compiler mitigations).</li> </ul> <b><b>Nomination process</b></b><br /> <br /> Anyone can nominate an open source project for support by filling out <a href="http://goo.gle/patchz-nomination">http://goo.gle/patchz-nomination</a>. Our Patch Reward Panel will review submissions on a monthly basis and select a number of projects that meet the program criteria. The panel will let submitors know if a project has been chosen and will start working with the project maintainers directly.<br /> <b><br /></b> <b>Projects in scope</b><br /> <b><br /></b></div> <div> Any open source project can be nominated for support. When selecting projects, the panel will put an emphasis on projects that either are vital to the health of the Internet or are end-user projects with a large user base.<br /> <b><br /></b> <b>What do we expect in return?</b><br /> <br /> We expect to see security improvements to open source software. Ideally, the project can provide us<br />with a short blurb or pointers to some of the completed work that was possible because of our support. We don’t want to add bureaucracy, but would like to measure the success of the program.<br /><b>What about the existing Patch Rewards program?</b><br /> This is an addition to the existing program, the current <a href="http://goo.gle/patchz">Patch Rewards program</a> will continue as it stands today.</div> </div> </div> <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 Jan Keller, Technical Program Manager, Security </span><br /> <span class="byline-author"><br /></span> At Google, we strive to make the internet safer and that includes recognizing and rewarding security improvements that are vital to the health of the entire web. In 2020, we are building on this commitment by launching a new iteration of our <a href="http://goo.gle/patchz">Patch Rewards program</a> for third-party open source projects.<br /> <br /> Over the last six years, we have rewarded open source projects for security improvements after they have been implemented. While this has led to overall improved security, we want to take this one step further.<br /> <br /> <b>Introducing upfront financial help</b><br /> Starting on January 1, 2020, we’re not only going to reward proactive security improvements <a href="https://www.google.com/about/appsecurity/patch-rewards/">after the work is completed</a>, but we will also complement the program with upfront financial support to provide an additional resource for open source developers to prioritize security work. For example, if you are a small open source project and you want to improve security, but don’t have the necessary resources, this new reward can help you acquire additional development capacity.<br /> <div> <div> <div> <br /> We will start off with two support levels : <br /> <ul> <li><b>Small ($5,000):</b> Meant to motivate and reward a project for fixing a small number of security issues. Examples: improvements to privilege separation or sandboxing, cleanup of integer artimetrics, or more generally fixing vulnerabilities identified in open source software by bug bounty programs such as <a href="https://ec.europa.eu/info/departments/informatics/eu-fossa-2_en">EU-FOSSA 2</a> (see ‘Qualifying submissions’ <a href="http://goo.gle/patchz">here</a> for more examples).</li> <li><b>Large ($30,000): </b>Meant to incentivize a larger project to invest heavily in security, e.g. providing support to find additional developers, or implement a significant new security feature (e.g. new compiler mitigations).</li> </ul> <b><b>Nomination process</b></b><br /> <br /> Anyone can nominate an open source project for support by filling out <a href="http://goo.gle/patchz-nomination">http://goo.gle/patchz-nomination</a>. Our Patch Reward Panel will review submissions on a monthly basis and select a number of projects that meet the program criteria. The panel will let submitors know if a project has been chosen and will start working with the project maintainers directly.<br /> <b><br /></b> <b>Projects in scope</b><br /> <b><br /></b></div> <div> Any open source project can be nominated for support. When selecting projects, the panel will put an emphasis on projects that either are vital to the health of the Internet or are end-user projects with a large user base.<br /> <b><br /></b> <b>What do we expect in return?</b><br /> <br /> We expect to see security improvements to open source software. Ideally, the project can provide us<br />with a short blurb or pointers to some of the completed work that was possible because of our support. We don’t want to add bureaucracy, but would like to measure the success of the program.<br /><b>What about the existing Patch Rewards program?</b><br /> This is an addition to the existing program, the current <a href="http://goo.gle/patchz">Patch Rewards program</a> will continue as it stands today.</div> </div> </div> <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 updates to our Patch Rewards program in 2020 &url=https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.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/2019/12/announcing-updates-to-our-patch-rewards.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/2019/12/announcing-updates-to-our-patch-rewards.html' data-url='https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='8088518406820129578' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/12/protecting-programmatic-access-to-user.html' itemprop='url' title='Protecting programmatic access to user data with Binary Authorization for Borg'> Protecting programmatic access to user data with Binary Authorization for Borg </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> December 17, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Daniel Rebolledo Samper and Mark Lodato, Software Engineers, Security & Privacy</span><br /> <span class="byline-author"><br /></span> At Google, the safety of user data is our paramount concern and we strive to protect it comprehensively. That includes protection from insider risk, which is the possible risk that employees could use their organizational knowledge or access to perform malicious acts. Insider risk also covers the scenario where an attacker has compromised the credentials of someone at Google to facilitate their attack. There are times when it’s necessary for our services and personnel to access user data as part of fulfilling our contractual obligations to you: as part of their role, such as user support; and programmatically, as part of a service. Today, we’re releasing a whitepaper, “Binary Authorization for Borg: how Google verifies code provenance and implements code identity,” that explains one of the mechanisms we use to protect user data from insider risks on Google's cluster management system <a href="https://research.google.com/pubs/pub43438.html?hl=es">Borg</a>.<br /> <div> <b><br /></b></div> <div> <b>Binary Authorization for Borg is a deploy-time enforcement check</b></div> <div> <br /></div> <div> Binary Authorization for Borg, or BAB, is an internal deploy-time enforcement check that reduces insider risk by ensuring that production software and configuration deployed at Google is properly reviewed and authorized, especially when that code has the ability to access user data. BAB ensures that code and configuration deployments meet certain standards prior to being deployed. BAB includes both a deploy-time enforcement service to prevent unauthorized jobs from starting, and an audit trail of the code and configuration used in BAB-enabled jobs.<b><br /></b><br /> BAB ensures that Google's official software supply chain process is followed. First, a code change is reviewed and approved before being checked into Google's central source code repository. Next, the code is verifiably built and packaged using Google's central build system. This is done by creating the build in a secure sandbox and recording the package's origin in metadata for verification purposes. Finally, the job is deployed to Borg, with a job-specific identity. BAB rejects any package that lacks proper metadata, that did not follow the proper supply chain process, or that otherwise does not match the identity’s predefined policy.<br /> <div> <b><br /></b></div> <div> <b>Binary Authorization for Borg allows for several kinds of security checks</b></div> <div> <br /></div> <div> BAB can be used for many kinds of deploy-time security checks. Some examples include:<br /> <ul> <li>Is the binary built from checked in code?</li> <li>Is the binary built verifiably?</li> <li>Is the binary built from tested code?</li> <li>Is the binary built from code intended to be used in the deployment?</li> </ul> After deployment, a job is continuously verified for its lifetime, to check that jobs that were started (and any that may still be running) conform to updates to their policies.<br /> <div> <br /></div> <b>Binary Authorization for Borg provides other security benefits</b><br /> Though the primary purpose of BAB is to limit the ability of a potentially malicious insider to run an unauthorized job that could access user data, BAB has other security benefits. BAB provides robust code identity for jobs in Google’s infrastructure, tying a job’s identity to specific code, and ensuring that only the specified code can be used to exercise the job identity’s privileges. This allows for a transition from a job identity—trusting an identity and any of its privileged human users transitively—to a code identity—trusting a specific piece of reviewed code to have specific semantics and which cannot be modified without an approval process.<br /> <br /> BAB also dictates a common language for data protection, so that multiple teams can understand and meet the same requirements. Certain processes, such as those for financial reporting, need to meet certain change management requirements for compliance purposes. Using BAB, these checks can be automated, saving time and increasing the scope of coverage.<br /> <div> <br /></div> <div> <b>Binary Authorization for Borg is part of the BeyondProd model</b><br /> BAB is one of several technologies used at Google to mitigate insider risk, and one piece of how we secure containers and microservices in production. By using containerized systems and verifying their BAB requirements prior to deployment, our systems are easier to debug, more reliable, and have a clearer change management process. More details on how Google has adopted a cloud-native security model are available in another whitepaper we are releasing today, <a href="https://cloud.google.com/security/beyondprod/">“BeyondProd: A new approach to cloud-native security.”</a></div> <div> <br /></div> <div> In summary, implementing BAB, a deploy-time enforcement check, as part of Google’s containerized infrastructure and continuous integration and deployment (CI/CD) process has enabled us to verify that the code and configuration we deploy meet certain standards for security. Adopting BAB has allowed Google to reduce insider risk, prevent possible attacks, and also support the uniformity of our production systems. For more information about BAB, read our whitepaper, <a href="https://cloud.google.com/security/binary-authorization-for-borg/">“Binary Authorization for Borg: how Google verifies code provenance and implements code identity.”</a></div> <div> <br /></div> <i>Additional contributors to this whitepaper include Kevin Chen, Software Engineer; Tim Dierks, Engineering Director; Maya Kaczorowski, Product Manager; Gary O’Connor, Technical Writing; Umesh Shankar, Principal Engineer; Adam Stubblefield, Distinguished Engineer; and Wilfried Teiken, Software Engineer; with special recognition to the entire Binary Authorization for Borg team for their ideation, engineering, and leadership</i></div> </div> <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 Daniel Rebolledo Samper and Mark Lodato, Software Engineers, Security & Privacy</span><br /> <span class="byline-author"><br /></span> At Google, the safety of user data is our paramount concern and we strive to protect it comprehensively. That includes protection from insider risk, which is the possible risk that employees could use their organizational knowledge or access to perform malicious acts. Insider risk also covers the scenario where an attacker has compromised the credentials of someone at Google to facilitate their attack. There are times when it’s necessary for our services and personnel to access user data as part of fulfilling our contractual obligations to you: as part of their role, such as user support; and programmatically, as part of a service. Today, we’re releasing a whitepaper, “Binary Authorization for Borg: how Google verifies code provenance and implements code identity,” that explains one of the mechanisms we use to protect user data from insider risks on Google's cluster management system <a href="https://research.google.com/pubs/pub43438.html?hl=es">Borg</a>.<br /> <div> <b><br /></b></div> <div> <b>Binary Authorization for Borg is a deploy-time enforcement check</b></div> <div> <br /></div> <div> Binary Authorization for Borg, or BAB, is an internal deploy-time enforcement check that reduces insider risk by ensuring that production software and configuration deployed at Google is properly reviewed and authorized, especially when that code has the ability to access user data. BAB ensures that code and configuration deployments meet certain standards prior to being deployed. BAB includes both a deploy-time enforcement service to prevent unauthorized jobs from starting, and an audit trail of the code and configuration used in BAB-enabled jobs.<b><br /></b><br /> BAB ensures that Google's official software supply chain process is followed. First, a code change is reviewed and approved before being checked into Google's central source code repository. Next, the code is verifiably built and packaged using Google's central build system. This is done by creating the build in a secure sandbox and recording the package's origin in metadata for verification purposes. Finally, the job is deployed to Borg, with a job-specific identity. BAB rejects any package that lacks proper metadata, that did not follow the proper supply chain process, or that otherwise does not match the identity’s predefined policy.<br /> <div> <b><br /></b></div> <div> <b>Binary Authorization for Borg allows for several kinds of security checks</b></div> <div> <br /></div> <div> BAB can be used for many kinds of deploy-time security checks. Some examples include:<br /> <ul> <li>Is the binary built from checked in code?</li> <li>Is the binary built verifiably?</li> <li>Is the binary built from tested code?</li> <li>Is the binary built from code intended to be used in the deployment?</li> </ul> After deployment, a job is continuously verified for its lifetime, to check that jobs that were started (and any that may still be running) conform to updates to their policies.<br /> <div> <br /></div> <b>Binary Authorization for Borg provides other security benefits</b><br /> Though the primary purpose of BAB is to limit the ability of a potentially malicious insider to run an unauthorized job that could access user data, BAB has other security benefits. BAB provides robust code identity for jobs in Google’s infrastructure, tying a job’s identity to specific code, and ensuring that only the specified code can be used to exercise the job identity’s privileges. This allows for a transition from a job identity—trusting an identity and any of its privileged human users transitively—to a code identity—trusting a specific piece of reviewed code to have specific semantics and which cannot be modified without an approval process.<br /> <br /> BAB also dictates a common language for data protection, so that multiple teams can understand and meet the same requirements. Certain processes, such as those for financial reporting, need to meet certain change management requirements for compliance purposes. Using BAB, these checks can be automated, saving time and increasing the scope of coverage.<br /> <div> <br /></div> <div> <b>Binary Authorization for Borg is part of the BeyondProd model</b><br /> BAB is one of several technologies used at Google to mitigate insider risk, and one piece of how we secure containers and microservices in production. By using containerized systems and verifying their BAB requirements prior to deployment, our systems are easier to debug, more reliable, and have a clearer change management process. More details on how Google has adopted a cloud-native security model are available in another whitepaper we are releasing today, <a href="https://cloud.google.com/security/beyondprod/">“BeyondProd: A new approach to cloud-native security.”</a></div> <div> <br /></div> <div> In summary, implementing BAB, a deploy-time enforcement check, as part of Google’s containerized infrastructure and continuous integration and deployment (CI/CD) process has enabled us to verify that the code and configuration we deploy meet certain standards for security. Adopting BAB has allowed Google to reduce insider risk, prevent possible attacks, and also support the uniformity of our production systems. For more information about BAB, read our whitepaper, <a href="https://cloud.google.com/security/binary-authorization-for-borg/">“Binary Authorization for Borg: how Google verifies code provenance and implements code identity.”</a></div> <div> <br /></div> <i>Additional contributors to this whitepaper include Kevin Chen, Software Engineer; Tim Dierks, Engineering Director; Maya Kaczorowski, Product Manager; Gary O’Connor, Technical Writing; Umesh Shankar, Principal Engineer; Adam Stubblefield, Distinguished Engineer; and Wilfried Teiken, Software Engineer; with special recognition to the entire Binary Authorization for Borg team for their ideation, engineering, and leadership</i></div> </div> <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:Protecting programmatic access to user data with Binary Authorization for Borg&url=https://security.googleblog.com/2019/12/protecting-programmatic-access-to-user.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/2019/12/protecting-programmatic-access-to-user.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/2019/12/protecting-programmatic-access-to-user.html' data-url='https://security.googleblog.com/2019/12/protecting-programmatic-access-to-user.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/12/protecting-programmatic-access-to-user.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='3437024629909207516' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/12/better-password-protections-in-chrome.html' itemprop='url' title='Better password protections in Chrome - How it works'> Better password protections in Chrome - How it works </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> December 10, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Patrick Nepper, Kiran C. Nair, Vasilii Sukhanov and Varun Khaneja, Chrome Team</span> <br /> <br /> Today, we <a href="https://blog.google/products/chrome/better-password-protections">announced</a> better password protections in Chrome, gradually rolling out with release M79. Here are the details of how they work. <br /> <br /> <br /> <strong>Warnings about compromised passwords</strong> <br /> Google first <a href="https://www.blog.google/technology/safety-security/google-password-checkup-cross-account-protection/">introduced</a> password breach warnings as a <a href="https://chrome.google.com/webstore/detail/password-checkup-extensio/pncabnpcffmalkkjpajodfhijclecjno?hl=en">Password Checkup extension</a> early this year. It compares passwords and usernames against over 4 billion credentials that Google knows to have been compromised. You can read more about it <a href="https://security.googleblog.com/2019/02/protect-your-accounts-from-data.html">here</a>. In October, Google built the Password Checkup feature<a href="https://www.blog.google/technology/safety-security/password-checkup/"> into the Google Account</a>, making it available from <a href="https://passwords.google.com/?utm_source=keyword&utm_medium=blog&utm_campaign=pwc">passwords.google.com</a>. <br /> <br /> Chrome’s integration is a natural next step to ensure we protect even more users as they browse the web. Here is how it works:<br /> <div class="separator" style="clear: both; text-align: center;"> </div> <ul> <li>Whenever Google discovers a username and password exposed by another company’s data breach, we store a hashed and encrypted copy of the data on our servers with a secret key known only to Google. </li> <li>When you sign in to a website, Chrome will send a hashed copy of your username and password to Google encrypted with a secret key only known to Chrome. No one, including Google, is able to derive your username or password from this encrypted copy. </li> <li>In order to determine if your username and password appears in any breach, we use a technique called <a href="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/33bc2203e7bcb5c0abe289f7432e11563fb2a238.pdf">private set intersection with blinding</a> that involves multiple layers of encryption. This allows us to compare your encrypted username and password with all of the encrypted breached usernames and passwords, without revealing your username and password, or revealing any information about any other users’ usernames and passwords. In order to make this computation more efficient, Chrome sends a 3-byte SHA256 hash prefix of your username to reduce the scale of the data joined from 4 billion records down to 250 records, while still ensuring your username remains anonymous. </li> <li>Only you discover if your username and password have been compromised. If they have been compromised, Chrome will tell you, and we strongly encourage you to change your password.</li> </ul> <div class="separator" style="clear: both; text-align: center;"> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirz9sQtDC86gt-p8un2emtAQDTV_Cott9Zs134vAaXte9YMbvNLU37-rEjzhf2ETQFmNuKwcqLUQyuRMaYG5-hNYVyipfVJaEWU9WGpdDBXQwh_JQc8bxfFmgsK5ixDpVRvKDtB_8Jhs5H/s1600/password_checkup_chrome_revised.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1600" data-original-width="1236" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirz9sQtDC86gt-p8un2emtAQDTV_Cott9Zs134vAaXte9YMbvNLU37-rEjzhf2ETQFmNuKwcqLUQyuRMaYG5-hNYVyipfVJaEWU9WGpdDBXQwh_JQc8bxfFmgsK5ixDpVRvKDtB_8Jhs5H/s640/password_checkup_chrome_revised.png" width="494" /></a></div> You can control this feature in the “<a href="https://support.google.com/chrome/answer/185277?co=GENIE.Platform%3DDesktop&hl=en-GB">Sync and Google Services</a>” section of Chrome Settings. Enterprise admins can control this feature using <a href="https://cloud.google.com/docs/chrome-enterprise/policies/?policy=PasswordLeakDetectionEnabled">the PasswordLeakDetectionEnabled policy setting</a>. <br /> <br /> <br /> <strong>Real-time phishing protection: Checking with Safe Browsing’s blocklist in real time. </strong> <br /> Chrome’s new real-time phishing protection is also expanding existing technology — in this case it’s Google’s well-established <a href="https://safebrowsing.google.com/">Safe Browsing.</a> <br /> <br /> Every day, Safe Browsing discovers thousands of new unsafe sites and adds them to the blocklists shared with the web industry. Chrome checks the URL of each site you visit or file you download against this local list, which is updated approximately every 30 minutes. If you navigate to a URL that appears on the list, Chrome checks a partial URL fingerprint (the first 32 bits of a SHA-256 hash of the URL) with Google for verification that the URL is indeed dangerous. Google cannot determine the actual URL from this information. <br /> <br /> However, we’re noticing that some phishing sites slip through our 30-minute refresh window, either by switching domains very quickly or by hiding from Google's crawlers. <br /> <br /> That’s where real-time phishing protections come in. These new protections can inspect the URLs of pages visited with Safe Browsing’s servers in real time. When you visit a website, Chrome checks it against a list stored on your computer of thousands of popular websites that are known to be safe. If the website is not on the safe-list, Chrome checks the URL with Google (after dropping any username or password embedded in the URL) to find out if you're visiting a dangerous site. Our analysis has shown that this results in a 30% increase in protections by warning users on malicious sites that are brand new. <br /> <br /> We will be initially rolling out this feature for people who have already opted-in to “<a href="https://support.google.com/chrome/answer/9116376?hl=en">Make searches and browsing better</a>” setting in Chrome. Enterprises administrators can manage this setting via the <a href="https://cloud.google.com/docs/chrome-enterprise/policies/?policy=UrlKeyedAnonymizedDataCollectionEnabled">UrlKeyedAnonymizedDataCollectionEnabled policy settings</a>. <br /> <br /> <br /> <strong>Expanding predictive phishing protection</strong> <br /> Your password is the key to your online identity and data. If this key falls into the hands of attackers, they can easily impersonate you and get access to your data. We<a href="https://www.blog.google/technology/safety-security/new-security-protections-tailored-you/"> launched</a> predictive phishing protections to warn users who are syncing history in Chrome when they enter their Google Account password into suspected phishing sites that try to steal their credentials. <br /> <br /> With this latest release, we’re expanding this protection to everyone signed in to Chrome, even if you have not enabled Sync. In addition, this feature will now work for all the passwords you have stored in Chrome’s password manager. <br /> <br /> If you type one of your protected passwords (this could be a password you stored in Chrome’s password manager, or the Google Account password you used to sign in to Chrome) into an unusual site, Chrome classifies this as a potentially dangerous event. <br /> <br /> In such a scenario, Chrome checks the site against a list on your computer of thousands of popular websites that are known to be safe. If the website is not on the safe-list, Chrome checks the URL with Google (after dropping any username or password embedded in the URL). If this check determines that the site is indeed suspicious or malicious, Chrome will immediately show you a warning and encourage you to change your compromised password. If it was your Google Account password that was phished, Chrome also offers to notify Google so we can add additional protections to ensure your account isn't compromised. <br /> <br /> By watching for password reuse, Chrome can give heightened security in critical moments while minimizing the data it shares with Google. We think predictive phishing protection will protect hundreds of millions more people. <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 Patrick Nepper, Kiran C. Nair, Vasilii Sukhanov and Varun Khaneja, Chrome Team</span> <br /> <br /> Today, we <a href="https://blog.google/products/chrome/better-password-protections">announced</a> better password protections in Chrome, gradually rolling out with release M79. Here are the details of how they work. <br /> <br /> <br /> <strong>Warnings about compromised passwords</strong> <br /> Google first <a href="https://www.blog.google/technology/safety-security/google-password-checkup-cross-account-protection/">introduced</a> password breach warnings as a <a href="https://chrome.google.com/webstore/detail/password-checkup-extensio/pncabnpcffmalkkjpajodfhijclecjno?hl=en">Password Checkup extension</a> early this year. It compares passwords and usernames against over 4 billion credentials that Google knows to have been compromised. You can read more about it <a href="https://security.googleblog.com/2019/02/protect-your-accounts-from-data.html">here</a>. In October, Google built the Password Checkup feature<a href="https://www.blog.google/technology/safety-security/password-checkup/"> into the Google Account</a>, making it available from <a href="https://passwords.google.com/?utm_source=keyword&utm_medium=blog&utm_campaign=pwc">passwords.google.com</a>. <br /> <br /> Chrome’s integration is a natural next step to ensure we protect even more users as they browse the web. Here is how it works:<br /> <div class="separator" style="clear: both; text-align: center;"> </div> <ul> <li>Whenever Google discovers a username and password exposed by another company’s data breach, we store a hashed and encrypted copy of the data on our servers with a secret key known only to Google. </li> <li>When you sign in to a website, Chrome will send a hashed copy of your username and password to Google encrypted with a secret key only known to Chrome. No one, including Google, is able to derive your username or password from this encrypted copy. </li> <li>In order to determine if your username and password appears in any breach, we use a technique called <a href="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/33bc2203e7bcb5c0abe289f7432e11563fb2a238.pdf">private set intersection with blinding</a> that involves multiple layers of encryption. This allows us to compare your encrypted username and password with all of the encrypted breached usernames and passwords, without revealing your username and password, or revealing any information about any other users’ usernames and passwords. In order to make this computation more efficient, Chrome sends a 3-byte SHA256 hash prefix of your username to reduce the scale of the data joined from 4 billion records down to 250 records, while still ensuring your username remains anonymous. </li> <li>Only you discover if your username and password have been compromised. If they have been compromised, Chrome will tell you, and we strongly encourage you to change your password.</li> </ul> <div class="separator" style="clear: both; text-align: center;"> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirz9sQtDC86gt-p8un2emtAQDTV_Cott9Zs134vAaXte9YMbvNLU37-rEjzhf2ETQFmNuKwcqLUQyuRMaYG5-hNYVyipfVJaEWU9WGpdDBXQwh_JQc8bxfFmgsK5ixDpVRvKDtB_8Jhs5H/s1600/password_checkup_chrome_revised.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1600" data-original-width="1236" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirz9sQtDC86gt-p8un2emtAQDTV_Cott9Zs134vAaXte9YMbvNLU37-rEjzhf2ETQFmNuKwcqLUQyuRMaYG5-hNYVyipfVJaEWU9WGpdDBXQwh_JQc8bxfFmgsK5ixDpVRvKDtB_8Jhs5H/s640/password_checkup_chrome_revised.png" width="494" /></a></div> You can control this feature in the “<a href="https://support.google.com/chrome/answer/185277?co=GENIE.Platform%3DDesktop&hl=en-GB">Sync and Google Services</a>” section of Chrome Settings. Enterprise admins can control this feature using <a href="https://cloud.google.com/docs/chrome-enterprise/policies/?policy=PasswordLeakDetectionEnabled">the PasswordLeakDetectionEnabled policy setting</a>. <br /> <br /> <br /> <strong>Real-time phishing protection: Checking with Safe Browsing’s blocklist in real time. </strong> <br /> Chrome’s new real-time phishing protection is also expanding existing technology — in this case it’s Google’s well-established <a href="https://safebrowsing.google.com/">Safe Browsing.</a> <br /> <br /> Every day, Safe Browsing discovers thousands of new unsafe sites and adds them to the blocklists shared with the web industry. Chrome checks the URL of each site you visit or file you download against this local list, which is updated approximately every 30 minutes. If you navigate to a URL that appears on the list, Chrome checks a partial URL fingerprint (the first 32 bits of a SHA-256 hash of the URL) with Google for verification that the URL is indeed dangerous. Google cannot determine the actual URL from this information. <br /> <br /> However, we’re noticing that some phishing sites slip through our 30-minute refresh window, either by switching domains very quickly or by hiding from Google's crawlers. <br /> <br /> That’s where real-time phishing protections come in. These new protections can inspect the URLs of pages visited with Safe Browsing’s servers in real time. When you visit a website, Chrome checks it against a list stored on your computer of thousands of popular websites that are known to be safe. If the website is not on the safe-list, Chrome checks the URL with Google (after dropping any username or password embedded in the URL) to find out if you're visiting a dangerous site. Our analysis has shown that this results in a 30% increase in protections by warning users on malicious sites that are brand new. <br /> <br /> We will be initially rolling out this feature for people who have already opted-in to “<a href="https://support.google.com/chrome/answer/9116376?hl=en">Make searches and browsing better</a>” setting in Chrome. Enterprises administrators can manage this setting via the <a href="https://cloud.google.com/docs/chrome-enterprise/policies/?policy=UrlKeyedAnonymizedDataCollectionEnabled">UrlKeyedAnonymizedDataCollectionEnabled policy settings</a>. <br /> <br /> <br /> <strong>Expanding predictive phishing protection</strong> <br /> Your password is the key to your online identity and data. If this key falls into the hands of attackers, they can easily impersonate you and get access to your data. We<a href="https://www.blog.google/technology/safety-security/new-security-protections-tailored-you/"> launched</a> predictive phishing protections to warn users who are syncing history in Chrome when they enter their Google Account password into suspected phishing sites that try to steal their credentials. <br /> <br /> With this latest release, we’re expanding this protection to everyone signed in to Chrome, even if you have not enabled Sync. In addition, this feature will now work for all the passwords you have stored in Chrome’s password manager. <br /> <br /> If you type one of your protected passwords (this could be a password you stored in Chrome’s password manager, or the Google Account password you used to sign in to Chrome) into an unusual site, Chrome classifies this as a potentially dangerous event. <br /> <br /> In such a scenario, Chrome checks the site against a list on your computer of thousands of popular websites that are known to be safe. If the website is not on the safe-list, Chrome checks the URL with Google (after dropping any username or password embedded in the URL). If this check determines that the site is indeed suspicious or malicious, Chrome will immediately show you a warning and encourage you to change your compromised password. If it was your Google Account password that was phished, Chrome also offers to notify Google so we can add additional protections to ensure your account isn't compromised. <br /> <br /> By watching for password reuse, Chrome can give heightened security in critical moments while minimizing the data it shares with Google. We think predictive phishing protection will protect hundreds of millions more people. <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:Better password protections in Chrome - How it works&url=https://security.googleblog.com/2019/12/better-password-protections-in-chrome.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/2019/12/better-password-protections-in-chrome.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/2019/12/better-password-protections-in-chrome.html' data-url='https://security.googleblog.com/2019/12/better-password-protections-in-chrome.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/12/better-password-protections-in-chrome.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='3599719621549025882' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/12/detecting-unsafe-path-access-patterns.html' itemprop='url' title='Detecting unsafe path access patterns with PathAuditor'> Detecting unsafe path access patterns with PathAuditor </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> December 9, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Marta Ro<span id="docs-internal-guid-c16842d7-7fff-42bf-1e60-c4b99ea23547"><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">ż</span></span>ek, Google Summer Intern 2019, and Stephen R<span id="docs-internal-guid-ba0b1c39-7fff-2390-95bb-fd8fbccab6e7"><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">ö</span></span>ttger, Software Engineer </span><br /> <br /> <b>#!/bin/sh<br />cat /home/user/foo</b><br /> <br /> What can go wrong if this command runs as root? Does it change anything if foo is a symbolic link to /etc/shadow? How is the output going to be used?<br /> <br /> Depending on the answers to the questions above, accessing files this way could be a vulnerability. The vulnerability exists in syscalls that operate on file paths, such as open, rename, chmod, or exec. For a vulnerability to be present, part of the path has to be user controlled and the program that executes the syscall has to be run at a higher privilege level. In a potential exploit, the attacker can substitute the path for a symlink and create, remove, or execute a file. In many cases, it's possible for an attacker to create the symlink before the syscall is executed.<br /> <br /> At Google, we have been working on a solution to find these potentially problematic issues at scale: PathAuditor. In this blog post we'll outline the problem and explain how you can avoid it in your code with PathAuditor.<br /> <br /> Let’s take a look at a real world example. The <a href="http://manpages.ubuntu.com/manpages/bionic/man8/tmpreaper.8.html">tmpreaper</a> utility contained the following code to check if a directory is a mount point:<br /> <b>if ((dst = malloc(strlen(ent->d_name) + 3)) == NULL)</b><br /> <b>       message (LOG_FATAL, "malloc failed.\n");<br />strcpy(dst, ent->d_name);<br />strcat(dst, "/X");<br />rename(ent->d_name, dst);<br />if (errno == EXDEV) {<br />[...]</b><br /> <br /> This code will call rename("/tmp/user/controlled", "/tmp/user/controlled/X"). Under the hood, the kernel will resolve the path twice, once for the first argument and once for the second, then perform some checks if the rename is valid and finally try to move the file from one directory to the other.<br /> <br /> However, the problem is that the user can race the kernel code and replace the “/tmp/user/controlled” with a symlink just between the two path resolutions.<br /> <br /> A successful attack would look roughly like this:<br /> <ul> <li>Make “/tmp/user/controlled” a file with controlled content.</li> <li>The kernel resolves that path for the first argument to rename() and sees the file.</li> <li>Replace “/tmp/user/controlled” with a symlink to /etc/cron.</li> <li>The kernel resolves the path again for the second argument and ends up in /etc/cron.</li> <li>If both the tmp and cron directories are on the filesystem, the kernel will move the attacker controlled file to /etc/cron, leading to code execution as root.</li> </ul> Can we find such bugs via automated analysis? Well, yes and no. As shown in the tmpreaper example, exploiting these bugs can require some creativity and it depends on the context if they’re vulnerabilities in the first place. Automated analysis can uncover instances of this access pattern and will gather as much information as it can to help with further investigation. However, it will also naturally produce false positives.<br /> <div> <br /></div> <div> We can’t tell if a call to open(/user/controlled, O_RDONLY) is a vulnerability without looking at the context. It depends on whether the contents are returned to the user or are used in some security sensitive way. A call to chmod(/user/controlled, mode) depending on the mode can be either a DoS or a privilege escalation. Accessing files in sticky directories (like /tmp) can become vulnerabilities if the attacker found an additional bug to delete arbitrary files.<br /> <br /> <div> <b>How Pathauditor works</b><br /> <b><br /></b> To find issues like this at scale we wrote <a href="https://github.com/google/path-auditor">PathAuditor</a>, a tool that monitors file accesses and logs potential vulnerabilities. PathAuditor is a shared library that can be loaded into processes using LD_PRELOAD. It then hooks all filesystem related libc functions and checks if the access is safe. For that, we traverse the path and check if any component could be replaced by an unprivileged user, for example if a directory is user-writable. If we detect such a pattern, we log it to syslog for manual analysis.<br /> <br /> Here's how you can use it to find vulnerabilities in your code: <br /> <ul> <li>LD_PRELOAD the library to your binary and then analyse its findings in syslog. You can also add the library to /etc/ld.so.preload, which will preload it in all binaries running on the system. </li> <li>It will then gather the PID and the command line of the calling process, arguments of the vulnerable function, and a stack trace -- this provides a starting point for further investigation. At this point, you can use the stack trace to find the code path that triggered the violation and manually analyse what would happen if you would point the path to an arbitrary file or directory. </li> <li>For example, if the code is opening a file and returning the content to the user then you could use it to read arbitrary files. If you control the path of chmod or chown, you might be able to change the permissions of chosen files and so on. </li> </ul> PathAuditor has proved successful at Google and we're excited to share it with the community. The project is still in the early stages and we are actively working on it. We look forward to hearing about any vulnerabilities you discover with the tool, and hope to see pull requests with further improvements.</div> <div> <br /></div> <div> Try out the PathAuditor tool <a href="https://github.com/google/path-auditor">here</a>.<br /> <div> <span style="background-color: transparent; color: black; font-family: "roboto mono" , monospace; font-size: 11pt; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><span id="docs-internal-guid-137f0c97-7fff-c927-64bb-4d857e815f39" style="font-weight: normal;"><br /></span></span> <div dir="ltr" style="line-height: 1.38; margin-bottom: 16pt; margin-top: 0pt;"> <span style="background-color: transparent; color: black; font-family: "roboto mono" , monospace; font-size: 11pt; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><span id="docs-internal-guid-137f0c97-7fff-c927-64bb-4d857e815f39" style="font-weight: normal;"><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline;"><i>Marta Rożek was a Google Summer intern in 2019 and contributed to this blog and the PathAuditor tool </i></span></span></span></div> <span style="background-color: transparent; color: black; font-family: "roboto mono" , monospace; font-size: 11pt; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><span id="docs-internal-guid-137f0c97-7fff-c927-64bb-4d857e815f39" style="font-weight: normal;"> <div style="font-style: normal;"> <span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline;"><br /></span></div> </span></span></div> </div> </div> <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 Marta Ro<span id="docs-internal-guid-c16842d7-7fff-42bf-1e60-c4b99ea23547"><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">ż</span></span>ek, Google Summer Intern 2019, and Stephen R<span id="docs-internal-guid-ba0b1c39-7fff-2390-95bb-fd8fbccab6e7"><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">ö</span></span>ttger, Software Engineer </span><br /> <br /> <b>#!/bin/sh<br />cat /home/user/foo</b><br /> <br /> What can go wrong if this command runs as root? Does it change anything if foo is a symbolic link to /etc/shadow? How is the output going to be used?<br /> <br /> Depending on the answers to the questions above, accessing files this way could be a vulnerability. The vulnerability exists in syscalls that operate on file paths, such as open, rename, chmod, or exec. For a vulnerability to be present, part of the path has to be user controlled and the program that executes the syscall has to be run at a higher privilege level. In a potential exploit, the attacker can substitute the path for a symlink and create, remove, or execute a file. In many cases, it's possible for an attacker to create the symlink before the syscall is executed.<br /> <br /> At Google, we have been working on a solution to find these potentially problematic issues at scale: PathAuditor. In this blog post we'll outline the problem and explain how you can avoid it in your code with PathAuditor.<br /> <br /> Let’s take a look at a real world example. The <a href="http://manpages.ubuntu.com/manpages/bionic/man8/tmpreaper.8.html">tmpreaper</a> utility contained the following code to check if a directory is a mount point:<br /> <b>if ((dst = malloc(strlen(ent->d_name) + 3)) == NULL)</b><br /> <b>       message (LOG_FATAL, "malloc failed.\n");<br />strcpy(dst, ent->d_name);<br />strcat(dst, "/X");<br />rename(ent->d_name, dst);<br />if (errno == EXDEV) {<br />[...]</b><br /> <br /> This code will call rename("/tmp/user/controlled", "/tmp/user/controlled/X"). Under the hood, the kernel will resolve the path twice, once for the first argument and once for the second, then perform some checks if the rename is valid and finally try to move the file from one directory to the other.<br /> <br /> However, the problem is that the user can race the kernel code and replace the “/tmp/user/controlled” with a symlink just between the two path resolutions.<br /> <br /> A successful attack would look roughly like this:<br /> <ul> <li>Make “/tmp/user/controlled” a file with controlled content.</li> <li>The kernel resolves that path for the first argument to rename() and sees the file.</li> <li>Replace “/tmp/user/controlled” with a symlink to /etc/cron.</li> <li>The kernel resolves the path again for the second argument and ends up in /etc/cron.</li> <li>If both the tmp and cron directories are on the filesystem, the kernel will move the attacker controlled file to /etc/cron, leading to code execution as root.</li> </ul> Can we find such bugs via automated analysis? Well, yes and no. As shown in the tmpreaper example, exploiting these bugs can require some creativity and it depends on the context if they’re vulnerabilities in the first place. Automated analysis can uncover instances of this access pattern and will gather as much information as it can to help with further investigation. However, it will also naturally produce false positives.<br /> <div> <br /></div> <div> We can’t tell if a call to open(/user/controlled, O_RDONLY) is a vulnerability without looking at the context. It depends on whether the contents are returned to the user or are used in some security sensitive way. A call to chmod(/user/controlled, mode) depending on the mode can be either a DoS or a privilege escalation. Accessing files in sticky directories (like /tmp) can become vulnerabilities if the attacker found an additional bug to delete arbitrary files.<br /> <br /> <div> <b>How Pathauditor works</b><br /> <b><br /></b> To find issues like this at scale we wrote <a href="https://github.com/google/path-auditor">PathAuditor</a>, a tool that monitors file accesses and logs potential vulnerabilities. PathAuditor is a shared library that can be loaded into processes using LD_PRELOAD. It then hooks all filesystem related libc functions and checks if the access is safe. For that, we traverse the path and check if any component could be replaced by an unprivileged user, for example if a directory is user-writable. If we detect such a pattern, we log it to syslog for manual analysis.<br /> <br /> Here's how you can use it to find vulnerabilities in your code: <br /> <ul> <li>LD_PRELOAD the library to your binary and then analyse its findings in syslog. You can also add the library to /etc/ld.so.preload, which will preload it in all binaries running on the system. </li> <li>It will then gather the PID and the command line of the calling process, arguments of the vulnerable function, and a stack trace -- this provides a starting point for further investigation. At this point, you can use the stack trace to find the code path that triggered the violation and manually analyse what would happen if you would point the path to an arbitrary file or directory. </li> <li>For example, if the code is opening a file and returning the content to the user then you could use it to read arbitrary files. If you control the path of chmod or chown, you might be able to change the permissions of chosen files and so on. </li> </ul> PathAuditor has proved successful at Google and we're excited to share it with the community. The project is still in the early stages and we are actively working on it. We look forward to hearing about any vulnerabilities you discover with the tool, and hope to see pull requests with further improvements.</div> <div> <br /></div> <div> Try out the PathAuditor tool <a href="https://github.com/google/path-auditor">here</a>.<br /> <div> <span style="background-color: transparent; color: black; font-family: "roboto mono" , monospace; font-size: 11pt; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><span id="docs-internal-guid-137f0c97-7fff-c927-64bb-4d857e815f39" style="font-weight: normal;"><br /></span></span> <div dir="ltr" style="line-height: 1.38; margin-bottom: 16pt; margin-top: 0pt;"> <span style="background-color: transparent; color: black; font-family: "roboto mono" , monospace; font-size: 11pt; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><span id="docs-internal-guid-137f0c97-7fff-c927-64bb-4d857e815f39" style="font-weight: normal;"><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline;"><i>Marta Rożek was a Google Summer intern in 2019 and contributed to this blog and the PathAuditor tool </i></span></span></span></div> <span style="background-color: transparent; color: black; font-family: "roboto mono" , monospace; font-size: 11pt; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><span id="docs-internal-guid-137f0c97-7fff-c927-64bb-4d857e815f39" style="font-weight: normal;"> <div style="font-style: normal;"> <span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline;"><br /></span></div> </span></span></div> </div> </div> <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:Detecting unsafe path access patterns with PathAuditor&url=https://security.googleblog.com/2019/12/detecting-unsafe-path-access-patterns.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/2019/12/detecting-unsafe-path-access-patterns.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/2019/12/detecting-unsafe-path-access-patterns.html' data-url='https://security.googleblog.com/2019/12/detecting-unsafe-path-access-patterns.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/12/detecting-unsafe-path-access-patterns.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='4001781070534033664' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/12/an-update-on-android-tls-adoption.html' itemprop='url' title=' An Update on Android TLS Adoption'> An Update on Android TLS Adoption </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> December 3, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <meta name="twitter:image" content="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrfcBQ1qvsEgsgVRFimtT7oWkLNeDfmij23iX7FU4lvEmSjobdWdQnBiezhCuGnWz7hHoNmKUMBIbLkP5Fva3l77-bw4S31Rs-HaExPzLKI8ebByTNc0hRFBWCDLlATq9AkcyiQXmIXtc/s1600/image3.png"> <img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrfcBQ1qvsEgsgVRFimtT7oWkLNeDfmij23iX7FU4lvEmSjobdWdQnBiezhCuGnWz7hHoNmKUMBIbLkP5Fva3l77-bw4S31Rs-HaExPzLKI8ebByTNc0hRFBWCDLlATq9AkcyiQXmIXtc/s1600/image3.png" style="display:none"> <p><em>Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security</em><p> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrfcBQ1qvsEgsgVRFimtT7oWkLNeDfmij23iX7FU4lvEmSjobdWdQnBiezhCuGnWz7hHoNmKUMBIbLkP5Fva3l77-bw4S31Rs-HaExPzLKI8ebByTNc0hRFBWCDLlATq9AkcyiQXmIXtc/s1600/image3.png" imageanchor="1" ><img alt="banner illustration with several devices and gaming controller" border="0" data-original-height="699" data-original-width="1272" id="imgFull" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrfcBQ1qvsEgsgVRFimtT7oWkLNeDfmij23iX7FU4lvEmSjobdWdQnBiezhCuGnWz7hHoNmKUMBIbLkP5Fva3l77-bw4S31Rs-HaExPzLKI8ebByTNc0hRFBWCDLlATq9AkcyiQXmIXtc/s1600/image3.png" style="width:100%;" /></a> <p> Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting network traffic that enters or leaves an Android device with Transport Layer Security (TLS). </p> <p> Android 7 (API level 24) <a href="https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html">introduced</a> the <a href="https://developer.android.com/training/articles/security-config.html">Network Security Configuration</a> in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a <a href="https://android-developers.googleblog.com/2018/04/protecting-users-with-tls-by-default-in.html">policy</a> set by default that prevents unencrypted traffic for every domain. </p> <p> Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default. </p> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-jmd6Kza6OoYdTz12HQDR410v6CUp82BXPel_rCG7Uyk5i9tGQczrdXqxnuj8dwJkw3fUgdYWn6i2b7_tBUzPDGVA1TlmKP0ZmGcdjeTO0WUUapRZluLmHE08vjBch93GuGYa5lpf1W4/s1600/image1.png" imageanchor="1" ><img alt="Percentage of apps that block cleartext by default." border="0" data-original-height="388" data-original-width="626" id="imgFull" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-jmd6Kza6OoYdTz12HQDR410v6CUp82BXPel_rCG7Uyk5i9tGQczrdXqxnuj8dwJkw3fUgdYWn6i2b7_tBUzPDGVA1TlmKP0ZmGcdjeTO0WUUapRZluLmHE08vjBch93GuGYa5lpf1W4/s1600/image1.png" style="width:85%;" /></a> <p id="imgCaption"> Percentage of apps that block cleartext by default. </p> <p> Since November 1 2019, <a href="https://developer.android.com/distribute/best-practices/develop/target-sdk">all app (updates as well as all new apps on Google Play) must target at least Android 9</a>. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer. </p> <p> The latest releases of Android Studio and Google Play’s <a href="https://support.google.com/googleplay/android-developer/answer/7002270">pre-launch report</a> warn developers when their app includes a potentially insecure Network Security Configuration (for example, when they allow unencrypted traffic for all domains or when they accept user provided certificates outside of debug mode). This encourages the adoption of HTTPS across the Android ecosystem and ensures that developers are aware of their security configuration. </p> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQmYj6nyUVYXII42yfduMgDAGeWrT0x1qrByTGFzSfTRSuop3d4SeB6Up_cUcGJOT03LsmirL-J8xceUyEcwvC3kVxwgCaOBnCWczGm5tUHr7nnDPK3V7-UOvp-AQ_FLviBXvJqSxOHak/s1600/image2.png" imageanchor="1" ><img alt="Example of a warning shown to developers in Android Studio." border="0" data-original-height="209" data-original-width="680" id="imgFull" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQmYj6nyUVYXII42yfduMgDAGeWrT0x1qrByTGFzSfTRSuop3d4SeB6Up_cUcGJOT03LsmirL-J8xceUyEcwvC3kVxwgCaOBnCWczGm5tUHr7nnDPK3V7-UOvp-AQ_FLviBXvJqSxOHak/s1600/image2.png" /></a> <p id="imgCaption"> Example of a warning shown to developers in Android Studio. </p> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_GG5yAqVXobMSSn9Gk-9bt_1SAkaSxHX6QOIqzSIuQrTnQCnIc9iOzDFJxOAFla9Vo4lo7GCXRjaN0grLcspDzK_SH4j9l98wFrmPbtvMQJ05lH78_Fe1Y40GmIvVCATvVlGb7x0mC5s/s1600/image4.png" imageanchor="1" ><img alt="Example of a warning shown to developers as part of the pre-launch report." border="0" data-original-height="223" data-original-width="997" id="imgFull" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_GG5yAqVXobMSSn9Gk-9bt_1SAkaSxHX6QOIqzSIuQrTnQCnIc9iOzDFJxOAFla9Vo4lo7GCXRjaN0grLcspDzK_SH4j9l98wFrmPbtvMQJ05lH78_Fe1Y40GmIvVCATvVlGb7x0mC5s/s1600/image4.png" /></a> <p id="imgCaption"> Example of a warning shown to developers as part of the <a href="https://support.google.com/googleplay/android-developer/answer/7002270">pre-launch report</a>. </p> <h2>What can I do to secure my app?</h2> <p> For apps targeting Android 9 and higher, the out-of-the-box default is to encrypt all network traffic in transit and trust only certificates issued by an authority in the standard Android CA set without requiring any extra configuration. Apps can provide an exception to this only by including a separate Network Security Config file with carefully selected exceptions. </p> <p> If your app needs to allow traffic to certain domains, it can do so by including a Network Security Config file that only includes these exceptions to the default secure policy. <strong>Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.</strong> </p> <pre class="prettyprint"><network-security-config> <base-config cleartextTrafficPermitted="false" /> <domain-config cleartextTrafficPermitted="true"> <domain includeSubdomains="true">insecure.example.com</domain> <domain includeSubdomains="true">insecure.cdn.example.com</domain> </domain-config> </network-security-config></pre> <p> If your app needs to be able to accept user specified certificates for testing purposes (for example, connecting to a local server during testing), make sure to wrap your <code><trust-anchors></code> element inside a <code><debug-overrides></code> element. This ensures the connections in the production version of your app are secure. </p> <pre class="prettyprint"><network-security-config> <debug-overrides> <trust-anchors> <certificates src="user"/> </trust-anchors> </debug-overrides> </network-security-config></pre> <h2>What can I do to secure my library?</h2> <p> If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking <code><a href="https://developer.android.com/reference/android/security/NetworkSecurityPolicy.html#isCleartextTrafficPermitted(java.lang.String)">isCleartextTrafficPermitted</a></code> <em>before</em> opening any cleartext connection. <p> Android’s <a href="https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection.html">built-in networking libraries</a> and other popular HTTP libraries such as <a href="https://square.github.io/okhttp/">OkHttp</a> or <a href="https://developer.android.com/training/volley/index.html">Volley</a> have built-in Network Security Config support. </p> <p> <em>Giles Hogben, Nwokedi Idika, Android Platform Security, Android Studio and Pre-Launch Report teams</em> </p> <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <meta name="twitter:image" content="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrfcBQ1qvsEgsgVRFimtT7oWkLNeDfmij23iX7FU4lvEmSjobdWdQnBiezhCuGnWz7hHoNmKUMBIbLkP5Fva3l77-bw4S31Rs-HaExPzLKI8ebByTNc0hRFBWCDLlATq9AkcyiQXmIXtc/s1600/image3.png"> <img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrfcBQ1qvsEgsgVRFimtT7oWkLNeDfmij23iX7FU4lvEmSjobdWdQnBiezhCuGnWz7hHoNmKUMBIbLkP5Fva3l77-bw4S31Rs-HaExPzLKI8ebByTNc0hRFBWCDLlATq9AkcyiQXmIXtc/s1600/image3.png" style="display:none"> <p><em>Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security</em><p> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrfcBQ1qvsEgsgVRFimtT7oWkLNeDfmij23iX7FU4lvEmSjobdWdQnBiezhCuGnWz7hHoNmKUMBIbLkP5Fva3l77-bw4S31Rs-HaExPzLKI8ebByTNc0hRFBWCDLlATq9AkcyiQXmIXtc/s1600/image3.png" imageanchor="1" ><img alt="banner illustration with several devices and gaming controller" border="0" data-original-height="699" data-original-width="1272" id="imgFull" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrfcBQ1qvsEgsgVRFimtT7oWkLNeDfmij23iX7FU4lvEmSjobdWdQnBiezhCuGnWz7hHoNmKUMBIbLkP5Fva3l77-bw4S31Rs-HaExPzLKI8ebByTNc0hRFBWCDLlATq9AkcyiQXmIXtc/s1600/image3.png" style="width:100%;" /></a> <p> Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting network traffic that enters or leaves an Android device with Transport Layer Security (TLS). </p> <p> Android 7 (API level 24) <a href="https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html">introduced</a> the <a href="https://developer.android.com/training/articles/security-config.html">Network Security Configuration</a> in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a <a href="https://android-developers.googleblog.com/2018/04/protecting-users-with-tls-by-default-in.html">policy</a> set by default that prevents unencrypted traffic for every domain. </p> <p> Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default. </p> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-jmd6Kza6OoYdTz12HQDR410v6CUp82BXPel_rCG7Uyk5i9tGQczrdXqxnuj8dwJkw3fUgdYWn6i2b7_tBUzPDGVA1TlmKP0ZmGcdjeTO0WUUapRZluLmHE08vjBch93GuGYa5lpf1W4/s1600/image1.png" imageanchor="1" ><img alt="Percentage of apps that block cleartext by default." border="0" data-original-height="388" data-original-width="626" id="imgFull" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-jmd6Kza6OoYdTz12HQDR410v6CUp82BXPel_rCG7Uyk5i9tGQczrdXqxnuj8dwJkw3fUgdYWn6i2b7_tBUzPDGVA1TlmKP0ZmGcdjeTO0WUUapRZluLmHE08vjBch93GuGYa5lpf1W4/s1600/image1.png" style="width:85%;" /></a> <p id="imgCaption"> Percentage of apps that block cleartext by default. </p> <p> Since November 1 2019, <a href="https://developer.android.com/distribute/best-practices/develop/target-sdk">all app (updates as well as all new apps on Google Play) must target at least Android 9</a>. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer. </p> <p> The latest releases of Android Studio and Google Play’s <a href="https://support.google.com/googleplay/android-developer/answer/7002270">pre-launch report</a> warn developers when their app includes a potentially insecure Network Security Configuration (for example, when they allow unencrypted traffic for all domains or when they accept user provided certificates outside of debug mode). This encourages the adoption of HTTPS across the Android ecosystem and ensures that developers are aware of their security configuration. </p> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQmYj6nyUVYXII42yfduMgDAGeWrT0x1qrByTGFzSfTRSuop3d4SeB6Up_cUcGJOT03LsmirL-J8xceUyEcwvC3kVxwgCaOBnCWczGm5tUHr7nnDPK3V7-UOvp-AQ_FLviBXvJqSxOHak/s1600/image2.png" imageanchor="1" ><img alt="Example of a warning shown to developers in Android Studio." border="0" data-original-height="209" data-original-width="680" id="imgFull" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQmYj6nyUVYXII42yfduMgDAGeWrT0x1qrByTGFzSfTRSuop3d4SeB6Up_cUcGJOT03LsmirL-J8xceUyEcwvC3kVxwgCaOBnCWczGm5tUHr7nnDPK3V7-UOvp-AQ_FLviBXvJqSxOHak/s1600/image2.png" /></a> <p id="imgCaption"> Example of a warning shown to developers in Android Studio. </p> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_GG5yAqVXobMSSn9Gk-9bt_1SAkaSxHX6QOIqzSIuQrTnQCnIc9iOzDFJxOAFla9Vo4lo7GCXRjaN0grLcspDzK_SH4j9l98wFrmPbtvMQJ05lH78_Fe1Y40GmIvVCATvVlGb7x0mC5s/s1600/image4.png" imageanchor="1" ><img alt="Example of a warning shown to developers as part of the pre-launch report." border="0" data-original-height="223" data-original-width="997" id="imgFull" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_GG5yAqVXobMSSn9Gk-9bt_1SAkaSxHX6QOIqzSIuQrTnQCnIc9iOzDFJxOAFla9Vo4lo7GCXRjaN0grLcspDzK_SH4j9l98wFrmPbtvMQJ05lH78_Fe1Y40GmIvVCATvVlGb7x0mC5s/s1600/image4.png" /></a> <p id="imgCaption"> Example of a warning shown to developers as part of the <a href="https://support.google.com/googleplay/android-developer/answer/7002270">pre-launch report</a>. </p> <h2>What can I do to secure my app?</h2> <p> For apps targeting Android 9 and higher, the out-of-the-box default is to encrypt all network traffic in transit and trust only certificates issued by an authority in the standard Android CA set without requiring any extra configuration. Apps can provide an exception to this only by including a separate Network Security Config file with carefully selected exceptions. </p> <p> If your app needs to allow traffic to certain domains, it can do so by including a Network Security Config file that only includes these exceptions to the default secure policy. <strong>Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.</strong> </p> <pre class="prettyprint"><network-security-config> <base-config cleartextTrafficPermitted="false" /> <domain-config cleartextTrafficPermitted="true"> <domain includeSubdomains="true">insecure.example.com</domain> <domain includeSubdomains="true">insecure.cdn.example.com</domain> </domain-config> </network-security-config></pre> <p> If your app needs to be able to accept user specified certificates for testing purposes (for example, connecting to a local server during testing), make sure to wrap your <code><trust-anchors></code> element inside a <code><debug-overrides></code> element. This ensures the connections in the production version of your app are secure. </p> <pre class="prettyprint"><network-security-config> <debug-overrides> <trust-anchors> <certificates src="user"/> </trust-anchors> </debug-overrides> </network-security-config></pre> <h2>What can I do to secure my library?</h2> <p> If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking <code><a href="https://developer.android.com/reference/android/security/NetworkSecurityPolicy.html#isCleartextTrafficPermitted(java.lang.String)">isCleartextTrafficPermitted</a></code> <em>before</em> opening any cleartext connection. <p> Android’s <a href="https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection.html">built-in networking libraries</a> and other popular HTTP libraries such as <a href="https://square.github.io/okhttp/">OkHttp</a> or <a href="https://developer.android.com/training/volley/index.html">Volley</a> have built-in Network Security Config support. </p> <p> <em>Giles Hogben, Nwokedi Idika, Android Platform Security, Android Studio and Pre-Launch Report teams</em> </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 Android TLS Adoption&url=https://security.googleblog.com/2019/12/an-update-on-android-tls-adoption.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/2019/12/an-update-on-android-tls-adoption.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/2019/12/an-update-on-android-tls-adoption.html' data-url='https://security.googleblog.com/2019/12/an-update-on-android-tls-adoption.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/12/an-update-on-android-tls-adoption.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/android%20security' rel='tag'> android security </a> </span> </div> </div> </div> <div class='post' data-id='3419519380131378987' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/11/expanding-android-security-rewards.html' itemprop='url' title=' Expanding the Android Security Rewards Program'> Expanding the Android Security Rewards Program </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> November 21, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Jessica Lin, Android Security Team</span> <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoASBxlolSZ-HyhUYmEmyS6keQxkVjnl2dQS1HSpvzSuIIrpw5jyHAiE9Nd_mhaaR_Vk1gK0-yMIzrU3bCOxHvIl_tZ3arhGMe5U1EQ1M-wbRJXSiOx0bYV4W4UggR9DRTRVvT4gT0oY0k/s1600/bugsVRP_REV8+%25281%2529.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="634" data-original-width="1168" height="347" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoASBxlolSZ-HyhUYmEmyS6keQxkVjnl2dQS1HSpvzSuIIrpw5jyHAiE9Nd_mhaaR_Vk1gK0-yMIzrU3bCOxHvIl_tZ3arhGMe5U1EQ1M-wbRJXSiOx0bYV4W4UggR9DRTRVvT4gT0oY0k/s640/bugsVRP_REV8+%25281%2529.png" width="640" /></a></div> <p> The <a href="https://www.google.com/about/appsecurity/android-rewards/">Android Security Rewards</a> (ASR) program was created in 2015 to reward researchers who find and report security issues to help keep the Android ecosystem safe. Over the past 4 years, we have awarded over 1,800 reports, and paid out over four million dollars. </p> <p> Today, we’re expanding the program and increasing reward amounts. We are introducing a top prize of $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. Additionally, we will be launching a specific program offering a 50% bonus for exploits found on specific developer preview versions of Android, meaning our top prize is now $1.5 million. </p> <p> As mentioned in a <a href="https://security.googleblog.com/2019/05/quantifying-measurable-security.html">previous blog post,</a> in 2019 Gartner rated the Pixel 3 with Titan M as having the most “strong” ratings in the built-in security section out of all devices evaluated. This is why we’ve created a dedicated prize to reward researchers for exploits found to circumvent the secure elements protections. </p> <p> In addition to exploits involving Pixel Titan M, we have added other categories of exploits to the rewards program, such as those involving data exfiltration and lockscreen bypass. These rewards go up to $500,000 depending on the exploit category. For full details, please refer to the <a href="https://www.google.com/about/appsecurity/android-rewards/">Android Security Rewards Program Rules page</a>. </p> <p> Now that we’ve covered some of what’s new, let’s take a look back at some milestones from this year. Here are some highlights from 2019: </p> <ul> <li>Total payouts in the last 12 months have been over $1.5 million. </li> </ul> <ul> <li>Over 100 participating researchers have received an average reward amount of over $3,800 per finding (46% increase from last year). On average, this means we paid out over $15,000 (20% increase from last year) per researcher!<br> <li>The top reward paid out in 2019 was $161,337. </li> </ul> <h2><strong>Top Payout</strong></h2> <p> The highest reward paid out to a member of the research community was for a report from Guang Gong (<a href="https://twitter.com/oldfresher">@oldfresher</a>) of Alpha Lab, Qihoo 360 Technology Co. Ltd. This report detailed the first reported 1-click remote code execution exploit chain on the Pixel 3 device. Guang Gong was awarded $161,337 from the <a href="https://www.google.com/about/appsecurity/android-rewards/">Android Security Rewards program</a> and $40,000 by <a href="https://www.google.com/about/appsecurity/chrome-rewards/">Chrome Rewards program</a> for a total of $201,337. The $201,337 combined reward is also the highest reward for a single exploit chain across all Google VRP programs. The Chrome vulnerabilities leveraged in this report were fixed in <a href="https://chromereleases.googleblog.com/2019/09/stable-channel-update-for-desktop.html">Chrome 77.0.3865.75</a> and released in September, protecting users against this exploit chain. </p> <p> We’d like to thank all of our researchers for contributing to the security of the Android ecosystem. If you’re interested in becoming a researcher, check out our <a href="https://sites.google.com/site/bughunteruniversity/improve/how-to-submit-an-android-platform-bug-report">Bughunter University</a> for information on how to get started. </p> <p> Starting today November 21, 2019 the new rewards take effect. Any reports that were submitted before November 21, 2019 will be rewarded based on the previously existing rewards table. </p> <p> Happy bug 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">Posted by Jessica Lin, Android Security Team</span> <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoASBxlolSZ-HyhUYmEmyS6keQxkVjnl2dQS1HSpvzSuIIrpw5jyHAiE9Nd_mhaaR_Vk1gK0-yMIzrU3bCOxHvIl_tZ3arhGMe5U1EQ1M-wbRJXSiOx0bYV4W4UggR9DRTRVvT4gT0oY0k/s1600/bugsVRP_REV8+%25281%2529.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="634" data-original-width="1168" height="347" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoASBxlolSZ-HyhUYmEmyS6keQxkVjnl2dQS1HSpvzSuIIrpw5jyHAiE9Nd_mhaaR_Vk1gK0-yMIzrU3bCOxHvIl_tZ3arhGMe5U1EQ1M-wbRJXSiOx0bYV4W4UggR9DRTRVvT4gT0oY0k/s640/bugsVRP_REV8+%25281%2529.png" width="640" /></a></div> <p> The <a href="https://www.google.com/about/appsecurity/android-rewards/">Android Security Rewards</a> (ASR) program was created in 2015 to reward researchers who find and report security issues to help keep the Android ecosystem safe. Over the past 4 years, we have awarded over 1,800 reports, and paid out over four million dollars. </p> <p> Today, we’re expanding the program and increasing reward amounts. We are introducing a top prize of $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. Additionally, we will be launching a specific program offering a 50% bonus for exploits found on specific developer preview versions of Android, meaning our top prize is now $1.5 million. </p> <p> As mentioned in a <a href="https://security.googleblog.com/2019/05/quantifying-measurable-security.html">previous blog post,</a> in 2019 Gartner rated the Pixel 3 with Titan M as having the most “strong” ratings in the built-in security section out of all devices evaluated. This is why we’ve created a dedicated prize to reward researchers for exploits found to circumvent the secure elements protections. </p> <p> In addition to exploits involving Pixel Titan M, we have added other categories of exploits to the rewards program, such as those involving data exfiltration and lockscreen bypass. These rewards go up to $500,000 depending on the exploit category. For full details, please refer to the <a href="https://www.google.com/about/appsecurity/android-rewards/">Android Security Rewards Program Rules page</a>. </p> <p> Now that we’ve covered some of what’s new, let’s take a look back at some milestones from this year. Here are some highlights from 2019: </p> <ul> <li>Total payouts in the last 12 months have been over $1.5 million. </li> </ul> <ul> <li>Over 100 participating researchers have received an average reward amount of over $3,800 per finding (46% increase from last year). On average, this means we paid out over $15,000 (20% increase from last year) per researcher!<br> <li>The top reward paid out in 2019 was $161,337. </li> </ul> <h2><strong>Top Payout</strong></h2> <p> The highest reward paid out to a member of the research community was for a report from Guang Gong (<a href="https://twitter.com/oldfresher">@oldfresher</a>) of Alpha Lab, Qihoo 360 Technology Co. Ltd. This report detailed the first reported 1-click remote code execution exploit chain on the Pixel 3 device. Guang Gong was awarded $161,337 from the <a href="https://www.google.com/about/appsecurity/android-rewards/">Android Security Rewards program</a> and $40,000 by <a href="https://www.google.com/about/appsecurity/chrome-rewards/">Chrome Rewards program</a> for a total of $201,337. The $201,337 combined reward is also the highest reward for a single exploit chain across all Google VRP programs. The Chrome vulnerabilities leveraged in this report were fixed in <a href="https://chromereleases.googleblog.com/2019/09/stable-channel-update-for-desktop.html">Chrome 77.0.3865.75</a> and released in September, protecting users against this exploit chain. </p> <p> We’d like to thank all of our researchers for contributing to the security of the Android ecosystem. If you’re interested in becoming a researcher, check out our <a href="https://sites.google.com/site/bughunteruniversity/improve/how-to-submit-an-android-platform-bug-report">Bughunter University</a> for information on how to get started. </p> <p> Starting today November 21, 2019 the new rewards take effect. Any reports that were submitted before November 21, 2019 will be rewarded based on the previously existing rewards table. </p> <p> Happy bug 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: Expanding the Android Security Rewards Program&url=https://security.googleblog.com/2019/11/expanding-android-security-rewards.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/2019/11/expanding-android-security-rewards.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/2019/11/expanding-android-security-rewards.html' data-url='https://security.googleblog.com/2019/11/expanding-android-security-rewards.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/11/expanding-android-security-rewards.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/android%20security' rel='tag'> android security </a> </span> </div> </div> </div> <div class='post' data-id='119521864970808537' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/11/using-built-in-fido-authenticator-on.html' itemprop='url' title='Using a built-in FIDO authenticator on latest-generation Chromebooks '> Using a built-in FIDO authenticator on latest-generation Chromebooks </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> November 19, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Christiaan Brand, Product Manager, Google Cloud </span><br /> <span class="byline-author"><br /></span> <span class="byline-author"><br /></span> <span class="byline-author"><span id="docs-internal-guid-eeba40d9-7fff-3dd0-cbcf-d34e4c1c2ece"></span></span><br /> We previously <a href="https://cloud.google.com/blog/products/chrome-enterprise/admin-insider-whats-new-in-chrome-enterprise-release-76">announced</a> that starting with Chrome 76, most latest-generation Chromebooks gained the option to enable a built-in FIDO authenticator backed by hardware-based Titan security. For supported services (e.g. G Suite, Google Cloud Platform), enterprise administrators can now allow end users to use the power button on these devices to protect against certain classes of account takeover attempts. This feature is disabled by default, however, administrators can enable it by changing <a href="https://cloud.google.com/docs/chrome-enterprise/policies/?policy=DeviceSecondFactorAuthentication">DeviceSecondFactorAuthentication</a> policy in the Google Admin console. <br /> <div> <br /></div> Before we dive deeper into this capability, let’s first cover the main use cases FIDO technology solves, and then explore how this new enhancement can satisfy an advanced requirement that can help enterprise organizations.<br /> <div> <b><br /></b></div> <div> <b>Main use cases</b><br /> <a href="https://fidoalliance.org/how-fido-works/">FIDO technology</a> aims to solve three separate use cases for relying parties (or otherwise referred to as Internet services) by helping to: <br /> <ol> <li>Prevent phishing during initial login to a service on a new device;</li> <li>Reverify a user’s identity to a service on a device on which they’ve already logged in to; </li> <li>Confirm that the device a user is connecting from is still the original device where they logged in from previously. This is typically needed in the enterprise. </li> </ol> Security-savvy professionals may interpret the third use case as a special instance of use case #2. However, there are some differences, which we break down a bit further below: <br /> <ul> <li>In case #2, the problem that FIDO technology tries to solve is re-verifying a user’s identity by unlocking a private key stored on the device.</li> <li>In case #3, FIDO technology helps to determine whether a previously created key is still available on the original device without any proof of who the user is.</li> </ul> <b>How use case #1 works: Roaming security keys </b><br /> <div> <br /> Because the whole premise of this use case is one in which the user logs in on a brand new device they’ve never authenticated before, this requires the user to have a FIDO security key (removeable, cross-platform, or a roaming authenticator). By this definition, a built-in FIDO authenticator on Chrome OS devices would not be able to satisfy this requirement, because it would not be able to help verify the user’s identity without being set up previously. Upon initial log-in, the user’s identity is verified together with the presence of a security key (such as Google’s <a href="https://store.google.com/product/titan_security_key">Titan Security Key</a>) previously tied to their account. </div> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-0wdlTgo_8PU/XdMzT86MbYI/AAAAAAAABKs/-IIrM2d5giMGM7mV1UdkC01-e1y4fyvigCNcBGAsYHQ/s1600/titankeys.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="300" data-original-width="517" height="185" src="https://1.bp.blogspot.com/-0wdlTgo_8PU/XdMzT86MbYI/AAAAAAAABKs/-IIrM2d5giMGM7mV1UdkC01-e1y4fyvigCNcBGAsYHQ/s320/titankeys.png" width="320" /></a></div> <div class="separator" style="clear: both; text-align: center;"> <u>Titan Security Keys </u></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> Once the user is successfully logged in, trust is conferred from the security key to the device on which the user is logging on, usually by placing a cookie or other token on the device in order for the relying party to “remember” that the user already performed a second factor authenticator on this device. Once this step is completed, it is no longer necessary to require a physical second factor on this device because the presence of the cookie signals to the relying party that this device is to be trusted. <br /> <br /> Optionally, some services might require the user to still periodically verify that it’s the correct user in front of the already recognized device (for example, particularly sensitive and regulated services such as financial services companies). In almost all cases, it shouldn’t be necessary for the user to also-in addition to providing their knowledge factor (such as a password) - re-present their second factor when re-authenticating as they’ve already done that during initial bootstrapping.<br /> <br /> Note that on Chrome OS devices, your data is encrypted when you’re not logged on, <a href="https://services.google.com/fh/files/misc/google_enterprise_chrome_security_whitepaper.pdf">which further protects your data</a> against malicious access.</div> <div> <b><br /></b></div> <div> <b>How use case #2 works: Re-authentication </b></div> <br /> Frequently referred to as “re-authentication,” use case #2 allows a relying party to reverify that the same user is still interacting with the service from a previously verified device. This mainly happens when a user performs an action that’s particularly sensitive, such as changing their password or when interacting with regulated services, such as financial services companies. In this case, a built-in biometric authenticator (e.g. a fingerprint sensor or PIN on Android devices) can be registered, which offers users a more convenient way to re-verify their identity to the service in question. In fact, we have <a href="https://security.googleblog.com/2019/08/making-authentication-even-easier-with_12.html">recently enabled</a> this use case on Android devices for some Google services.<br /> <div> <br /> Additionally, there are security benefits to this particular solution, as the relying party doesn’t only have to trust a previously issued cookie, but can now both verify that the right user is present (by means of a biometric) and that a particular private key is available on this particular device. Sometimes this promise is made based on key material stored in hardware (e.g. Titan security in Pixel Slate), which can be a strong indicator that the relying party is interacting with the right user on the right device.</div> <div> <br /></div> <div> <b>How use case #3 works: Built-in device authenticator</b></div> <br /> The challenge of verifying that a device a user has previously logged in on is still the device from which they’re interacting with the relying party, is what the built-in FIDO authenticator on most latest-generation Chromebooks is able to help solve. <br /> <br /> Earlier we noted that upon initial log-in, relying parties regularly place cookies or tokens on a user’s device, so they can remember that a user has previously authenticated. Under some circumstances, such as when there’s malware present on a device, it might be possible for these tokens to be exfiltrated. Asking for the “touch of a built-in authenticator” at regular intervals helps the relying party know that the user is still interacting from a legitimate device which has previously been issued a token. It also helps verify that the token has not been exfiltrated to a different device since FIDO authenticators offer increased protection against the exfiltration of the private key. This is because it’s usually housed in the hardware itself. For example, in the case of most latest-generation Chromebooks (e.g. Pixel Slate), it’s protected by hardware-based Titan security. <br /> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-n4uwhaIwLsQ/XdM1Bu9xjpI/AAAAAAAABK4/dSFPvoS1tjYY76NwX1iF8Joxn4X99adGACNcBGAsYHQ/s1600/pxel.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="216" data-original-width="512" height="168" src="https://1.bp.blogspot.com/-n4uwhaIwLsQ/XdM1Bu9xjpI/AAAAAAAABK4/dSFPvoS1tjYY76NwX1iF8Joxn4X99adGACNcBGAsYHQ/s400/pxel.png" width="400" /></a></div> <div style="text-align: center;"> <u>Pixel Slate devices are built with hardware-based Titan security </u></div> <div style="text-align: left;"> <br /></div> In the case of our implementation on Chrome OS, the FIDO keys are also scoped to the specific logged in user, meaning that every user on the device essentially gets their own FIDO authenticator that can’t be accessed across user boundaries. We expect this use case to be particularly useful in enterprise environments, which is why the feature is not enabled by default. Administrators can enable it in the Google Admin console.<br /> <div> <br /> We still highly recommend users to have a primary FIDO security key, such as <a href="https://cloud.google.com/titan-security-key/">Titan Security Key</a> or an <a href="https://support.google.com/accounts/answer/9289445?p=phone-security-key&visit_id=637049334778849540-46307047&rd=1">Android phone</a>. This should be used in conjunction with a “FIDO re-authentication” policy, <a href="https://gsuiteupdates.googleblog.com/2019/09/session-length-for-google-cloud-console-login.html">which is supported</a> by G Suite.</div> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-riusZXFtxV0/XdM6yN-8DKI/AAAAAAAABLg/kLY_LA2-NcEnO8bwzDtF6JjiWeG5tRnwgCNcBGAsYHQ/s1600/adminimage.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="684" data-original-width="1600" height="170" src="https://1.bp.blogspot.com/-riusZXFtxV0/XdM6yN-8DKI/AAAAAAAABLg/kLY_LA2-NcEnO8bwzDtF6JjiWeG5tRnwgCNcBGAsYHQ/s400/adminimage.png" width="400" /></a></div> <div style="text-align: center;"> <u>Enabling the built-in FIDO authenticator in the Google Admin console</u></div> <div style="text-align: center;"> <u><br /></u></div> Even though it’s technically possible to register the built-in FIDO authenticator on a Chrome OS device as a “security key” with services, it’s best to avoid this instance as users can run an increased risk of account lockout if they ever need to sign in to the service from a different machine.<br /> <div> <b><br /></b></div> <div> <b>Supported Chromebooks</b><br /> Starting with Chrome 76, most latest-generation Chromebooks gained the option to enable a built-in FIDO authenticator backed by hardware-based Titan security. To see if your Chromebook can be enabled with this capability, you can navigate to chrome://system and check the “tpm-version” entry. If “vendor” equals “43524f53”, then your Chromebook is backed by Titan security. <br /> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-UftIGFHOj78/XdM7YfLPUUI/AAAAAAAABLo/n_yxNBtbZXYWJZJmYcTPTSHeTfxtkY2QQCNcBGAsYHQ/s1600/tpm.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="133" data-original-width="1059" height="50" src="https://1.bp.blogspot.com/-UftIGFHOj78/XdM7YfLPUUI/AAAAAAAABLo/n_yxNBtbZXYWJZJmYcTPTSHeTfxtkY2QQCNcBGAsYHQ/s400/tpm.png" width="400" /></a></div> <div style="text-align: center;"> <u>Navigating to chrome://system on your Chromebook</u></div> </div> <div style="text-align: center;"> <br /></div> <b>Summary</b><br /> <div> <b><br /></b>In summary, we believe that this new enhancement can provide value to enterprise organizations that want to confirm that the device a user is connecting from is still the original device from which a user logged in from in the past. Most users, however, should be using roaming FIDO security keys, such as <a href="https://cloud.google.com/titan-security-key/">Titan Security Key</a>, their <a href="https://support.google.com/accounts/answer/9289445?p=phone-security-key&visit_id=637049334778849540-46307047&rd=1">Android phone</a>, or security keys from other vendors, in order to avoid account lockouts.</div> <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 Christiaan Brand, Product Manager, Google Cloud </span><br /> <span class="byline-author"><br /></span> <span class="byline-author"><br /></span> <span class="byline-author"><span id="docs-internal-guid-eeba40d9-7fff-3dd0-cbcf-d34e4c1c2ece"></span></span><br /> We previously <a href="https://cloud.google.com/blog/products/chrome-enterprise/admin-insider-whats-new-in-chrome-enterprise-release-76">announced</a> that starting with Chrome 76, most latest-generation Chromebooks gained the option to enable a built-in FIDO authenticator backed by hardware-based Titan security. For supported services (e.g. G Suite, Google Cloud Platform), enterprise administrators can now allow end users to use the power button on these devices to protect against certain classes of account takeover attempts. This feature is disabled by default, however, administrators can enable it by changing <a href="https://cloud.google.com/docs/chrome-enterprise/policies/?policy=DeviceSecondFactorAuthentication">DeviceSecondFactorAuthentication</a> policy in the Google Admin console. <br /> <div> <br /></div> Before we dive deeper into this capability, let’s first cover the main use cases FIDO technology solves, and then explore how this new enhancement can satisfy an advanced requirement that can help enterprise organizations.<br /> <div> <b><br /></b></div> <div> <b>Main use cases</b><br /> <a href="https://fidoalliance.org/how-fido-works/">FIDO technology</a> aims to solve three separate use cases for relying parties (or otherwise referred to as Internet services) by helping to: <br /> <ol> <li>Prevent phishing during initial login to a service on a new device;</li> <li>Reverify a user’s identity to a service on a device on which they’ve already logged in to; </li> <li>Confirm that the device a user is connecting from is still the original device where they logged in from previously. This is typically needed in the enterprise. </li> </ol> Security-savvy professionals may interpret the third use case as a special instance of use case #2. However, there are some differences, which we break down a bit further below: <br /> <ul> <li>In case #2, the problem that FIDO technology tries to solve is re-verifying a user’s identity by unlocking a private key stored on the device.</li> <li>In case #3, FIDO technology helps to determine whether a previously created key is still available on the original device without any proof of who the user is.</li> </ul> <b>How use case #1 works: Roaming security keys </b><br /> <div> <br /> Because the whole premise of this use case is one in which the user logs in on a brand new device they’ve never authenticated before, this requires the user to have a FIDO security key (removeable, cross-platform, or a roaming authenticator). By this definition, a built-in FIDO authenticator on Chrome OS devices would not be able to satisfy this requirement, because it would not be able to help verify the user’s identity without being set up previously. Upon initial log-in, the user’s identity is verified together with the presence of a security key (such as Google’s <a href="https://store.google.com/product/titan_security_key">Titan Security Key</a>) previously tied to their account. </div> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-0wdlTgo_8PU/XdMzT86MbYI/AAAAAAAABKs/-IIrM2d5giMGM7mV1UdkC01-e1y4fyvigCNcBGAsYHQ/s1600/titankeys.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="300" data-original-width="517" height="185" src="https://1.bp.blogspot.com/-0wdlTgo_8PU/XdMzT86MbYI/AAAAAAAABKs/-IIrM2d5giMGM7mV1UdkC01-e1y4fyvigCNcBGAsYHQ/s320/titankeys.png" width="320" /></a></div> <div class="separator" style="clear: both; text-align: center;"> <u>Titan Security Keys </u></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> Once the user is successfully logged in, trust is conferred from the security key to the device on which the user is logging on, usually by placing a cookie or other token on the device in order for the relying party to “remember” that the user already performed a second factor authenticator on this device. Once this step is completed, it is no longer necessary to require a physical second factor on this device because the presence of the cookie signals to the relying party that this device is to be trusted. <br /> <br /> Optionally, some services might require the user to still periodically verify that it’s the correct user in front of the already recognized device (for example, particularly sensitive and regulated services such as financial services companies). In almost all cases, it shouldn’t be necessary for the user to also-in addition to providing their knowledge factor (such as a password) - re-present their second factor when re-authenticating as they’ve already done that during initial bootstrapping.<br /> <br /> Note that on Chrome OS devices, your data is encrypted when you’re not logged on, <a href="https://services.google.com/fh/files/misc/google_enterprise_chrome_security_whitepaper.pdf">which further protects your data</a> against malicious access.</div> <div> <b><br /></b></div> <div> <b>How use case #2 works: Re-authentication </b></div> <br /> Frequently referred to as “re-authentication,” use case #2 allows a relying party to reverify that the same user is still interacting with the service from a previously verified device. This mainly happens when a user performs an action that’s particularly sensitive, such as changing their password or when interacting with regulated services, such as financial services companies. In this case, a built-in biometric authenticator (e.g. a fingerprint sensor or PIN on Android devices) can be registered, which offers users a more convenient way to re-verify their identity to the service in question. In fact, we have <a href="https://security.googleblog.com/2019/08/making-authentication-even-easier-with_12.html">recently enabled</a> this use case on Android devices for some Google services.<br /> <div> <br /> Additionally, there are security benefits to this particular solution, as the relying party doesn’t only have to trust a previously issued cookie, but can now both verify that the right user is present (by means of a biometric) and that a particular private key is available on this particular device. Sometimes this promise is made based on key material stored in hardware (e.g. Titan security in Pixel Slate), which can be a strong indicator that the relying party is interacting with the right user on the right device.</div> <div> <br /></div> <div> <b>How use case #3 works: Built-in device authenticator</b></div> <br /> The challenge of verifying that a device a user has previously logged in on is still the device from which they’re interacting with the relying party, is what the built-in FIDO authenticator on most latest-generation Chromebooks is able to help solve. <br /> <br /> Earlier we noted that upon initial log-in, relying parties regularly place cookies or tokens on a user’s device, so they can remember that a user has previously authenticated. Under some circumstances, such as when there’s malware present on a device, it might be possible for these tokens to be exfiltrated. Asking for the “touch of a built-in authenticator” at regular intervals helps the relying party know that the user is still interacting from a legitimate device which has previously been issued a token. It also helps verify that the token has not been exfiltrated to a different device since FIDO authenticators offer increased protection against the exfiltration of the private key. This is because it’s usually housed in the hardware itself. For example, in the case of most latest-generation Chromebooks (e.g. Pixel Slate), it’s protected by hardware-based Titan security. <br /> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-n4uwhaIwLsQ/XdM1Bu9xjpI/AAAAAAAABK4/dSFPvoS1tjYY76NwX1iF8Joxn4X99adGACNcBGAsYHQ/s1600/pxel.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="216" data-original-width="512" height="168" src="https://1.bp.blogspot.com/-n4uwhaIwLsQ/XdM1Bu9xjpI/AAAAAAAABK4/dSFPvoS1tjYY76NwX1iF8Joxn4X99adGACNcBGAsYHQ/s400/pxel.png" width="400" /></a></div> <div style="text-align: center;"> <u>Pixel Slate devices are built with hardware-based Titan security </u></div> <div style="text-align: left;"> <br /></div> In the case of our implementation on Chrome OS, the FIDO keys are also scoped to the specific logged in user, meaning that every user on the device essentially gets their own FIDO authenticator that can’t be accessed across user boundaries. We expect this use case to be particularly useful in enterprise environments, which is why the feature is not enabled by default. Administrators can enable it in the Google Admin console.<br /> <div> <br /> We still highly recommend users to have a primary FIDO security key, such as <a href="https://cloud.google.com/titan-security-key/">Titan Security Key</a> or an <a href="https://support.google.com/accounts/answer/9289445?p=phone-security-key&visit_id=637049334778849540-46307047&rd=1">Android phone</a>. This should be used in conjunction with a “FIDO re-authentication” policy, <a href="https://gsuiteupdates.googleblog.com/2019/09/session-length-for-google-cloud-console-login.html">which is supported</a> by G Suite.</div> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-riusZXFtxV0/XdM6yN-8DKI/AAAAAAAABLg/kLY_LA2-NcEnO8bwzDtF6JjiWeG5tRnwgCNcBGAsYHQ/s1600/adminimage.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="684" data-original-width="1600" height="170" src="https://1.bp.blogspot.com/-riusZXFtxV0/XdM6yN-8DKI/AAAAAAAABLg/kLY_LA2-NcEnO8bwzDtF6JjiWeG5tRnwgCNcBGAsYHQ/s400/adminimage.png" width="400" /></a></div> <div style="text-align: center;"> <u>Enabling the built-in FIDO authenticator in the Google Admin console</u></div> <div style="text-align: center;"> <u><br /></u></div> Even though it’s technically possible to register the built-in FIDO authenticator on a Chrome OS device as a “security key” with services, it’s best to avoid this instance as users can run an increased risk of account lockout if they ever need to sign in to the service from a different machine.<br /> <div> <b><br /></b></div> <div> <b>Supported Chromebooks</b><br /> Starting with Chrome 76, most latest-generation Chromebooks gained the option to enable a built-in FIDO authenticator backed by hardware-based Titan security. To see if your Chromebook can be enabled with this capability, you can navigate to chrome://system and check the “tpm-version” entry. If “vendor” equals “43524f53”, then your Chromebook is backed by Titan security. <br /> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-UftIGFHOj78/XdM7YfLPUUI/AAAAAAAABLo/n_yxNBtbZXYWJZJmYcTPTSHeTfxtkY2QQCNcBGAsYHQ/s1600/tpm.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="133" data-original-width="1059" height="50" src="https://1.bp.blogspot.com/-UftIGFHOj78/XdM7YfLPUUI/AAAAAAAABLo/n_yxNBtbZXYWJZJmYcTPTSHeTfxtkY2QQCNcBGAsYHQ/s400/tpm.png" width="400" /></a></div> <div style="text-align: center;"> <u>Navigating to chrome://system on your Chromebook</u></div> </div> <div style="text-align: center;"> <br /></div> <b>Summary</b><br /> <div> <b><br /></b>In summary, we believe that this new enhancement can provide value to enterprise organizations that want to confirm that the device a user is connecting from is still the original device from which a user logged in from in the past. Most users, however, should be using roaming FIDO security keys, such as <a href="https://cloud.google.com/titan-security-key/">Titan Security Key</a>, their <a href="https://support.google.com/accounts/answer/9289445?p=phone-security-key&visit_id=637049334778849540-46307047&rd=1">Android phone</a>, or security keys from other vendors, in order to avoid account lockouts.</div> <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:Using a built-in FIDO authenticator on latest-generation Chromebooks &url=https://security.googleblog.com/2019/11/using-built-in-fido-authenticator-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/2019/11/using-built-in-fido-authenticator-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/2019/11/using-built-in-fido-authenticator-on.html' data-url='https://security.googleblog.com/2019/11/using-built-in-fido-authenticator-on.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/11/using-built-in-fido-authenticator-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'> </div> </div> </div> <div class='post' data-id='1295070036973390554' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/11/gwp-asan-sampling-heap-memory-error.html' itemprop='url' title='GWP-ASan: Sampling heap memory error detection in-the-wild'> GWP-ASan: Sampling heap memory error detection in-the-wild </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> November 7, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Vlad Tsyrklevich, Dynamic Tools Team</span> <p> Memory safety errors, like use-after-frees and out-of-bounds reads/writes, are a leading source of vulnerabilities in C/C++ applications. Despite investments in preventing and detecting these errors in Chrome, over 60% of high severity vulnerabilities in Chrome are memory safety errors. Some memory safety errors don’t lead to security vulnerabilities but simply cause crashes and instability. </p> <p> Chrome uses state-of-the-art techniques to prevent these errors, including: </p> <ul> <li><a href="https://llvm.org/docs/LibFuzzer.html">Coverage-guided</a> <a href="https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer)">fuzzing</a> with <a href="https://clang.llvm.org/docs/AddressSanitizer.html">AddressSanitizer</a> (ASan) <li>Unit and integration testing with ASan <li>Defensive programming, like custom libraries to perform safe math or provide bounds checked containers <li>Mandatory code review </li> </ul> <p> Chrome also makes use of sandboxing and exploit mitigations to complicate exploitation of memory errors that go undetected by the methods above. </p> <p> AddressSanitizer is a compiler instrumentation that finds memory errors occurring on the heap, stack, or in globals. ASan is highly effective and one of the lowest overhead instrumentations available that detects the errors that it does; however, it still incurs an average 2-3x performance and memory overhead. This makes it suitable for use with unit tests or fuzzing, but not deployment to end users. Chrome used to deploy <a href="https://blog.chromium.org/2013/05/testing-chromium-syzyasan-lightweight.html">SyzyASAN instrumented binaries</a> to detect memory errors. SyzyASAN had a similar overhead so it was only deployed to a small subset of users on the canary channel. It was discontinued after the Windows toolchain switched to LLVM. </p> <p> GWP-ASan, also known by its recursive backronym, GWP-ASan Will Provide Allocation Sanity, is a sampling allocation tool designed to detect heap memory errors occurring in production with negligible overhead. Because of its negligible overhead we can deploy GWP-ASan to the entire Chrome user base to find memory errors happening in the real world that are not caught by fuzzing or testing with ASan. Unlike ASan, GWP-ASan can not find memory errors on the stack or in globals. </p> <p> GWP-ASan is currently enabled for all Windows and macOS users for allocations made using malloc() and PartitionAlloc. It is only enabled for a small fraction of allocations and processes to reduce performance and memory overhead to a negligible amount. At the time of writing it has found <a href="https://bugs.chromium.org/p/chromium/issues/list?q=Hotlist%3DGWP-ASan&can=1">over sixty bugs</a> (many are still restricted view). About 90% of the issues GWP-ASan has found are use-after-frees. The remaining are out-of-bounds reads and writes. </p> <p> To learn more, check out our full write up on GWP-ASan <a href="https://www.chromium.org/Home/chromium-security/articles/gwp-asan">here</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 Vlad Tsyrklevich, Dynamic Tools Team</span> <p> Memory safety errors, like use-after-frees and out-of-bounds reads/writes, are a leading source of vulnerabilities in C/C++ applications. Despite investments in preventing and detecting these errors in Chrome, over 60% of high severity vulnerabilities in Chrome are memory safety errors. Some memory safety errors don’t lead to security vulnerabilities but simply cause crashes and instability. </p> <p> Chrome uses state-of-the-art techniques to prevent these errors, including: </p> <ul> <li><a href="https://llvm.org/docs/LibFuzzer.html">Coverage-guided</a> <a href="https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer)">fuzzing</a> with <a href="https://clang.llvm.org/docs/AddressSanitizer.html">AddressSanitizer</a> (ASan) <li>Unit and integration testing with ASan <li>Defensive programming, like custom libraries to perform safe math or provide bounds checked containers <li>Mandatory code review </li> </ul> <p> Chrome also makes use of sandboxing and exploit mitigations to complicate exploitation of memory errors that go undetected by the methods above. </p> <p> AddressSanitizer is a compiler instrumentation that finds memory errors occurring on the heap, stack, or in globals. ASan is highly effective and one of the lowest overhead instrumentations available that detects the errors that it does; however, it still incurs an average 2-3x performance and memory overhead. This makes it suitable for use with unit tests or fuzzing, but not deployment to end users. Chrome used to deploy <a href="https://blog.chromium.org/2013/05/testing-chromium-syzyasan-lightweight.html">SyzyASAN instrumented binaries</a> to detect memory errors. SyzyASAN had a similar overhead so it was only deployed to a small subset of users on the canary channel. It was discontinued after the Windows toolchain switched to LLVM. </p> <p> GWP-ASan, also known by its recursive backronym, GWP-ASan Will Provide Allocation Sanity, is a sampling allocation tool designed to detect heap memory errors occurring in production with negligible overhead. Because of its negligible overhead we can deploy GWP-ASan to the entire Chrome user base to find memory errors happening in the real world that are not caught by fuzzing or testing with ASan. Unlike ASan, GWP-ASan can not find memory errors on the stack or in globals. </p> <p> GWP-ASan is currently enabled for all Windows and macOS users for allocations made using malloc() and PartitionAlloc. It is only enabled for a small fraction of allocations and processes to reduce performance and memory overhead to a negligible amount. At the time of writing it has found <a href="https://bugs.chromium.org/p/chromium/issues/list?q=Hotlist%3DGWP-ASan&can=1">over sixty bugs</a> (many are still restricted view). About 90% of the issues GWP-ASan has found are use-after-frees. The remaining are out-of-bounds reads and writes. </p> <p> To learn more, check out our full write up on GWP-ASan <a href="https://www.chromium.org/Home/chromium-security/articles/gwp-asan">here</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:GWP-ASan: Sampling heap memory error detection in-the-wild&url=https://security.googleblog.com/2019/11/gwp-asan-sampling-heap-memory-error.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/2019/11/gwp-asan-sampling-heap-memory-error.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/2019/11/gwp-asan-sampling-heap-memory-error.html' data-url='https://security.googleblog.com/2019/11/gwp-asan-sampling-heap-memory-error.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/11/gwp-asan-sampling-heap-memory-error.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='5835631147739683084' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/11/the-app-defense-alliance-bringing.html' itemprop='url' title='The App Defense Alliance: Bringing the security industry together to fight bad apps'> The App Defense Alliance: Bringing the security industry together to fight bad apps </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> November 6, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqXeN8zAukBVvRj0ezc0tgBdx5-_QXqTPO0f6d1pKtsuk7JXbYpjqicLZHxxqDy0gpp-hZzBlCP6GQyGKpzUwkgUB_UBz5WsDBQwx5qvg-Xx0IpHKSCd6p75DnpZl0i-FkCkguQN8eDwz0/s1600/adaHeroSpinAnimation.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="557" data-original-width="666" height="268" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqXeN8zAukBVvRj0ezc0tgBdx5-_QXqTPO0f6d1pKtsuk7JXbYpjqicLZHxxqDy0gpp-hZzBlCP6GQyGKpzUwkgUB_UBz5WsDBQwx5qvg-Xx0IpHKSCd6p75DnpZl0i-FkCkguQN8eDwz0/s320/adaHeroSpinAnimation.gif" width="320" /></a></div> <span class="byline-author">Posted by Dave Kleidermacher, VP, Android Security & Privacy </span><br /> Fighting against bad actors in the ecosystem is a top priority for Google, but we know there are others doing great work to find and protect against attacks. Our research partners in the mobile security world have built successful teams and technology, helping us in the fight. Today, we’re excited to take this collaboration to the next level, announcing a partnership between Google, <a href="https://www.eset.com/us/">ESET</a>, <a href="https://www.lookout.com/">Lookout</a>, and <a href="https://www.zimperium.com/">Zimperium</a>. It’s called the App Defense Alliance and together, we’re working to stop bad apps before they reach users’ devices. <br /> The Android ecosystem is thriving with over 2.5 billion devices, but this popularity also makes it an attractive target for abuse. This is true of all global platforms: where there is software with worldwide proliferation, there are bad actors trying to attack it for their gain. Working closely with our industry partners gives us an opportunity to collaborate with some truly talented researchers in our field and the detection engines they’ve built. This is all with the goal of, together, reducing the risk of app-based malware, identifying new threats, and protecting our users. <br /> <strong>What will the App Defense Alliance do?</strong> <br /> Our number one goal as partners is to ensure the safety of the Google Play Store, quickly finding potentially harmful applications and stopping them from being published <br /> As part of this Alliance, we are integrating our Google Play Protect detection systems with each partner’s scanning engines. This will generate new app risk intelligence as apps are being queued to publish. Partners will analyze that dataset and act as another, vital set of eyes prior to an app going live on the Play Store. <br /> <strong>Who are the partners?</strong> <br /> All of our partners work in the world of endpoint protection, and offer specific products to protect mobile devices and the mobile ecosystem. Like Google Play Protect, our partners’ technologies use a combination of machine learning and static/dynamic analysis to detect abusive behavior. Multiple heuristic engines working in concert will increase our efficiency in identifying potentially harmful apps. <br /> We hand-picked these partners based on their successes in finding potential threats and their dedication to improving the ecosystem. These partners are regularly recognized in analyst reports for their work. <br /> <strong>Industry collaboration is key</strong> <br /> Knowledge sharing and industry collaboration are important aspects in securing the world from attacks. We believe working together is the ultimate way we will get ahead of bad actors. We’re excited to work with these partners to arm the Google Play Store against bad apps. <br /> Want to learn more about the App Defense Alliance’s work? Visit us <a href="https://developers.google.com/android/play-protect/app-defense-alliance">here</a>. <span itemprop='author' itemscope='itemscope' itemtype='http://schema.org/Person'> <meta content='https://plus.google.com/116899029375914044550' itemprop='url'/> </span> </script> <noscript> <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqXeN8zAukBVvRj0ezc0tgBdx5-_QXqTPO0f6d1pKtsuk7JXbYpjqicLZHxxqDy0gpp-hZzBlCP6GQyGKpzUwkgUB_UBz5WsDBQwx5qvg-Xx0IpHKSCd6p75DnpZl0i-FkCkguQN8eDwz0/s1600/adaHeroSpinAnimation.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="557" data-original-width="666" height="268" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqXeN8zAukBVvRj0ezc0tgBdx5-_QXqTPO0f6d1pKtsuk7JXbYpjqicLZHxxqDy0gpp-hZzBlCP6GQyGKpzUwkgUB_UBz5WsDBQwx5qvg-Xx0IpHKSCd6p75DnpZl0i-FkCkguQN8eDwz0/s320/adaHeroSpinAnimation.gif" width="320" /></a></div> <span class="byline-author">Posted by Dave Kleidermacher, VP, Android Security & Privacy </span><br /> Fighting against bad actors in the ecosystem is a top priority for Google, but we know there are others doing great work to find and protect against attacks. Our research partners in the mobile security world have built successful teams and technology, helping us in the fight. Today, we’re excited to take this collaboration to the next level, announcing a partnership between Google, <a href="https://www.eset.com/us/">ESET</a>, <a href="https://www.lookout.com/">Lookout</a>, and <a href="https://www.zimperium.com/">Zimperium</a>. It’s called the App Defense Alliance and together, we’re working to stop bad apps before they reach users’ devices. <br /> The Android ecosystem is thriving with over 2.5 billion devices, but this popularity also makes it an attractive target for abuse. This is true of all global platforms: where there is software with worldwide proliferation, there are bad actors trying to attack it for their gain. Working closely with our industry partners gives us an opportunity to collaborate with some truly talented researchers in our field and the detection engines they’ve built. This is all with the goal of, together, reducing the risk of app-based malware, identifying new threats, and protecting our users. <br /> <strong>What will the App Defense Alliance do?</strong> <br /> Our number one goal as partners is to ensure the safety of the Google Play Store, quickly finding potentially harmful applications and stopping them from being published <br /> As part of this Alliance, we are integrating our Google Play Protect detection systems with each partner’s scanning engines. This will generate new app risk intelligence as apps are being queued to publish. Partners will analyze that dataset and act as another, vital set of eyes prior to an app going live on the Play Store. <br /> <strong>Who are the partners?</strong> <br /> All of our partners work in the world of endpoint protection, and offer specific products to protect mobile devices and the mobile ecosystem. Like Google Play Protect, our partners’ technologies use a combination of machine learning and static/dynamic analysis to detect abusive behavior. Multiple heuristic engines working in concert will increase our efficiency in identifying potentially harmful apps. <br /> We hand-picked these partners based on their successes in finding potential threats and their dedication to improving the ecosystem. These partners are regularly recognized in analyst reports for their work. <br /> <strong>Industry collaboration is key</strong> <br /> Knowledge sharing and industry collaboration are important aspects in securing the world from attacks. We believe working together is the ultimate way we will get ahead of bad actors. We’re excited to work with these partners to arm the Google Play Store against bad apps. <br /> Want to learn more about the App Defense Alliance’s work? Visit us <a href="https://developers.google.com/android/play-protect/app-defense-alliance">here</a>. <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:The App Defense Alliance: Bringing the security industry together to fight bad apps&url=https://security.googleblog.com/2019/11/the-app-defense-alliance-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/2019/11/the-app-defense-alliance-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/2019/11/the-app-defense-alliance-bringing.html' data-url='https://security.googleblog.com/2019/11/the-app-defense-alliance-bringing.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/11/the-app-defense-alliance-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/android%20security' rel='tag'> android security </a> </span> </div> </div> </div> <div class='post' data-id='5348389075537923625' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/11/opentitan-open-sourcing-transparent.html' itemprop='url' title='OpenTitan - open sourcing transparent, trustworthy, and secure silicon'> OpenTitan - open sourcing transparent, trustworthy, and secure silicon </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> November 5, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Royal Hansen, Vice President, Google and Dominic Rizzo, OpenTitan Lead, Google Cloud </span><br /> <span class="byline-author"><br /></span> Security begins with secure infrastructure. To have higher confidence in the security and integrity of the infrastructure, we need to anchor our trust at the foundation - in a special-purpose chip.<br /> <div> <br /></div> <span style="font-family: inherit;">Today, along with our partners, we are excited to announce <a href="http://www.opentitan.org/">OpenTitan</a> - the first open source silicon root of trust (RoT) project. OpenTitan will deliver a high-quality RoT design and integration guidelines for use in data center servers, storage, peripherals, and more. Open sourcing the silicon design makes it more transparent, trustworthy, and ultimately, secure.</span><br /> <div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-n2qQdpSpUuc/Xb965lxHFAI/AAAAAAAABEc/aVj757izoYMQtLdHOGS4yCUaJXtI7chNQCNcBGAsYHQ/s1600/OT.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="283" data-original-width="1155" height="97" src="https://1.bp.blogspot.com/-n2qQdpSpUuc/Xb965lxHFAI/AAAAAAAABEc/aVj757izoYMQtLdHOGS4yCUaJXtI7chNQCNcBGAsYHQ/s400/OT.png" width="400" /></a></div> <span style="font-family: inherit;"><br /></span></div> <div style="text-align: center;"> <h4> The OpenTitan logo</h4> </div> <span style="font-family: inherit;"><br /></span> <br /> <h3> <span style="font-family: inherit;"><b>Anchoring trust in silicon</b></span></h3> <span style="font-family: inherit;">Silicon RoT can help ensure that the hardware infrastructure and the software that runs on it remain in their intended, trustworthy state by verifying that the critical system components boot securely using authorized and verifiable code. Silicon RoT can provide many security benefits by helping to:</span><br /> <ul><span style="font-family: inherit;"> <li><span style="font-family: inherit;">Ensure that a server or a device boots with the correct firmware and hasn't been infected by a low-level malware.</span></li> <li><span style="font-family: inherit;">Provide a cryptographically unique machine identity, so an operator can verify that a server or a device is legitimate.</span></li> <li><span style="font-family: inherit;">Protect secrets like encryption keys in a tamper-resistant way even for people with physical access (e.g., while a server or a device is being shipped).</span></li> <li><span style="font-family: inherit;">Provide authoritative, tamper-evident audit records and other runtime security services.</span></li> </span></ul> <span style="font-family: inherit;"> </span>The silicon RoT technology can be used in server motherboards, network cards, client devices (e.g., laptops, phones), consumer routers, IoT devices, and more. For example, Google has relied on a custom-made RoT chip, <a href="https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext">Titan</a>, to help ensure that machines in Google’s data centers boot from a known trustworthy state with verified code; it is our system root of trust. Recognizing the importance of anchoring the trust in silicon, together with our partners we want to spread the benefits of reliable silicon RoT chips to our customers and the rest of the industry. We believe that the best way to accomplish that is through open source silicon.<br /> <div> <br /> <h3> <b>Raising the transparency and security bar</b></h3> <div> <div> Similar to open source software, open source silicon can:</div> <div> <ol> <li>Enhance trust and security through design and implementation transparency. Issues can be discovered early, and the need for blind trust is reduced.</li> <li>Enable and encourage innovation through contributions to the open source design.</li> <li>Provide implementation choice and preserve a set of common interfaces and software compatibility guarantees through a common, open reference design.</li> </ol> The OpenTitan project is managed by the <a href="https://www.lowrisc.org/">lowRISC CIC</a>, an independent not-for-profit company with a full-stack engineering team based in Cambridge, UK, and is supported by a coalition of like-minded partners, including <a href="https://ethz.ch/">ETH Zurich</a>, <a href="https://www.gi-de.com/">G+D Mobile Security</a>, <a href="https://opensource.google/">Google</a>, <a href="http://www.nuvoton.com/hq/about-nuvoton/news/products-technology/Nuvoton-Technology-announces-its-collaboration-on-OpenTitan-the-first-open-source-silicon-root-of-trust-RoT-project/?__locale=en">Nuvoton Technology</a>, and <a href="https://www.westerndigital.com/company/newsroom/press-releases/2019/2019-11-05-western-digital-collaborates-with-lowrisc-and-google-to-increase-security-transparency-in-data-centric-platforms">Western Digital</a>.</div> </div> </div> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-ggGxGBSS-K8/Xb976JloWjI/AAAAAAAABEo/c57FeeqkGgItyXfst31gUZewNu2SwURjQCNcBGAsYHQ/s1600/logos.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="400" data-original-width="1600" height="160" src="https://1.bp.blogspot.com/-ggGxGBSS-K8/Xb976JloWjI/AAAAAAAABEo/c57FeeqkGgItyXfst31gUZewNu2SwURjQCNcBGAsYHQ/s640/logos.png" width="640" /></a></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> <div> <h4 style="text-align: center;"> The founding partners of the OpenTitan project</h4> <br /> <div style="text-align: left;"> <span id="docs-internal-guid-6e0ddcce-7fff-8eb9-94ad-150f008c74fc"></span></div> OpenTitan is an active engineering project staffed by a team of engineers representing a coalition of partners who bring ideas and expertise from many perspectives. We are transparently building the logical design of a silicon RoT, including an open source microprocessor (the <a href="https://github.com/lowRISC/ibex/">lowRISC Ibex</a>, a RISC-V-based design), cryptographic coprocessors, a hardware random number generator, a sophisticated key hierarchy, memory hierarchies for volatile and non-volatile storage, defensive mechanisms, IO peripherals, secure boot, and more. With OpenTitan, a coalition of partners have come together to deliver a more open, transparent, and high-quality RoT.</div> <div> <br /></div> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> </div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-34AYhG8_1Ns/XcJ2C5FCt7I/AAAAAAAABG4/sUviv8OW17QWPQWGgcdmMvwwcPrS5weZgCNcBGAsYHQ/s1600/TraditionalvsOpenTitan%2B%25281%2529.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1426" data-original-width="1090" height="400" src="https://1.bp.blogspot.com/-34AYhG8_1Ns/XcJ2C5FCt7I/AAAAAAAABG4/sUviv8OW17QWPQWGgcdmMvwwcPrS5weZgCNcBGAsYHQ/s400/TraditionalvsOpenTitan%2B%25281%2529.jpg" width="305" /></a></div> <br /> <h4 style="text-align: center;"> A comparison of the major design components of a traditional RoT and an OpenTitan RoT</h4> <div> <br /> <br /> The OpenTitan project is rooted in three key principles:<br /> <ul> <li>Transparency - anyone can inspect, evaluate, and contribute to OpenTitan’s design and documentation to help build more transparent, trustworthy silicon RoT for all.</li> <li>High quality - we are building a high-quality logically-secure silicon design, including reference firmware, verification collateral, and technical documentation.</li> <li>Flexibility - adopters can reduce costs and reach more customers by using a vendor- and platform-agnostic silicon RoT design that can be integrated into data center servers, storage, peripheral and other devices. </li> </ul> <h3> <b>Participating in the OpenTitan project</b></h3> OpenTitan will be helpful for chip manufacturers, platform providers, and security-conscious enterprise organizations that want to enhance their infrastructure with silicon-based security. Visit our <a href="https://github.com/lowRISC/opentitan">GitHub repository</a> today.<br /> <br /> If you are interested in actively collaborating on OpenTitan to help make secure open source silicon a reality, we encourage you to <a href="mailto:get-involved@opentitan.org">contact</a> the OpenTitan team. If you would like your product to be considered for a pilot OpenTitan RoT integration, the team would be excited to <a href="mailto:pilots@opentitan.org">hear</a> from you.</div> <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 Royal Hansen, Vice President, Google and Dominic Rizzo, OpenTitan Lead, Google Cloud </span><br /> <span class="byline-author"><br /></span> Security begins with secure infrastructure. To have higher confidence in the security and integrity of the infrastructure, we need to anchor our trust at the foundation - in a special-purpose chip.<br /> <div> <br /></div> <span style="font-family: inherit;">Today, along with our partners, we are excited to announce <a href="http://www.opentitan.org/">OpenTitan</a> - the first open source silicon root of trust (RoT) project. OpenTitan will deliver a high-quality RoT design and integration guidelines for use in data center servers, storage, peripherals, and more. Open sourcing the silicon design makes it more transparent, trustworthy, and ultimately, secure.</span><br /> <div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-n2qQdpSpUuc/Xb965lxHFAI/AAAAAAAABEc/aVj757izoYMQtLdHOGS4yCUaJXtI7chNQCNcBGAsYHQ/s1600/OT.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="283" data-original-width="1155" height="97" src="https://1.bp.blogspot.com/-n2qQdpSpUuc/Xb965lxHFAI/AAAAAAAABEc/aVj757izoYMQtLdHOGS4yCUaJXtI7chNQCNcBGAsYHQ/s400/OT.png" width="400" /></a></div> <span style="font-family: inherit;"><br /></span></div> <div style="text-align: center;"> <h4> The OpenTitan logo</h4> </div> <span style="font-family: inherit;"><br /></span> <br /> <h3> <span style="font-family: inherit;"><b>Anchoring trust in silicon</b></span></h3> <span style="font-family: inherit;">Silicon RoT can help ensure that the hardware infrastructure and the software that runs on it remain in their intended, trustworthy state by verifying that the critical system components boot securely using authorized and verifiable code. Silicon RoT can provide many security benefits by helping to:</span><br /> <ul><span style="font-family: inherit;"> <li><span style="font-family: inherit;">Ensure that a server or a device boots with the correct firmware and hasn't been infected by a low-level malware.</span></li> <li><span style="font-family: inherit;">Provide a cryptographically unique machine identity, so an operator can verify that a server or a device is legitimate.</span></li> <li><span style="font-family: inherit;">Protect secrets like encryption keys in a tamper-resistant way even for people with physical access (e.g., while a server or a device is being shipped).</span></li> <li><span style="font-family: inherit;">Provide authoritative, tamper-evident audit records and other runtime security services.</span></li> </span></ul> <span style="font-family: inherit;"> </span>The silicon RoT technology can be used in server motherboards, network cards, client devices (e.g., laptops, phones), consumer routers, IoT devices, and more. For example, Google has relied on a custom-made RoT chip, <a href="https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext">Titan</a>, to help ensure that machines in Google’s data centers boot from a known trustworthy state with verified code; it is our system root of trust. Recognizing the importance of anchoring the trust in silicon, together with our partners we want to spread the benefits of reliable silicon RoT chips to our customers and the rest of the industry. We believe that the best way to accomplish that is through open source silicon.<br /> <div> <br /> <h3> <b>Raising the transparency and security bar</b></h3> <div> <div> Similar to open source software, open source silicon can:</div> <div> <ol> <li>Enhance trust and security through design and implementation transparency. Issues can be discovered early, and the need for blind trust is reduced.</li> <li>Enable and encourage innovation through contributions to the open source design.</li> <li>Provide implementation choice and preserve a set of common interfaces and software compatibility guarantees through a common, open reference design.</li> </ol> The OpenTitan project is managed by the <a href="https://www.lowrisc.org/">lowRISC CIC</a>, an independent not-for-profit company with a full-stack engineering team based in Cambridge, UK, and is supported by a coalition of like-minded partners, including <a href="https://ethz.ch/">ETH Zurich</a>, <a href="https://www.gi-de.com/">G+D Mobile Security</a>, <a href="https://opensource.google/">Google</a>, <a href="http://www.nuvoton.com/hq/about-nuvoton/news/products-technology/Nuvoton-Technology-announces-its-collaboration-on-OpenTitan-the-first-open-source-silicon-root-of-trust-RoT-project/?__locale=en">Nuvoton Technology</a>, and <a href="https://www.westerndigital.com/company/newsroom/press-releases/2019/2019-11-05-western-digital-collaborates-with-lowrisc-and-google-to-increase-security-transparency-in-data-centric-platforms">Western Digital</a>.</div> </div> </div> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-ggGxGBSS-K8/Xb976JloWjI/AAAAAAAABEo/c57FeeqkGgItyXfst31gUZewNu2SwURjQCNcBGAsYHQ/s1600/logos.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="400" data-original-width="1600" height="160" src="https://1.bp.blogspot.com/-ggGxGBSS-K8/Xb976JloWjI/AAAAAAAABEo/c57FeeqkGgItyXfst31gUZewNu2SwURjQCNcBGAsYHQ/s640/logos.png" width="640" /></a></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> <div> <h4 style="text-align: center;"> The founding partners of the OpenTitan project</h4> <br /> <div style="text-align: left;"> <span id="docs-internal-guid-6e0ddcce-7fff-8eb9-94ad-150f008c74fc"></span></div> OpenTitan is an active engineering project staffed by a team of engineers representing a coalition of partners who bring ideas and expertise from many perspectives. We are transparently building the logical design of a silicon RoT, including an open source microprocessor (the <a href="https://github.com/lowRISC/ibex/">lowRISC Ibex</a>, a RISC-V-based design), cryptographic coprocessors, a hardware random number generator, a sophisticated key hierarchy, memory hierarchies for volatile and non-volatile storage, defensive mechanisms, IO peripherals, secure boot, and more. With OpenTitan, a coalition of partners have come together to deliver a more open, transparent, and high-quality RoT.</div> <div> <br /></div> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> </div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-34AYhG8_1Ns/XcJ2C5FCt7I/AAAAAAAABG4/sUviv8OW17QWPQWGgcdmMvwwcPrS5weZgCNcBGAsYHQ/s1600/TraditionalvsOpenTitan%2B%25281%2529.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1426" data-original-width="1090" height="400" src="https://1.bp.blogspot.com/-34AYhG8_1Ns/XcJ2C5FCt7I/AAAAAAAABG4/sUviv8OW17QWPQWGgcdmMvwwcPrS5weZgCNcBGAsYHQ/s400/TraditionalvsOpenTitan%2B%25281%2529.jpg" width="305" /></a></div> <br /> <h4 style="text-align: center;"> A comparison of the major design components of a traditional RoT and an OpenTitan RoT</h4> <div> <br /> <br /> The OpenTitan project is rooted in three key principles:<br /> <ul> <li>Transparency - anyone can inspect, evaluate, and contribute to OpenTitan’s design and documentation to help build more transparent, trustworthy silicon RoT for all.</li> <li>High quality - we are building a high-quality logically-secure silicon design, including reference firmware, verification collateral, and technical documentation.</li> <li>Flexibility - adopters can reduce costs and reach more customers by using a vendor- and platform-agnostic silicon RoT design that can be integrated into data center servers, storage, peripheral and other devices. </li> </ul> <h3> <b>Participating in the OpenTitan project</b></h3> OpenTitan will be helpful for chip manufacturers, platform providers, and security-conscious enterprise organizations that want to enhance their infrastructure with silicon-based security. Visit our <a href="https://github.com/lowRISC/opentitan">GitHub repository</a> today.<br /> <br /> If you are interested in actively collaborating on OpenTitan to help make secure open source silicon a reality, we encourage you to <a href="mailto:get-involved@opentitan.org">contact</a> the OpenTitan team. If you would like your product to be considered for a pilot OpenTitan RoT integration, the team would be excited to <a href="mailto:pilots@opentitan.org">hear</a> from you.</div> <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:OpenTitan - open sourcing transparent, trustworthy, and secure silicon&url=https://security.googleblog.com/2019/11/opentitan-open-sourcing-transparent.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/2019/11/opentitan-open-sourcing-transparent.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/2019/11/opentitan-open-sourcing-transparent.html' data-url='https://security.googleblog.com/2019/11/opentitan-open-sourcing-transparent.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/11/opentitan-open-sourcing-transparent.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='1907702278354377339' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/10/how-google-adopted-beyondcorp-part-4.html' itemprop='url' title='How Google adopted BeyondCorp: Part 4 (services)'> How Google adopted BeyondCorp: Part 4 (services) </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> October 31, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Guilherme Gonçalves, Site Reliability Engineer and Kyle O'Malley, Security Engineer </span><br /> <span class="byline-author"><br /></span> <br /> <b><span style="font-size: large;">Intro</span></b><br /> This is the final post in a series of four, in which we set out to revisit various <a href="https://cloud.google.com/beyondcorp/">BeyondCorp</a> topics and share lessons that were learnt along the internal implementation path at Google.<br /> <br /> The <a href="https://security.googleblog.com/2019/06/how-google-adopted-beyondcorp.html">first post</a> in this series focused on providing necessary context for how Google adopted BeyondCorp, Google’s implementation of the zero trust security model. The <a href="https://security.googleblog.com/2019/08/how-google-adopted-beyondcorp-part-2.html">second post</a> focused on managing devices - how we decide whether or not a device should be trusted and why that distinction is necessary. The <a href="https://security.googleblog.com/2019/09/how-google-adopted-beyondcorp-part-3.html">third post</a> focused on tiered access - how to define access tiers and rules and how to simplify troubleshooting when things go wrong.<br /> <br /> This post introduces the concept of gated services, how to identify and, subsequently, migrate them and the associated lessons we learned along the way.<br /> <span class="byline-author"><br /></span> <br /> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-Uu_kkCOrkCY/Xbn_KJ05U6I/AAAAAAAABDA/xmCo3WYBCD4slf8zT_AZyLOy13JIm2pmQCNcBGAsYHQ/s1600/beyond1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="507" data-original-width="1260" height="128" src="https://1.bp.blogspot.com/-Uu_kkCOrkCY/Xbn_KJ05U6I/AAAAAAAABDA/xmCo3WYBCD4slf8zT_AZyLOy13JIm2pmQCNcBGAsYHQ/s320/beyond1.png" width="320" /></a></div> <div style="text-align: center;"> <span class="byline-author"><span id="docs-internal-guid-3b1f47ca-7fff-dd1f-3434-d9af14a1528d"></span></span></div> <div style="text-align: center;"> High level architecture for BeyondCorp</div> <br /> <b><span style="font-size: large;">Identifying and gating services</span></b><br /> <div> <b><br />How do you identify and categorize all the services that should be gated?</b><br /> Google began as a web-based company, and as it matured in the modern era, most internal business applications were developed with a web-first approach. These applications were hosted on similar internal architecture as our external services, with the exception that they could only be accessed on corporate office networks. Thus, identifying services to be gated by BeyondCorp was made easier for us due to the fact that most internal services were already properly inventoried and hosted via standard, central solutions. Migration, in many cases, was as simple as a DNS change. Solid IT asset inventory systems and maintenance are critical to migrating to a zero trust security model.<br /> <br /> Enforcement of zero trust access policies began with services which we determined would not be meaningfully impacted by the change in access requirements. For most services, requirements could be gathered via typical access log analysis or consulting with service owners. Services which could not be readily gated by default ACL requirements required service owners to develop strict access groups and/or eliminate risky workflows before they could be migrated.</div> <div> <br /></div> <b>How do you know which trust tier is needed for every service?</b><br /> As discussed in our <a href="https://security.googleblog.com/2019/09/how-google-adopted-beyondcorp-part-3.html">previous blog post</a>, Google makes internal services available based on device trust tiers. Today, those services are accessible by the highest trust tier by default. <br /> <br /> When the intent of the change is to restrict access to a service to a specific group or team, service owners are free to propose access changes to add or remove restrictions to their service. Access changes which are deemed to be sufficiently low risk can be automatically approved. In all other cases, such as where the owning team wants to expose a service to a risky device tier, they must work with security engineers to follow the <a href="http://en.wikipedia.org/wiki/Principle_of_least_privilege">principle of least privilege</a> and devise solutions.<br /> <div> <br /> <b>What do you do with services that are incompatible with BeyondCorp ideals?</b><br /> <br /> It may not always be possible to gate an application by the preferred zero trust solution. Services that cannot be easily gated typically fall into these categories:<br /> <ul> <li>Type 1: "Non-proxyable protocols", e.g. non-HTTP/HTTPS traffic.</li> <li>Type 2: Low latency requirements or localized high throughput traffic.</li> <li>Type 3: Administrative and emergency access networks.</li> </ul> The typical first step in finding a solution for these cases is finding a way to remove the need for that service altogether. In many cases, this was made possible by deprecating or replacing systems which could not be made compatible with the BeyondCorp implementation.<br /> <br /> When that was not an option, we found that no single solution would work for all critical requirements: <br /> <ul> <li>Solutions for the "Type 1" traffic have generally involved maintaining a specialized client tunneling which strongly enforces authentication and authorization decisions on the client and the server end of the connection. This is usually client/server type traffic which is similar to HTTP traffic in that connectivity is typically multi-point to point.</li> <li>Solutions to the "Type 2" problems generally rely on moving BeyondCorp-compatible compute resources locally or developing a solution tightly integrated with network access equipment to selectively forward "local" traffic without permanently opening network holes.</li> <li>As for “Type 3,” it would be ideal to completely eliminate all privileged internal networks. However, the reality is that some privileged networking will likely always be required to maintain the network itself and also to provide emergency access during outages.</li> </ul> It should be noted that server-to-server traffic in secure production data center environments does not necessarily rely on BeyondCorp, although many systems are integrated regardless, due to the Service-Oriented Design benefits that BeyondCorp inherently provides. </div> <div> <br /> <b>How do you prioritize gating?</b><br /> <br /> Prioritization starts by identifying all the services that are currently accessible via internal IP-access alone and migrating the most critical services to BeyondCorp, while working to slowly ratchet down permissions via exception management processes. Criticality of the service may also depend on the number and type of users, sensitivity of data handled, security and privacy risks enabled by the service.</div> <div> <br /> <b>Migration logistics</b><br /> <br /> Most services required integration testing with the BeyondCorp proxy. Service teams were encouraged to stand up "test" services which were used to test functionality behind the BeyondCorp proxy. Most services that performed their own access control enforcement were reconfigured to instead rely on BeyondCorp for all user/group authentication and authorization. Service teams have been encouraged to develop their own "fine-grained" discretionary access controls in the services by leveraging session data provided by the BeyondCorp proxy.</div> <div> <br /></div> <span style="font-size: large;"><b>Lessons learnt</b></span><br /> <div> <span style="font-size: large;"><br /></span><b>Allow coarse gating and exceptions</b><br /> <br /> Inventory: It's easy to overlook the importance of keeping a good inventory of services, devices, owners and security exceptions. The journey to a BeyondCorp world should start by solving organizational challenges when managing and maintaining data quality in inventory systems. In short, knowing how a service works, who should access it, and what makes that acceptable are the central tenets of managing BeyondCorp. Fine-grained access control is severely complicated when this insight is missing.<br /> <br /> Legacy protocols: Most large enterprises will inevitably need to support workflows and protocols which cannot be migrated to a BeyondCorp world (in any reasonable amount of time). Exception management and service inventory become crucial at this stage while stakeholders develop solutions.</div> <div> <b>Run highly reliable systems</b><br /> The BeyondCorp initiative would not be sustainable at Google’s scale without the involvement of various Site Reliability Engineering (SRE) teams across the inventory systems, BeyondCorp infrastructure and client side solutions. The ability to successfully achieve wide-spread adoption of changes this large can be hampered by perceived (or in some cases, actual) reliability issues. Understanding the user workflows that might be impacted, working with key stakeholders and ensuring the transition is smooth and trouble-free for all users helps protect against backlash and avoids users finding undesirable workarounds. By applying our <a href="https://landing.google.com/sre/sre-book/toc/index.html">reliability engineering practices</a>, those teams helped to ensure that the components of our implementation all have availability and latency targets, operational robustness, etc. These are compatible with our business needs and intended user experiences.</div> <div> <br /> <b>Put employees in control as much as possible</b><br /> <br /> Employees cover a broad range of job functions with varying requirements of technology and tools. In addition to communicating changes to our employees early, we provide them with self-service solutions for handling exceptions or addressing issues affecting their devices. By putting our employees in control, we help to ensure that security mechanisms do not get in their way, helping with the acceptance and scaling processes.</div> <div> <br /></div> <span style="font-size: large;"><b>Summary</b></span><br /> <br /> Throughout this series of blog posts, we set out to revisit and demystify BeyondCorp, Google’s internal implementation of a zero trust security model. The four posts had different focus areas - <a href="https://security.googleblog.com/2019/06/how-google-adopted-beyondcorp.html">setting context</a>, <a href="https://security.googleblog.com/2019/08/how-google-adopted-beyondcorp-part-2.html">devices</a>, <a href="https://security.googleblog.com/2019/09/how-google-adopted-beyondcorp-part-3.html">tiered access</a> and, finally, services (this post).<br /> <br /> If you want to learn more, you can check out the <a href="https://cloud.google.com/beyondcorp/#researchPapers">BeyondCorp research papers</a>. In addition, getting started with BeyondCorp is now easier using zero trust solutions from <a href="https://cloud.google.com/context-aware-access/">Google Cloud (context-aware access)</a> and other enterprise providers. Lastly, stay tuned for an upcoming BeyondCorp webinar on <a href="https://cloudonair.withgoogle.com/">Cloud OnAir</a> in a few months where you will be able to learn more and ask us questions. We hope that these blog posts, research papers, and webinars will help you on your journey to enable zero trust access.<br /> <br /> <i>Thank you to the editors of the BeyondCorp blog post series, Puneet Goel (Product Manager), Lior Tishbi (Program Manager), and Justin McWilliams (Engineering Manager).</i> <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 Guilherme Gonçalves, Site Reliability Engineer and Kyle O'Malley, Security Engineer </span><br /> <span class="byline-author"><br /></span> <br /> <b><span style="font-size: large;">Intro</span></b><br /> This is the final post in a series of four, in which we set out to revisit various <a href="https://cloud.google.com/beyondcorp/">BeyondCorp</a> topics and share lessons that were learnt along the internal implementation path at Google.<br /> <br /> The <a href="https://security.googleblog.com/2019/06/how-google-adopted-beyondcorp.html">first post</a> in this series focused on providing necessary context for how Google adopted BeyondCorp, Google’s implementation of the zero trust security model. The <a href="https://security.googleblog.com/2019/08/how-google-adopted-beyondcorp-part-2.html">second post</a> focused on managing devices - how we decide whether or not a device should be trusted and why that distinction is necessary. The <a href="https://security.googleblog.com/2019/09/how-google-adopted-beyondcorp-part-3.html">third post</a> focused on tiered access - how to define access tiers and rules and how to simplify troubleshooting when things go wrong.<br /> <br /> This post introduces the concept of gated services, how to identify and, subsequently, migrate them and the associated lessons we learned along the way.<br /> <span class="byline-author"><br /></span> <br /> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/-Uu_kkCOrkCY/Xbn_KJ05U6I/AAAAAAAABDA/xmCo3WYBCD4slf8zT_AZyLOy13JIm2pmQCNcBGAsYHQ/s1600/beyond1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="507" data-original-width="1260" height="128" src="https://1.bp.blogspot.com/-Uu_kkCOrkCY/Xbn_KJ05U6I/AAAAAAAABDA/xmCo3WYBCD4slf8zT_AZyLOy13JIm2pmQCNcBGAsYHQ/s320/beyond1.png" width="320" /></a></div> <div style="text-align: center;"> <span class="byline-author"><span id="docs-internal-guid-3b1f47ca-7fff-dd1f-3434-d9af14a1528d"></span></span></div> <div style="text-align: center;"> High level architecture for BeyondCorp</div> <br /> <b><span style="font-size: large;">Identifying and gating services</span></b><br /> <div> <b><br />How do you identify and categorize all the services that should be gated?</b><br /> Google began as a web-based company, and as it matured in the modern era, most internal business applications were developed with a web-first approach. These applications were hosted on similar internal architecture as our external services, with the exception that they could only be accessed on corporate office networks. Thus, identifying services to be gated by BeyondCorp was made easier for us due to the fact that most internal services were already properly inventoried and hosted via standard, central solutions. Migration, in many cases, was as simple as a DNS change. Solid IT asset inventory systems and maintenance are critical to migrating to a zero trust security model.<br /> <br /> Enforcement of zero trust access policies began with services which we determined would not be meaningfully impacted by the change in access requirements. For most services, requirements could be gathered via typical access log analysis or consulting with service owners. Services which could not be readily gated by default ACL requirements required service owners to develop strict access groups and/or eliminate risky workflows before they could be migrated.</div> <div> <br /></div> <b>How do you know which trust tier is needed for every service?</b><br /> As discussed in our <a href="https://security.googleblog.com/2019/09/how-google-adopted-beyondcorp-part-3.html">previous blog post</a>, Google makes internal services available based on device trust tiers. Today, those services are accessible by the highest trust tier by default. <br /> <br /> When the intent of the change is to restrict access to a service to a specific group or team, service owners are free to propose access changes to add or remove restrictions to their service. Access changes which are deemed to be sufficiently low risk can be automatically approved. In all other cases, such as where the owning team wants to expose a service to a risky device tier, they must work with security engineers to follow the <a href="http://en.wikipedia.org/wiki/Principle_of_least_privilege">principle of least privilege</a> and devise solutions.<br /> <div> <br /> <b>What do you do with services that are incompatible with BeyondCorp ideals?</b><br /> <br /> It may not always be possible to gate an application by the preferred zero trust solution. Services that cannot be easily gated typically fall into these categories:<br /> <ul> <li>Type 1: "Non-proxyable protocols", e.g. non-HTTP/HTTPS traffic.</li> <li>Type 2: Low latency requirements or localized high throughput traffic.</li> <li>Type 3: Administrative and emergency access networks.</li> </ul> The typical first step in finding a solution for these cases is finding a way to remove the need for that service altogether. In many cases, this was made possible by deprecating or replacing systems which could not be made compatible with the BeyondCorp implementation.<br /> <br /> When that was not an option, we found that no single solution would work for all critical requirements: <br /> <ul> <li>Solutions for the "Type 1" traffic have generally involved maintaining a specialized client tunneling which strongly enforces authentication and authorization decisions on the client and the server end of the connection. This is usually client/server type traffic which is similar to HTTP traffic in that connectivity is typically multi-point to point.</li> <li>Solutions to the "Type 2" problems generally rely on moving BeyondCorp-compatible compute resources locally or developing a solution tightly integrated with network access equipment to selectively forward "local" traffic without permanently opening network holes.</li> <li>As for “Type 3,” it would be ideal to completely eliminate all privileged internal networks. However, the reality is that some privileged networking will likely always be required to maintain the network itself and also to provide emergency access during outages.</li> </ul> It should be noted that server-to-server traffic in secure production data center environments does not necessarily rely on BeyondCorp, although many systems are integrated regardless, due to the Service-Oriented Design benefits that BeyondCorp inherently provides. </div> <div> <br /> <b>How do you prioritize gating?</b><br /> <br /> Prioritization starts by identifying all the services that are currently accessible via internal IP-access alone and migrating the most critical services to BeyondCorp, while working to slowly ratchet down permissions via exception management processes. Criticality of the service may also depend on the number and type of users, sensitivity of data handled, security and privacy risks enabled by the service.</div> <div> <br /> <b>Migration logistics</b><br /> <br /> Most services required integration testing with the BeyondCorp proxy. Service teams were encouraged to stand up "test" services which were used to test functionality behind the BeyondCorp proxy. Most services that performed their own access control enforcement were reconfigured to instead rely on BeyondCorp for all user/group authentication and authorization. Service teams have been encouraged to develop their own "fine-grained" discretionary access controls in the services by leveraging session data provided by the BeyondCorp proxy.</div> <div> <br /></div> <span style="font-size: large;"><b>Lessons learnt</b></span><br /> <div> <span style="font-size: large;"><br /></span><b>Allow coarse gating and exceptions</b><br /> <br /> Inventory: It's easy to overlook the importance of keeping a good inventory of services, devices, owners and security exceptions. The journey to a BeyondCorp world should start by solving organizational challenges when managing and maintaining data quality in inventory systems. In short, knowing how a service works, who should access it, and what makes that acceptable are the central tenets of managing BeyondCorp. Fine-grained access control is severely complicated when this insight is missing.<br /> <br /> Legacy protocols: Most large enterprises will inevitably need to support workflows and protocols which cannot be migrated to a BeyondCorp world (in any reasonable amount of time). Exception management and service inventory become crucial at this stage while stakeholders develop solutions.</div> <div> <b>Run highly reliable systems</b><br /> The BeyondCorp initiative would not be sustainable at Google’s scale without the involvement of various Site Reliability Engineering (SRE) teams across the inventory systems, BeyondCorp infrastructure and client side solutions. The ability to successfully achieve wide-spread adoption of changes this large can be hampered by perceived (or in some cases, actual) reliability issues. Understanding the user workflows that might be impacted, working with key stakeholders and ensuring the transition is smooth and trouble-free for all users helps protect against backlash and avoids users finding undesirable workarounds. By applying our <a href="https://landing.google.com/sre/sre-book/toc/index.html">reliability engineering practices</a>, those teams helped to ensure that the components of our implementation all have availability and latency targets, operational robustness, etc. These are compatible with our business needs and intended user experiences.</div> <div> <br /> <b>Put employees in control as much as possible</b><br /> <br /> Employees cover a broad range of job functions with varying requirements of technology and tools. In addition to communicating changes to our employees early, we provide them with self-service solutions for handling exceptions or addressing issues affecting their devices. By putting our employees in control, we help to ensure that security mechanisms do not get in their way, helping with the acceptance and scaling processes.</div> <div> <br /></div> <span style="font-size: large;"><b>Summary</b></span><br /> <br /> Throughout this series of blog posts, we set out to revisit and demystify BeyondCorp, Google’s internal implementation of a zero trust security model. The four posts had different focus areas - <a href="https://security.googleblog.com/2019/06/how-google-adopted-beyondcorp.html">setting context</a>, <a href="https://security.googleblog.com/2019/08/how-google-adopted-beyondcorp-part-2.html">devices</a>, <a href="https://security.googleblog.com/2019/09/how-google-adopted-beyondcorp-part-3.html">tiered access</a> and, finally, services (this post).<br /> <br /> If you want to learn more, you can check out the <a href="https://cloud.google.com/beyondcorp/#researchPapers">BeyondCorp research papers</a>. In addition, getting started with BeyondCorp is now easier using zero trust solutions from <a href="https://cloud.google.com/context-aware-access/">Google Cloud (context-aware access)</a> and other enterprise providers. Lastly, stay tuned for an upcoming BeyondCorp webinar on <a href="https://cloudonair.withgoogle.com/">Cloud OnAir</a> in a few months where you will be able to learn more and ask us questions. We hope that these blog posts, research papers, and webinars will help you on your journey to enable zero trust access.<br /> <br /> <i>Thank you to the editors of the BeyondCorp blog post series, Puneet Goel (Product Manager), Lior Tishbi (Program Manager), and Justin McWilliams (Engineering Manager).</i> <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 Google adopted BeyondCorp: Part 4 (services)&url=https://security.googleblog.com/2019/10/how-google-adopted-beyondcorp-part-4.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/2019/10/how-google-adopted-beyondcorp-part-4.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/2019/10/how-google-adopted-beyondcorp-part-4.html' data-url='https://security.googleblog.com/2019/10/how-google-adopted-beyondcorp-part-4.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/10/how-google-adopted-beyondcorp-part-4.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='6585924387720469179' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/10/protecting-against-code-reuse-in-linux_30.html' itemprop='url' title='Protecting against code reuse in the Linux kernel with Shadow Call Stack'> Protecting against code reuse in the Linux kernel with Shadow Call Stack </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> October 30, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Sami Tolvanen, Staff Software Engineer, Android Security & Privacy Team </span> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik7MTjh-5BgGwUn2GE-M4ZkFXhKuvQYGw5qEwY236mzI4cg-L4g1-VXa8gvisbfZ5kkXHZGIYr9jqROSzplg44mhMbwtcumC0bGzagw-zxoELOgen4aInJjcZhnSIELVB8zOl7PdRipCYH/s1600/Asset+2.png" imageanchor="1"><img border="0" data-original-height="763" data-original-width="1183" height="411" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik7MTjh-5BgGwUn2GE-M4ZkFXhKuvQYGw5qEwY236mzI4cg-L4g1-VXa8gvisbfZ5kkXHZGIYr9jqROSzplg44mhMbwtcumC0bGzagw-zxoELOgen4aInJjcZhnSIELVB8zOl7PdRipCYH/s640/Asset+2.png" width="640" /></a> <br /> The Linux kernel is responsible for enforcing much of Android’s security model, which is why we have put a lot of effort into hardening the Android Linux kernel against exploitation. In Android 9, we introduced support for Clang’s forward-edge <a href="https://android-developers.googleblog.com/2018/10/control-flow-integrity-in-android-kernel.html">Control-Flow Integrity (CFI)</a> enforcement to protect the kernel from code reuse attacks that modify stored function pointers. This year, we have added backward-edge protection for return addresses using Clang’s <a href="https://clang.llvm.org/docs/ShadowCallStack.html">Shadow Call Stack (SCS)</a>. <br /> Google’s Pixel 3 and 3a phones have kernel SCS enabled in the Android 10 update, and Pixel 4 ships with this protection out of the box. We have made patches available to all supported versions of the Android kernel and also maintain a patch set against upstream Linux. This post explains how kernel SCS works, the benefits and trade-offs, how to enable the feature, and how to debug potential issues. <br /> <h2> Return-oriented programming</h2> As kernel memory protections increasingly make code injection more difficult, attackers commonly use control flow hijacking to exploit kernel bugs. <a href="https://en.wikipedia.org/wiki/Return-oriented_programming">Return-oriented programming (ROP)</a> is a technique where the attacker gains control of the kernel stack to overwrite function return addresses and redirect execution to carefully selected parts of existing kernel code, known as ROP gadgets. While address space randomization and stack canaries can make this attack more challenging, return addresses stored on the stack remain vulnerable to many overwrite flaws. The general availability of tools for <a href="https://www.usenix.org/conference/usenixsecurity19/presentation/wu-wei">automatically generating this type of kernel exploit</a> makes protecting against it increasingly important. <br /> <h2> Shadow Call Stack</h2> One method of protecting return addresses is to store them in a separately allocated shadow stack that’s not vulnerable to traditional buffer overflows. This can also help protect against arbitrary overwrite attacks. <br /> Clang added the Shadow Call Stack instrumentation pass for arm64 in version 7. When enabled, each non-leaf function that pushes the return address to the stack will be instrumented with code that also saves the address to a shadow stack. A pointer to the current task’s shadow stack is always kept in the x18 register, which is reserved for this purpose. Here’s what instrumentation looks like in a typical kernel function: <br /> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjOzY5xbtZ1TFrj3g-x85ha8wLDgrkFgooek_MxavNmPzta7V_8BNApW_D8QfeSqdX_6D6l_7AJ-l83gF4TH54YS3hTzExAix8TDMNwfuKi7oqLfNov0x82x4lydwhGW2asWAt9VFE1Z7g/s1600/scs-instrumentation.png" imageanchor="1"><img border="0" data-original-height="331" data-original-width="858" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjOzY5xbtZ1TFrj3g-x85ha8wLDgrkFgooek_MxavNmPzta7V_8BNApW_D8QfeSqdX_6D6l_7AJ-l83gF4TH54YS3hTzExAix8TDMNwfuKi7oqLfNov0x82x4lydwhGW2asWAt9VFE1Z7g/s1600/scs-instrumentation.png" /></a> <br /> SCS doesn’t require error handling as it uses the return address from the shadow stack unconditionally. Compatibility with stack unwinding for debugging purposes is maintained by keeping a copy of the return address in the normal stack, but this value is never used for control flow decisions. <br /> Despite requiring a dedicated register, SCS has minimal performance overhead. The instrumentation itself consists of one load and one store instruction per function, which results in a performance impact that’s within noise in our benchmarking. Allocating a shadow stack for each thread does increase the kernel’s memory usage but as only return addresses are stored, the stack size defaults to 1kB. Therefore, the overhead is a fraction of the memory used for the already small regular kernel stacks. <br /> SCS patches are available for Android kernels <a href="https://android-review.googlesource.com/q/topic:android-4.14-scs">4.14</a> and <a href="https://android-review.googlesource.com/q/topic:android-4.19-scs">4.19</a>, and for <a href="https://github.com/samitolvanen/linux/commits/clang-scs">upstream Linux</a>. It can be enabled using the following configuration options: </p> <pre class="prettyprint">CONFIG_SHADOW_CALL_STACK=y # CONFIG_SHADOW_CALL_STACK_VMAP is not set # CONFIG_DEBUG_STACK_USAGE is not set</pre> <p> By default, shadow stacks are not virtually allocated to minimize memory overhead, but CONFIG_SHADOW_CALL_STACK_VMAP can be enabled for better stack exhaustion protection. With CONFIG_DEBUG_STACK_USAGE, the kernel will also print out shadow stack usage in addition to normal stack usage which can be helpful when debugging issues. <br /> <h2> Alternatives</h2> Signing return addresses using <a href="https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf">ARMv8.3 Pointer Authentication (PAC)</a> is an alternative to shadow stacks. PAC has similar security properties and comparable performance to SCS but without the memory allocation overhead. Unfortunately, PAC requires hardware support, which means it cannot be used on existing devices, but may be a viable option for future devices. For x86, Intel’s <a href="https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf">Control-flow Enforcement Technology (CET)</a> extension will offer a native shadow stack support, but also requires compatible hardware. <br /> <h2> Conclusion</h2> We have improved Linux kernel code reuse attack protections on Pixel devices running Android 10. Pixel 3, 3a, and 4 kernels have both CFI and SCS enabled and we have made patches available to all Android OEMs. <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 Sami Tolvanen, Staff Software Engineer, Android Security & Privacy Team </span> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik7MTjh-5BgGwUn2GE-M4ZkFXhKuvQYGw5qEwY236mzI4cg-L4g1-VXa8gvisbfZ5kkXHZGIYr9jqROSzplg44mhMbwtcumC0bGzagw-zxoELOgen4aInJjcZhnSIELVB8zOl7PdRipCYH/s1600/Asset+2.png" imageanchor="1"><img border="0" data-original-height="763" data-original-width="1183" height="411" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik7MTjh-5BgGwUn2GE-M4ZkFXhKuvQYGw5qEwY236mzI4cg-L4g1-VXa8gvisbfZ5kkXHZGIYr9jqROSzplg44mhMbwtcumC0bGzagw-zxoELOgen4aInJjcZhnSIELVB8zOl7PdRipCYH/s640/Asset+2.png" width="640" /></a> <br /> The Linux kernel is responsible for enforcing much of Android’s security model, which is why we have put a lot of effort into hardening the Android Linux kernel against exploitation. In Android 9, we introduced support for Clang’s forward-edge <a href="https://android-developers.googleblog.com/2018/10/control-flow-integrity-in-android-kernel.html">Control-Flow Integrity (CFI)</a> enforcement to protect the kernel from code reuse attacks that modify stored function pointers. This year, we have added backward-edge protection for return addresses using Clang’s <a href="https://clang.llvm.org/docs/ShadowCallStack.html">Shadow Call Stack (SCS)</a>. <br /> Google’s Pixel 3 and 3a phones have kernel SCS enabled in the Android 10 update, and Pixel 4 ships with this protection out of the box. We have made patches available to all supported versions of the Android kernel and also maintain a patch set against upstream Linux. This post explains how kernel SCS works, the benefits and trade-offs, how to enable the feature, and how to debug potential issues. <br /> <h2> Return-oriented programming</h2> As kernel memory protections increasingly make code injection more difficult, attackers commonly use control flow hijacking to exploit kernel bugs. <a href="https://en.wikipedia.org/wiki/Return-oriented_programming">Return-oriented programming (ROP)</a> is a technique where the attacker gains control of the kernel stack to overwrite function return addresses and redirect execution to carefully selected parts of existing kernel code, known as ROP gadgets. While address space randomization and stack canaries can make this attack more challenging, return addresses stored on the stack remain vulnerable to many overwrite flaws. The general availability of tools for <a href="https://www.usenix.org/conference/usenixsecurity19/presentation/wu-wei">automatically generating this type of kernel exploit</a> makes protecting against it increasingly important. <br /> <h2> Shadow Call Stack</h2> One method of protecting return addresses is to store them in a separately allocated shadow stack that’s not vulnerable to traditional buffer overflows. This can also help protect against arbitrary overwrite attacks. <br /> Clang added the Shadow Call Stack instrumentation pass for arm64 in version 7. When enabled, each non-leaf function that pushes the return address to the stack will be instrumented with code that also saves the address to a shadow stack. A pointer to the current task’s shadow stack is always kept in the x18 register, which is reserved for this purpose. Here’s what instrumentation looks like in a typical kernel function: <br /> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjOzY5xbtZ1TFrj3g-x85ha8wLDgrkFgooek_MxavNmPzta7V_8BNApW_D8QfeSqdX_6D6l_7AJ-l83gF4TH54YS3hTzExAix8TDMNwfuKi7oqLfNov0x82x4lydwhGW2asWAt9VFE1Z7g/s1600/scs-instrumentation.png" imageanchor="1"><img border="0" data-original-height="331" data-original-width="858" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjOzY5xbtZ1TFrj3g-x85ha8wLDgrkFgooek_MxavNmPzta7V_8BNApW_D8QfeSqdX_6D6l_7AJ-l83gF4TH54YS3hTzExAix8TDMNwfuKi7oqLfNov0x82x4lydwhGW2asWAt9VFE1Z7g/s1600/scs-instrumentation.png" /></a> <br /> SCS doesn’t require error handling as it uses the return address from the shadow stack unconditionally. Compatibility with stack unwinding for debugging purposes is maintained by keeping a copy of the return address in the normal stack, but this value is never used for control flow decisions. <br /> Despite requiring a dedicated register, SCS has minimal performance overhead. The instrumentation itself consists of one load and one store instruction per function, which results in a performance impact that’s within noise in our benchmarking. Allocating a shadow stack for each thread does increase the kernel’s memory usage but as only return addresses are stored, the stack size defaults to 1kB. Therefore, the overhead is a fraction of the memory used for the already small regular kernel stacks. <br /> SCS patches are available for Android kernels <a href="https://android-review.googlesource.com/q/topic:android-4.14-scs">4.14</a> and <a href="https://android-review.googlesource.com/q/topic:android-4.19-scs">4.19</a>, and for <a href="https://github.com/samitolvanen/linux/commits/clang-scs">upstream Linux</a>. It can be enabled using the following configuration options: </p> <pre class="prettyprint">CONFIG_SHADOW_CALL_STACK=y # CONFIG_SHADOW_CALL_STACK_VMAP is not set # CONFIG_DEBUG_STACK_USAGE is not set</pre> <p> By default, shadow stacks are not virtually allocated to minimize memory overhead, but CONFIG_SHADOW_CALL_STACK_VMAP can be enabled for better stack exhaustion protection. With CONFIG_DEBUG_STACK_USAGE, the kernel will also print out shadow stack usage in addition to normal stack usage which can be helpful when debugging issues. <br /> <h2> Alternatives</h2> Signing return addresses using <a href="https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf">ARMv8.3 Pointer Authentication (PAC)</a> is an alternative to shadow stacks. PAC has similar security properties and comparable performance to SCS but without the memory allocation overhead. Unfortunately, PAC requires hardware support, which means it cannot be used on existing devices, but may be a viable option for future devices. For x86, Intel’s <a href="https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf">Control-flow Enforcement Technology (CET)</a> extension will offer a native shadow stack support, but also requires compatible hardware. <br /> <h2> Conclusion</h2> We have improved Linux kernel code reuse attack protections on Pixel devices running Android 10. Pixel 3, 3a, and 4 kernels have both CFI and SCS enabled and we have made patches available to all Android OEMs. <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:Protecting against code reuse in the Linux kernel with Shadow Call Stack&url=https://security.googleblog.com/2019/10/protecting-against-code-reuse-in-linux_30.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/2019/10/protecting-against-code-reuse-in-linux_30.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/2019/10/protecting-against-code-reuse-in-linux_30.html' data-url='https://security.googleblog.com/2019/10/protecting-against-code-reuse-in-linux_30.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/10/protecting-against-code-reuse-in-linux_30.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/android%20security' rel='tag'> android security </a> </span> </div> </div> </div> <div class='post' data-id='4037946343832110321' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/10/improving-site-isolation-for-stronger.html' itemprop='url' title='Improving Site Isolation for Stronger Browser Security'> Improving Site Isolation for Stronger Browser Security </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> October 17, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Charlie Reis, Site Isolator </span> </p> <p> The Chrome Security team values having multiple lines of defense. Web browsers are complex, and malicious web pages may try to find and exploit browser bugs to steal data. Additional lines of defense, like <a href="https://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html">sandboxes</a>, make it harder for attackers to access your computer, even if bugs in the browser are exploited. With <a href="https://www.chromium.org/Home/chromium-security/site-isolation">Site Isolation</a>, Chrome has gained a new line of defense that helps protect your accounts on the Web as well. </p> <p> Site Isolation ensures that pages from different sites end up in different sandboxed processes in the browser. Chrome can thus limit the entire process to accessing data from only one site, making it harder for an attacker to steal cross-site data. We started isolating all sites <a href="https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html">for desktop users back in Chrome 67</a>, and now we’re excited to enable it on Android for sites that users log into <a href="https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html">in Chrome 77</a>. We've also strengthened Site Isolation on desktop to help defend against even fully compromised processes. </p> <p> Site Isolation helps defend against two types of threats. First, attackers may try to use advanced "side channel" attacks to leak sensitive data from a process through unexpected means. For example, <a href="https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html">Spectre</a> attacks take advantage of CPU performance features to access data that should be off limits. With Site Isolation, it is harder for the attacker to get cross-site data into their process in the first place. </p> <p> Second, even more powerful attackers may discover security bugs in the browser, allowing them to completely hijack the sandboxed process. On desktop platforms, Site Isolation can now catch these misbehaving processes and limit their access to cross-site data. We're working to bring this level of hijacked process protection to Android in the future as well. </p> <p> Thanks to this extra line of defense, Chrome can now help keep your web accounts even more secure. We are still making improvements to get the full benefits of Site Isolation, but this change gives Chrome a solid foundation for protecting your data. </p> <p> If you’d like to learn more, check out our <a href="https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html">technical write up</a> on the Chromium blog. </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 Charlie Reis, Site Isolator </span> </p> <p> The Chrome Security team values having multiple lines of defense. Web browsers are complex, and malicious web pages may try to find and exploit browser bugs to steal data. Additional lines of defense, like <a href="https://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html">sandboxes</a>, make it harder for attackers to access your computer, even if bugs in the browser are exploited. With <a href="https://www.chromium.org/Home/chromium-security/site-isolation">Site Isolation</a>, Chrome has gained a new line of defense that helps protect your accounts on the Web as well. </p> <p> Site Isolation ensures that pages from different sites end up in different sandboxed processes in the browser. Chrome can thus limit the entire process to accessing data from only one site, making it harder for an attacker to steal cross-site data. We started isolating all sites <a href="https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html">for desktop users back in Chrome 67</a>, and now we’re excited to enable it on Android for sites that users log into <a href="https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html">in Chrome 77</a>. We've also strengthened Site Isolation on desktop to help defend against even fully compromised processes. </p> <p> Site Isolation helps defend against two types of threats. First, attackers may try to use advanced "side channel" attacks to leak sensitive data from a process through unexpected means. For example, <a href="https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html">Spectre</a> attacks take advantage of CPU performance features to access data that should be off limits. With Site Isolation, it is harder for the attacker to get cross-site data into their process in the first place. </p> <p> Second, even more powerful attackers may discover security bugs in the browser, allowing them to completely hijack the sandboxed process. On desktop platforms, Site Isolation can now catch these misbehaving processes and limit their access to cross-site data. We're working to bring this level of hijacked process protection to Android in the future as well. </p> <p> Thanks to this extra line of defense, Chrome can now help keep your web accounts even more secure. We are still making improvements to get the full benefits of Site Isolation, but this change gives Chrome a solid foundation for protecting your data. </p> <p> If you’d like to learn more, check out our <a href="https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html">technical write up</a> on the Chromium blog. </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 Site Isolation for Stronger Browser Security&url=https://security.googleblog.com/2019/10/improving-site-isolation-for-stronger.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/2019/10/improving-site-isolation-for-stronger.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/2019/10/improving-site-isolation-for-stronger.html' data-url='https://security.googleblog.com/2019/10/improving-site-isolation-for-stronger.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/10/improving-site-isolation-for-stronger.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='6400740041765624233' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/10/usb-c-titan-security-keys-available.html' itemprop='url' title='USB-C Titan Security Keys - available tomorrow in the US'> USB-C Titan Security Keys - available tomorrow in the US </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> October 14, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Christiaan Brand, Product Manager, Google Cloud </span><br /> <br /> <br /> Securing access to online accounts is critical for safeguarding private, financial, and other sensitive data online. Phishing - where an attacker tries to trick you into giving them your username and password - is one of the most common causes of data breaches. To protect user accounts, we’ve long made it a priority to offer users many convenient forms of 2-Step Verification (2SV), also known as two-factor authentication (2FA), in addition to <a href="https://safety.google/security/">Google’s automatic protections</a>. These measures help to ensure that users are not relying solely on passwords for account security. <br /> <br /> For users at higher risk (e.g., IT administrators, executives, politicians, activists) who need more effective protection against targeted attacks, security keys provide the <a href="https://security.googleblog.com/2019/05/new-research-how-effective-is-basic.html">strongest</a> form of 2FA. To make this phishing-resistant security accessible to more people and businesses, we recently <a href="https://security.googleblog.com/2019/06/use-your-android-phones-built-in.html">built</a> this capability into Android phones, <a href="https://security.googleblog.com/2019/07/titan-security-keys-are-now-available.html">expanded</a> the availability of Titan Security Keys to more regions (Canada, France, Japan, the UK), and <a href="https://cloud.google.com/blog/products/identity-security/new-protections-for-users-data-and-apps-in-the-cloud">extended</a> Google’s Advanced Protection Program to the enterprise. <br /> <br /> Starting tomorrow, you will have an additional option: Google’s new USB-C Titan Security Key, compatible with your Android, Chrome OS, macOS, and Windows devices.<br /> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/--MtjcHRkYIs/XaD9iz1DaYI/AAAAAAAAA_0/LzdnJrpl9xQI0CT1ymZyOPpG6u9V-hS5QCNcBGAsYHQ/s1600/USB-C%2BTitan%2BSecurity%2BKey%2BAngled%2Bview2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1233" data-original-width="1080" height="320" src="https://1.bp.blogspot.com/--MtjcHRkYIs/XaD9iz1DaYI/AAAAAAAAA_0/LzdnJrpl9xQI0CT1ymZyOPpG6u9V-hS5QCNcBGAsYHQ/s320/USB-C%2BTitan%2BSecurity%2BKey%2BAngled%2Bview2.png" width="280" /></a></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> <h3 style="text-align: center;"> <br /><i>USB-C Titan Security Key</i></h3> <div style="text-align: center;"> <i><br /></i></div> We partnered with <a href="https://www.yubico.com/">Yubico</a> to manufacture the USB-C Titan Security Key. We have had a long-standing working and customer relationship with Yubico that began in 2012 with the collaborative effort to create the <a href="https://fidoalliance.org/how-fido-works/">FIDO</a> Universal 2nd Factor (U2F) standard, the first open standard to enable phishing-resistant authentication. This is the same security technology that we use at Google to protect access to internal applications and systems.<br /> <br /> USB-C Titan Security Keys are built with a hardware secure element chip that includes firmware engineered by Google to verify the key’s integrity. This is the same secure element chip and firmware that we use in our existing USB-A/NFC and Bluetooth/NFC/USB Titan Security Key models manufactured in partnership with <a href="http://www.ftsafe.com/">Feitian Technologies</a>.<br /> <br /> USB-C Titan Security Keys will be available tomorrow individually for $40 on the <a href="https://store.google.com/product/titan_security_key">Google Store</a> in the United States. USB-A/NFC and Bluetooth/NFC/USB Titan Security Keys will also become available individually in addition to the existing bundle. <a href="https://cloud.google.com/titan-security-key/#pricing">Bulk orders</a> are available for enterprise organizations in select countries.<br /> <div> <br /></div> <div> <br /></div> <div> We highly recommend all users at a higher risk of targeted attacks to get Titan Security Keys and enroll into the <a href="https://landing.google.com/advancedprotection/">Advanced Protection Program</a> (APP), which provides Google’s industry-leading security protections to defend against evolving methods that attackers use to gain access to your accounts and data. You can also use Titan Security Keys for any site where FIDO security keys are supported for 2FA, including your personal or work <a href="//g.co/2sv">Google Account</a>, <a href="https://support.1password.com/security-key/">1Password</a>, <a href="https://support.coinbase.com/customer/portal/articles/2973914-using-and-managing-security-keys">Coinbase</a>, <a href="https://www.dropbox.com/help/security/enable-two-step-verification#securitykey">Dropbox</a>, <a href="https://www.facebook.com/help/401566786855239">Facebook</a>, <a href="https://help.github.com/articles/configuring-two-factor-authentication/#configuring-two-factor-authentication-using-fido-u2f">GitHub</a>, <a href="https://help.salesforce.com/articleView?id=security_u2f_enable.htm&type=5">Salesforce</a>, <a href="https://support.stripe.com/questions/authentication-using-fido-u2f-security-keys">Stripe</a>, <a href="https://help.twitter.com/en/managing-your-account/two-factor-authentication#security-key">Twitter</a>, and more.</div> <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 Christiaan Brand, Product Manager, Google Cloud </span><br /> <br /> <br /> Securing access to online accounts is critical for safeguarding private, financial, and other sensitive data online. Phishing - where an attacker tries to trick you into giving them your username and password - is one of the most common causes of data breaches. To protect user accounts, we’ve long made it a priority to offer users many convenient forms of 2-Step Verification (2SV), also known as two-factor authentication (2FA), in addition to <a href="https://safety.google/security/">Google’s automatic protections</a>. These measures help to ensure that users are not relying solely on passwords for account security. <br /> <br /> For users at higher risk (e.g., IT administrators, executives, politicians, activists) who need more effective protection against targeted attacks, security keys provide the <a href="https://security.googleblog.com/2019/05/new-research-how-effective-is-basic.html">strongest</a> form of 2FA. To make this phishing-resistant security accessible to more people and businesses, we recently <a href="https://security.googleblog.com/2019/06/use-your-android-phones-built-in.html">built</a> this capability into Android phones, <a href="https://security.googleblog.com/2019/07/titan-security-keys-are-now-available.html">expanded</a> the availability of Titan Security Keys to more regions (Canada, France, Japan, the UK), and <a href="https://cloud.google.com/blog/products/identity-security/new-protections-for-users-data-and-apps-in-the-cloud">extended</a> Google’s Advanced Protection Program to the enterprise. <br /> <br /> Starting tomorrow, you will have an additional option: Google’s new USB-C Titan Security Key, compatible with your Android, Chrome OS, macOS, and Windows devices.<br /> <div> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://1.bp.blogspot.com/--MtjcHRkYIs/XaD9iz1DaYI/AAAAAAAAA_0/LzdnJrpl9xQI0CT1ymZyOPpG6u9V-hS5QCNcBGAsYHQ/s1600/USB-C%2BTitan%2BSecurity%2BKey%2BAngled%2Bview2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1233" data-original-width="1080" height="320" src="https://1.bp.blogspot.com/--MtjcHRkYIs/XaD9iz1DaYI/AAAAAAAAA_0/LzdnJrpl9xQI0CT1ymZyOPpG6u9V-hS5QCNcBGAsYHQ/s320/USB-C%2BTitan%2BSecurity%2BKey%2BAngled%2Bview2.png" width="280" /></a></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> <h3 style="text-align: center;"> <br /><i>USB-C Titan Security Key</i></h3> <div style="text-align: center;"> <i><br /></i></div> We partnered with <a href="https://www.yubico.com/">Yubico</a> to manufacture the USB-C Titan Security Key. We have had a long-standing working and customer relationship with Yubico that began in 2012 with the collaborative effort to create the <a href="https://fidoalliance.org/how-fido-works/">FIDO</a> Universal 2nd Factor (U2F) standard, the first open standard to enable phishing-resistant authentication. This is the same security technology that we use at Google to protect access to internal applications and systems.<br /> <br /> USB-C Titan Security Keys are built with a hardware secure element chip that includes firmware engineered by Google to verify the key’s integrity. This is the same secure element chip and firmware that we use in our existing USB-A/NFC and Bluetooth/NFC/USB Titan Security Key models manufactured in partnership with <a href="http://www.ftsafe.com/">Feitian Technologies</a>.<br /> <br /> USB-C Titan Security Keys will be available tomorrow individually for $40 on the <a href="https://store.google.com/product/titan_security_key">Google Store</a> in the United States. USB-A/NFC and Bluetooth/NFC/USB Titan Security Keys will also become available individually in addition to the existing bundle. <a href="https://cloud.google.com/titan-security-key/#pricing">Bulk orders</a> are available for enterprise organizations in select countries.<br /> <div> <br /></div> <div> <br /></div> <div> We highly recommend all users at a higher risk of targeted attacks to get Titan Security Keys and enroll into the <a href="https://landing.google.com/advancedprotection/">Advanced Protection Program</a> (APP), which provides Google’s industry-leading security protections to defend against evolving methods that attackers use to gain access to your accounts and data. You can also use Titan Security Keys for any site where FIDO security keys are supported for 2FA, including your personal or work <a href="//g.co/2sv">Google Account</a>, <a href="https://support.1password.com/security-key/">1Password</a>, <a href="https://support.coinbase.com/customer/portal/articles/2973914-using-and-managing-security-keys">Coinbase</a>, <a href="https://www.dropbox.com/help/security/enable-two-step-verification#securitykey">Dropbox</a>, <a href="https://www.facebook.com/help/401566786855239">Facebook</a>, <a href="https://help.github.com/articles/configuring-two-factor-authentication/#configuring-two-factor-authentication-using-fido-u2f">GitHub</a>, <a href="https://help.salesforce.com/articleView?id=security_u2f_enable.htm&type=5">Salesforce</a>, <a href="https://support.stripe.com/questions/authentication-using-fido-u2f-security-keys">Stripe</a>, <a href="https://help.twitter.com/en/managing-your-account/two-factor-authentication#security-key">Twitter</a>, and more.</div> <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:USB-C Titan Security Keys - available tomorrow in the US&url=https://security.googleblog.com/2019/10/usb-c-titan-security-keys-available.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/2019/10/usb-c-titan-security-keys-available.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/2019/10/usb-c-titan-security-keys-available.html' data-url='https://security.googleblog.com/2019/10/usb-c-titan-security-keys-available.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/10/usb-c-titan-security-keys-available.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </div> </div> </div> <div class='post' data-id='5060870697079429093' itemscope='' itemtype='http://schema.org/BlogPosting'> <h2 class='title' itemprop='name'> <a href='https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html' itemprop='url' title='No More Mixed Messages About HTTPS'> No More Mixed Messages About HTTPS </a> </h2> <div class='post-header'> <div class='published'> <span class='publishdate' itemprop='datePublished'> October 3, 2019 </span> </div> </div> <div class='post-body'> <div class='post-content' itemprop='articleBody'> <script type='text/template'> <span class="byline-author">Posted by Emily Stark and Carlos Joan Rafael Ibarra Lopez, Chrome security team</span> <p> <em>Update (04/06/2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the <a href="https://www.chromestatus.com/feature/4926989725073408">Chrome Platform Status entry</a> for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://. Sites with mixed images will continue to trigger the “Not Secure” warning. </em> </p> <br /> Today we’re announcing that Chrome will gradually start ensuring that https:// pages can only load secure https:// subresources. In a series of steps outlined below, we’ll start blocking <a href="https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content">mixed content</a> (insecure http:// subresources on https:// pages) by default. This change will improve user privacy and security on the web, and present a clearer browser security UX to users. <br /> In the past several years, the web has made great <a href="https://transparencyreport.google.com/https/overview?hl=en">progress</a> in transitioning to HTTPS: Chrome users now spend over 90% of their browsing time on HTTPS on all major platforms. We’re now turning our attention to making sure that HTTPS configurations across the web are secure and up-to-date. <br /> HTTPS pages commonly suffer from a problem called mixed content, where subresources on the page are loaded insecurely over http://. Browsers block many types of mixed content by default, like scripts and iframes, but images, audio, and video are still allowed to load, which threatens users’ privacy and security. For example, an attacker could tamper with a mixed image of a stock chart to mislead investors, or inject a tracking cookie into a mixed resource load. Loading mixed content also leads to a confusing browser security UX, where the page is presented as neither secure nor insecure but somewhere in between. <br /> In a series of steps starting in Chrome 79, <strong>Chrome will gradually move to blocking all mixed content by default</strong>.<strong> </strong>To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://. Users will be able to enable a setting to opt out of mixed content blocking on particular websites, and below we’ll describe the resources available to developers to help them find and fix mixed content. <br /> <strong>Timeline</strong> <br /> Instead of blocking all mixed content all at once, we’ll be rolling out this change in a series of steps. <br /> <ul> <li>In <strong>Chrome 79</strong>, releasing to stable channel in December 2019, we’ll introduce a new setting to unblock mixed content on specific sites. This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default. Users can toggle this setting by clicking the lock icon on any https:// page and clicking Site Settings. This will replace the shield icon that shows up at the right side of the omnibox for unblocking mixed content in previous versions of desktop Chrome.</li> </ul> <div style="text-align: center;"> <div class="separator" style="clear: both; text-align: center;"> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWAP8YSk7A0nxRGpFvgaLK7AXQUrnc53z4Uva7tBOKseG2F6Hq1KabPFy117fVH933Ncg9Y_WYbCftI6TekeevzrfP9qykIkCfM_wUsEXu1EbuYMUekhYMnA4MYztkjBogD1PNWMxVVolg/s1600/Page+info+%2528with+browser%2529_2x+%25281%2529.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1000" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWAP8YSk7A0nxRGpFvgaLK7AXQUrnc53z4Uva7tBOKseG2F6Hq1KabPFy117fVH933Ncg9Y_WYbCftI6TekeevzrfP9qykIkCfM_wUsEXu1EbuYMUekhYMnA4MYztkjBogD1PNWMxVVolg/s1600/Page+info+%2528with+browser%2529_2x+%25281%2529.png" /></a></div> <br /></div> <div> <br /></div> <br /> <div style="text-align: center;"> <em>Accessing Site settings, from which users will be able to unblock mixed content loads in Chrome 79.</em></div> <ul> </ul> <ul> <li style="text-align: left;">In <strong>Chrome 80</strong>, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 80 will be released to early release channels in January 2020. Users can unblock affected audio and video resources with the setting described above. </li> <li>Also in <strong>Chrome 80</strong>, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox. We anticipate that this is a clearer security UI for users and that it will motivate websites to migrate their images to HTTPS. Developers can use the <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests">upgrade-insecure-requests</a> or <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content">block-all-mixed-content</a> Content Security Policy directives to avoid this warning. </li> </ul> <div style="text-align: center;"> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqq6aHHWwKNKyEmrD8mwF6s8EwJaCCXGNsYmRtXb9ZehDsTq-SGa1sRK8JukhGsKDsjmAwqzx3v7vR_VBKf0b_-x14GgUi3i_UEA0fHJauDfWDjYK62U0ynEsZvNAQ48NOreVLYAN01xnq/s1600/not+secure.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="36" data-original-width="498" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqq6aHHWwKNKyEmrD8mwF6s8EwJaCCXGNsYmRtXb9ZehDsTq-SGa1sRK8JukhGsKDsjmAwqzx3v7vR_VBKf0b_-x14GgUi3i_UEA0fHJauDfWDjYK62U0ynEsZvNAQ48NOreVLYAN01xnq/s1600/not+secure.png" /></a></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> <em></em><br /> <div style="text-align: center;"> <em><em>Omnibox treatment for websites that load mixed images in Chrome 80.</em> </em></div> <em> </em><br /> <ul> <li>In<strong> Chrome 81</strong>, mixed images will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 81 will be released to early release channels in February 2020.</li> </ul> <strong>Resources for developers</strong> <br /> Developers should migrate their mixed content to https:// immediately to avoid warnings and breakage. Here are some resources: <br /> <ul> <li>Use <a href="https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content">Content Security Policy</a> and <a href="https://developers.google.com/web/tools/lighthouse/audits/mixed-content">Lighthouse</a>’s mixed content audit to discover and fix mixed content on your site. </li> <li>See <a href="https://developers.google.com/web/fundamentals/security/encrypt-in-transit/enable-https">this guide</a> for general advice on migrating servers to HTTPS. </li> <li>Check with your CDN, web host, or content management system to see if they have special tools for debugging mixed content. For example, Cloudflare offers a <a href="https://support.cloudflare.com/hc/en-us/articles/227227647">tool</a> to rewrite mixed content to https://, and WordPress <a href="https://en-gb.wordpress.org/plugins/ssl-insecure-content-fixer/">plugins</a> are available as well.</li> </ul> <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 Emily Stark and Carlos Joan Rafael Ibarra Lopez, Chrome security team</span> <p> <em>Update (04/06/2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the <a href="https://www.chromestatus.com/feature/4926989725073408">Chrome Platform Status entry</a> for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://. Sites with mixed images will continue to trigger the “Not Secure” warning. </em> </p> <br /> Today we’re announcing that Chrome will gradually start ensuring that https:// pages can only load secure https:// subresources. In a series of steps outlined below, we’ll start blocking <a href="https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content">mixed content</a> (insecure http:// subresources on https:// pages) by default. This change will improve user privacy and security on the web, and present a clearer browser security UX to users. <br /> In the past several years, the web has made great <a href="https://transparencyreport.google.com/https/overview?hl=en">progress</a> in transitioning to HTTPS: Chrome users now spend over 90% of their browsing time on HTTPS on all major platforms. We’re now turning our attention to making sure that HTTPS configurations across the web are secure and up-to-date. <br /> HTTPS pages commonly suffer from a problem called mixed content, where subresources on the page are loaded insecurely over http://. Browsers block many types of mixed content by default, like scripts and iframes, but images, audio, and video are still allowed to load, which threatens users’ privacy and security. For example, an attacker could tamper with a mixed image of a stock chart to mislead investors, or inject a tracking cookie into a mixed resource load. Loading mixed content also leads to a confusing browser security UX, where the page is presented as neither secure nor insecure but somewhere in between. <br /> In a series of steps starting in Chrome 79, <strong>Chrome will gradually move to blocking all mixed content by default</strong>.<strong> </strong>To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://. Users will be able to enable a setting to opt out of mixed content blocking on particular websites, and below we’ll describe the resources available to developers to help them find and fix mixed content. <br /> <strong>Timeline</strong> <br /> Instead of blocking all mixed content all at once, we’ll be rolling out this change in a series of steps. <br /> <ul> <li>In <strong>Chrome 79</strong>, releasing to stable channel in December 2019, we’ll introduce a new setting to unblock mixed content on specific sites. This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default. Users can toggle this setting by clicking the lock icon on any https:// page and clicking Site Settings. This will replace the shield icon that shows up at the right side of the omnibox for unblocking mixed content in previous versions of desktop Chrome.</li> </ul> <div style="text-align: center;"> <div class="separator" style="clear: both; text-align: center;"> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWAP8YSk7A0nxRGpFvgaLK7AXQUrnc53z4Uva7tBOKseG2F6Hq1KabPFy117fVH933Ncg9Y_WYbCftI6TekeevzrfP9qykIkCfM_wUsEXu1EbuYMUekhYMnA4MYztkjBogD1PNWMxVVolg/s1600/Page+info+%2528with+browser%2529_2x+%25281%2529.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1000" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWAP8YSk7A0nxRGpFvgaLK7AXQUrnc53z4Uva7tBOKseG2F6Hq1KabPFy117fVH933Ncg9Y_WYbCftI6TekeevzrfP9qykIkCfM_wUsEXu1EbuYMUekhYMnA4MYztkjBogD1PNWMxVVolg/s1600/Page+info+%2528with+browser%2529_2x+%25281%2529.png" /></a></div> <br /></div> <div> <br /></div> <br /> <div style="text-align: center;"> <em>Accessing Site settings, from which users will be able to unblock mixed content loads in Chrome 79.</em></div> <ul> </ul> <ul> <li style="text-align: left;">In <strong>Chrome 80</strong>, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 80 will be released to early release channels in January 2020. Users can unblock affected audio and video resources with the setting described above. </li> <li>Also in <strong>Chrome 80</strong>, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox. We anticipate that this is a clearer security UI for users and that it will motivate websites to migrate their images to HTTPS. Developers can use the <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests">upgrade-insecure-requests</a> or <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content">block-all-mixed-content</a> Content Security Policy directives to avoid this warning. </li> </ul> <div style="text-align: center;"> <br /></div> <div class="separator" style="clear: both; text-align: center;"> <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqq6aHHWwKNKyEmrD8mwF6s8EwJaCCXGNsYmRtXb9ZehDsTq-SGa1sRK8JukhGsKDsjmAwqzx3v7vR_VBKf0b_-x14GgUi3i_UEA0fHJauDfWDjYK62U0ynEsZvNAQ48NOreVLYAN01xnq/s1600/not+secure.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="36" data-original-width="498" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqq6aHHWwKNKyEmrD8mwF6s8EwJaCCXGNsYmRtXb9ZehDsTq-SGa1sRK8JukhGsKDsjmAwqzx3v7vR_VBKf0b_-x14GgUi3i_UEA0fHJauDfWDjYK62U0ynEsZvNAQ48NOreVLYAN01xnq/s1600/not+secure.png" /></a></div> <div class="separator" style="clear: both; text-align: center;"> <br /></div> <em></em><br /> <div style="text-align: center;"> <em><em>Omnibox treatment for websites that load mixed images in Chrome 80.</em> </em></div> <em> </em><br /> <ul> <li>In<strong> Chrome 81</strong>, mixed images will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 81 will be released to early release channels in February 2020.</li> </ul> <strong>Resources for developers</strong> <br /> Developers should migrate their mixed content to https:// immediately to avoid warnings and breakage. Here are some resources: <br /> <ul> <li>Use <a href="https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content">Content Security Policy</a> and <a href="https://developers.google.com/web/tools/lighthouse/audits/mixed-content">Lighthouse</a>’s mixed content audit to discover and fix mixed content on your site. </li> <li>See <a href="https://developers.google.com/web/fundamentals/security/encrypt-in-transit/enable-https">this guide</a> for general advice on migrating servers to HTTPS. </li> <li>Check with your CDN, web host, or content management system to see if they have special tools for debugging mixed content. For example, Cloudflare offers a <a href="https://support.cloudflare.com/hc/en-us/articles/227227647">tool</a> to rewrite mixed content to https://, and WordPress <a href="https://en-gb.wordpress.org/plugins/ssl-insecure-content-fixer/">plugins</a> are available as well.</li> </ul> <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:No More Mixed Messages About HTTPS&url=https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.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/2019/10/no-more-mixed-messages-about-https_3.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/2019/10/no-more-mixed-messages-about-https_3.html' data-url='https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html' style='color: #4184F3;'></span> </div> <div class='post-footer'> <div class='cmt_iframe_holder' data-href='https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html' data-viewtype='FILTERED_POSTMOD'></div> <a href='https://plus.google.com/112374322230920073195' rel='author' style='display:none;'> Google </a> <div class='label-footer'> </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> <span id='blog-pager-newer-link'> <a class='blog-pager-newer-link' href='https://security.googleblog.com/search?updated-max=2020-02-25T18:30:00-05:00&max-results=10&reverse-paginate=true' id='Blog1_blog-pager-newer-link' title='Newer Posts'> <i class='material-icons'>  </i> </a> </span> <span id='blog-pager-older-link'> <a class='blog-pager-older-link' href='https://security.googleblog.com/search?updated-max=2019-10-03T12:00:00-04:00&max-results=10' 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> <a dir='ltr' href='https://security.googleblog.com/search/label/chrome'> chrome </a> </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 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/2024/'> 2024 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate collapsed'> <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 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/2019/'> 2019 </a> </div> <div class='items'> <ul class='hierarchy'> <li class='archivedate expanded'> <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'] = 'AOuZoY4RKyOMm0PMVBjrRdMvC-ATWK0ftQ:1732770747455';_WidgetManager._Init('//www.blogger.com/rearrange?blogID\x3d1176949257541686127','//security.googleblog.com/2019/','1176949257541686127'); _WidgetManager._SetDataContext([{'name': 'blog', 'data': {'blogId': '1176949257541686127', 'title': 'Google Online Security Blog', 'url': 'https://security.googleblog.com/2019/', 'canonicalUrl': 'https://security.googleblog.com/2019/', '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': 'archive', 'pageName': '2019', 'pageTitle': 'Google Online Security Blog: 2019'}}, {'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/2019/', 'type': 'feed', 'isSingleItem': false, 'isMultipleItems': true, 'isError': false, 'isPage': false, 'isPost': false, 'isHomepage': false, 'isArchive': true, 'isLabelSearch': false, 'archive': {'year': 2019, 'rangeMessage': 'Showing posts from 2019'}}}]); _WidgetManager._RegisterWidget('_HeaderView', new _WidgetInfo('Header1', 'header', document.getElementById('Header1'), {}, 'displayModeFull')); _WidgetManager._RegisterWidget('_BlogView', new _WidgetInfo('Blog1', 'main', document.getElementById('Blog1'), {'cmtInteractionsEnabled': false}, '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>