黑客声称窃取海量腾讯数据，腾讯回应 近日，一则关于“黑客声称窃取腾讯海量用户信息”的消息引起了很多网友关注。8月14日，腾讯方面回应称该消息不实。此前，名为“Fenice”的黑客发帖曝料称，其窃取了腾讯的海量数据库，手握14亿用户账号信息。据报道，该数据库采用JSON格式，包括电子邮件地址、手机号码和QQ ID等敏感字段。本次泄露的数据可能不是近期发生的，时间戳和存储路径表明，这些数据是在2023年5月9日前处理的。8月14日，腾讯集团回复大河财立方称，上述信息并不属实，实为黑产利用历史资料拼凑、注水而成，对公众存在极大误导。腾讯公关总监@卡獭秦 也发文称该消息不属实。其表示：“其实过去两年，类似的虚假信息被海外黑客多次反复炒作。谣言越来越离谱，数据口径也不断膨胀，出现过7亿、12亿、14亿等多个版本，还被恶意关联到国内多个互联网产品，除了鹅厂也有其他多个友商躺枪，莫信莫慌哈。”随后，另一位腾讯公关总监@腾讯张军 转发该微博称：“隔段时间就会出一个新版本。”我想说，这个文件太大无法解压，但是看了别人的分享，是有QQ号码、手机号码、QQ邮箱。

腾讯宣布：腾讯文件助手将于10月停运 注意：腾讯文件助手（ https://wecloud.qq.com ），并非微信里的文件传输助手，这是两个不一样的产品，前者官网写着“QQ同步助手出品”，看到这个就明白是什么下场。8月5日，腾讯文件助手突然发布公告，文件助手小程序及web页面将在2024年10月11日停止运营。据公告，因业务调整2024年10月11日起文件助手小程序及web页面将停止运营即日起，文件助手备份文件功能将关闭。在2024年10月11日前，用户可以正常浏览和下载备份过的文件，但无法再备份新的文件，腾讯文档提醒，请尽快保存备份过的文件文档。公告提到，对于受影响的会员用户，已开放退款通道，用户可以在同步助手app--文件--共享空间--点击公告--退款通道填写需退款的账号信息，官方将在核实提交的信息后，尽快办理退款。据腾讯文件助手官方介绍，该功能可防止文件过期失效，提高多人文件收集效率。支持聊天文件备份、群作业收集共享、PDF格式在线转换等。据悉，2023年以来，腾讯旗下已有多个产品宣布停运。2023年9月6日，腾讯旗下音频平台企鹅FM正式停止运营；2023年12月20日，腾应用“腾讯待办”全面停止运营并下架；2023年12月26日11时，腾讯NOW直播停止运营；腾讯课堂将于2024年8月1日停止运营，届时将全面停止所有平台的服务。

腾讯课堂于8月1日关停 腾讯课堂，是腾讯推出的首个专业在线教育平台。下设职业培训、公务员考试、托福雅思、考证考级、英语口语、中小学教育等众多在线学习精品课程，主打的就是一个线上、线下质量一致，让广大用户利用闲暇时间，上到高质量的课。不可否认，腾讯课堂在疫情期间确实为许多教育机构提供了便利，腾讯课堂也因此获得了近3亿用户的拥戴。巅峰时期，腾讯课堂每周有超过百万的用户在线学习，在架课程超10万门。但随着线下教育的复苏，线上教育流量骤减，现如今只能靠语言类、相关考试等板块苦苦支撑。 据官方消息，腾讯课堂将于2024年8月1日起停止所有在线课程的访问功能，并在同年10月1日正式停止运营。虽然用户仍可观看历史免费课程内容，但全新的课程内容已经无法访问。在安卓手机应用商店和苹果App Store中均无法搜索到“腾讯课堂”应用程序。关于这个消息，“腾讯课堂”官方公众号上最后一次更新是2023年2月28日，而此前一年保持了较为频繁的更新频率。早在2023年8月24日，腾讯课堂也以同样的方式发布公告，称由于功能与服务调整，其旗下的教培通服务将于2023年9月20日起正式停止提供服务，包括发课、排课、创建直播任务及交易功能将全面暂停。腾讯内部人士在接受采访时则表示：“目前只是教培通的功能与服务调整，（腾讯课堂）后续可能还有进一步的调整计划。”据了解，腾讯课堂是腾讯推出的综合性在线终身学习平台，聚合了大量教育机构和名师，并设置了职业培训、公务员考试、托福雅思、考证考级、英语口语等众多在线学习课程，打造老师在线上课教学、学生及时互动学习的课堂。公开资料显示，2014年4月，腾讯课堂在线教育平台上线；2015年，腾讯课堂App发布，彼时，据介绍，作为腾讯旗下的线学习平台，腾讯课堂上线仅一年内就与5000多家教育机构达成合作，而上线App版本是腾讯课堂对用户需求的进一步满足和探索。根据2019年披露的数据，2018年全平台机构营收同比增长70%，TOP100入驻机构年营收同比增长超2倍，营收过千万元的机构伙伴超过20家。

一个依赖库更新引发的血案：QQ 号被冻结技术分析 昨天（2020年7月15日）中午十一点左右，大量网友反应自己的 QQ 号被冻结，这个问题一度冲上知乎和微博热搜第一，很多人表示自己的生活受到了影响。具体的事态发展各位吃瓜群众可以自行了解，这里打算从技术角度分析一下这次故障的原因。先给结论：这应该是一次第三方依赖库升级引发的。这个第三方依赖库是恰好是我本人在 github 上开源的，一个名为 `epic` 的项目（地址在这里：https://github.com/tiann/epic）；`epic` 是一个在虚拟机层面、以 Java Method 为粒度的 运行时 AOP Hook 框架。它可以拦截本进程内部几乎任意的 Java 方法调用，可用于实现 AOP 编程、运行时插桩、性能分析、安全审计等。我开发这个库的初衷是做性能分析，更具体点，是为了监控 App 内部线程的调度情况。当时我正在支付宝做 Android 端 App 的性能优化，因为研发团队很大，内部又没有一个完全统一的基础设施，代码里面很多四处散落的线程（池）、广播，Service等；可能一个线程或者广播并不消耗什么性能，但是量变产生质变，支付宝启动之后峰值会有三百多个子线程在运行，同时有一百多个广播在主线程跑，即使每个只运行几毫秒加起来也有若干秒了。为了知道是哪里创建了这些资源，我非常需要一个运行时插桩工具来监控 App 的运行情况；于是我就花了点时间撸了一个库并且开源在 github 上。说到这里也许有童鞋会问：这 `epic`听起来不是挺好吗，为啥会导致冻结？技术是一把双刃剑。由于 `epic` 可以拦截本进程内几乎任意的方法调用，一旦以合适的方式加以利用，就可以创建上帝视角，控制任意 App 的运行。这个功能与 Android 上大名鼎鼎的 Xposed 框架本质上是一样的。Xposed 框架可以在不修改应用安装包的情况下修改程序的运行（修改系统），基于它可以制作出许多功能强大的模块，且在功能不冲突的情况下同时运作。