Ok, so he made a very informative page about it, but this is still a well known effect. It affects practically everything you can do in image editing. Blurs, etc. Most people neither notice nor care. It's rooted in the fact that most images come with undefined black and white points and a gamma chosen for artistic effect rather than physical accuracy. Thus correctly converting to linear gamma is hardly ever possible. You can still correct for monitor gamma to avoid some rarely seen inconsistencies and artifacts, but most people don't even notice, so why bother? However, Photoshop does have everything you need to avoid the effect completely, even in the ancient Photoshop 6.0.

Here's how to properly resize in Photoshop:

1. Convert mode to 16 bit (to avoid tone aliasing in the next step, no other influence on the calculations)
2. Convert to profile, select "Custom RGB", set Gamma to 1.0 (this converts the internal image data to linear gamma, no visible change because the image is color managed and corrected back to monitor gamma on the fly)
3. Image Size
4. Convert to profile, select "Custom RGB", set Gamma to 2.2 (default)
5. Convert mode to 8 bit

Done. You can substitute your favorite image filter for the image resize. Unsharp mask works much better at gamma 1.0, for example. Of course you can use several filters before converting back to monitor gamma and 8 bit.

DNSSEC uses cryptographic signatures to authenticate DNS records and thereby prevents DNS spoofing. DNSSEC does not use encryption, only authentication, i.e. it provides trust, but not privacy.

DNS spoofing is an attack which can be used to redirect traffic to an attacker's server, where the attacker can intercept the traffic for a man in the middle attack or create an impostor service and harvest credentials. There are several countermeasures in plain DNS to prevent spoofing, but Dan Kaminsky's discovery of a fundamental spoofing vulnerability in the DNS protocol finally pushed DNSSEC out of the labs into the wild.

Reposting logged in:

To people interested in image based rendering, something like the system presented by Microsoft is inevitable, yet still impressive when actually implemented. Look at the transitions in Google Streetview, for example: You have to pay close attention because it happens really fast, but you can see that Google also has a 3D proxy underneath the images. The transition is not between different projections of flat images but between rough approximations of the actual geometry, textured with the image data. That is what makes Microsoft's system so seamless as well. The existence of an underlying geometric understanding of the scene is also obvious when you move the cursor over a Streetview image or look at the cursor in the TED demo: It changes perspective depending on the geometry.

The critical algorithm at the core of it all is called "SIFT" (Scale Invariant Feature Transform). That's what enables the computer to identify matching features in different pictures, as long as they're taken from similar positions. (This is done after prefiltering the images according to geo-tagging information to reduce the search space.) Then you have sets of 2D coordinates of 3D points under several projections (images). This data defines a set of equations which you can solve to get the relative camera positions and 3D coordinates of the feature points. If you've followed the news on PhotoSynth, you might remember pictures of 3D point clouds: Those were the calculated 3D positions of feature points in the source images. From these point clouds, you can create an approximate representation of the geometry of the scene. If you then use the picture taken from a position closest to your current viewpoint to texture that geometric proxy, you get what Microsoft presented at TED. It really isn't all that complicated.

Inevitable, therefore not really surprising, but still mighty cool.

Doesn't anybody read the paper?

You can not use a fake card. You need a genuine card. The MITM is between the genuine card and the terminal. The transaction goes through because "chip and PIN" isn't the only acceptable protocol. The card can also be used in combination with a signature instead of the PIN. The trick is to make the terminal think that the card is using PIN authentication while the card actually performs the (authenticated!) chip and signature protocol.

The bank usually gets the information that no PIN was sent to the card, but this information is not relayed back to the terminal in way which is both standardized and authenticated. The "PIN-OK" message from the card to the terminal is not authenticated and the authenticated transaction request/accept messages between the card and the bank (through the terminal) only contain the information in an unstandardized format. That's the flaw.

No, the whole protocol is designed such that the important information is exchanged in authenticated packets between the chip on the card and the issuer's servers, with the terminal acting as a dumb relay. The terminal could not perform any transactions without a genuine card if there had not been the 2010 mishap: That caused the mag-stripe authentication to be reactivated. Once that problem is solved and the non-chip authentication methods are finally disabled, a transaction will require a genuine card, no matter what an attacker does to the terminal.

The problem described in the paper is that the terminal (and by extension the merchant) can't tell that the card performed a "chip and signature" authentication instead of the negotiated "chip and PIN" authentication.

It's either/or. You can authenticate with the chip and your signature, then the merchant eats the damage if the signature turns out to be fake. Or you can authenticate with the chip and your PIN, then the usual assumption is that the customer didn't keep the PIN a secret. The attack works by pretending to the terminal that the card performs PIN authentication. The card, and by extension the bank, are made to believe that the customer wants to use signature authentication.

No, the payment processor is made to believe that PIN authentication isn't used. The false PIN-OK message is between the MITM and the terminal. The PIN entered is not actually compared to the PIN on the card. The MITM handles the card according to the "chip and signature" protocol and the terminal according to the "chip and PIN" protocol.

Yes, they still need the card. The card performs a "chip and signature" protocol with the bank. In the "chip and signature" protocol as well as in the "chip and PIN" protocol, the chip on the card uses a secret symmetric key to create a transaction-specific message authentication code. The bank will not accept the transaction without that code. The attack is to have the card perform "chip and signature" while the terminal performs "chip and PIN". The protocol flaw is that the terminal cannot tell that the card is not performing "chip and PIN".

The messages between the card and the bank do usually include this information, but the format is not part of the standard. Consequently the terminal can not read it. It blindly relays the "chip and signature" messages, thinking that they're "chip and PIN" messages. The other indication that something's wrong would be the lack of a PIN-OK message from the card, but this message is not authenticated in any way, so the MITM can just fake that part of the "chip and PIN" protocol.

Seconded. I have a very simple circuit for an IR repeater which uses a 556 (that's two 555s in one IC), three resistors, one capacitor, an IR LED and a TSOP 1736 IR receiver. Total cost is less than $5 with a small breadboard, the latter being the most expensive component. One of the 555s is (ab-)used as an inverter. If you don't care too much about protocol, you can do away with that and just have a 50% duty cycle on the output instead of the usual 25%. The IR repeater works with almost all IR remotes (those which don't work use different modulations and are really uncommon).

If you're looking for something more digital, building a counter from flip-flops is always instructive and provides the blinkenlights.

Total moderation failure...

Here's how the standard defines the meaning of "seconds since the epoch" in relation to UTC dates: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14
As you can see, the meaning is actually "seconds since the epoch, excluding leap seconds." Always read the definitions.

According to that definition, the time_t value of "Friday the 13th, 2009 at 11:31:30pm UTC" is:
30 + 31*60 + 23*3600 + 43*86400 + (109-70)*31536000 + ((109-69)/4)*86400 - ((109-1)/100)*86400 + ((109+299)/400)*86400
= 30 + 1860 + 39600 + 3715200 + 1229904000 + 864000 - 86400 + 86400
= 1234567890

So, to answer the question which started this: Not including leap seconds.

Besides, it should be "Friday the 13th, 2009 at 23:31:30 UTC." The am/pm notation is not without ambiguities.

Almost. If year is disible by 16, then (year&15) is 0, aka false. You need to negate that condition.

Then roll it all into one (with one !((!a)||b) turned into (a&&(!b)):

return ((year&3)||((year&15)&&(!(year%100))))?false:true;

or ?0:1 or ?365:366, depending on language and application. This code probably warrants a //don't touch! comment.

Sorry, I overlooked the second daysInYear assignment. That code would actually work, but because of the unexpected code duplication, I would have written it like this:

year = ORIGINYEAR;

while (true) {
        daysInYear = IsLeapYear(year) ? 366 : 365;
        if (days <= daysInYear) break;
        days -= daysInYear;
        year += 1;
}

The function iteratively converts days into years. If there are more days left in the days variable than there are days in a year (365), then the days in that year are subtracted from the days variable and added as 1 year to the year variable.

It starts with year=1980, because the RTC counts days since 1/1/1980 (inclusive). For normal years, it subtracts 365 days and adds a year. After the first iteration, year is 1981 and days is the number of days since 1/1/1981 (inclusive). If the loop is currently looking at a leap year, then 366 days are subtracted from the days variable and 1 year is added to the year variable. So far the code looks like this:

while (days>365){
    if (IsLeapYear(year)){
        days-=366;
        year+=1;
    }else{
        days-=365;
        year+=1;
    }
}

The crazy thing is that someone must have looked at the edge case in that code: The last day of a leap year. On that day, the above code fails by incrementing year once too often, because at the beginning of the last iteration, the loop test indicates that there are more days in the days variable than there are in a year, but there are not, because a leap year has 366 days. That edge case is caught by the second if:

while (days>365){
    if (IsLeapYear(year)){
        if (days>366){
            days-=366;
            year+=1;
        }
    }else{
        days-=365;
        year+=1;
    }
}

The loop goes into the last iteration because of the loop condition which is on day short, then the IsLeapYear test selects the first branch, and instead of blindly incrementing the year and subtracting 366 days, there is an extra check if there are really more days left to make a full year...and then it fails to handle the only case where the code fails without that extra check. It should simply break the loop:

while (days>365){
    if (IsLeapYear(year)){
        if (days>366){
            days-=366;
        }else{
            break; // days==366 && IsLeapYear(year): end of calculation
        }
    }else{
        days-=365;
    }
    year+=1;
}

(Matt's code always reduces the day count by 366. 1980 was a leap year.)

That is deeply flawed code. (Why? Left as an exercise to the reader.)

The correct solution, if you want to keep the looping algorithm, is to add "else break;" as the alternate case of the "if (days > 366)" test: The infinite loop case then terminates the loop with the right year and days=366, which is the expected result.