中文维基百科上的7个用户被永久禁制(附:關於一系列重大基金會行動的說明)

维基媒体基金会今天的大动作:WMC在中文维基百科上的7个用户被永久禁制(包括Techyan和WG),12个管理员权限被剥夺

 https://i.redd.it/izorje812fn71.png

 

https://meta.wikimedia.org/wiki/Office_actions/September_2021_statement/z

 各位好,

我是維基媒體基金會法務部門的副總瑪姬·丹尼斯(Maggie Dennis),目前專門負責社群穩定及發展(Community Resilience & Sustainability)。[1]此信是為了要向大家說明為了保護全球社群,維基媒體基金會採取的一系列行動。

在此先向各位致歉——這封信內容非常長,且部分內容較為含糊。本信所述之大量議題相當複雜,我會儘量簡單總結其中對大家來說可能較不熟悉的資訊。在條件允許的情況下,我會儘量回覆相關問題,在數個星期之後我們的部門將會舉辦公聽會,到時我們可以更深入的討論本案相關議題。具體時間和詳細訊息會於跟工作人員協調好之後,盡快公告於Wikimedia-L和元維基。

也許您們之中許多人已經注意到,最近維基媒體基金會修改了保密協議(Non-disclosure agreements,NDA)政策。在元維基上已經有針對這些政策改變的討論,我不會在此信中複述相關討論內容。[2]簡而言之,基于潜在威脅的可信資訊,維基媒體基金會改變了個人接受保密協議的相關方針。这些安全威脅是有关于對維基媒體的滲透(infiltration)的資訊,包括对能够接触個人身份資訊以及当選的有影響力人物的职务的威脅。由于担心可能触发我们被警告的相關風險,我們無法預告我們此次的行動——即便是對我們所信任的社群成員(如監管員等)我們也不得不保密。我們立即限制了可能受影響的人士對此類工具的使用權限,並正在與相關用戶積極溝通,以核實他們是否確切受到危险。

我想要在此強調我們無意指责因此政策改变而權限受到限制之用戶有任何不良企圖。上述的渗透有多種渠道。我們既发现有用戶為了取得相關權力來刻意试图融入社群——然而他們的最終目的與維基媒體基金會開放知識之目標相左。同時我們也注意到部分受信任的社群成員,可能已成為外部團體利用和伤害的危险目標。这项政策主要為了解決后者,減少相關成員被招募或脅迫的可能性。除了这项政策改变中被除權的用戶能获得的個人資訊可能被洩露之外,我們相信这些用户中的部分也可能面臨危险。

本日,維基媒體基金會已经推出第二阶段的方案著手處理關於滲透的顧慮。我們在兩大受到影響的轄區之一內採取行動。在深入調查未獲認可的組織「中國大陸維基人(用戶組)」(Wikimedians of Mainland China,以下簡稱WMC)部分成員之相關行為後,我們決定全域禁制7位用戶,並將12位管理人員除權。[3]同時,我們向部分編輯者告知了拉票以及人肉搜索的相關政策,要求他們改变行為。

通常來說,維基媒體基金會不會對於自身之行動做過多的解釋,但此次破例是因为此次受影響範圍之大前所未見。為了保護在特定國家,及未受認可之用戶組的用戶之隱私及安全,我們無法透露過多訊息。我承认這些行動实属激進,然而此決議并非轻易。我們並不想要打擊及摧毀那些積極為開放知識奮鬥的诚信的包含WMC成員的中國編輯者的努力。我們不希望他們擔憂他們的貢獻會不受歡迎。可是,我們也不能在明知他們的安全可能遭受威脅的前提下,放任他們暴露在危險之中,而不採取任何保護措施。

  1. 在此之前,我們已經限制了對中國大陸地區用戶的個人資訊存取,我們知悉到上述的威脅存在於我們的專案之中。我們了解到已有用戶因此受到人身傷害。在確認案件真實性後,我們不得不立即採取相應措施。

    在我的維基生涯裡面,此次的事件是一場挑戰,同時是一場勝利——維基百科已從一個受怀疑的非主流網站變成了全球高度信任普遍仰仗的網路百科。我在2007年第一次編輯專案時,就覺得維基媒體有成為世界最偉大的成就之潛力:大众的知识唾手可得。這是全體編輯者偉大的善舉。但是我在我开始編輯之后很快地意識到在如何呈现資訊上的角力之激烈,且有人利用该争端來達成其目的。在此,我並不是要說我有先见之明——我相信有許多維基成員在我之前早就意識到了相應的風險。我相信當今天的維基媒體專案備受信任,而外部勢力控制維基媒體資訊對他們能帶來前所未有的好處的时候,我們面臨的風險之大也是前所未有的。

    「掌控」社群的威脅是實質存在的。數年來,維基媒體基金會一直知道克羅埃西亞語維基百科(Croatian Wikipedia)有面臨相關的挑戰——當中的相關檔案可以追溯至近十年前。維基媒體基金會近期設置了打擊虛假訊息團隊,他們在評估相關風險、尋找適當的方式、並已聘僱外部研究人員來審查專案的相關資料,以幫助我們更好地理解在面臨相似情況時可以使用怎樣的解決方案,以及該情境的起因[4]。最近,我們也成立了人權團隊,專門處理这些因有组织的控制訊息的尝试而造成的緊急人權威脅。我們今天所處理的案件展示了作為一個全球媒體活動,我們多么需要積極地處理面對的威脅,既要保证任何人在任何地方都可以编辑,又要保證这些人免受想让他们噤声的人的伤害。

    關於除權,我們希望可以於可見的未來跟國際中文社群作近一步的溝通,探討我們對於選舉制度的計劃,以避免相關的維基媒體基金會專案被不合理的控制,並確保人们可以感觉安全并确实安全地編輯維基百科。我們需要確保我們的社群可以舉辦公正的選舉——沒有拉票或欺詐的行為。同時,我們希望對於選舉制度的改變可以幫助我們恢復(中文維基百科之)使用者查核員(Checkuser)權限。

    在本信的結尾,我想要对你们当中被驚擾到人被表達我最真摯的歉意。这些人无疑包括那些擔心個人資訊是否已被洩漏的(我們並不認為有這樣的問題。我們已經及時採取行動避免了此事。)以及那些擔心更多此類的維基媒體基金會行動可能影響他們正常編輯和他们的社区的用戶(我們認為我們目前的行動已經在中短期遏止了相關的風險)。我對於受到相關威脅的社群表示抱歉。維基媒體基金會將繼續加強建設,以支持所有需要我們支持的社群,我們也仍然在學習如何能做得更好。同時,我們將繼續改进我們在这两方面的認知:我们在人權領域的影响以及我們解决相關挑戰的能力。您們值得有更好的服務——我們無法馬上解決所有的問題,但我們將积极努力专注地提升改進。

    在此,我想要對在全球活躍貢獻的为五洲四海的读者服务的四千多名中文維基人表達歉意和遗憾。[5][6]我向你們保證,我們將會做得更好。您們向在世界各地的中文維基讀者分享知識是非常有意義的善舉——我們保證會持續支持您們的付出,為您們提供所需工具,使您們在一个安全、有效的环境心想事成。

    在此重申,我會在法務團隊及其他相關團隊的幫助下,盡力回答你們的問題。我們會在元維基上設立一個專頁,以討論此系列的行動,並於幾週之後,我會主持公聽會,讓我們能更深入的討論本案相關議題。

    致以最誠摯的問候, Maggie Dennis (WMF)留言) 2021年9月13日 (一) 16:13 (UTC) 瑪姬


  2. Community Resilience and Sustainability

  3. Talk:Access to nonpublic personal data policy § Policy adjustment on behalf of Legal

  4. Wikimedians of Mainland China

  5. m:Croatian Wikipedia Disinformation Assessment-2021

  6. https://stats.wikimedia.org/#/zh.wikipedia.org

  7. https://stats.wikimedia.org/#/zh.wikipedia.org/reading/page-views-by-country/normal%7Cmap%7Clast-month%7C(access)~desktop*mobile-app*mobile-web%7Cmonthly

全局 HTTPS 是势在必行

https://seo.g2soft.net/2017/01/20/full-https.html

很多站长应该收到 Google 发来的 email 了。从 Chrome 56 开始,任何网页,如果有输入密码或者信用卡资料的,却没有使用 HTTPS,将被 Chrome 浏览器标识为不安全。

其实这只是第一步,之后,任何没有使用 HTTPS 协议的网页都会被标识为"不安全",或者 "Not Secure"。

之前 DavidYin 就建议过,要使用 HTTPS,而且过去我也认为只有在有支付等需求的网站才需要上 HTTPS,现在看来还不够,从2017年1月开始,任何网站都要考虑到上 HTTPS了,新网站从设计,从买域名开始就要考虑到这一点。现有网站也要尽快加上 HTTPS。

google-warning-https.jpg

过去用 HTTPS,买 SSL 证书都是一个比较大的成本。从去年的 Let's Encrypt 可以免费签发证书后,这就不再是一个费用的问题了,而且网上有不少自动签发证书以及续签的脚本,找一个用上就是了。还有一些虚拟空间的服务商,比如 Dreamhost , 也免费提供 Let's Encrypt 的自动签发服务,你都不用去找脚本了,直接在管理后台改一个设置就成了,以后每三个月自动给你续签。

如果想要用付费的域名,我推荐使用 gogetssl ,他们的 SSL 证书价格有优势,而且验证域名所有权以及签发的速度都是非常快的,一般我都是在一个小时内都可以完成了。

Gogetssl 的证书价格,就举几个最低的好了。

  • Comodo Essential SSL,3年USD$25。
  • Comodo PositiveSSL, 3年USD$11.25。
  • GGSSL Domain SSL, 3年USD$9.65。

这三个是 DV 证书而已,我都有买过,用过。可以签发 ECC 证书。

这里 DavidYin 总结一下目前对于 HTTPS 的形势,告诉你如何做好 HTTPS 的8点。

  1. 所有网站都要加上 HTTPS。
  2. SSL 要用 ECC 证书,即使因为某种原因必须要用 RSA 证书的,那么也要用双证书,就是 ECC + RSA两个证书。
  3. 沃通已经信用破产,哪怕以后改个名字再来,也不要用。
  4. 有条件上 HSTS 的,那就加上,这无疑会更加安全。
  5. 只使用 TLS 协议,包括 TLSv1.0, TLSv1.1,TLSv1.2。禁止 SSL 协议。
  6. 在加密算法上,要去掉 RC4。
  7. SSL 证书的签名算法,要使用 SHA-2,不要使用已经被证明有严重缺陷的 SHA-1了。
  8. 前向安全性,Forward Secrecy,就是说要使用 DHE 或者ECDHE 密钥交换。

V2Ray、trojan、NaiveProxy代理的异同及相关问题

https://allinfa.com/reviews-v2ray-trojan-naiveproxy-self-built-proxy.html?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+allinfa+%28%E7%BE%8E%E5%8D%9A%E7%BF%BB%E5%A2%99%29

一、北理工破解V2Ray的专利之乱

先说说一年前北京理工大学破解V2Ray的专利一事。2019年3月,北理工的三人(二位教师一位在读硕士生)申请了“基于长短期记忆网络的 V2Ray 流量识别方法”专利,2019年7月公布,发布一种识别V2Ray的特征信号的方法,一时引起一阵小小的骚动。这个事要真成了,中共邪党可高兴了,可是大家也没见到它表现出高兴来,倒是网友担心V2Ray步ss后尘而多了一份担忧。

美博此文讨论这一点就是要让网友放心,一是从道理上来讲,魔高一尺、道高一丈,这才是真理。相生相克,有墙,就一定有破墙的技术,这就是人世间的理。二是,中共还没有办法破解和识别V2Ray的VMess协议,至今如此,那个专利毫无技术水准(下面会分析),以后中共能不能破解VMess协议这也很难说,说不定在破解它的技术出现之前,GFW就随着中共一起下地狱了。退一万步说,即使是中共能找到V2Ray某些特称,也一定会有v3、v4……等等的其他翻墙技术出现来克制中共GFW,邪不胜正,这在封锁网络与翻墙的现实中表现的淋漓尽致,网是封不住的,中共只是领着一帮小鬼如方滨兴、江绵恒等在瞎折腾,耗费民脂民膏,它也从来没有封住过网络。

该专利申请原文在网上也可查到,有兴趣的网友可以去查看,当然是不值得一看的:https://files.catbox.moe/vmzj04.pdf

言归正传看看该专利的专业水准。专利内容是使用LSTM识别V2Ray流量,这不是具有新意或者创造力的技术,从专利本身来看,其权利要求(专利原文):

1.基于长短期记忆网络的V2Ray流量识别方法,其特征在于所述方法包括如下步骤:
步骤1,从交换机设备中获得数据链路层数据包并标注为V2Ray流量或其他流量;
步骤2,去除数据中不包含有用信息和冗余的数据包,去除TCP三次握手数据包,去除DNS域名解析数据包,保留每次通信的前16个数据包,并将这16个数据包作为数据集中的一条数据;
步骤3,对数据链路层数据包进行处理,去除数据链路层报头获得网络层数据包,对UDP报头进行填充使其长度与TCP报头保持一致,去除网络层数据报头中的表示IP地址和端口的信息,对数据包长度进行调整,使其保持一致;
步骤4,使用这些预处理过的数据训练长短期记忆网络。

从专业角度来评审,这个专利基本上就是来吓唬非专业人员的,了解中共高校运作的人就会知道,这样的专利多半是滥竽充数,一般是用来抢站研究位置并获取研究经费的手段、或者评职称需要而已,其技术水准离真正的实际应用和破解或识别还差十万八千里都不止。

既然他们申请了专利,并经过网络转载发酵,当然也引来众多专业人员的评审。我们简单摘录几条。

约翰霍普金斯大学计算机科学李博士说:
步骤1,2和3基本上是标准操作,该专业本科生就知道,没什么可以解释的。步骤四,就是把处理过的包扔进长短期记忆网络里训练,然后用模型匹配数据包。唯一的创新点可能就是V2Ray的前16个包比较有特征吧,具体什么特征还不知道。遇事不决机器学习呗。这个东西不就是把抓来的数据包修修剪剪,不做任何处理,不考虑后续数据包各种加密,然后扔到模型里训练么??坏人打不死,好人误伤一大片吧。。而且就算真的有效果,V2Ray稍微修改下特征,估计整个方法都能废了吧。
Ivlianvs对此专利的分析:
首先,技术错误:
步骤3里提到获得网络层数据包,然而后面跟的是UDP和TCP头。然而UDP和TCP头属于传输层(OSI模型第4层)而不是网络层(3层)。
其次,授权风险:
A) 缺少必要技术特征:该方法是一个流量识别方法,然而最后一步只是训练记忆网络,没有识别任何流量,因此不能解决技术问题。 
B)公开不充分:说明书只给了训练方法,没有详细说明如何识别流量。
第三,商业价值:
A)保护范围过小,易于规避:
最明显的是“保留每次通信的前16个数据包”,任何潜在侵权者可以修改为16之外的任何数量就可以规避专利。
B)只有方法权利要求,只能针对使用者。
C)难以搜集侵权证据:
除非得到源代码,否则无法证明潜在侵权者使用了该专利。D)缺少直接侵权者:流量识别方法的使用者和模型的训练者可能不是同一主体,因此没有人直接侵权。

结论:总之:垃圾专利

V2Ray官方网站的评论:

# 关于某专利
首先,专利并不会保证方法的有效性,专利仅仅是保护方法本身。
其次,该专利的描述存在一些问题:
1. 专利中提到:“V2ray服务端与客户端进行每次通信时需要预先交换密钥,因而每次通信较为靠前的数据包具有显著特征”。
实际上,VMess 协议并不存在“预先交换密钥”这个步骤。
即使将 V2Ray 与需要进行“预先交换密钥”的协议配合使用,那么进行“预先交换密钥”时的数据包也不会有 V2Ray 的数据特征,因为此时还没有开始发送有效数据,即使有特征也是配合使用的协议的特征。
2. 专利中将 V2Ray 拼写成了 V2ray。

北京理工大学的背景

据悉,该专利于2019.07.05公布,三个专利人,依次是罗姓教授、读研一的王同学、潘姓副研究员,都来自北京理工信息与对抗技术研究所。随后这个专利申请的截图被贴在了微博上,并在一些人士的渲染、关心和转发下迅速发酵。更有消息指出,最初的这项研究来自几位本科生的毕业论文,之后再被读研究生一年级的王同学(专利申请人第二位)承袭。按照中共高校的体制,专利申请人第一位的罗姓教授应是其指导教师。

再说说北京理工大学,其前身叫做延安自然科学院。在中共阅兵的30个方阵中,北京理工大学参与了22个方阵的装备的设计和研制,参与数量和深度位居全国高校第一。由此可见,其与红魔的关系要搞出这种荒诞事,也就不奇怪了。

这个专利的最后结果:

大概是因技术含量实在low,所说方法实在太普通,被专业质疑太多,该专利已经悄悄的被撤回。并且连这位申请教授也关闭了微博评论区和私信。一场闹剧结束。

二、V2Ray 的优势与其方案的选择

V2Ray为大家提供了一个平台,支持多种协议,有强力的研发team。V2Ray有别于 trojan、NaiveProxy 的最大特点是 V2Ray有独创的VMess协议。VMess 协议是由 V2Ray 原创并使用于 V2Ray 的加密传输协议,为了对抗墙的深度包检测而研发的。VMess 是一个加密传输协议,它分为入站和出站两部分,通常作为 V2Ray 客户端和服务器之间的桥梁。VMess 依赖于系统时间,请确保使用 V2Ray 的系统 UTC 时间误差在 90 秒之内。

V2Ray的加密形式并不局限于一种协议, VMess 加密在各个传输协议中均是存在的。对于一个内容, VMess 会根据客户端支持的加密方式进行加密,在服务端进行解密,这是基础的一层加密,如果使用WS+TLS的协议进行传输这些内容时,会在内容加密的基础上再进行一次 TLS 加密,也就是说, VMess 会加密两次。因此,即便在传输过程中遭到中间人攻击,导致传输内容变成明文及 TLS 加密失效,V2Ray传输的内容依旧能一定程度保持安全。

V2Ray团队也在及时推行混淆策略,即使是上面专利谈到的”深度学习“,策略制定的复杂度和更新速度就可以克服。在反主动指纹识别上,彻底避免主动指纹识别的方法是用一个真的常见应用(例:nginx)作为前端。

独创的VMess协议优势在于此,其弱点也“可能"在于此。

优势是:独创的VMess协议,可以自行完善,V2Ray团队会想办法让其优于HTTPS,同时克服有特征被识别,也就是说,在VMess被邪党GFW破解之前,这个V2Ray就是安全最好的;
弱点是:也如上述,因使用其独特的VMess协议,这个独特也成为GFW的攻击重点,只要破解协议,或者找到其特征信号,中共GFW就有可能封杀。不过,美博认为至今这个弱点并没有显现。

V2Ray的若干代理方式简评

利用V2Ray核心程序,用户可以开发出多种翻墙方式,而这些方式也各有其特点,常见的:

1)V2Ray + mKCP
特点:连线延迟低,速度更快,但流量大,iOS不支持;有可探测特征信号;不建议使用。
2)V2Ray + TLS
特点:伪装 HTTPS 连线,仅是伪装,有可探测特征信号;不建议使用。
3)V2Ray + Caddy(NGINX等前端)+ ws + TLS
这个有美博教程:自建最强科学上网2:V2Ray+Caddy+Tls+WebSocket
特点:这种方法引入了前端处理,将代理服务器隐藏于真正的网页浏览之中,是网友期待已久的一个完美的翻墙办法,因为即使是中共发疯,也不至于疯狂到全网封杀最常用的 port 80、443 的连线。这种方式的优势就在于只要能通过 端口80, 443 的连线,就能翻墙;而理论上 GFW 要封亦极困难,基本上没可能在不杀错“良民”的情况下禁止 HTTPS 连线。ws(WebSocket)是一种在单个TCP连接上进行全双工通信的协议,解决了HTTP协议的部分问题。ws用在V2Ray上时,请求与应答的效率要远高于HTTP,而V2Ray的请求本就远高于普通的请求,ws对V2Ray就是一个很好的搭配,而且ws已经很成熟,Cloudflare等云服务商也支持基于WebSocket流量的CDN服务,进一步增进了服务器的安全性。由于WebSocket基于TCP协议,保证了链接的可靠性,但也有TCP效率和带宽较低的问题,但是,我们在建立V2Ray代理时开启了BBR加速也可弥补这方面的缺失。WebSocket还有一个缺点是明文传输,与服务器的通信内容可能被第三者探测或攻击,但我们的V2Ray开启了前端网站,也就避免了只做纯代理的这个问题。
4)V2Ray+h2+TLS
这个有美博教程:自建最强科学上网5:V2Ray + Caddy + Tls + HTTP/2
这个方法类似 3),h2本质是HTTP协议,比传统http1.1协议传输速度快,较之类似的WebSocket协议,传输效率略逊于WebSocket。h2+TLS这种协议能使V2Ray流量伪装在正常流量中更难以察觉。
从理论上讲:websocket是http1.1,HTTP/2协议包含了websocket的功能,而Caddy支持HTTP/2代理,所以,自建5略优于自建2,当然这是理论上,从实际使用上美博觉得自建2还要稳定一些,所以二者可等同使用。
5)V2Ray+QUIC/HTTP3
QUIC是谷歌制定的一种基于UDP的低时延的互联网传输层协议。QUIC融合了包括TCP,TLS,HTTP/2等协议的特性,基于UDP传输,UDP效率更高,但可靠性比不上TCP。若作为代理,由于协议本身太新,目前这类流量在网络并不太多,若大量流量指向一个IP会不会被觉察?V2Ray的QUIC、HTTP3,有没有一些兼容问题,美博还没有测试,等测试后若真的效果好,我们再补充教程。

关于caddy

美博这几种自建教程中后来选择使用Caddy,Caddy和常用的Nginx、Apache等Web服务器相比,最大的特点就是部署简单,它拥有基本的apache或者nginx有的web server模块,同时还有一些很有特色的功能,比如: HTTP/2、Automatic HTTPS、Multi-core、Websockets、Markdown、IPv6等等。用来作为搭建代理的前端是很好的选择。

不过,Caddy正在大改版,从v1跳升到v2,但是它的糟糕之处在于v2并不兼容现在广泛使用的v1,对于正在广泛使用v1的用户,Caddy也是不太负责任的,其v2与v1路径、命令等都有差异,使v1用户原本的应用在不知道的情况下被官方改变(删除)而不能使用,这导致全网v1用户都出现问题,并非只是美博遇到,它这个实际上不是v2,是一个全新的版本。本来Caddy_v1很多人觉得好用的命令和设置,在 v2版给删除了,其配置命令更趋近于Nginx,简直是倒车、用户体验也不太好,有网友是其想可能是要靠近Nginx,争夺Nginx的前端大饼。

所以,美博的自建教程在本次修改之前出现了一个空窗期(大约一个多月),里面的配置链接被Caddy官方改变了,不能使用,导致网友建立代理出现问题。

美博这次(2020-05-18)已经修改了教程,去掉了对官方配置下载的依赖,直接在自建时设置。

尽管有上面的变故,Caddy v1 用来与这几个代理搭配仍然不失为目前的最佳选择。

我们利用Caddy只是作为前端网页反代和SSL证书申请及续签,Caddy v1已经足够,如果没有大的变动,美博不考虑升级v2。

V2Ray小结

也就是说,目前V2Ray的最好的常用稳定的方式是: V2Ray + Caddy(NGINX等前端) + ws + TLS 或 V2Ray + Caddy + h2 + TLS,也就是美博教程中介绍的方法。

使用 ws (WebSocket)或 h2 + TLS + Caddy等 伪装的好处:从外面看完全属于通过443端口访问正常的HTTPS网站,websocket、h2的path(即美博教程中的/vv22)被TLS加密不能被探测到,TLS不是伪装、也不是混淆,而是真正的HTTPS,看似浏览网站其用途合理就不会被封锁探测到。从上网记录上来看,代理流量被识别为正常的应用和通讯。

V2Ray代理的安全禁忌:一定要保密!

既然V2Ray可以把代理隐身于茫茫网络数据大海之中,而不被探测、被封锁,这是其技术优势,那么这个代理的创建者和使用者要对其保密也就是至关重要和基本前提,有网友时不时来信希望美博帮忙做一些大家都可以使用的V2Ray代理。

美博要在这里提醒大家的是:只要V2Ray代理公开,你的代理IP和域名就会被人知晓,那么这个代理通过最简单封锁ip和域名的方式就可以被封杀、或者置于不安全的被监控的境地,这对于一些安全要求高的网友要特别注意这一点,一定要保密你的V2Ray,这是基本和前提。

一旦ip和域名被人知晓,通过查询ip和域名等信息,就可能了解到代理拥有人的一些基本信息。

三、trojan的特点及与V2Ray的异同

请注意网上关于trojan搭建代理,也有不同方式,美博介绍的 trojan+caddy 这种方式是目前最好的trojan应用方式。

概括而言,trojan就是V2Ray这种方式(V2Ray+Caddy+ws+TLS)的简化版。

v2ray是一个网络框架,功能齐全;trojan是一个绕过防火墙的工具,轻量级、功能单纯;若二者都使用TLS加密,理论上trojan比V2ray性能更好,所以很多网友觉得trojan代理速度比较快。

v2ray内核用go语言开发,trojan是c++实现;v2ray和trojan都能实现https流量伪装。

详细来说,trojan 采用常见的协议HTTPS,没有使用特别的协议。trojan在建立连接的过程中考虑了现行加密协议的不足,也参考了传统网站服务器的连接过程,trojan似乎有意识的将它trojan服务器伪造成只处理 HTTPS 流量的Caddy/Nginx服务器,这很好。trojan默认监听443端口,其思路是把 trojan代理数据伪装成正常的 HTTPS 通信,对于任何其他访问数据则直接转发到80端口,通过caddy、Nginx等web服务器提供网页访问服务,其他人访问你这个443端口就会跳到你设置的网页页面。当trojan客户端连接到服务器时,首先执行真正的 TLS 握手,若握手成功,则所有后续流量都将受到保护TLS; 否则服务器就立即关闭连接,就像任何HTTPS服务器一样。这样VPS更像一个正常的web服务器,使得 GFW 认为是 正常HTTPS。trojan反侦查采用主动检测与被动检测,而不会被识别出来。caddy+trojan一起合用是很好的组合,trojan绑定在0.0.0.0:443上,转发非trojan流量到 caddy 达到掩护的目的。caddy绑定在0.0.0.0:80上,并自动重定位到https加密浏览。

trojan的方法类似于上面介绍的 V2Ray+ws+TLS,其协议差异并不大。两者建立连接的过程有区别,从流量本身是难以发现区别的。也就是说,对于第三者的监听,这两类协议与普通流量表现均一致,这是两者的共性。

V2Ray是Caddy/Nginx侦听443,数据 → Caddy/Nginx → V2Ray;trojan是自己侦听443,都是伪装成网站。准确的说,以前的ssr是伪装,而trojan和V2Ray的ws+tls其实已经不是伪装,是完整的真正的tls。

V2Ray更专业,功能全面,套两层加密更安全(前提是服务器和本地数据不泄露,使用强root密码/仅使用公钥登录),能套CDN,相对的的速度较慢;trojan更简单、少一层加密,所以理论上速度会快一些。

trojan默认使用tls1.3,V2Ray自 4.18.1版后也支持 TLS1.3 ,传输层加密都支持tls1.3,这一点二者没有区别。

trojan有多线程,V2Ray 在客户端可选择 Mux(多路复用 multiplexing)使所有流量走单线程。所以有人发现长时间的高能使用trojan,服务器的trojan线程越来越多,服务器CPU越来越高,最后可能会死掉。当然,作为代理服务器,除非是商用,个人使用很少出现这种情况。

trojan不能用CDN,不要开启CDN。V2Ray可以使用CND。

一台VPS上可以同时安装 V2Ray ws+tls 和 trojan,但要注意端口控制和传输阻塞。但美博还是不建议同时安装。现在的VPS已经很便宜,建立个人代理买最便宜的VPS都行。

理论上来说,trojan可以永久地穿越Great FireWall,而不会被识别出来。

四、NaiveProxy的独到之处

正如美博教程所述:NaiveProxy是比较新的代理项目,与trojan类似也采用HTTPS协议,但有其独到特点,NaiveProxy可减轻流量指纹识别(特征)、主动探测和数据包长度分析的GFW审查带来的风险,就是说更难被墙检测和封锁。而且,设置比v2ray、trojan还要简略一些。

据官方介绍:NaiveProxy 使用Chrome的网络堆栈来伪装流量,与自定义的网络堆栈(如:Shadowsocks、V2Ray,手工Golang堆栈)相比,具有更强的抗审查能力和更低的可检测性。复用Chrome堆栈使得NaïveProxy在(代理)性能和安全方面有最佳的表现。

NaïveProxy可缓解以下几种方式的流量攻击:

# 网站指纹识别/流量分类:通过HTTP/2中的流量复用来缓解。
# TLS参数指纹识别:因复用Chrome的网络堆栈而不能识别。
# 主动探测:被前端应用所克制,即将代理服务器隐藏在具有应用程序层路由的常用前端后面。(美博注:这应是指反向代理)
# 基于数据包长度的流量分析:通过长度充填来减免。

NaiveProxy 使用Chrome的网络堆栈,GFW墙(审查器)拦截的流量行为与Chrome和标准前端(例Caddy,HAProxy)之间的常规HTTP/2流量相同,没有特征信号。前端还会将未经身份验证的用户和活动探针重新路由到后端HTTP服务器,从而使得无法检测到代理的存在,即:探测Probe → 前端服务器 → index.html(网页)。(美博注:这个部份在v2ray、trojan也都有实现)

正因为其抗指纹识别的独到之处,有人测试比较过几种代理的TLS指纹,结果NaiveProxy独领风骚。

所以,美博教程的NaiveProxy+Caddy,我们也推荐大家与v2ray、trojan等同使用。

总之,trojan、NaiveProxy的出现,借用广泛普及使用的HTTPS协议本身来隐身翻墙,置翻墙于无形,这是重大的技术突破。

五、关于代理性能与速度

谈到这三种代理的性能和速度,网上有一些网友進行了一些零星的测试。美博认为,翻墙技术最重要的在于安全,因为现在的服务器性能提升很快,一年一个样,基本上建立的代理性能即使是比较差一点,服务器都能完全承受并良好运行,至于各个代理的速度,美博也测试过,其实差别也不大,而对于网友上网来讲的感觉并不很明显,而且各个地区也有差异。而且,这些代理与以前的很多代理方法相比,已经都算是相当快了。所以,这些方面不是我们关注的重点。建成、实用、安全,对于代理来讲才是最重要的。

六、关于机场

SS(shadowsocks)的出现是当时翻墙方法的一个突破,后因其协议和特称被识别及国内开发者被中共国安抓去喝茶而停止,后来国外网友继续开发这一项目命名为SSR。
SS/SSR的LOGO,是一个纸飞机的图案。那么建立SS/SSR代理的翻墙服务基地(网站)就被形象的称为“机场”(纸飞机落地的地方)。后来,把提供建立众多SS/SSR、V2Ray、trojan等这些代理服务的场所(网站),概括都叫做“机场”,很显然,这一新名词的流行也是要规避中共关键词的过滤,其准确的含义是“代理服务商或代理服务器提供商”,当然里面有免费的代理提供,更多的是需要付费的,对于用户来讲就是买一个代理来使用。根据“机场”的要求,购买后,填入必要的设置就可以开启代理,可以正常浏览被墙封锁的所有网站了。

对于机场,方便了不会建立代理的网友,有人帮忙建立好了,只是使用即可。

美博建议:

因你无法确认机场背后的主人是谁?在哪里?做什么的?就像是现在已经确认的事实,国外的大多数VPN实际上是中国的,很多是有中共背景的陷阱,若使用到那种代理,就会置自己的安全于危险之中。

当然,如果你能够确认机场主人是可靠的,可信的,没有安全疑虑的,当然那是可以使用的。

总之,对于安全性要求高,或者有安全隐患的网友,美博还是一贯的主张,建议自己学会搭建代理,一生只花几天的时间就学会了自建代理,一劳永逸,很值得呀。而且最重要的是安全。加上美博的代理自建教程写的很详细,一步一步按照教程去做,基本上都能成功搭建自己的代理。

七、更安全的代理使用方法

有些网友要做一些特别的事情,需要特别高的安全保障,如果你已经自建有自己的V2Ray、trojan、NaiveProxy代理,那么这就简单了,用V2Ray、trojan、NaiveProxy作为tor的前置代理,二者配合起来使用,速度虽然会慢一点,但安全、匿名度高,对于安全要求高的网友是目前最安全、稳妥的隐身方法。

当然,安全的基本要求前提是:你的电脑必须是安全的,这是大前提,如果电脑不安全,其他上网代理安全就无从谈起。

八、结论

至今,V2Ray、trojan、NaiveProxy 代理仍然是目前最好的代理,网友若有一些基本的电脑知识,美博的教程写的尽量的详细就是要适合新手操作。美博一直建议尽可能的学会自建这些代理,尽管开始学可能会多花几天时间,但学会以后就几乎是一劳永逸,邪墙再也封锁不了你上网了,而且安全、快速,这几种代理隐藏身份的效果是目前最好的,所以,建议大家都来学学自建。

每多一个人学会自建,共产党的邪墙就多一个崩溃的窟窿,千万人、亿万人都能自建,邪党墙就形同虚设了,不攻自破了。

以前一些著名代理软件,比如利用公共服务等来做代理,早被邪党识别其特征,所以只有不断更新来维持,新版一推出很快又被封杀,所以技术尚待更新。而这几种代理V2Ray、trojan、NaiveProxy 几乎趋近完美,代理服务就像是浏览真正的网站,目前都是安全可靠的,再次建议大家都来学学自建。

首例!违反 GPL 协议致侵权,被判赔偿 50 万元

https://www.oschina.net/news/159435

https://twitter.com/txyyss/status/1436004934697115651?s=20
这是大好事啊,对后续类似案件应该有正面影响。我现在有种我国也是判例法的错觉了。--- Shengyi Wang

近日,一起关于 GPL 版权纠纷案裁判文书公示。一审判决书显示,GPL3.0 协议是一种民事法律行为,合同性质,可认定为授权人与用户间订立的著作权协议,属于我国《合同法》调整的范围。一审判定两侵权被告公司赔偿原告公司经济损失及维权合理费用共计 50 万元,并停止侵权行为。

此判例可以说是中国首个明确 GPL3.0 协议的法律效力的案例。判决书显示,明确违反开源软件许可证的侵权法律责任,一方面可以及时制止侵权行为,防止他人对开源软件的不正当利用;另一方面能够有效保护授权人的利益,使他们保有继续创作的动力,促进源代码共享和知识的传播。

不过值得注意的是,本案中被告的侵权事实成立,是因为违反 GPL3.0 协议导致 GPL3.0 协议自动解除,被告失去了 GPL3.0 协议下的源代码授权保护,进而构成侵权。

判决书中对于违反 GPL3.0 协议的侵权责任明确如下:

关于违反 GPL3.0 协议的侵权责任。

著作权法为了保护权利人的专有权,仅规定非权利人可以在如“合理使用”等范围内使用作品,诸如复制、修改、发行等权利则专属于权利人,任何人非经许可实施这些行为将构成侵权。

根据 GPL3.0 协议第 8 条“终止授权”的约定,授权人许可用户在遵守许可证规定的前提下行使某些权利,但用户必须承担相应的义务。若用户违反 GPL3.0 协议的使用条件来复制、修改或传播受保护的作品,其通过 GPL3.0 协议获得的授权将会自动终止。

对此,我国《民法总则》第一百五十八条规定:“民事法律行为可以附条件……附解除条件的民事法律行为,自条件成就时失效”。

根据开源软件的特性,GPL3.0 协议规定的使用条件(如开放源代码、标注著作权信息和修改信息等)系授权人许可用户自由使用的前提条件,亦即协议所附的解除条件。一旦用户违反了使用的前提条件,将导致 GPL3.0 协议在授权人与用户之间自动解除,用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为,因失去权利来源而构成侵权。

本文案件相关内容整理自一审判决书。

案件概况

原告:济宁市罗盒网络科技有限公司

被告:福建风灵创景科技有限公司(以下简称福建风灵公司) 

被告:北京风灵创景科技有限公司(以下简称北京风灵公司)

(福建风灵公司系被告北京风灵公司的全资子公司)

被告:深圳市腾讯计算机系统有限公司(以下简称腾讯公司)

原告济宁市罗盒网络科技有限公司独立开发“罗盒(VirtualApp)插件化框架虚拟引擎系统 V1.0(简称 VirtualApp V1.0)。VirtualApp 从 2016 年 7 月 8 日的版本开始引入开源协议,起初为 LGPL3.0 协议,2016 年 8 月 12 日更换为 GPL3.0 协议。

2017 年 10 月 29 日,原告公司在 VirtualApp 后续开源版本中删除“适用 GPL3.0 协议”的表述。

2017 年 11 月 8 日,原告公司为 VirtualApp V1.0 取得计算机软件著作权登记证书,依法享有 VirtualApp V1.0 软件著作权的全部权利。

2017 年 12 月 30 日由 Lody(原告公司股东、VirtualApp 项目人罗迪) 提交的更新(对应 Git 码为8e6d9cd925af55b53a7e93046c469dd69676c38b)的 CHINESE.md 文件内载明“VirtualApp(中文名为罗盒)2017 年 8 月份正式公司化运作,当您需要将 VirtualApp 用于商业用途时,请务必联系 QQ1*****购买商业授权……VirtualApp 源代码将于 2017 年 12 月 31 日停止更新”。

2018 年 9 月,原告调查发现名为“点心桌面”的软件使用了 VirtualApp V1.0 的代码,将两个软件源代码进行分析比对,两者间 421 个可比代码中有 308 个代码具有实质相似性,有 27 个代码具有高度相似性,有 78 个代码具有一般相似性。因此,被诉侵权软件与涉案软件构成实质相似。

原告向法院起诉,庭审时明确诉请为判令如下:

1.被告福建风灵公司、被告北京风灵公司立即停止侵害原告的计算机软件著作权,即立即停止通过互联网提供所有版本的“点心桌面”软件的下载、安装和运营服务;

2.被告福建风灵公司、被告北京风灵公司赔偿原告经济损失 2000 万元;

3.被告福建风灵公司、被告北京风灵公司赔偿原告为制止侵权行为而支出的合理费用 50 万元;

4.被告福建风灵公司、被告北京风灵公司承担本案诉讼费用。

证据显示,被告福建风灵公司系被诉侵权软件“点心桌面”的著作权人。被告北京风灵公司亦被有关互联网平台标示为“点心桌面”的开发者,并被登记为“点心桌面”软件的著作权人。此外,提供被诉侵权软件下载、安装和运营服务的“点心桌面官网”和“应用宝”网站分别由被告福建风灵公司和腾讯公司经营。

立案之后,经查,被诉“点心桌面”App(V6.5.8)中使用了原告采用 GPL3.0 协议发布的VirtualApp,同时被告对此亦予以确认。

法院观点

法院认为,该案系侵害计算机软件著作权纠纷,涉及开源软件的相关问题。根据双方诉辩意见及举证情况,该案争议焦点有四方面。法院已就焦点问题给出明确观点。

(此部分为法院观点截选,详情可查看判决书原文。)

焦点一:GPL3.0 协议的法律效力。

法院明确 GPL3.0 协议具有合同性质,可认定为授权人与用户间订立的著作权协议,属于我国《合同法》调整的范围

关于违反 GPL3.0 协议的侵权责任,明确若用户违反 GPL3.0 协议的使用条件来复制、修改或传播受保护的作品,其通过 GPL3.0 协议获得的授权将会自动终止。

焦点二:原告是否有权提起本案诉讼。

一是根据代码托管网站上的上传记录及证明等,原告公司可以证明是 VirtualApp 的著作权人。

二是原告提起本案诉讼无需贡献者的同意或授权,即有权提起诉讼。原因包括:原告公司股东罗迪作为项目人已将 VirtualApp 初始版本的源代码共计 31097 行在 Github 网站上公开发布,此系原告主张权利的基础;本案项目人对“主分支”中 VirtualApp 源代码的形成起到了决定作用;贡献者选择在 GPL3.0 协议的 VirtualApp 项目中上传自己的源代码,贡献者亦将按照 GPL3.0 协议许可其贡献,即视为同意将贡献内容许可给项目人及其他用户使用,并且若开源项目的起诉维权需经全体贡献者一致同意或授权,实则导致维权行为无从提起。综上,原告提起本案诉讼无需贡献者的同意或授权。

三是,GPL3.0 协议中仅限制授权人不得向用户主张任何专利权,而并未限制授权人对违反许可协议的用户主张著作权。因此,原告的诉讼行为并未违反 GPL3.0 协议关于争议解决方式的约定。

焦点三:被诉行为是否侵害原告的著作权。

一是原告虽将 VirtualApp 分为开源版本与商业版本,并且在后续开源版本中删除“适用 GPL3.0 协议”的影响问题。

原告在本案中系以 VirtualApp 开源版本而非商业版本作为其权利基础,故本案中不必对VirtualApp 开源版本与商业版本的关联及影响作出认定。而根据 GPL3.0 协议,若先前版本使用了 GPL3.0 协议,则后续版本也必然受 GPL3.0 协议的约束,因此 VirtualApp 后续开源版本仍然受 GPL3.0 协议的约束。

二是 GPL3.0 协议允许用户进行商用,授权人不得对此作出限制。所以原告主张“点心桌面”App进行商用违反 GPL3.0 协议及其附加条款缺乏理据,法院不予支持

三是被诉“点心桌面”App(V6.5.8)本应当遵循 GPL3.0 协议向公众无偿开放源代码,但被告福建风灵公司拒不履行 GPL3.0 协议规定的使用条件。根据 GPL3.0 协议第 8 条自动终止授权的约定及《民法总则》第一百五十八条的规定,被告福建风灵公司通过该协议获得的授权已因解除条件的成就而自动终止。被告福建风灵公司对 VirtualApp 实施的复制、修改、发布等行为,因失去权利来源而构成侵权。

焦点四:若侵权成立,被告应承担的法律责任。

被告福建风灵公司作为“点心桌面”App(V6.5.8)的开发、运营和发布者,依法应承担停止侵害 VirtualApp 著作权的行为。鉴于被告福建风灵公司系被告北京风灵公司的全资子公司的情形,原告指控两被告共同承担侵权责任合法有据,法院予以支持。

被告腾讯公司对其“应用宝官网”上可能存在的侵权行为制定了相关规则、设置了投诉渠道,且对被诉软件作了及时下架处理。原告亦未对被告腾讯公司提出具体诉请。因此,被告腾讯公司无需承担法律责任。

关于赔偿问题,原告主张以被告福建风灵公司、被告北京风灵公司的侵权获利来计算。鉴于开源许可协议缔约方式和缔约主体的特殊性,导致违约或侵权行为更具隐蔽性,相应法律责任的承担应有助于敦促缔约方诚信履行开源义务,确保开源社区规范、持久的发展。开源软件大多都是免费的,但授权人付出的开发成本是必然存在的,按照侵权获利来承担赔偿责任更为公平合理。

最终,法院酌情确定赔偿数额为 50 万元。原告为制止本案侵权行为所支出的合理费用,计算在赔偿损失数额范围之内。

关于此案的更多细节和法院观点,详情可登陆中国裁判文书网查看此案(2019)粤03民初3928号一审判决书。

一审判决书:

https://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?docId=05f553bd178d4354bb48ad5100c1314f(中国裁判文书网地址)

https://www.iphouse.cn/cases/detail/woznd0v9pek4jx35ovdj8y5gxrm371q2.html?keyword=GPL(其他网站地址)

律师解读

我们邀请专注 TMT 领域的知识产权问题的邓超律师(18611123013)就此案件做相关解读。后续邓超律师将发表深度解读文章,敬请期待!

问题一:此案对后续有关开源软件版权纠纷案件有何具体参考意义?

这个案子据我所知,被告上诉了,所以现在这个判决还没有生效,最后法院怎么认定,还没有最终定论。

但毫无疑问的一点是,违反许可证的义务是会遭到权利人的侵权索赔的。

因为以往国内开源主要是拿来主义,使用国外的代码比较多,但随着国内开发者的不断成熟。将来相关的纠纷会越来越多,这就要求法务和开发人员了解开源的相关问题。

问题二:为什么此案件中,“点心桌面”未被强制开源?

没有要求强制开源是因为原告没有提出这样的要求,那么法院是一个被动的审判机关,不告不理,只被动审理原告提出的请求。

在这个案件中,原告没有选择合同,也就是许可证违约,而是选择了版权侵权这条救济途径。一般而言,版权侵权要比合同违约的救济力度要大,无论从各个方面,这在国内和在美国都是如此。

问题三:如果原告提出了开源的诉求,会如何?

如果原告选择了合同违约这条途径,法院是不是会支持被告将代码强制开源这个问题其实很值得探讨,我个人初步的观点是,法院不一定会支持这种诉请。关于这个事情,我准备近期写篇文章,但我现在初步的看法是要求代码强制开源,在法院不太可能得到支持。

所以,如果违反 GPL 许可证的义务,那么将代码全部开源,更多的是一种理论上的可能。在实践中,以中国和美国的法院为例,我理解支持这种诉求的可能性都非常低。

延伸阅读

GPL 解读文章:

人话解读GPLv3https://my.oschina.net/vigor23/blog/4951596

论“GPL就是给软件开发者们准备的坑”https://my.oschina.net/vigor23/blog/4954734

开源软件、自由软件、Copyleft、CC都是啥,傻傻分不清楚?https://my.oschina.net/vigor23/blog/5138356

夜天之书 #6(Copyleft 相关解读):https://my.oschina.net/u/4489239/blog/5252879

4 個你不該使用 Hola VPN 的理由《2021》

https://twhowto.com/hola-vpn/

如果你是 Hola VPN 的用戶,或者是正在猶豫要不要使用 Hola VPN,那麼你一定不能錯過接下來的內容

在這個時代,使用者付費己經是多數人都接受的觀念,連停車都要收費的時代,為什麼 Hola VPN 願意提供免費的服務呢?

在這篇文章我們將告訴你關於 Hola VPN 的優缺點、以及為什麼那麼「佛心」的秘密


目錄


hola vpn

Hola VPN 優點

一、免費又容易使用

Hola VPN 稱自己為「免費的 VPN」,事實上它的確是免費沒錯,但這也伴隨著一點代價,我們在下面 Hola VPN 的缺點中會提到這一點

安裝相當容易,只要在 Google 搜尋一下「Hola VPN」就能夠找到它的瀏覽器套件,安裝後馬上就能使用

二、輕鬆破解部份網站

Hola VPN 的確能解除部份網站的地區限制,像是 Youtube、或是部份的國外網站,不過 Netflix、Amazon Prime Video、Disney+ 這些只在付費功能中才能解鎖

乍看之下 Hola VPN 真的是佛心來著,但接下來我們將告訴你,Hola VPN 不會告訴你的事


hola vpn

Hola VPN 缺點

一、蒐集用戶的資料

和大多數的免費 VPN 一樣,Hola VPN 在隱私權政策裡就有提到,「我們將蒐集使用者瀏覽過的頁面、網站停留時間、IP 位址、姓名、電子信箱、帳單紀錄

而它們再將蒐集到的客戶資訊賣給第三方的廣告公司來換取利潤,藉以維持 Hola VPN 的營運,這也是我們不建議使用 Hola VPN 最主要的原因

如果您希望使用 VPN 的原因是在於匿名性,無日誌紀錄 Surfshark  NordVPN 才是您該選擇的 VPN

二、沒有任何的加密

首先我們得先談談 Hola VPN 的運作原理,和其他 VPN供應商不一樣,Hola VPN 並不需要花大錢去架設伺服器,它透過共享使用者的資源來運作

你所連線到的 IP 其實是另一個 Hola VPN 的使用者,而在連線的同時,或許也有人正連到你的 IP 來解除網站的地區限制

而更可怕的是由於沒有任何的加密,Hola VPN 是沒辦法保證你的電腦安全的,事實上,Hola VPN 的開發帳號也曾經被駭客盜取過,還因此上了新聞

hola vpn

三、成為殭屍網路的一員

如果你不懂什麼是殭屍網路的話,簡單來說就是由於電腦中毒、或是被駭入,透過程式來操控你的電腦來進行其他動作、指令

想像你什麼事情都沒做,卻有警察上門說有網路犯罪事件,而 IP 位址就是在你的住家,這樣子不可怕嗎?

或許你會覺得有點誇張了,但 Hola VPN 也證實了曾經發生過這件事

四、功能不夠完整

如果你不在乎資安的問題,那麼前三點或許無法勸退你,不過你知道 Hola VPN 其實能做的非常有限嗎?

需要跨區看 Netflix、找更快的 BT 種子,這些 Hola VPN 其實並不支援,Hola VPN 並非變更你的 IP,而是讓你使用他人的 IP,即使這次能夠成功,下次同一組 IP 可能己經被網站加入黑名單了

ProtonMail承认因遵循瑞士法律而披露了法国活动家的IP地址

https://www.cnbeta.com/articles/tech/1175851.htm
作为一项专注于端到端加密的托管电子邮件服务,ProtonMail 最近被曝出记录了法国活动人士的 IP 地址。在警方报告揭示法国当局获得了一名使用该线上服务的法国活动家的信息之后,ProtonMail 就一直遭到猛烈的批评。即使该公司已就此事开展了广泛的沟通、且承诺默认情况下并不会记录用户的 IP 地址,但瑞士当局还是对其下达了依法不可拒绝的命令。

 https://www.reddit.com/r/ProtonMail/comments/pil6xi/climate_activist_arrested_after_protonmail/hbqha63/

过去一年,一群人打着要与房地产投机、Airbnb、以及高端餐厅作斗争的旗号,接管了巴黎圣马特广场附近的一些商业场所和公寓。

起初该活动只是一个区域性冲突,但很快演变成了一场象征性的运动。当他们开始入住 Le Petit Cambodge 租用的场所时(2015 年 11 月 13 日的恐袭受害目标),很快就吸引了媒体的高度关注。

2.png

9 月 1 日,该组织在 Paris-luttes.info 上发表了一篇文章,总结了针对该组织部分成员的各种警方调查与法律案件。

具体说来是,尽管 ProtonMail 没有直接与法国当局展开合作,但法国警方还是通过欧洲刑警组织的渠道,向瑞士方面发出了协查请求,迫使其交出了某位线上服务用户的 IP 地址。

3.png

事情曝光后,很快引发了隐私权益倡导者的忧虑。一方面,欧盟议员希望努力找到一个能够合法访问加密数据的方法,即使他们同时声称支持强加密政策。

另一方面,包括 ProtonMail 在内的一些端到端加密服务提供商,也在今年初的一份公开信中发出警告 —— 若欧洲继续推动这方面的立法,或最终走向留下加密后门的危险道路。

 

香港電台 1973 年以來六千多段影片已永存於區塊鏈

https://ckxpress.com/why-depub/

港人無名氏整理了香港電台 1973 年以來六千多段影片,全部註冊 ISCN,賦予每段共同記憶一張賽博空間身份證,向遺忘說不。

無名氏把香港電台 1973 年以來的六千多段影片,註冊在區塊鏈

只是以上幾個例子,已讓我們窺見無大台出版的雛形,顯然跟傳統出版有所不同。DePub 的意義很廣,我們過去已經討論過不少;從實用的角度,把內容出版到區塊鏈,大致有以下幾個目的。

一、存在的證明

現代社會,我們很難想像有父母覺得沒必要為子女申請「出世紙」。對內容也一樣,只要對你來說重要、有意義、有存在價值,就值得為它申請「身份證」ISCN。

雖然拿了內容跟孩子作類比,但孩子是唯一的,數位內容卻可以無限複製,而這個特性,很多時正是我們應該註冊數位內容的根本原因。

利用區塊鏈記錄作者、發表日期、版權等各種元資料(metadata),以產生存在的證明(proof of existence),雖然並不會從技術上阻止其他人複製,卻可以有效證明自己註冊內容在先,而別人複製在後。

試想像網上眾多有趣、發布量極廣的迷因(meme),假如能透過翻查註冊找到照片的出處,甚至追蹤原照片逐步成為迷因的軌跡,將能產生很多前所未有的可能性。

二、出版自由

無大台的一大意義和原則是無需許可(permissionless)。在 DePub 的生態中,這代表任何人都可自由出版。

很多人以為無需許可的出版自由代表胡作非為,不負責任,是個誤解。無大台的大原則是不由一方獨大,避免濫權、自肥、作假、獨裁等各種行為,在出版的意義,體現為避免噤聲產生一言堂;但無大台同樣有方法獲取共識,比如透過流動民主,定義和處理假訊息(俗稱假新聞,fake news)、內容農場等。

三、永恆不變

內容一旦註冊 ISCN,永恆不變。

註冊到區塊鏈的內容,就算原作者都不能竄改(immutable)。就是說,原作者可以修改,但修改記錄完全公開,而其他人則完全不能更改。

不可竄改的特性,除了保障作品不會被肆意修改,也可有效打擊惡意改圖、小量修改網上內容當作原創等行為。至於徹頭徹尾的謊言,雖然不能以技術手段杜絕,然而,不能竄改的特性也會讓假訊息不傾向註冊,避免一旦被拆穿,撒謊的事實也將永久被記錄,不像現時被拆穿就刪帖當作沒發生過那麼輕鬆。

所以說,DePub 非但不意味胡作非為濫用自由,應用得宜更能反過來,幫助事實查核,打擊假訊息。

四、為鑄造 NFT 鋪墊

最近,NFT Non-fungible token 非常火爆,連很多過往對密碼貨幣興趣缺缺的,都躍躍欲試 NFT。我們今日先不討論當下一塊 NFT 石頭都能買幾百萬的現象,但 NFT 為一直以來無限複製的數位內容提供了各種可能性,這一點毫無懸念。

NFT 的核心就是元資料,何時、何地、由誰創作,現在和曾經由誰持有等等。不是每筆內容都應該都值得鑄成 NFT,但發表作品時先註冊 ISCN,把元資料永久寫在區塊鏈,時機到了,ISCN 就能成為 NFT 最穩健的基礎。

NFT 帶起了對元宇宙的關注,而無大台出版的核心 ISCN,則是元宇宙中的元資料,metadata for the metaverse。為內容註冊,就是為內容在元宇宙留下永恆印記。

大家都冒充 `Mozilla` --- 科学的检测用户浏览器

https://a-wing.top/browser/2021/08/22/user-agent.html

用户的特殊浏览器

经常有用户使用奇怪的浏览器,来使用我们的产品,然后出问题。

因为产品上的音视频使用了浏览器的 WebRTC 特性,所以对浏览器的要求就很高

当然,从原则上来看,是不应该根据 User-Agent 来提供差异化服务的,应该使用另一种方式:feature detection

可以使用 modernizr 来进行 feature detection

毕竟 WebRTC 是由浏览器 API 组成,通过探测这些 API 是否存在,来判读是否可以使用 WebRTC

但是这个不够严谨,WebRTC 是很新的东西,有些浏览器可以支持,但是支持不够完整和稳定性都有问题。

Web Real-Time Communications (WebRTC) transforms the communications landscape; becomes a World Wide Web Consortium (W3C) Recommendation and multiple Internet Engineering Task Force (IETF) standards

WebRTC 改变了通信格局; 成为 W3C 和 IETF 官方标准

———— 2021.01.26

所以我们需要去检测用户到底用了什么浏览器,是如何出现了问题的。一个很通用的办法就是检测 User-Agent

从黑曜石浏览器(HEICORE)说起

某年的科大的 CTF 要使用黑曜石浏览器去解题。当然,所谓的黑曜石浏览器是不存在的

不得不说,黑曜石浏览器是我用过最好用的浏览器 用户体验极佳

—— 知乎某用户 如何评价黑曜石浏览器(HEICORE)?

通过设置 User-Agent ,把自己伪装成了黑曜石浏览器

curl http://202.38.95.46:12001/ -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) HEICORE/49.1.2623.213 Safari/537.36"

出自中国科学技术大学第五届信息安全大赛

User-Agent 是什么

用户不能直接去互联网上获取信息,需要一个软件去代表用户的行为,这个软件就是 User-Agent (用户代理)

浏览器就是一种 User-Agent 。用户使用不同的软件去用统一的协议去做相同的事情。

这也是定义在 http 请求里的,每一条 http 请求一定会携带 User-Agent 头

网站的服务者可以通过 User-Agent 头来判断用户使用了什么浏览器,当然也可以根据 User-Agent 的内容来提供差异化的服务

标准语法和历史

原本 User-Agent 浏览器的语法 是很清晰的

User-Agent: <product> / <product-version> <comment>

因为可以根据 User-Agent 的内容来提供差异化的服务,所以当年在浏览器大战时期,浏览器的实现各不相同。 当年 Mozilla (Firefox 的前身)浏览器最强的,很多网站都只对 Mozilla 提供高质量的服务,后来有人把自己伪装成了 Mozilla (没错,就是 IE 先开始的)。 从此 Mozilla/5.0 就变成了 User-Agent 的第一段

后来的浏览就在这上面不断扩充,就像今天这样:

Linux / Firefox

Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Mac OS / Safari

Mozilla/5.0 (Macintosh; Intel Mac OS X 11_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Safari/605.1.15

Chromium OS / Chrome

Mozilla/5.0 (X11; CrOS x86_64 13904.16.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.25 Safari/537.36

Windows / Edge

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4482.0 Safari/537.36 Edg/92.0.874.0

这就变成了,去识别 User-Agent 变得很困难。目前的识别基本上都是使用正则表达式,配合自己的 User-Agent 库来判断

这方面的库有很多,对比很多后,这个库是比较全的 ua-parser-js

目前几乎所有的网站识别浏览器都是 User-Agent 来判断,目前有两个接口:

前端有浏览器接口:

window.navigator.userAgent

后端可以通过浏览器的 http request header 来拿到 User-Agent

user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36

如何使用 User-Agent

另外,在移动端。因为算力的问题,在有些老旧的处理器上也会出现卡顿的情况

当然,我们可以在浏览器里跑一下 Benchmark 来判断算力是否够用

不过,移动端的 User-Agent 会携带处理器信息(可以去查数据库来判断)

综上,目前所进行的操作是:检测用户浏览器,给予提示,并在文档页显示支持性列表

最后,要通过定义的规则生成这样一个表格

browser-list

为了降低未来的维护成本要使用一套数据源,既可以检测,又可以在文档页生成列表

ua-parser-js 的返回结果的数据结构比较科学,直接复用这一数据结构

interface Result {
  ua: string;
  browser: {
    name: string | undefined;
    version: string | undefined;
  };
  device: {
    model: string | undefined;
    type: string | undefined;
    vendor: string | undefined;
  };
  engine: {
    name: string | undefined;
    version: string | undefined;
  };
  os: {
    name: string | undefined;
    version: string | undefined;
  };
  cpu: {
    architecture: string | undefined;
  };
}

这样我们可以定义三条规则:

  • daily_list (某个测试版的浏览器)
  • white_list (测试过没有问题的浏览器)
  • black_list (已知有问题的浏览器)
// 存在优先级关系: daily_list > white_list > black_list
//
// https://www.npmjs.com/package/ua-parser-js
// @params: ua-parser-js.result
// @params: { <list_name>: <whiteList | blackList>}
// @return: string(list_name)
function browserDetect(ua, list) {
  const { daily_list, white_list, black_list } = list
  if (checkList(ua, daily_list)) return 'daily_list'
  if (checkList(ua, white_list)) return 'white_list'
  if (checkList(ua, black_list)) return 'black_list'
  return ''
}

基于这种数据结构,加入一种简单的语法。支持版本号判断,加入这个几种符号的支持:>, , =, <,

由于没有现成可以用的,所以要自己用 compare-versions 写一段判断,遍历整个结构对比全部的版本号

这样的话配置文件就可以这样写:config/browser.yml

# https://www.npmjs.com/package/ua-parser-js
#
# 本文件的语法是在这个库之上做的修改

# 白名单,完全没有问题的版本
white_list:
  - browser:
      name: "Chrome"
      version: ">= 85.0.0.0"
  - browser:
      name: "Firefox"
      version: ">= 85.0.0.0"
  - browser:
      name: "Edge"
      version: ">= 45.0.0.0"
    device:
      type: "mobile"
    os:
      name: "Android"
      version: ">= 10.0"

black_list:
  # 老版本的 Edge 不支持
  - browser:
      name: "Edge"
      version: "< 80.0.0.0"
    os:
      name: "Windows"

  # 手机微信内置浏览器
  - browser:
      name: "WeChat"
    device:
      type: "mobile"

我们的产品的用户上至自己编译浏览器自己用的极客,下至用微信内置浏览器的小白

所以要给使用 beta 版,dev 版,canary 开发版,nightly 版给予提示。这个 WebRTC 不稳定,可能会有问题。

这件事情出现过,有人用了开发版的浏览器,音视频不稳定,然后他又更新了的版本。。。

由于开发版浏览器并不会在 ua 里面携带 dev 的标识。只能通过版本号来判断。可以使用 caniuse-lite 的数据库,取出最新稳定版的的版本号,然后进行版本号比对

但是 caniuse-lite 的数据库有 1.3M 如果直接使用,会打包整个数据库。这个体积的增加了太多

需要优化一下,所以采用把查询结果打包成文件的办法,实际上真正有用的数据非常的少。

创建一个生成器,可以动态创建这个文件 latest_browser_list_generator.js

#!/usr/bin/env node

const browserslist = require('browserslist')
const fs = require('fs')

const list = {
  'firefox': true,
  'chrome': true,
  'edge': true,
}

const latest = browserslist("last 1 version").filter(i => list[i.split(' ')[0]])
fs.writeFileSync('latest_browser_list.js', `export default ${JSON.stringify(latest)}`)

之后定期执行这两个就可以了

  • npx browserslist@latest --update-db
  • node latest_browser_list_generator.js

当然,这个可以用 GitHub action 或 GitLab CI 来每周执行一次

360 浏览器检测

360 浏览器隐藏了自己的 UA 。360 浏览器只有在访问自己的网站(比如:360.cn)是才会在 UA 里携带 QIHU 360SE (360 安全浏览器)或 QIHU 360EE (360 极速浏览器)字段

我们只能使用一下其他的方式,通过一些其他的特征来检测

对待国内浏览器:这个库可以检测到 360

不过这个库的作者并没有提供可以直接使用包。只能把核心代码提取出来

  // https://github.com/mumuy/browser/blob/4a50ee18cc76a5013dea3596bb33fbab9ed584c3/Browser.js#L111-L143
  if (_window.chrome) {
    let chrome_version = u.replace(/^.*Chrome\/([\d]+).*$/, '$1')
    if (_window.chrome.adblock2345 || _window.chrome.common2345) {
      match['2345Explorer'] = true
    } else if (
      _mime('type', 'application/360softmgrplugin') ||
      _mime('type', 'application/mozilla-npqihooquicklogin')
    ) {
      is360 = true
    } else if (chrome_version > 36 && _window.showModalDialog) {
      is360 = true
    } else if (chrome_version > 45) {
      is360 = _mime('type', 'application/vnd.chromium.remoting-viewer')
      if (!is360 && chrome_version >= 69) {
        is360 = _mime('type', 'application/hwepass2001.installepass2001') || _mime('type', 'application/asx')
      }
    }
  }

  // 修正
  if (match['Mobile']) {
    match['Mobile'] = !(u.indexOf('iPad') > -1)
  } else if (is360) {
    if (_mime('type', 'application/gameplugin')) {
      match['360SE'] = true
    } else if (
      _navigator &&
      typeof _navigator['connection'] !== 'undefined' &&
      typeof _navigator['connection']['saveData'] == 'undefined'
    ) {
      match['360SE'] = true
    } else {
      match['360EE'] = true
    }
  }

不过这里要注意:navigator.mimeTypes 已经从 Web 标准中移除(也许未来的某天这个方法就没法用了)

判断 360 的版本,是做了一个版本的对应关系

// https://github.com/mumuy/browser/blob/4a50ee18cc76a5013dea3596bb33fbab9ed584c3/Browser.js#L283-L292
function get360SEVersion(u) {
  let hash = { '86': '13.0', '78': '12.0', '69': '11.0', '63': '10.0', '55': '9.1', '45': '8.1', '42': '8.0', '31': '7.0', '21': '6.3' }
  let chrome_version = u.replace(/^.*Chrome\/([\d]+).*$/, '$1')
  return hash[chrome_version] || ''
}
function get360EEVersion(u) {
  let hash = { '86': '13.0', '78': '12.0', '69': '11.0', '63': '9.5', '55': '9.0', '50': '8.7', '30': '7.5' }
  let chrome_version = u.replace(/^.*Chrome\/([\d]+).*$/, '$1')
  return hash[chrome_version] || ''
}

最后

为了网络环境的健康,为了不重蹈浏览器大战时的覆辙。不要针对特定浏览器提供差异化内容。

我们可以告知用户:「我们没有在这个浏览器上充分测试过」

但不能去禁止某个特定的浏览器,或对不同浏览器提供差异化内容

尽可能使用 feature detection 来判读浏览器的支持情况