I opened the browser console for other work, and saw that the Snowflake addon was looping with the errors "The resource at “https://snowflake-broker.bamsoftware.com/proxy” was blocked by Safe Browsing." and "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://snowflake-broker.bamsoftware.com/proxy. (Reason: CORS request did not succeed)."
I worked around the problem by going to that URL in a new tab and clicking the "do it anyway" option when the warning appeared, and now the addon is looping normally with the "at client capacity" message. But bypassing/disabling Safe Browsing is obviously a non-starter for general users, so someone needs to determine why the agent URL was blacklisted by Google and get it cleared, or the Firefox addon will be effectively dead.
Addon version 0.0.5.
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
More info: the workaround doesn't persist, after restarting Firefox it goes back to being blacklisted again. While blacklisted, it logs the two errors above and also the line "Snowflake: Broker ERROR: Unexpected 0 - ". That last line is also looped if I use the in-page version of the proxy from https://snowflake.torproject.org/snowflake.
I wonder if it's related to the zip bomb article I posted recently. That was on www.bamsoftware.com, not snowflake-broker.bamsoftware.com, but perhaps it carries across subdomains. I noticed about 2019-07-20 that Twitter started calling it an "unsafe link". There's some kind of lookup service for Safe Browsing here, but it looks like it needs a Google account login.
If it's the case that *.bamsoftware.com is blocked by Safe Browsing, we'll need a new top-level domain for the broker (and bridge). It's not that hard to do: we just need
a DNS record pointing to the broker's IP address
to restart the broker with the new domain name in --acme-hostnames
to update brokerUrl in config.js
push a new release of the WebExtension and update snowflake.torproject.org
I don't think we need to push a new release of the client software, only the in-browser software.
That's truly one of the most stupid episodes that I've ever seen from this "g00gle safe browsing".
Isn't it sufficient to change it to https://snowflake-broker.azureedge.net/?
Good call, that will work for a short-term fix. But then the proxy requests will be going through the CDN and cost money.
Rough cost estimate. CDn traffic costs minimum $0.08/GB, call it $0.10/GB. Proxies poll every 10 s, that's 9000 times per day. Suppose each poll costs 1 KB (wild guess including TLS overhead). Then if there are 6 proxies running, that's about 0.5¢ per day:
Trac: Description: I opened the browser console for other work, and saw that the Snowflake addon was looping with the errors "The resource at “https://snowflake-broker.bamsoftware.com/proxy” was blocked by Safe Browsing." and "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://snowflake-broker.bamsoftware.com/proxy. (Reason: CORS request did not succeed)."
I worked around the problem by going to that URL in a new tab and clicking the "do it anyway" option when the warning appeared, and now the addon is looping normally with the "at client capacity" message. But bypassing/disabling Safe Browsing is obviously a non-starter for general users, so someone needs to determine why the agent URL was blacklisted by Google and get it cleared, or the Firefox addon will be effectively dead.
Addon version 0.0.5.
to
I opened the browser console for other work, and saw that the Snowflake addon was looping with the errors "The resource at “https://snowflake-broker.bamsoftware.com/proxy” was blocked by Safe Browsing." and "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://snowflake-broker.bamsoftware.com/proxy. (Reason: CORS request did not succeed)."
I worked around the problem by going to that URL in a new tab and clicking the "do it anyway" option when the warning appeared, and now the addon is looping normally with the "at client capacity" message. But bypassing/disabling Safe Browsing is obviously a non-starter for general users, so someone needs to determine why the agent URL was blacklisted by Google and get it cleared, or the Firefox addon will be effectively dead.
Hmm, maybe now is a good time to get some TPO domains for the broker and bridge.
My understanding is that the sysadmins don't want to point any torproject.org DNS at hosts that they don't manage. So we would have to get new Tor-managed hosts set up first, I believe. I could be wrong about that.
Hmm, maybe now is a good time to get some TPO domains for the broker and bridge.
My understanding is that the sysadmins don't want to point any torproject.org DNS at hosts that they don't manage. So we would have to get new Tor-managed hosts set up first, I believe. I could be wrong about that.
Okay I pinged the sysadmin team and made legacy/trac#31232 (moved) to discuss this. It's possible this isn't an immediate solution but probably a good conversation to have anyway.
dcf: I'd like to mail some folks at Google and try to get a proper contact in the safe browsing team. I'm thinking agl and meredith, since I know them. Sound good to you?
It's worth getting ahead of this in case somebody there thinks snowflake is unsafe.
dcf: I'd like to mail some folks at Google and try to get a proper contact in the safe browsing team. I'm thinking agl and meredith, since I know them. Sound good to you?
It's worth getting ahead of this in case somebody there thinks snowflake is unsafe.
It's okay with me. I do have the Snowflake badge embed on a bunch of pages across www.bamsoftware.com. (But https://transparencyreport.google.com/safe-browsing/search returns positive even for nonexistent subdomains, so it seems like a whole-domain block rather than something heuristic for individual pages.) If it's not Snowflake but something else that they don't like, that's good news, we only need to get a new domain name for Snowflake stuff.
Hmm, maybe now is a good time to get some TPO domains for the broker and bridge.
My understanding is that the sysadmins don't want to point any torproject.org DNS at hosts that they don't manage. So we would have to get new Tor-managed hosts set up first, I believe. I could be wrong about that.
We have been using the torproject.net domain for that purpose, and I think we could do that here too if we wanted. (One reason to keep it separate from torproject.org is because of words like cookies, cross-site, and isolation.)
That's truly one of the most stupid episodes that I've ever seen from this "g00gle safe browsing".
Isn't it sufficient to change it to https://snowflake-broker.azureedge.net/?
Good call, that will work for a short-term fix. But then the proxy requests will be going through the CDN and cost money.
Just noting here that we seem to be having trouble with the bridge at snowflake.bamsoftware.com as well (see legacy/trac#31231 (moved)) which is not domain fronted. I'm not 100% sure this is the same issue but it seems plausible.