关于数据同步提供内置密钥的讨论

本贴最后更新于 560 天前,其中的信息可能已经物是人非

提供内置密钥不是取代自定义密钥,而是两种密钥生成方式用户自己选择。

  • 内置密钥:通过不可变的用户账号信息(比如用户 ID 等)在云端自动生成并保存密钥
  • 自定义密钥:现有的密钥生成方式,在本地生成并保存密钥

内置密钥的优点:对于新用户友好,用户无需记住密钥,只要登录账号就可以使用内置密钥加解密数据快照

内置密钥的缺点:安全性没有自定义密钥高,技术上开发者是可以解密云端数据的

总得来说,内置密钥是降低一些安全性而提升便利性。

你是否赞同提供内置密钥?

单选 公开 已于 2023-05-18 17:45:00 结束 135 票
赞同
33% 45 票
反对
66% 90 票

如果你投了反对票,方便的话请在评论区描述一下反对的理由,也欢迎在评论区补充其他观点,谢谢。

  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统,支持完全离线使用,同时也支持端到端加密同步。

    融合块、大纲和双向链接,重构你的思维。

    22335 引用 • 89369 回帖
5 操作
88250 管理员在 2023-05-18 09:08:01 取消置顶了该帖
88250 管理员在 2023-05-11 22:29:16 置顶了该帖
88250 在 2023-05-11 19:09:06 更新了该帖
88250 在 2023-05-11 18:54:39 更新了该帖 88250 在 2023-05-11 17:57:25 置顶了该帖

相关帖子

优质回帖
  • 内置方案有悖思源隐私性的特点,主打的安全性将被破坏。托管客户的密钥也将置官方于不利境地,相当于是沦落为跟 Notion、FlowUs、Wolai 同流了。客户无法相信审查是不是就是下一步。

    思源作为一家非常注重云端数据隐私性的笔记厂商,建议借鉴 1Password 在密钥管理方面的经验。在生成密钥时生成“急救包”,告诫用户做好保存。

    SASHUZ63WOFBKF.png

  • bug320 5 赞同

    内置密钥会让人“敏感”起来。而且,忘记密码这种事情,本地都是明文加密,重置密钥上传即可。这个功能,我觉得还是不要加为好。如果要加,第一,不能设置成“默认”的密钥选项;第二,请务必保留自定义密钥功能。

    如果是对小白,可以考虑把这块的帮助说明写的详细点。

    像我这种把个人账号、日记啥的写到笔记软件的人,还是比较在意这块的。从“某来”软件迁出的原因,就是因为知乎上帖子,虽然无法对帖子真假性判断,但还是本着“万一是真的呢”的想法,开始比对市面主要的几款软件,最后选了 siyuan。我当时选择 siyuan,最开始还是冲着“完全本地 ”、“端到端加密”、“国内的软件”去的。

  • yawei 1 4 赞同

    我投了反对票。

    原因:对于我这样的普通用户,不要给我介绍太多技术细节,我需要的只是一个简单粗暴的结论。你就告诉我,如果使用自定义密钥,除了你自己谁也看不到你写的东西。哪怕你写了一些不正确的,不能见光的,ZZ 敏感的东西,只要你保管好自己的电脑,就不用担心这些文字被别人截获。如果是这样,哪怕我同时还在用 workflowy, remnote 等一堆云端笔记,我也不会抛弃思源。

    但如果你告诉我,你的云端数据是会被解谜的哦。哪怕可能性只有 0.00000001%,我打字的时候心里也会有些膈应...我从来没看过 WX,WB 这些 app 的隐私政策,但是有些话我绝对不会在上面说...

    与其说是个技术问题,不如说是个心理问题,或者刻板影响。

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 在内置密钥的同时,加强创建自定义密钥的提醒、自动生成备份导出。

    1 回复
  • 现在就有自动生成选项,将自动生成设置为默认,同时允许个人设置不行么?

    1 回复
  • 88250

    假设现在创建自定义密钥已经会强提醒和自动导出了,那么内置密钥还有必要吗?

    1 回复
  • dd798922110 2 赞同

    1 如果是两种方式都提供,我觉得没问题。如果是用内置取代自定义,我坚决反对。
    2 内置密钥如果提供,容易成为“黑点”,别的人可以用这个来攻击思源所谓的数据安全性
    3 本身密码类的东西就是需要自己记住的。可以通过其他地方保存。个人觉得在对应的地方提示用户就可以了。同时,思源本身是本地笔记,一般线上和本地差别不太大,我觉得就算丢失密钥,问题没那么大。
    4 以上都是自己的观点

    1 回复
  • 88250

    现在的自动生成密钥是随机密钥,安全性非常高,但是每次生成都是随机的。

    帖子中提到的是云端生成内置密钥,生成以后就不会改变,所以可以跨设备重复使用。

    2 回复
  • 88250 1 评论

    两种密钥生成机制都提供,不是使用内置密钥取代自定义密钥。

    这样我觉得没问题,给用户多一种选择。只是 D 大你要考虑如果别人(或者友商)拿这个来营销思源并不安全(本身数据安全是思源的买点),虽然有自定义,但是你只要有内置的这个选项,黑你的人才不关心。所以 D 大慎重考虑一下。
    dd798922110 1
  • 赞同楼下的:默认使用内置密钥。要想更多人用,就得简化入门门槛,越简单越好

  • 有必要的。不管强提醒还是自动备份导出,都存在人为忘记,或者备份未保存的情况。但内置不一样,内置相当于只要思源还在,账号还记得,就还能用,减少了用户本身的心理负担。

    但如果真的要上,还是要区分好新老用户。

    比如老用户已经设置过密码的,那在新设备首次同步的时候应该是默认输入自定义密码,不是默认内置密码,否则就容易发生密码不匹配的情况,这个不知道好不好弄。

    1 回复
  • 个人看法,选择自动生成的不在意安全性高多少,在意的是便捷性。毕竟上面也没写随机生成的官方知不知道或者安全性有多高,我在看到这个的时候想到的是可以省略这一步了,我的副空间就用的这个。

    真正在意的都选择自己设置了

  • 88250

    我们无法区别“新老”的,最多只能区别是否在当前设备上初始化过密钥,如果初始化过并且和云端内置密钥不一致,那么就认为是自定义密钥了。

    1 回复
  • 我觉得官方有点过于在乎所谓用户体验以至于钻了牛角尖了。安全性并没有一个量化指标,1-100 分。

    1 回复
  • 云端同步增加这个配置项的同步呢?

    1 回复
  • 88250

    我目前没有看到你投票是赞同还是反对,有点难以理解你的意思,能投票后再补充一下评论吗,谢谢。

    1 回复
  • 88250

    再增加配置项的话会更复杂,用户误操作的可能性更高。

    1 回复
  • 这个配置项明显不是给客户配置呀。是在设置云端的时候就一并记录并和账号绑定了。

    1 回复
  • zuoez02 7 赞同 2 评论

    内置方案有悖思源隐私性的特点,主打的安全性将被破坏。托管客户的密钥也将置官方于不利境地,相当于是沦落为跟 Notion、FlowUs、Wolai 同流了。客户无法相信审查是不是就是下一步。

    思源作为一家非常注重云端数据隐私性的笔记厂商,建议借鉴 1Password 在密钥管理方面的经验。在生成密钥时生成“急救包”,告诫用户做好保存。

    SASHUZ63WOFBKF.png

    在急救包里面包含急救步骤流程与 Q&A 文档就更好了嘿嘿
    shuoying 1 赞同
    这个不错,是一个很好的选择,同时也能刷一波保存隐私的好感。我支持
    dd798922110
  • bug320 5 赞同

    内置密钥会让人“敏感”起来。而且,忘记密码这种事情,本地都是明文加密,重置密钥上传即可。这个功能,我觉得还是不要加为好。如果要加,第一,不能设置成“默认”的密钥选项;第二,请务必保留自定义密钥功能。

    如果是对小白,可以考虑把这块的帮助说明写的详细点。

    像我这种把个人账号、日记啥的写到笔记软件的人,还是比较在意这块的。从“某来”软件迁出的原因,就是因为知乎上帖子,虽然无法对帖子真假性判断,但还是本着“万一是真的呢”的想法,开始比对市面主要的几款软件,最后选了 siyuan。我当时选择 siyuan,最开始还是冲着“完全本地 ”、“端到端加密”、“国内的软件”去的。

  • 88250

    是设置云端的时候提供给用户选择,比如我们提供两个选项:

    • 内置密钥
    • 自定义密钥

    用户设备 1 上选择了内置密钥,设备 2 上选择了自定义密钥,这样也是不能成功解密的。无法做到设备 2 上面自动给用户选择内置密钥。

    1 回复
  • leolee 1 1 赞同

    建议不要。很可能会授人以柄

    1 回复
  • LeonardoDiCaprio 1 1 赞同

    保留原有机制的前提下我投赞成票。

    作为要面向大众的软件,要尽可能的简化操作流程,降低入门门槛,最显明的例子就是苹果在女生中流行的一部分原因其实是苹果系统操作简单,不需要太繁琐的操作。

    说实话,我认为思源如果想面向更多的用户,总是要简化流程的。我不是说现在不好,只是说,如果现在的操作难度是 90 分,那每降低一分,就意味着多 1% 潜在用户。

  • 我觉得没那么夸张,要这么说,世界上其他笔记软件都别做了,只留思源就好了。毕竟他们都是内置的。

    3 回复
  • leolee 1 赞同

    每个软件面对的环境不一样,就算最终会内置密钥,可能现在也不是合适的时机

    1 回复
  • 追求不一样,有的人不在乎自己的隐私,有的在乎

    1 回复
  • 而且说实话,思源相关的舆论环境,确实就是很夸张。。。

  • 内置和自定义同时提供的话,我们觉得不安全可以用自定义啊

  • LeonardoDiCaprio 1 赞同

    把帖子正文改一下把,我猜 80% 投反对票的都觉得你要把自定义密钥取消了改成内置密钥。

    1 回复
  • 不是两个同时提供么?似乎并没有影响到谁的利益,,

  • 我个人没有觉得不安全,从之前五一那段时间来看,会有人想要大家觉得不安全

  • 88250

    正文结尾已经加入说明,投票的前提是两种机制都提供,不是取代关系。

    1 回复
  • 字体大一点,或者放到第一排。。

    我觉得预防针要先打,而不是最后补充一句 😂 反对情绪上来了不会看后续的

    额,这只是我对网民的一种认知,你看着来

    1 回复
  • 88250

    嗯,已经调整到正文第一行了。

  • 由于思源密钥可以直接导出, 目前来说基本没有听过因为删除本地工作空间导致密钥与数据一起丢失的问题

    而且目前的机制对新用户来说, 也就是多点几下鼠标的麻烦, 大幅度牺牲安全性提供这点便利性并不可取

  • 虽然我投了赞成,但是能不加还是不吧,现在配置也比较简单了。而且以小黑子的性格,肯定会在上面取片面之词大做文章的,我不太想看到黑子乱说。

  • Ocean0117 1 赞同 1 评论

    我投了赞成,是建议提供这个功能,但不改变原有的密钥设置。

    我认为许多低技术用户几乎是不可能区分账户密码与密钥的,在他们看来,一道密码就已经足够保险,他们既不理解再设一遍「密码」的意义,也不会试图去弄清这些云服务上的逻辑。所以,我认为针对这些用户(我个人观点,这部分用户绝不在少数,至少一半以上),启用一个内置密钥是有必要的。

    我认为如果推出这个功能,最好是在安装后第一次打开时和工作空间相同的方式提示,比方,提供三个安全等级选项:

    • 低安全级:内置密钥,保存在服务器上,与账号绑定,配上相关声明,不会主动泄露密钥;
    • 中安全级:由字符串生成密钥,基本不会泄露,但某些特定密码或许有泄露风险;
    • 高安全级:随机生成,安全性高,但最好自己保存;

    把选择权优先交给用户,如果点进去则是各个选项的详细说明,这样或许更能满足普通用户的需要。

    1 回复
    哈,你这个也是一个很好的选择。支持
    dd798922110
  • zuoez02 1 评论

    提供一下云端存储密钥如何确保在被脱库的情况下仍能确保密钥不被泄露的方案吧。能达到一般系统的数据库和代码暴露的情况下仍然获取不到密码的方式就可以了。

    当数据被交出去后,就很难保证了吧。最牢靠的还是不要上传,个人觉得。
    dd798922110
  • 88250

    提供多一种密钥生成方式无形中也增加了用户的使用负担。比如你建议的三种选项,用户需要考虑到底使用哪一种,在难以抉择的时候可能会随便选择某一种(也可能会趋向于高安全级别),一旦这个设备上选择了这种方式生成密钥,那么其他设备上也要选择相同的方式,对于普通用户而言这一步就很可能会选错……

    所以增加内置密钥很有可能会给用户带来额外的操作成本,操作步骤中的分支意味着配置不当的概率会增加,从而背离提供内置密钥提供便利的初衷。

  • zxhd86 2 赞同 1 评论

    我投了反对票,是因为在我看来这个是安全不绝对,等于绝对不安全。

    首先,我认为安全性不是下降一点,而是下降到稍微努力就能攻破的地步。

    思源是开源软件,加密算法是公开的。从这个角度来说,开发者和攻击者所站的高度是一致的,假如得到了不可变的账号信息,那么攻破云端数据加密不在话下。也就是说,思源的安全等级从之前的目前技术无法攻破变为了上限是攻破密码即可。如果对于不可变的账号信息的选择不慎,那可能连破解密码都不需要。

    而哪怕是上限,密码所能提供的保护能力是极其低下的,目前 QQ、微信之流都增加了验证步骤,就足以见得。

    其次,思源作为一个实体存在的公司运营的产品,就必须考虑政策的影响。很多时候,不是开发者自己不愿意侵入用户隐私就能如愿的,当你有能力的时候,用户的安全只取决于政策的变动。如果政策需要登记用户的笔记内容(这可能听起来有点扯,但是你必须考虑有这种可能),你作为有能力的开发者,你就必须照做。对于这种问题,最好的做法就是不要打开潘多拉的魔盒,不要触及这种风险。

    最后,说一点题外话,就算有了内置密钥,而且新的用户基本选择了内置密钥,难道就说明他们愿意放弃真正的安全性?他们可能只是不理解这么麻烦的意义,所以从方便起见,选择了只方便一点的方案。对于这些用户,我们更应该教育他们,替他们作出决断,而不是把选择直接交给他们,这在我看来无疑就是一个免责声明而已。

    1 回复
    首先,针对开源软件,加密的原理是破解的代价非常大(耗时是天文数字),理论上就是安全的。同时后端关于审查的内容支持,D 大也要考虑一下如果思源用户再多起来以后,审查的事情要好好考虑一下。
    dd798922110
  • LeonardoDiCaprio 11 评论

    因为是开源软件,所以破解变得格外容易是么?

    不过 D 都投了反对票,那就没啥讨论的必要了。

    1 回复
    开源会降低破解难度,因为攻击者不需要猜你用的是哪种加密算法,但没有还是能逆向出来,只是比较难。
    zxhd86
    如果用分数来衡量破解难度的话,密码 100 分,闭源 50 分,良好的算法 1000 分,原本是 1100 的,内置后现在就剩下 100 分了。
    zxhd86
    不过 d 的反对票只能代表他个人的想法,他一直就是反对的。假如社区认为真的内置好的话,那也会做的,这在技术上不难。
    zxhd86
    @zxhd86 我的意思是,虽然我投赞成,但是目前的形式反对居多。如果 D 也反对的话,那我也没必要坚持了。我的坚持是因为我认为他好。但是思源的掌舵人是 D,我相信他的判断。
    LeonardoDiCaprio
    @zxhd86 不是两种都可以么?我继续用原来的呢?
    LeonardoDiCaprio
    @LeonardoDiCaprio 当然可以,我的理由只是说这不利于使用内置密钥的用户,认为这是为了提高思源的便利性进而提高思源的口碑,而牺牲了他们的安全。
    zxhd86
    @LeonardoDiCaprio 换而言之,我认为这对于思源本身、对于用自定义密钥的用户来说,起码是没有影响,更可能是有利无害,只是损害了使用内置密钥用户的安全。
    zxhd86
    @zxhd86 大家都知道骑摩托车不安全,难道摩托飙车党不知道么?我们上街游行,理由是摩托车对飙车党的生命有危害,那飙车党会感谢我们么?
    LeonardoDiCaprio
    @zxhd86 所以说,你认为这样会损害他们的利益,却不知道他们并不认为这样对他们利益有损,反而是设置自定义密码才让他们望而却步。萌新说,只是多点几步的事。我其实不这么看。他是 IT 界大佬,他懂得多,我为了些 SQL 花了近一个月学习,对他来说也不过是敲敲键盘罢了。实际上很多人连说明书都不想看,这几步可能就是堵在他和思源之间的一堵墙。
    LeonardoDiCaprio
    @zxhd86 我记得,前一阵子抖音有一个 up 挺火的,她做视频就是教你最基础的东西,大概对我们来说就是怎么安装软件这个级别的人。但是他火了,为什么?因为现在的人确实不爱看说明书了,东西拿在手上,自己琢磨能用,就用,不能用,竞品那么多,换一个就好了。
    LeonardoDiCaprio
    @zxhd86 哦对,我不希望有人杠我什么这些人不是思源的目标客户之类的话,所以补充一句,每一个人,只要他有写笔记的需求,他就是思源的目标客户
    LeonardoDiCaprio
  • yawei 1 4 赞同 1 评论

    我投了反对票。

    原因:对于我这样的普通用户,不要给我介绍太多技术细节,我需要的只是一个简单粗暴的结论。你就告诉我,如果使用自定义密钥,除了你自己谁也看不到你写的东西。哪怕你写了一些不正确的,不能见光的,ZZ 敏感的东西,只要你保管好自己的电脑,就不用担心这些文字被别人截获。如果是这样,哪怕我同时还在用 workflowy, remnote 等一堆云端笔记,我也不会抛弃思源。

    但如果你告诉我,你的云端数据是会被解谜的哦。哪怕可能性只有 0.00000001%,我打字的时候心里也会有些膈应...我从来没看过 WX,WB 这些 app 的隐私政策,但是有些话我绝对不会在上面说...

    与其说是个技术问题,不如说是个心理问题,或者刻板影响。

    我的想法跟你一样。
    dd798922110
  • suiji 1

    我投赞成票,虽然我自己不是,但我相信一定有许多用户是不需要严格的私密性的,一来是个人防护意识淡漠,二来可能是笔记内容本身并不敏感。提供内置密钥与其说给防护意识淡漠的人以方便,不如说是给内容不敏感的笔记记录以方便——免得给人一种成见:我又不记录多私密的笔记,干嘛要用思源笔记?

    所以,在提供内置密钥时,不妨把说明适当夸大点:选择内置密钥几乎默认你放弃私密性。

  • 88250 1 赞同

    开源软件是否更容易破解这个不好下结论,但是公开加密算法不不意味着就能破解这一点是肯定的。

    本贴的意义在于集思广益,只是我个人考虑的话难免会存在思路上的局限,这会限制思源的长期发展。

  • qiancang

    支持使用自定义密钥方案,不反对提供内置密钥方案。

    在用户启用同步功能的时候,应该默认要求设置自定义密钥,在输入窗口可以加个使用内置密钥的按钮,并在点击后弹窗提示相应风险。

    内置密钥的云端计算方案应该是部署在服务器上不开源的吧?内置密钥从服务器传输到本地的过程是加密的吗,传输过程是否存在泄露风险?

    1 回复
  • 88250

    如果要做的话,内置密钥生成算法是不开源的,传输使用 HTTPS,存在泄漏风险。

  • someone101676 2 评论

    反对投票本身 2023-05-12 20:19:03

    这个投票没有意义, 投哪个都会有争议, 没能解决真正的问题.

    方便与安全不一定要对立起来, 不同需求的用户也不一定要对立起来.

    1 回复
    1 操作
    someone101676 在 2023-05-12 20:19:10 更新了该回帖
    感觉你提出两个方案跟这次投票的好像没什么区别。个人觉得
    dd798922110
    @dd798922110 大概的意思就是, 在自定义密钥与自定义存储提供商之前, 按需求区分人群, 简单需求软件/思源处理, 高级的需求完全自定义.
    someone101676
  • zuoez02 1 2 赞同 2 评论

    网络安全课程里第一堂课讲的内容:“安全性最重要的不是算法,而是密钥的管理”。啥算法再高级,只要你密钥泄露出去了,基本就是玩完。密钥不做保护,太白搭。甚至可以被内部利用。

    本地客户端,密钥直接就在全局变量里,window.siyuan.config.repo.key。所有插件都可以直接访问的到,S3 配置,window.siyuan.config.sync.s3。拿到这两样,一个思源用 S3 存储的客户的数据就已经可以被插件读走了。假设我做个好用的插件,直接编译压缩混淆,代码审核起来也费劲,完全是有可能的。

    1 回复
    大佬,你这个评论让我一身冷汗啊。我装了一大堆插件
    dd798922110
    完了……对安全性产生怀疑了
    dd798922110
  • 88250

    这个投票的意义我前面简短写过一点,怎么能说没有意义呢……

    不同需求的用户实际上已经通过产品选择过滤了,比如不需要本地数据的用户会选择云端产品,安全性和便利性本身是对立的,我们讨论的意义在于探寻是否存在一个折中方案进行兼顾。

    对于“真正的问题”前面已经讨论过,即内置密钥(甚至是不加密)的需求是客观存在的,但是思源是不是一定要去实现这个需求?思源的受众定位如果不考虑这部分用户的需求是否合理?

    我认为一个产品不可能满足所有人的需求的,放弃一部分需求是合理的。在内置密钥这个具体的需求上,放弃的代价可能就是无法获得更多“小白用户”的青睐,但真正的小白用户会选择本地优先的产品吗?这也是个需要不断思考和讨论的问题。

    我们期望的不是毫无根据的信任,而是能够用技术证明的信任。开发者抛开代码实现谈信任是一种不负责任的做法,用户将希望寄托于开发者人品上也是不明智的,因为人品不能保证安全,但是代码能。

    对于内置密钥就像前面 @zxhd86 提到的那样:“安全不绝对,等于绝对不安全”,一旦我们为思源提供了不足够安全的加密方案,云端数据实际上有很多泄漏的可能性,不只是开发者可以解密,云服务提供商也可以。所以前面 @zuoez02 提出了实现内置密钥后进一步的安全方案,但是这个方案非常难实现,或者说对于我们来说代价过高,已经偏离了现在的目标。

    如果把提供内置密钥看作功能性需求的话,多提供一种选择给用户确实更好;但如果把它看作是非功能性需求的话,提供了内置密钥会导致产品整体安全性降低很多。

    3 回复
  • 88250

    是的,这部分已经在用户指南中的 数据安全 章节描述过。

    1 回复
  • zuoez02 1 1 赞同

    image.png

    说的是这个吗?用插件读取用户配置我认为是内部攻破了软件自身安全性,不属于“用户不泄露密钥给攻击者”,而且软件行为用户本身也没法修改

    1 回复
  • someone101676

    简单的同步备份, 不需要关心密钥是如何产生. 2023-05-12 20:20:02

    1 回复
    1 操作
    someone101676 在 2023-05-12 20:20:17 更新了该回帖
  • 88250

    对,本地环境上面我们只能认为是受信任的安全环境,包括插件的安装或者其他软件的行为都认为是受控的。

    1 回复
请输入回帖内容 ...

推荐标签 标签

  • Unity

    Unity 是由 Unity Technologies 开发的一个让开发者可以轻松创建诸如 2D、3D 多平台的综合型游戏开发工具,是一个全面整合的专业游戏引擎。

    25 引用 • 7 回帖 • 174 关注
  • 面试

    面试造航母,上班拧螺丝。多面试,少加班。

    325 引用 • 1395 回帖
  • HTML

    HTML5 是 HTML 下一个的主要修订版本,现在仍处于发展阶段。广义论及 HTML5 时,实际指的是包括 HTML、CSS 和 JavaScript 在内的一套技术组合。

    107 引用 • 295 回帖 • 1 关注
  • Android

    Android 是一种以 Linux 为基础的开放源码操作系统,主要使用于便携设备。2005 年由 Google 收购注资,并拉拢多家制造商组成开放手机联盟开发改良,逐渐扩展到到平板电脑及其他领域上。

    334 引用 • 323 回帖 • 1 关注
  • 宕机

    宕机,多指一些网站、游戏、网络应用等服务器一种区别于正常运行的状态,也叫“Down 机”、“当机”或“死机”。宕机状态不仅仅是指服务器“挂掉了”、“死机了”状态,也包括服务器假死、停用、关闭等一些原因而导致出现的不能够正常运行的状态。

    13 引用 • 82 回帖 • 52 关注
  • 996
    13 引用 • 200 回帖 • 6 关注
  • Openfire

    Openfire 是开源的、基于可拓展通讯和表示协议 (XMPP)、采用 Java 编程语言开发的实时协作服务器。Openfire 的效率很高,单台服务器可支持上万并发用户。

    6 引用 • 7 回帖 • 95 关注
  • Log4j

    Log4j 是 Apache 开源的一款使用广泛的 Java 日志组件。

    20 引用 • 18 回帖 • 31 关注
  • React

    React 是 Facebook 开源的一个用于构建 UI 的 JavaScript 库。

    192 引用 • 291 回帖 • 384 关注
  • V2Ray
    1 引用 • 15 回帖
  • etcd

    etcd 是一个分布式、高可用的 key-value 数据存储,专门用于在分布式系统中保存关键数据。

    5 引用 • 26 回帖 • 529 关注
  • PWA

    PWA(Progressive Web App)是 Google 在 2015 年提出、2016 年 6 月开始推广的项目。它结合了一系列现代 Web 技术,在网页应用中实现和原生应用相近的用户体验。

    14 引用 • 69 回帖 • 154 关注
  • H2

    H2 是一个开源的嵌入式数据库引擎,采用 Java 语言编写,不受平台的限制,同时 H2 提供了一个十分方便的 web 控制台用于操作和管理数据库内容。H2 还提供兼容模式,可以兼容一些主流的数据库,因此采用 H2 作为开发期的数据库非常方便。

    11 引用 • 54 回帖 • 654 关注
  • DNSPod

    DNSPod 建立于 2006 年 3 月份,是一款免费智能 DNS 产品。 DNSPod 可以为同时有电信、网通、教育网服务器的网站提供智能的解析,让电信用户访问电信的服务器,网通的用户访问网通的服务器,教育网的用户访问教育网的服务器,达到互联互通的效果。

    6 引用 • 26 回帖 • 510 关注
  • 微软

    微软是一家美国跨国科技公司,也是世界 PC 软件开发的先导,由比尔·盖茨与保罗·艾伦创办于 1975 年,公司总部设立在华盛顿州的雷德蒙德(Redmond,邻近西雅图)。以研发、制造、授权和提供广泛的电脑软件服务业务为主。

    8 引用 • 44 回帖
  • Firefox

    Mozilla Firefox 中文俗称“火狐”(正式缩写为 Fx 或 fx,非正式缩写为 FF),是一个开源的网页浏览器,使用 Gecko 排版引擎,支持多种操作系统,如 Windows、OSX 及 Linux 等。

    8 引用 • 30 回帖 • 407 关注
  • HBase

    HBase 是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的 Google 论文 “Bigtable:一个结构化数据的分布式存储系统”。就像 Bigtable 利用了 Google 文件系统所提供的分布式数据存储一样,HBase 在 Hadoop 之上提供了类似于 Bigtable 的能力。

    17 引用 • 6 回帖 • 73 关注
  • Sphinx

    Sphinx 是一个基于 SQL 的全文检索引擎,可以结合 MySQL、PostgreSQL 做全文搜索,它可以提供比数据库本身更专业的搜索功能,使得应用程序更容易实现专业化的全文检索。

    1 引用 • 211 关注
  • Gitea

    Gitea 是一个开源社区驱动的轻量级代码托管解决方案,后端采用 Go 编写,采用 MIT 许可证。

    4 引用 • 16 回帖 • 4 关注
  • DevOps

    DevOps(Development 和 Operations 的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

    47 引用 • 25 回帖
  • Solidity

    Solidity 是一种智能合约高级语言,运行在 [以太坊] 虚拟机(EVM)之上。它的语法接近于 JavaScript,是一种面向对象的语言。

    3 引用 • 18 回帖 • 399 关注
  • NetBeans

    NetBeans 是一个始于 1997 年的 Xelfi 计划,本身是捷克布拉格查理大学的数学及物理学院的学生计划。此计划延伸而成立了一家公司进而发展这个商用版本的 NetBeans IDE,直到 1999 年 Sun 买下此公司。Sun 于次年(2000 年)六月将 NetBeans IDE 开源,直到现在 NetBeans 的社群依然持续增长。

    78 引用 • 102 回帖 • 680 关注
  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    142 引用 • 442 回帖
  • Vue.js

    Vue.js(读音 /vju ː/,类似于 view)是一个构建数据驱动的 Web 界面库。Vue.js 的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件。

    266 引用 • 665 回帖 • 1 关注
  • Wide

    Wide 是一款基于 Web 的 Go 语言 IDE。通过浏览器就可以进行 Go 开发,并有代码自动完成、查看表达式、编译反馈、Lint、实时结果输出等功能。

    欢迎访问我们运维的实例: https://wide.b3log.org

    30 引用 • 218 回帖 • 629 关注
  • 安全

    安全永远都不是一个小问题。

    199 引用 • 816 回帖
  • 程序员

    程序员是从事程序开发、程序维护的专业人员。

    567 引用 • 3532 回帖