帮助讨论:如何访问维基百科

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)

🤔...--Shinohara Chihiro（留言） 2024年2月21日 (三) 05:25 (UTC)

斜坡计划的安全补丁

先前讨论：1 2

简易流程图

很抱歉再次提出这个计划来打扰大家。针对先前讨论中各位比较关注的安全问题（政府可能留下门户的访问记录，可以与注册日志一一对应），在下最近想出一个解决办法：门户只发放临时账号，永久账号转发给IPBE授予系统处理。

大致思路是：用户在注册门户注册时，如果希望长期贡献，可以选择注册永久账号。提交申请后，门户提供一个临时账号用于编者即时编辑（可以限制使用时间，如一个月，或者根据ipbe授予的积压情况决定），同时将希望注册的用户名等信息发送给IPBE授予者。这样政府可能留下的访问记录只能对应到临时账号。可以在右侧查看此方案的简易流程图。

如果安全问题能够解决，我觉得应该不会有太大的阻碍，希望这次能够达到实行此计划的共识。谢谢各位。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月15日 (四) 11:39 (UTC)

没看懂。是自动发放一次性账号？怎么避免滥用。如何使门户可信。用户贡献归属等需求。注册日志时间问题，随机延迟不就行了，不过我觉得意义不大，因为访客数量有限、网络特征公开。--YFdyh000（留言） 2024年2月15日 (四) 16:37 (UTC)

如果门户是维基媒体基金会的网站，不存在什么可信不可信。用户贡献归属，新用户会在意这个？别人只想编辑。滥用这个词太抽象，不知道你指的是什么，最好说明一下更具体的情况。--日期20220626（留言） 2024年2月15日 (四) 17:00 (UTC)

1. 不看好基金会为此系统投入和有效地得出成果。这还不如研发与优化开放代理与反破坏机制的关系，使通过代理的注册和编辑更可见和可控（Tag/每笔人机验证/反破坏更敏感/二次审核，等等），将有益全域。
2. 如果有用户声称自己用了门户但出事，是门户的问题（运维或网络特征），还是其他问题，如何解决信任危机。
3. 会的，并且牵扯到傀儡判定、条目主编者等问题。
4. 不太懂这样做对隐藏身份的意义，IP连接有日志，使用门户在特定时点做出收发（及对应流量特征）反而范围很小。
5. 创建临时账号非人工审查，LTA可以用完就扔，未见反破坏机制，人工审封IP不太可靠、会误伤。
6. 如果门户是为保障时间点隐私，就不宜支持即时提交编辑。

--YFdyh000（留言） 2024年2月15日 (四) 19:28 (UTC)

1. “研发与优化开放代理与反破坏机制的关系”，基金会这方面有什么动作吗？没有吧。谈一个不存在的事情有什么意思。我就是顾虑基金会的人可能会比较懒，不会特地去为了中维去开发这么一个门户。
2. 那你等有人真的用了门户出事情再说，不要自己去凭空臆测。本来就有人因为翻墙上维基百科被抓[3]，说明翻墙上维基百科本身就有一定风险，也没见基金会出来说要保护或者出面去介入。
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)

谁会用这个门户？当然是新用户和一些图谋开傀儡的被封的账户。如果这一门户机制不影响查傀儡的话问题不大。--日期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)

@魔琴、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)

已移动到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)

其实社群可自行开发，并非必须交由基金会开发（例如本站不少小工具就是由社群开发的），更何况基金会资源及人手有限，也不太可能帮助本站开发这规模的系统。谢谢。--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)

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)

这里还是副知一下@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)

参考英维做法，VPO也是可以挂RFC的，既然也是要增加曝光度，不防也挂上RFC来尝试让更多人看到这个讨论？不过RFC仍在早期运作，效果大概不大就是了。--路西法人 2024年2月26日 (一) 00:47 (UTC)

，要不我把几部分拆分讨论 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月9日 (六) 13:59 (UTC)

拆吧--路西法人 2024年3月11日 (一) 08:33 (UTC)

分段1

稍微整理一下上方的发言，目前的讨论千头万绪混乱不堪。（著作权声明：下面部分内容原文来自上方讨论，CC BY-SA 4.0）括号【】内为可能的解决方案或者我本人的评论：

1. 安全：
   • 1.1 如果有用户声称自己用了门户但出事，是门户的问题（运维或网络特征），还是其他问题，如何解决信任危机。【门户界面告知使用有安全风险，不接受的直接走IPBEG流程。信任问题没什么头绪】
   • 1.2 IP连接有日志，使用门户在特定时点做出收发（及对应流量特征）反而范围很小，意义不大【如果社群同意意义不大的话安全问题似乎没有了？】
   • 1.3 如果门户是为保障时间点隐私，就不宜支持即时提交编辑【可能在本计划的scope之外】
   • 1.4 维基人做这个有信任问题
2. 账户问题，比如傀儡和署名：
   • 2.1 牵扯到傀儡判定、条目主编者等问题【一次性临时账户应该可以解决：临时账号的用户名应该有特定规律，视作因为隐私问题而不公开披露sockpuppeteer的分身账号。】
   • 2.2 创建临时账号非人工审查，LTA可以用完就扔。反破坏机制中，人工审封IP不太可靠、会误伤。【并非这个系统的特色问题，普通反破坏也适用】
   • 2.3 如果用类似IP Masking的机制的话，是不是需要基金会或者其他技术上的配合（IP Masking好像是准备预留一个用户名前缀）。【设置统一的用户名前缀及过滤器避免外人注册即可。-->全域账户怎么办？】
   • 2.4 可能增加条目质量沟通成本。【和普通匿名编辑的问题相同，不考虑】
3. 效率和运维问题：
   • 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)