The A1530 actually falls back to 3G and then 2G depending on the part of Beijing. I don't really understand how that works, but the 3G is also much better than the 2G, which is pretty awful.
One very painful thing about the A1530 is that the 4G connection gets broken (and thrown back to 3G or 2G, depending on location) whenever a call comes in or you make a call out. You then have to manually reconnect to the 4G network. I don't really understand why this is. Maybe the voice data is being sent over the 4G network during a call or something? The China Mobile people told me explicitly about the problem. 4G has only been available since the 18th, so haven't had that much time with it, but coverage seems decent.
iPhone 5s's bought in Hong Kong (model A1530) work on the LTE network. The iPhone 5s's previously sold in the mainland, however, will not, as they lack the right chipset for receiving a TD-LTE signal. I'm guessing China Mobile will just be selling the A1530s.
McDonalds and KFC do deliver in major Chinese cities. The biggest difference is the cost structure. Chinese cities have a very high population density, which makes delivery much easier. They also have relatively cheap labor (although this is changing). And people here ride electric scooters, which are much faster at navigating big cities than cars. McDonalds in Beijing charges a little less than $1.50 USD for delivery.
I've been skeptical of Google-branded hardware ever since my Nexus One stopped working due to a non-functioning power button. I find myself associating "beta" with their stuff - that's fine for software but not so much for physical goods.
Recommend reading Sep Kamvar's essays known as Mastery and Mimicry. He is a former Stanford and current MIT professor. Fred Wilson is a fan of his work.
Venture hacks and Fred Wilson's blog both have a lot of great content, although I have no idea what the signal:noise ratio is because I mostly read the posts that make the front page of HN.
Thanks so much for this. This will be incredibly useful for me (behind the GFW, which gets moody about Wikipedia pretty often). Could this easily periodically update itself to grab fresh versions of articles? I think that would be a great feature, especially if you could do it without having to pull down the whole database each time you wanted to update, instead just updating on an article-by-article basis.
How could such a technique actually give the firewall information pertinent to whether or not the offending site was illegal? It's like a MITM attack where they intercept the outgoing ssh connection, send seemingly arbitrary data to the ssh server on the non-Chinese internet, and then sometimes disrupt the ssh connection or allow it pass through.
What information could the response to garbage possibly convey beyond: "how does this server respond to garbage"?
How would that even help with fingerprinting, which is his suggestion? Would there even be much variation in how different sshds would respond to that? So what could you do with that information? 30% of known Tor servers use sshd version X, so let's ratchet up the frequency of RST packets for connections to servers of version X? Seems like a long shot: that would be both a sophisticated attack and have pretty hamfisted results. And how could this information be used to find open relays? Just guilt by sshd version again, since statistically machines with open relays have a tendency to run version X of sshd?
I'd like to hear a security person come and talk instead of my wild speculations.
TCP uses a 32bit sequence number that should be initially seeded to a _securely generated_ random number. As each packet is sent back and forth between endpoints, this number increments by 1. If an adversary wanted to disrupt the connection (denial of service) they could obtain the sequence number and other numbers such as the source and destination ports and spoof some packets pretending to be the real client. It would then become a race between the real and fake clients as to which packet is accepted first. There is usually over 2^40 bits of entropy that an adversary would need to know to hijack a TCP session.
If the adversary is in the middle (MITM) they can read all your traffic and obtain the required entropy in real time. In this scenario, it doesn't matter how much entropy is contained in each packet because the adversary knows that information in real time. Thus the adversary will be able to inject packets to reset/terminate the TCP session, causing a Denial of Service situation.
Cryptographic protocols including SSH and TLS are designed to solve the majority of problems that MITM adversaries can cause. The notable exception is that these protocols rely on unprotected TCP sessions. MITM adversaries are still able to reset/terminate TCP sessions (when SSH/TLS protocols are detected).
IPSec protects not only the information transmitted, but the IP packet headers as well. An Authentication Header (AH)[1] is appended and verified to ensure that packets haven't been tampered with or forged. MITM session reset/termination attacks are therefore no longer possible because forged packets will be ignored.
You can fairly easily spot most common protocols by seeing what they 1) Say to you without you prodding them or 2) Respond when you hit them with random data.
My guess is that they're using it as a cheap way to tell the difference between most of the common protocols. (ie. ssh vs. openvpn vs. https, etc.)
Would an outgoing ssh request be hard to discriminate from an outgoing openvpn request or an outgoing https request? I don't know enough about how the protocols work to understand.
> Would an outgoing ssh request be hard to discriminate from an outgoing openvpn request or an outgoing https request?
No. But the point probably is: it is much easier and more economic to block the receiving end once by figuring out what it is than having to scan every single outgoing connection all the time.
I'm guessing its not actually garbage, but something that an authorized VPN can respond to, so if you are not authorized, its garbage and you cannot give the correct response and are blocked.
So then you're theorizing that this is a whitelist approach to VPN connections. Again, this would seem really heavy-handed, since it would block the vast majority of VPN traffic. It's certainly not the case for me currently (I'm in China), but it's possible that other cities are taking that approach.
> since it would block the vast majority of VPN traffic
Which would be a problem for the Chinese government HOW?
I think those very blunt ways of identifying "unwelcome" connections and then just blocking them looks like exactly the solution a government makes that doesn't twitch an eye at re-locating thousands because they want to build a dam right there.
So far encrypted traffic was a neat way of circumventing the control, now this could be trying to just plug those holes. Even if the handshake message does not say "OpenSSH xx...." at least the protocol response to random data would give them a clue and it is (sort of) more difficult to fix on a larger scale because they could always fine-tune the finger-printing.
Instead of monitoring and analyzing all outgoing connections all the time, they just figure out where they are going and then block the destination once and for all - sounds logical and neat.
It sounds like you were trying to do click arbitrage. Is that forbidden by Google / FB ads? I don't really understand why it would be, but I guess I could understand that being a more reasonable cause for a ban than the fact that you were advertising a chicken coop.
No arbitrage, just advertising Clickbank products through Facebook and Adwords.
I was told by Adwords staff, that if I change the content of the Chicken Coop site to conform to Google's policies, the account ban would be lifted.
Unfortunately, as an affiliate, I have no control over the content of the Clickbank site I am promoting, nor any warning as to when it went into 'non-compliance'.
I did not think the Chicken Coop site was insidious.
One very painful thing about the A1530 is that the 4G connection gets broken (and thrown back to 3G or 2G, depending on location) whenever a call comes in or you make a call out. You then have to manually reconnect to the 4G network. I don't really understand why this is. Maybe the voice data is being sent over the 4G network during a call or something? The China Mobile people told me explicitly about the problem. 4G has only been available since the 18th, so haven't had that much time with it, but coverage seems decent.