Brad Fitzpatrick

Tailscalar here.

Yeah, this sucks.

We’re working on changing the identity model. (how users/domains/tailnets all map to each other)

When we first started, we were trying to make it easy for companies to sign up and start working with their coworkers, but we had a special case for @gmail.com users getting their own tailnets (because at the time, we only supported Google Auth). Later we added GitHub, and GitHub special cases for individuals vs orgs (which nicely mapped to our single-user vs multi-user tailnets).

Over time, we added more auth providers like (and BYO-OIDC) and this whole assume-a-multi-user-tailnet-unless-gmail-and-192-other-shared-email-hosts model really fell apart. We "decompose" (add to our shared email domain list) tailnets every month or so as we find them. We didn’t have your domain on our list previously.

We’re in the middle of changing the identity model to make this class of problem go away entirely, though.

Meanwhile, we just chatted about it and seems like the quickest thing we can do here is turn on User Approvals for all new tailnets so at least the admin of new tailnets like yours has to approve people joining them.

[Edit May 28: see https://www.reddit.com/r/Tailscale/comments/1kxwtu5/shared_domains_security_bulletin/ for the security bulletin]

Yeah, I'm particularly excited about StrictMode. (but I'm also the author of it :))

StrictMode (http://developer.android.com/reference/android/os/StrictMode.html) is not about unnecessarily using network or CPU but about doing it on the correct thread (and it's about network or disk, not CPU)

To run a 60 fps animation, you only have 16 ms in your main thread (UI thread) callbacks before you stutter an animation. Or 5000 ms to bring up an ANR dialog. Anything between 16 ms and 5000 ms is "janky", though (unresponsive, not pleasant).

Given that the disk (and especially the network) can take longer than 16 ms, StrictMode helps you find places where you unknowingly use one of them. It's often the case that you didn't hit the disk directly, but some API you used hit the disk via IPC calls across 2 or more processes. And that process might have to wait for the system-wide yaffs lock (on devices that use yaffs) before it could even start the read/write. And it it's a write, the flash chip (whether MTD or a FTL emulating a block device) may have to do some slow GC, making some writes slower than others.

In any case, you should get off the UI thread if there's any risk you might take longer than 16 ms.

Gingerbread has hundreds of such fixes using data we've collected from internal dogfooding. We setup our dev builds to write all disk/network violations to the DropBox (http://developer.android.com/reference/android/os/DropBoxManager.html) and setup our dev builds' DropBox to upload them to servers to run mapreduces over. Every hour we'd have a new dashboard of the top offenders (count, total latency jank, etc), fixing as many as possible both in apps and in the system (various core services, providers, etc).

I saw the transition slowly, but friends who have switched right from Froyo (which was already pretty fast!) to Gingerbread tell me that it's noticeably smoother & more responsive across the board. A large part of that is also the concurrent Garbage Collector in Dalvik.

Anyway, bunch of exciting stuff in Gingerbread.

(this comment is long... I should write a blog post.)