IT之家 5 月 27 日消息，科技媒体 9to5Mac 今天（5 月 27 日）发布博文，报道称苹果正在开发一项新的 iPhone 防盗功能：系统判断手机被人从手中抢走后，会自动锁定设备。 根据曝光的代码细节，这项功能在通过一系列系统判断 iPhone 被抢走后， 自动锁定设备，并进一步限制部分敏感操作。 这项功能瞄准的是一个老问题：即便苹果公司已提供“查找”、“激活锁”（Activation Lock）和“失窃设备保护”，一旦盗贼抢走的是一台仍处于解锁状态的 iPhone，很多保护措施的效果都会打折。 代码显示苹果会结合 iPhone 的加速度计、和已配对 Apple Watch 之间的距离、检查 iPhone 是否连接熟悉的 Wi-Fi 网络、以及是否处于家或公司等常用地点等多种信号，综合判断 iPhone 是否处于被“抢夺”状态。 该功能试图把防护时点从“被偷之后”提前到“被抢当下”，但目前该功能仍处于开发阶段，目前尚不清楚何时能落地商用。
IT之家 5 月 13 日消息，科技媒体 Android Authority 今天（5 月 13 日）发布博文，报道称在 2026 年 Android Show I/O Edition 活动中， 谷歌宣布增强安卓 17 系统防盗能力，核心升级“Find Hub”的“标记为丢失”功能。 “标记为丢失”功能新增 Biometric Authentication（生物识别认证），目标是即便窃贼已经拿到设备 PIN，也难以关闭追踪或重新控制手机。 IT之家援引博文介绍，安卓设备过去主要依赖密码或 PIN 锁定，而现在用户触发丢失模式后，想要重新获得访问权限，必须通过指纹或面部等生物识别方式完成验证。这样一来，仅掌握 PIN 的窃贼将被拦在系统之外。 在手机被标记为丢失后，系统会自动隐藏快捷设置，减少窃贼从下拉菜单快速关闭关键功能的机会。同时，设备还会禁用新的 Wi-Fi 和蓝牙连接，防止他人借助无线方式切断定位、配对配件或转移控制路径。 谷歌还默认开启 Remote Lock（远程锁定）和 Theft Detection Lock（盗窃检测锁）两项既有防盗能力。这项策略建立在巴西试点成功的基础上。今后所有新的安卓 17 设备，以及刚恢复出厂设置或刚升级到安卓 17 的设备，都会默认拥有这两层保护。 除功能层面的拦截外，Android 17 还压缩了 PIN 或密码的可尝试次数，并拉长连续输错后的等待时间，进一步限制暴力猜测。
最近做了一个 PBKDF2 加密文件的小工具，加密成二进制文件，采用许可证形式解密。可设置有效期，防盗溯源水印。 等我优化好些过几天发布开源一下。。大家期待一下哈哈哈哈。晚安，佬友们～ 1 个帖子 - 1 位参与者 阅读完整话题
这两天我用 Python 给下载站开发了一个防盗链小网关，虽然项目不算重量级，但也涉及FastAPI之类的一大堆依赖。接下来一段时间内，项目的代码会快速迭代，依赖也可能不断更新，如果为了容器化，用 Dockerfile 执行完整的镜像构建流程，绝对会严重拖慢交付速度。即使正确执行了分层构建也没差，只要一动requirement列表，那么 pip install 这层缓存全部完蛋——应该不会有神经病把每个依赖都分层构建和缓存吧，不会吧？ 那么有什么解决方法呢？ 既然项目代码和依赖都会不断变化，那么最简单的部署方法其实是直接使用纯净的Python容器镜像，但是要注意将Python依赖也持久化到本地，不然每次运行容器都要重新从pypi拉取一次依赖，同样效率低下。这里Python和uv的容器分别有各自的解决方案。 Python容器通过 PYTHONPATH 定义额外的第三方库搜索目录（它会被添加到 sys.path ，跟在当前脚本所在目录之后），因此在使用Python镜像时，我们要做的就包括： 指定pip将依赖安装到一个被持久化/挂载到卷的目录 指定Python在这个目录寻找第三方库 如此就得到了以下Docker compose模板（Docker CLI自行修改，都是一一对应的） services: myapp: image: python:3.11.9 working_dir: /app restart: always volumes: - ./app:/app - ./packages:/packages environment: - PYTHONPATH=/packages/lib/python3.11/site-packages command: bash -c "pip install --target=/packages/lib/python3.11/site-packages -r requirements.txt --exists-action=s && python main.py" 由于pip不会自动清理未列出的库，因此此前按照的所有 package 都会残留下来，不仅臃肿，而且指不定那天出现依赖冲突，因此需要不定期删档重开，不甚雅观。 如果使用的是uv，并且项目已经跟踪了 pyproject.toml ，那就更简单了， uv sync 会在项目目录下创建 .venv 目录隔离环境，即使目录丢失，在缓存具备的情况下也能几乎在瞬间从缓存中同步依赖，因此我们直接增加一条，覆写并持久化 UV_CACHE_DIR 即可： services: myapp: image: astral/uv:python3.12-bookworm-slim restart: always volumes: - ./app:/app - ./.cache/uv:/root/.cache/uv environment: - UV_CACHE_DIR=/root/.cache/uv working_dir: /app command: ["bash", "-c", "uv sync && uv run main.py"] 说实话，要是项目的Python版本固定、部署设备的CPU指令集固定，这玩意儿比每次都费一大堆时间build镜像来得靠谱多了， git pull 完直接删除容器重建，基本不会有可感知的延迟，同时也不需要下载一堆乱七八糟的层（TMD服务器空间不够清理悬空镜像和层简直就是地狱），对于快速迭代的开发调试极为友好。 当然，生产环境里还是乖乖build吧。 1 个帖子 - 1 位参与者 阅读完整话题