标签 DMCA 下的文章

阿里云发布第七代云服务器,并全面兼容 X86、ARM、RISC-V等多种芯片架构

今天阿里云在北京召开 2021 阿里云峰会,一句发布多款新品,包括第七云服务器、一站式数据服务平台、湖仓一体 2.0 等;

阿里云智能总裁张建锋表示,阿里云自研的云计算操作系统飞天已经全面兼容 X86、ARM 、RISC-V 芯片架构。

阿里云作为国内的云计算的先行者, 领头羊,他们的一举一动都会带来行业的跟随,下一步就可以期待各家都对 ARM、RISC-V 等芯片架构的支撑,真正推动 ARM 架构落地服务器领域。

Ubuntu 用户被 DMCA 组织滥发 DMCA 通知

美国电信公司 Comcast 的一个用户在 Reddit 上透露,他通过 BT 下载了 Ubuntu 官方的 ISO 镜像后收到了 DMCA 侵权通知。

DMCA 全称是千禧年数字版权法,用于保护软件创作者作者的原始权利。但法律无罪,人有罪, 当人将法律用在一些坏的途径上时,这法律就成了恶法。

FaceBook 赞助的研究抨击苹果的隐私问题

苹果在 iOS 14.5 后为每一个 App 加入了强制的信息追踪弹窗,以允许用户禁止 App 的针对性追踪。而最近,佛罗里达大学莱文学院的丹尼尔 · 索科尔与哈佛大学商学院的朱锋撰写的论文《Harming Competition and Consumers under the Guise of Protecting Privacy: An Analysis of Apple’s iOS 14 Policy Updates》抨击了这一功能。

学术沦为资本的工具,可叹可笑。

仓库被封禁

在 2018 年 2 月 20 日,我们的开源项目放在 GitHub 上的仓库由于收到了 DMCA Takedown 投诉被封禁,仓库处于不可访问状态。此时在 GitHub 上访问该仓库时,会显示一个公开消息,表明该仓库被封禁的原因。

按照 GitHub DMCA 的规则,GitHub 在确认投诉有效后,会给该仓库的管理员发送一封邮件,提示该仓库需要在 24 小时内清理被投诉的内容,并回复 GitHub 才行——否则,该仓库会被封禁,禁止任何访问和数据导出。

我们在收到该 Takedown 投诉后,会有 24 小时的时间来响应,但由于过年期间,仓库拥有者没有及时看到邮件,未能及时发现这么严重的通知。因此,在过了 24 小时后, Github 按照 DMCA 的规则,进行了仓库的封禁。

仓库被封禁后,我们发现无法访问。根据封禁消息的提示,发现原来之前仓库内的某个文件出了问题,侵犯了原作者的版权。原作者向 Github 发送了 DMCA 投诉。而由于我们的未及时处理,导致了仓库的最终被封。当我们发现被封时,已经是深夜了。

紧急商讨方案

在被封禁后,由于已经超过了 24 小时时限,在这个阶段下, GitHub 的文档中给出的解决方案仅有请求 GitHub 来删除该仓库并根据自己手里的仓库数据重建的方案。但对我们来说,这种方案是不可接受的,因为这种方案会导致丢失所有的 issue、PR、Wiki,以及你本地的仓库和远程的仓库之间的版本差异。

我们在群内先找了更新最全的 fork,找到了一个群友提供的,和上游只差 2 个提交的版本,并将其保存下来,作为最后的自救手段。

此外,在查询 DMCA 的过程中,我了解到 DMCA 除了有 DMCA Takedown 以外,还有一个 DMCA Counter Notice,用于反向解除 DMCA 封禁。

DMCA Counter Notice

DMCA Counter Notice 用于向服务商发起申诉,说明 DMCA Takedown 投诉为恶意投诉且并无版权问题。

延展阅读

https://www.plagiarismtoday.com/2010/06/03/7-common-questions-about-dmca-counter-notices/

https://help.github.com/articles/guide-to-submitting-a-dmca-counter-notice/

当时考虑到我们已经错过了窗口期,没办法删除 GitHub 上仓库中的特定文件,所以想通过 DMCA Counter Notice 来解除封禁。

为此,我通过 Github 发给我们的邮件,找到了那份侵权文件,并在他的网站中找到了版权拥有者的邮件,发送邮件说明情况,看看能否通过付费获得授权。但其是挪威人,存在时差,所以我们只能边等待,边想办法。

山重水复疑无路,柳暗花明又一村

在准备 DMCA Counter Notice 时,我们又向 Github 发送了邮件,说明了中国春节的特殊情况,导致我们没有来得及处理文件,请求给我们一个机会让我们处理这些文件。但是迟迟没有回应,无奈之下,多位成员又以成员身份向 GitHub 发送邮件,请求给予帮助。

令人惊奇的是,经过大约 9 个小时的等待,仓库拥有者的请求邮件似乎开小差了,而各位成员的请求邮件得到了响应。Github 回信给大家说,根据其规则,给出了额外的 24 小时窗口期,让我们处理这些文件(后来经过仔细查阅 GitHub 的 DMCA Takedown 规则,对这种错过了第一次窗口期的情况,可以给予第二个,也是最后一个窗口期)。但是这个开启额外的窗口期,需要仓库的拥有者向 GitHub 发送邮件请求。

然后,我们就以仓库拥有者的身份再次向 GitHub 发送了请求,可能是由于时差的原因,又是几个小时没有回应。

与此同时,我们也收到了版权拥有者的回复。很遗憾,原作者不愿意授权,也不打算收费。好在 Github 给的额外窗口期,让我们有了改正错误的机会。

还好,在焦急的等待之中,我们终于收到了 GitHub 的回复,并同时恢复了仓库的访问——宝贵的 24 小时窗口期。

使用 BFG 处理文件

得到了窗口期后,我们开始处理仓库内的文件。

首先,你得清除了现在还在仓库里面的文件,然后再使用下面的方面来清除提交历史中的数据。

推荐阅读

以下文章建议按顺序阅读

https://help.github.com/articles/removing-sensitive-data-from-a-repository/

https://rtyley.github.io/bfg-repo-cleaner/

删除 Git 仓库的历史数据有多种方法,一种是使用 git filter-branch来处理,但是速度极慢。另外一种就是使用 BFG 来处理,我们采用的是 BFG 来处理(BFG 是git filter-branch 首字母的逆转)。

BFG 需要 Java 的运行环境,如果无法运行,请检查你的本地 Java 环境是否安装,或高于 Java 7 。

Java 6 需要使用 bfg v1.12.3版本

BFG 的处理过程比较简单,首先,你需要下载 BFG。

wget http://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar

然后克隆你的仓库到本地,比如 bestony/test

git clone --mirror  git://github.com/bestony/test.git

克隆时用不用 --mirror 模式都可以,但是后续命令上会有所差距,所以我还是推荐大家使用镜像模式,毕竟按照官方的文档走,出现了问题也好搜索。(镜像模式克隆的仓库和远程仓库完全一样,但是不能直接看到仓库里面的文件,而且也不能允许 git 的各种命令)

克隆到本地后,执行 BFG 命令来处理文件。

cd test.git
java -jar bfg.jar --delete-files "filename"

这里需要注意的是,filename 不支持目录路径,只能是文件名,而不能是 dir/filename 这样的形式,所以添加参数时你要注意这个。对于有同样名字的文件却想只删除某个目录的情况,可能就没有办法了。

此外,默认情况下, BFG 不会处理最新的提交,它认为你的最新提交应该是干净的(不包含需要删除的敏感数据),如果你要删除的文件是最新的提交(比如你最新的一个提交是删除那些敏感数据),可以加入--no-blob-protection参数来强制清除,也可以再添加一个提交,使包含了要被删除文件的提交不是最新的提交。

java -jar bfg.jar --delete-files "filename" --no-blob-protection

BFG 处理完成后,会提示你使用 git 命令进行垃圾回收,你需要执行如下命令来操作:

cd test.git # 进入目标目录
git reflog expire --expire=now --all && git gc --prune=now --aggressive # 垃圾回收
这里需要注意的是,如果你删除多个文件,每次删除后执行和多个文件都删除后效果一样,所以建议你删除多个文件后再进行垃圾回收,会更省时一些。

处理完成后,将数据推送到远端即可(需要关闭 GitHub 上仓库设置里面对强制推送的防护):

git push

执行完成后,就可以到远端上去看了,你的文件会被删除,相关的提交不会被删除,但是提交里面不包含该文件了。

在推送时,可能会提示你有些更改被拒绝了,这些更改如果是和 Pull Request 有关的,你可以不需要在意,这是 GitHub 自身的问题。Github 设定 Pull Request 是只读不可改的。所以我们无法修改这些信息。

具体可以参考 https://github.com/rtyley/bfg-repo-cleaner/issues/36

至此,我们将文件进行了删除处理,并清除了相关的数据。

后续处理

在完成文件及历史数据的删除后,我们将我们的删除结果回复了 Github ,等待 Github 的确认。GitHub 会在 24 小时收到该回复后,会通知投诉方进行确认。如果投诉方无异议,此事就此结束,不会再有下一步动作。如果有异议,则会重新进行此流程。

此外,由于 GitHub 存在垃圾缓存回收的时间差,所以你推送到 GitHub 上的数据虽然并无需要被删除的文件,但是依旧在一定时间内可以看到。这种缓存只能请 GitHub 自行操作删除。此外,与要删除的文件相关的 Pull Request 也需要 GitHub 来删除——因为用户是没有权限删除 Pull Request 的。这些请求也可以一并发给 GitHub 来操作(但似乎 GitHub 并不热衷执行这些请求,只要被投诉的文件访问不到即可,也就是说,如果没有被投诉历史数据,其实或许并不用大动干戈清理历史……)。

这种清除操作还有一个副作用就是,所有之前 fork 的仓库,由于主仓库被封禁而导致各个 fork 仓库的 remote 意外地变为另外一个仓库(该仓库是最早的一个 fork 仓库)。而主仓库恢复之后,我们并没有找到好的办法将 remote 恢复回原来的主仓库。因此,需要所有成员重新 fork 主仓库并从缓慢的 GitHub 克隆到本地。

余思

这个惊魂事件当中,我们首先要反思的是,我们对版权问题的认识不足,这是一切问题的根源。因此,这之后,我们对既有数据进行了排查。

其次,GitHub 在这种事件的处置上,我们认为也并不够好。这么严重的处置(整个库封禁),仅仅通过一份普通的邮件通知,而且仅仅给出 24 小时的时间窗口。而 GitHub 其实掌握了仓库拥有者的更可靠、更及时的联系方式,比如说手机短信,也完全可以在 GitHub 的网页界面上以显目的方式提醒。另外,虽然 DMCA 规则中提到了可以容情第二个时间窗口,但是似乎这个附加窗口期是后来才改变的政策,在前面的流程说明中并未提及,很容易忽视。

其三,由于封禁会导致对该仓库的所有访问均不可进行,这不仅包括了提交数据,也包括了并没有存在于 Git 仓库中的 issue、PR 和 Wiki 等数据,而 GitHub 不会让你在封禁的情况下有机会导出这些数据。所以,有机会的话,各种数据还是有个备份的好。

最后,感谢在这个事件中,所有不离不弃支持我们的成员,感谢小白进行的仓库清理工作。

相关阅读