The S-1 contains a table with number of options granted as well as strike price on various dates since June 20, 2014. Some other data can be determined from the option grants for executives. Here's a rough list:
Date Strike ($)
==============================
July 25, 2012 2.73
May 31, 2013 2.90
August 27, 2013 3.33
February 27, 2014 7.25
June 20, 2014 8.23
August 16, 2014 9.11
December 17, 2014 10.06
March 20, 2015 11.28
May 14, 2015 13.09
June 17, 2015 13.94
July 9, 2015 14.81
August 11, 2015 15.25
September 16, 2015 15.39
However, for this particular service, I think that you could get away with much less by leveraging existing work: modify an OpenVPN client so that it has an additional listen socket; then, use a websockets-based relay to link the OpenVPN client's listen socket and your OpenVPN servers.
A nice thing about this setup is that the webpage with the websockets relay can be dynamically generated and point to any server of your choice for quick load-balancing; it would also make it difficult for carriers to block any single server. The biggest problem would be scaling, since OpenVPN might load a server with just hundreds of active clients (http://forums.openvpn.net/topic9148.html), in which case a custom solution might be better...
Regardless of how they did it, very clever workaround!
I wrote a non-root tethering app, so I might have a bit of tunnel vision.
First, any good tethering app should be immune to a simple TTL check. The most likely culprits are instead application traffic patterns. The following immediately come to mind:
- Browser user agents
- Automatic status checks under both OS X and Windows
- Application behavior:
* Netflix and Hulu on Android isn't supposed to happen.
* Browsers like Chrome are very aggressive and can open dozens of simultaneous TCP connections. DNS prefetching can also generate dozens of requests over UDP in a very short time window.
Yep. Any non-root tethering app should just show the encrypted tunnel as a connection originating from the device itself. Just make sure that DNS requests don't leak when using an SSH tunnel. In fact, a simple port-forwarding app is all that's really necessary for most tunnel cases.
All of this makes a $6-$8/mo SSH/VPN privacy service (e.g., cotse.net) rather intriguing.
Most properly configured VPN service providers will reroute any DNS request traffic to their private NS servers (e.g., privateinternetaccess.com).
Another thing I'd like to mention is MPPE is not functioning in most Android builds, so don't rely on PPTP based VPNs on your phone - encryption won't work! Make sure your VPN service provider has IPSec/L2TP tunneling available.
Obviously root users should opt for OpenVPN. (e.g., cyanogenmod 7+)
The goal is not to forward packets blindly like a NAT. You emulate the NAT's behavior by running a TCP state machine in user space and converting packets to regular Android SDK calls. This is what all of the non-root tethering apps likely do, because raw socket access is not allowed.
TTLs should not affect PdaNet if it is written like any of the other non-root tethering apps. Mac and Windows update pings are probably a good indicator, however.
I wrote one of the (non-root, virtual network-adapter based) apps like PdaNet, and I can say that a number of people on VZW have reported this. I wonder what would happen if my app were one day open-sourced so that anyone could publish an apk to the market in 15 minutes...
Putting the phone in airplane mode and turning on Wifi mode also effects the same behavior on many Android phones from AT&T. This would probably work for your Nexus, too.
That worked perfectly! I am hardly able to express how grateful I am :-)
It even worked more smoothly than the Google Toolbar's own importer, which complains about dupes (wrongly), and prefixes all the labels with "Tag:" for no good reason.
