Ask most people why they use places like Facebook. The typical answers that don't mention some stupid "feature" are the ones that say "everyone uses Facebook" (no they don't, but some people think enough people do). The reality is the "old internet" just didn't have the dilution of lower IQ mases. When someone was "wrong on the internet" that usually meant there could be some intelligence in the long running debate.
Both of these seem lost to me, by failing to even display a page at all on a browser a little more than a year old that supports ratified standards. They haven't even heard of graceful degrade? I sure would not put my stuff there.
Yeah, I keep this old browser to test sites and see just how useless they are. But 99% of sites still work fine.
For the most part, I agree with you. Maybe it's just me, but there is one style aspect that does not follow this. AndThatIsThatISimplyCannotReadCamelCase. Well, at least not very fast. And for code, I do need to be able to read fast. I also find CamelCase harder to type. So I need more lower case and the spaces. And underline characters are sufficient as a substitute for a space in several languages.
So if I were to take a programming job, I would need to check in advance what their style standard is.
Just saying... I think it is an utterly stupid idea. It is doomed to fail because it is too complex and uses too many things that can fail. And I do agree with you. More often than not, guns save lives without ever being fired. And just because guns are known to be common, criminals will flee even if they hear a homeowner wake up during a burglary, just because she might have a gun and might have it loaded and might even know how to use it. A scary thought to a burglar, right?
And these events never get told by the media... burglar tries to break in a home... owner turns on lights... burglar flees... homeowner finds nothing... homeowner does not call police... media never hears about it happening (as if it would matter to them).
If they can really seriously make this work reliably... which means sitting in a drawer for 10 years and always works for everyone... then I am interested... not because I'd use it on my guns (I still won't)... but because something technological has become more reliable than anything else. Eh, never happen.
Why do you think it is Linux's fault that the program had a segmentation fault?
Let's get the perspective right. The programmers at game companies are simply not experienced enough at writing good code to make sure it is reliable on a "new to them" platform. If it bugs out on Windows, they are used to that. But they are NOT writing proper portable code. So they have to write a bunch of NEW code just to go on Linux, given the bad way they have everything structured. Then they don't know what to do to debug it.
It's not Linux's fault these guys are not experienced with Linux.
There are two ways to verify a client that is connecting with some private key. The more commonly known method involves the client providing its signed public key, and verifying the signature (a use of the signer's private key) against its known and trusted public key. Then it is assumed if the trusted signer signed this user public key, then the signer trusted the user, and so the server can trust the user as well. The less commonly known method involves the server having a copy of the user public key, and keeping that copy in the context of users it trusts. Signatures are not involved. The server simply checks if the two keys it has are corresponding pairs.
There are two examples of the latter method being used. The lesser well known is "mode 3" verification in the "stunnel" program. The more well known is the "authorized_keys" list per user in "ssh".
The first method is more appropriate for web access where it is not practical for each user to keep a list of trusted web sites given the vast numbers user may access. But it is possible to do that. You do that by accepting the site key the first time you visit. Future visits verify keys using the stored public key that was previously trusted.
The second method is actually more appropriate for services where all users must be trusted enough to connect, such as ssh. The server needs to trust the client (but trust the other way is good, too). However, the second method should already have been in use for services like POP3 and IMAP.
The second method is done simply by providing you own public key through a channel which the server can verify the user by another means (login by password over HTTPS for example), and keep that public key as part of the user credentials. It, like a password, can also be changed at any time. Signed certificates are not needed. Signatures are not involved.
The things I heard on TV news this evening about how his mother was treating him was the people with Asperger's Syndrome hate being treated. They want to be accepted for who they are and what they are. They don't want someone trying to make them different.
Or maybe he was just pissed because DSM-IV recently deleted AS.
Cox has software? Ask them for the Linux version. They will ask you to use Windows. Your tell them you need Linux for the security. They will ask you why you need security. Tell them it's to keep bad companies from messing with your web browsing.
Surf using HTTPS only. Not all web sites over this, yet. But more and more complaints to them about their lack of support for secure communications could get more to see the need.
Use an offsite provy via a secure vpn/ssh. Rent a VPS for a few more a month (VPS providers are not known to be doing this, yet). Or rent one of those free-for-a-year micro instances at a cloud provider and run your own proxy and connect via ssh.
Nothing is gained by this. You still need to be able to decrypt in the process. And the database is part of the process. This is just silliness for manager to get brownie points.
The central database itself does not need to encrypted (doing so just means the decryption key has to be there, making the encryption pointless). It needs to be secured against any means of access that does not go through the process (locked building, restricted physical access to data center, armed guards, no internet access to that whole room, etc). Thieves should not be able to get in there at all.
But any data being stored outside needs to be encrypted, and have data compartmentalization on that. There should be no data usable by anyone that steals it. The access process itself should never let the data be outside of its control (it encrypts it if the data goes to storage... or just prevents it from being stored). Such devices need to have encrypted swap, if any at all.
It should say that SSN is nothing more than identity (as if pointing at a person). It should specifically say that anyone (individual, business, or corporation) who assumes than an SSN is AUTHORIZATION shall be CRIMINALLY (as well as civilly) liable for having committed a crime of fraud upon the identified person.
Encapsulate and isolate. The work devices should be used for work function, only. No PERSONAL surfing. In addition to that, all devices with access to sensitive data shall be completely separate from devices that can access the internet. The database itself must be fully secured. It does not need to store data encrypted, since it would just need to have keys to function. The data is going to be decrypted under process control. What needs to happen is to identify where process control can be bypassed. The glaring example is someone with access to the data on a laptop or tablet AND store the data there. The device can be stolen and access by NON-process means is possible (direct disk dump, for example). THIS is where the data needs to be encrypted with the key NOT stored on the device.
In the case of the South Carolina breach, the central database is not the issue. The PC that let someone into the data is the issue.
We should put the blame on a business/legal system that makes the false assumption that only the person identified by some number actually has or knows that number. Since we have to give out SSNs to so many places, our system needs to assume that by having the number, it in no way means the holder of the number is the person identified by it. An SSN is IDENTITY ONLY. It is NOT AUTHORIZATION, ever. It should be impossible for someone to open a bank account in someone ELSE's name. While that is a violation under existing law, it needs to be made equally liable on BOTH parties. If a bank is willing to open such an account, they MUST also be willing to accept the real person's say-so that it is not their account, and completely drop it, and pay the real person for all the damages and costs... and not be required to be sued to get it. If they refuse and fail to prove that the identified person is lying, it's jail time, baby.
FYI, jail time for a company does not need to mean a PERSON at the company is jailed. It should mean the company itself is jailed... shut down and non-operational. If it was a real person doing business, they cannot serve their customers while in jail. So the excuse "we need to have this company" operating does not fly. Shut the bank down for a week if they violate a law where, if a real individual had done so would land that individual in jail for a week.
All those businesses and government agencies that allow merely having data, like that which was taken in this case, The fact that I can walk into any bank and open an account in YOUR NAME just because I have YOUR SSN does not mean that I AM YOU. But the vast majority of banks make that assumption. Lots of other businesses types make this kind of assumption, too. Many have expressly even said so. "This account has your SSN, so it must be your account".
The first law we need to have is one that allows people to deny an account. When they do, the only option for the business involved it so actually prove that PERSON (not someone who had their number) was the one that really opened it, or charged it, or whatever. If the named person asserts that it was not them (penalty of perjury, signed), then it must be disassociated with them everywhere immediately, as if it never happened. The only recourse to undo that is prove the named person lied by proving they actually did open the account or whatever was involved. And this law will clearly state that it must be the person, and not their numbers. And this law would have criminal penalties and jail time for anyone that still does stuff like trying to collect debts on this from the person so named once they assert it is not them.
The system of business we use should not, in any way, and under any circumstance, make ID theft be able to cause any harm to whoever's ID was taken. Things like an SSN should be nothing more than information to refer to a person, and not any indication of authorization.
I would agree. And it starts with taking over the users machine. Once that happens, all bets are off if that user had access rights to the data by some machine. Whether the data (elsewhere) was stored encrypted or not doesn't even matter. If this person had such access it would have to include decrypting it by some means and by that he would give the new owner of his machine full access to the data, too... even if it wasn't on the same day he clicked the email. Both email reading and web browsing should never, ever, have any means to run any software on the machine. Ideally, people who do have such access should be doing that entirely on machines dedicated to that access which do nothing else (no mail reader, no web browser, etc).
The impact of holding down labor costs is that income of the market is going down. It means fewer people can afford to buy your product. That means your market is getting smaller. You'll have to reduce the scale of your business. And that means you'll have to cut costs even more. And you know what that leads to.
Slashdot Mirror
Some day they will track him down.
AOL had a version of the internet?
Ask most people why they use places like Facebook. The typical answers that don't mention some stupid "feature" are the ones that say "everyone uses Facebook" (no they don't, but some people think enough people do). The reality is the "old internet" just didn't have the dilution of lower IQ mases. When someone was "wrong on the internet" that usually meant there could be some intelligence in the long running debate.
Both of these seem lost to me, by failing to even display a page at all on a browser a little more than a year old that supports ratified standards. They haven't even heard of graceful degrade? I sure would not put my stuff there.
Yeah, I keep this old browser to test sites and see just how useless they are. But 99% of sites still work fine.
For the most part, I agree with you. Maybe it's just me, but there is one style aspect that does not follow this. AndThatIsThatISimplyCannotReadCamelCase. Well, at least not very fast. And for code, I do need to be able to read fast. I also find CamelCase harder to type. So I need more lower case and the spaces. And underline characters are sufficient as a substitute for a space in several languages.
So if I were to take a programming job, I would need to check in advance what their style standard is.
Just saying ... I think it is an utterly stupid idea. It is doomed to fail because it is too complex and uses too many things that can fail. And I do agree with you. More often than not, guns save lives without ever being fired. And just because guns are known to be common, criminals will flee even if they hear a homeowner wake up during a burglary, just because she might have a gun and might have it loaded and might even know how to use it. A scary thought to a burglar, right?
And these events never get told by the media ... burglar tries to break in a home ... owner turns on lights ... burglar flees ... homeowner finds nothing ... homeowner does not call police ... media never hears about it happening (as if it would matter to them).
If they can really seriously make this work reliably ... which means sitting in a drawer for 10 years and always works for everyone ... then I am interested ... not because I'd use it on my guns (I still won't) ... but because something technological has become more reliable than anything else. Eh, never happen.
So why did the police not arrest the obvious culprits ... all those moderators, each of which failed to delete that straw in the hay stack.
... without using any electrical parts, let me know.
I believe that coating is gallium oxide.
Why do you think it is Linux's fault that the program had a segmentation fault?
Let's get the perspective right. The programmers at game companies are simply not experienced enough at writing good code to make sure it is reliable on a "new to them" platform. If it bugs out on Windows, they are used to that. But they are NOT writing proper portable code. So they have to write a bunch of NEW code just to go on Linux, given the bad way they have everything structured. Then they don't know what to do to debug it.
It's not Linux's fault these guys are not experienced with Linux.
Actually, it's just a plutocracy.
There are two ways to verify a client that is connecting with some private key. The more commonly known method involves the client providing its signed public key, and verifying the signature (a use of the signer's private key) against its known and trusted public key. Then it is assumed if the trusted signer signed this user public key, then the signer trusted the user, and so the server can trust the user as well. The less commonly known method involves the server having a copy of the user public key, and keeping that copy in the context of users it trusts. Signatures are not involved. The server simply checks if the two keys it has are corresponding pairs.
There are two examples of the latter method being used. The lesser well known is "mode 3" verification in the "stunnel" program. The more well known is the "authorized_keys" list per user in "ssh".
The first method is more appropriate for web access where it is not practical for each user to keep a list of trusted web sites given the vast numbers user may access. But it is possible to do that. You do that by accepting the site key the first time you visit. Future visits verify keys using the stored public key that was previously trusted.
The second method is actually more appropriate for services where all users must be trusted enough to connect, such as ssh. The server needs to trust the client (but trust the other way is good, too). However, the second method should already have been in use for services like POP3 and IMAP.
The second method is done simply by providing you own public key through a channel which the server can verify the user by another means (login by password over HTTPS for example), and keep that public key as part of the user credentials. It, like a password, can also be changed at any time. Signed certificates are not needed. Signatures are not involved.
Many other plausible theories exist, too.
The things I heard on TV news this evening about how his mother was treating him was the people with Asperger's Syndrome hate being treated. They want to be accepted for who they are and what they are. They don't want someone trying to make them different.
Or maybe he was just pissed because DSM-IV recently deleted AS.
I don't get adsense anymore.
Cox has software? Ask them for the Linux version. They will ask you to use Windows. Your tell them you need Linux for the security. They will ask you why you need security. Tell them it's to keep bad companies from messing with your web browsing.
Probably due to underpowered servers.
Surf using HTTPS only. Not all web sites over this, yet. But more and more complaints to them about their lack of support for secure communications could get more to see the need.
Use an offsite provy via a secure vpn/ssh. Rent a VPS for a few more a month (VPS providers are not known to be doing this, yet). Or rent one of those free-for-a-year micro instances at a cloud provider and run your own proxy and connect via ssh.
This post has been sponsored by your own ISP.
Nothing is gained by this. You still need to be able to decrypt in the process. And the database is part of the process. This is just silliness for manager to get brownie points.
The central database itself does not need to encrypted (doing so just means the decryption key has to be there, making the encryption pointless). It needs to be secured against any means of access that does not go through the process (locked building, restricted physical access to data center, armed guards, no internet access to that whole room, etc). Thieves should not be able to get in there at all.
But any data being stored outside needs to be encrypted, and have data compartmentalization on that. There should be no data usable by anyone that steals it. The access process itself should never let the data be outside of its control (it encrypts it if the data goes to storage ... or just prevents it from being stored). Such devices need to have encrypted swap, if any at all.
It should say that SSN is nothing more than identity (as if pointing at a person). It should specifically say that anyone (individual, business, or corporation) who assumes than an SSN is AUTHORIZATION shall be CRIMINALLY (as well as civilly) liable for having committed a crime of fraud upon the identified person.
Encapsulate and isolate. The work devices should be used for work function, only. No PERSONAL surfing. In addition to that, all devices with access to sensitive data shall be completely separate from devices that can access the internet. The database itself must be fully secured. It does not need to store data encrypted, since it would just need to have keys to function. The data is going to be decrypted under process control. What needs to happen is to identify where process control can be bypassed. The glaring example is someone with access to the data on a laptop or tablet AND store the data there. The device can be stolen and access by NON-process means is possible (direct disk dump, for example). THIS is where the data needs to be encrypted with the key NOT stored on the device.
In the case of the South Carolina breach, the central database is not the issue. The PC that let someone into the data is the issue.
We should put the blame on a business/legal system that makes the false assumption that only the person identified by some number actually has or knows that number. Since we have to give out SSNs to so many places, our system needs to assume that by having the number, it in no way means the holder of the number is the person identified by it. An SSN is IDENTITY ONLY. It is NOT AUTHORIZATION, ever. It should be impossible for someone to open a bank account in someone ELSE's name. While that is a violation under existing law, it needs to be made equally liable on BOTH parties. If a bank is willing to open such an account, they MUST also be willing to accept the real person's say-so that it is not their account, and completely drop it, and pay the real person for all the damages and costs ... and not be required to be sued to get it. If they refuse and fail to prove that the identified person is lying, it's jail time, baby.
FYI, jail time for a company does not need to mean a PERSON at the company is jailed. It should mean the company itself is jailed ... shut down and non-operational. If it was a real person doing business, they cannot serve their customers while in jail. So the excuse "we need to have this company" operating does not fly. Shut the bank down for a week if they violate a law where, if a real individual had done so would land that individual in jail for a week.
All those businesses and government agencies that allow merely having data, like that which was taken in this case, The fact that I can walk into any bank and open an account in YOUR NAME just because I have YOUR SSN does not mean that I AM YOU. But the vast majority of banks make that assumption. Lots of other businesses types make this kind of assumption, too. Many have expressly even said so. "This account has your SSN, so it must be your account".
The first law we need to have is one that allows people to deny an account. When they do, the only option for the business involved it so actually prove that PERSON (not someone who had their number) was the one that really opened it, or charged it, or whatever. If the named person asserts that it was not them (penalty of perjury, signed), then it must be disassociated with them everywhere immediately, as if it never happened. The only recourse to undo that is prove the named person lied by proving they actually did open the account or whatever was involved. And this law will clearly state that it must be the person, and not their numbers. And this law would have criminal penalties and jail time for anyone that still does stuff like trying to collect debts on this from the person so named once they assert it is not them.
The system of business we use should not, in any way, and under any circumstance, make ID theft be able to cause any harm to whoever's ID was taken. Things like an SSN should be nothing more than information to refer to a person, and not any indication of authorization.
I would agree. And it starts with taking over the users machine. Once that happens, all bets are off if that user had access rights to the data by some machine. Whether the data (elsewhere) was stored encrypted or not doesn't even matter. If this person had such access it would have to include decrypting it by some means and by that he would give the new owner of his machine full access to the data, too ... even if it wasn't on the same day he clicked the email. Both email reading and web browsing should never, ever, have any means to run any software on the machine. Ideally, people who do have such access should be doing that entirely on machines dedicated to that access which do nothing else (no mail reader, no web browser, etc).
What the internet is doing is showing people for who and what they really are.
The impact of holding down labor costs is that income of the market is going down. It means fewer people can afford to buy your product. That means your market is getting smaller. You'll have to reduce the scale of your business. And that means you'll have to cut costs even more. And you know what that leads to.