Screenshare 查端参考规范 Terms（中英双语版）

版本： 1.2
修订日期： 2026 年 10 月 22 日
参考用途： 供服务器合作方及个人查端方制定或完善 Screenshare（SS）检查规则，用于核验涉嫌作弊、规避检查、证据篡改或相关违规的事项。

本文中的“应”“必须”“不得”等表述用于描述建议采用的规范要求，不表示本文自行创设检查权限、处罚权限或对受查人的义务。采用方应按第 14 条明确实际采用的内容、适用范围及生效安排，并履行相应告知和授权程序。

下列中文版与文末英文版使用相同条款编号，表达相同的参考规则。中文定义保留对应英文术语，便于跨语言沟通和记录。

一、Screenshare 查端参考规范（中文版）

1. 定义（Definitions）

1. Screenshare（SS）：在明确授权和已告知范围内，通过屏幕共享、远程连接或经批准的扫描工具，对设备状态、相关文件、系统记录及运行环境进行检查的过程。
2. ScreenSharer（SSer）：取得相应检查授权，并在已告知及获授权范围内执行 SS 的检查人员，包括经授权的个人查端人员。
3. 受查人（Subject）：被要求参加或自愿参加 SS 的用户。本文统一以 Subject 指代原规则中的 “Player” 或 “Suspect”；该称谓本身不表示其已经违规。
4. SS Session：从正式告知检查开始，到 SSer 出具结论或明确终止检查为止的完整会话。
5. SS Tool：经采用方事先批准，用于自动化查端、扫描或取证辅助的软件，包括但不限于 Echo、Ocean。SS Tool 仅在其名称、提供方、来源、访问范围、数据处理方式、输出内容及适用的服务条款（Terms of Service，简称 Tool TOS）已向受查人披露后，方属于本文所称的已批准工具（Approved SS Tool）。
6. Bypass Attempt：为了妨碍、误导或规避 SS，故意删除、清除、修改、伪造、替换、转移或隐藏与检查事项有关的证据或环境。
7. Anti-Forensics：旨在降低证据可见性、完整性、可追溯性或可信度的反取证方法、工具或操作。
8. Force Majeure：任何人无法合理控制、无法合理预见或无法合理避免，并直接导致其不能完成 SS 要求的事件。
9. Permanent / Perm：无限期停权。该期限表述本身不表示排除复核或申诉；具体途径依决定方事先公开的规则及适用法律确定。
10. 采用方（Adopting Party）：参考本文制定或完善检查规则的服务器合作方或个人查端方。参考或采用本文本身不赋予其检查授权或处罚权限。
11. 决定方（Decision-Making Party）：对相关事项具有管理权限的服务器运营方或其他相关第三方，负责在其权限范围内确定具体适用条款，并独立作出、执行及复核处理或处罚决定。

2. 基本原则（Core Principles）

1. 授权与告知（Authority and Notice）：SSer 必须具有执行检查的明确权限。开始前应向受查人说明检查理由、范围、所用工具、是否录制、预计时长、数据保存方式及可用的复核渠道。
2. 目的限定（Purpose Limitation）：仅可检查与已告知事项具有合理关联的内容。不得借 SS 搜索无关的私人信息、账号凭据、通信内容或商业秘密。
3. 最小必要（Data Minimization）：应优先使用侵入性最低、足以核验相关事实的方法。能够通过状态确认或特定扫描完成的，不应扩大为无边界的文件浏览。
4. 不得擅自改变设备（No Unauthorized Alteration）：除非受查人明确同意且确有检查必要，SSer 不得安装、删除、上传、下载、修改或执行与检查无关的内容。
5. 无罪推定与证据标准（Presumption of Innocence and Evidence Standard）：安装过某类软件、加入某个群组或出现单一异常，不得自动视为作弊或 Bypass Attempt。拒绝 Approved SS Tool 或其 Tool TOS 应依第 7.3 条作为程序性 Refusing 处理，但拒绝行为本身不得被直接认定为 Cheating 或 Bypass Attempt。任何实体违规结论仍必须由可复核事实支持。
6. 一致与比例（Consistency and Proportionality）：相同事实应适用相同标准；处分应考虑故意程度、证据影响、重复次数、配合情况及 Force Majeure。
7. 保密（Confidentiality）：SSer 及复核人员对检查中接触的非公开信息承担保密义务，不得将其用于检查以外的目的。
8. 工具授权与 Tool TOS（Authorization of Tools and Tool TOS）：在相关规则已被实际采用并完成必要告知的前提下，受查人明确接受该等检查规则、同意已披露的工具使用范围并选择继续 SS，方可据此授权 SSer 在该范围内使用 Approved SS Tool。受查人在工具运行前还必须接受该工具当时适用的 Tool TOS。受查人可以拒绝相关检查规则并拒绝整个 SS；拒绝完成检查所必需的 Approved SS Tool 或其 Tool TOS 时，按第 7.3 条处理。单纯查阅本文不构成对检查、工具运行或数据处理的同意。
9. 结果与决定分离（Separation of Findings and Decisions）：社区出具的检查结果、行为分类及处理建议均为参考意见，不直接产生停权、封禁或其他处罚效力。是否采纳相关意见、适用何种规则以及是否作出处理或处罚，由决定方独立判断；不得将社区参考意见表述为社区作出的最终处罚决定。

3. SS 前的要求（Pre-Session Requirements）

1. SSer 应确认受查人身份、检查事项、实际适用的检查规则及版本，说明检查结果的参考性质和负责后续处理的决定方，告知拟使用的 Approved SS Tool，向受查人提供当前 Tool TOS 的查看方式，并记录受查人对相关检查规则、SS 及 Tool TOS 的接受或拒绝情况和 SS Session 的开始时间。
2. 受查人应在收到检查通知后保持相关设备和环境的当前状态，不得为影响检查而重启服务、清理记录、删除文件、切换设备或运行清理工具。
3. 如设备性能、网络、管理员权限、远程连接工具或辅助功能存在真实障碍，受查人应立即说明并提供可合理验证的信息。
4. 如设备中存在与检查无关的敏感、私密或受保密义务保护的内容，受查人应在相关目录被查看前提出。SSer 应在不损害检查目的的前提下采用遮挡、限定路径、由受查人操作或其他替代方式。
5. 受查人应披露可能影响判断的多鼠标、多存储设备、虚拟挂载、定制系统、优化工具或其他特殊环境；披露本身不构成违规。

4. SS 期间的行为（Session Conduct）

1. 受查人应在事先说明的合理响应时间内答复，不得无故离开、故意拖延、反复中断连接或通过重新启动、退出相关程序等方式妨碍检查。
2. 在 SSer 明确要求保持运行后，受查人不得关闭相关应用、游戏进程或远程连接程序。真实崩溃、断网或系统故障应依据可验证事实处理，不得仅因结果相同而推定为故意。
3. 受查人不得夺取控制、遮挡相关窗口、提供虚假说明或引导 SSer 检查错误的设备、账号、目录或时间范围。
4. SSer 不得超出已告知范围操作设备；发现无关私人内容时，应立即停止查看并避免复制或传播。
5. SSer 可在有效授权和已披露范围内使用 Approved SS Tool，包括但不限于 Echo、Ocean。工具首次运行前，SSer 必须披露其名称、提供方、来源、访问范围、向第三方传输或保存的数据、输出内容，并向受查人提供当前 Tool TOS 的查看和接受方式。SSer 不得使用未经批准的工具，也不得使工具超出已披露范围运行。
6. 受查人明确接受实际适用的检查规则并选择继续 SS 后，应按已告知且获授权的检查流程配合使用 Approved SS Tool，并在工具运行前接受其 Tool TOS。受查人拒绝相关检查规则、拒绝整个 SS，或拒绝完成 SS 所必需的 Approved SS Tool 或其 Tool TOS 时，SSer 应停止检查，并在符合第 7.3 条条件时将其记录为对整个 SS 的 Refusing。是否适用已公开的拒绝检查后果，由决定方依相关规则判断；不得仅凭拒绝行为认定 Cheating 或 Bypass Attempt。
7. Admitting 仅指受查人在理解问题和后果后作出的明确、自愿且被准确记录的承认。含糊陈述、推测或在压力下作出的表述不得单独作为结论依据。

5. 轻度违规（Light Offenses）

5.1 无法进行 SS（Inability to SS）

1. Type I — 非故意技术障碍：低性能设备、网络不稳定、缺少管理员权限或远程连接工具故障，且没有证据表明这些问题由受查人故意制造、设置或伪造。
2. Type I — 故意制造或伪造：受查人故意造成、夸大或伪造前述技术障碍，以阻止或缩短 SS。
3. Type II — 环境性障碍：定制或精简操作系统、无法恢复的关键组件缺失，或其他使完整 SS 在技术上无法进行的环境。SSer 在作出结论前必须先尝试合理的替代检查方法。
4. Type III — Approved SS Tool 替代扫描：受查人能够运行采用方批准的 SS Tool、已经接受其 Tool TOS，且扫描范围足以解决检查事项时，可将该扫描作为完成或部分完成 SS 的方式。工具未覆盖的事项不得被描述为已经核验。

5.2 多个鼠标或缺少鼠标软件（1+ Mice Connected / No Mouse Software）

存在两个或以上已连接的指针设备、预装鼠标软件缺失、设备损坏或配置异常时，应记录设备标识和解释。只有在未披露、解释明显虚假，或该状态被用于隐藏宏、脚本、输入修改或设备替换时，方可按本项认定违规；设备数量本身不是作弊结论。

5.3 拖延（Stalling）

在收到明确指令和合理响应时间后，无正当理由离开、持续不回复、反复中断、故意制造无关步骤，或以其他方式延迟检查，构成 Stalling。短暂断网、无障碍需求、紧急事件或其他 Force Majeure 不构成 Stalling。

5.4 SS 滥用（SS Misuse）

伪造、冒用、篡改或重复使用 SS 报告，使用已经失效的报告规避新的检查要求，向无权人员披露 SS 资料，或将 SS 结论用于其授权范围以外的目的，构成 SS Misuse。

6. 不可抗力（Force Majeure）

1. 经合理验证的 Force Majeure 不应产生主处罚，也不应与其他违规叠加。
2. SSer 应记录事件、受影响的要求、已尝试的替代方法以及是否需要重新安排 SS。
3. 如果只有部分检查受影响，应完成不受影响且仍属必要的部分，不得据此扩大检查范围。
4. 故意伪造或恶意利用 Force Majeure 的，按 Bypass Attempt 评估；仅因无法立即证明事件，不得自动认定为恶意。

7. 中度违规（Medium Offenses）

7.1 禁用服务或记录源（Disabled Services）

1. 与检查相关的系统服务或记录源被禁用、终止、截断或无法访问，并且该状态实质性降低证据可见性时，可认定为 Disabled Services。常见对象包括 SysMain、CDPUserSvc_{...}、PcaSvc、DPS、EventLog、Task Scheduler、SearchIndexer、BAM/DAM、DusmSvc 和 Appinfo。
2. 同类状态包括终止 BAM inheritance、禁用 ActivitiesCache、禁用 Jump Lists，以及终止相关服务线程。
3. 仅有服务关闭这一事实不足以证明故意。SSer 应检查关闭时间、方式、操作者、优化工具的作用、系统版本及是否能够恢复。
4. 受查人使用优化软件或定制配置时，应自行了解其影响；但 SSer 仍必须证明该状态与本次检查的关联，不得以“使用优化工具”替代证据。

7.2 关闭相关程序（Closing Relevant Applications）

在明确收到保持运行的指令后，故意关闭相关程序、进程或远程连接，构成本项违规。真实崩溃或非人为掉线应单独核验。单纯退出账号而未影响相关证据的，不自动构成违规。

7.3 拒绝或承认（Refusing / Admitting）

1. Refusing：在检查具有明确权限、范围合理且已完成必要告知后，受查人拒绝实际适用的检查规则、拒绝整个 SS，或拒绝使用完成 SS 所必需的 Approved SS Tool，包括拒绝接受该工具适用的 Tool TOS。该分类用于记录检查未能继续的原因；相应后果应由决定方预先公开，并由其决定是否适用。
2. Admitting：受查人明确承认相关违规。承认应保留准确上下文，并尽可能由独立证据印证。
3. 受查人可以拒绝相关检查规则并拒绝整个 SS。受查人明确接受规则并选择继续 SS 后，如拒绝完成检查所必需的 Approved SS Tool 或其 Tool TOS，应按本条记录为对整个 SS 的 Refusing，不因此产生要求仅以人工方式继续检查的权利。SSer 不得在受查人拒绝后强行运行工具或继续访问设备。
4. 如果工具未经采用方批准、SSer 未提供当前 Tool TOS、未完成必要披露，或拟运行范围超出已披露范围，受查人对此提出异议不构成 Refusing；SSer 应先纠正相关缺陷。任何 Refusing 均不当然撤销无罪推定，也不单独证明 Cheating 或 Bypass Attempt。

7.4 干扰（Tampering）

以妨碍检查为目的，故意使相关内容更难查找、隐藏或移动窗口、改变搜索结果、误导路径、撤回必要权限，或在 SS 期间改变相关状态，构成 Tampering。受查人依第 7.3 条拒绝或终止检查的行为，本身不构成 Tampering。SSer 对受查人提出的保密内容应采用第 3.4 条的限定措施；不得以核实文件是否私密为由，无边界查看图片、文档、文本或脚本。

7.5 作弊（Cheating）

发现作弊客户端、作弊应用、宏、脚本或其他不公平功能，且证据能够证明其存在、可用性以及与受查事项的关联时，可认定 Cheating。认定时应区分：

• 工具是否具有自毁或告警式自毁功能；
• 是否使用了 Bypass 或 Anti-Forensics；
• 是否仅隐藏了工具，还是改变了其形式、时间或证据；
• 是否同时满足 Bypass Attempt 的任一类型。

若存在 Bypass Attempt，应分别记录，不得用笼统的 “Cheating” 掩盖更严重的证据篡改行为。

8. 严重违规（Severe Offenses）

8.1 规避检查（Bypass Attempt）

Bypass Attempt 仅应在有明确、可复核证据证明相关行为旨在妨碍或误导 SS 时成立。软件的存在、合法日常使用或孤立的系统异常，不足以单独成立本项。

1. Type I — 清理或重置证据源：重启相关服务以改变状态；清理 Journal、注册表项、Event Logs、Prefetch 或 shell:recent；使用字符串清理器、文件粉碎器；篡改 NvAPPTimestamps；或就相关状态故意向 SSer 提供虚假信息。
2. Type II — 替换、覆盖或重新连接环境：为改变证据而使用 PsExec 或脚本环境；在 FAT16/FAT32/exFAT 介质上覆盖或替换文件；重新连接大容量存储设备；改变 Virtual Mounts。开发工具、脚本环境或外置介质的正常存在不构成违规，必须证明其与证据改变有关。
3. Type III — 临近或计划执行反取证操作：在 SS 前后计划或运行 PowerShell、PowerShell ISE、CMD、批处理、清理器、优化器、Process Hacker、System Informer、ProcMon、WMIC 方法、注册表修改或其他脚本操作，并有证据表明其用于隐藏、清理或改变相关信息；还包括通过 Unicode 混淆作弊工具或故意修改默认下载路径以误导检查。
4. Type IV — 身份、设备或数据替换：切换设备或由他人、其他账号代替接受 SS；使用公开 Anti-Forensics；修改文件数据或元数据；组合实施多项不同类型的规避行为。
5. 通过谎报自身环境、故意选择较轻的违规描述或其他方式逃避正确分类的，应按其实际行为重新分类；不得仅因当事人提出不同解释而认定其撒谎。

8.2 规则禁止的修改（Prohibited Modifications）

用于取得不公平优势或规避检查，且被实际适用的规则禁止的代理客户端、鼠标宏、外部宏、输入自动化、HitDelay 修改、Freelook 或同类功能，属于 Prohibited Modifications。此处“禁止”指违反相关管理规则，不表示对行为是否违法作出法律认定。仅用于图形、性能或可访问性优化且不包含被禁止功能的启动器或工具，不因其类别自动违规。

8.3 网络、VPN 与 Ping 操纵（Ping Manipulation）

故意使用热点、代理、VPN 或其他方法伪造、操纵或隐藏网络状态，并以获取不公平优势、规避 SS 或逃避既有处分为目的时，可认定违规。VPN、企业网络、Cloudflare WARP 或网络波动本身不构成违规。

8.4 输入修改（Input Modification）

修改鼠标灵敏度、加速度或辅助输入的内部或外部工具，在不包含 CPS 自动化、HitDelay 修改、宏或其他被禁止功能时，不构成违规。

8.5 定制或精简系统（Modified OS）

1. Customized OS 或 Trimmed OS 关闭大量必要服务、导致关键记录不可用且无法合理恢复时，可认定 Modified OS。SSer 在作出结论前必须尝试合理、低风险的替代检查。
2. 若受影响的关键服务或记录源超过三项，可同时评估 Inability to SS，但不得重复计算同一事实造成的损害。
3. Boot Camp 或其他合法的跨平台运行方式本身不构成违规。
4. 系统优化器导致的精简效果应按实际状态、时间和证据影响判断，不因品牌或合作关系直接认定或排除违规。

8.6 删除相关文件（Deleting Relevant Files）

在收到检查通知后，或能够合理预见即将接受检查时，故意删除、粉碎、覆盖或使相关文件无法恢复，并因此实质性影响 SS 的，构成本项违规。正常的自动清理、存储故障或与检查无关的删除，必须结合时间线和其他证据判断。

9. 组织性规避、利益输送与规避服务（Organized Bypass and Bribery）

1. Organized Bypass：组织或协助他人以替换设备、替换身份、提供无违规设备、隐藏信息或统一虚假说法等方式规避 SS。
2. Bribing ScreenSharers：为影响检查过程、证据评价或检查结论，向 SSer、复核人员或管理人员提供、承诺给予不当利益，或由上述人员索取、收受不当利益。涉事 SSer 应立即回避并接受独立调查。
3. Providing Bypass Services：制作、销售、分发、教授或定向提供用于规避 SS 的 Anti-Forensics、伪装程序、作弊工具或操作方案。
4. Receiving Bypass Services：明知服务旨在规避 SS 而购买、获取或使用该服务。
5. 单纯加入群组、浏览公开内容、与相关人员存在联系或表现兴趣，不得自动撤销无罪推定。必须证明当事人具有实际参与、提供、获取或使用行为。

10. 证据、结论与记录（Evidence, Findings and Records）

1. 每项检查结论应记录实际适用的检查规则及所参考的本文条款、关键事实、时间线、证据来源、证据完整性、替代解释以及 SSer 的判断理由，并区分已核实事实、尚存疑点和参考意见。
2. 对可能自然产生或由正常软件产生的系统状态，应验证时间、因果关系和用户控制能力，不得把相关性直接当作故意。
3. 屏幕截图、扫描结果或工具告警应保留必要上下文；无法验证来源、时间或对象的材料不得作为唯一依据。
4. 同一事实符合多个条款时，应说明分别保护的利益和额外损害；不得仅为加重处分而重复计罚。
5. 决定方拟作出 Permanent、Server Ban 或其他重大处分时，应安排未直接执行该次 SS 的另一名授权人员复核相关事实与依据。
6. 社区出具的报告应注明其仅为查端结果及参考意见，不构成最终处罚决定。决定方应独立审查其适用性及证据基础；社区结果不应被表述为对设备、账号或受查人全部历史行为的全面保证。

11. 参考处罚与叠加（Reference Penalties and Stacking）

1. 下方处罚表仅为制定规则时的参考示例，不构成社区对任何个人或服务器的处罚要求，也不因社区出具检查结果而自动适用。决定方可在其权限范围内明确采用、调整或另行制定处罚规则，并应事先公开适用条件、期限及申诉渠道；不得在事件发生后为个案临时提高处罚。
2. “第 1 次至第 5 次”是指同一受查人在决定方公开的有效追溯期内，被最终确认的同类违规次数。尚在复核中的决定不得计入下一次。
3. +7d stacking 表示此后每次在上一档基础上增加 7 天；Perm / Permanent 表示无限期停权；Server Ban 表示决定方管理权限范围内的服务器或平台封禁，不当然具有跨服务器或跨平台效力；Event Penalty 表示决定方公开规则中的额外活动限制。
4. 空白单元格或 — 表示参考表未设定该档次，不得推定为自动加重处罚。
5. Force Majeure、证据不足或程序性错误不得通过“叠加”补足。由同一连续行为产生且损害相同的多个标签原则上不重复计罚。

12. 复核与申诉（Review and Appeal）

1. SSer 应向受查人提供书面检查结果摘要，说明事实依据、参考分类、结果局限及检查结果复核渠道。决定方另行作出处理或处罚的，应由其告知实际适用条款、决定内容、生效时间及申诉方式和期限；为保护他人隐私或敏感检测方法而限制披露的，应限于必要范围。
2. 复核申请可以对身份、事实、证据完整性、违规分类、检查程序、Force Majeure、重复计罚或处分计算提出异议。
3. 在合理可行的情况下，复核人员应独立于原检查或原决定，并记录复核结果及理由。社区对其检查结果的复核，与决定方对处理或处罚决定的申诉审查，应分别受理；社区复核不代替决定方的申诉程序。
4. 检查结论被撤销或更正后，社区应及时更正相关记录并告知已接收该结果的决定方，由决定方复查受影响的处理或处罚。经撤销或更正后不再成立的违规，不得继续计入处罚叠加。

13. 隐私、安全与保存（Privacy, Security and Retention）

1. 仅可收集记录 SS 和支持结论所必需的数据。密码、认证令牌、无关私信及无关个人文件不得被保存。
2. SS 资料仅可由具有明确工作需要的授权 SSer、复核人员和安全人员访问。
3. 录像、导出文件、截图和报告应加密或采取其他合理保护措施，记录访问日志，并仅保存至公开期限届满。
4. 保存期限届满后，应安全删除相关资料；法律要求或正在进行的复核确需保留的除外。
5. 未授权访问或披露应按照采用方的安全事件响应流程处理，并在法律要求时通知受影响人员。

14. 参考性质、采用与修订（Reference Status, Adoption and Amendments）

1. 本文全部条款及所附处罚表均为参考材料，供服务器合作方及个人查端方使用。本文不直接替代服务器规则、平台协议、工具服务条款或其他有效约定，也不单独构成检查授权、数据处理授权或处罚依据。
2. 采用方应明确并公开实际采用的条款、版本和适用范围，说明其身份、授权检查人员、批准工具、响应时间、资料保存期限及检查结果复核联系方式；决定方应另行明确处罚规则、违规追溯期、申诉渠道及对参考处罚表的调整。个人查端方没有相应管理权限的，不得仅凭本文作出处罚。
3. 具体适用条款的制定、采纳及执行，以及最终处理、处罚决定权，属于相关服务器运营方及其他具有相应管理权限的第三方，并受适用法律、事先公开规则及有效约定约束。社区仅提供查端结果和参考意见；决定方应对其独立作出的决定及执行行为负责。
4. 本文更新不自动变更采用方已公布的规则。采用方或决定方将修订内容纳入其规则时，应另行履行适用的告知程序并明确生效日期；实质性修订原则上向后适用，对受查人更有利且有权主体明确决定适用于未结事项的除外。
5. 如已采用条款与适用法律或有效约定冲突，应在允许范围内调整适用；某一条款无效或不可执行，不当然影响其他可独立适用条款。本文所称“最终决定”仅用于区分社区参考意见与决定方的处理权限，不排除适用规则或法律规定的复核、申诉及其他救济途径。

二、参考处罚阶梯（Reference Penalty Schedule）

三、Screenshare Reference Terms（English Version）

Version: 1.2
Revision date: October 22, 2026
Intended use: A reference for partner servers and individual screenshare practitioners developing or refining Screenshare (SS) inspection rules to assess suspected cheating, inspection evasion, evidence tampering, or related violations.

Words such as “must,” “must not,” and “should” describe the proposed standards, not inspection powers, sanctioning authority, or obligations independently created by this document. An Adopting Party must specify the provisions actually adopted, their scope, and their effective date, and complete the applicable notice and authorization procedures under Section 14. The Chinese and English versions use matching provision numbers and express the same reference rules.

1. Definitions

1. Screenshare (SS) means a process, conducted within an expressly authorized and disclosed scope, in which screen sharing, remote access, or an approved scanner is used to inspect device state, relevant files, system records, and the operating environment.
2. ScreenSharer (SSer) means a person who has obtained the relevant inspection authorization and conducts an SS within the disclosed and authorized scope, including an authorized individual practitioner.
3. Subject means the person asked or volunteering to undergo an SS. The label does not imply that the person has committed a violation.
4. SS Session means the complete session beginning when formal notice of the inspection is given and ending when the SSer issues a finding or expressly terminates the inspection.
5. SS Tool means software, including but not limited to Echo and Ocean, approved in advance by the Adopting Party for automated screenshare inspection, scanning, or forensic assistance. An SS Tool is an Approved SS Tool under this document only after its name, provider, source, access scope, data-processing practices, output, and applicable terms of service (Tool TOS) have been disclosed to the Subject.
6. Bypass Attempt means an intentional act to obstruct, mislead, or evade an SS by deleting, clearing, modifying, falsifying, replacing, transferring, or concealing evidence or an environment relevant to the inspection.
7. Anti-Forensics means a method, tool, or act intended to reduce the visibility, integrity, traceability, or reliability of evidence.
8. Force Majeure means an event outside a person’s reasonable control that could not reasonably have been foreseen or avoided and that directly prevents compliance with an SS requirement.
9. Permanent / Perm means an indefinite suspension. This duration does not itself exclude review or appeal; available procedures depend on the Decision-Making Party’s rules published in advance and applicable law.
10. Adopting Party means a partner server or individual screenshare practitioner using this document as a reference to develop or refine inspection rules. Referring to or adopting this document does not itself confer inspection or sanctioning authority.
11. Decision-Making Party means the server operator or other relevant third party with authority over the matter, responsible for determining the specific applicable rules and independently making, implementing, and reviewing handling or sanction decisions within that authority.

2. Core Principles

1. Authority and Notice. An SSer must have clear authority to conduct the inspection. Before the SS begins, the Subject must be informed of the reason, scope, tools, recording status, expected duration, data-retention method, and available review process.
2. Purpose Limitation. Inspection is limited to material reasonably connected to the disclosed matter. An SS must not be used to search unrelated private information, account credentials, communications, or trade secrets.
3. Data Minimization. The least intrusive method sufficient to verify the relevant facts must be preferred. A bounded status check or targeted scan must not be expanded into unrestricted file browsing without a documented need.
4. No Unauthorized Alteration. Unless the Subject expressly consents and the act is necessary for the inspection, an SSer must not install, delete, upload, download, modify, or execute unrelated material on the device.
5. Presumption of Innocence and Evidence Standard. Having a category of software installed, joining a group, or presenting a single anomaly does not automatically establish Cheating or a Bypass Attempt. Refusal of an Approved SS Tool or its Tool TOS is handled as procedural Refusing under Section 7.3, but refusal itself must not be treated as direct proof of Cheating or a Bypass Attempt. Any substantive finding must remain supported by reviewable facts.
6. Consistency and Proportionality. Comparable facts must be evaluated under comparable standards. A sanction must account for intent, impact on evidence, repetition, cooperation, and Force Majeure.
7. Confidentiality. SSers and reviewers must keep non-public information encountered during an SS confidential and must not use it outside the inspection purpose.
8. Authorization of Tools and Tool TOS. Where the relevant rules have actually been adopted and the required notice has been given, the Subject’s express acceptance of those inspection rules, consent to the disclosed tool-use scope, and election to continue the SS may authorize the SSer to use Approved SS Tools within that scope. Before a tool runs, the Subject must also accept its then-current Tool TOS. The Subject may reject the inspection rules and decline the entire SS; refusal of an Approved SS Tool necessary to complete the inspection or its Tool TOS is addressed under Section 7.3. Merely reading this document is not consent to inspection, tool execution, or data processing.
9. Separation of Findings and Decisions. Community findings, conduct classifications, and handling recommendations are advisory and do not themselves impose a suspension, ban, or other sanction. The Decision-Making Party independently determines whether to adopt an opinion, which rules apply, and whether to take action or impose a sanction. A community advisory opinion must not be represented as a final sanction decision made by the community.

3. Pre-Session Requirements

1. The SSer must confirm the Subject’s identity, the matter under inspection, and the inspection rules and version actually applicable; explain the advisory status of the findings and identify the Decision-Making Party responsible for subsequent action; identify each proposed Approved SS Tool; provide a means to review the current Tool TOS; and record the Subject’s acceptance or rejection of the inspection rules, the SS, and the Tool TOS, together with the start time of the SS Session.
2. After receiving notice, the Subject must preserve the current state of relevant devices and environments. The Subject must not restart services, clear records, delete files, switch devices, or run cleaners for the purpose of affecting the inspection.
3. A genuine limitation involving device performance, network access, administrator permissions, remote-access software, or accessibility must be disclosed promptly and supported with reasonably verifiable information.
4. If a device contains unrelated sensitive, private, or legally protected material, the Subject must raise the concern before the relevant location is viewed. Where consistent with the inspection purpose, the SSer must use masking, path limitation, Subject-controlled navigation, or another alternative.
5. The Subject must disclose multiple mice, storage devices, virtual mounts, customized operating systems, optimizers, or other unusual conditions that may affect interpretation. Disclosure alone is not a violation.

4. Session Conduct

1. The Subject must respond within the reasonable interval stated in advance and must not leave without justification, deliberately delay, repeatedly interrupt the connection, or obstruct the inspection by restarting or exiting relevant applications.
2. After an instruction to preserve an application, game process, or remote connection, the Subject must not close it. A genuine crash, outage, or system failure must be assessed on verifiable facts and must not be presumed intentional merely because it has the same result.
3. The Subject must not seize control, conceal a relevant window, provide a false explanation, or direct the SSer to the wrong device, account, location, or time period.
4. The SSer must remain within the disclosed scope. If unrelated private material appears, the SSer must stop viewing it and avoid copying or disclosing it.
5. An SSer may use Approved SS Tools, including but not limited to Echo and Ocean, within valid authorization and the disclosed scope. Before first use, the SSer must disclose the tool’s name, provider, source, access scope, data transmitted to or retained by a third party, and output, and must provide a means for the Subject to review and accept the current Tool TOS. The SSer must not use an unapproved tool or operate a tool outside its disclosed scope.
6. After expressly accepting the inspection rules actually applicable and electing to continue the SS, the Subject must cooperate with Approved SS Tool use under the disclosed and authorized inspection procedure and accept the Tool TOS before a tool runs. If the Subject rejects the inspection rules, declines the entire SS, or refuses an Approved SS Tool necessary to complete the SS or its Tool TOS, the SSer must stop the inspection and, where the conditions in Section 7.3 are met, record Refusing the entire SS. The Decision-Making Party determines whether published refusal consequences apply under its rules; refusal alone must not establish Cheating or a Bypass Attempt.
7. Admitting means a clear, voluntary, and accurately recorded admission made after the Subject understands the question and consequence. An ambiguous, speculative, or pressured statement must not be the sole basis of a finding.

5. Light Offenses

5.1 Inability to SS

1. Type I — Unintentional technical limitation: low device performance, an unstable network, lack of administrator permissions, or a remote-access failure, where there is no evidence that the Subject intentionally created, configured, or falsified the limitation.
2. Type I — Intentionally caused or falsified limitation: intentionally causing, exaggerating, or falsifying a technical limitation in order to prevent or shorten an SS.
3. Type II — Environmental limitation: a Customized OS, Trimmed OS, irrecoverably missing component, or another environment that makes a complete SS technically impossible. The SSer must attempt reasonable alternative inspection methods before making a finding.
4. Type III — Approved SS Tool scan: where the Subject can run an SS Tool approved by the Adopting Party, has accepted its Tool TOS, and its scope is sufficient to resolve the matter, the scan may complete or partially complete the SS. A matter outside the tool’s coverage must not be described as verified.

5.2 1+ Mice Connected / No Mouse Software

Where two or more pointing devices are connected, expected mouse software is absent, a device is broken, or its configuration is unusual, the device identity and explanation must be recorded. A violation may be found only where the condition was not disclosed, the explanation is demonstrably false, or the condition was used to conceal a macro, script, input modification, or device substitution. The number of devices alone does not establish Cheating.

5.3 Stalling

Stalling means leaving without justification, persistently failing to reply, repeatedly disconnecting, deliberately creating irrelevant steps, or otherwise delaying the inspection after a clear instruction and reasonable response interval. A temporary outage, accessibility need, emergency, or other Force Majeure is not Stalling.

5.4 SS Misuse

SS Misuse means falsifying, impersonating, altering, or reusing an SS report; using an expired report to evade a new inspection requirement; disclosing SS material to an unauthorized person; or using an SS finding outside its authorized purpose.

6. Force Majeure

1. A reasonably verified Force Majeure event must not result in a primary sanction and must not be stacked with another violation.
2. The SSer must record the event, the affected requirement, the alternatives attempted, and whether the SS must be rescheduled.
3. If only part of the inspection is affected, the necessary and unaffected portion may be completed, but the event must not be used to expand the inspection scope.
4. Intentionally falsifying or abusing Force Majeure in bad faith may be evaluated as a Bypass Attempt. An inability to prove the event immediately does not by itself establish bad faith.

7. Medium Offenses

7.1 Disabled Services

1. Disabled Services may be found where a system service or record source relevant to the inspection has been disabled, terminated, truncated, or made inaccessible, and that condition materially reduces evidence visibility. Common sources include SysMain, CDPUserSvc_{...}, PcaSvc, DPS, EventLog, Task Scheduler, SearchIndexer, BAM/DAM, DusmSvc, and Appinfo.
2. Equivalent conditions include terminating BAM inheritance, disabling ActivitiesCache, disabling Jump Lists, and terminating relevant service threads.
3. A disabled service alone does not prove intent. The SSer must consider when and how it was disabled, who controlled the act, the effect of an optimizer, the operating-system version, and whether the condition can be restored.
4. A Subject using an optimizer or custom configuration is responsible for understanding its effects, but the SSer must still establish a connection to the inspection. The use of an optimizer is not a substitute for evidence.

7.2 Closing Relevant Applications

Intentionally closing a relevant application, process, or remote connection after a clear preservation instruction is a violation. A genuine crash or non-user-caused outage must be evaluated separately. Logging out alone is not automatically a violation where relevant evidence is unaffected.

7.3 Refusing / Admitting

1. Refusing means rejecting the inspection rules actually applicable, declining the entire SS, or refusing an Approved SS Tool required to complete the SS, including refusal to accept that tool’s applicable Tool TOS, after the inspection’s authority and reasonable scope have been established and the required notice has been given. This classification records why the inspection could not continue. Any consequence must be published in advance by the Decision-Making Party, which determines whether it applies.
2. Admitting means clearly acknowledging the relevant violation. The full context must be preserved, and independent corroboration should be obtained where possible.
3. The Subject may reject the inspection rules and decline the entire SS. If the Subject expressly accepts those rules and elects to continue, but then refuses an Approved SS Tool necessary to complete the inspection or its Tool TOS, that refusal is recorded under this Section as Refusing the entire SS. It does not create a right to require a manual-only inspection. The SSer must not force tool execution or continue accessing the device after the Subject refuses.
4. An objection is not Refusing where the tool has not been approved by the Adopting Party, the current Tool TOS has not been made available, required disclosures have not been given, or the proposed operation exceeds the disclosed scope. The SSer must first cure the defect. Refusing does not itself revoke the presumption of innocence or prove Cheating or a Bypass Attempt.

7.4 Tampering

Tampering means deliberately making relevant material harder to locate, hiding or moving windows, altering search results, misdirecting a path, withdrawing necessary permissions, or changing relevant state during an SS for the purpose of obstructing the inspection. Refusing or ending an inspection under Section 7.3 does not itself constitute Tampering. A confidentiality concern raised by the Subject must be handled through the limitations in Section 3.4. Checking whether a file is private does not justify unrestricted inspection of images, documents, text, or scripts.

7.5 Cheating

Cheating may be found where a cheat client, cheat application, macro, script, or other unfair functionality is discovered and the evidence establishes its existence, usability, and connection to the inspected matter. The finding must distinguish:

• whether the tool has self-destruction or alerting self-destruction functionality;
• whether Bypass or Anti-Forensics was used;
• whether the tool was merely concealed or its form, time, or evidence was altered; and
• whether any type of Bypass Attempt was also committed.

Where a Bypass Attempt exists, it must be recorded separately. A generic Cheating label must not conceal more serious evidence tampering.

8. Severe Offenses

8.1 Bypass Attempt

A Bypass Attempt may be found only on clear, reviewable evidence that the conduct was intended to obstruct or mislead an SS. The presence of software, ordinary legitimate use, or an isolated system anomaly is not sufficient by itself.

1. Type I — Clearing or resetting evidence sources: restarting a relevant service to change its state; clearing Journal, Registry entries, Event Logs, Prefetch, or shell:recent; using string cleaners or file shredders; tampering with NvAPPTimestamps; or intentionally giving the SSer false information about a relevant condition.
2. Type II — Replacing, overwriting, or reconnecting an environment: using PsExec or a scripting environment to alter evidence; overwriting or replacing files on FAT16/FAT32/exFAT media; reconnecting a mass-storage device; or changing Virtual Mounts. The ordinary presence of development tools, scripting environments, or external media is not a violation; a connection to evidence alteration must be established.
3. Type III — Proximate or scheduled anti-forensic execution: scheduling or running PowerShell, PowerShell ISE, CMD, batch files, cleaners, optimizers, Process Hacker, System Informer, ProcMon, WMIC methods, Registry changes, or other scripts near an SS, where evidence establishes that the act was used to hide, clear, or alter relevant information. This Type also includes Unicode obfuscation of cheat tools or intentionally changing a default Downloads path to misdirect the inspection.
4. Type IV — Identity, device, or data substitution: switching devices; having another person or account undergo the SS; using public Anti-Forensics; altering file data or metadata; or combining multiple distinct types of bypass conduct.
5. A person who misrepresents the environment or deliberately selects a lesser offense description to evade the correct classification may be reclassified according to the actual conduct. Merely offering a different explanation does not establish a lie.

8.2 Prohibited Modifications

Proxy clients, mouse macros, external macros, input automation, HitDelay modifications, Freelook, or similar features are Prohibited Modifications where they are used to obtain an unfair advantage or evade inspection and are prohibited by the rules actually applicable. “Prohibited” refers to those rules and is not a legal determination that the conduct is unlawful. A launcher or tool used only for graphics, performance, or accessibility optimization is not prohibited merely by category where it contains no banned functionality.

8.3 Ping Manipulation

The intentional use of a hotspot, proxy, VPN, or other method to falsify, manipulate, or conceal network conditions may be a violation where its purpose is to obtain an unfair advantage, evade an SS, or avoid an existing sanction. A VPN, enterprise network, Cloudflare WARP, or network fluctuation alone is not a violation.

8.4 Input Modification

An internal or external tool that changes mouse sensitivity, acceleration, or assistive input is allowed where it does not include CPS automation, HitDelay modification, macros, or other prohibited functionality.

8.5 Modified OS

1. A Customized OS or Trimmed OS may be treated as a Modified OS where it disables many necessary services, makes key records unavailable, and cannot reasonably be restored. The SSer must attempt reasonable, low-risk alternatives before making a finding.
2. Where more than three key services or record sources are affected, Inability to SS may also be evaluated, but the same evidentiary harm must not be counted twice.
3. Boot Camp or another legitimate cross-platform environment is not a violation by itself.
4. Trimming caused by a system optimizer must be evaluated according to the actual state, timing, and evidentiary impact. A brand or commercial relationship does not by itself establish or exclude a violation.

8.6 Deleting Relevant Files

Intentionally deleting, shredding, overwriting, or making a relevant file unrecoverable after notice of an inspection, or when an inspection is reasonably foreseeable, is a violation where it materially impairs the SS. Ordinary automated cleanup, storage failure, or deletion unrelated to the inspection must be evaluated with the timeline and other evidence.

9. Organized Bypass, Bribery, and Bypass Services

1. Organized Bypass means organizing or assisting another person to evade an SS through device substitution, identity substitution, presentation of a clean device, concealment of information, or a coordinated false account.
2. Bribing ScreenSharers means offering or promising an improper benefit to an SSer, reviewer, or administrator, or such a person requesting or accepting an improper benefit, to influence the inspection process, evaluation of evidence, or findings. An involved SSer must be recused immediately and independently investigated.
3. Providing Bypass Services means creating, selling, distributing, teaching, or specifically supplying Anti-Forensics, camouflaged programs, cheat tools, or procedures intended to evade an SS.
4. Receiving Bypass Services means knowingly purchasing, obtaining, or using a service intended to evade an SS.
5. Membership in a group, viewing public material, association with a person, or expressed interest does not automatically revoke the presumption of innocence. Actual participation, provision, receipt, or use must be established.

10. Evidence, Findings, and Records

1. Every inspection finding must identify the inspection rules actually applicable and the provisions referenced in this document, material facts, timeline, evidence sources, evidence integrity, alternative explanations, and the SSer’s reasons. Verified facts, unresolved issues, and advisory opinions must be distinguished.
2. A system state that can occur naturally or through ordinary software must be evaluated for timing, causation, and user control. Correlation must not be treated as intent without supporting facts.
3. A screenshot, scanner result, or tool alert must retain necessary context. Material whose source, time, or Subject cannot be verified must not be the sole basis of a finding.
4. Where one act falls within multiple provisions, the assessment must identify the distinct interest protected and additional harm addressed by each. Classifications must not be duplicated solely to increase a sanction.
5. Before imposing a Permanent suspension, Server Ban, or other major sanction, the Decision-Making Party must arrange for another authorized person who did not directly conduct the SS to review the relevant facts and grounds.
6. A community report must state that it contains inspection findings and advisory opinions only and is not a final sanction decision. The Decision-Making Party must independently assess its applicability and evidentiary basis. Community findings must not be represented as a comprehensive guarantee concerning a device, account, or the Subject’s entire history of conduct.

11. Reference Penalties and Stacking

1. The schedule above is an example for rule drafting only. It is not a community requirement to sanction any person or server and does not apply automatically when the community issues findings. Within its authority, the Decision-Making Party may expressly adopt, amend, or replace it and must publish the applicable conditions, durations, and appeal channels in advance. A sanction must not be increased ad hoc after the event for an individual case.
2. “First” through “Fifth” refer to finally sustained violations of the same category within the Decision-Making Party’s published lookback period. A decision still under review must not count toward the next instance.
3. +7d stacking means seven days are added to the previous level for each later instance; Perm / Permanent means an indefinite suspension; Server Ban means a server or platform ban within the Decision-Making Party’s authority, with no automatic effect across other servers or platforms; and Event Penalty means an additional participation restriction defined in that party’s published rules.
4. A blank cell or — means that the reference schedule does not define that level; no automatic escalation may be inferred.
5. Force Majeure, insufficient evidence, or a procedural defect cannot be cured through stacking. Multiple labels arising from the same continuous act and protecting the same interest should not be punished more than once.

12. Review and Appeal

1. The SSer must provide the Subject with a written inspection summary stating the factual basis, reference classification, limitations, and channels for reviewing the findings. If the Decision-Making Party separately takes action or imposes a sanction, it must communicate the rules actually applied, the decision, its effective time, and the appeal procedure and deadline. Restrictions on disclosure to protect another person’s privacy or sensitive detection methods must be limited to what is necessary.
2. A review request may challenge identity, facts, evidence integrity, classification, procedure, Force Majeure, duplication, or sanction calculation.
3. Where reasonably possible, the reviewer must be independent of the original inspection or decision and must record the result and reasons. The community’s review of its findings and the Decision-Making Party’s review of an action or sanction must be handled separately; community review does not replace that party’s appeal process.
4. If an inspection finding is withdrawn or corrected, the community must promptly correct its records and notify Decision-Making Parties that received the finding so they can reassess affected actions or sanctions. A violation that no longer stands after withdrawal or correction must not remain in stacking calculations.

13. Privacy, Security, and Retention

1. Only data necessary to document the SS and support a finding may be collected. Passwords, authentication tokens, unrelated private messages, and unrelated personal files must not be retained.
2. Access to SS material must be limited to authorized SSers, reviewers, and security personnel with a documented need.
3. Recordings, exports, screenshots, and reports must be encrypted or otherwise reasonably protected, access-logged, and retained only for a published period.
4. At the end of the retention period, material must be securely deleted unless preservation is required by law or an active review.
5. Unauthorized access or disclosure must be handled under the Adopting Party’s incident-response process, including notice to affected persons where required by law.

14. Reference Status, Adoption and Amendments

1. Every provision and the accompanying penalty schedule are reference materials for partner servers and individual screenshare practitioners. This document does not directly replace server rules, platform agreements, Tool TOS, or other valid agreements, and does not independently authorize inspection, data processing, or sanctions.
2. The Adopting Party must identify and publish the provisions, version, and scope actually adopted, its identity, authorized inspectors, approved tools, response intervals, retention period, and contact for reviewing inspection findings. The Decision-Making Party must separately specify its sanction rules, lookback period, appeal channels, and any changes to the reference schedule. An individual practitioner without the relevant authority must not impose a sanction solely on the basis of this document.
3. Authority to establish, adopt, and enforce the specific applicable rules and to make final handling or sanction decisions rests with the relevant server operator and other third parties with the necessary authority, subject to applicable law, rules published in advance, and valid agreements. The community provides inspection findings and advisory opinions only. The Decision-Making Party is responsible for its independent decisions and their implementation.
4. An update to this document does not automatically amend rules already published by an Adopting Party. When incorporating a revision into its rules, the Adopting Party or Decision-Making Party must complete the applicable notice procedure and specify an effective date. Material amendments generally apply prospectively, except where more favorable to the Subject and expressly applied to an open matter by the competent party.
5. An adopted provision that conflicts with applicable law or a valid agreement must be adjusted within the permitted scope. The invalidity or unenforceability of one provision does not automatically affect other independently applicable provisions. “Final decision” distinguishes the community’s advisory opinion from the Decision-Making Party’s authority; it does not exclude review, appeal, or other remedies available under applicable rules or law.