On this page
Update — 2019-01-29
First thing this morning, the moment I plugged into the office network the download rate shot up to 600 KB/s. Sure enough, it was that same com.apple.Safari.SafeBrowsing.Service process again. Awkward — turns out “just don’t use Safari” doesn’t stop it.
I changed the rule for it in Surge from Direct to Reject.
Tracking the issue
Around late December 2018, I happened to log in to AgentNEO to check the bandwidth balance I’d just topped up. To my surprise, the SS traffic I’d bought only days earlier had burned through nearly 95 GB in just four days — about 75 GB of it on New Year’s Day alone. For context, my monthly usage typically sits below 10 GB. I’m at the office most of the day and I don’t watch much YouTube in my spare time either.
When I first saw the numbers I genuinely suspected their accounting was off.
Over the next few days I kept a close eye on it. One day I noticed Surge’s menu-bar throughput meter was constantly showing 500–600 KB/s of incoming traffic, even though I knew I wasn’t downloading anything.
Opening the Surge Dashboard showed this:
The process responsible for the steady stream of downloads was com.apple.Safari.SafeBrowsing.Service, and the destination was safebrowsing.googleapis.com.
The name suggests this is Safari’s safe-browsing service. Snitch’s database describes it as:
Safari has built-in support for Google’s Safe Browsing service to identify fraudulent and unsafe websites. Right before Safari navigates to a certain website, the website gets checked for possible security concerns using Google’s Safe Browsing online database. Accessing the online database requires connections to Google servers.
In other words: it’s Safari’s mechanism for checking, just before navigation, whether a page is fraudulent or unsafe. You can find the toggle for fraudulent-site detection under Safari’s Security preferences. On my machine it reads:
Safari uses Tencent Safe Browsing and Google Safe Browsing to identify fraudulent websites.
So Safari uses both Tencent’s and Google’s safe-browsing services to flag fraudulent sites — the Tencent piece is presumably a localization for China.
Watching the outbound hosts for this process confirms the same thing — there are two destinations:
- safebrowsing.googleapis.com
- safebrowsing.urlsec.qq.com
There’s an equivalent process on iOS doing the same job — packet captures sometimes pick up these two requests on China-region iPhones too:
In my case, it was Google’s fraudulent-site database that was misbehaving.
I tried disabling Surge as the system proxy. Activity Monitor still showed the process downloading — just now bound directly to the process instead of going through Surge (Surge had been absorbing the traffic, which is why it had been counted against Surge before). Either way, downloads to that host kept going.
By the way — Little Snitch Network Monitor is software I only bought because of this traffic-loss issue.
Before I disabled Surge as the proxy, this one process had burned through about 12.4 GB in roughly seven hours.
I couldn’t find much online discussion of the safebrowsing process. The Chinese forum V2EX has one thread where someone hit the same problem.
I still don’t know whether it’s an official bug or something on my machine triggering it. For now I’ve parked Safari and switched to Chrome; I’ll check back with Snitch after a while.
To be safe, I also added a custom rule in Surge:
NAME,com.apple.Safari.SafeBrowsing.Service,DIRECT
All traffic from that process now bypasses the proxy. I’ll update the blog as I learn more.