Mtgsig

〇、摘要 这篇文章起初只准备回答一个问题：社区分析里的 mtgsig2.4，是不是美团的设备指纹？ 🧑‍🔬 笔者把 2024 年看雪帖子、2019 年美团 Web 人机识别文章、2020 年 Zeus 规则引擎文章和 2026 年隐私政策排在一起后，发现这个问题问得太扁平了。四份材料跨越七年，面向不同终端，也在回答不同的工程问题。mtgsig 所在的请求保护、俗称 DFP 的设备连续性判断，以及围绕账号、位置、订单和履约展开的服务端风控，可能互相传递信号，却没有证据表明它们是一套算法的三个名字。 笔者不复现签名，也没有当前 APK、抓包或线上实验。真正要做的是把四份材料拆回原来的时间和职责，看看每一层的结论能走到哪里，又在哪里必须停下。 Research Evidence Methodology Item Detail 文章类型 Type B：官方资料与历史社区样本复核 时间跨度 2019-03 至 2026-06；不同年份材料不视为同一在线实现 证据标记 A：官方公开；B：跨材料架构判断；C：历史社区观察 一手实验 0；没有 APK Hash、运行环境、抓包或服务端原因码 安全边界 不公开生产签名配方、偏移、密钥、调用复刻或阈值试探 Sources & Evidence Grading 来源 等级 使用方式 美团 Web 人机识别文章，2019 A（历史） 观察公开流程如何区分入口校验与业务处理 美团 Zeus 规则引擎文章，2020 A（历史） 理解场景、因子、累计事件、决策和回放治理 看雪 mtgsig2.4 分析，2024 C 只确认某历史请求保护对象曾被社区分析 美团基本功能隐私政策，2026 A 确认安全场景涉及的设备、网络、应用等类别与用途 Android 标识符最佳实践 A 校准标识符作用域、可重置性和隐私边界 Scope Limitations mtgsig2.4 帖子没有提供足以独立复核的完整 App 版本、渠道、ABI、APK Hash 和设备环境。 2019 年 Web 流程与 2020 年 Zeus 是历史公开实践，不能直接映射到 2026 年 Android 客户端。 政策确认数据类别和用途，不提供当前 DFP 格式、字段组合、模型权重或采集频率。 文中的三层模型是职责划分，不声称采用美团内部命名。 一、路线总览：先把三层分开 笔者原来沿着 mtgsig2.4 继续追函数。样本身份核不实后，这条路越走越像在给旧帖子续写。于是研究问题换了一个方向：不再猜“怎么算”，先检查每层证据究竟有资格证明什么。 ...