Help talk:如何访问维基百科

message: 似乎#直接连接方法中的所有方法都只能在电脑上使用？有没有能在Android端使用的类似方法？（注意，我指的不是使用代理服务器的方法）--Wnotieagusdr（讨论 | 贡献） 2024年2月1日 (四) 06:10 (UTC)
replies: text: 见“本地代理工具”，Accesser可以在Termux中运行，然后你要配置浏览器使用http://localhost:7654代理。--Shinohara Chihiro（留言） 2024年2月1日 (四) 07:23 (UTC)
replies: text: :我不太会用，还遇到了问题……先问一下我的操作对不对：一行一行地输入这个链接中的命令。但这样，我在执行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).这该如何是好……

text: :--Wnotieagusdr（讨论 | 贡献） 2024年2月3日 (六) 07:17 (UTC)
replies: text: ::这段错误是因为Termux不允许pip自己更新自己，只允许通过其pkg包管理器更新它。这行命令不是必要的，你可以直接略过。--Shinohara Chihiro（留言） 2024年2月3日 (六) 09:37 (UTC)
replies: text: :::抱歉啊，作为非专业人士，我觉得在没有一个系统的教程或者便捷的方法的情况下，我可能是没法完成了（笑）。我把每一步都做了，最后却连网都连不上了，说是要验证什么的（或许是安装证书或者配置代理的问题……所以我觉得我可以暂时放弃了233，感谢您的指导。--Wnotieagusdr（讨论 | 贡献） 2024年2月13日 (二) 12:04 (UTC)
replies: text: ::::@Wnotieagusdr：你应该不是在浏览器，而是在WLAN设置里添加代理的，才会让系统误以为网络需要认证。如果你的浏览器没有设置代理的选项，可以试试这个，在其“设置”的“隐私和安全”中找到Proxy configuration，然后选择Use a single proxy，填入PROXY localhost:7654，然后Apply就可以了。--Akishima Yuka（留言） 2024年2月13日 (二) 13:21 (UTC)
replies: text: :::::然后需要让浏览器信任Accesser的证书，先去系统设置的隐私和安全中安装Termux应用目录中的root.crt作为CA证书，然后去Cromite浏览器的Cromite flags list中启用Allow user certificates。--Akishima Yuka（留言） 2024年2月13日 (二) 13:25 (UTC)
replies: text: ::::::感谢，我照做了，但是我如果访问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)
replies: text: :::::::@Wnotieagusdr：

text: :::::::在“设置”-“隐私和安全”-“Open Cromite flags list”，设置为“Enabled”。--Akishima Yuka（留言） 2024年2月17日 (六) 15:17 (UTC)
replies: text: ::::::::是的，我已经做了……--Wnotieagusdr（讨论 | 贡献） 2024年2月21日 (三) 02:00 (UTC)
replies: text: :::::::::🤔...--Shinohara Chihiro（留言） 2024年2月21日 (三) 05:25 (UTC)
thread_title:  Android（移动）端的直接连接方法 

message: 本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者： ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 09:36 (UTC)。
先前讨论：1 2
诚邀加入回饋請求系統。有編者正就本議題徵求社群意見。本頁已經新增至以下列表：
*維基百科提議
當討論結束時，請移除本標籤以將本頁從徵求意見列表中移除。Category:維基百科徵求意見
很抱歉再次提出这个计划来打扰大家。针对先前讨论中各位比较关注的安全问题（政府可能留下门户的访问记录，可以与注册日志一一对应），在下最近想出一个解决办法：门户只发放临时账号，永久账号转发给IPBE授予系统处理。
大致思路是：用户在注册门户注册时，如果希望长期贡献，可以选择注册永久账号。提交申请后，门户提供一个临时账号用于编者即时编辑（可以限制使用时间，如一个月，或者根据ipbe授予的积压情况决定），同时将希望注册的用户名等信息发送给IPBE授予者。这样政府可能留下的访问记录只能对应到临时账号。可以在右侧查看此方案的简易流程图。
如果安全问题能够解决，我觉得应该不会有太大的阻碍，希望这次能够达到实行此计划的共识。谢谢各位。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月15日 (四) 11:39 (UTC)
replies: text: 没看懂。是自动发放一次性账号？怎么避免滥用。如何使门户可信。用户贡献归属等需求。注册日志时间问题，随机延迟不就行了，不过我觉得意义不大，因为访客数量有限、网络特征公开。--YFdyh000（留言） 2024年2月15日 (四) 16:37 (UTC)
replies: text: :如果門戶是維基媒體基金會的網站，不存在什麼可信不可信。用戶貢獻歸屬，新用戶會在意這個？別人只想編輯。滥用這個詞太抽象，不知道你指的是什麼，最好說明一下更具體的情況。--日期20220626（留言） 2024年2月15日 (四) 17:00 (UTC)
replies: text: ::#不看好基金会为此系统投入和有效地得出成果。这还不如研发与优化开放代理与反破坏机制的关系，使通过代理的注册和编辑更可见和可控（Tag/每笔人机验证/反破坏更敏感/二次审核，等等），将有益全域。

text: ::#如果有用户声称自己用了门户但出事，是门户的问题（运维或网络特征），还是其他问题，如何解决信任危机。

text: ::#会的，并且牵扯到傀儡判定、条目主编者等问题。

text: ::#不太懂这样做对隐藏身份的意义，IP连接有日志，使用门户在特定时点做出收发（及对应流量特征）反而范围很小。

text: ::#创建临时账号非人工审查，LTA可以用完就扔，未见反破坏机制，人工审封IP不太可靠、会误伤。

text: ::#如果门户是为保障时间点隐私，就不宜支持即时提交编辑。

text: ::--YFdyh000（留言） 2024年2月15日 (四) 19:28 (UTC)
replies: text: :::#「研发与优化开放代理与反破坏机制的关系」，基金會這方面有什麼動作嗎？沒有吧。談一個不存在的事情有什麼意思。我就是顧慮基金會的人可能會比較懶，不會特地去為了中維去開發這麼一個門戶。

text: :::#那你等有人真的用了門戶出事情再說，不要自己去憑空臆測。本來就有人因為翻墻上維基百科被抓，說明翻墻上維基百科本身就有一定風險，也沒見基金會出來說要保護或者出面去介入。

text: :::#傀儡判定，之前討論說允許把本地IP提供給查核員，這個可以再討論一下。不過本身在不用翻墻的地區，傀儡就可以隨意創建賬號登入編輯。非大陸地區的LTA本身就會用完賬號就扔。你看影武者都有多少賬號了。這個門戶主要面對新用戶的，新用戶不會想到条目主编者這一層面。你10年前剛編輯的時候你會考慮這個？

text: :::--日期20220626（留言） 2024年2月16日 (五) 05:23 (UTC)
replies: text: ::::1. 从基金会的开发效率及意愿来说，我倾向不让基金会做这个。维基人做这个又有信任度问题。2. 提议中的临时账号就是为了所谓安全，如果无所谓，IPBE申请表单系统就足够了——维基人可以帮忙。3. 如果临时账号提交一份条目，注册账号编修，或者多个临时账号编写，DYKC主编、傀儡活动怎么算。注册时间隐藏，听上去需要提前注册储备一些临时账号。如果是先用后审，似乎没意义啊。--YFdyh000（留言） 2024年2月17日 (六) 05:11 (UTC)
replies: text: ::::: 3. 临时账号的用户名应该有特定规律，视作因为隐私问题而不公开披露sockpuppeteer的分身账号。临时账号的注册时间不隐藏，门户界面告知使用有安全风险。如果编辑不敏感的条目或者头铁的自然承担风险就是。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:34 (UTC)

text: ::::补充，我的临时账号想法是IPBE申请系统自动/半自动创建所请求账号，限制有效时长和编辑次数，超出有警告与自动封禁/剥夺IPBE，配合过滤器自动封禁，之后人工审核和批准永久IPBE（类似WP:AFC）。这之前讲过。我的想法中IP验证并非必选项，甚至不考虑，但如何避免傀儡反复注册，暂时只想到人机验证；答题可选；网页版工作量证明也许会有帮助。--YFdyh000（留言） 2024年2月17日 (六) 05:22 (UTC)
replies: text: ::::: 这样甚至比现行IPBE还严格，要知道目前IPBE授予和自动授予没有太大的区别，如果我没搞错的话，如果填写正确且用户名不是明显破坏者的话都会给过。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:36 (UTC)
replies: text: ::::::目前问题是处理时延太久，而我的提议为人机校验（及其他自动检测）后先发后审但限制编辑能力（次数和范围），是否永久批准仍是传统流程。--YFdyh000（留言） 2024年2月17日 (六) 05:48 (UTC)

text: :::誰會用這個門戶？當然是新用戶和一些圖謀開傀儡的被封的賬戶。如果這一門戶機制不影響查傀儡的話問題不大。--日期20220626（留言） 2024年2月16日 (五) 05:30 (UTC)

text: ::: 4. 永久账号给IPBEG发，和门户就没关系了，也无法通过门户来精准索敌 5. 同日期君。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:32 (UTC)

text: : 防滥用措施的可行方案已经写在用户页上，譬如设置管理员、封禁开放代理、同步封禁列表等手段。不清楚门户可信是什么意思，这个系统应该不会处理敏感信息，可以建议开发者开源。署名问题可以提前在注册页告知，临时账号事实上相当于IP用户，也没人关心IP用户或者IP masking的临时账户怎么署名啊。随机延迟可能有用户名撞名的问题，其实解决这个问题也行() ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:28 (UTC)
replies: text: ::门户只是申请表单的话，我之前可能想错。临时账号统一命名、提前注册，永久账号等待审核，可能不需延迟。总感觉以IP为IPBE信任元素，很容易滥用，不过非开放代理似乎能达成相同目的。--YFdyh000（留言） 2024年2月17日 (六) 06:07 (UTC)

text: @-{魔琴}-、-{YFdyh000}-、-{日期20220626}-：請問考不考慮讓這討論改走RFC機制？Sanmosa 起視四境　秦兵又至 2024年2月16日 (五) 06:40 (UTC)
replies: text: :我無所謂。--日期20220626（留言） 2024年2月16日 (五) 06:42 (UTC)

text: :太多想法未确定，为免含糊的支持/反对，目前倾向不要。--YFdyh000（留言） 2024年2月17日 (六) 05:12 (UTC)

text: :IPBE授予員討論尚主要涉及權限方針修訂，這個初步概念應該VPO討論吧。--路西法人 2024年2月17日 (六) 06:19 (UTC)
replies: text: :: 前幾次討論都是在其他區；此案目前尚未涉及實際方針與指引修訂。—— Eric Liu -{創造}-は生命（留言・留名・學生會） 2024年2月17日 (六) 07:30 (UTC)
replies: text: :::這樣的話，考慮到VPP這裏的長度問題已經比以前改善不少了，那就不一定要搬了。Sanmosa Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina 2024年2月17日 (六) 08:50 (UTC)

text: 已移动到VPO ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 09:36 (UTC)

text: 认为应该在易于申请、保护隐私和反破坏中寻求平衡。这应该是一个排序题，而不是选择题。

text: 应该如何给申请人分发临时账户，又该如何收回？我建议使用一个独立的表单，让用户提交要发送的代码和延时时长，以达到编辑目的。

text: 这个提案不同于大部分讨论，是在商议软件需求。我们不能写一个复杂而模糊的需求难为开发人员，所以我们要把所有细节敲定了，再和开发人员提出。考虑到本地实际，这必然需要长久的讨论，因此提案人不必担心重复提出。

text: ( π )题外话如若通过，可否将IPBE授予系统一并开发？--落花有意12138 2024年2月17日 (六) 15:51 (UTC)
replies: text: :临时账号我倾向一次性而不是回收再利用，避免贡献混淆。预先批量申请，通过时发放账号密码。延时注册是可选需求，如果IPBE永久授权依旧很费时、批次授予，可能无所谓。如果只是要验证IP，可以将验证模块站点独立出来，也不需要将申请表单放在上面，直接一个附令牌的网址访问、自动检查风险（建议搭配人机验证）、确认，原网页/邮件系统发放账号密码就可以了，这样验证站点只获得了令牌和访客IP信息。未理解“IPBE授予系统”，除了风险检查机制，授予系统是否只是一个表单管理系统。--YFdyh000（留言） 2024年2月17日 (六) 16:08 (UTC)
replies: text: ::如果临时账户不收回为什么不直接把临时账户改名？

text: ::认为单设验证站点可行。--落花有意12138 2024年2月19日 (一) 11:34 (UTC)
replies: text: :::用户更名的复杂度好像较高，比如可能涉及全域账户？最低复杂度就是立即创建+有条件IPBE吧。--YFdyh000（留言） 2024年2月19日 (一) 12:28 (UTC)

text: 其實社群可自行開發，並非必須交由基金會開發（例如本站不少小工具就是由社群開發的），更何況基金會資源及人手有限，也不太可能幫助本站開發這規模的系統。謝謝。--SCP-0000（留言） 2024年2月17日 (六) 16:33 (UTC)
replies: text: :非常同意。但该计划意图以中国大陆用户IP地址为认证手段，且需要经常维护（反LTA），并从IPBE与NDA保密条款的近期讨论风向来看，我觉得较难有符合信任条件的维基人参与运维建设。--YFdyh000（留言） 2024年2月17日 (六) 16:51 (UTC)

text: “临时账户”和“永久账户”这个概念还是太新颖了。如果用类似IP Masking的机制的话，是不是需要基金会或者其他技术上的配合（IP Masking好像是准备预留一个用户名前缀）？另外始终无法解决庙的问题：放外面，域名地址维护成本（“游击战”对抗）和可用性维护难以维持，甚至可能扩大损害（更多地址被黑洞）；放里面，有信任风险。临时账户这个概念和现在IP用户机制类似，可能增加条目质量沟通成本。或者退而求其次：门户用于地址验证和提交邮箱地址（等联系方式）申请，然后管理员在门户管理后台审阅并代申请后回发（本来就有代创建账户，并通过邮箱回发的机制）；这样的可行性可以观望，虽然仍然有庙的问题。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 06:07 (UTC)
replies: text: :1. 不需要，设定统一的用户名前缀及过滤器避免外人注册即可。2. 如前所述，表单等放在需代理的页面，可以仅将IP与人机验证页面放在小型VPS上（及用容器快速部署）、结果回传主服务器，域名不清楚能否免费或直接用IP+证书，证书用免费的。3. 沟通成本，暂未考虑，其他匿名用户一样的。4. 只有地址验证需要门户，表单、管理等系统都可以独立设置。--YFdyh000（留言） 2024年2月18日 (日) 08:38 (UTC)
replies: text: ::所以就是庙的问题：这样的门户注册机制真的要搞成打游击模式？或者简单来说，我非常不看好这样的计划。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:52 (UTC)

text: ::另外，“临时账号”这个机制我认为就是画蛇添足，可以考虑给这类申请的账户“永久化”并分发一个短期的LIPE（参照现行的不活跃机制的话，6个月为建议上限），同时可以增发一份提醒，可以通过“锻炼”编辑的方式，积累有助于判断申请用户编辑长期性的好感，临期时允许申请延长LIPE，可以进一步提升上限。这样可以减少引入更多不必要的技术性改动。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:59 (UTC)
replies: text: ::: 在WMF站下搞什么东西都逃不过庙的问题，也许确实该考虑与第三方网站合作？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 14:02 (UTC)
replies: text: ::::WMF大概不會喜歡社群自己搞工具還將個資放第三方網站，最終出了什麼事也難以追責。--路西法人 2024年2月28日 (三) 14:54 (UTC)

text: ::::@-{魔琴}-：，“LIPE”就是IPBE，“L”就是Local（本地）。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月19日 (二) 09:17 (UTC)
replies: text: ::::: 悉。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月19日 (二) 09:22 (UTC)

text: en的:en:Wikipedia:Unblock_Ticket_Request_System其实可以一定程度上充当这类账户申请和封锁接触申请的门户，甚至不同部署方式主要业务功能也可以面向不同（放里面，只保留账户申请登记和地址信息查验，不添加项目用户登录绑定来实现项目权限功能联动，就是一个简易的账户申请系统；放外面，加上项目用户登录实现权限功能联动，可以不保留账户申请登记，就是UTRS+），当然问题是，谁写或者引进改造这套系统。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 06:36 (UTC)
replies: text: :印象里英文那套系统未设计本地化支持，改造可能费时费力、对目前缺乏帮助——只是一个表单管理系统。--YFdyh000（留言） 2024年2月18日 (日) 08:40 (UTC)
replies: text: ::UTRS可以参考想法，而不只是实现，实际上现在申请门户系统就是上面描述的类似设计思路。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:59 (UTC)
replies: text: :::引進做處理用途似乎可以？--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年2月28日 (三) 17:52 (UTC)
replies: text: ::::還有OAuth還是有必要的。--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年2月28日 (三) 18:16 (UTC)

text: 這裡還是副知一下@-{Bluedeck}-。—— Eric Liu -{創造}-は生命（留言・留名・學生會） 2024年2月19日 (一) 08:43 (UTC)
replies: text: :谢谢ping，确实是我很感兴趣的话题。Bluedeck 2024年3月3日 (日) 01:44 (UTC)
replies: text: :: XD —— Eric Liu -{創造}-は生命（留言・留名・學生會） 2024年3月4日 (一) 11:37 (UTC)

text: 參考英維做法，VPO也是可以掛RFC的，既然也是要增加曝光度，不防也掛上RFC來嘗試讓更多人看到這個討論？不過RFC仍在早期運作，效果大概不大就是了。--路西法人 2024年2月26日 (一) 00:47 (UTC)

text: ，要不我把几部分拆分讨论 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月9日 (六) 13:59 (UTC)
replies: text: :拆吧--路西法人 2024年3月11日 (一) 08:33 (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 可能增加条目质量沟通成本。【和普通匿名编辑的问题相同，不考虑】
# 效率和运维问题：
#*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)

text: Wikipedia:互助客栈/其他#Unblock-zh.org--Dnaimfz（留言） 2024年5月15日 (三) 08:08 (UTC)
thread_title:  [[User:魔琴/斜坡计划|斜坡计划]]的安全补丁 

message: 稍微整理一下上方的发言，目前的讨论千头万绪混乱不堪。（著作权声明：下面部分内容原文来自上方讨论，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 可能增加条目质量沟通成本。【和普通匿名编辑的问题相同，不考虑】
# 效率和运维问题：
#*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)
replies: text: Wikipedia:互助客栈/其他#Unblock-zh.org--Dnaimfz（留言） 2024年5月15日 (三) 08:08 (UTC)
thread_title:  分段1 

message: 我尝试复现帮助正文中的深度包检测: "对于未加密的HTTP连接，该技术可以检测详细的传输内容，如果触发敏感词则立即发起TCP重置攻击"。根据论文 "Chinese Wall or Swiss Cheese? Keyword filtering in the Great Firewall of China" ，我用 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)
replies: text: @Space Timee：对HTTP Path检测是非常老的策略，现在我猜测已经被弃用，敏感词列表也不再更新。甚至对HTTP协议本身的检测也已经停止了，比如最近某年被封锁的i.pximg.net就是只检测HTTPS SNI而不是HTTP Host头。这里有一份出现在HTTP Path中就会触发重置的关键字列表：。目前我看到的在你说的情况会触发重置的只有两个词：“动态网”和“自由亚洲电台”。请求http://github.com/search?q=自由亚洲电台试试吧。--Akishima Yuka（留言） 2024年5月15日 (三) 15:44 (UTC)
replies: text: :是的，我用 postman 成功触发了“动态网”和“自由亚洲电台”的深度包检测，并收到了 rst，谢谢你的解答

text: :GFW 的变化速度真的很快，三年前的论文放到现在已经有很多内容过时了 ---- Space Timee（留言） 2024年5月16日 (四) 05:15 (UTC)
replies: text: ::

text: ::其实你这个说法有些问题：DPI不是能不能被触发，而是一直都在、对每个连接都有，只是没匹配到预设定词就不会注入重置，但是即使不注入也可能会记录访问日志，像美国的棱镜就是只记录不注入东西。--Akishima Yuka（留言） 2024年5月16日 (四) 06:28 (UTC)
replies: text: :::据说现在的DPI改到光猫上了……哈人--Dnaimfz（留言） 2024年5月16日 (四) 15:28 (UTC)
thread_title:  深度包检测无法复现