大家了解 为什么 PWA 还有 web assembly 之类的技术，为什么不开放文件和网络权限吗？

[maomaomao001]

PWA 真的是好东西啊，可以离线运行， 感觉明明可以给他文件，网络（可跨域不限制的）权限 （或者至少让用户选择给不给这些权限）的话，感觉会非常强大啊， 再放开 https 的限制 （比如像 chrome 插件那样可以打包本地安装使用）， 完全可以当 native app 的用的呀。 比如各种小工具

还有 web assembly 也是，性能那么强大了， 结果还是没有办法 操作文件 和 发起跨域网络请求的能力，这个么多性能用来干嘛

其实提这个问题还有一个原因就是， 感觉现在开发跨平台桌面应用太费劲了
1.兼容性好像不好控制
2.还有体积问题，electron 有太大， 比较底层的 Qt，C++ 之类的开发方式又相对比较困难
3.而且，如果只是做小工具的话，我连 ui 框架都不会去用，直接 用 web 原生 空间，一个小工具几 kb 的 html 就完成了，这本该多么美好的最佳夸平台方案呀

或者换个角度去想这么个问题
如果浏览器提供了这些功能的话， 成千上万的装有浏览器的系统就能重复利用浏览器本身的资源啊

- 相对不错的 UI
- 不弱于原生的能力

要不然，像 electron 那种方案，我感觉是对现有资源的极大浪费

[GM]

放开权限的话，不就成了一个随便下载安装任意功能的软件吗？黑客表示我可喜欢这样的东西了。

[maomaomao001]

与其让 Tencent 之类的用各种小程序破坏生态 ， 为什么谷歌不大力发展推广 PWA 呢 ，想不通

[maomaomao001]

@GM 最简单的一个小工具类程序，
从 A 网站请求一个页面，然后把其中某个标签的内容保存为文件


当然，用户使用的过程中，浏览器可以让用户选择给或者不给这个权限（甚至可以选择给这个 PWA app 一个沙盒（假）环境）啊 ， 这样不是可以让很大一部分 native app 不依赖操作系统了呀，多好的事情，谷歌为何不考虑呢，想不通

[zeromake]

因为小程序有审核啊，pwa 没有审核

[GM]

@maomaomao001 你给了它一个沙盒环境，那在这个沙盒环境里能不能访问到真实的功能，比如启动摄像头？如果不能的话，那给你所有权限又有什么意义，反正你无法使用，如果能，那还叫沙盒？

至于让用户选择，想太多。大部分用户都只会点确定、同意。

[maomaomao001]

@GM 摄像头我不知道有没有方案，但是已知的很多 native app 的权限，都可以做沙盒环境啊，
全新的沙盒文件空间， 伪定位坐标 ，
通讯录，系统设置，几乎所有东西都可以有沙盒环境
至于 摄像头的话，如果我设计它的沙盒环境的话
简单一点就始终 给 app 一个静态图 ，或者可以让用户选择图片

我明明感觉这个东西市场巨大，不明白巨头们为什么不这样做

[maomaomao001]

而且这样的话，微软做好了它的 app，没有任何人能限制它不能运行在 chrome book 上 或者其他任何 w3c 标准的浏览器上吧 ，这不是一个非常美好的打破垄断的事情的吗

[learnshare]

PWA 依然是网页，网页依然需要可靠的安全策略，开放意味着滥用。
另外文件相关的 API 快进入正式版本了 https://developers.google.com/web/updates/2019/10/nic78#native-file-system

主流浏览器和操作系统对 PWA 的支持都算不错了，只是国内应用开发者和用户都选择了小程序

[optional]

pwa 比小程序能实现的功能还差一些，，而且小程序之类除了带来审核等成本，也带来了微信生态内的分享之类的好处。

[maomaomao001]

@learnshare 这个安全策略的选择权给用户多好呀

[ClarkAbe]

@maomaomao001 #3 可以用万能的 img 标签啊

[GM]

@maomaomao001 都是假权限，拿到的都是假数据，那有什么意义？
如果想拿真数据，那就要经过用户同意，这又回到刚才说的话了：大部分用户都只会点确定、同意，根本不看提示框内容。

[ClericPy]

小程序什么的...
别拿 Google 和 Tencent 比好么

[maomaomao001]

@ClericPy 你确定你看完内容了吗？（纯好奇)

[mingmeng]

@maomaomao001 不是所有用户都有识别的能力呀，楼上老哥说得对，很多用户是不会分辨的，小程序能做起来生态是因为微信自己的审核机制和微信自己有动力去推动移动端的小程序生态来带给自己利益。首先如果要做一个良好的生态，理想环境是 app store 这种，如果没有审核之类的，这种能力一旦放开滥用，和之前 win32 的生态就没什么区别了，也是隐私侵犯什么的案例满天飞了。你可以拿 win32 类比一下，以前很多用户也是遇到软件就装，导致微软现在在 win32 问题上还很头疼，想全面推进 uwp 压根不方便。

[maomaomao001]

@ClarkAbe 跨域 post 呢，限制这么奇怪为什么不开放呢

[mingmeng]

楼主想法没错，但是现实中很多问题确实不是技术造成的，PWA 应该会一步步推进，但是浏览器应该也会慢慢的找角度来解决之前所遇到的这些问题

[maomaomao001]

@mingmeng 可是这么对比的话， 安卓 ios 应用用户 ye 可以无脑点同意吧。

对对 ，win 32 那种生态，自由，方便，应用市场根本没法垄断（或者组织竞争对手上架产品） ， 我觉得只要做好隐私保护（也就是各种沙盒环境，1.解决了不给权限不能用的问题 2.又可以让 app 开发上架难度降低到最低）

ios 那个环境也太费劲了，自己给自己开发小工具安装好像都很费劲的样子

[taxiaohaohhh]

我最近也从小程序迁移到 PWA 上面了，期待后面的发展

[maomaomao001]

当然，也不一定非要吧所有 native 的功能实现一遍 （这样浏览器不就变成差不多操作系统一样了吗）

我觉得最基础就还是，只要把文件系统，和网络系统做好的话，真的可以替换掉很多原生 app 了，

[maomaomao001]

@taxiaohaohhh 我觉得 国内厂商搞的小程序侵入型太高了，直接把 web 标准扔了，自己搞一套还那么封闭，
明明给个自己的 SDK （用来实现微信一键登录，用户基本信息之类的）明明就可以的

[Mutoo]

开放的安全必须折中考虑，早期与 Web 相近的 Flash 有更开放的 API , 但即使如此，如果你要联网访问 flash player 就不允许你读本地文件。如果你要读本地文件，它就不允许联网访问。为什么要这样设计？因为怕恶意程序在你不知情的情况下随便将你的文件发到网络上去。毕竟 flash 可以在互联网上随意发布，没有一个第三方机构来审核它。

此外跨域访问一样是安全性考虑，防止了未授权访问的可能。减少的跨站请求伪造的危害。

[luob]

google：别催了别催了别催了别催了在做了在做了在做了在做了

[maomaomao001]

@Mutoo 我现在遇到的场景就很奇怪
功能很简单: 程序访问 A 接口 POST （有跨域限制）,然后拿到的数据存成文件保存。

可是这个用原生开发，发网络请求没有限制 （ post 随便发，app 不会拦截去拦截）， 文件随便写 (当然用户得授权)

所以我是真的没看懂他们这么限制住的意义

[maomaomao001]

而且，我记得以前 Android 写个 hello word 才 4，5kb 的，现在好像 hello word 都快 1mb 的样子，不知道中间发生了什么

[jin5354]

路要一步一步走，PWA 正在推进更多的 API，详见 Project fugu
https://qcon.infoq.cn/2019/shanghai/presentation/2079
包括本地文件访问，NFC 访问，通讯录访问等等逐渐落地中，据说本地文件访问 chrome M78 开始测试，就在 10 月发布

[ClericPy]

@maomaomao001
反正从本世纪初到现在, 腾讯的文化一直透漏着一种商人的精明, 恨不得把所有东西都捞到自己怀里来, 藏着掖着不给别人用; Google 的态度反而是有什么好东西, 就做到精而美, 然后开放出去, 恨不得所有人都在用它的东西. 二者目的性明确, 感觉不太适合拿来比
微信和 QQ 用户量那么大, 并不是做的太好, 而是早期流量绑架了, 现在那么多教张小龙做产品的, 张小龙又不是真傻, 很多别人眼里的缺点, 反而是刻意为之的选择.
小程序确实解决了很大程度上原始 web app 的认证方面的短板, 而且在生活中帮助也很大, 但是它的体验实在是难受...

你标题提的, 前几年还真好奇过, 不知道为什么这么优秀的东西普及率那么低, 普及速度那么慢, 现在看来, 可能是红利不够诱人吧. 不在这个圈子逛, 对国外前沿是什么态度也不了解, 进来灌水纯粹就是觉得什么东西不是腾讯做了, Google 就值得搞...

[whileFalse]

因为 PWA 构建在 JS 上，web assembly 是 JS 的高性能版。

JS 不能干什么，PWA 和 web assembly 就不能干什么。

[sujin190]

web 是安全与便利性妥协的完美，完全读取文件权限如果只能读写自己保存的，那么现在的 localstore、db 不好用么，如果能随意读写谁还敢随意打开你的网页，网络也是相似的，直接拥有底层网络权限，你这跨域限制还有个毛用，你想象一下你打开一下百度，就给你自动发了篇微博，图片用的还是你家里 nas 保存的私房照，这样的 web 太优秀了吧，各种硬件更不用说了吧

沙箱什么的太不认真了吧，如果拥有底层完整权限就不可能有沙箱，让用户授权确认就更扯了，且不说各种手残的，还有各种伪装欺骗点击的等等等，不要把世界想的太善良，而且不能说用户点了有损失就怪用户吧，你造了个手雷给一个普通用户弄炸了怪用户手残不适合吧

web 是一个开放式去中心话的协议，小程序则完全是由微信背书保证安全完整性的，他即从小程序生态或许巨大利益，同时也是整个生态主宰者，予取予夺，但是微信也承担了对小程序安全性的责任，出了问题微信要负责

[maomaomao001]

@jin5354 这些访问他们能出个沙盒控制就非常完美了，特别是通讯录之类的隐私相关的部分

[momocraft]

flash 能做很多事，后来凉了。activex 更早就凉了。

一个无法保证安全的平台不太可能流行。消费者可能比开发者反应慢、知道得少，但不更傻。

如果你甚至不能理解 CORS 保护了什么，可能不适合认真地规划一个没有跨域的 "灵活" 平台。

[maomaomao001]

@ClericPy 我当然也不是说微信搞了小程序，为什么谷歌不搞一个， 我完全不是这个意思
我的重点在于，为什么这个技术做的这么好了（可以离线了（ PWA ），性能强大了（ web assembly ））,为什么缺迟迟不开放网络能力和文件能力，这点让我很非常诧异，主要是不明白谷歌，微软他们为什么不考虑这么搞的原因 ？

[whypool]

PWA 没监管和审核，注定是坨屎，还不如小程序

还想开文件权限，那是不可能的，一个 js 能读写本地磁盘，那多恐怖

跨域也是不能开的，资源保护，没资源也就没互联网了

[murmur]

开放了啊，cordova 就有 file api,这些 api 都参照了 html5 的标准开发命名，只不过开了更多后门

[maomaomao001]

@sujin190 问题是 localstore， 和 db，没有办法创建目录和文件，按照一定的规则保存在本地吧，或者吧我想保存的文件 zip 压缩（明明 web assembly 那么强大了） ，缺输入输出完全不够用啊

[maomaomao001]

@whileFalse

Progressive Web App 既然 Progressive 好歹超过现有的 web 应用吧（虽然能离线已经很不错了）

webassembly 就更应该支持文件之类的 （明明可以写 c c++ rust 之类的）

我只是觉得这样很可惜啊

[ClericPy]

@maomaomao001 我也想知道啊...
现在那些快应用什么的我都不想用, Windows 上的 app store 也不想开启, 味道都变了. 这帖子这么火, 应该会有好看的答案出现

[momocraft]

wasm 有出现 fs net 等 binding 的可能 (wasi)

不过不要指望能在浏览器用，至少不要指望能无条件用

[DOLLOR]

Chrome 本身就有 FileSystem 实现，只是没有成为标准，但 Chrome 下还是能用的
https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
https://developer.mozilla.org/en-US/docs/Web/API/Window/requestFileSystem

如果你用过 Mega 网盘，你应该发现了，Mega 网盘的 web 端不同其他网盘。其他网盘点击下载链接后直接由浏览器接管下载工作了。但是 Mega 网盘的 web 端不一样，它是由 web 端先下载到网页的沙箱存储里，下载过程是在网页上进行的，完成后再弹出保存对话框。

[Mutoo]

这些限制是现代浏览器提供的，由于 web 开发是一个非常复杂的环境，需要考虑到各方安全性。

就拿为什么要限制跨域访问来说，跨域这个限制本来是不在 HTTP 协议中的，早期的浏览器也没这些限制，自己写的原生 APP 就更不用说了。

但浏览器开发商为用户隐私着想，增设了这个限制，可以让用户的数据更加安全，也更多的用户愿意使用，使其在浏览器之争中获得更大的市场份额。

为什么跨域能保护用户隐私，举一个很简单的例子，如果我在 E 浏览器登录了 Facebook，在 E 浏览器请求我的私信页面，就能获得我的私信内容。如果没有跨域限制，你打开了一个第三方开发者的网站，这个网站尝试在后台偷偷加载 facebook 的私信页面，然后你的私信就被读取了。相比 Chrome，你会使用 E 这样的浏览器吗？。

解决这种跨站 请求伪造（ CSRF ）的方法有很多，但如果一个浏览器在客户端就能帮你设置一道防线，你是不是会更信任这个浏览器。

用原生开发之所以没限制，有一个原因是 APP 的受众比较单一，用户不会在你的原生应用里登录各种可能涉及隐私的服务，除非用户本来就授权你去获取这些数据。

[maomaomao001]

@momocraft 可是现在 wasm 的 net 再强大也会被浏览器挡住请求 🐶

[maomaomao001]

@DOLLOR 对的，想要的就是一个类似这一类的文件操作方案，赶紧实践好成为标准就好了

[whileFalse]

@maomaomao001

“Node.js 能访问文件系统，浏览器 js 不行”你能接受；“c++桌面编程能访问文件系统，web assembly 不行”很难理解？
PWA 的核心就是个类库，纯 js 裸写也能写出来。

[whileFalse]

修正，PWA 是个应用设计思路

[maomaomao001]

Node.js 能访问文件系统，浏览器 js 不行”你能接受

不不，我现在不能接受了，以前能接受，但是现在 js 也比较强大了，而却更是出现了 webassembly 这种高性能方案，



我还是觉得用沙箱（模拟）环境之类的允许他们操作文件和网络比较好，或者至少让用户选择让不让应用这么操作，


对了，类似的是，你用浏览器打开地图网站， 这个时候浏览器就会提示要不要给这个网站提供位置信息啊，
我说的就是类似这样的功能，为什么不能给用户呢，我自己写的工具 app 我还不知道它会不会偷我的隐私吗？

[maomaomao001]

为什么不能给用户呢->为什么不能把选择权给用户呢?

[yyfearth]

@maomaomao001 首先 PWA，web assembly 以及 文件和网络权限 其实没有什么关联
不同的技术和 API 罢了

PWA 就是可以离线运行和安装的网页版小程序 目的是用户体验看起来像本地程序 同时又不需要应用商店来分发
Web Assembly 是除了 JS 以外一个全新的基于二进制的运行时 一方面运行效率高 同时可以把各种现有的程序直接移植到 Web 平台 又可以支持任何可以编译到 WASM 的语言
文件和网络权限或者 API 这个是浏览器提供的功能罢了
这几个其实没什么相互的联系
至于 WebApp 的开放生态 也就 Google 有兴趣 其他厂商巴不得让所有 App 都建在自己的封闭围墙里面（其实就算是开放的 Web 其实也可以算是 Google 的围墙）每个厂商都有自己的如意算盘 要想让系统或者各大浏览器统一来支持是很困难的事情

“为什么缺迟迟不开放网络能力和文件能力”
之所以不给 WebApp 文件和网络权限 是因为安全问题 就算你可以加上权限管理和沙盒 但是总有办法绕过的
你没办法给一个随便可以打开运行的网页随便访问文件系统 以及随便链接其他网络 这样黑客得笑死
本地 App 还好控制一点 可以用签名来做一些保护 另外现在还到搞封闭花园和沙盒什么的

“微软他们为什么不考虑这么搞”
你说的小工具一个 html 就可以了 其实微软早在 IE5/Win98 的时代就有了
就是 HTA 可以用 html/css 写 UI 用 js+vba 访问几乎所有本地系统 API 文件读写访问网络什么都可以
结果并没有什么正经的软件在用 倒是各路病毒木马用的很欢

“谷歌为什么不考虑这么搞”
Google 一直在尝试做安全又实用的文件系统和文件访问 API 给浏览器
最早有 FileReader API 现在也可以用
同时还有 FileSystem API 沙盒的文件系统 但是被标准否决了 同时也很难用 局限性太大
最近又出了了新的 Native File System API 我觉得这个应该就是你想要的吧
但是要推成标准 让 Firefox 和 Safari 支持可就难了
最近 Firefox 疯狂注重安全和隐私 自然不想要这种高风险的 API 而 Safari 东家 Apple 希望 App 强大 并不希望 WebApp 可以强大到取代 Apps

“感觉现在开发跨平台桌面应用太费劲了”
对于跨平台的 UI 你想要保证兼容性问题 你就得自带浏览器引擎 否则就算是相同的浏览器或者相同 web 核心 不同版本也可以弄的你够呛 所以 Electron 这种虽然好几百 MB 但还算不错的选择 只不过应该还可以通过组件化来优化一下体积 不用的功能应该可以丢掉（貌似可以精简到 80-100MB 左右）
如果非常在乎体积 兼容性要求低一些 其实各大系统都有系统自带 web 核心来用 做出来的 app 都可以非常的小 效果也还过得去

[tyrealgray]

PWA 现在最适合的业务是那些阅读信息类，比如 twitter，新闻网站，视频网站很适合直接搞成 pwa。
其他应用想直接用 pwa 做可能都不适合，浏览器之间区别太大了。

[sujin190]

@maomaomao001 #35 但是这明显是个不合理需求，web 从设计之初想的就是无本地依赖话，大量文件的存储应该有网络来完成，本地保存大量文件本身就不符合 web 随处可用的思想，也正基于此，我们打开访问网页才很随意很方便，不用担心有任何网页会在你设备上大量保存文件，也不用担心你无意中在某个不安全设备访问网页后保留你私人数据造成不安全因素，要求使用这个管理设备依赖这是不符合 web 设计思想的，也是极其不合理的

从未来看，个人设备会变的越来越多，管理设备依赖将会变的越发困难，所以设备无关的 web 才是更好的，数据保存应该全部有网络来完成，集中管理集中授权

[maomaomao001]

@yyfearth 感谢你的回复

针对这一点: App 还好控制一点
为什么 App 会好管理，这个没太明白 ，
web 上是做不到类似 native app 式的管理吗？

其实我现在想要的，似乎是可以理解为：
我想要一个新的安装包格式 （假设是 .chromeApp 吧）

开发流程
1.正常像前端 web app 那样开发
2.完成后，发布方式又两种

1.是正常部署到 web server
2.把 html js css 打包后形成 xxApp.chromeApp 文件 （也许仅仅是 zip 压缩文件呢） （这个正式我很想要的一点）


也就是未来存在 xxApp.chromeApp 格式的应用程序包，无论是 Android 还是 ios，更别说是 windows 和 mac 了，
只要是个浏览器就能安装使用，这得多好呀

[yyfearth]

@maomaomao001 Chrome App 不是已经有了吗 虽然没有移动端支持 但是桌面系统都支持了啊
也可以访问本地文件 可以授权访问任何网址
即有应用商店 也可以手动载入自己写的

主要问题还是安全性
发布的 app 经过审查 加上签名校验 安全性还可以有点保障

否则就算你给用户来选择 不是所有用户都知道这些

更重要的是要防止被黑客利用 通过复杂的手段钻漏洞 彻底攻破系统的安全性

[ClarkAbe]

@maomaomao001 #16 跨域 post.....碰不到服务器貌似没什么好的办法.....

[runze]

楼主可能想要 https://deskgap.com/

[runze]

https://github.com/electron/electron/issues/673

早在 2014 年就有人想要解决每个 electron 应用都需要自带一份 runtime 的问题，但至今都没有结果。

[Phariel]

你要这么讲 ActiveX DLL COM 表示不服 当年在 WINDOWS 环境下如日中天 怎么现在都不普遍使用了？

[usam]

只写 web 的程序员才有这种想法吧

[maomaomao001]

@usam 有可能吧，之前写过一点 Andriod，感觉，除了视频播放器之类的应用，和股票类需要实时性很高的应用之外，很多大部分 app 完全没有必要做成 native 呀

[a132811]

@maomaomao001 挖个坟，chrome pwa 已经开放了文件系统、摄像等主要 API 了。参考：
1. https://fugu-tracker.web.app/#shipped
2. https://whatpwacando.today/

文件系统需要用户授权访问指定的目录。

现在的授权机制已经在安全、易用性、开发效率之间做到很好的平衡了。

Proj fugu 有人提过 fetch without CORS ，但是我是不希望取消跨域 CORS 的，这对网站的数据保护绝对不是好事。

CORS 是各网站本身的要求，如果能轻松绕过 CORS ，随便不小心点一个钓鱼网站就能偷偷爬数据，PWA 应该会受各大网站所反对、更别提国内的审查备案了。

本来 Android App 滥用文件权限，就已经受够了。


想绕过 CORS ，必须要付出点成本：参考 Proj Fugu 提的 feature https://bugs.chromium.org/p/chromium/issues/detail?id=962321
1. 自己部署 cors.your.com 或者使用别人的 cors 代理
2. 或者利用 cors chrome 扩展，扩展这个东西谷歌还是会审查一下的
3. 或者让用户下载一个 app 专门，不干别的事，就提供 CORS 代理，证书什么的让用户自签名（反正是用户自己授权安装的，风险自担）

[a132811]

@a132811 主要缺点是国内不能使用 google 的 Web Notifications