本文件包含完整中英文构思，可通过语言链接跳转，也可直接向下阅读。
This README contains the full concept in Chinese and English. Use the language links or continue scrolling.
一个无需新增教室专用硬件的课堂签到构想。
教师现有手机作为课堂根，学生现有手机通过蓝牙近场双向互证，再将本人核验与同一次课堂会话绑定。目标是让“知道接口怎么调用”不再等于“能够在校外批量签到”。
项目状态：Concept / Design Discussion。
这里分享的是完整构思，不是已经实现的软件。目前没有可运行的 App、SDK、演示或经过验证的性能与安全结论，也不提供安装和部署步骤。文中的流程、能力与界面均为设计设想。
- 不加教室设备：不为每间教室安装 Beacon、摄像头或专用考勤机，使用师生已有手机。
- 少打扰课堂：理想学生流程是“打开签到 → 本人核验 → 短暂等待”，附近互证由系统完成。
- 重点防规模化：聚焦没有教室内受控终端的纯远程批量发包、重放与虚拟身份攻击。
- 证据由多方产生：课堂挑战、设备身份、本人核验、同伴见证与教师记录相互绑定，不能只相信一个客户端。
- 接受明确边界：需要逐教室安排现场同伙或桥接设备的攻击，不是这个构想的重点；排除它不等于证明它不可行。
- 保留公平与隐私：技术失败不直接等于作弊，人脸有替代通道，临时邻接关系不用于持续追踪。
如果只用一句话表达：
不要让发起签到的客户端，同时拥有生成全部签到证据的能力。
- 为什么提出这个构想
- 想解决什么和不解决什么
- 核心思路
- 整体结构
- 一次签到如何发生
- 为什么重点防协议发包
- 威胁模型与能力边界
- 正常体验与异常处理
- 隐私与公平
- 还可以怎样发散
- 仍值得讨论的问题
- 常见问题
- 参与讨论
- 参考资料
二维码、位置、手势和口令都可以成为签到入口。但对于那些只依赖可复制内容，或仅相信学生客户端声明的设计，入口再复杂，最后仍可能退化成一次可复刻的网络请求。
例如：
“我知道这个签到码。”
“我提交的坐标在教室附近。”
“我扫描到了某个蓝牙设备。”
这些声明本身，并不等于“这个学生此刻正在这间教室上课”。
这里不是断言所有现有签到产品都能被轻易绕过，而是提出一个设计问题：
如果攻击者完全知道接口、参数和消息格式，但无法控制课堂现场，服务器还能要求哪些由他无法单独产生的证据？
由此产生了这个想法：
- 教室里本来就有许多真实手机。
- 手机可以在短距离内发现和交互。
- 学生手机之间可以为同一时刻的相遇分别留下记录。
- 教师手机可以为这些相遇提供课堂起点。
- 人脸核验可以补充“拿着设备的人是谁”。
把这些信息绑定到同一次签到中，或许就能改变签到的信任结构，而不只是再增加一种签到入口。
| 目标 | 具体含义 |
|---|---|
| 零新增教室专用硬件 | 不要求每间教室安装和维护固定考勤设备 |
| 正常流程简短 | 学生不手动选见证人、不互扫二维码、不逐台配对；教师只处理少量例外 |
| 抵御纯远程规模化代签 | 研究协议、复制请求或运行脚本，不应足以在没有现场协助的情况下批量制造出席 |
“零新增硬件”不意味着软件、服务、兼容性或隐私治理完全没有成本；这里只限定教室不新增专用设备。
- 不追求任何条件下都不可绕过。
- 不证明学生一定坐在某个座位，也不做持续定位。
- 不把普通蓝牙当作严格的教室边界或安全测距。
- 不重点对抗每间目标教室都有现场桥接端的攻击。
- 不尝试用纯技术解决教师与学生共同作弊。
- 不把“在场”当作认真听课、学习效果或课堂参与度的证明。
- 不建设区块链、代币、挖矿或公开学生社交关系的网络。
签到判断围绕五类证据展开：
本人 · 本机 · 本课 · 本时 · 本场
这是一种概念划分，不是已经成立的数学安全证明。
| 证据 | 想回答的问题 | 拟采用的方式 |
|---|---|---|
| 本人 | 当前操作人与学生身份相符吗？ | 本次会话的人脸一对一核验与活体，或等效替代 |
| 本机 | 请求来自该账号绑定的主要设备吗？ | 设备身份、受保护密钥与设备状态约束 |
| 本课 | 这份证据属于哪门课、哪次签到？ | 课程和会话绑定 |
| 本时 | 这是新鲜发生的交互，而非历史记录吗？ | 不可预测挑战、短时有效性与防重复使用 |
| 本场 | 设备是否接入教师所在的课堂近场关系？ | 教师手机根、双向近场交互及同伴独立见证 |
关键不只是同时获得五项结果，而是让它们相互绑定：
- 不能把上节课的近场证据用于这节课。
- 不能把甲设备的人脸结果交给乙设备使用。
- 不能把一个人的见证记录改成另一个人的身份。
- 不能只上传“蓝牙成功”和“人脸成功”两个客户端布尔值。
- 不能让所有所谓“独立证据”最终仍由一个客户端自行编写。
只让学生相互发现，最多能说明一群设备聚集在某处。它们可能在教室，也可能在宿舍。
因此，构想中保留一个可信的课堂起点：已经获得本次课程授权、并由教师在现场使用的手机。
它为本次签到产生临时课堂挑战，通过近场通道发布，并分别留下教师侧的交互或观察记录。其他学生的证明需要能关联到这个课堂根，而不是任意一张自成一体的学生网络。
每台学生手机只与少量随机同伴完成双向交互，不要求全班两两连接。
这里的“互证”不是投票，也不是看到足够多的蓝牙名称就算成功，而是两个已登记的设备分别为这一次相遇提供可相互核对的记录。
flowchart TD
S["学校服务端<br/>课程授权与证据判断"]
T["教师现有手机<br/>本次课堂根"]
A["学生手机 A<br/>本人核验与设备身份"]
B["学生手机 B<br/>本人核验与设备身份"]
C["学生手机 C<br/>本人核验与设备身份"]
S -->|"课程授权"| T
T <-->|"近场交互"| A
T <-->|"近场交互"| B
A <-->|"随机双向互证"| B
B <-->|"随机双向互证"| C
T -.->|"教师侧记录"| S
A -.->|"独立提交"| S
B -.->|"独立提交"| S
C -.->|"独立提交"| S
图中只是关系示意，不代表连接数量、真实拓扑或已验证的覆盖能力。直接观察与多跳互证如何组合，仍属于可讨论的设计取舍。
服务端不因为学生上传了一张“附近同学列表”就承认出席，而是核对：
- 是否存在本次授权课堂根；
- 账号、主要设备与本人核验是否对应；
- 互证双方的记录是否相互吻合；
- 所有证据是否属于相同课程和时间窗口；
- 是否出现重复使用、单边声明或明显冲突。
最终输出的不是“绝对证明本人坐在教室”，而是“是否满足这套构想规定的签到证据要求”。
以下是理想交互，不是已达到的时延或成功率承诺。
学生完成身份与主要设备绑定，了解附近设备权限、本人核验和替代方式。换机、无手机和不适用人脸的情况有单独通道，不把一次技术设置变成长期上课障碍。
教师打开本节课，点击“开始签到”。
教师手机在此时产生新鲜的课堂挑战。学生可以从网络得知课程和签到状态，但不应能从普通学生接口直接取得完整、可复用的现场证明。
学生进入签到页面，接收本次课堂挑战，与教师手机或已经关联课堂根的同伴建立本轮近场交互。
学生在远端自行组织的互证网络，不应仅凭“人数多、图很密”就被认可。
本人核验与本次课堂、当前设备及短时窗口绑定。不是先拍一次脸，再长期使用一个“人脸已通过”的状态。
概念中的标准流程包含学籍身份的一对一人脸核验和活体，同时保留便捷的非人脸替代。手机系统的 Face ID 或指纹解锁可作为设备授权手段，但不能直接等同于“学校已确认这是该学生”。Apple LocalAuthentication
学生不选择自己的好友作为见证人。系统分配本轮少量互证关系，双方分别完成挑战与回应，再独立提交记录。
这种随机性旨在减少自主选择固定同伙的空间，并不意味着随机图天然安全，也不意味着相同同学反复相邻就是作弊。
理想学生体验是：
打开签到 → 完成本人核验 → 等待近场证据补齐 → 查看结果。
教师端则尽量只显示已完成、待补强和需要复核的学生，而不是让教师理解无线图、密钥和协议细节。
协议始终可以被观察和理解。这个构想不依赖“攻击者不知道参数”，而是希望让某些必要证据不能由远程攻击者单独产生。
| 所需证据 | 来源 | 仅修改请求为什么不应足够 |
|---|---|---|
| 本次课堂挑战及教师记录 | 教师手机 | 不能只由学生客户端自称“老师已看到我” |
| 当前设备的证明 | 已绑定设备 | 知道账号密码不应等于拥有设备的受保护密钥 |
| 本次本人核验结果 | 可信核验链路 | 不能使用客户端自填结果，也不能跨会话复用 |
| 双向同伴见证 | 两端分别产生和提交 | 不能由一方凭空编造另一方的回应 |
| 会话与有效期 | 多份证据共同绑定 | 历史记录、改字段和重复提交不应仍有效 |
设备和应用完整性证明可以为这一方向提供参考能力，但不是“物理位置认证”，也不是所有手机都天然具备的不可伪造身份证。Android Play Integrity、Apple App Attest
如果最终规则只是“知道老师刚广播的随机数就能签到”，方案又会退化成可以转发的签到码。
因此，课堂挑战只是把各项证据串起来的本轮标记。知道它本身不能直接获得签到资格；还应有账号与设备绑定、本人核验、相互对应的近场记录，以及教师根关联证据。
蓝牙广播中的数据并不会因为经由蓝牙发送就变得不可复制。真实性来自证据之间的来源与绑定关系，不来自为某个字段换一种传输方式。
这个 README 希望把思路公开，而不是把协议当作秘密。
理想目标是：即使读者理解全部消息格式，只要不掌握受信设备、本人核验结果和课堂侧证据，单纯构造网络请求也不应满足签到规则。
目前这仍是一项设计主张，不是经过形式化证明或实际验证的结论。
- 学校服务端、课程授权与教师身份没有被攻击者控制。
- 教师在实际授课现场发起签到；本方案不另行证明教师所在位置。
- 学生初始身份与主要设备绑定可信，受保护密钥未被盗取。
- 本人核验不是客户端自报成功，而由可信链路产生本次结果。
- 攻击者可以研究协议、重放请求、控制多个远程账号或设备。
- 针对重点防护范围，目标教室内没有攻击者控制的转发终端，也没有为其实时搬运现场证据的同伙。
最后一条是主动选择的范围，不是蓝牙协议自动提供的安全属性。
| 场景 | 在构想中的定位 |
|---|---|
| 校外脚本直接调用签到接口 | 核心目标：单个客户端不应能生成完整证据 |
| 重放旧请求或修改账号、课程、时间 | 核心目标：新鲜会话与证据绑定应使其失效 |
| 模拟器或单设备伪装大量学生 | 核心目标：已登记设备身份与账号绑定限制批量伪造 |
| 复用人脸结果、客户端伪造成功 | 核心目标：本次、本人、本机绑定，而非接受自报值 |
| 一群学生在宿舍互相见证 | 在无课堂现场协助的假设下，不应形成有效教师根证据 |
| 固定小团体、频繁换机、异常账号共享 | 基础约束与可解释风险提示，不凭关联直接判作弊 |
| 每个目标教室均有桥接手机或现场同伙 | 已接受的剩余风险，不作为核心对抗任务 |
| 专业无线中继、系统级漏洞、教师合谋 | 已接受的剩余风险，不承诺解决 |
本构想关注的是跨多个教室、多个并发课程的纯远程规模化服务。如果攻击必须为每个课堂维持现场落点，它已不再是一个无需现场资源的集中脚本。
这不表示桥接一定昂贵，也不表示一台桥接手机只能影响一个账号；它可能影响同一课堂内的多个人。这里只是明确选择：不为覆盖这类已接受风险，把普通学生的签到变成更复杂的流程。
普通蓝牙信号可能跨墙，接收强度会受设备、遮挡和环境影响。“收到广播”“有多条见证边”都不能直接推出“位于某个座位或墙体以内”。
同样，签名证明消息来源和完整性，并不自动证明物理距离。BLE 邻近交互仍需考虑应用层保护及相应边界。USENIX BLE 应用层安全研究
因此本文使用“课堂在场证据”而非“绝对位置证明”，也不设置未经依据的信号强度硬阈值。
这里假设采用与学籍身份对应的一对一核验及可靠活体，而不是仅检测眨眼、转头或上传自拍。
即便如此，人脸也不是不可攻击的绝对真值；NIST 的呈现攻击检测评测体现了不同算法与攻击类型之间的能力差异。它在本构想中的作用，是补充本人证据并抬高无人值守批量操作的门槛。NIST FATE PAD
学生不应该为了签到而遍历同学列表、选择见证人或重复操作设备配对。教师也不应该成为现场系统维护人员。
预期结果分为三类：
| 状态 | 含义 | 合理的下一步 |
|---|---|---|
| 证据相符 | 满足本次签到规则 | 显示完成 |
| 证据不足 | 权限、网络、设备能力或无线关系不充分 | 自动重试或提供替代核验 |
| 存在冲突 | 出现重复、矛盾或无效证明 | 说明原因并人工复核 |
技术失败不等于学生作弊。 即使出现密码学错误，也应先区分攻击、软件缺陷与数据损坏，不能直接产生纪律处分。
- 蓝牙关闭或权限拒绝：说明用途，允许重新授权或选择替代方式。
- 小班课：不以固定同伴数量卡住学生，提高教师直接确认的权重。
- 迟到：为本次补签生成新窗口，不复用已经结束的班级证据。
- 网络中断：可以设想暂存已经形成的现场记录；完整离线本人核验与记录有效性仍是开放问题，不声称已经解决。
- 手机没电、损坏或没有智能手机：提供教师现场确认，不把设备拥有情况当作出席资格。
- 换机或设备维修：允许撤销旧绑定并重新确认，防止旧设备与新设备同时代表同一身份。
- 人脸不适用或不同意使用：提供同样合理、便捷的非人脸流程，不故意增加羞辱性动作或额外惩罚。
- 代课或换教室：教师获得课程授权后建立新的课堂根，不需要搬迁专用硬件。
签到不应顺便变成学生轨迹库或社交关系分析工具。
- 近场扫描限定在明确、短时的签到窗口。
- 清楚告知扫描与采集内容，不用“无感”代替知情。
- 不默认持续后台定位、持续录音或持续摄像。
- 不因安全目的无限增加权限。
手机之间不主动广播学号、姓名、手机号或长期设备标识，而使用本节课的临时身份，减少跨课关联。
但临时标识只是降低关联风险，不等于消除无线特征、时间、位置或旁观者推断。学校服务端仍需将证明关联到学生，不能把它宣传成“完全匿名签到”。
同伴也不应看到其他学生的人脸、学号或完整考勤记录。
| 数据 | 设计原则 |
|---|---|
| 正式考勤结果与更正记录 | 根据明确用途与学校规则保留，允许查询和申诉 |
| 本次近场原始记录与临时邻接关系 | 仅保留必要的短申诉窗口，之后按规则删除或最小化 |
| 人脸采集样本及核验服务数据 | 区分本次新增数据、学校既有底图与供应商处理，尽量减少新增留存 |
“临时身份过期”不等于服务器已删除相关记录；数据删除、日志保留与第三方留存都需要单独说明。摘要也不应被默认称为“不可关联”。
人脸应遵循必要性与最小影响原则，并提供合理便捷的替代。撤回人脸处理授权，也应与正式考勤记录的更正、删除和必要保留规则分别说明。国家网信办《人脸识别技术应用安全管理办法》
这部分是概念层面的设计原则，不构成具体学校场景的合规结论。
以下是可选方向，不是功能清单或开发路线。
对确有必要确认中途在场的课程，可以在课中出现一次短暂、事先不固定的近场刷新。
它不必再次完整人脸，也不默认每节课启用。讨论重点是“这种打扰是否值得”，而不是把签到变成持续监控。
将轻量在场确认与课堂问题、匿名投票或即时反馈结合，让操作本身产生教学价值。但回答正确与否不应成为出席条件，教学评价与在场判断也应分开。
让学生知道本次用了哪些证据、是否处理人脸、哪些记录会在何时删除、谁进行过人工更改，以及如何申诉。
它只展示自己的必要记录，不公开其他同学的见证关系。
大课可以依赖更广的同伴互证，小班可更多依赖教师直接确认；讲座、实验培训与研讨课也不必采用完全相同的规则。
系统越灵活，越需要防止较弱的替代路径变成批量绕过入口。这是值得讨论的产品取舍。
一个学生在场，并不代表认真听讲；一条缺失的设备证据，也不代表学生没有学习。
课证可以坚持只提供有限的出席证据，不把无线行为进一步解释为专注度、人格或学习态度。
类似结构也可以用于校园讲座、工作坊、社团活动或培训到场的概念讨论。
这里不把它直接推广为考试身份核验、应急人员清点或其他高风险场景的替代方案。
这些问题用于完善构想，不是待开发任务：
- 目标是否合适？ 对普通课程而言，压缩纯远程批量代签空间，是否已经比追求所有情形下的绝对真实性更有价值？
- 同伴互证需要多重要？ 在教师根已存在的情况下，它主要提供覆盖和独立证据，还是应当承担更多真实性判断？
- 一次操作应花在哪里？ 每次本人核验与只对异常补强，哪一种更符合课堂与学生接受度？
- 怎样做等效替代？ 无手机、换机、人脸不适用与权限拒绝的通道，怎样同时兼顾公平和反批量滥用？
- 哪些信息应该可见？ 学生应知道自己参与了何种互证，但是否有必要知道具体见证了谁？
- 何时不应该升级？ 哪些课程应明确不启用课中刷新、声音特征或额外设备信号？
- 多短的证据保留才够？ 如何让申诉有依据，同时避免积累学生位置与关系数据？
- 怎样评价“更难规模化”？ 应分别看账号数量、教室数量还是并发课程，而不是用一个笼统的“绝对安全”描述？
不是。当前只有构想文档，没有应用、接口服务、供应商选择或实际效果数据。本文描述的是想要成立的产品逻辑。
不是。如果最后仍只让客户端提交两个成功标志，信任结构没有变化。关键是各项证据由不同来源产生，并共同绑定当前身份、设备、课程和时间。
学生设备互证只能说明某些设备聚在一起，不能单独说明它们在这位教师的课堂。教师手机提供受授权的课堂起点；这里也明确依赖教师诚实在场的假设。
不是。只是教室新增硬件成本为零这一设计目标；手机兼容、软件、服务、身份核验与隐私治理仍有成本。
因为真实课堂不需要每个学生都见证所有人。稀疏、随机、短时的互证关系更符合低打扰目标，但足够程度及失败处理仍需合理定义，不能用理论上连通替代现实可靠性。
这里没有挖矿、代币或去中心化账本，学校仍是课程与身份的授权主体。“多方见证”只是一个信任设计思路，不等于区块链共识。
如果本人核验确实发生在当前设备和本次签到中，且核验链可信，它是用于抑制这类行为的重要证据。但本机解锁不等于学籍人脸认证，人脸本身也不提供物理位置证明。
需要逐教室现场协助的转发攻击属于本构想主动接受的边界。这里不把它包装成“已经解决”，也不因此增加全部学生的操作负担；重点仍是没有课堂现场落点的纯远程批量请求。
不应如此。证据不足需要替代和补强，明确冲突也需要解释与复核，最终考勤和处分不能只依赖一个不透明评分。
不会。移动平台的近场通信、权限和后台行为存在差异。现有平台能力可作为思路参考，但不等于本构想已经具备跨平台覆盖或大班容量。Nearby Connections、Android 蓝牙权限、Apple Core Bluetooth 后台行为
欢迎通过 Issue 或文档修改建议讨论这个构想，尤其是：
- 指出概念中的逻辑断点或不成立的信任假设；
- 提出在现有三项约束下更简洁的思路；
- 讨论人脸、替代流程、隐私和课堂体验；
- 补充官方文档、原始研究或真实业务场景；
- 帮助把复杂机制表达得更清楚。
提出问题时，可以简单说明：讨论的是哪个场景、攻击者或参与者具有什么条件、现有描述缺在哪里，以及建议改变什么。
请不要提交真实学生人脸、学号、考勤记录、设备凭据或其他个人敏感信息。这里讨论的是一般性防护构想，不是针对某个学校或现有系统的绕过工具。
以下资料用于了解局部技术能力与限制，不表示相关机构验证、认可或背书了整个 ClassMesh 构想：
- Nearby Connections：邻近设备通信的能力参考。
- Android 蓝牙权限：附近设备权限与用户交互边界。
- Apple Core Bluetooth 后台行为：后台发现与广播限制。
- Android Play Integrity：应用与设备完整性信号。
- Apple App Attest：应用实例及请求真实性参考。
- Apple LocalAuthentication：本机生物认证与业务身份判断的区别。
- NIST FATE PAD：人脸呈现攻击检测评测。
- USENIX BLE 应用层安全研究：蓝牙链路之外仍需应用层保护。
- 国家网信办《人脸识别技术应用安全管理办法》：人脸处理、替代方式与个人信息保护边界。
ClassMesh 希望改变的，不是签到按钮，而是签到依据：从“一个客户端说自己在场”，转向“多方证据在同一次课堂中相互吻合”。
A classroom attendance concept that requires no additional dedicated classroom hardware.
The teacher's existing phone provides a classroom anchor. Students' existing phones exchange two-way Bluetooth proximity evidence, while identity verification is bound to the same check-in session. The goal is to make “knowing how to call the API” insufficient for recording fraudulent attendance remotely at scale.
Project status: Concept / Design Discussion.
This repository shares a complete concept, not implemented software. There is currently no runnable app, SDK, demo, or validated performance or security result, and no installation or deployment guide. All workflows, capabilities, and interfaces described here are design proposals.
- No additional classroom devices: Use the phones teachers and students already own, without installing beacons, cameras, or dedicated attendance terminals in each room.
- Minimal classroom disruption: The intended student experience is “open check-in → verify identity → wait briefly,” with proximity witnessing handled by the system.
- Focus on scale: Address remote-only request forgery, replay, and fabricated device identities when the attacker has no controlled endpoint inside the classroom.
- Evidence from multiple sources: Bind the classroom challenge, device identity, identity verification, peer records, and teacher records together instead of trusting a single client.
- Explicit boundaries: Attacks requiring an on-site accomplice or relay device in each target classroom are not the primary focus. Excluding them does not mean they are impossible.
- Privacy and fairness: A technical failure is not automatically cheating. Face verification has alternatives, and temporary proximity relationships are not intended for continuous tracking.
The idea in one sentence:
The client requesting check-in should not also be able to manufacture every piece of evidence needed to approve it.
- Why this idea
- Goals and non-goals
- The core idea
- Conceptual architecture
- A check-in session
- Why focus on forged and replayed requests
- Threat model and limitations
- Everyday use and exceptions
- Privacy and fairness
- Directions to explore
- Open questions
- Frequently asked questions
- Joining the discussion
- References
QR codes, location checks, gesture patterns, and passcodes can all serve as attendance entry points. But in designs that rely only on copyable content or on claims made by the student's client, even an elaborate interface may ultimately reduce to a network request that can be reproduced.
For example:
“I know the attendance code.”
“The coordinates I submitted are near the classroom.”
“I scanned a particular Bluetooth device.”
None of those statements, on its own, means “this student is attending this class in this room right now.”
This is not a claim that every existing attendance product is easy to bypass. It is a design question:
If an attacker knows the APIs, parameters, and message formats but cannot control the classroom environment, what evidence could the server require that the attacker cannot produce alone?
The idea follows from a few observations:
- A classroom already contains many real phones.
- Phones can discover and communicate with nearby devices.
- Student phones can separately record their encounters during the same short interval.
- The teacher's phone can connect those encounters to a particular class.
- Face verification can add evidence about who is using the device.
Binding these observations to the same check-in session could change the trust model of attendance, rather than merely add another entry point.
| Goal | What it means |
|---|---|
| No additional dedicated classroom hardware | No requirement to install and maintain fixed attendance devices in every room |
| A short normal workflow | Students do not select witnesses, scan one another's QR codes, or manually pair with each device; teachers handle only a small number of exceptions |
| Resistance to remote-only attendance fraud at scale | Understanding the protocol, copying requests, or running a script should not be enough to fabricate attendance in bulk without on-site assistance |
“No additional hardware” does not mean software, services, compatibility, or privacy governance are free. It refers specifically to avoiding new dedicated devices in classrooms.
- Being impossible to bypass under every circumstance.
- Proving that a student occupies a particular seat, or continuously tracking location.
- Treating ordinary Bluetooth as a precise room boundary or a secure distance measurement.
- Primarily defending against attacks with an on-site relay in every target classroom.
- Solving teacher–student collusion through technology alone.
- Treating presence as evidence of attention, learning outcomes, or participation.
- Building a blockchain, token, mining mechanism, or public map of student social relationships.
Attendance decisions would draw on five related categories of evidence:
Person · Device · Class · Time · Setting
This is a conceptual framework, not an established mathematical security proof.
| Evidence | The question it addresses | Proposed approach |
|---|---|---|
| Person | Does the current user match the enrolled student? | Session-specific one-to-one face verification with liveness detection, or an equivalent alternative |
| Device | Does the request come from the account's registered primary device? | Device identity, protected keys, and device-state constraints |
| Class | Which course and check-in session does this evidence belong to? | Binding to the course and session |
| Time | Is this a fresh interaction rather than a historical record? | Unpredictable challenges, short validity periods, and protection against reuse |
| Setting | Is the device connected to proximity relationships anchored to the teacher's classroom? | A teacher-provided classroom anchor, two-way proximity interactions, and separately submitted peer records |
The important part is not simply obtaining five successful results. They must be bound together:
- Proximity evidence from a previous class should not be accepted in a new one.
- A face-verification result from device A should not be reusable on device B.
- A witness record for one person should not remain valid after its identity is changed.
- Uploading two client-side flags—“Bluetooth succeeded” and “face verification succeeded”—should not be enough.
- All supposedly “independent evidence” should not ultimately be authored by the same client.
Student devices discovering one another can, at most, indicate that a group of devices is gathered somewhere. That place could be the classroom or a dormitory.
The concept therefore retains a trusted classroom starting point: a phone authorized for the current course and used by the teacher at the actual class location.
It would generate a temporary classroom challenge, publish it over a proximity channel, and separately retain teacher-side interaction or observation records. Student evidence would need to connect to this classroom anchor, rather than merely form a self-contained peer network.
Each student phone would interact with a small number of randomly assigned peers. The concept does not require every phone to connect to every other phone.
“Witnessing” here is neither voting nor counting Bluetooth device names. It means that two registered devices separately provide records of this particular encounter that can be checked against one another.
flowchart TD
S["School server<br/>Course authorization and evidence assessment"]
T["Teacher's existing phone<br/>Anchor for this class session"]
A["Student phone A<br/>Identity verification and device identity"]
B["Student phone B<br/>Identity verification and device identity"]
C["Student phone C<br/>Identity verification and device identity"]
S -->|"Course authorization"| T
T <-->|"Proximity interaction"| A
T <-->|"Proximity interaction"| B
A <-->|"Random two-way witnessing"| B
B <-->|"Random two-way witnessing"| C
T -.->|"Teacher-side records"| S
A -.->|"Separate submission"| S
B -.->|"Separate submission"| S
C -.->|"Separate submission"| S
This diagram illustrates relationships, not required connection counts, a real deployment topology, or validated coverage. How direct observations and multi-hop witnessing should be combined remains a design question.
The server would not approve attendance merely because a student uploads a “nearby classmates” list. Instead, it would check:
- Whether an authorized classroom anchor exists for this session.
- Whether the account, primary device, and identity-verification result correspond.
- Whether the two sides of each peer interaction report matching records.
- Whether all evidence belongs to the same class and time window.
- Whether there is reuse, a one-sided claim, or a clear inconsistency.
The result would not mean “absolute proof that this person is sitting in the classroom.” It would mean “the submitted evidence satisfies the attendance rules defined by this concept.”
The following is an intended interaction, not a claim about achieved latency or success rates.
Students would register their identity and primary device and learn about nearby-device permissions, identity verification, and alternatives. Separate paths would cover replacement phones, students without phones, and cases where face verification is unsuitable. A one-time technical setup should not become a lasting barrier to attending class.
The teacher opens the current course and selects “Start check-in.”
The teacher's phone would then generate a fresh classroom challenge. Students could learn the course and check-in status over the network, but ordinary student APIs should not directly provide a complete, reusable package of on-site evidence.
A student opens the check-in page, receives the current classroom challenge, and establishes a session-specific proximity interaction with the teacher's phone or with peers already linked to the classroom anchor.
A peer network assembled remotely should not be accepted simply because it contains many participants or has a dense graph.
Identity verification would be bound to the current class, device, and short time window. It would not consist of taking a face image once and retaining a long-lived “face verified” status.
The standard workflow proposed here includes one-to-one face verification against the enrolled student identity, with liveness detection and convenient non-facial alternatives. System Face ID or fingerprint authentication can help authorize device operations, but it is not equivalent to “the school has verified that this is the enrolled student.” Apple LocalAuthentication
Students would not choose their friends as witnesses. The system would assign a small set of peer interactions for the current session. Both devices would exchange challenges and responses, then submit their records separately.
Random assignment is intended to reduce the ability to select a fixed group of accomplices. It does not make a random graph inherently secure, nor does repeatedly sitting near the same classmates imply cheating.
The intended student experience is:
Open check-in → verify identity → wait for proximity evidence → view the result.
The teacher's interface should focus on completed check-ins, cases needing additional evidence, and cases needing review—not require teachers to understand wireless graphs, keys, or protocol details.
Protocols can be observed and understood. This concept does not rely on the attacker being unaware of the parameters. It aims to make certain required evidence unavailable to a remote attacker acting alone.
| Required evidence | Source | Why changing request fields should not be enough |
|---|---|---|
| The current classroom challenge and teacher records | Teacher's phone | The student client should not be able to invent the claim that the teacher observed it |
| Evidence from the current device | Registered device | Knowing an account password should not be equivalent to possessing the device's protected key |
| Identity verification for this session | Trusted verification process | A client-supplied success value or a result reused from another session should not qualify |
| Two-way peer records | Separately generated and submitted by both endpoints | One party should not be able to invent the other party's response |
| Session and validity information | Bound across the evidence bundle | Historical records, changed fields, and repeated submissions should not remain valid |
Device and application integrity mechanisms offer relevant capabilities, but they are neither physical-location authentication nor an unforgeable identity card universally available on every phone. Android Play Integrity, Apple App Attest
If the final rule were merely “know the random value the teacher just broadcast,” the scheme would collapse back into a shareable attendance code.
The classroom challenge is therefore only the session-specific value that links the evidence. Knowing it alone should not grant attendance credit. Account–device binding, identity verification, matching proximity records, and evidence linking back to the teacher's anchor should still be required.
Data does not become uncopyable simply because it was transmitted over Bluetooth. Credibility comes from the sources and bindings of the evidence, not from moving a field to a different transport.
This README is meant to explain the idea publicly, not keep the protocol secret.
The intended property is that even someone who understands every message format should not be able to satisfy the attendance rules merely by constructing network requests without the trusted device, identity-verification result, and classroom-side evidence.
For now, that remains a design claim—not a formally proven or practically validated result.
- The school server, course authorization, and teacher identity are not controlled by the attacker.
- The teacher starts the session at the actual class location; this concept does not independently establish the teacher's location.
- Initial student identity enrollment and primary-device registration are trustworthy, and protected keys have not been stolen.
- The session's identity-verification result comes from a trusted process, not a client reporting its own success.
- An attacker may study the protocol, replay requests, and control multiple remote accounts or devices.
- Within the primary threat model, the target classroom contains neither an attacker-controlled forwarding endpoint nor an accomplice relaying on-site evidence in real time.
The last assumption is an explicit scope choice, not a security property automatically provided by Bluetooth.
| Scenario | Position within the concept |
|---|---|
| An off-site script directly calls the check-in API | Core goal: one client should not be able to generate all required evidence |
| Old requests are replayed, or account, course, or time fields are changed | Core goal: fresh sessions and evidence binding should invalidate them |
| Emulators or one device impersonate many students | Core goal: registered device identities and account binding should constrain bulk fabrication |
| Face-verification results are reused, or the client invents a success result | Core goal: bind verification to this session, person, and device rather than accept self-reported success |
| A group of students witness one another in a dormitory | Without classroom-side assistance, they should not be able to establish valid evidence tied to the teacher's anchor |
| Fixed groups, frequent device changes, or unusual account sharing | Apply basic constraints and explainable risk signals; association alone is not grounds for a cheating finding |
| Every target classroom contains a relay phone or an on-site accomplice | Accepted residual risk, not a primary defense objective |
| Specialized wireless relays, system-level vulnerabilities, or teacher collusion | Accepted residual risks; the concept does not claim to solve them |
The focus is a remote-only fraud service operating across many classrooms and concurrent classes. If an attack needs to maintain an on-site foothold in each classroom, it is no longer a centralized script that needs no local resources.
This does not mean relaying is necessarily expensive, or that one relay phone can affect only one account. It may affect multiple students in the same classroom. The choice here is simply not to complicate every legitimate student's workflow in order to cover that accepted risk.
Ordinary Bluetooth signals can pass through walls, and received signal strength varies with devices, obstructions, and the environment. “A broadcast was received” or “several witness edges exist” does not establish that a device occupies a particular seat or is inside specific walls.
Likewise, signatures authenticate message origin and integrity, not physical distance. BLE proximity interactions still require application-layer protection and an understanding of its limits. USENIX research on BLE application-layer security
This document therefore uses “classroom presence evidence,” not “absolute location proof,” and does not invent a hard signal-strength threshold.
The concept assumes one-to-one verification against the enrolled student identity with reliable liveness detection—not merely checking for a blink, a head turn, or a submitted selfie.
Even then, face verification is not an unassailable source of truth. NIST's presentation attack detection evaluations show that capabilities vary across algorithms and attack types. Its role here is to add identity evidence and raise the barrier to unattended fraud at scale. NIST FATE PAD
Students should not need to browse classmate lists, choose witnesses, or repeatedly pair devices just to check in. Teachers should not have to act as on-site system administrators.
Three types of result are envisioned:
| Status | Meaning | Appropriate next step |
|---|---|---|
| Evidence matches | The session's attendance rules are satisfied | Show completion |
| Insufficient evidence | Permissions, connectivity, device capabilities, or proximity records are incomplete | Retry automatically or offer alternative verification |
| Conflicting evidence | Duplicate, contradictory, or invalid records appear | Explain the reason and request human review |
A technical failure is not the same as student cheating. Even when cryptographic verification fails, the cause should first be assessed—an attack, a software defect, or corrupted data—rather than immediately triggering disciplinary action.
- Bluetooth is disabled or permission is denied: Explain the purpose and allow the student to grant permission or choose an alternative.
- Small classes: Do not block attendance because a fixed peer-count threshold cannot be met; give more weight to direct teacher confirmation.
- Late arrivals: Use a new check-in window rather than reuse evidence from a closed class session.
- Network interruptions: One option is to retain on-site records already generated. Fully offline identity verification and the validity of retained records remain open questions, not solved capabilities.
- A dead or damaged phone, or no smartphone: Offer on-site teacher confirmation. Device ownership should not determine eligibility to attend class.
- Phone replacement or repair: Allow the old registration to be revoked and a new one confirmed, so old and new devices do not simultaneously represent the same identity.
- Face verification is unsuitable or declined: Provide an equally reasonable and convenient non-facial option, without deliberately adding humiliating actions or penalties.
- Substitute teachers or room changes: An authorized teacher could establish a new classroom anchor without moving dedicated equipment.
Attendance should not quietly become a student movement database or a tool for analyzing social relationships.
- Limit proximity scanning to clearly defined, short check-in windows.
- Explain what is scanned and collected; “seamless” is not a substitute for informed participation.
- Do not default to continuous background location tracking, audio recording, or video capture.
- Do not expand permissions indefinitely in the name of security.
Phones would use session-specific identifiers instead of deliberately broadcasting student IDs, names, phone numbers, or persistent device identifiers, reducing linkage across classes.
However, temporary identifiers only reduce correlation risks. They do not eliminate inferences based on wireless characteristics, timing, location, or observation. The school server still needs to associate evidence with a student, so this should not be advertised as “fully anonymous attendance.”
Peers should also not see other students' faces, student IDs, or complete attendance records.
| Data | Design principle |
|---|---|
| Official attendance results and correction records | Retain for clearly stated purposes and under school rules, with access and appeal mechanisms |
| Raw proximity records and temporary encounter relationships for this session | Retain only for a necessary, short appeal window, then delete or minimize according to explicit rules |
| Face samples and data handled by verification services | Distinguish newly collected session data, existing school reference images, and provider processing; minimize additional retention |
“The identifier expired” does not mean the server deleted the associated records. Deletion, logging, and third-party retention each require a separate explanation. A summary or digest should not automatically be described as “unlinkable.”
Face verification should follow necessity and minimal-impact principles and offer reasonable, convenient alternatives. Withdrawing authorization for face-data processing should be explained separately from the rules for correcting, deleting, or necessarily retaining official attendance records. China's Measures for the Security Management of Facial Recognition Technology Applications
These are conceptual design principles, not a compliance determination for a particular school.
These are optional ideas, not an implemented feature list or a development roadmap.
For courses that genuinely need an additional indication of mid-class presence, a brief proximity refresh could occur at a time that is not fixed in advance.
It need not repeat full face verification or be enabled in every class. The question is whether the interruption is worthwhile—not how to turn attendance into continuous surveillance.
A lightweight presence check could accompany a classroom question, anonymous poll, or immediate feedback, making the interaction educationally useful. Correct answers should not be a condition of attendance, and learning assessment should remain separate from presence assessment.
Let students see which evidence categories were used, whether face data was processed, when records are scheduled for deletion, who made a manual correction, and how to appeal.
It should show only the student's own necessary records, not expose classmates' witness relationships.
Large lectures might draw on a wider peer network, while small classes could rely more on direct teacher confirmation. Talks, laboratory training, and seminars need not follow identical rules.
The more flexible the policy, the more important it is to prevent weaker alternative paths from becoming an entry point for bulk fraud. That is a product trade-off worth discussing.
Being present does not mean paying attention. Missing device evidence does not mean a student has not learned.
ClassMesh could remain deliberately limited to attendance evidence, without interpreting wireless behavior as concentration, personality, or attitude toward learning.
A similar structure could be discussed for campus talks, workshops, student clubs, or training attendance.
It should not be directly presented as a replacement for examination identity checks, emergency personnel accounting, or other high-stakes procedures.
These questions are intended to improve the concept, not assign development tasks:
- Is the objective right? For ordinary classes, is reducing remote-only attendance fraud at scale more valuable than pursuing absolute certainty in every circumstance?
- How much responsibility should peer witnessing carry? With a teacher-provided anchor already present, should peers mainly improve coverage and provide separate evidence, or carry more weight in assessing presence?
- Where should the interaction burden fall? Is identity verification at every check-in, or additional verification only for exceptions, more acceptable to teachers and students?
- What makes an alternative equivalent? How can paths for students without phones, replacement devices, unsuitable face verification, or denied permissions remain both fair and resistant to bulk abuse?
- What should participants see? Students should know what witnessing they participate in, but do they need to know exactly whom their devices witnessed?
- When should verification not be expanded? Which classes should explicitly avoid mid-class refreshes, ambient-audio features, or additional device signals?
- How much retention is enough? How can appeals remain evidence-based without accumulating student location and relationship histories?
- How should resistance to scaling be described? Should account counts, classroom counts, and concurrent sessions be considered separately rather than summarized as “absolute security”?
No. There is currently only a concept document: no application, API service, selected provider, or measured results. This README describes the product logic the idea is intended to support.
No. If the client still submits only two success flags, the trust structure has not changed. The important part is evidence from separate sources, bound to the current identity, device, class, and time.
Peer interactions can indicate that certain devices are gathered together, but not that they are in this teacher's class. The teacher's phone provides an authorized classroom starting point. This explicitly relies on the assumption that the teacher is honestly present.
No. The design goal is to avoid additional classroom hardware. Phone compatibility, software, services, identity verification, and privacy governance still have costs.
A real class does not need every student device to witness everyone else. Sparse, random, short-lived interactions better match the low-disruption goal. However, sufficient evidence and failure handling still need sensible definitions; theoretical connectivity is not a substitute for real-world reliability.
There is no mining, token, or decentralized ledger here. The school remains responsible for course and identity authorization. Multi-party witnessing is a trust-design idea, not blockchain consensus.
If identity verification genuinely occurs on the current device for this session, and the verification process is trustworthy, it provides important evidence against that behavior. But unlocking a phone is not equivalent to verifying the enrolled student, and face verification itself does not prove physical location.
Relaying that requires on-site assistance in each target classroom is an explicitly accepted boundary of this concept. It is not presented as solved, nor is it used to justify more friction for every student. The primary target remains remote-only bulk requests without a classroom foothold.
It should not. Missing evidence calls for alternatives or additional confirmation; explicit conflicts still require explanation and review. Attendance decisions and disciplinary action should not depend solely on an opaque score.
No. Proximity communication, permissions, and background behavior vary across mobile platforms. Existing platform capabilities are useful references, not evidence that this concept already supports all devices or large classes. Nearby Connections, Android Bluetooth permissions, Apple Core Bluetooth background behavior
Ideas, issues, and documentation suggestions are welcome, particularly those that:
- Identify gaps in the reasoning or trust assumptions that do not hold.
- Suggest a simpler approach within the three main constraints.
- Discuss face verification, alternatives, privacy, and classroom experience.
- Add official documentation, original research, or realistic use cases.
- Help explain the mechanisms more clearly.
When raising a question, it helps to state the scenario, the capabilities or conditions of the participants or attacker, what is missing from the current description, and what change you propose.
Please do not submit real student face images, student IDs, attendance records, device credentials, or other sensitive personal information. This is a discussion of general defensive design, not a tool for bypassing a particular school or existing system.
These sources help explain individual capabilities and limitations. They do not indicate that the named organizations have validated, approved, or endorsed the ClassMesh concept as a whole.
- Nearby Connections: Reference capabilities for communication between nearby devices.
- Android Bluetooth permissions: Nearby-device permissions and user-interaction requirements.
- Apple Core Bluetooth background behavior: Background discovery and advertising limitations.
- Android Play Integrity: Application and device integrity signals.
- Apple App Attest: Application-instance and request-authenticity mechanisms.
- Apple LocalAuthentication: The distinction between local biometric authentication and identifying an enrolled student.
- NIST FATE PAD: Face presentation attack detection evaluation.
- USENIX research on BLE application-layer security: Why application-layer protection is still needed beyond the Bluetooth link.
- China's Measures for the Security Management of Facial Recognition Technology Applications: Face-data processing, alternative verification, and personal information protection.
ClassMesh aims to change the basis of attendance—not the check-in button: from “one client says it is present” to “evidence from multiple sources agrees within the same class session.”