BZZZZT try again. Chrome used (and still uses) its own JS engine, distinct from the built-in JS support in WebKit. Apple didn't let them do that on iOS; they had to use the JS engine that runs in the WebKit that is used in the webview widget, no exceptions. Until a recent iOS version (8, I believe), that WebKit build didn't even use JIT-compiled JavaScript, so it was always a lot slower than Safari.

The JS engine (including both its performance and its behavior) is a hugely important part of a modern browser. By that standard, Chrome-on-iOS definitely wasn't the same thing as Chrome-on-PC.

That's not how HSTS preload works. Or rather, it is, but you're missing a vital step. The preload list won't accept sites that don't specify the "preload" flag in their Strict-Transport-Security header. It ought to go without saying that they won't accept sites which don't serve HTTPS at all...

The max-age and includeSubDomains directives are relevant to browsers. The preload directive is relevant to HSTS preload list maintainers (or rather, to their servers). I guess the government could try coercing the preload list maintainers into including the relevant .gov sites even if they don't meet the requirements for inclusion in the list, but I'm pretty sure that won't happen.

Space is really, *really* fucking big. Even low earth orbit at any given altitude is vast; it's literally larger than the surface of the planet. Add altitude shells to that - go up a few KM and you're now a few KM away from anything in the lower shell, even at closest point of approach - and there's an astonishing amount of room in space.

You wouldn't ask if there's room for 4000 more ships on the ocean, despite the fact that there's a lot less ocean and a lot more things crossing it vs. what we have in LEO. You wouldn't even ask if there's room for 4000 more cars on the road in the continental US, despite there being many orders of magnitude less space on US roads than there is in any given LEO altitude. Satellites, functional or not (including debris), move in predictable patterns, and functional satellites have thrusters that allow them to alter or maintain their course.

Agreed, of course, that the satellites should be capable of de-orbiting. But seriously, this "is there enough space in LEO?!?" meme is kind of dumb, at least right now. Let's assume you put each satellite in the middle of 20x20 KM non-overlapping exclusionary zone (omitting the third dimension for now). 400 KM^2 per bird. 1,600,000 KM^2 total. Sounds big, right? You could fit that entire collection, with a hundred thousand square KM left over, into Alaska. Don't get me wrong, Alaska is a big place, but it's not *that* big on the world scale. That's all in one orbital shell.

Well, MS isn't always the fastest on rolling out security features. Somebody else may need to lead the way. If the Mozilla foundation releases HSTS for Firefox 1.0, it might be possible to persuade MS to do the same for their similarly-aged browser...

SRP has a number of problems, the most notable being that there's no way to securely *distribute* (or create) the password without falling back to some other TLS suite, or doing it out of band. This really limits the usefulness of SRP in a browser.

Additionally, I'm not sure how browser support for SRP is supposed to make phishing stop working. If the user still needs to enter their password somewhere, then the phishing attack just has to look like wherever they usually enter their password. Yes, an attacker intercepting the network traffic of a legitimate handshake won't be able to extract any useful info about the password (or be able to replay it blindly), but a phishing site that gets users to enter their password and then sends that password back to the (attacker's) server via whatever mechanism it cares to will still work just fine.

On the other hand, there are definitely places that I'd like to see SRP deployed. A key one, which I consider a lot more important than in browsers, would be as a replacement for NTLM hashes (which are antique and terrible) in SMB (Windows networking, Samba, etc.) traffic. It also makes sense for things like remote desktop or ssh (where, at least for password auth, you assume that both sides already know the password so the distribution problem is taken care of). Once you have it in those places, putting it in the browser seems reasonable enough - after all, enterprises do use IE's built-in support for NTLM auth to web servers, which sucks about as much as NTLM for SMB - but I'd put the other areas ahead of the browser.

On the one hand, you're kind of wrong; any site that wants to can opt into the HSTS preload list, and IE uses the same preload list that both Chrome, Safari, and Firefox use. The preload list, by the way, is not a "whitelist" in the usual sense; it simply has the effect of there having been a "zeroth visit" before the first visit, so the first visit is safe. After that, the site behaves as normal.

On the other hand, it is true that getfirefox.com doesn't support HSTS at all (much less appear in the preload list, which would reject it anyhow for failing to have the response header present). Worse, though, mozilla.org doesn't seem to support it! At least, the Chrome dev tools don't list the Strict-Transport-Security header in responses from the site. That is a bizarre (and, frankly, unwise) omission.

The Internet was a very different place 15 years ago! Also, satellites were less advanced, bandwidth demand was lower, launch costs were higher, and Elon Musk wasn't behind the project.

OpenSSH has been ported to Windows a number of times. Off the top of my head:
  * Interix (POSIX subsystem running on native NT, but still technically Windows) has at least one version of OpenSSH (server and client).
  * Cygwin (emulates Unix on Win32) has OpenSSH, (server and client).
  * MSYS (a set of Unix tools ported to Win32 via MinGW) has OpenSSH (client for sure - it's installed with Git for Windows - not sure about server).

None of those are terribly well integrated with Windows' way of doing things, though. Sometimes that's a good thing - I can take my .ssh folder from a Linux box, drop it on a Windows system, and it'll work with the things listed above - but it also means that (for example) the public key used when SSHing into my Windows box is completely unrelated to the public key used when RDPing into the same box. That's silly.

Does the OpenSSH license prevent making the code proprietary? I'd have guessed it was under a BSD license, which permits closed-source derived works.

Indeed. I expect one of the things they'll be looking at doing is adding support for some of Windows' built-in authentication options. For example, recent versions of RDP use machine certificates, typically with a trust-on-first-use model similar to SSH. It would be nice if SSHing into a Windows box could re-use that machine cert, and SSHing from a Windows box could take advantage of the list of IP+cert pairs that you already trust. This would require some code changes to OpenSSH though, since it is of course currently utterly unaware of Windows' certificate stores.

Also, powershell isn't really used to displaying to anything except Windows consoles. Just for the hell of it, I tried running it in xterm (which, while antique, any *nix program would be OK with) by SSHing into a Windows box. It launched, but trying to run any commands - even exit - appeared to hang (though Ctrl+C worked to exit out of PS entirely). This may not be something that Microsoft needs the help of the OpenSSH devs to fix, but it's something that needs to be fixed, regardless. If people can SSH into Powershell, then Powershell needs to be able to display to whatever console they're SSHing from.

In fairness, a country can have lots of astronauts without having the ability to launch them itself. After all, right now, the *USA* doesn't have a man-rated spacecraft, yet we still routinely send astronauts to the ISS. We just use Russian launches for it.

For the record, Windows Phone is reasonably popular in some parts of the world. For example, in India, it's somewhere around 10% (based on sales share there the last few years, and on having just spent a couple weeks in India). As a reminder, there are a *lot* of Indians (though many are too poor to afford a smartphone, even the super-cheap WP8 and Android models popular there).

I'm from Seattle, so Windows phones aren't really that rare around here. I've also seen them in France and, of course, Finland, when I was last there. I only rarely see them in California or elsewhere in the US, though.

On the other hand, when I was in Indonesia last year, there wasn't a single Windows Phone in sight, but I think Blackberries outnumbered iPhones. Android beat both, but it was weird seeing a platform that's a rounding error in the US in second place.

Often it's not even the cheap hardware, but just really shitty drivers (frequently pre-installed by OEMs). Do a clean install of Windows and be careful about the source of your drivers, and you can go years without a crash on Windows (on a heavily used gaming box, no less). I know, I've done it.

I honestly didn't understand why most people hated Vista so much (I mean, it had bugs, but they weren't *that* bad; it used a lot of RAM, but I was running it on 1280 MB and it was all right) until I tried an OEM image of it. Took 3x as long to boot to a usable state (despite having about the same specs), was noticeably laggier, had less free memory, and crashed in under an hour of use (I'd been running the RC2 build - not even release - for months without a crash). That kind of problem with shitty OEM builds is, unfortunately, a problem in the PC world. Apple takes care to avoid it (though their own Windows drivers also tend to be shit.)

Bringing this back to phones, the same problem applies there. An awful lot of Android OEMs take a fairly good OS - the stock Android platform - and then run it on hardware with bad firmware (which, sadly, is usually not user-fixable), bad drivers, and (often buggy) bloatware. The result is... not pretty. The OEMs don't really have anybody to blame but themselves, but the users keep buying it so as far as the OEMs are concerned, they're doing the right thing.

My take on it is, that iPhone users only THINK they use their phone a lot, while Android users use their phones more than they think they do.

Sadly, it's arguably the other way around. The problem isn't that Android users use their phones a lot, it's that the phones (or rather, the OS) is terrible at not using the battery when the user isn't using it. A skilled and conscientious user can regulate their Android phone's battery use pretty well, and get excellent battery life (without compromising functionality much), and there are apps to automate some of that, but... by default, Android is *terrible* about leaving stuff running in the background. This makes it more functional than the competing OSes in some ways, since those tend to have pretty strict restrictions on background processing, but sometimes the stuff it does (like continually tracking your location if you open Maps and then don't tell it to kill the location service when not needed*) is just stupid.

Yes, when you're running something that will really pound on the battery (like gaming) then Android devices might outlast their competition. They do have larger batteries, in most cases, and their processors are no less efficient. The reason for those larger batteries, though, is because in order to get anything close to the same average battery life in normal usage Android needs more battery capacity. Expand the time scale from a few hours of intense usage to a day or normal usage, and Android will usually burn through a lot more Watt-hours for the same level of user usage.

* Caveat: This was something I noticed on my father's Android 4.0 device; they might have fixed it since. It was fucking stupid though; he'd used Maps for a few minutes in the morning (with location, but not navigating to anything), then gone back to the home screen without force-killing the app or turning off GPS, left the phone in his pocket the whole rest of the day, and found its battery nearly dead in the afternoon. Over 90% of the battery had, over half a day, gone into tracking him as he wandered around a boatyard with the app neither running in the foreground nor under orders to do anything in the background!

Correct. As a random example, a NULL pointer read - certainly the most common class of memory error I've seen, probably the most common by far in general - is almost never exploitable (for arbitrary code execution). You can use it to crash programs (denial of service) but usually not for anything else.