cbr

We had to prepay before they would do the work, $2.5k at a time. They've probably been burned before by people who can't pay, and I can see why they would avoid that.

We live well below our means so we can donate more, so we did have some savings.

Breathing the fumes for an extended period of time? That's exactly what we would have had without the remediation.

We bought the house in February. We might try to sue people, but it's pretty clear the previous owners don't have much money. (The house was mortgaged to within a few-k of the selling price, and they had stopped paying their monthly payments. Which made it pretty hard to actually buy the house! http://www.jefftk.com/p/house-buying-timeline)

I've now linked that from the article; thanks!

(I read that page when I was first reading about this the night of the spill, but had forgotten about it. Holohan is amazingly knowledgeable about old heating systems.)

I do understand why insurance companies don't want to pay for things that happened before the policy took effect. Otherwise people could do harmful things, take out a policy, and then file a claim. All sorts of bad incentives.

On the other hand, it's pretty frustrating in our case!

They were initially using a Jerome meter to find the areas that needed cleanup, and then used the more sensitive but more expensive Lumex meter to finish the job.

The first few days were with a less experienced crew (from the same company) but they were pretty clearly wrong to declare the house cleared without being able to measure below 3000 ng/m3.

Author here: happy to answer questions.

A shopvac (or any vacuum not designed for mercury) would be a really bad idea: they vaporize the mercury and seriously distribute it around the house.

Client hints are a nice solution, but they don't require an image format stored in progressive order. They work fine with storing multiple copies on disk, and the overhead of low-rez versions server-side is minimal.

I say net loss because with current http the loss of closing the connection is typically much higher than the loss of downloading more bytes than you need. Connection reestablishment needs a lot of round trips.

To use a range request the client needs to know what range of bytes it needs. Currently your html is:

  <img src="foo.jpg">

Now, let's say foo.jpg is progressive, and if you examine the file you can see that you need H bytes for the header, N bytes for the first layer, M for the next, and so on. Then you could mark up the html as:

  <img src="foo.jpg"
       bytes-1x="(H+N)"
       bytes-2x="(H+N+M)" ...>

but that's a huge pain to generate by hand, and people like to compose html by hand.

If we want something that can catch on, it needs to be something where browsers and servers can negotiate in a fully automated way. Or we can just use srcset/picture.

They claim this is good for responsive images:

    The download or file read operations can be stopped
    as soon as sufficient detail is available, and if
    needed, it can be resumed when for whatever reason
    more detail is needed.
     -- http://flif.info/responsive.php

Unfortunately that's not how HTTP works. Your browser opens several connections to a website, and makes requests for resources. Each connection is in use until that resource is fully loaded, at which point you can send a request for another resource up that connection. Yes, the browser could close the connection after it has received enough of the image for the desired quality, but there's a lot of overhead in setting up a new connection, including some round trips, and so that is probably a net loss.

The JPEG image format also supports progressive images, in browsers today, and no one has figured out how to use that for single-file responsive images yet.

(You might be able to do something in HTTP/2 where you set the priority of the stream to 0 after you have enough of it for your needs, but I don't think anyone has gotten this working yet.)

The downside is memory usage during compression. A non-progressive jpeg can be compressed locally but a progressive encoding requires the whole image. But this is only a small downside.

(Converting JPEG images to progressive format is one of the optimizations mod_pagespeed makes.)

Nope: http://www.jefftk.com/p/sri-against-the-great-cannon

When their competitors can be 5x faster while still traveling to space that's not so hot.

(And it doesn't actually travel to space unless you're on a satellite connection.)

    red and black posts for me to crimp my speaker wire to

They tried that and no one wanted it: https://en.wikipedia.org/wiki/Nexus_Q

    If Firefox supports webp in the near future...

Where are you getting this? My understanding is FF still doesn't intend to add WebP support. https://bugzilla.mozilla.org/show_bug.cgi?id=856375

I read this looking to see if there was anything we could adapt for mod_pagespeed. Making images smaller without looking worse is, of course, what anyone optimizing images wants. Unfortunately, all they say about how they actually did their perceptual compression is:

    Ideally we’d have an algorithm which automatically tuned
    all JPEG parameters to make a file smaller, but which
    would limit perceptible changes to the image.  Technology
    exists that attempts to do this and can decrease image
    file size by 30-50%.

As far as I know, the only practical way to do this is to do a binary search for the quality level that gives a desired SSIM [1], but this is kind of expensive and I was hoping that they had something cool to tell us here.

[1] If you're interested in getting this kind of improvement and your images are viewed enough that it's worth doing more intensive encoding to get things exactly right, you could do this:

    def evaluator(image, candidate_quality):
      compressed = jpeg_compress(image, candidate_quality)
      return dssim(image, compressed)

    best_quality = binary_search(
      image, desired_dssim, candidate_qualities, evaluator)

It's a 33% increase, or an increase of 1.07 percentage points. It's not a 1.07% increase.

The metric divides compression ratio by log compression time. (Ignore for now the normalization to a standard compressor.) This is:

    r / log(T)

That doesn't seem like a good metric, because it overvalues changes in T. For example, say we currently can manage 10% compression (ratio = 100/90 = 1.11) and it takes us 16ms. That's

    r / logT = 1.11 / log(16) = 0.2775

Now we have two proposals. One brings us to from 10% compression to 55% compression (ratio = 100/45 = 2.22) while the other one drops compression time to 4ms:

    r / logT = 2.22 / log(16) = 0.555
    r / logT = 1.11 / log( 4) = 0.555

But improving compression by 5x matters more than improving speed by 4x. Take this to the extreme: a compressor that exits immediately leaving its input unchanged has the best possible score here, despite being useless.

CRIME: TLS compression can reveal private headers, like auth cookies. Fixed by turning off TLS compression. Not applicable to HTTP because HTTP never had header compression.

BREACH: Response body compression of a page where there's (a) something attacker controlled, (b) something private and unchanging in the body can reveal that secret, and (c) response length is visible to an attacker. Doesn't require HTTPS.

If an attack applied, it would be one like BREACH. Which isn't surprising: this is a direct replacement for "Accept-Encoding: gzip / Content-Encoding: gzip" and so we should expect it to be in the same security situation.

That sounds a lot like sdch, which you can actually use today if you're serving to in Chrome or Opera. (Look for "Accept-Encoding: sdch".)

    Widespread adoption of Subresource Integrity could
    have largely prevented the Great Cannon attack
    earlier this year.

Sorry, it wouldn't have. From the CitizenLab report [1] on the Great Cannon attacks:

    In the attack on GitHub and GreatFire.org, the GC
    intercepted traffic sent to Baidu infrastructure
    servers that host commonly used analytics, social,
    or advertising scripts.  If the GC saw a request
    for certain Javascript files on one of these servers,
    it appeared to probabilistically take one of two
    actions: it either passed the request onto Baidu’s
    servers unmolested (roughly 98.25% of the time),
    or it dropped the request before it reached Baidu
    and instead sent a malicious script back to the
    requesting user (roughly 1.75% of the time).  In
    this case, the requesting user is an individual
    outside China browsing a website making use of a
    Baidu infrastructure server (e.g., a website with
    ads served by Baidu’s ad network).  The malicious
    script enlisted the requesting user as an unwitting
    participant in the DDoS attack against GreatFire.org
    and GitHub.

So the idea is someone runs a site with:

    <script src="http://baidu.com/ads.js">

When visitors request these scripts the request passes through the "Great Cannon" which 1.75% of the time serves a different script instead. That malicious script makes lots of requests to the victim sites, and they're overloaded.

To prevent this sort of attack with SRI you would need to change your page to look like:

    <script src="http://baidu.com/ads.js"
            integrity="hash of the real ads.js">

The problem is, Baidu isn't going to be willing to commit to always serving the same ads js: they need to be able to make upgrades.

SRI is useful in the case where the entity producing the html is referencing js that they've uploaded to a third party CDN or js where they choose what version to run, but not in the normal "include a snippet and we'll do stuff to your page" model.

(To block the Great Cannon there, what would have worked would be moving the js serving to HTTPS.)

[1] https://citizenlab.org/2015/04/chinas-great-cannon/

The browser could do something with this, but I believe it doesn't. Instead the algorithm is just:

1) Load the resource specified in src (from network or cache)

2) If there's an integrity attribute, verify its hash

Your parent wrote:

"You're essentially making a bet that someone will find something useful to do with a frozen brain -- and that your estate will be able to afford the procedure -- before the company you've entrusted your brain to either makes a mistake or collapses."

The procedure your parent was talking about is revival, not cryopreservation. Your comment talks in detail about why you think ALCOR's corporate structure makes them unlikely to collapse, but the money in ALCOR's trust is only enough to keep people frozen, not to cover revival.

(ALCOR does claim that the patient care trust will be enough to cover revival, but (a) revival could potentially be very expensive and (b) ongoing maintenance expenses have been using up the money generated by the trust and this seems likely to continue).

"In what kind of bleak world would no one be willing to pay for a probable return to full health?"

This one.

People are dying now because of diseases we have basically eradicated in rich countries. The choice you're talking about making, saving a life for a few weeks worth of your own salary, is one that is already available to you and many others. What are you doing about it?

Now, I think you're right that it's horribly wrong to be letting people die when it's so easily avoidable, and I donate half my salary to help make things better, but most people don't think this way--most people just spend their money on themselves. Which means that if you're relying on the generosity of others to revive you you're probably going to be out of luck.

"that your estate will be able to afford the procedure" reads to me as being about revival? Which ALCOR etc don't attempt to cover.

> the fed/government backstops the s&p

How so?

Well, you'd know if your siblings died, but you're right, there's some survivorship bias in the "and I" portion.

The main issues, though, are very small sample sizes and the difficulty of knowing if people really were "just fine" compared to what they would have been otherwise.

Eh. We still know about people who didn't survive.

Survivorship bias is when you are only seeing the successes.