有没有人碰到最新的 chrome 把开发环境自定义的.dev 域名都跳 https 了
zjsxwc · zjsxwc · 2017-12-11 10:32:54 +08:00 · 11429 次点击这是一个创建于 2547 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天来上班, 用 mac chrome 打开我本机开发域名 http://my.dev 他都强制跳了 https://my.dev
换 firefox 和 opera 却都没这问题
第 1 条附言 · 2017-12-12 09:14:41 +08:00
*.dev 之类域名在 chrome 里是神圣不可, 就算是在内网也不能自己改着玩
 |
2
raysonx 2017-12-11 10:36:53 +08:00  2
.dev 是 gTLD，有效的公网顶级域名，所有权在 Google。Google 自然有权限对这个域名下的所有子域名设置 HSTS Preload.
|
 |
3
msg7086 2017-12-11 10:38:34 +08:00 2
dev 和 foo 顶级后缀现在归 Google 公司了……
|
 |
4
zjsxwc OP 妈的, 改用 opera 了
|
 |
5
wunonglin 2017-12-11 10:42:14 +08:00
为什么不用 dev.XXXXX.XXX 啊？
|
|
6
raysonx 2017-12-11 10:43:01 +08:00 3
作为一个程序员，要时刻按照规范行事。一个域名进入 HSTS Preload List 之后，其他浏览器厂商后续也有可能跟进。把.dev 挪为私用就和把 11.0.0.0/8 挪为内网 IP 一样，既然做了就是承担风险。.dev 域名是 Google,所有权不在你。
|
 |
7
sobigfish 2017-12-11 10:43:52 +08:00
|
|
8
raysonx 2017-12-11 10:46:35 +08:00 2
不想用自己的域名的话，可以用.test。这个域名是被 RFC 规定保留的。
|
|
9
zjsxwc OP .dev 后缀的域名我们开发环境里用到的地方很多, 而且不单单是只是我一个人的开发环境 hosts, 各种配置脚本里也存在, 换后缀的话, 工作量有点大的, 比如 docker 容器也要重新 build
. |
 |
10
mooncakejs 2017-12-11 11:21:23 +08:00 4
@raysonx 这里我觉得谷歌跨界了：浏览器的权限范围在哪里？ 如果浏览器的定义仅仅是浏览器，那么应该老老实实遵守协议， 请求 dns，http 请求，如果有 hsts header 或者缓存，那么请求 https， 如果在一个私有的网络环境（比如纯内网），浏览器也应该遵守 http 协议。
如果你认为 chrome 不仅仅是一个浏览器，而是谷歌实现霸权的工具，无可辩驳。 题外话： 互联网“已经”变得越来越不开放。 |
 |
11
Moker 2017-12-11 11:23:52 +08:00
chrome 62.0.3202.94 目前没发现此问题
|
 |
12
wwqgtxx 2017-12-11 11:37:13 +08:00 via iPhone
@mooncakejs 从所有权上说.dev 现在已经是 google 的了，那么他在自己的产品中把自己的域名加入 hsts 有什么问题。
chrome 本来就是商业产品，人家的许可证上说有为了纯私有网络服务了么？ 至于浏览器不遵守标准，当初 chrome 支持 spdy，然后支持 quic，按照你的说法都是不老实的行为喽 |
|
13
mooncakejs 2017-12-11 11:48:37 +08:00 via iPhone
@wwqgtxx 支持更多的协议当然没问题，但是不能不兼容现有的协议，这事严重点说叫不兼容 http 协议。
谷歌当然可以这么做，只不过不支持 HTML5 的 IE 骂得，现在连 http 协议都有问题的 chrome 说不得？ |
|
14
msg7086 2017-12-11 11:51:20 +08:00
@mooncakejs HSTS Preload 什么时候变成不兼容 HTTP 协议了？
|
 |
15
zuohuadong 2017-12-11 11:52:29 +08:00
@mooncakejs hsts 的目的不是霸权，而是因为太多的域名劫持，https 本身可以防止中间人攻击 和 域名劫持的现象，所以推荐都使用 https。 其次，谷歌在自己域名加入 hsts，因为 dev 本来就是谷歌的，无可厚非
|
|
16
zuohuadong 2017-12-11 11:54:17 +08:00
@msg7086 他估计还没搞懂 为什么会有 https 为什么会有 hsts ～
|
 |
17
xderam 2017-12-11 11:57:14 +08:00
https://www.iana.org/domains/root/db
建议了解下 new gTLD，我也是刚刚才知道，虽然从 2013 年就开始有了。 另外： 从个人来说，了解其争议的流程和制度比单纯抱怨更有意义。 从单位来说，了解申请流程和对自己的保护比眼馋人家注册这么好的域名更有意义。 |
|
18
mooncakejs 2017-12-11 12:07:10 +08:00 via iPhone
|
|
19
mooncakejs 2017-12-11 12:10:19 +08:00 via iPhone
@zuohuadong 如果是为了安全，这和 360 的绿标认证有什么区别？
|
|
20
xderam 2017-12-11 12:13:25 +08:00
不过 g 家这个做法有点类似于国内推行普通话标准的感觉了。
争论起来估计又是地域战争。所以大家了解下 hsts RFC gTLD 啥的科普下就 ok 了，貌似真没啥好坏之分。 PS 我个人怎么也不太喜欢 new gTLD 的那个做法呢，看到好多国内的域名贩子注册公司开始了这项生意了。 |
|
21
zuohuadong 2017-12-11 12:14:12 +08:00
@mooncakejs 你知道谷歌搞这玩意目的是什么么？
用户点击 www.abc.com 会直接访问 http://www.abc.com 这时候不管你有没有 https，在 http 这一层就给你劫持然后强制或者非强制跳转了。 所以才有了 hsts 这玩意，访问一次 https，一定时间内只能访问 https。 但是首次访问的用户怎么办？ 他们还是会访问到 http，所以就又有了 preload list，这些域名，用户只要用 chrome firefox EDGE 这些，就直接访问 https ～ 虽然不是 w3c 标准，但目的还是为了防止劫持和中间人攻击 |
|
22
zuohuadong 2017-12-11 12:15:47 +08:00
@mooncakejs 360 绿标没有真正安全，说白了只能证明这个域名是“官方”的，但面对中间人攻击毫无意义～
此外，360 绿标也好，腾讯绿标也好，真正的目的只是为了收钱～ |
 |
23
skylancer 2017-12-11 12:21:40 +08:00 3
@mooncakejs 你先去了解一下这两者分别是什么再来说这话比较好，不是我说你，你是真的菜
|
|
25
mooncakejs 2017-12-11 12:31:47 +08:00 via iPhone
@skylancer 区别是什么，我已经发出来了，一个是 RFC 一个是浏览器厂商标准，看不明白吗？
|
|
26
skylancer 2017-12-11 12:33:43 +08:00
@mooncakejs 呵呵 还嘴硬，算了我继续看戏
|
|
27
mooncakejs 2017-12-11 12:36:37 +08:00 via iPhone
@zuohuadong 防劫持我懂，为了安全我也懂。但是一个标准还没定下来就粗暴的
|
|
28
zuohuadong 2017-12-11 12:45:57 +08:00
@mooncakejs 谷歌这个公司整体比较激进，也确实有很多东西是先于标准的～ 但是目的是好的
|
|
29
mooncakejs 2017-12-11 12:59:51 +08:00 via iPhone
@skylancer 你哪来的优越感？说白了是看热闹不嫌事大。标准和功能是两回事。
@zuohuadong preload list 也只是在解决信任问题上更近了一步，而不是彻底解决。如果谷歌真的纯粹为了安全，那他为什么不把内置根证书和 preload list 权限交给操作系统上实现。毕竟浏览器下载过程中也可能中间人。 |
 |
30
mengzhuo 2017-12-11 13:00:49 +08:00 via iPhone
Google do evils
|
 |
31
jk2K 2017-12-11 13:16:15 +08:00
为了方便, 只能换 .test 域名了, 要不然大家可以试试 https://github.com/typicode/hotel , 这个可以给 .dev 域名生成自定义证书
|
 |
32
lepig 2017-12-11 14:27:21 +08:00
chrome 这是在作死吗？ dev 和 app 好歹给留一个呀 不喜欢 test
|
 |
33
whx20202 2017-12-11 14:36:47 +08:00
@lepig 老哥，HSTS 和 preload 我都知道，但是请问一下 为什么会用 dev app 这些域名啊，还有这些域名不用购买吗？
|
 |
36
yuxuan 2017-12-11 14:59:45 +08:00
没用过这些后缀 感觉自己不是程序员。。。
|
 |
38
audoe 2017-12-11 15:14:42 +08:00
@mooncakejs 我的浏览器，我的域名，我就有权做，你不认同，可以不用的。
|
|
39
msg7086 2017-12-11 15:19:41 +08:00 7
@mooncakejs Preload 是域名所有者提交给各大浏览器的。域名所有者当然对域名有权利。
你要说 RFC 规范的话，规范上提到的是对于 UA 已知的 HSTS 策略。Preload 就是一种分发 UA 已知 HSTS 策略的手段，因为谷歌公司已经收到域名所有者明确的要求，并且审核过这个域名确实有 HSTS 策略，才会把这个域名加入 Preload 中。申请的是域名所有者，策略是已经存在于世界上的，谷歌并没有凭空创造任何数据，只是「收集」了世界上已经有的东西，并且提前让 UA 也就是浏览器知道罢了。 反倒是在本地把 *.dev 写入 hosts，实质上是劫持了原本 Google 所拥有的域名。劫持他人的域名结果无法正常访问难道是域名所有者的错？那这么说的话，访问 google.com 不应该强制 HTTPS 而应该被 DNS 劫持去 baidu 才是正确的做法吗？ |
 |
40
BearD01001 2017-12-11 15:32:03 +08:00
使用 .local 的路过，静静看你们撕 0.0
|
|
41
mooncakejs 2017-12-11 15:35:27 +08:00 via iPhone 1
@audoe 大哥，这个世界如果不讲标准乱来，还要 w3c，反垄断组织干嘛，微软是不是也可以说我的系统，不能装其它浏览器？
|
|
42
mooncakejs 2017-12-11 15:55:12 +08:00 via iPhone
@msg7086 这就涉及到大家怎么理解互联网了，从 http 等协议看，互联网是一个去中心化的组织结构，包括域名 DNS 解等，私网公网表现不一样没有协议本身的约束。
包括浏览器，浏览器也有不同的理解，本身是一个工具还是一个裁判？ hsts 协议只规定了怎么缓存这个域名，preload list 就是浏览器本身的野心，它跳过了通过 http 协议的方式决定了访问方式，如果更进一步，它还可以跳过 DNS 请求，因为 IP 地址也可以通过 preload list 进入浏览器，甚至还有性能上的提高。 包括去年的证书事件，虽然谷歌的出发点很伟光正，但是决定是否不信任证书的权限是属于一个浏览器还是属于操作系统，它的决定权属于一个组织结构还是仅仅一个浏览器公司？如果谷歌真的那么无私，那么这个权限交给操作系统显然好过浏览器本身，因为如果假定第一个 http 请求就会被劫持，浏览器下载过程也是可能被劫持的，操作系统却是由比较可靠的人或者结构 /媒介分发的。 |
|
43
msg7086 2017-12-11 16:10:12 +08:00
@mooncakejs 是这样，但是 Preload 必须要域名拥有者申请才能加入，所以最终是否植入用户电脑，是由域名所有者决定的，谷歌从浏览器的角度没有任何权利去擅自决定加入哪些域名。这次 dev 和 foo 域名加入 Preload，开源项目 Chromium 上源代码签入时间是 9 月 15 日，生效（推送到 GA ）是 12 月，中间整整 3 个月的公示期。一个全世界盯着的开源项目，3 个月的公示期，你说决定权完全在谷歌，我觉得这报道有偏差。
浏览器下载过程可能被劫持 —— 你是怎么下载的呢？如果是使用任何一个其他支持 HSTS Preload 的浏览器，那自然不会被劫持。如果不是，那当然怎么都会被劫持，甚至你下载的可能都不是 Chrome。这恰恰说明了 Preload 的重要性，大家都用 Preload，就能保证从头开始就不被骗。 交给操作系统也没有那么简单。操作系统安装盘下载的时候就不会被劫持了吗？桥洞下买碟就不会买到拍黄片吗？ |
 |
44
leetom 2017-12-11 16:16:56 +08:00 1
|
|
45
msg7086 2017-12-11 16:18:30 +08:00 1
安全本来就是个很复杂的话题。安全性和自由度是对立的。安全意味着更多审计，更多管控，复杂的机制，可能会不兼容旧版的网站（比如 SSLv3 ），可能会对不规范使用网络产生影响（比如 hosts 写入不属于自己的域名来劫持 IP ）。要自由则意味着更容易被人搞事（能 hosts 劫持就能 DNS 污染，能 HTTP 就能 MITM 等等）。对于普通用户来说，安全性比自由度更重要。
说野心的话，操作系统内置 Preload 也可以看成是野心呢。 |
|
46
mooncakejs 2017-12-11 16:32:54 +08:00 via iPhone
@msg7086 系统的安装者比使用者更专业。另外对于安全来说，其实商业 /企业客户更在意。preload 安全的前提是第一个浏览器就已经内置了，那我可以理解成，还是要系统内置。那既然系统已经内置了，为什么再搞一次。
同时又带来了一个新的问题，域名所有者的权益与内网的权益冲突，在一个机构或者说公司，其实有权限定义乃至劫持任意一个域名的地址与访问方式（内置证书，DNS,代理等），这是互联网本身所设计的。当然，也可以说 chrome 不是一个内网环境下推荐 /适合的浏览器。 当然说再多也没用，毕竟这个社会 渠道为王 。谁更靠近用户，更有底气乱来。 |
|
47
mooncakejs 2017-12-11 16:34:17 +08:00 via iPhone
@leetom 做不做恶另说，从这件事看来，谷歌不是一个很好的商业合作伙伴。
|
|
48
mooncakejs 2017-12-11 16:41:16 +08:00 via iPhone
@msg7086 操作系统本身就有预载证书，但是他把更好的权限交给了管理员，哪怕是你在 windows 的 hosts 里，把 Microsoft 的域名 IP 改了，它也不会来个 preload。
当然最近在安全形式下，苹果谷歌的系统都越来越封闭，以至于手机的拥有者，都不能修改手机的选项了，我的理解是开互联网倒车。 但是作为给最终用户的终端，为了安全也能理解。 只是 chrome 是 w3c 标准的先行者，也是个开发网页的常用工具，也这么搞(甚至没有关闭选项) ，有点难以理解。 |
|
50
msg7086 2017-12-11 16:53:23 +08:00 2
@mooncakejs 系统内置有个很大的问题，更新不及时。比如谷歌 9 月份要植入新买的域名到 Preload，那到什么时候才会植入系统呢？更不说 Win 7 8 8.1 用户已经永远失去更新能力了。
其次，比如 Linux，刚开始是没有浏览器的，你要装第一个，那第一个浏览器从系统 Repo 中安装的时候，是通过 GPG 校验确保安全的。GPG 校验、应用程序签名校验、根 CA，这些是可以由操作系统内置的，因为他们三五年，或者发行新版本时才会改变。而 HSTS 时常会有新域名加入，靠操作系统的更新是跟不上变化的。所以才有现在这样的链式认证，操作系统认证浏览器的合法性，而浏览器认证网站的合法性。Windows 下的话，也应该是 Edge 内置而不是 Windows 10 内置才对。 至于域名所有者和内网的权益冲突，这就见仁见智了。毕竟通用浏览器是服务于公网的，不可能为内网定制，而公网上被保留的域名后缀就那么几个（应该就 .test .invalid 之类的吧），剩下的都不应该随便使用（不是不允许，而是后果自负）。我前面去搜了一下别人的看法，一般都是推荐购买一个便宜的域名然后放在内网用，而不是劫持不存在的域名。也有人在推 .localhost 后缀 RFC 草案，把整个后缀都自动路由给回环网络。另外还有一些推荐用 .internal，虽然也是不存在的域名，但是至少不会被人随便买掉。 总之这个行为本来就不符合标准，不符合标准的行为就只能后果自负。我司现在内网用的是 公司名.int ，万一以后真有人注册了这域名，那我们也真的就只能再换了。 |
 |
52
yxn1910 2017-12-11 17:32:19 +08:00
推荐一个顶级域名：.run
今天把环境里的.dev 全部改成这个了。 |
|
53
wwqgtxx 2017-12-11 19:27:04 +08:00
@mooncakejs 说到底 google 开发 chrome 本来就是为了让你更好的用 google 提供的网页服务，至于你说的内网需求，这可能根本不在人家开发者考虑的范围之列
另外一个 preload 流氓的问题，那么 firefox 自己集成一套根证书而不用操作系统自带的根证书是不是也是耍流氓？ |
 |
54
HowardMei 2017-12-11 19:34:41 +08:00
也是醉了，我也得去改。。。
|
|
56
mooncakejs 2017-12-11 19:38:04 +08:00 via iPhone 1
@wwqgtxx 你说得对，谷歌压根不在乎这些需求。我只是认为互联网越来越不开放。
|
 |
57
azh7138m 2017-12-11 19:48:01 +08:00
|
 |
58
codehz 2017-12-11 20:06:04 +08:00 via Android 1
@mooncakejs 讲道理的话，标准不就是流氓们互相协商出来的吗。。。hsts preload 只是没成文标准而已，但是各大流氓已经遵守了(大家都有 preload，只是激进程度不一样)，那就是事实标准
|
 |
59
ysc3839 2017-12-11 20:45:58 +08:00 via Android
浏览器标准不代表就是坏的。看看
|
|
60
ysc3839 2017-12-11 20:47:35 +08:00 via Android
|
|
61
mooncakejs 2017-12-11 20:59:50 +08:00 via iPhone
@codehz 成文的标准一般会有比较好的兼容方案，即使是这种看起来貌似没错的 dev 后缀，都会有温和一点的方案。 比如巨硬至今还兼容不少 bug
|
 |
62
ColinZeb 2017-12-11 21:45:16 +08:00 via iPhone
@mooncakejs 巨硬的做法值得鼓励？十几年前的垃圾 api 命名还留着。
|
 |
63
realpg 2017-12-11 22:06:02 +08:00
本地测试从来不用公网上归属权不属于自己的域名……
还得做 host |
|
66
wwqgtxx 2017-12-11 22:55:07 +08:00
@breeswish 他这逻辑就是好比对自己的邻居说你不允许锁门，这样我就看不到你家人在干嘛了一样，至于为什么，我之前每天都能看见习惯了，现在你不给我看了就是霸权主义
|
 |
67
pengbo37877 2017-12-11 23:03:49 +08:00
.app 的后缀也会强制 https
|
|
68
mooncakejs 2017-12-11 23:48:32 +08:00 via iPhone
@ColinZeb 那怎么办，学谷歌两三年重新造轮子？仔细想想，仔细想想，谷歌有长命一点的生态吗？ Android 用的还是 JAVA JAVA 兼容到现在还保持着古老的设计与 API
|
|
69
msg7086 2017-12-12 00:51:19 +08:00 1
@mooncakejs 一个完全开源的软件能叫做越来越不开放吗？
dev 域名和其他域名并没有什么区别，都是一开始没人用，后来突然有一天有人买了下来，成为了他的资产，然后他来处分之。 如果你以前天天用 yahoo.com 做本地开发，突然有一天 Chrome 内置了雅虎的 HSTS，你也要怪 Google 不开放吗？如果你以前嫌好玩，天天用 sb.sb 做本地开发，突然有一天秀峰叔买下了这个域名并 Preload，你也要怪 Google 不开放吗？ 开放不开放又不是看你能不能对不属于自己的资源为所欲为的…… 内网里可以随便用的资源，是内网 IP、LL IP 还有 LO IP。 你可以随便用 172.17.123.45 ，fddf::dead，169.254.32.1，或者 127.8.9.10 。 当然，谷歌并没有强迫你遵守他的规则。源代码 Pull 下来，HSTS 一关，编译一下，黑喂狗。 |
 |
70
Tink 2017-12-12 01:32:04 +08:00 via iPhone
preload 确实是个流氓，通过不合理的方式劫持用户使用 https，这点很不合适。
|
|
71
mooncakejs 2017-12-12 08:27:44 +08:00 via iPhone
@msg7086 开放不等于开源。裹挟用户就不算开放，实现 hsts preload 的方法很多，搞个不兼容的方案，再自己造个闸门也能叫开放。再加上把 http 标记成不安全，自己搞个 hsts preload 这是好生意。
|
 |
72
stzz 2017-12-12 09:09:09 +08:00 via Android
没理解逻辑，就是我可以劫持人家域名内网玩，人家修正了就是不开放？
|
 |
73
AlphaTr 2017-12-12 09:29:03 +08:00
劫持域名说得这么理直气壮。。
|
 |
74
zpf124 2017-12-12 09:35:35 +08:00
等待其他几个不那么激进的浏览器也慢慢跟进了 hsts preload 列表看各位是不是所有浏览器一起骂。
喷人点都喷不对，你要喷也该喷 google 为什么要买 app 和 dev 的域名。 |
|
75
zpf124 2017-12-12 09:40:28 +08:00
@Tink 添加到 preload 列表需要 验证域名所有者的，可以保证进入这个列表的都是域名所有者自己确认的。
方式不合理，那合理的方式应该是怎么样的？让用户自己选择要不要 https ？ 那 hsts 有什么用？ 怎么防止 http 中间人？ |
|
76
skylancer 2017-12-12 11:00:20 +08:00
我搜了下某人的帖子
真的呵呵 |
 |
77
Yangxu 2017-12-12 14:41:31 +08:00
@pengbo37877 刚好碰到 真是 今天突然不能用了。。
|
|
78
Yangxu 2017-12-12 14:49:01 +08:00
个人认为内网内部使用，做域名劫持并没有什么问题。 我没有开放出去 就没有影响你的盈利。
就像一个明星的照片 我拿你的照片放在我的全国电视广告上是侵权，我放到自己钱包里不能这样说吧（除非偷拍或者明星本人真的介意。） 至于改 hsts，浏览器强制使用 hsts 确实是他的权利，但是别人也有评论这种做法的权利。 （上面给别人戴帽子，目的不是来讨论的不用回复，先谢谢） |
 |
81
gclove 2017-12-12 18:51:13 +08:00
劫持域名还理直气壮。。。
本地也是可以配置 ssl 证书的啊. 又不是只能裸奔 |
 |
82
jasontse 2017-12-12 19:03:45 +08:00 via iPad
真好笑，人家自己的东西不能做主要你来指手画脚。
|
|
83
gclove 2017-12-12 19:31:20 +08:00
顶 #81 楼
3 个方法, 1. 换一个域名 2. nginx 反代 3. 增加 ssl 证书 |
 |
84
8qwe24657913 2017-12-12 19:37:39 +08:00 via Android
如果你把 www.baidu.com 指向的主机改了，百度有 hsts，锅也要百度背喽？
|
|
85
azh7138m 2017-12-12 19:44:17 +08:00
@leetom 老哥，这不一样，当初行政手段直接回收了多少 cn 域名，Google 是我不喜欢我可以不用，但郭嘉老这么玩，谁也抗不住啊
|
|
86
zuohuadong 2017-12-13 11:01:53 +08:00
|
|
87
zuohuadong 2017-12-13 11:05:14 +08:00
@mooncakejs 软件劫持的可能性很小，最起码目前来说我们下载的软件都是官方的～
操作系统更新频率请参考 XP 和 IE， 维护麻烦不说，那么多用户你都让升级操作系统？ 意义不大 。 而且不是所有操作系统都需要 浏览器～ |
|
88
mooncakejs 2017-12-13 13:22:15 +08:00
@zuohuadong 官方下载链接就不能劫持了？
|
|
89
zuohuadong 2017-12-13 14:47:04 +08:00
@mooncakejs 可以是可以，但现实是基本上都没被劫持～ 系统下载也能被劫持呢
|
|
90
mooncakejs 2017-12-13 14:57:38 +08:00
@zuohuadong 理论上来说，因为下载系统前就必须有系统，所以系统内置 list 肯定比浏览器更安全。什么更新啊都不是问题，只要按照信任链来，开放给权限，让浏览器也可以更新系统级的列表，这也没问题，但是前几年谷歌没有操作系统，只有浏览器，所以他选择让浏览器实现。
|
 |
91
ety001 2017-12-14 15:16:12 +08:00
谷歌在 v63 的这一强制改动的确是造成了大多数程序员的不便，如果受影响的程序员在改域名的时候，除了骂谷歌大爷，增加自己工作量，还能干啥？本来就是个牢骚贴，硬生生的开始撕逼。。。
|
|
92
ety001 2017-12-14 15:16:43 +08:00
通过撕逼来秀自己的知识量渊博么？
|
|
93
zuohuadong 2017-12-14 18:57:48 +08:00
@mooncakejs 来，吊销个证书试试～～ 另外，系统被二次修改的也很多，各种 ghost 版， 还有希望继续用 xp 的 ，都是不可控的。
|
|
94
mooncakejs 2017-12-15 10:13:26 +08:00 via iPhone
@zuohuadong 会用 ghost 之类的机器会用原生 chrome 的有多少。 更注重安全的企业用户反而一般有专业的 IT 支持。
|
|
95
zuohuadong 2017-12-15 10:45:40 +08:00
@mooncakejs 总之是没有意义的，也不会有企业推动这样的事情，跟系统绑定结果会跟 IE 系列一样
|
|
96
mooncakejs 2017-12-15 11:12:41 +08:00 via iPhone
@zuohuadong 所以现在谷歌在做同样的事情，他一直有做浏览器系统的想法，你觉得微软做法是个好的合作伙伴还是谷歌是？
|
 |
97
solaro 2017-12-23 23:08:09 +08:00
mark，今天踩坑了
|
 |
98
Fishdrowned 2017-12-27 22:10:18 +08:00
|
Select Language