Help talk:如何访问维基百科
![]() | 测试方法
|
![]() | 留言之前务必记得用~~~~ 签名。 |
![]() 存檔 |
---|
|
Android(移动)端的直接连接方法
似乎#直接连接方法中的所有方法都只能在电脑上使用?有没有能在Android端使用的类似方法?(注意,我指的不是使用代理服务器的方法)--Wnotieagusdr(讨论 | 贡献) 2024年2月1日 (四) 06:10 (UTC)
- 见“本地代理工具”,Accesser可以在Termux中运行[1],然后你要配置浏览器使用
http://localhost:7654
代理。--Shinohara Chihiro(留言) 2024年2月1日 (四) 07:23 (UTC)- 我不太会用,还遇到了问题……先问一下我的操作对不对:一行一行地输入这个链接中的命令。但这样,我在执行
python -m pip install -i https://mirrors.bfsu.edu.cn/pypi/web/simple --upgrade pip
时遇到提示(红色字):ERROR:Installing pip is forbidden, this will break the python-pip package(termux).
这该如何是好…… - --Wnotieagusdr(讨论 | 贡献) 2024年2月3日 (六) 07:17 (UTC)
- 这段错误是因为Termux不允许pip自己更新自己,只允许通过其pkg包管理器更新它。这行命令不是必要的,你可以直接略过。--Shinohara Chihiro(留言) 2024年2月3日 (六) 09:37 (UTC)
- 抱歉啊,作为非专业人士,我觉得在没有一个系统的教程或者便捷的方法的情况下,我可能是没法完成了(笑)。我把每一步都做了,最后却连网都连不上了,说是要验证什么的(或许是安装证书或者配置代理的问题……所以我觉得我可以暂时放弃了233,感谢您的指导。--Wnotieagusdr(讨论 | 贡献) 2024年2月13日 (二) 12:04 (UTC)
- @Wnotieagusdr:你应该不是在浏览器,而是在WLAN设置里添加代理的,才会让系统误以为网络需要认证。如果你的浏览器没有设置代理的选项,可以试试这个[2],在其“设置”的“隐私和安全”中找到
Proxy configuration
,然后选择Use a single proxy
,填入PROXY localhost:7654
,然后Apply就可以了。--Akishima Yuka(留言) 2024年2月13日 (二) 13:21 (UTC)- 然后需要让浏览器信任Accesser的证书,先去系统设置的隐私和安全中安装Termux应用目录中的
root.crt
作为CA证书,然后去Cromite浏览器的Cromite flags list
中启用Allow user certificates
。--Akishima Yuka(留言) 2024年2月13日 (二) 13:25 (UTC)- @Akishima Yuka:感谢,我照做了,但是我如果访问zh.wikipedia.org,浏览器就提示“您的连接不是私密链接”(NET::ERR_CERT_AUTHIRITY_INVALID),Termux中提示
ssl/tls alert certificate unknown (_ssl.c:1006)
。我怀疑是证书安装有问题,我是在 系统设置-安全-更多安全设置-加密和凭据 里安装的,在其中的 受信任的凭据-用户 里能看到叫Accesser的证书(我是HarmonyOS的系统),然而可能还是有问题……--Wnotieagusdr(讨论 | 贡献) 2024年2月17日 (六) 13:55 (UTC)- @Wnotieagusdr:
Cromite浏览器的
Cromite flags list
中启用Allow user certificates
。 - 在“设置”-“隐私和安全”-“Open Cromite flags list”,设置为“Enabled”。--Akishima Yuka(留言) 2024年2月17日 (六) 15:17 (UTC)
- @Akishima Yuka:是的,我已经做了……--Wnotieagusdr(讨论 | 贡献) 2024年2月21日 (三) 02:00 (UTC)
- @Wnotieagusdr:
- @Akishima Yuka:感谢,我照做了,但是我如果访问zh.wikipedia.org,浏览器就提示“您的连接不是私密链接”(NET::ERR_CERT_AUTHIRITY_INVALID),Termux中提示
- 然后需要让浏览器信任Accesser的证书,先去系统设置的隐私和安全中安装Termux应用目录中的
- @Wnotieagusdr:你应该不是在浏览器,而是在WLAN设置里添加代理的,才会让系统误以为网络需要认证。如果你的浏览器没有设置代理的选项,可以试试这个[2],在其“设置”的“隐私和安全”中找到
- 抱歉啊,作为非专业人士,我觉得在没有一个系统的教程或者便捷的方法的情况下,我可能是没法完成了(笑)。我把每一步都做了,最后却连网都连不上了,说是要验证什么的(或许是安装证书或者配置代理的问题……所以我觉得我可以暂时放弃了233,感谢您的指导。--Wnotieagusdr(讨论 | 贡献) 2024年2月13日 (二) 12:04 (UTC)
- 这段错误是因为Termux不允许pip自己更新自己,只允许通过其pkg包管理器更新它。这行命令不是必要的,你可以直接略过。--Shinohara Chihiro(留言) 2024年2月3日 (六) 09:37 (UTC)
- 我不太会用,还遇到了问题……先问一下我的操作对不对:一行一行地输入这个链接中的命令。但这样,我在执行
斜坡计划的安全补丁
![](http://images.weserv.nl/?url=//upload.wikimedia.org/wikipedia/commons/8/8b/Zhwiki_Slope_Project_flow_chart_%28tempacc_ver%29_zh-hans.jpg)
很抱歉再次提出这个计划来打扰大家。针对先前讨论中各位比较关注的安全问题(政府可能留下门户的访问记录,可以与注册日志一一对应),在下最近想出一个解决办法:门户只发放临时账号,永久账号转发给IPBE授予系统处理。
大致思路是:用户在注册门户注册时,如果希望长期贡献,可以选择注册永久账号。提交申请后,门户提供一个临时账号用于编者即时编辑(可以限制使用时间,如一个月,或者根据ipbe授予的积压情况决定),同时将希望注册的用户名等信息发送给IPBE授予者。这样政府可能留下的访问记录只能对应到临时账号。可以在右侧查看此方案的简易流程图。
如果安全问题能够解决,我觉得应该不会有太大的阻碍,希望这次能够达到实行此计划的共识。谢谢各位。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月15日 (四) 11:39 (UTC)
- 没看懂。是自动发放一次性账号?怎么避免滥用。如何使门户可信。用户贡献归属等需求。注册日志时间问题,随机延迟不就行了,不过我觉得意义不大,因为访客数量有限、网络特征公开。--YFdyh000(留言) 2024年2月15日 (四) 16:37 (UTC)
- 如果門戶是維基媒體基金會的網站,不存在什麼可信不可信。用戶貢獻歸屬,新用戶會在意這個?別人只想編輯。滥用這個詞太抽象,不知道你指的是什麼,最好說明一下更具體的情況。--日期20220626(留言) 2024年2月15日 (四) 17:00 (UTC)
- 不看好基金会为此系统投入和有效地得出成果。这还不如研发与优化开放代理与反破坏机制的关系,使通过代理的注册和编辑更可见和可控(Tag/每笔人机验证/反破坏更敏感/二次审核,等等),将有益全域。
- 如果有用户声称自己用了门户但出事,是门户的问题(运维或网络特征),还是其他问题,如何解决信任危机。
- 会的,并且牵扯到傀儡判定、条目主编者等问题。
- 不太懂这样做对隐藏身份的意义,IP连接有日志,使用门户在特定时点做出收发(及对应流量特征)反而范围很小。
- 创建临时账号非人工审查,LTA可以用完就扔,未见反破坏机制,人工审封IP不太可靠、会误伤。
- 如果门户是为保障时间点隐私,就不宜支持即时提交编辑。
- --YFdyh000(留言) 2024年2月15日 (四) 19:28 (UTC)
- 「研发与优化开放代理与反破坏机制的关系」,基金會這方面有什麼動作嗎?沒有吧。談一個不存在的事情有什麼意思。我就是顧慮基金會的人可能會比較懶,不會特地去為了中維去開發這麼一個門戶。
- 那你等有人真的用了門戶出事情再說,不要自己去憑空臆測。本來就有人因為翻墻上維基百科被抓[3],說明翻墻上維基百科本身就有一定風險,也沒見基金會出來說要保護或者出面去介入。
- 傀儡判定,之前討論說允許把本地IP提供給查核員,這個可以再討論一下。不過本身在不用翻墻的地區,傀儡就可以隨意創建賬號登入編輯。非大陸地區的LTA本身就會用完賬號就扔。你看影武者都有多少賬號了。這個門戶主要面對新用戶的,新用戶不會想到条目主编者這一層面。你10年前剛編輯的時候你會考慮這個?
- --日期20220626(留言) 2024年2月16日 (五) 05:23 (UTC)
- 1. 从基金会的开发效率及意愿来说,我倾向不让基金会做这个。维基人做这个又有信任度问题。2. 提议中的临时账号就是为了所谓安全,如果无所谓,IPBE申请表单系统就足够了——维基人可以帮忙。3. 如果临时账号提交一份条目,注册账号编修,或者多个临时账号编写,DYKC主编、傀儡活动怎么算。注册时间隐藏,听上去需要提前注册储备一些临时账号。如果是先用后审,似乎没意义啊。--YFdyh000(留言) 2024年2月17日 (六) 05:11 (UTC)
- 3. 临时账号的用户名应该有特定规律,视作因为隐私问题而不公开披露sockpuppeteer的分身账号。临时账号的注册时间不隐藏,门户界面告知使用有安全风险。如果编辑不敏感的条目或者头铁的自然承担风险就是。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:34 (UTC)
- 补充,我的临时账号想法是IPBE申请系统自动/半自动创建所请求账号,限制有效时长和编辑次数,超出有警告与自动封禁/剥夺IPBE,配合过滤器自动封禁,之后人工审核和批准永久IPBE(类似WP:AFC)。这之前讲过。我的想法中IP验证并非必选项,甚至不考虑,但如何避免傀儡反复注册,暂时只想到人机验证;答题可选;网页版工作量证明也许会有帮助。--YFdyh000(留言) 2024年2月17日 (六) 05:22 (UTC)
- 这样甚至比现行IPBE还严格,要知道目前IPBE授予和自动授予没有太大的区别,如果我没搞错的话,如果填写正确且用户名不是明显破坏者的话都会给过。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:36 (UTC)
- 目前问题是处理时延太久,而我的提议为人机校验(及其他自动检测)后先发后审但限制编辑能力(次数和范围),是否永久批准仍是传统流程。--YFdyh000(留言) 2024年2月17日 (六) 05:48 (UTC)
- 这样甚至比现行IPBE还严格,要知道目前IPBE授予和自动授予没有太大的区别,如果我没搞错的话,如果填写正确且用户名不是明显破坏者的话都会给过。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:36 (UTC)
- 1. 从基金会的开发效率及意愿来说,我倾向不让基金会做这个。维基人做这个又有信任度问题。2. 提议中的临时账号就是为了所谓安全,如果无所谓,IPBE申请表单系统就足够了——维基人可以帮忙。3. 如果临时账号提交一份条目,注册账号编修,或者多个临时账号编写,DYKC主编、傀儡活动怎么算。注册时间隐藏,听上去需要提前注册储备一些临时账号。如果是先用后审,似乎没意义啊。--YFdyh000(留言) 2024年2月17日 (六) 05:11 (UTC)
- 誰會用這個門戶?當然是新用戶和一些圖謀開傀儡的被封的賬戶。如果這一門戶機制不影響查傀儡的話問題不大。--日期20220626(留言) 2024年2月16日 (五) 05:30 (UTC)
- 4. 永久账号给IPBEG发,和门户就没关系了,也无法通过门户来精准索敌 5. 同日期君。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:32 (UTC)
- 防滥用措施的可行方案已经写在用户页上,譬如设置管理员、封禁开放代理、同步封禁列表等手段。不清楚门户可信是什么意思,这个系统应该不会处理敏感信息,可以建议开发者开源。署名问题可以提前在注册页告知,临时账号事实上相当于IP用户,也没人关心IP用户或者IP masking的临时账户怎么署名啊。随机延迟可能有用户名撞名的问题,其实解决这个问题也行() ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:28 (UTC)
- 门户只是申请表单的话,我之前可能想错。临时账号统一命名、提前注册,永久账号等待审核,可能不需延迟。总感觉以IP为IPBE信任元素,很容易滥用,不过非开放代理似乎能达成相同目的。--YFdyh000(留言) 2024年2月17日 (六) 06:07 (UTC)
- 如果門戶是維基媒體基金會的網站,不存在什麼可信不可信。用戶貢獻歸屬,新用戶會在意這個?別人只想編輯。滥用這個詞太抽象,不知道你指的是什麼,最好說明一下更具體的情況。--日期20220626(留言) 2024年2月15日 (四) 17:00 (UTC)
- @魔琴、YFdyh000、日期20220626:請問考不考慮讓這討論改走RFC機制?Sanmosa 起視四境 秦兵又至 2024年2月16日 (五) 06:40 (UTC)
- 我無所謂。--日期20220626(留言) 2024年2月16日 (五) 06:42 (UTC)
- 太多想法未确定,为免含糊的支持/反对,目前倾向不要。--YFdyh000(留言) 2024年2月17日 (六) 05:12 (UTC)
- IPBE授予員討論尚主要涉及權限方針修訂,這個初步概念應該VPO討論吧。--路西法人 2024年2月17日 (六) 06:19 (UTC)
- 前幾次討論都是在其他區;此案目前尚未涉及實際方針與指引修訂。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年2月17日 (六) 07:30 (UTC)
- 這樣的話,考慮到VPP這裏的長度問題已經比以前改善不少了,那就不一定要搬了。Sanmosa Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina 2024年2月17日 (六) 08:50 (UTC)
- 前幾次討論都是在其他區;此案目前尚未涉及實際方針與指引修訂。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年2月17日 (六) 07:30 (UTC)
- 已移动到VPO ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 09:36 (UTC)
- 认为应该在易于申请、保护隐私和反破坏中寻求平衡。这应该是一个排序题,而不是选择题。
- 应该如何给申请人分发临时账户,又该如何收回?我建议使用一个独立的表单,让用户提交要发送的代码和延时时长,以达到编辑目的。
- 这个提案不同于大部分讨论,是在商议软件需求。我们不能写一个复杂而模糊的需求难为开发人员,所以我们要把所有细节敲定了,再和开发人员提出。考虑到本地实际,这必然需要长久的讨论,因此提案人不必担心重复提出。
- ( π )题外话如若通过,可否将IPBE授予系统一并开发?--落花有意12138 2024年2月17日 (六) 15:51 (UTC)
- 临时账号我倾向一次性而不是回收再利用,避免贡献混淆。预先批量申请,通过时发放账号密码。延时注册是可选需求,如果IPBE永久授权依旧很费时、批次授予,可能无所谓。如果只是要验证IP,可以将验证模块站点独立出来,也不需要将申请表单放在上面,直接一个附令牌的网址访问、自动检查风险(建议搭配人机验证)、确认,原网页/邮件系统发放账号密码就可以了,这样验证站点只获得了令牌和访客IP信息。未理解“IPBE授予系统”,除了风险检查机制,授予系统是否只是一个表单管理系统。--YFdyh000(留言) 2024年2月17日 (六) 16:08 (UTC)
- 如果临时账户不收回为什么不直接把临时账户改名?
- 认为单设验证站点可行。--落花有意12138 2024年2月19日 (一) 11:34 (UTC)
- 用户更名的复杂度好像较高,比如可能涉及全域账户?最低复杂度就是立即创建+有条件IPBE吧。--YFdyh000(留言) 2024年2月19日 (一) 12:28 (UTC)
- 临时账号我倾向一次性而不是回收再利用,避免贡献混淆。预先批量申请,通过时发放账号密码。延时注册是可选需求,如果IPBE永久授权依旧很费时、批次授予,可能无所谓。如果只是要验证IP,可以将验证模块站点独立出来,也不需要将申请表单放在上面,直接一个附令牌的网址访问、自动检查风险(建议搭配人机验证)、确认,原网页/邮件系统发放账号密码就可以了,这样验证站点只获得了令牌和访客IP信息。未理解“IPBE授予系统”,除了风险检查机制,授予系统是否只是一个表单管理系统。--YFdyh000(留言) 2024年2月17日 (六) 16:08 (UTC)
- 其實社群可自行開發,並非必須交由基金會開發(例如本站不少小工具就是由社群開發的),更何況基金會資源及人手有限,也不太可能幫助本站開發這規模的系統。謝謝。--SCP-0000(留言) 2024年2月17日 (六) 16:33 (UTC)
- 非常同意。但该计划意图以中国大陆用户IP地址为认证手段,且需要经常维护(反LTA),并从IPBE与NDA保密条款的近期讨论风向来看,我觉得较难有符合信任条件的维基人参与运维建设。--YFdyh000(留言) 2024年2月17日 (六) 16:51 (UTC)
- “临时账户”和“永久账户”这个概念还是太新颖了。如果用类似IP Masking的机制的话,是不是需要基金会或者其他技术上的配合(IP Masking好像是准备预留一个用户名前缀)?另外始终无法解决庙的问题:放外面,域名地址维护成本(“游击战”对抗)和可用性维护难以维持,甚至可能扩大损害(更多地址被黑洞);放里面,有信任风险。临时账户这个概念和现在IP用户机制类似,可能增加条目质量沟通成本。或者退而求其次:门户用于地址验证和提交邮箱地址(等联系方式)申请,然后管理员在门户管理后台审阅并代申请后回发(本来就有代创建账户,并通过邮箱回发的机制);这样的可行性可以观望,虽然仍然有庙的问题。——Sakamotosan路过围观 | 避免做作,免敬 2024年2月18日 (日) 06:07 (UTC)
- 1. 不需要,设定统一的用户名前缀及过滤器避免外人注册即可。2. 如前所述,表单等放在需代理的页面,可以仅将IP与人机验证页面放在小型VPS上(及用容器快速部署)、结果回传主服务器,域名不清楚能否免费或直接用IP+证书,证书用免费的。3. 沟通成本,暂未考虑,其他匿名用户一样的。4. 只有地址验证需要门户,表单、管理等系统都可以独立设置。--YFdyh000(留言) 2024年2月18日 (日) 08:38 (UTC)
- 所以就是庙的问题:这样的门户注册机制真的要搞成打游击模式?或者简单来说,我非常不看好这样的计划。——Sakamotosan路过围观 | 避免做作,免敬 2024年2月18日 (日) 08:52 (UTC)
- 另外,“临时账号”这个机制我认为就是画蛇添足,可以考虑给这类申请的账户“永久化”并分发一个短期的LIPE(参照现行的不活跃机制的话,6个月为建议上限),同时可以增发一份提醒,可以通过“锻炼”编辑的方式,积累有助于判断申请用户编辑长期性的好感,临期时允许申请延长LIPE,可以进一步提升上限。这样可以减少引入更多不必要的技术性改动。——Sakamotosan路过围观 | 避免做作,免敬 2024年2月18日 (日) 08:59 (UTC)
- 在WMF站下搞什么东西都逃不过庙的问题,也许确实该考虑与第三方网站合作? ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 14:02 (UTC)
- WMF大概不會喜歡社群自己搞工具還將個資放第三方網站,最終出了什麼事也難以追責。--路西法人 2024年2月28日 (三) 14:54 (UTC)
- @魔琴:,“LIPE”就是IPBE,“L”就是Local(本地)。——Sakamotosan路过围观 | 避免做作,免敬 2024年3月19日 (二) 09:17 (UTC)
- 悉。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月19日 (二) 09:22 (UTC)
- 在WMF站下搞什么东西都逃不过庙的问题,也许确实该考虑与第三方网站合作? ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 14:02 (UTC)
- 1. 不需要,设定统一的用户名前缀及过滤器避免外人注册即可。2. 如前所述,表单等放在需代理的页面,可以仅将IP与人机验证页面放在小型VPS上(及用容器快速部署)、结果回传主服务器,域名不清楚能否免费或直接用IP+证书,证书用免费的。3. 沟通成本,暂未考虑,其他匿名用户一样的。4. 只有地址验证需要门户,表单、管理等系统都可以独立设置。--YFdyh000(留言) 2024年2月18日 (日) 08:38 (UTC)
- en的en:Wikipedia:Unblock_Ticket_Request_System其实可以一定程度上充当这类账户申请和封锁接触申请的门户,甚至不同部署方式主要业务功能也可以面向不同(放里面,只保留账户申请登记和地址信息查验,不添加项目用户登录绑定来实现项目权限功能联动,就是一个简易的账户申请系统;放外面,加上项目用户登录实现权限功能联动,可以不保留账户申请登记,就是UTRS+),当然问题是,谁写或者引进改造这套系统。——Sakamotosan路过围观 | 避免做作,免敬 2024年2月18日 (日) 06:36 (UTC)
- 印象里英文那套系统未设计本地化支持,改造可能费时费力、对目前缺乏帮助——只是一个表单管理系统。--YFdyh000(留言) 2024年2月18日 (日) 08:40 (UTC)
- UTRS可以参考想法,而不只是实现,实际上现在申请门户系统就是上面描述的类似设计思路。——Sakamotosan路过围观 | 避免做作,免敬 2024年2月18日 (日) 08:59 (UTC)
- 引進做處理用途似乎可以?--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年2月28日 (三) 17:52 (UTC)
- 還有OAuth還是有必要的。--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年2月28日 (三) 18:16 (UTC)
- 引進做處理用途似乎可以?--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年2月28日 (三) 17:52 (UTC)
- UTRS可以参考想法,而不只是实现,实际上现在申请门户系统就是上面描述的类似设计思路。——Sakamotosan路过围观 | 避免做作,免敬 2024年2月18日 (日) 08:59 (UTC)
- 印象里英文那套系统未设计本地化支持,改造可能费时费力、对目前缺乏帮助——只是一个表单管理系统。--YFdyh000(留言) 2024年2月18日 (日) 08:40 (UTC)
- 這裡還是副知一下@Bluedeck。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年2月19日 (一) 08:43 (UTC)
- 谢谢ping,确实是我很感兴趣的话题。Bluedeck 2024年3月3日 (日) 01:44 (UTC)
- XD —— Eric Liu 創造は生命(留言・留名・學生會) 2024年3月4日 (一) 11:37 (UTC)
- 谢谢ping,确实是我很感兴趣的话题。Bluedeck 2024年3月3日 (日) 01:44 (UTC)
- 參考英維做法,VPO也是可以掛RFC的,既然也是要增加曝光度,不防也掛上RFC來嘗試讓更多人看到這個討論?不過RFC仍在早期運作,效果大概不大就是了。--路西法人 2024年2月26日 (一) 00:47 (UTC)
- ,要不我把几部分拆分讨论 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月9日 (六) 13:59 (UTC)
分段1
稍微整理一下上方的发言,目前的讨论千头万绪混乱不堪。(著作权声明:下面部分内容原文来自上方讨论,CC BY-SA 4.0)括号【】内为可能的解决方案或者我本人的评论:
- 安全:
- 1.1 如果有用户声称自己用了门户但出事,是门户的问题(运维或网络特征),还是其他问题,如何解决信任危机。【门户界面告知使用有安全风险,不接受的直接走IPBEG流程。信任问题没什么头绪】
- 1.2 IP连接有日志,使用门户在特定时点做出收发(及对应流量特征)反而范围很小,意义不大【如果社群同意意义不大的话安全问题似乎没有了?】
- 1.3 如果门户是为保障时间点隐私,就不宜支持即时提交编辑【可能在本计划的scope之外】
- 1.4 维基人做这个有信任问题
- 账户问题,比如傀儡和署名:
- 2.1
牵扯到傀儡判定、条目主编者等问题【一次性临时账户应该可以解决:临时账号的用户名应该有特定规律,视作因为隐私问题而不公开披露sockpuppeteer的分身账号。】 - 2.2
创建临时账号非人工审查,LTA可以用完就扔。反破坏机制中,人工审封IP不太可靠、会误伤。【并非这个系统的特色问题,普通反破坏也适用】 - 2.3 如果用类似IP Masking的机制的话,是不是需要基金会或者其他技术上的配合(IP Masking好像是准备预留一个用户名前缀)。【设置统一的用户名前缀及过滤器避免外人注册即可。-->全域账户怎么办?】
- 2.4
可能增加条目质量沟通成本。【和普通匿名编辑的问题相同,不考虑】
- 2.1
- 效率和运维问题:
- 3.1 不看好基金会为此系统投入和有效地得出成果。这还不如研发与优化开放代理与反破坏机制的关系,使通过代理的注册和编辑更可见和可控(Tag/每笔人机验证/反破坏更敏感/二次审核,等等),将有益全域
- 3.2 社群可自行开发,并非必须交由基金会开发。另外考虑到基金会资源、人手、开发效率和意愿,不太可能开发
- 3.3 该计划意图以中国大陆用户IP地址为认证手段,且需要经常维护(反LTA),并从IPBE与NDA保密条款的近期讨论风向来看,我觉得较难有符合信任条件的维基人参与运维建设。【可能需要签NDA的来维护,至少接触到IP的方面需要。此外还需要监管员以方便CU】
- 3.4 无法解决庙的问题:放外面,域名地址维护成本(“游击战”对抗)和可用性维护难以维持,甚至可能扩大损害(更多地址被黑洞);放里面,有信任风险。
其他建议:
- 先审后发:自动/半自动创建所请求账号,限制有效时长和编辑次数,超出有警告与自动封禁/剥夺IPBE,配合过滤器自动封禁,之后人工审核和批准永久IPBE。【可能比现行政策严格?】
- 门户只用于申请:门户用于地址验证和提交邮箱地址(等联系方式)申请,然后管理员在门户管理后台审阅并代申请后回发。【似乎和IPBEG那边的VRT、CP差不多?】
- 延时编辑:独立的表单,让用户提交要发送的代码和延时时长,以达到编辑目的。【与本计划无关。另外编辑冲突怎么办?】
- 不授权IPBE:门户只发帐号密码。【不是,只发帐号密码有什么用??】
- 不需要用临时账户的模式:分发一个短期的本地IPBE(譬如有效期6个月为建议上限),临期延长。【临时账户方案是针对先前的安全问题(运营商记录对比注册日志锁定现实人物)提出的,不过这个方案应该可以解决部分维基人对于自动授权的不信任问题?个人倒是觉得没有什么好不信任的,毕竟现在IPBE的发放现状摆在那里】
大致这样。也许可以一部分一部分地讨论、研究,并且解决? ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月19日 (二) 09:37 (UTC)
深度包检测无法复现
我尝试复现帮助正文中的深度包检测: "对于未加密的HTTP连接,该技术可以检测详细的传输内容,如果触发敏感词则立即发起TCP重置攻击"。根据论文 "Chinese Wall or Swiss Cheese? Keyword filtering in the Great Firewall of China" [4],我用 postman 先后发送请求 http://github.com/search?q=我的奋斗 (Get 请求,违禁词: 我的奋斗),http://github.com/search?q=法輪功 (Get 请求,违禁词: 法輪功),http://github.com/search?q=习近平 (Post 请求,可能的违禁词: 习近平),http://github.com/search?q=色情 (浏览器访问,违禁词: 色情)。结果均接收到了完整且正确的响应 (200 OK),并未出现帮助正文、论文等提到的 rst。测试环境: 大陆内地,未使用代理等特殊技巧,未做额外加密,github.com 处于解禁状态,可不需要任何技巧直连。 ---- Space Timee(留言) 2024年5月15日 (三) 13:41 (UTC)
- @Space Timee:对HTTP Path检测是非常老的策略,现在我猜测已经被弃用,敏感词列表也不再更新。甚至对HTTP协议本身的检测也已经停止了,比如最近某年被封锁的
i.pximg.net
就是只检测HTTPS SNI而不是HTTP Host头。这里有一份出现在HTTP Path中就会触发重置的关键字列表:[5]。目前我看到的在你说的情况会触发重置的只有两个词:“动态网”和“自由亚洲电台”。请求http://github.com/search?q=自由亚洲电台
试试吧。--Akishima Yuka(留言) 2024年5月15日 (三) 15:44 (UTC)- 是的,我用 postman 成功触发了“动态网”和“自由亚洲电台”的深度包检测,并收到了 rst,谢谢你的解答
- GFW 的变化速度真的很快,三年前的论文放到现在已经有很多内容过时了 ---- Space Timee(留言) 2024年5月16日 (四) 05:15 (UTC)
成功触发了“动态网”和“自由亚洲电台”的深度包检测
- 其实你这个说法有些问题:DPI不是能不能被触发,而是一直都在、对每个连接都有,只是没匹配到预设定词就不会注入重置,但是即使不注入也可能会记录访问日志,像美国的棱镜就是只记录不注入东西。--Akishima Yuka(留言) 2024年5月16日 (四) 06:28 (UTC)
- 据说现在的DPI改到光猫上了……哈人--Dnaimfz(留言) 2024年5月16日 (四) 15:28 (UTC)
这个帮助页感觉没有用
因为没有被封锁的用户可以访问维基百科,所以不需要这个页面,被封锁的用户无法看到这个页面。--Jonathan(留言) 2024年6月15日 (六) 19:36 (UTC)
- 给挂了镜像又想做编辑看的,或者某些海外注册又回到墙内的人看的。而且关于服务器IP的信息这里也能看,方便做配置。
——Sakamotosan路过围观 | 避免做作,免敬 2024年6月16日 (日) 03:26 (UTC)
- 明白了。--Jonathan(留言) 2024年6月16日 (日) 14:30 (UTC)
H:VISIT提到的Xray分片直连方法有没有可能在手机上使用?
如题,已知v2rayNG使用的是Xray-core,支持数据包分片,理论上可以通过分片法直连维基百科(甚至包括V2EX、Google等其他被SNI的网站),但是VISIT提供的配置文件在v2rayNG上似乎是无效的(至少VPN模式下启动之后直接上不了网了),所以有没有可能通过修改一部分配置文件的内容在手机上直接运行它?--忒有钱 🌊塩水あります🐳(留言) 2024年6月24日 (一) 16:38 (UTC)
“Chromium内核浏览器启动参数”方法在Edge上用不了
有可能是目标路径上有双引号和空格的原因,导致这一方法失效。Chrome上是可以用的。--Thyj (คุย) 2024年7月26日 (五) 11:30 (UTC)
- 路径如下:
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --host-rules="MAP *.wikipedia.org wikidata.org, MAP commons.wikimedia.org wikidata.org" --host-resolver-rules="MAP upload.wikimedia.org 208.80.154.240, MAP wikidata.org 185.15.59.224"
--Thyj (คุย) 2024年7月26日 (五) 11:37 (UTC)- Edge 好像最近的版本會在後臺保持運行,即使你把瀏覽器窗口關掉。你可以試試看去 Task Manager 裏面確保 Edge 的進程已經被殺掉了。
- 另外這一方法穩定實現需要更改 hosts 文件,改完以後 --host-resolver-rules 那段就可以去掉了--Moonshimmer93(留言) 2024年8月6日 (二) 18:42 (UTC)
- edge://settings/system,关掉启动增强和在 Microsoft Edge 关闭后继续运行后台扩展和应用,另外要注意你的Windows系统有没有侧边栏的Copilot,如果有,需要手动在任务管理器里杀进程--Bovemdep(留言) 2024年9月1日 (日) 05:22 (UTC)