@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 回复文章

    如何评价小号海?

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

  4. 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/
    好不好用可以亲自尝试, 我们应该只管传播来让更多人亲自尝试, 切勿透露自己的网络环境(比如自己是否测试过, 是否好用, 而且你透露了也没用, 你当时的时间与环境好用不等于别人的时间与环境下好用), 这种评测透露丝毫帮不到别人(也就是毫无积极意义), 只能使得自己暴露更多网络环境信息增加被查找到的风险(比如根据有效时间, 可以确定大致地区, 然后如果你又提到自己的链接速度那么还可能根据日志计算出当时匹配的传输速度对应到更精确的范围, 运气不好甚至就直接对应到个体了).