Chrome 和 Chromium 的异同


=Start=

缘由:

前段时间在调研Chromium时总结整理的一些内容,在此记录一下,方便查阅和参考。

正文:

参考解答:

直接以表格形式展现,方便对比查看:


比较项
Chrome Chromium
是否开源 代码闭源,但提供免费下载和使用(free to download and use, but you cannot decompile, reverse engineer, or use the source code to build another program 代码开源,且支持自定义修改anyone can take and modify the source code however they please
应用图标 彩色 天蓝色
音视频解码 支持广泛(AAC, H.264, MP3, Opus, Theora, Vorbis, VP8, VP9, and WAV) 默认不支持闭源的音视频解码方式(AAC, H.264, MP3),但可以通过编译选项开启
安装方式 安装包方式安装 免安装,下载解压缩后即可使用
是否支持自动更新 支持自动更新 不支持
更新频率 正式版更新较慢(因为有稳定性方面的考虑) 更新频繁,新功能会先在Chromium上推出(更像是Chrome的新功能试验基地)
数据收集 会追踪一些使用信息 不追踪
Flash支持 默认支持(在76及其之后版本,默认关闭) 默认不支持
Google API keys 由Google添加 默认没有
Extension限制 默认需要重Chrome应用商店下载安装 无限制
安全沙盒 默认开启 默认不开启

以上就是它们两者之间的主要不同点。

参考链接:

Google Chrome version history
https://en.wikipedia.org/wiki/Google_Chrome_version_history

Chrome Release
https://chromereleases.googleblog.com/

Google Chrome 博客
https://blog.google/products/chrome/

下载 Chrome 浏览器
https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg
https://cloud.google.com/chrome-enterprise/browser/download/

The Chromium Projects
https://www.chromium.org/
https://www.chromium.org/developers/version-numbers
https://chromium.googlesource.com/chromium/

Chromium 博客
https://blog.chromium.org/

=END=

,

《“Chrome 和 Chromium 的异同”》 有 23 条评论

  1. 万字详文:深入理解浏览器原理
    https://zhuanlan.zhihu.com/p/96986818
    https://mp.weixin.qq.com/s/QqpPGWf3IVEDN1t80CZ06Q
    `
    导语:本文从市面主流的浏览器及相应的内核引擎开始,介绍了Chromium为代表的浏览器架构及Blink内核的功能架构。Chromium为多进程架构,用户从启动运行浏览器后,先后经过页面导航、渲染、资源加载、样式计算、布局、绘制、合成到栅格化,最后完成GPU展示。而页面渲染完成后,浏览器如何响应页面操作事件也进行了深入的介绍。良心推荐!

    本文第二至五部分内容根据 Mariko Kosaka 的英文原版《Inside look at modern web browser》(见参考文献),进行翻译、理解、总结提炼、条理化、加入应用示例、进行相关知识补充扩展而来。
    `

  2. https://zh.wikipedia.org/wiki/Google_Chrome
    https://zh.wikipedia.org/wiki/Chromium
    `
    Google Chrome相对于Chromium:

    图标:Chromium的是蓝色调,而Chrome的则是红、黄、绿
    Chromium 是开源软件,以BSD许可协议发布;Google Chrome则是闭源软件,不可修改再发布。
    Google Chrome 增加Google Update自动更新系统
    Google Chrome 增加自动发送使用统计数据及死机报告给Google的选项
    当Chrome用作市场推广及分销合作伙伴时会记录并发送用户记录,如:何时何处下载的信息。2010年6月,Google解释任一版本的Chromium或是从Google官方网站上下载的Chrome都不带有这一记录用户信息的功能。同时也公开了这些记录的源代码,以便开发者了解此功能是如何运作的。
    Chromium不包含Google API Key,导致部分功能仅Google Chrome能使用
    默认情况下,Chromium的HTML5播放器只支持Vorbis、Theora和WebM,而Google Chrome除了这些解码器外还支持AAC和MP3。2011年1月11日,Google Chrome的产品经理Mike Jazayeri宣布Chrome的HTML5播放器将和Chromium一样,不再支持H.264格式。但截至2012年4月,Chrome仍然支持H.264。有些Linux发行版本会向自定版Chromium增加对其他编解码器的支持。
    `

  3. 谷歌浏览器打开黑屏的最有效解决方法
    https://jingyan.baidu.com/article/6b18230908fa1cfa59e15900.html
    `
    1. 首先,要解决黑屏,才能打开浏览器,最后才可以禁用硬件加速!已经黑屏通过更改 快捷图标属性目标 地址,能够临时解决黑屏,正常进入浏览器。–disable-gpu –disable-software-rasterize粘贴复制到浏览器快捷图标 属性更改目标里,注意粘贴到原地址后面要先加一个空格(找到浏览器快捷图标,右键鼠标就可以更改目标了),然后应用,确认!这一步就可以临时正常打开浏览器了。

    2. 打开浏览器,最右上角点击,打开设置

    3. 找到系统,点开就可以看到:使用硬件加速模式 开关了

    4. 关闭后就可以正常使用浏览器了。
    `
    chrome里面设置里 使用硬件加速模式(如果可用) 要不要勾上?
    https://www.zhihu.com/question/60254110
    `
    不建议勾选。因为选后,播放视频可能会出现黑屏。
    `
    https://www.sysgeek.cn/chrome-hardware-acceleration/

  4. Chrome 80.0中将SameSite的默认值设为Lax,对现有的Cookie使用有什么影响?
    https://www.zhihu.com/question/373011996
    `
    要说哪些业务功能会到受影响,得先从技术上分析,得先知道 SameSite=Lax 会屏蔽掉那些类型的请求中带的第三方 Cookie。我在我 16 年写的 SameSite 科普文 https://www.cnblogs.com/ziyunfei/p/5637945.html 中已经总结出一个容易记忆的规则(但不完全对),那就是我们前端开发人员口中通常的“异步请求”会受到影响,即主要是 XHR/fetch()、、、 这些请求方式。
    `
    SameSite Cookie,防止 CSRF 攻击
    https://www.cnblogs.com/ziyunfei/p/5637945.html

  5. 深度解读浏览器全面禁用三方 Cookie
    https://mp.weixin.qq.com/s/izJ5fVpXuqSLFbMeuBlNfw
    `
    最近几大浏览器针对 Cookie 策略的频繁改动,意味着三方 Cookie 被全面禁用已经不远了:

    Firefox、Safari —— 默认禁用
    在 Safari 13.1、Firefox 79 版本中,三方 Cookie 已经被默认禁用,但是由于这些游览器市场份额较小,并没有给市场带来巨大的冲击。

    Chrome —— SameSite Cookie
    还好由于三方 Cookie 对 Google 的广告业务影响较大,所以其没有立即进行禁用,而是一直陆续修改一些小的策略来对三方 Cookie 进行限制,比如 SameSite 。
    SameSite 是 Chrome 51 版本为浏览器的 Cookie 新增的了一个属性, SameSite 阻止浏览器将此 Cookie 与跨站点请求一起发送。其主要目标是降低跨源信息泄漏的风险。同时也在一定程度上阻止了 CSRF 攻击。
    Chrome 也宣布,将在下个版本也就是 Chrome 83 版本,在访客模式下禁用三方 Cookie,在 2022 年全面禁用三方 Cookie,到时候,即使你能指定 SameSite 为 None 也没有意义,因为你已经无法写入第三方 Cookie 了。

    # 当三方 Cookie 被全面禁止
    前端日志异常
    智能广告推荐消失
    无法追踪转化率
    是好是坏?

    # 使用一方 Cookie 替代 三方 Cookie
    # 浏览器指纹
    `

  6. `
    samesite机制导致的cookie相关异常如何处理?

    1. 在地址栏中输入 chrome://flags/
    2. 页面内上方的搜索框输入:samesite
    3. 把【SameSite by default cookies、Enable removing SameSite=None cookies、Cookies without SameSite must be secure】三个栏目的右侧下拉选择为 “Disabled”,然后重启浏览器即可。
    `

  7. Mac 下chromium缺少Google API 密钥,因此 chromium的部分功能将无法使用
    https://blog.csdn.net/sinat_21302587/article/details/84960580

    set-up-chromium-keys.md
    https://gist.github.com/cvan/44a6d60457b20133191bd7b104f9dcc4
    `
    set 3 environment variables:

    On Windows: Launch cmd.exe and enter the following commands:

    setx GOOGLE_API_KEY your_key_goes_here
    setx GOOGLE_DEFAULT_CLIENT_ID your_client_id_goes_here
    setx GOOGLE_DEFAULT_CLIENT_SECRET your_client_secret_goes_here

    On Mac OS X / Linux: Plop these in your ~/.profile file:

    export GOOGLE_API_KEY=”your_key_goes_here”
    export GOOGLE_DEFAULT_CLIENT_ID=”your_client_id_goes_here”
    export GOOGLE_DEFAULT_CLIENT_SECRET=”your_client_secret_goes_here”
    `

  8. Some features of Chromium use Google APIs, and to access those APIs, either an API Key or a set of OAuth 2.0 tokens is required. Setting up API keys is optional. If you don’t do it, the specific APIs using Google services won’t work in your custom build, but all other features will run normally.
    http://www.chromium.org/developers/how-tos/api-keys
    `
    # Providing Keys at Build Time
    If you are building Chromium yourself, you can provide keys as part of your build configuration, that way they are always baked into your binary.

    Specify three variables in your args.gn file (which you can edit by running gn args out/your_out_dir_here)

    google_api_key = “your_api_key”
    google_default_client_id = “your_client_id”
    google_default_client_secret = “your_client_secret”

    # Providing Keys at Runtime

    If you prefer, you can build a Chromium binary (or use a pre-built Chromium binary) without API keys baked in, and instead provide them at runtime. To do so, set the environment variables GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET to your “API key”, “Client ID” and “Client secret” values respectively.
    `

  9. 第三方cookie马上就不让用了,互联网广告还怎么玩?
    https://mp.weixin.qq.com/s/futJHDkOCpYAA2O3WljX4w
    `
    Chrome Developer Summit 2020的一些话题挺有意思的,其中A more private way to measure ad conversions是关于互联网广告的,值得关注,这是互联网广告的未来方向。在第三方Cookie限制越来越多且很快就会被禁用的情况下,广告作为互联网最核心的商业模式之一,还怎么玩下去?

    互联网广告现在越来越精准了,我们在A站点看的东西,怎么就跑到B站点的广告里面去了?其中关键之一就是第三方cookie,广告巨头比如Google可以通过第三方cookie把我们在很多不同网站的行为给串联起来,你说它的广告能不准吗?想要理解这一点,不妨看一下基于cookie的广告是怎么做的。

    # 基于cookie的广告是怎么做
    * news.example是新闻站点,流量很高,靠互联网广告赚钱
    * shoes.example是卖鞋的购物网站,需要通过投放广告获取用户
    * adtech.example是广告服务商,shoes.example可以通过adtech.example在news.example投放广告
    * 用户在news.example站点看新闻,会加载adtech.example的广告JS脚本(用于展现广告、记录广告浏览和点击数据),点击广告就可以跳转到了shoes.example站点
    * 用户访问shoes.example的时候,也会加载adtech.example的JS脚本(用于记录下单数据)
    * adtech.example的JS脚本可以为每一个用户生成唯一的用户ID,保存到cookie中,并发送到adtech.example的服务器,通过唯一ID将用户在news.example的广告浏览、点击数据与用户在shoes.example下单数据合并分析,计算广告的转化率

    广告服务商adtech.example之所以可以计算广告转化率,原因在于它为每一个用户生成了唯一ID,并保存在cookie中。adtech.example的cookie对于news.example和shoes.example来说,都是第三方cookie(third party cookie,图中缩写为3P cookie)。

    在Chrome中,第三方cookie现在还是可以用的,只要cookie的SameSite属性设为None,同时设置Secure属性即可。

    但是,Chrome计划在2022年停止支持第三方Cookie,这就意味着广告服务商adtech.example无法再通过Cookie来追踪用户了。其他主流的浏览器,比如Safari 13.1已经禁止使用第三方cookie了,Firefox和Edge也在做类似的事情。所以,禁用第三方Cookie是迟早的事情,会比我们想象中快很多。

    # 没有cookie的广告是怎么做
    故事的主角没变:
    news.example是新闻站点,流量很高,靠互联网广告赚钱
    shoes.example是卖鞋的购物网站,需要通过投放广告获取用户
    adtech.example是广告服务商,shoes.example可以通过adtech.example在news.example投放广告

    区别在于,广告商不再使用cookie保存用户的唯一ID,没法通过cookie来把用户在news.example点击广告的行为与用户在adtech.example的下单行为关联起来了,那这广告转化率还怎么算?

    这时候Chrome就出来说了,你们别想什么数据都拿走了,我来决定给你什么数据,提出了Event Conversion Measurement API。
    * 用户在news.example站点看新闻,会加载adtech.example的广告JS脚本,因此可以看到shoes.example的广告,点击广告就可以跳转到了shoes.example站点,用户的点击行为会记录到浏览器,存在本地
    * 用户访问shoes.example的时候,用户的下单行为也会记录到浏览器
    * 根据adtech.example接入广告时配置的信息,浏览器可以把在news.example点击广告的行为与用户在adtech.example的下单行为关联起来,上报给广告服务商,这样广告服务商就可以计算转化率了
    * 浏览器在上报数据给广告服务商时,会进行一定的数据混淆,并且会有延时,这样可以进一步保护用户隐私。因为如果实时上报数据的话,广告服务商知道用户下单的准确时间,就能和广告主”串通”起来分析用户到底是谁。

    由于跨站点的用户行为的关联是浏览器做的,因此广告服务商所能获取的用户数据将局限于浏览器所做的限制,Chrome可以决定给哪些数据、是否给完全精准的数据、什么时候给数据。Chrome的代码是开源的,Event Conversion Measurement API也是一个开放的标准,我们也不用担心Chrome会故意给自己留什么后门。

    看起来一切都很完美,用户隐私得到了保护,news.example、shoes.example、adtech.example也都赚到了钱。

    但是,这事对adtech.example来说,还是有点难受,因为它没法获取全面的用户数据,也没法实时分析广告转化率了,也没法把用户在各个站点的用户行为串联起来了。用户隐私的保护确实增强了,但是互联网广告商的日子不太好过了,这也是合理并且也是趋势吧,现在的广告商们确实玩得有点过火了,搜集了太多用户数据。

    还有一个问题,Event Conversion Measurement API其实有点复杂的,只是我没有讲得特别细(大家估计也没兴趣),如果每一个浏览器都自己搞一套类似于Chrome的Event Conversion Measurement API,复杂度差不多,然后还不太一样,那也是一件很头疼的事情:(
    `

  10. 记一次Chrome更新带来的登录Cookie问题
    https://mp.weixin.qq.com/s/pT8EjkDxFDMO_9tunPIEVg
    `
    从v88升级到v89后,Chrome浏览器内置的schemeful-same-site规则默认值改为启用,导致跨协议也被认定为跨站(cross-site),cookies无法传递。

    临时解决方案:地址栏打开chrome://flags/#schemeful-same-site,将选项设置为Disabled。

    在Chrome 80版本,SameSite的默认值被改为Lax。

    # Same-Site 的概念 (eTLD+1 一般指的是sub domain)

    eTLD+1部分一致就可以称之为same-site。
    scheme和eTLD+1部分一致则被称为schemeful same-site

    # Schemeful Same-Site

    Schemeful Same-Site 是 same-site 的进阶版,通过协议+域名两个维度来定义,如果想深入了解下,你可以浏览这篇文章:Understanding ‘same-site’ and ‘same-origin’ 。

    这意味着 http://website.example 和https://website.example 相互之间是跨站(cross-site)的。

    如果你的网站已经全部使用HTTPS,那Schemeful Same-Site不会有任何影响,否则应该尽快升级到HTTPS。
    `
    Schemeful Same-Site
    https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html#rfc.section.3.3

    Understanding ‘same-site’ and ‘same-origin’
    https://web.dev/same-site-same-origin/#%22schemeful-same-site%22

  11. 如果不用第三方 Cookie,Google FLoC 会是更好的替代者吗?
    https://sspai.com/post/66056
    `
    # 从用户的角度来看:

    * FLoC 的目的还是追踪用户,以利于广告商精准投放广告。
    * 在总要被投放广告的情况下,从隐私保护角度,FLoC 确实比 Cookie 好。因为Cookie 是个人标识,FLoC 是群体标识,且通过加入随机性实现了差分隐私。
    * 目前浏览器会逐渐禁止第三方 Cookie,也有插件可以阻止第三方 Cookie。但是,目前还没有足够多且被证明有效的手段去禁止 FLoC。

    # 从广告平台的角度来看:

    * 相比于 Cookie,广告平台使用 FLoC 时能收集到的信息会大幅度减少。
    * 广告平台需要一段时间去测试,如何使用 FLoC 精准地投放广告。
    * FLoC 由 Google 主导,其他广告平台失去了使用自己第三方 Cookie 收集数据的能力,可能会导致 Google 在广告追踪市场一家独大。
    `

  12. 攻防启示:Chromium组件风险剖析与收敛
    https://mp.weixin.qq.com/s/f0aFLEKyABpYDobPN2b6tQ
    `
    目录
    • I.背景
    • II.浅析Chromium
    • 2.1 Chromium涉及哪些组件?
    • 2.1.1 渲染引擎
    • 2.1.2 浏览器内核
    • 2.2 Chromium的沙箱保护原理/机制
    • 2.2.1 为什么要引入沙箱?
    • 2.2.2 浏览器的哪些部分是运行在沙箱中的?
    • 2.2.3 Windows和Linux下沙箱实现的技术细节
    • 2.3 小结
    • III. Chromium漏洞攻击利用场景分析
    • 3.1 服务器端
    • 3.1.1 禁用沙盒的chromium headless应用
    • 3.1.2 浅议攻击方式
    • 3.2 客户端
    • 3.2.1 移动客户端
    • 3.2.2 桌面客户端
    • IV.风险收敛方案
    • 4.1 风险监测和评估
    • 4.1.1 风险情报
    • 4.1.2 风险评估
    • 4.1.3 风险检测
    • 4.1.3.1 黑盒测试
    • 4.1.3.2 静态代码扫描
    • 4.1.3.3 主机Agent采集
    • 4.2 风险修复
    • 4.2.1 通用修复方案
    • 方案1. 启用Sandbox
    • 方案2. 更新Chromium内核版本(后续维护成本极高)
    • 方案3. 客户端选择系统默认浏览器打开外链URL
    • 4.2.2 云原生时代下,针对Chrome组件容器化的风险修复指引
    • V.总结
    • VI.参考及引用
    • VII.团队介绍
    `

  13. chrome://flags/#reduce-user-agent-minor-version
    `
    #reduce-user-agent-minor-version
    Reduce the minor version in the User-Agent string
    Reduce the minor, build, and patch versions in the User-Agent string. The Chrome version in the User-Agent string will be reported as Chrome/.0.0.0. – Mac, Windows, Linux, ChromeOS, Android, Fuchsia, Lacros

    比如我当前的Chrome浏览器版本实际上是 Chrome/108.0.5359.94 ,但是在 navigator.userAgent (还有提供服务的后端看到的User-Agent请求头字段)中记录的是 Chrome/108.0.0.0 这个版本。
    `

    User-Agent Reduction deprecation trial
    https://developer.chrome.com/blog/user-agent-reduction-deprecation-trial/
    `
    Published on Thursday, February 24, 2022

    Starting from Chrome 101, the information available in the User-Agent (UA) string will be reduced using a phased approach. Sites that haven’t had time to migrate away from using the reduced User-Agent string and move toward User-Agent Client Hints can take part in a deprecation trial to continue receiving the full User-Agent string.

    The User-Agent HTTP request header
    The navigator.userAgent Javascript getter
    The navigator.platform Javascript getter
    The navigator.appVersion Javascript getter
    `

    Update on User-Agent String Reduction in Chrome
    https://blog.chromium.org/2021/05/update-on-user-agent-string-reduction.html
    `
    Wednesday, May 19, 2021
    `

  14. User-Agent Reduction
    https://www.akamai.com/blog/developers/user-agent-reduction
    `
    Chrome is rolling out changes to the browser’s User-Agent string that will affect how web servers, applications, and CDNs like Akamai gather information about the current user agent (such as the browser’s version, device, and platform information).

    # Timeline

    The Chrome team has published their guidance on the expected timeline for when these changes will be implemented.
    * Chrome 92 (July 2021): JavaScript developer warnings accessing .userAgent
    * Chrome 95–100: Sites can opt-in to frozen UA for testing
    * Chrome 100 (March 2022): Sites can opt-out of UA freezing (until May 2023)
    * Chrome 101 (April 2022): Version reduced to NN.0.0.0
    * Chrome 107 (October 2022): Desktop platform frozen (hardcoded)
    * We’re here! Desktop platform will be frozen with Chrome 107 on Oct 25
    * Chrome 110 (February 2023): Mobile platform frozen (hardcoded)
    * Chrome 113 (May 2023): Sites can no-longer opt-out of UA deprecation

    We expect the Chrome 107 and 110 changes (in October 2022 and February 2023) that freeze the platform to have the largest effect on Akamai products, as a misleading platform string could affect logic flows.

    Although other user agents (such as Safari and Firefox) have not announced their intention to reduce the User-Agent string in the exact same way, we would not be surprised to see similar changes at some point in the future.
    `

回复 hi 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注