Let me know your admin's name, so I can contract him to do some work, then stiff him when it's time to get paid. Hell, if I can't get a linux admin to work for me for free, I'll just stiff them rather than give them a dime.
Oh, I don't know. How about a new one? You don't seem to get the fact that free (the ability to do something) and free (costs nothing) aren't the same thing. It would not be that hard to make a new license that allowed you to re-distribute the code (with or without modifications), but not without cost. Really, is that a difficult concept?
No, they didn't. The entitlement of this country is just insane. Read your contract. The government isn't there to save you from your own laziness and/or stupidity. Take responsibility for your own actions. I don't want to pay for a government that has to watch everything you do to make sure you don't do something stupid.
every carrier, now save 1, is capping data at 5GB/month
No, there are plenty of carriers that will let you use more than 5GB/month, however, it isn't FREE. Big difference. It's amazing how much people whine when they actually have to pay for stuff they want to use.
Yes, I do it every single day, every day. Have you ever tried upgrading from a 10+ year old OS or are you going to continue complaining that Fords suck because you STILL can't get your model T up to highway speeds.
Sorry, impossible to guarantee. In most cases it will work just fine, but I wouldn't want to explain to the people that happen to have collisions why they can't shop/use the software/shop at the store.
Of course, a larger underlying problem is that credit card numbers are so short (Strip the first 4 digits that basically tell you who issued it, and the last digit which is a checksum) being only 11 digits of useful information, you can easily create a rainbow table to reverse any encryption or hash you do very quickly if you know what technique was used to hash or what the public encryption key, which completely invalidates the "Must not store credit card information" except for all but the most useless hacking attempts.
Not exactly. Hash functions, by their very design allow for collisions, encryption keys do not. Since you want to take credit cards numbers (Which *aren't* really arbitrary input) and turn them into a UNIQUE number, hashing is not what you want to do. You want encryption.
Generate an encryption key, and toss away (or simply do not generate) the decryption key.
sqrt(2^64)=4294967296 2^53=9007199254740992
I'm not sure sqrt(2^n) is correct for the expected number of collisions, and 2^53 definately isn't the number of credit card numbers, but assuming those two things as given by you, you are going to have a lot of collisions, which makes identifying a unique person using a MD5 hash of someones credit card numbers impossible.
I'm not a cryptographic expert, but ones that are said "two weak input differences are able to find a collision within 2^10 MD5 compressions. In particular, a 2-bit weak input difference is found to be able to construct a practical 1-block collision attack on MD5."
If I read this correctly, MD5 shows my point exactly. Using MD5 with credit card numbers (Often of which can be within 2-bits of difference of each other), you will likely find 2^43 collisions within the range of legal credit card numbers. Based on my own experiences with MD5, I can vogue for the likelihood of collisions with short inputs, so while this number does seem larger than I would expect, it doesn't completely surprise me.
As a side note, using a 128-bit hashing function on a 53-bit input really isn't hashing. It's poor implementation of encryption using known keys that has probable data loss/corruption.
Fail. Hashes aren't guaranteed to be unique for differing inputs. That's a terrible technique and one I hope no one with half a brain tries to implement.
On a side note about WebGL: The specification was released just 12 days ago, and quick test with all the latest (released) major browsers (As tested with http://www.doesmybrowsersupportwebgl.com/):
Well except, let's see: Android (up to 2.3) doesn't support even basic SVG.
SVG Effects for HTML: Buggy in FF 3.0, Not supported in Safari 3.2 at all, buggy in 4.0+, Buggy in Chrome (Up to 12.0), buggy in Opera (Up to 11.5), Buggy in iOS (Up to 4.2), not supported at all in Opera Mini (Up to 5.0), Buggy in Opera Mobile (Up to 10.0), Not supported in Android Browser (Up to 2.3).
SVG filters: Not supported in safari (Up to 5.0), Buggy in Chrome (Up to 12.0), Not supported in iOS (Up to 4.2), Not supported in android.
SVG support in img tag: Supported in IE 9.0. Not supported in FF (Up to 3.6), Buggy in safari 3.2, buggy in iOS 3.2, not supported in android.
SVG in CSS backgrounds: Supported in IE 9.0, Not supported in FF (Up to 3.6), Buggy in safari up to 4.0, buggy in iOS, not supported in android.
SVG SMIL animation: Not supported in IE, FF (up to 3.6), Safari (up to 3.2), Opera Mini, Android. Buggy in Safari 4.0, iOS.
SVG fonts: Not supported in IE, FF, Opera Mini, Android.
Inline SVG: Not supported in IE (up to 8.0), FF (Up to 3.6), Safari (Up to 5.0), iOS, Opera Mini, Opera Mobile, Android.
Somehow, this doesn't look like "All browsers except IE" have had complete support for SVG for the past 10 years.
I would agree with you if IE was the only one like that, however, NOT A SINGLE BROWSER implements all of the standards (HTML5, CSS3, etc). All of them have bugs, and all of them take a very very long time to correct them when they are found.
I currently have bugs submitted to webkit, chrome, firefox, and the IE team. I don't even both with opera, there are just too many. All of them have been reproduced, none of them fixed, and most are 1+ years old and still buggy in the latest versions of the browsers.
P.S. Perhaps you need a refresher on what ad hominem means.
Nothing I said was in any way a personal attack, nor did I try and say anything about your personal conduct, character, or motives. If you however took what I said to mean that you think like a 3 year old, you've assumed something that wasn't there. However, perhaps that does say something about you after all.
Just because something is private, does not mean only one person knows it. Just because something is public also does mean that everyone knows it.
My name is not private (it is public), however, I'd be surprised if you know it. Not everything is black and white, nor does everything work exactly the way mom and dad told you how it worked when you were 3.
No, and he is correct. Just because you have "freedom of speech" does not automatically imply that there will be consequences for saying such things. There are many things that are quite illegal to say (hate speech, distributing things covered by national security, in sighting a riot, etc).
(...) Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user. (...)
Seems to cover login cookies, as they are "strictly necessary" to give you the service you registered for.
Thanks for proving my point. Now just wait for the inevitable lawsuit to be put forth proving that you don't need any kind of cookie to provide said service (say, such as using a unique/encrypted seed as part of the query string in the URLS), and presto! You have exactly what I just said.
That's like saying that companies should be stopped from putting cameras in every street because people can't be bothered to use face-covering hats.
Are you suggesting that it should be illegal for traffic cameras, ATM cameras, in store cameras, etc? lol.
Not to mention, it's impossible for the user to distinguish between a tracking cookie and a login or preferences cookie.
That is because they are exactly the same thing. Only difference is how they are used. I'm quite sure the EU will be incompetent enough to make both illegal.
Slashdot Mirror
Let me know your admin's name, so I can contract him to do some work, then stiff him when it's time to get paid. Hell, if I can't get a linux admin to work for me for free, I'll just stiff them rather than give them a dime.
Oh, I don't know. How about a new one? You don't seem to get the fact that free (the ability to do something) and free (costs nothing) aren't the same thing. It would not be that hard to make a new license that allowed you to re-distribute the code (with or without modifications), but not without cost. Really, is that a difficult concept?
The GPL isn't the only FOSS license.
No, they didn't. The entitlement of this country is just insane. Read your contract. The government isn't there to save you from your own laziness and/or stupidity. Take responsibility for your own actions. I don't want to pay for a government that has to watch everything you do to make sure you don't do something stupid.
every carrier, now save 1, is capping data at 5GB/month
No, there are plenty of carriers that will let you use more than 5GB/month, however, it isn't FREE. Big difference. It's amazing how much people whine when they actually have to pay for stuff they want to use.
ROFL
Thieves can (mostly) be replaced as well.
i wouldn't be surprised to find that linux actually outnumbers windows quite considerably
WOW. Live in your own little make believe world do you?
Supercomputers - 80-90% running linux is still high, but seriously, it's easier to grab computing cycles from many desktop computers, turning them into a "supercomputer" with more computing power than all the top500 supercomputers combined than trying to infect one and keep it infected while you steal all those cpu cycles.
Linux servers get hacked all the time, but you would know that if you actually ran one. See: http://www.chkrootkit.org/
Phones get malware: http://mobile.slashdot.org/story/11/03/06/202208/Google-Finally-Uses-Remote-Kill-Switch-On-Malware?from=rss
Embedded Linux: Nope, not safe here either: http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=154392
Yes, I do it every single day, every day. Have you ever tried upgrading from a 10+ year old OS or are you going to continue complaining that Fords suck because you STILL can't get your model T up to highway speeds.
Using your logic, the lady who lost $2,000 to an email scam isn't an idiot. Not until she loses $2,000 to another email scam to the same guy.
Sorry, impossible to guarantee. In most cases it will work just fine, but I wouldn't want to explain to the people that happen to have collisions why they can't shop/use the software/shop at the store.
Of course, a larger underlying problem is that credit card numbers are so short (Strip the first 4 digits that basically tell you who issued it, and the last digit which is a checksum) being only 11 digits of useful information, you can easily create a rainbow table to reverse any encryption or hash you do very quickly if you know what technique was used to hash or what the public encryption key, which completely invalidates the "Must not store credit card information" except for all but the most useless hacking attempts.
Not exactly. Hash functions, by their very design allow for collisions, encryption keys do not. Since you want to take credit cards numbers (Which *aren't* really arbitrary input) and turn them into a UNIQUE number, hashing is not what you want to do. You want encryption.
Generate an encryption key, and toss away (or simply do not generate) the decryption key.
sqrt(2^64)=4294967296
2^53=9007199254740992
I'm not sure sqrt(2^n) is correct for the expected number of collisions, and 2^53 definately isn't the number of credit card numbers, but assuming those two things as given by you, you are going to have a lot of collisions, which makes identifying a unique person using a MD5 hash of someones credit card numbers impossible.
>>>IsoHunt willy facilitates copyright infringement a
WRONG
Oh. So you are saying they don't facilitate copyright infringement?
just providing links
Oh. So they are facilitating copyright infringement. What was your point?
I'm not a cryptographic expert, but ones that are said "two weak input differences are able to find a collision within 2^10 MD5
compressions. In particular, a 2-bit weak input difference is found to be able to construct a practical 1-block collision attack on MD5."
If I read this correctly, MD5 shows my point exactly. Using MD5 with credit card numbers (Often of which can be within 2-bits of difference of each other), you will likely find 2^43 collisions within the range of legal credit card numbers. Based on my own experiences with MD5, I can vogue for the likelihood of collisions with short inputs, so while this number does seem larger than I would expect, it doesn't completely surprise me.
As a side note, using a 128-bit hashing function on a 53-bit input really isn't hashing. It's poor implementation of encryption using known keys that has probable data loss/corruption.
Fail. Hashes aren't guaranteed to be unique for differing inputs. That's a terrible technique and one I hope no one with half a brain tries to implement.
On a side note about WebGL: The specification was released just 12 days ago, and quick test with all the latest (released) major browsers (As tested with http://www.doesmybrowsersupportwebgl.com/):
Safari: Fail.
Firefox: Fail.
Opera: Fail.
Chome: Pass.
IE: Untested - I assume Fail.
This does NOT constitute all major browsers. This is ONE browser currently supports it.
Well except, let's see:
Android (up to 2.3) doesn't support even basic SVG.
SVG Effects for HTML: Buggy in FF 3.0, Not supported in Safari 3.2 at all, buggy in 4.0+, Buggy in Chrome (Up to 12.0), buggy in Opera (Up to 11.5), Buggy in iOS (Up to 4.2), not supported at all in Opera Mini (Up to 5.0), Buggy in Opera Mobile (Up to 10.0), Not supported in Android Browser (Up to 2.3).
SVG filters: Not supported in safari (Up to 5.0), Buggy in Chrome (Up to 12.0), Not supported in iOS (Up to 4.2), Not supported in android.
SVG support in img tag: Supported in IE 9.0. Not supported in FF (Up to 3.6), Buggy in safari 3.2, buggy in iOS 3.2, not supported in android.
SVG in CSS backgrounds: Supported in IE 9.0, Not supported in FF (Up to 3.6), Buggy in safari up to 4.0, buggy in iOS, not supported in android.
SVG SMIL animation: Not supported in IE, FF (up to 3.6), Safari (up to 3.2), Opera Mini, Android. Buggy in Safari 4.0, iOS.
SVG fonts: Not supported in IE, FF, Opera Mini, Android.
Inline SVG: Not supported in IE (up to 8.0), FF (Up to 3.6), Safari (Up to 5.0), iOS, Opera Mini, Opera Mobile, Android.
Somehow, this doesn't look like "All browsers except IE" have had complete support for SVG for the past 10 years.
I would agree with you if IE was the only one like that, however, NOT A SINGLE BROWSER implements all of the standards (HTML5, CSS3, etc). All of them have bugs, and all of them take a very very long time to correct them when they are found.
I currently have bugs submitted to webkit, chrome, firefox, and the IE team. I don't even both with opera, there are just too many. All of them have been reproduced, none of them fixed, and most are 1+ years old and still buggy in the latest versions of the browsers.
P.S. Perhaps you need a refresher on what ad hominem means.
Nothing I said was in any way a personal attack, nor did I try and say anything about your personal conduct, character, or motives. If you however took what I said to mean that you think like a 3 year old, you've assumed something that wasn't there. However, perhaps that does say something about you after all.
Just because something is private, does not mean only one person knows it. Just because something is public also does mean that everyone knows it.
My name is not private (it is public), however, I'd be surprised if you know it. Not everything is black and white, nor does everything work exactly the way mom and dad told you how it worked when you were 3.
No. But a jury can.
No, and he is correct. Just because you have "freedom of speech" does not automatically imply that there will be consequences for saying such things. There are many things that are quite illegal to say (hate speech, distributing things covered by national security, in sighting a riot, etc).
(...) Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user. (...)
Seems to cover login cookies, as they are "strictly necessary" to give you the service you registered for.
Thanks for proving my point. Now just wait for the inevitable lawsuit to be put forth proving that you don't need any kind of cookie to provide said service (say, such as using a unique/encrypted seed as part of the query string in the URLS), and presto! You have exactly what I just said.
Electrons have a negatively charged flavor, so they taste like crap.
That's like saying that companies should be stopped from putting cameras in every street because people can't be bothered to use face-covering hats.
Are you suggesting that it should be illegal for traffic cameras, ATM cameras, in store cameras, etc? lol.
Not to mention, it's impossible for the user to distinguish between a tracking cookie and a login or preferences cookie.
That is because they are exactly the same thing. Only difference is how they are used. I'm quite sure the EU will be incompetent enough to make both illegal.