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.
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.
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.
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.
AES is a cypher. TKIP is a protocol, the Temporal Key Integrity Protocol, to be precise. The cypher used by WEP and WPA/TKIP is RC4. TKIP is what keeps changing the RC4 key to avoid the attacks on WEP, for which the attacker needs to collect many packets which have been encrypted with the same key. TKIP was invented to salvage older hardware, which only implemented the RC4 cypher.
It is important to know that WEP's weakness is not simply a vulnerable cypher, but a vulnerability of the crypto system. The announcement states that the attack on WPA/TKIP does not actually crack the key, so this too looks like a vulnerability of the crypto system. That highlights the importance of crypto system design. You can't just take a "secure" cypher and be done with it. The protocol surrounding that cypher is just as important.
An appropriate field for priority preferences is in the IP header.
TFA is about TCP congestion control, not about priority, and suffers from a fundamental misunderstanding of the effect that congestion control has on the network: None whatsoever. It is an algorithm which strives to improve the TCP link quality (!) for the communication endpoints of this connection. The reason why it appears that a P2P application can hog bandwidth is entirely on the local system. If an application sends more packets, more packets will get through, as long as there is a competing application which doesn't increase the packet rate. That is simply a result of the coin flipping: If your uplink can send 80 packets, but application A wants to send 60 and application B wants to send 40, then you have to drop 20 packets (20%), so applicaton A can send 48 and application B can send 32. If application A increases the rate to 120 packets while application B stays at 40, then you have to throw away 80 packets (50%), so application can send 60 and application B can only send 20. Attempt to send more and you'll get more through. None of that changes the number of packets which leave your system: 80. Your computer can use different TCP congestion control algorithms, but as long as the algorithm makes full use of the uplink (there is no reason that it should not,) it won't do the network any good.
The perceived unfairness is somewhere else: Something very similar happens on the network level with IP: a user who sends 10 packets may get 9 through while a user who sends 100 packets gets 90 through (usage 10% over bandwidth.) It is important to not that this happens regardless of protocol. This problem can be solved by queuing packets in per-subscriber queues. Up to bandwidth/subscribers, a subscriber's queue has top priority. Beyond that, the queue from which the next packet is sent is selected at random (with 1/packetsize as weight.) As long as such a scheme applies to all packets equally, regardless of content or protocol, it is fair. This will cause the standard TCP algorithm to slow down to the point where the local system experiences no packet loss, as expected. No TCP changes needed, works with all protocols, but doesn't throttle the evil P2P applications lower than the fair share of network capacity.
The spectral composition of light sources is far from irrelevant. The only case where it doesn't matter is when you look directly at the light source (TV, computer monitor) or at a surface which reflects the spectrum of the light source evenly (e.g. a projection screen or a white wall.) In every other case, a spiky light source spectrum results in improper color perception. One red color (e.g. a flower) can modulate the spectrum in a completely different way from another red (e.g. a shirt), even though they look exactly the same under a black body radiator light (light bulb, sun) at a certain temperature. The same two reds can look as different as red and black under a light source with only a very narrow band of red light in its spectrum. The difference in the color perception can only be reduced by making the emitted spectrum as similar to that of "natural" light as possible. That's why LEDs are still primarily used in effect lighting, to shine cones of colorful light onto known surfaces.
And yes, white LEDs are fluorescent. The yellowish stuff on the LED chip absorbs blue light and re-emits it as a broad spectrum from red to green. Because it's all so tiny, the exact amount of fluorescent spectrum light and the mixture with the original blue light from the chip is hard to control, which is why the light color of white LEDs is never the same.
I think it's amazing that people who knowingly declare wrong document types still get jobs as web developers. I think it's amazing that they think they're doing it to be professional.
The way to solve this is to make IE8 render all existing document types as IE6 or IE7 renders them, and implement new document types without deviating from the standard, to avoid a rerun of the current episode. Of course that is not an option, because it means that IE would remain stuck in 2001 for quite some time (until the IE team has the HTML5 rendering engine ready) while the other browsers can continue to render fancy CSS websites, and it means the IE team would have to actually create a complete standard implementation. As I said, not an option.
The opposite will happen. Since you can't write standards compliant pages which work in IE6 and/or IE7, web authors will continue to write broken pages for those browsers. They simply have to, as long as those browsers have any market share. Those pages will not be updated, because thanks to the new header, IE8 doesn't screw up these pages and updating isn't necessary. All other browsers now have to deal with those broken pages too, and since the pages come with the information which rendering engine they expect, users will push the other vendors to implement a compatible rendering mode. Now Microsoft can safely ignore the standards and implement only what is necessary to keep their major customers happy, because their browser never has to assume that a page actually wants to be rendered according to a standard.
Without the existence of the header, IE couldn't tell an actually standards-compliant page from an IE6- or IE7-only page with a doctype. Then it would have to render existing doctypes nonconformingly (like IE6/7, to maintain compatibility) and new doctypes conformingly (like other standards compliant browsers.) Then MS could not choose which parts of the standard they implement, which parts they change and which parts they extend, because the doctype refers to a standard, not a browser version.
As innocent as this extension may seem, it is a major setback for web standards.
No, it will be rendered by something which is almost IE7. Microsoft's inability to make new software correctly render the document formats of its predecessors is legendary. The concept of using older rendering engines for testing isn't new, yet we still need to test with actual old browser versions in virtual machines precisely because that's the only way to get actually reliable results.
Why would other browsers do anything differently than they do today?
Because each value of that header defines a rendering mode. Not rendering it accordingly is a failure of the browser. It's the return of designed-for-IE in machine readable form, with everybody else scrambling to implement the quirks of the browser with the highest market share.
I think the plan is for IE8 to act like IE7
No, the plan is certainly to make IE8 act like IE6 if the tag is not present, because, as you might have heard, many businesses are still holding off on the IE7 upgrade because it would break their business web applications.
The whole thing is an attempt to make implementation replace specification, which is especially devious coming from a closed source company.
First, instead of pretending that this is a doctype problem, own up the mistake and explain that IE6 created the problem which needs to be fixed.
The only actual problem is that many IE6-only pages exist which declare a wrong doctype. A solution to that does not need to be extended into a mechanism which makes it a standard compliant behaviour to design to specific browsers and browser versions. The proposed solution puts Microsoft in the position where they can continue to disregard standards, because as long as the document declares for which browser it is written, every other browser has to cope, should this become a standard.
In conclusion, Microsoft could either provide a new browser which faces the same problems as every other browser, i.e. not being recognized as IE and therefore being excluded from certain pages and web applications, alongside a compatibility browser which emulates IE6 for those legacy applications. Or Microsoft could simply push for a new version of HTML, complete with a new doctype, which a new browser version would then render accurately while treating older doctypes like IE7 or IE6 does today. The only thing they really need is a way of saying "this is a new page, no quirks mode, for real" and a new HTML doctype would do that just fine.
What they propose is the same compatibility scheme which has failed miserably in Word: Each version of Word creates its own "standard" of the DOC file format and every successive version has to render all versions of that format. Even Microsoft, despite having the code to the older Word versions, doesn't get that right. Competitors don't even stand a chance because there is no specification and no code to look at. Do you really want that for the web? That kind of mess is exactly why standards and accompanying standards replaced the proprietary Netscape vs. Microsoft tag soup.
Another great benefit for us developers is that we'll be able to change the new tag to get an IE7 rendering from IE8
Seriously, you're new to this, aren't you? Not only will you have to test your page with browsers running in virtual machines, over the course of time you'll have to test it in IE8 pretending to be IE7, IE8 pretending to be IE6, IE9 pretending to be IE8, IE9 pretending to be IE7, and so on as you change the tag to benefit from newer rendering modes. All those render modes will either use combined code, which means they won't render exactly as the old versions, or they are essentially multiple browsers in one, which means they'll each have their own security vulnerabilities and plugin incompatibilities.
This page is for IE7; deal with it
Added benefit for Microsoft: They get to write their own standards again. If another browser sees that made-for-IE7 tag, it must recreate all of IE7's quirks (and those of IE6 and IE8 and IE9...), i.e. behave like some closed source software from Microsoft. MS DOC deja vu...
I really hope that the other browser developers show MS the finger on this one, because if you thought browsers are memory hogs and security nightmares now, wait until every browser has to implement all its predecessors' quirks and all its predecessors' competitions' quirks.
Slashdot Mirror
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){ // days==366 && IsLeapYear(year): end of calculation
if (IsLeapYear(year)){
if (days>366){
days-=366;
}else{
break;
}
}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.
AES is a cypher. TKIP is a protocol, the Temporal Key Integrity Protocol, to be precise. The cypher used by WEP and WPA/TKIP is RC4. TKIP is what keeps changing the RC4 key to avoid the attacks on WEP, for which the attacker needs to collect many packets which have been encrypted with the same key. TKIP was invented to salvage older hardware, which only implemented the RC4 cypher.
It is important to know that WEP's weakness is not simply a vulnerable cypher, but a vulnerability of the crypto system. The announcement states that the attack on WPA/TKIP does not actually crack the key, so this too looks like a vulnerability of the crypto system. That highlights the importance of crypto system design. You can't just take a "secure" cypher and be done with it. The protocol surrounding that cypher is just as important.
Mr. Mabe is no longer with us...
Tom Mabe has filled several CDs with his "Revenge on the Telemarketers".
Do you know if visitors are allowed to take pictures (with a tripod, preferably) and show them online?
An appropriate field for priority preferences is in the IP header.
TFA is about TCP congestion control, not about priority, and suffers from a fundamental misunderstanding of the effect that congestion control has on the network: None whatsoever. It is an algorithm which strives to improve the TCP link quality (!) for the communication endpoints of this connection. The reason why it appears that a P2P application can hog bandwidth is entirely on the local system. If an application sends more packets, more packets will get through, as long as there is a competing application which doesn't increase the packet rate. That is simply a result of the coin flipping: If your uplink can send 80 packets, but application A wants to send 60 and application B wants to send 40, then you have to drop 20 packets (20%), so applicaton A can send 48 and application B can send 32. If application A increases the rate to 120 packets while application B stays at 40, then you have to throw away 80 packets (50%), so application can send 60 and application B can only send 20. Attempt to send more and you'll get more through. None of that changes the number of packets which leave your system: 80. Your computer can use different TCP congestion control algorithms, but as long as the algorithm makes full use of the uplink (there is no reason that it should not,) it won't do the network any good.
The perceived unfairness is somewhere else: Something very similar happens on the network level with IP: a user who sends 10 packets may get 9 through while a user who sends 100 packets gets 90 through (usage 10% over bandwidth.) It is important to not that this happens regardless of protocol. This problem can be solved by queuing packets in per-subscriber queues. Up to bandwidth/subscribers, a subscriber's queue has top priority. Beyond that, the queue from which the next packet is sent is selected at random (with 1/packetsize as weight.) As long as such a scheme applies to all packets equally, regardless of content or protocol, it is fair. This will cause the standard TCP algorithm to slow down to the point where the local system experiences no packet loss, as expected. No TCP changes needed, works with all protocols, but doesn't throttle the evil P2P applications lower than the fair share of network capacity.
Here's the short answer: RFIDiots, 35 minutes into the presentation. More Shmoocon 2007 presentations.
Wrong, all of it.
The spectral composition of light sources is far from irrelevant. The only case where it doesn't matter is when you look directly at the light source (TV, computer monitor) or at a surface which reflects the spectrum of the light source evenly (e.g. a projection screen or a white wall.) In every other case, a spiky light source spectrum results in improper color perception. One red color (e.g. a flower) can modulate the spectrum in a completely different way from another red (e.g. a shirt), even though they look exactly the same under a black body radiator light (light bulb, sun) at a certain temperature. The same two reds can look as different as red and black under a light source with only a very narrow band of red light in its spectrum. The difference in the color perception can only be reduced by making the emitted spectrum as similar to that of "natural" light as possible. That's why LEDs are still primarily used in effect lighting, to shine cones of colorful light onto known surfaces.
And yes, white LEDs are fluorescent. The yellowish stuff on the LED chip absorbs blue light and re-emits it as a broad spectrum from red to green. Because it's all so tiny, the exact amount of fluorescent spectrum light and the mixture with the original blue light from the chip is hard to control, which is why the light color of white LEDs is never the same.
I think it's amazing that people who knowingly declare wrong document types still get jobs as web developers. I think it's amazing that they think they're doing it to be professional.
The way to solve this is to make IE8 render all existing document types as IE6 or IE7 renders them, and implement new document types without deviating from the standard, to avoid a rerun of the current episode. Of course that is not an option, because it means that IE would remain stuck in 2001 for quite some time (until the IE team has the HTML5 rendering engine ready) while the other browsers can continue to render fancy CSS websites, and it means the IE team would have to actually create a complete standard implementation. As I said, not an option.
The opposite will happen. Since you can't write standards compliant pages which work in IE6 and/or IE7, web authors will continue to write broken pages for those browsers. They simply have to, as long as those browsers have any market share. Those pages will not be updated, because thanks to the new header, IE8 doesn't screw up these pages and updating isn't necessary. All other browsers now have to deal with those broken pages too, and since the pages come with the information which rendering engine they expect, users will push the other vendors to implement a compatible rendering mode. Now Microsoft can safely ignore the standards and implement only what is necessary to keep their major customers happy, because their browser never has to assume that a page actually wants to be rendered according to a standard.
Without the existence of the header, IE couldn't tell an actually standards-compliant page from an IE6- or IE7-only page with a doctype. Then it would have to render existing doctypes nonconformingly (like IE6/7, to maintain compatibility) and new doctypes conformingly (like other standards compliant browsers.) Then MS could not choose which parts of the standard they implement, which parts they change and which parts they extend, because the doctype refers to a standard, not a browser version.
As innocent as this extension may seem, it is a major setback for web standards.
the page will be rendered by IE7
No, it will be rendered by something which is almost IE7. Microsoft's inability to make new software correctly render the document formats of its predecessors is legendary. The concept of using older rendering engines for testing isn't new, yet we still need to test with actual old browser versions in virtual machines precisely because that's the only way to get actually reliable results.
Why would other browsers do anything differently than they do today?
Because each value of that header defines a rendering mode. Not rendering it accordingly is a failure of the browser. It's the return of designed-for-IE in machine readable form, with everybody else scrambling to implement the quirks of the browser with the highest market share.
I think the plan is for IE8 to act like IE7
No, the plan is certainly to make IE8 act like IE6 if the tag is not present, because, as you might have heard, many businesses are still holding off on the IE7 upgrade because it would break their business web applications.
The whole thing is an attempt to make implementation replace specification, which is especially devious coming from a closed source company.
First, instead of pretending that this is a doctype problem, own up the mistake and explain that IE6 created the problem which needs to be fixed.
The only actual problem is that many IE6-only pages exist which declare a wrong doctype. A solution to that does not need to be extended into a mechanism which makes it a standard compliant behaviour to design to specific browsers and browser versions. The proposed solution puts Microsoft in the position where they can continue to disregard standards, because as long as the document declares for which browser it is written, every other browser has to cope, should this become a standard.
In conclusion, Microsoft could either provide a new browser which faces the same problems as every other browser, i.e. not being recognized as IE and therefore being excluded from certain pages and web applications, alongside a compatibility browser which emulates IE6 for those legacy applications. Or Microsoft could simply push for a new version of HTML, complete with a new doctype, which a new browser version would then render accurately while treating older doctypes like IE7 or IE6 does today. The only thing they really need is a way of saying "this is a new page, no quirks mode, for real" and a new HTML doctype would do that just fine.
What they propose is the same compatibility scheme which has failed miserably in Word: Each version of Word creates its own "standard" of the DOC file format and every successive version has to render all versions of that format. Even Microsoft, despite having the code to the older Word versions, doesn't get that right. Competitors don't even stand a chance because there is no specification and no code to look at. Do you really want that for the web? That kind of mess is exactly why standards and accompanying standards replaced the proprietary Netscape vs. Microsoft tag soup.
Another great benefit for us developers is that we'll be able to change the new tag to get an IE7 rendering from IE8
Seriously, you're new to this, aren't you? Not only will you have to test your page with browsers running in virtual machines, over the course of time you'll have to test it in IE8 pretending to be IE7, IE8 pretending to be IE6, IE9 pretending to be IE8, IE9 pretending to be IE7, and so on as you change the tag to benefit from newer rendering modes. All those render modes will either use combined code, which means they won't render exactly as the old versions, or they are essentially multiple browsers in one, which means they'll each have their own security vulnerabilities and plugin incompatibilities.
This page is for IE7; deal with it
Added benefit for Microsoft: They get to write their own standards again. If another browser sees that made-for-IE7 tag, it must recreate all of IE7's quirks (and those of IE6 and IE8 and IE9...), i.e. behave like some closed source software from Microsoft. MS DOC deja vu...
I really hope that the other browser developers show MS the finger on this one, because if you thought browsers are memory hogs and security nightmares now, wait until every browser has to implement all its predecessors' quirks and all its predecessors' competitions' quirks.