Intels and AMDs new processors will continue to work on older Windows and Linux versions just like before. It is just that Microsoft has officially announced they are not going to backport new processor features to older operating system versions.
I don't think anyone expects Microsoft to reengineer previous versions of windows... backporting features..etc for free when they can charge your soul for those features in a new version of windows.
Some exerts from blog post:
"Through July 17, 2017, Skylake devices on the supported list will also be supported with Windows 7 and 8.1. During the 18-month support period, these systems should be upgraded to Windows 10 to continue receiving support after the period ends. "
"For example, Windows 10 will be the only supported Windows platform on Intelâ(TM)s upcoming âoeKaby Lakeâ silicon, Qualcommâ(TM)s upcoming âoe8996â silicon, and AMDâ(TM)s upcoming âoeBristol Ridgeâ silicon."
From wording of blog post Microsoft seems to be saying if you are using new hardware they won't support you. From my read this seems to be a separate issue from backporting new features and capabilities.. How else can you interpret them supporting you and then stop supporting you on same hardware after arbitrary date?
I fail to understood how large vendors feel they can get away with jerking their customers around.
When you go around retroactively proclaiming using x, y and z = no support 4U just for bullshit political reasons I guarantee your paying customers will take note of the fact they are being jerked around and not getting value they are paying for out of the deal.
Look at benefits, look at downsides. If the benefits > downsides then it's okay.
It rarely is okay. Most of the time same benefits can be derived in other ways without any of the downsides.
Like it or not the world is more complicated than "teh cloud is teh evil!!!"
Technology is neither good nor evil. The people wielding it are a different story.
As long as the "tech" market is fueled by the race to make everything free and monetize the user rather than making money by delivering value "teh cloud is teh evil" will remain a good enough approximation of reality.
I don't like the idea of cramming platters to increase density because it throws a wrench in useful scaling relationship between density and I/O rate. I don't want a disk requiring days to sync up or otherwise doubles time needed to read out a given percentage of the disk. This is what archival media is for.
Would much rather see R&D efforts focused on increasing density and therefore I/O performance of individual platters otherwise for my purposes better off simply buying more and scaling out disks.
If helium increases reliability over long term use then great.. if it lasts only as long as the warrantee period I'm not interested.
Hoping against hope something not resembling vaporware will come out of RRAM efforts like crossbar in the next year or two.
Decorating wishing wells, souvenir coin stamping currency defacement machines, purchasing love and half baked thoughts.
More and more transactions are done electronically these days - so you can keep your $x.99 pricing if you want, and if it's an electronic payment, you get charged the exact amount.
Consumers end up subsidizing (both sides of) all of those unnecessary transaction fees to the card companies. Material costs to mint coins represent rounding errors next to tens of billions in profits hoovered up in transaction fees.
Based on what evidence? What do you know about how any of this was leveraged or why it was done?
That being said, if they forcefully compel a company to allow backdoor into products,
What do you mean by force? Withholding contracts? Bribes? Vindictive leverage of regulatory sticks?
the government should be prepared accept all subsequent financial liability (that is, bail out the company) that would likely arise as a result of the would-be PR disaster.
LOL
No private company should stick their neck out for the government.
Is this a joke? Microsoft intentionally writing code to reset parameters people set to keep from being nagged into doing something they unambiguously indicated they want no part of?
Seems clear Microsoft neither wants nor deserve my business.
hashmd5(data) is weak. hashsha1(data) is weak. hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.
While this construction is wrong I never understood what the problem is with the general approach. The PRF in TLS is derived this way except they are not stacked but rather XOR'd together.
All justifications for not doing away with this I've ever read had been political rather than technical statements. This approach is not approved, untested, uncertain.. etc.
Assuming a sufficiently large block size what is the problem with a crapload of hash algorithms? Obviously defective algorithms pull down effective block size but if you have the margins what prevents this from being an effective insurance strategy? Especially if it is only used for key management/handshake and performance implications of duplicative work are nonexistent. Why not do it?
salt = newuuid(); final = salt + hashsha1(data + salt);
For storing hashes of data, this is a no-brainer. It also makes the second hash function unnecessary, providing a small, but measurable, performance boost.
Using salts is like publically apologizing for wrongdoing.
I've tried over the years to make people understand the simple truth only exponents can protect information. When you make something 1000 or 1000000 times harder this "sounds" like a worthwhile accomplishment but in reality it means very little especially if what you are protecting is worth anything to anyone.
If you feel you need to use salts to protect something you are doing that something a disservice by continuing with your current course of action.
The company I'm working for is undergoing some transitions and we needed a way to uniquely identify users without showing their personal information to everyone. I designed a system that uses some personal information (SSN, DOB), concatenates it into a string (whose composition is known to only a select few), and encrypts it using SHA1.
Your problem is not preimage resistance of SHA1 but the piss poor entropy of SSN + DOB.
If you want to do something like this at least use HMAC-SHA1 and try to keep the secret from falling into the wrong hands.
My question is this: Given this article and assuming that the hashes fell into the hands of someone who wanted to decrypt them, how long would it take to do so? Would it be hours? Months? Decades? Would having multiple hashes tell the would-be cracker anything about the structure of the decrypted string which might help shorten the decryption time? Or would they have to brute force each string until they got one decrypted?
None of this is relevant when the hashed data contains no meaningful entropy in the first place.
MERGE doesn't have proper concurrency semantics defined (see this for an example).
Not my problem MSSQL users have been brain damaged by the worthless default concurrency model of SQL Server.
If your going to use MERGE or any other statement to insert records based on data you've read then you damn well better have a plan to ensure consistency because it is NOT the databases job to do this for you.
If you are updating data based on data you've read then you damn well better have a plan to ensure consistency because it is NOT the databases job to do this for you.
Read locks are only an acceptable solution in trivial toy systems because they don't scale.
That's fine if you can do an exclusive table lock, or if you are doing a once-a-day upload at 3 AM. In that case you could do take a table lock in PostgreSQL, do an UPDATE in a CTE and then do an INSERT on any rows that were not successfully updated. That's pretty much all MERGE is.
All I care about is cross platform compatibility updating records. Given MERGE allows WHERE clause to be used with UPDATE I do not consider it to be defective in any way.
MSSQL and Oracle allow the same merge syntax to be used without modification. The more databases support MERGE the easier it is to support additional platforms.
Read this and be sick (I was)
This article is worthless as far as I'm concerned. There is a long history of errata with virtually every statement. It doesn't mean the statement is buggy or you will ever see any issues in real world usage.
Concurrency arguments are downright foolish and only realizable when you make the mistake of assuming a model stronger than MVCC. People who think it is rational to plant read locks or otherwise believe the data they read out EVER under ANY circumstance means anything in relation to subsequent changes regardless of transactional context are the problem not the syntax.
Trigger argument is equally worthless because trigger execution is managed by the database and calls are routinely coalesced to the transaction level for performance not the statement level as many blindly assume. This is merely a reflection of the ignorance of the author.
BTW there are other serious problems with MSSQL. I no longer consider it fit for purpose. I'd love to try postgres sometime.
To me personally MERGE syntax has value because it makes it easier to support multiple databases. What people chose to run is not my call, not my business. I don't care about opinions and feelings.
What I really would have liked to see is support for merge. MERGE is already supported by all of the platforms I care about. I don't even care about tradeoffs and syntax of 'UPSERT' schemes all I care about is one thing working across the board and MERGE is currently the closest to that.
All real-traffic testing of the major fully self driving cars projects (type Google) have concluded that they already are far safer in practice than manually driven cars.
I am not talking about fully self driving cars. I'm talking about half-assed features like lane assist and adaptive cruise that enable people to zone out and consequences of coupling this with unnecessary "infotainment"
I don't know whether anyone has yet to develop a competent self driving vehicle. For example does driving like granny or not counting accidents averted by humans babysitting self driving car prototypes count as a realistic test? I don't know what the state of the art is currently nor am I qualified to judge. All I know for sure is you can't buy anything approach a real self driving car from your local car dealer so the point is currently moot.
One can always discuss more or less theoretical "what if" scenarios (and I know that more than 80% of drivers considers themselves far better than the average driver), but that is what the overall statistics shows.
Again my comments are expressly not about the safety of fully autonomously piloted vehicles. It is about cars with limited automation that make it easier for people to zone out.
It isn't the price that pisses me off it is fact they must have known what price would be for quite some time. Lucky intentionally let the $350 expectation run unchallenged for all this time based on earlier statements until the bitter end when they knew full well it was a lie not even "virtually" close to "reality".
Who I really feel sorry for are all the devs who spent their time and energy alpha testing SDKs and developing content who are now royally fucked.
My interaction on the daily commute in heavy traffic is lane changes and turns or taking over in cases of bad weather. I don't abuse it and keep my hands on the wheel (it yells at me if I don't) but I have very little I have to do while in the traffic crawl on the highway and my car isn't one of the fancy ones like the
Having little to do is exactly what I'm afraid of. Making it worse by adding distracting crap to cars is priceless.
Tesla that can do much more. Right now it's just chilling to audiobooks, but we aren't that far from large periods of being completely interaction free.
On Tesla forums customers have complained about random turns that would have caused death/accident if they had not been paying attention after firmware update unlocked new self driving features.
If competent self driving cars exist I don't care if you turn the windows into vid screens, install a microwave oven in the glove box and fix breakfast while playing GTA with other fellow drivers on the way to work.
Until then coupling of half-assed automation schemes with unnecessary electronic gizmos is going to get people killed.
Ugh lets see 16-bit check space vs hosts and switches moving millions of packets per second.
Even if the 1's complient checksum implementation was not the crudest piece of shit imaginable routinely allowing bit flips to fly under the radar it wouldn't make any difference because the space is too damn small.
I've personally witnessed IP checksum fail to prevent corruption on multiple occasions due to faulty hardware.
If you have a better way to check packet integrity then go ahead and say it. Two requirements that the IP checksum has would be that it has to be computationally inexpensive since it is going to be implemented on whatever 8-bit microcontroller your doorbell uses and that it should be possible to rewrite the packet and update the checksum without having to recalculate it for the entire packet. You can assume that any CRC is too computationally intensive to be used. An XOR parity could be sufficient, but the checksum provides better checking without being more expensive.
Oh please, it isn't even a CRC. It is literally adding shit up and taking a compliment that's it. There are no tables, no position dependence no nothing. It is complete total and utter shit.
The *ONLY* reason data transmitted over the Internet is not corrupted left and right is implementation of useful error detection and correction schemes at the link layer.
This seems like it's people getting their panties in a bunch just to get their panties in a bunch.
Don't get me wrong, I'm all for individual privacy and keeping the government/corporations in check, but this is the modern day.
Oh hell its 2016 fuck it seems to be incompatible with giving a shit of any kind.
Everything you do in any digital format is about tracking you to make more dollars off you. This is the modern price for cheap software, before it was you get crap quality for discount items, now it's that you get (falsely believed) more efficient marketing.
How many customers are needed to support development of an operating system? Windows comes preinstalled on all new PCs whether you want it or not and there are *billions* of users. How the f*** can't they afford to develop Windows without ripping off the average bottom feeding malware/spyware vendor playbook?
More importantly how the f*** do they expect to keep billions of users once they have proven themselves to be morally bankrupt bottom feeders?
The thing is, the average/typical user doesn't CARE that any of this is taking place.
The average user does not KNOW that any of this is taking place. Ignorance is not the same as not caring. You can't care about encryption keys or spying when you have no clue what bitlocker or an encryption key is. You can't care if you turn off all the spy settings yet fail to take the step of collecting network capture which prove privacy options don't actually do all that much.
The relative minority who actually concern ourselves with online privacy rights are obviously not a crowd Microsoft really targets or cares much about. If it's that big a deal, you probably need to use something like Linux.
Privacy concerns exists independent of technical ability.
It doesn't specify a checksum for the header, which means that it relies on some elements of it (the address fields) to be checksummed by a higher layer (which indeed TCP and UDP do). But which also means that some elements of the header (quality of service, hop limit) are left out of the checksum, which means that (for instance) you can get router loops. But it's probably because the designers of IPv6 thought that the whole packet would be authenticated at layer 2. But then - why require an ICMP checksum when you've just completely redesigned ICMP (and why require the TCP and UDP checksums to still use a pseudo header)? I mean, calculating checksums costs time. Either specify that it happens at layer 2 and be done with it, or do it properly.
IP checksums are a joke which exist only for personal entertainment.
Well, for many of us, the notion that everything has a unique address which can be known by anybody else seems idiotic.
Having an outside entity know any information about your hosts and their IP addresses is just another vector to glean information and possibly act on it. You can't target a specific machine if you have no information about it from outside the firewall.
This is confusing because the word "NAT" is paraded around like "Cloud" in a mostly context free environment.
When people say don't use NAT what I assume they are actually referring to is many to one mappings where a single IP address is multiplexed and ALGs are required to make naive assumptions about state management.
The most public example of this is Linux netfilter guys saying in no uncertain terms NO to IPv6 NAT yet there are still map targets where IPv6 addresses can be mapped 1:1 across to other addresses.
You can still have a logical pool of addresses for external services mapped to internal resources without NAT even though it is NAT.
IPv6 seems to have a rather naive and in-built assumption that the internet isn't full of hostile assholes, and the decision to say that NAT was unnecessary reinforces that. Anything which assumes there isn't a risk in allowing outside actors to glean information about your environment is naive, broken, and not going to work. Because you pretty much need to assume that every additional item of information someone else has is going to be exploited in some way.
IPv6 gives us more options many of us didn't have before. Nobody is telling you to expose IP addresses directly associated with servers... All it really means is stop doing crummy 1:many mappings because it is dangerous, counterproductive and completely unnecessary given available address space.
If you need to rely on state-ful firewall rules to know what's allowed, you need to rely on the vendor to competently be able to handle all of these protocols and the like. And, quite frankly, time and time again we see plenty of reasons why we can't trust the vendors to competently do that.
You are relying on the vendor not to fuck up no matter what. The question is does it take more risk/code to implement SPI or to continue to mangle packets and tolerate ALGs with heuristic assumptions attackers can drive trucks thru?
This is one of the reasons a lot of organizations have looked at IPv6 and consistently said "no thanks, there's parts of this we really don't like".
All organizations have to do at some point is provide IPv6 connectivity for public facing services. That's it. They can keep IPv4 forever on their Internal networks for all anyone cares.
Slashdot Mirror
Intels and AMDs new processors will continue to work on older Windows and Linux versions just like before. It is just that Microsoft has officially announced they are not going to backport new processor features to older operating system versions.
I don't think anyone expects Microsoft to reengineer previous versions of windows... backporting features..etc for free when they can charge your soul for those features in a new version of windows.
Some exerts from blog post:
"Through July 17, 2017, Skylake devices on the supported list will also be supported with Windows 7 and 8.1. During the 18-month support period, these systems should be upgraded to Windows 10 to continue receiving support after the period ends. "
"For example, Windows 10 will be the only supported Windows platform on Intelâ(TM)s upcoming âoeKaby Lakeâ silicon, Qualcommâ(TM)s upcoming âoe8996â silicon, and AMDâ(TM)s upcoming âoeBristol Ridgeâ silicon."
From wording of blog post Microsoft seems to be saying if you are using new hardware they won't support you. From my read this seems to be a separate issue from backporting new features and capabilities.. How else can you interpret them supporting you and then stop supporting you on same hardware after arbitrary date?
I fail to understood how large vendors feel they can get away with jerking their customers around.
When you go around retroactively proclaiming using x, y and z = no support 4U just for bullshit political reasons I guarantee your paying customers will take note of the fact they are being jerked around and not getting value they are paying for out of the deal.
Look at benefits, look at downsides. If the benefits > downsides then it's okay.
It rarely is okay. Most of the time same benefits can be derived in other ways without any of the downsides.
Like it or not the world is more complicated than "teh cloud is teh evil!!!"
Technology is neither good nor evil. The people wielding it are a different story.
As long as the "tech" market is fueled by the race to make everything free and monetize the user rather than making money by delivering value "teh cloud is teh evil" will remain a good enough approximation of reality.
I don't like the idea of cramming platters to increase density because it throws a wrench in useful scaling relationship between density and I/O rate. I don't want a disk requiring days to sync up or otherwise doubles time needed to read out a given percentage of the disk. This is what archival media is for.
Would much rather see R&D efforts focused on increasing density and therefore I/O performance of individual platters otherwise for my purposes better off simply buying more and scaling out disks.
If helium increases reliability over long term use then great.. if it lasts only as long as the warrantee period I'm not interested.
Hoping against hope something not resembling vaporware will come out of RRAM efforts like crossbar in the next year or two.
LiFePo4 is inherently safe and will not catch fire or explode when overcharged, punctured, shot, dropped...etc.
When talking about big ass batteries why risk it for sake of marginal increase in energy density?
What do you even use a penny for?
Decorating wishing wells, souvenir coin stamping currency defacement machines, purchasing love and half baked thoughts.
More and more transactions are done electronically these days - so you can keep your $x.99 pricing if you want, and if it's an electronic payment, you get charged the exact amount.
Consumers end up subsidizing (both sides of) all of those unnecessary transaction fees to the card companies. Material costs to mint coins represent rounding errors next to tens of billions in profits hoovered up in transaction fees.
I think the NSA is doing what NSA needs to do.
Based on what evidence? What do you know about how any of this was leveraged or why it was done?
That being said, if they forcefully compel a company to allow backdoor into products,
What do you mean by force? Withholding contracts? Bribes? Vindictive leverage of regulatory sticks?
the government should be prepared accept all subsequent financial liability (that is, bail out the company) that would likely arise as a result of the would-be PR disaster.
LOL
No private company should stick their neck out for the government.
Have no fear CISA is here.
When you dim an LED bulb, the amount of light reduces, however the color temperature is the same.
No it isn't. One of many reasons displays use crappy PWMs to dim backlights.
Is this a joke? Microsoft intentionally writing code to reset parameters people set to keep from being nagged into doing something they unambiguously indicated they want no part of?
Seems clear Microsoft neither wants nor deserve my business.
hashmd5(data) is weak.
hashsha1(data) is weak.
hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.
While this construction is wrong I never understood what the problem is with the general approach. The PRF in TLS is derived this way except they are not stacked but rather XOR'd together.
All justifications for not doing away with this I've ever read had been political rather than technical statements. This approach is not approved, untested, uncertain.. etc.
Assuming a sufficiently large block size what is the problem with a crapload of hash algorithms? Obviously defective algorithms pull down effective block size but if you have the margins what prevents this from being an effective insurance strategy? Especially if it is only used for key management/handshake and performance implications of duplicative work are nonexistent. Why not do it?
Even Better, although I used SHA512 myself.
salt = cryptorand.getbbytes(64);
final = salt +HMACSHA1(data,salt);
What good is the HMAC in this case?
salt = newuuid();
final = salt + hashsha1(data + salt);
For storing hashes of data, this is a no-brainer. It also makes the second hash function unnecessary, providing a small, but measurable, performance boost.
Using salts is like publically apologizing for wrongdoing.
I've tried over the years to make people understand the simple truth only exponents can protect information. When you make something 1000 or 1000000 times harder this "sounds" like a worthwhile accomplishment but in reality it means very little especially if what you are protecting is worth anything to anyone.
If you feel you need to use salts to protect something you are doing that something a disservice by continuing with your current course of action.
The company I'm working for is undergoing some transitions and we needed a way to uniquely identify users without showing their personal information to everyone. I designed a system that uses some personal information (SSN, DOB), concatenates it into a string (whose composition is known to only a select few), and encrypts it using SHA1.
Your problem is not preimage resistance of SHA1 but the piss poor entropy of SSN + DOB.
If you want to do something like this at least use HMAC-SHA1 and try to keep the secret from falling into the wrong hands.
My question is this: Given this article and assuming that the hashes fell into the hands of someone who wanted to decrypt them, how long would it take to do so? Would it be hours? Months? Decades? Would having multiple hashes tell the would-be cracker anything about the structure of the decrypted string which might help shorten the decryption time? Or would they have to brute force each string until they got one decrypted?
None of this is relevant when the hashed data contains no meaningful entropy in the first place.
MERGE doesn't have proper concurrency semantics defined (see this for an example).
Not my problem MSSQL users have been brain damaged by the worthless default concurrency model of SQL Server.
If your going to use MERGE or any other statement to insert records based on data you've read then you damn well better have a plan to ensure consistency because it is NOT the databases job to do this for you.
If you are updating data based on data you've read then you damn well better have a plan to ensure consistency because it is NOT the databases job to do this for you.
Read locks are only an acceptable solution in trivial toy systems because they don't scale.
That's fine if you can do an exclusive table lock, or if you are doing a once-a-day upload at 3 AM. In that case you could do take a table lock in PostgreSQL, do an UPDATE in a CTE and then do an INSERT on any rows that were not successfully updated. That's pretty much all MERGE is.
All I care about is cross platform compatibility updating records. Given MERGE allows WHERE clause to be used with UPDATE I do not consider it to be defective in any way.
Well, kind of, if you mean MSSQL.
MSSQL and Oracle allow the same merge syntax to be used without modification. The more databases support MERGE the easier it is to support additional platforms.
Read this and be sick (I was)
This article is worthless as far as I'm concerned. There is a long history of errata with virtually every statement. It doesn't mean the statement is buggy or you will ever see any issues in real world usage.
Concurrency arguments are downright foolish and only realizable when you make the mistake of assuming a model stronger than MVCC. People who think it is rational to plant read locks or otherwise believe the data they read out EVER under ANY circumstance means anything in relation to subsequent changes regardless of transactional context are the problem not the syntax.
Trigger argument is equally worthless because trigger execution is managed by the database and calls are routinely coalesced to the transaction level for performance not the statement level as many blindly assume. This is merely a reflection of the ignorance of the author.
BTW there are other serious problems with MSSQL. I no longer consider it fit for purpose. I'd love to try postgres sometime.
To me personally MERGE syntax has value because it makes it easier to support multiple databases. What people chose to run is not my call, not my business. I don't care about opinions and feelings.
What I really would have liked to see is support for merge. MERGE is already supported by all of the platforms I care about. I don't even care about tradeoffs and syntax of 'UPSERT' schemes all I care about is one thing working across the board and MERGE is currently the closest to that.
It's a good thing Guido discovered the need for padding when riding bicycles because you could fall and hurt your head.
All real-traffic testing of the major fully self driving cars projects (type Google) have concluded that they already are far safer in practice than manually driven cars.
I am not talking about fully self driving cars. I'm talking about half-assed features like lane assist and adaptive cruise that enable people to zone out and consequences of coupling this with unnecessary "infotainment"
I don't know whether anyone has yet to develop a competent self driving vehicle. For example does driving like granny or not counting accidents averted by humans babysitting self driving car prototypes count as a realistic test? I don't know what the state of the art is currently nor am I qualified to judge. All I know for sure is you can't buy anything approach a real self driving car from your local car dealer so the point is currently moot.
One can always discuss more or less theoretical "what if" scenarios (and I know that more than 80% of drivers considers themselves far better than the average driver), but that is what the overall statistics shows.
Again my comments are expressly not about the safety of fully autonomously piloted vehicles. It is about cars with limited automation that make it easier for people to zone out.
It isn't the price that pisses me off it is fact they must have known what price would be for quite some time. Lucky intentionally let the $350 expectation run unchallenged for all this time based on earlier statements until the bitter end when they knew full well it was a lie not even "virtually" close to "reality".
Who I really feel sorry for are all the devs who spent their time and energy alpha testing SDKs and developing content who are now royally fucked.
My interaction on the daily commute in heavy traffic is lane changes and turns or taking over in cases of bad weather. I don't abuse it and keep my hands on the wheel (it yells at me if I don't) but I have very little I have to do while in the traffic crawl on the highway and my car isn't one of the fancy ones like the
Having little to do is exactly what I'm afraid of. Making it worse by adding distracting crap to cars is priceless.
Tesla that can do much more. Right now it's just chilling to audiobooks, but we aren't that far from large periods of being completely interaction free.
On Tesla forums customers have complained about random turns that would have caused death/accident if they had not been paying attention after firmware update unlocked new self driving features.
If competent self driving cars exist I don't care if you turn the windows into vid screens, install a microwave oven in the glove box and fix breakfast while playing GTA with other fellow drivers on the way to work.
Until then coupling of half-assed automation schemes with unnecessary electronic gizmos is going to get people killed.
In what way?
Ugh lets see 16-bit check space vs hosts and switches moving millions of packets per second.
Even if the 1's complient checksum implementation was not the crudest piece of shit imaginable routinely allowing bit flips to fly under the radar it wouldn't make any difference because the space is too damn small.
I've personally witnessed IP checksum fail to prevent corruption on multiple occasions due to faulty hardware.
If you have a better way to check packet integrity then go ahead and say it.
Two requirements that the IP checksum has would be that it has to be computationally inexpensive since it is going to be implemented on whatever 8-bit microcontroller your doorbell uses and that it should be possible to rewrite the packet and update the checksum without having to recalculate it for the entire packet.
You can assume that any CRC is too computationally intensive to be used.
An XOR parity could be sufficient, but the checksum provides better checking without being more expensive.
Oh please, it isn't even a CRC. It is literally adding shit up and taking a compliment that's it. There are no tables, no position dependence no nothing. It is complete total and utter shit.
The *ONLY* reason data transmitted over the Internet is not corrupted left and right is implementation of useful error detection and correction schemes at the link layer.
This seems like it's people getting their panties in a bunch just to get their panties in a bunch.
Don't get me wrong, I'm all for individual privacy and keeping the government/corporations in check, but this is the modern day.
Oh hell its 2016 fuck it seems to be incompatible with giving a shit of any kind.
Everything you do in any digital format is about tracking you to make more dollars off you. This is the modern price for cheap software, before it was you get crap quality for discount items, now it's that you get (falsely believed) more efficient marketing.
How many customers are needed to support development of an operating system? Windows comes preinstalled on all new PCs whether you want it or not and there are *billions* of users. How the f*** can't they afford to develop Windows without ripping off the average bottom feeding malware/spyware vendor playbook?
More importantly how the f*** do they expect to keep billions of users once they have proven themselves to be morally bankrupt bottom feeders?
The thing is, the average/typical user doesn't CARE that any of this is taking place.
The average user does not KNOW that any of this is taking place. Ignorance is not the same as not caring. You can't care about encryption keys or spying when you have no clue what bitlocker or an encryption key is. You can't care if you turn off all the spy settings yet fail to take the step of collecting network capture which prove privacy options don't actually do all that much.
The relative minority who actually concern ourselves with online privacy rights are obviously not a crowd Microsoft really targets or cares much about. If it's that big a deal, you probably need to use something like Linux.
Privacy concerns exists independent of technical ability.
It doesn't specify a checksum for the header, which means that it relies on some elements of it (the address fields) to be checksummed by a higher layer (which indeed TCP and UDP do). But which also means that some elements of the header (quality of service, hop limit) are left out of the checksum, which means that (for instance) you can get router loops. But it's probably because the designers of IPv6 thought that the whole packet would be authenticated at layer 2. But then - why require an ICMP checksum when you've just completely redesigned ICMP (and why require the TCP and UDP checksums to still use a pseudo header)? I mean, calculating checksums costs time. Either specify that it happens at layer 2 and be done with it, or do it properly.
IP checksums are a joke which exist only for personal entertainment.
Well, for many of us, the notion that everything has a unique address which can be known by anybody else seems idiotic.
Having an outside entity know any information about your hosts and their IP addresses is just another vector to glean information and possibly act on it. You can't target a specific machine if you have no information about it from outside the firewall.
This is confusing because the word "NAT" is paraded around like "Cloud" in a mostly context free environment.
When people say don't use NAT what I assume they are actually referring to is many to one mappings where a single IP address is multiplexed and ALGs are required to make naive assumptions about state management.
The most public example of this is Linux netfilter guys saying in no uncertain terms NO to IPv6 NAT yet there are still map targets where IPv6 addresses can be mapped 1:1 across to other addresses.
You can still have a logical pool of addresses for external services mapped to internal resources without NAT even though it is NAT.
IPv6 seems to have a rather naive and in-built assumption that the internet isn't full of hostile assholes, and the decision to say that NAT was unnecessary reinforces that. Anything which assumes there isn't a risk in allowing outside actors to glean information about your environment is naive, broken, and not going to work. Because you pretty much need to assume that every additional item of information someone else has is going to be exploited in some way.
IPv6 gives us more options many of us didn't have before. Nobody is telling you to expose IP addresses directly associated with servers... All it really means is stop doing crummy 1:many mappings because it is dangerous, counterproductive and completely unnecessary given available address space.
If you need to rely on state-ful firewall rules to know what's allowed, you need to rely on the vendor to competently be able to handle all of these protocols and the like. And, quite frankly, time and time again we see plenty of reasons why we can't trust the vendors to competently do that.
You are relying on the vendor not to fuck up no matter what. The question is does it take more risk/code to implement SPI or to continue to mangle packets and tolerate ALGs with heuristic assumptions attackers can drive trucks thru?
This is one of the reasons a lot of organizations have looked at IPv6 and consistently said "no thanks, there's parts of this we really don't like".
All organizations have to do at some point is provide IPv6 connectivity for public facing services. That's it. They can keep IPv4 forever on their Internal networks for all anyone cares.