照片元数据:分类广告网站到底泄露了广告主住在哪里的信息

广告主发布一条新信息时,做法通常很直接:打开手机相机,在光线好的地方拍几张照片,上传到账号,然后发布。整个过程完全不像是在做什么安全方面的决定,更像是让页面尽快上线的最快方式。在大多数网站上,这个过程确实就是这么快:五分钟前拍的照片,和陌生人在页面上看到的照片之间,几乎没有任何环节做过处理。

但陌生人能看到的信息,并不只是画面里出现的内容。绝大多数手机相机在获得定位权限的情况下(大多数时候确实如此),会把拍摄地点的精确经纬度写入照片文件内部一个叫作EXIF元数据的数据块里。这些坐标会随文件一路带到上传、存储、发布的每一个环节,除非链路中有某个步骤专门把它们删除。一张在广告主自己卧室里拍的照片,原本只是为了展示卧室,却在默认情况下把这个卧室的地址也一并带了出去。

这不是安全研究人员发现的什么理论上的漏洞,而是每家手机厂商为方便用户按拍摄地点整理旅行照片而做出的同一个设计决定,毫无例外地套用到了一张完全不同用途的照片上。相机不知道,也没办法知道,这张照片接下来会被发到一个拍摄者绝不希望自己家庭住址出现的地方。

手机在每张照片里悄悄写入了什么

这里有一个值得弄清楚的技术细节,因为它决定了修复方案到底该怎么做:EXIF数据本身就藏在图片文件内部,在一个肉眼看不到、大多数看图软件也不会主动显示的区域里。它不是标题、不是文件名,也不是广告主手动输入的任何内容,而是快门按下的瞬间由操作系统自动写入的,重命名、移动位置,甚至当作邮件附件发出去,它都会原样保留。真正能可靠去掉它的做法,是对图片重新编码:把像素数据拆开,重新写成一个新文件,这个过程会去掉旧的元数据,除非工具被明确要求保留它。

几乎每个人都遇到过这样一种情况,却不知道背后的原因:给一张照片截图之后,截图本身是没有位置信息的。因为截图是屏幕显示内容的一张全新图片,并不会带上原文件里那些隐藏数据。这也是为什么一个有心的广告主事后单纯关掉定位服务,并不能真正保护自己:只要照片是在定位开着的时候拍的,坐标早就已经写进去了,关掉设置只会影响下一张照片,对相册里已经拍好、等着上传的那些照片毫无作用。

这些都不是什么新鲜或冷僻的问题。科罗拉多大学博尔德分校2012年的一项研究调查了九十个交友网站,发现其中二十一个(大多数属于同一家公司)在发布用户照片时,并没有清除照片里嵌入的位置数据。这不是某一个不良运营商的个别问题,而是整整十多年前,大约四分之一的整个行业,都在通过一个用户从未要求过、也根本不知道存在的功能,悄悄把用户的家庭住址泄露出去。

为什么这个问题在这里性质完全不同

在一个普通分类广告网站上,这种泄露只是件让人尴尬的事。但在一个网站上,照片里的人是独立执业者,她的收入要靠别人能联系到她,而她的安全却要靠别人找不到她,同样的泄露就完全是另一个级别的问题了。这个地址不是卖旧沙发的人身上无关紧要的一点信息,而是一条信息发布时特意设计成绝不能透露的那一项,却悄悄藏在广告主确实愿意展示的那张照片底下。

单次泄露事件到底能牵扯多大规模,在2025年7月有了具体的例子:交友安全应用Tea披露,黑客从一个暴露的数据库中获取了大约七万两千张图片,其中约一万三千张是用于账号验证的自拍和身份证件照片,约五万九千张则来自帖子、评论和私信。该公司表示没有邮箱或电话号码被泄露,受影响的仅限于2024年2月之前创建的账号。没有人声称攻击者是专门冲着这批照片里嵌入的位置数据而来,本文也不打算这么说。

Tea事件真正说明的问题范围更窄,但也更实用:一旦平台存储并对外提供的是应用或浏览器最初上传的那份原始文件,不做任何处理,那么这份文件里恰好带着的任何内容,都会随着文件一起流向它后来去到的每一个地方,不管有没有发生数据泄露都是如此。分类广告信息根本不需要黑客介入才会出这种问题:只要一张照片在元数据没被清除的情况下就上线了,平台本身就是在主动、公开地把这份文件交到公众手里。

一个陈旧、乏味、早就有解法的问题

值得安心的一点是,这在技术上根本不算难题,而且早就不是难题了。Facebook和Instagram对外提供的照片副本会去掉位置元数据,而且已经这样做了很多年,原因很简单:一个每天有数亿次上传量的平台,根本没办法一个用户一个用户地去解释这件事。这件事只需要在照片发布前必经的代码流程里统一处理一次,任何人上传一张生日照片时都完全不需要考虑这个问题。

问题在规模较小、更细分的平台上则很容易出现,原因也不难预料:小团队里从来没有人被专门指派去负责这件事,用户也不会去提交工单,要求一个他们根本不知道自己缺了的功能。2024年一篇研究基于位置的交友应用的学术论文发现,被调查的服务中有一个,MeetMe,发布的照片仍原样保留着EXIF元数据,而同一研究里其他所有应用都已经妥善清除掉了。已经解决这个问题的平台和一直没顾上处理的平台之间的差距,跟内容有多敏感没什么关系,只跟研发这边有没有人在待办清单上勾选过这一项有关。

这个差距不仅是实务问题,在法律上也同样重要。在多个司法辖区的隐私法律下,这类精确位置数据被单独列为受保护的数据类别,加州的隐私法规更是专门把精确地理位置,即能把一个人定位到大约1850英尺范围内的数据,列为敏感个人信息,适用专门的规则。分类广告运营商就算只是在一张没人仔细看过的照片里,无意中发布了这类数据,也不会因为泄露是无意的就自动豁免于这些规则。

为什么广告主自己解决不了这个问题

最直接的应对办法,让广告主自己去关掉地理标记,听起来合情合理,但实际上根本行不通。大多数人从来没打开过控制这项功能的设置,不知道它存在,也没有理由主动去找它,直到出了问题才会想起来。少数知道的人,一旦换了新手机,几乎每次都会忘掉,因为这项设置会随设备重置。一个需要每一位广告主、在每一台设备上、永远不出差错地记住的习惯,根本不是一项安全措施,只是一种愿望。

这是同一个盲点:一个平台只要把技术性防护措施的责任,交给最没有能力持续落实它的那个人,就会出现这种问题。到头来只有运营方处在能够保证每一份文件、每一次都真正落实这项防护措施的位置,这和从来没有人特意决定过一份提交的身份证件该在服务器上留存多久,是同一种情况,只不过这里从未被真正做出的决定是:一张已发布的照片,是否还应该能指向一扇具体的家门。

上传流程到底需要做到什么

解决方案应该完全放在服务器端,放进照片发布前本来就要经过的处理代码里,而不是寄望于广告主记住某个设置。多数上传流程本来就会对图片重新编码,以便调整尺寸、生成网站做缩略图和预览需要的小图版本。这个过程会不会顺带清除EXIF数据,取决于用的是哪个工具:常用的Sharp库在这个过程中默认会清除,而同样常用的ImageMagick,如果没有明确传入要求清除元数据的参数,就会把它保留下来。这两个工具开箱即用的表现并不一样,这也正是为什么不能光看到有一个调整尺寸的步骤,就想当然地以为元数据已经被清掉了。

要知道自己的上传流程到底是哪种行为,唯一的办法是直接测试:用开着定位的手机拍一张照片,走真实广告主会用的那条上传路径上传上去,再把网站实际对外提供的那份文件下载下来,用任意一款免费的EXIF查看工具检查它的元数据。如果坐标还在,那说明调整尺寸这一步并没有起到原本以为它会起到的作用,不管背后用的是哪个库。

有两种走捷径的做法,失败的方式和原因是一样的。用浏览器端代码在前端清除元数据,看起来管用,直到有上传是通过手机应用、批量导入工具,或者直接调用同一个上传接口进来的,这些情况根本不会跑那段浏览器代码。而指望第三方上传组件已经处理好这件事,只是一种猜测,不是核实,除非真的有人拿上一段说的测试方法去实际验证过、看过结果。

以上这些都不需要额外请律师或安全顾问来解决。真正需要的,是这周找人做一次测试:通过真实的信息发布流程上传一张带定位信息的照片,把网站对外提供的那个版本下载下来,打开它的元数据看一看。如果坐标是干净的,说明流程已经在做该做的事,不用再改什么。如果不是,那这就是这份清单里唯一一件值得在下一条信息发布之前马上修好的事,因为不这么做的后果,就是每次广告主发一张照片,都在把一个家庭住址发布出去,还要把这叫作一个没人要求过的功能。