@Phantasialand
@Phantasialand
关注的小组(2)
动态 帖子 2 评论 4 短评 0 收到的赞 1 送出的赞 6
  1. Phantasialand   在小组 2047 回复文章

    (转载)I2P-Bote:基于I2P的随机高延迟匿名电子邮件

    说到去中心论坛, I2P已经有一个 Syndie, 但它似乎不支持去中心分布式的随机高延迟转发, 去中心只是体现在没有固定服务器, 内容本身加密存放在多个 Archiver 上, 不会因为2049那样服务器到期而丢掉帖子.
    另外 Syndie 客户端已经好几年没有更新, 感觉就是个粗制滥造半死不活的 Prototype , 真要用 Syndie 从事高风险活动需要考虑软件漏洞问题, 在高风险活动时应该像编程随想说的那样严格虚拟机甚至物理主机隔离.

  2. Phantasialand   在小组 2047 回复文章

    (转载)I2P-Bote:基于I2P的随机高延迟匿名电子邮件

    I2P-Bot 不同于普通的I2P服务, 不仅基于 I2P , 本身在 I2P 网络上也是去中心多层随机高延迟转发设计, 记得早期论坛就是电子邮件, 说不定用这个东西有希望搞一个去中心随机高延迟I2P匿名网络论坛?

  3. Phantasialand   在小组 2047 发表文章

    小号海模型收集, 欢迎各位贡献模型和思路

    受到隔壁葱岛的启发, 我想到一个模型来改善小号海质量: 论坛分为两个部分, 一个是经过严格筛选的高质量管理用户区(相当于编程随想博客里的墙外资深读者(在墙外(低风险), 不会写但至少能看懂编程随想博客)), 一个是小号海区(编程随想应该在这里活动).
    用户可以根据自身的风险等级决定主要在哪个区活动.
    小号海区适当使用验证码等机制阻止机器快速刷屏, 注意这里只是阻止机器过快刷屏, 并不是阻止人类低质量表达, 当然这个看站长倾向, 如果阻止fools可以像本站一样, 当然小号海也可以分区, 比如验证码小号海区, 答题考试小号海区等等.
    管理员在管理任何小号海区时发现高质量帖子就及时迁移部分或全部楼层到高质量管理用户区;注意迁移应该不影响小号海区的回复, 必要时高质量管理用户可新建编辑高质量区的帖子与楼层来反应小号海区里的高质量帖子和楼层.
    管理员区和所有小号海区都可选择是否延迟发布, 延迟发布可由用户自行设定, 包括用户手动设定和服务器自动默认随机决定.
    管理员区经过筛选之后可以使用公共帐号来管理和映射小号海区内容.
    虽然隔壁葱岛有管理员, 但似乎并没有如此系统的组织分工, 隔壁主站虽然有类似措施但注册严格, 发帖几乎只能使用固定身份, 不利于保护发言用户, 也就是强迫所有用户都进入"高质量管理用户区"了, 但墙内高风险高价值目标是不应该进入"高质量管理用户区"用固定身份发帖.

  4. Phantasialand   在小组 2047 回复文章

    如何评价小号海?

    @ygdvv1 #144376
    这其实是一种权衡, 仓库确实只有粮食而没烤鸭吃, 但你愿意冒着吃枪子儿的风险去吃烤鸭吗? 另外隔壁葱岛只是管理标准比较低所以显得垃圾, 真正刷屏和纯五毛还是会被管理员删掉的.

  5. Phantasialand   在小组 2047 回复文章

    为什么你们非要认为抓住编程随想的前提是识别出了Tor流量?为什么不能就是单纯十多年隐蔽而缓慢积累的时间相关性(缓慢小幅度调整GFW的设置逐步试探)?

    @NullPointer #144505 以后 Meek-Azure 确实不能用了, Azure 的 Domain Fronting 关闭后 Tor 官方也不打算再继续支持 Meek 了, 而是用Snowflake代替:https://gitlab.torproject.org/tpo/applications/tor-launcher/-/issues/40007#note_2733662
    关于账户抛弃, 他虽然贡献很大但指着单个人显然是不切实际的, 个体终究会因为各种原因失去贡献能力, 过时的手段不能指望失去贡献能力的个体去更新.
    现在的问题是我们无法确定编程随想是否真的被抓, 如果有办法能证明编程随想真的被抓了, 也就说明我们应该严肃认真的考虑小号海如何改进质量的问题, 相反如果能证明编程随想安全, 楼主就是在杞人忧天.
    但其实就算编程随想被证明安全, 我们也仍然应该想办法探索小号海, 如果质量和安全能两全其美那再好不过.
    关于翻墙体验:

    It has the convenience of Meek, but can support magnitudes more users with negligible CDN costs.

    来自:https://github.com/keroserene/snowflake 关于小白用户体验, Tor 官方正在尝试进一步改进, 很快就会发布:https://blog.torproject.org/improving-ux-connecting-to-tor-105
    关于 Snowflake 行不行:
    我觉得现在 Snowflake 的最大缺陷是它跟 Meek 一样依赖 Domain Fronting, 也就是说 Domain Fronting 一旦被全部厂商禁止, 现行的 Broker 就无法工作了, 也许 Tor 未来会学习 I2P ? 我不知道.
    无论如何, Snowflake 是现在就能在 Alpha 版用:https://support.torproject.org/zh-CN/censorship/how-can-i-use-snowflake/
    好不好用可以亲自尝试, 我们应该只管传播来让更多人亲自尝试, 切勿透露自己的网络环境(比如自己是否测试过, 是否好用, 而且你透露了也没用, 你当时的时间与环境好用不等于别人的时间与环境下好用), 这种评测透露丝毫帮不到别人(也就是毫无积极意义), 只能使得自己暴露更多网络环境信息增加被查找到的风险(比如根据有效时间, 可以确定大致地区, 然后如果你又提到自己的链接速度那么还可能根据日志计算出当时匹配的传输速度对应到更精确的范围, 运气不好甚至就直接对应到个体了).