While e-books have come a long way, they will never gain universal adoption. Some people still will prefer the physicality of a book. MP3s could replace CDs and CDs, Tapes and tapes, cassettes and cassettes 8 tracks and 8 tracks records because they are not media that we physically interact with. There was (for most people's perspective) an increase in quality without a change in experience. The same can not be said for e-books. As a very early e-book adopter, the thing driving the revolution forward is e-ink technology that allows books to finally be comfortably read in electronic format, but it still can not replicate the feeling of finishing a book and putting it on your bookshelf or the feel of turning pages through the book. For some people this doesn't matter and e-books will be it all, but for others who like the physicality of an actual book, they will still purchase books. Also, there are still many portions of the world that lack the technical base to move to electronic readers. You can see this in the same reason that people buy hardcovers when paperbacks are available. (I could however see eBooks as the death of the paperback and possibly the physical magazine.)
Even if in the very long run, we end up moving towards electronic books when they become completely ubiquitous, the case for archiving physical copies is stupid. You don't verify changes have not been made by referencing one physical work kept by a single organization. Anyone familiar with textual criticism knows this is bullshit. You verify it by looking at the MILLIONS OF COPIES and looking for differences. If someone wanted to make a change, they would have to update them all or the change could be detected and corrected. The storage of a single physical copy for archival purposes is both unnecessary and ineffective. The thinking that it is necessary is in fact actually outdated more so than the claim the author made that physical books are outdated.
Wow. I guess I opened up a can of worms. I agree with both of you really. I also happen to be an audio engineer and have done some recording work. I agree that a lot of stuff is currently over-compressed and unfortunately that is largely done because of the devices it is going to be playing on. It is the boombox mentality of playing it loud at the point where detail would be lost if the level of compression was not set where it is. You can even see this in the way that a fair number of live shows are mixed or the way that an average person will mix their sound for their living room speaker setup. That said, compression is a really critical tool to getting an appropriate sound on individual tracks and keeping proper balance between parts of the sound. In the right hands it can do very nice things like giving a rich dynamic range for soft stuff while not blowing away other parts at louder times.
Also, even with over-compression, really good DACs and speakers (particularly in-ear headphones) do make a difference in being able to pick out some of the details that are almost lost from the compression. (My original reference to compression was simply to the data storage algorithms though, but I like the discussion on acoustic compression as well.) I use a pair of Shure SE535s that I got as a warranty replacement of my old E5s. The 425s would have really been a bit better for technical work (the 535s have a slightly warm balanced sound due to the dual woofers) but it still isn't that far from level. Using them with my Galaxy S gives a pretty decent setup for phone based audio playback. (I also like the DAC on the Asus Transformer.) I've also got a Creative Professional 0404 for doing actual real audio work on my desktop.
Lossless isn't. It's still compressed from the original recordings to get to the audio recorded on a CD. Sure you can digitize the files on the CD to a format that will reproduce exactly what was on the CD, but at the end of the day compression is about portability. I am very much a true audiophile, but I mostly use 320 or 360kpbs encoding depending on the player I'm using simply to be able to have the collection portable. The DAC makes a far bigger deal anyway and there is no comparison between live sound from an analog or even a good digital board to what comes out of a CD. What really annoys me is the psycho-acoustic compressions that horribly distort music outside the "popular" frequency bands and the people who claim to be audiophiles and swear by them.
Video games are one of the few distractions that actually inspires people towards technology fields. Though yes, professional sports could be added to the list. His core point was that in most popular media and entertainment, there is not even a mention of engineering or science. It is simply stupid or average people doing stupid or average things. Video games frequently use scientists and engineers as main characters and make people engage in problem solving in many games. There is actually an entire subset of study on how to use gaming for more effective education. I can safely say from personal experience that my video game playing had a significant impact on my pursuit of a technology focused career.
Yeah, it can vary from person to person. The flicker on lower quality CRTs could be a problem for some I suppose, but I know many who the emitted light is the problem. So in the case of those who suffer from fatigue from the flicker, yes, it will make a difference, but those who are sensitive to light, it won't.
I think it is also ironic that ChromiumPC is atleast as close to ChromeOS or Chrome as ChromeBook is to ChromiumPC and I'm pretty sure that Google has the trademark on ChromeOS. If I was Google, I'd be suing the crap out of ISys for violating the ChromeOS trademark.
On the eyestrain thing, do you know the difference? The problem is emitted light vs reflected light. They are inherently different intensities of light and an LCD is still just as much emitted light as a CRT was, possibly worse since non-charged phosphors in CRTs didn't emit light while darkened LCD crystals still permit light through. Until you move to something like an e-ink reflective display, you are going to have the possibility of eye strain. Granted, properly adjusting your contrast ratio and screen brightness will help considerably, but it doesn't change the fact you are spending your day looking directly into a bunch of florescent light bulbs (or LEDs if you have an LED back lit LCD).
No, that just makes it more likely that people will try to zip through since they perceive it as having more time. What you actually want to increase is the delay between when one light goes red and the other goes green.
That's a nice image, but it's a standard rugadized pda. You can find similar hardware for doing work in factory environments and such where you potentially need to protect the electronics from more abuse than your average consumer electronics are designed to take. It really has nothing to do with preventing interference.
Because operating systems run the software that users tell it to run and a large portion of malware got there because users told the operating system to install it. It isn't the car manufacturers fault if the customer cuts their own brake line.
Yeah, but it is substantially less likely that both the browser and text will be compromised unless you bank from your phone. Note, I would never recommend banking from your phone with a txt message based 2 channel system. The two channels should always be on two separate devices or you are really making it single channel again. Also, if someone decides to attack you specifically, you are pretty much screwed. If they get really desperate, they can just break in to your home with a rather menacing looking wrench and beat the authorization out of you.
That actually isn't because if your system is compromised, the attacker can hijack the code you entered in the browser. Two channel isn't two channel if only one channel has to be compromised to break it. That said, there are plenty of ways to actually make that kind of a setup work, but mostly it involves sending a code along with the details of what is being attempted and then waiting to get that code as confirmation to do what was intended. If the details passed on one channel are wrong, then you as the user would never move the data from that channel to the other, so unless both channels are broken (they can get the code and enter it without your action) then you would be protected. Hope that makes sense. I'm realizing just how poorly understood a lot of these security principals are from reading the comments on here today (not specifically your's by the way, but other ones that have people claiming that there is no way to secure a compromised computer trying to make a transaction.)
Except if my device can validate a signature from the bank on the transaction that only would match if my transaction details are unaltered, then I would never enter the second token code.
See my description above of the correct scheme for this, it is the same as what the Commonwealth Bank of Australia does. As long as you have a secure device that can validate bank signed data, you can sign a request so that the bank knows you made a request, the bank can sign what the request they received is so you know that is what they received (unless their computer is compromised too, but we are worrying about client security here, so we'll ignore that scenario for now), you can then send them a validation with a second token signature that validates that the transaction they received is the transaction you authorized. Provided the token is secure and can not be generated by the attacker without the device, the system is secure to MIM.
Just because all communication from you goes through a single communication channel does not make it a single channel system. The number of channels is based on how many channels must be compromised to break the system. In the case of the text message for example, as long as you must take another step for your browser/computer to be able to say you approve the amount sent in the text message to the account sent in the text message, then both the text message sent to you and the message sent to/from your browser must both be compromised. Where you start getting tricky with that though is when you are working with a smartphone for mobile banking and text messages and the browser now both exist on the same device. This can still be overcome with the method I described earlier though (external hardware used to generate code to sign transaction, bank signs the transaction and returns it to user to be validated by external device and external device then generates a signature for the confirmation from the bank. This confirms to the bank that you made some request, confirms to you that the bank got your request unaltered and confirms to the bank that you acknowledged that the request they received was the request you sent. It can not be broken without compromising the external device and the communication channel and therefore is two channel and two factor. (What you have, what you know, provided that a password is part of the signing process.)
You could require a code per transaction and hash the descriptor of the transaction and return it. This return code could be validated to ensure that only the requested transaction occurred. If you did this as a two step process to make a transaction, it would protect against a compromised computer.
Ex, I request $100 transferred to account ABC and I sign it with my access code from my token. Bank validates that the token is valid and signs a response saying they wish to transfer $100 to ABC with their token. I validate that the bank correctly received my transaction. I sign the bank's receipt with my next code and return this to the bank to finalize my understanding and approval of the transaction.
Since the MIM can not return a valid response from the bank for my transaction, they can not alter it and since the bank works from that transaction when I validate it, the attacker is unable to generate the confirmation. The system gets to be kind of a pain, but a half measure could be taken by using an application and or TPM to handle a lot of the signing in software instead of using a token (or use a USB token). It weakens it a little if the attacker knows how to properly use the token, but it at least complicates the attack vector.
What I want to know is if the glasses will work with other 3DTVs and the feature will be supported on other TVs. I've got a 55" Bravia 3DTV and I would love to be able to use this feature. Really all it is is a different shutter pattern for the glasses, so there is no reasons they shouldn't make this available on any 3DTV that has compatible glasses.
Yeah, I agree that they need to be more forthcoming with detailed info. I was just defending that they are not untrustworthy as the previous poster had indicated. Though really, it is well understood how the system works and what information could potentially be compromised on their systems. It sounds like it was pretty much the worst case scenario that could occur (the situation I described is basically the worst possible case). It basically assumes that the token value is known and the only thing not known is the token that goes with a particular user. That said, I do realize now that the situation would actually be worse then though. If you can monitor someone's connection, you could gather their token and then run that timestamp against the known tokens to identify the pairing, granted you need to be able to MIM attack it, but it does raise my risk assessment by multiple orders of magnitude.
Also, specifically on the case of transferring the root key again, that leaves the key exposed and vulnerable. Even beyond convenience, do you trust your ability to exchange the key in the future securely or do you trust your ability to store it and not have to send it. The traditional rule for symmetric key exchange is to store securely rather than transmit if you can avoid it. Any time you transmit a key, you leave it open to compromise and once a key is compromised you can't uncompromise it and can't necessarily detect the compromise.
It isn't that simple, convenience always wins out over security. I will happily store your data for you in a way nobody will ever get to it (send it to dev\null). Unfortunately you can't get it either. Even the best designed security limits usability by the nature of what you are doing. The job of good design in security is to find the balancing point. Sure I could disable every single transfer of data out of a system without having every user of the system sign off on it so that nobody in the organization could collude with anyone else to hurt anyone in the organization, but is that really good security or is it just an overly burdensome system that offers no real benefit? Any system can and will be broken by a sufficiently motivated attacker with sufficient resources. The point of security is simply to set the balancing point between your possible loss, your costs and your usability at the ideal level. Anyone who doesn't understand this will never make a good security professional.
Last I knew, there are not air marshals on every flight. They are only on a small minority of flights as a random deterrent that they might be there. Also, that doesn't do anything about someone wanting to simply blow a plane up, it just stops hijackings which really would work anymore anyway.
In fairness to RSA, they did release updated best practices to their clients right away and had reason to believe (accurately) that the attackers were interested in the defense industry specifically, so they focused on fixing that first. Really, as long as you lock your system down if someone starts using the wrong RSA token with the wrong username repeatedly, then the chances of an actual penetration are still pretty minimal, at least for any sizable key-space. It's not a situation that would occur in almost any situation in real life, so setting the threshold for lock down to even 2 attempts would be sufficient. Sure it is still much less secure, but with a pool of say 100 users, you are still talking a.01% chance of a breach not being detected and shut down before being effective. That's still a very insignificant, particularly considering it leaves a very characteristic fingerprint of the attack that would make it rapidly obvious if someone was trying it on a large scale and they could take measures accordingly. (Statistically, a broad attack against all RSA clients would likely have a success, but it would still be complex to carry out quickly as usernames and passwords would need to be obtained for the targets as well.)
Slashdot Mirror
Gopher is still alive and somewhat well. There is a plugin for firefox that will let you access it. There are a couple hundred servers still.
While e-books have come a long way, they will never gain universal adoption. Some people still will prefer the physicality of a book. MP3s could replace CDs and CDs, Tapes and tapes, cassettes and cassettes 8 tracks and 8 tracks records because they are not media that we physically interact with. There was (for most people's perspective) an increase in quality without a change in experience. The same can not be said for e-books. As a very early e-book adopter, the thing driving the revolution forward is e-ink technology that allows books to finally be comfortably read in electronic format, but it still can not replicate the feeling of finishing a book and putting it on your bookshelf or the feel of turning pages through the book. For some people this doesn't matter and e-books will be it all, but for others who like the physicality of an actual book, they will still purchase books. Also, there are still many portions of the world that lack the technical base to move to electronic readers. You can see this in the same reason that people buy hardcovers when paperbacks are available. (I could however see eBooks as the death of the paperback and possibly the physical magazine.)
Even if in the very long run, we end up moving towards electronic books when they become completely ubiquitous, the case for archiving physical copies is stupid. You don't verify changes have not been made by referencing one physical work kept by a single organization. Anyone familiar with textual criticism knows this is bullshit. You verify it by looking at the MILLIONS OF COPIES and looking for differences. If someone wanted to make a change, they would have to update them all or the change could be detected and corrected. The storage of a single physical copy for archival purposes is both unnecessary and ineffective. The thinking that it is necessary is in fact actually outdated more so than the claim the author made that physical books are outdated.
Wow. I guess I opened up a can of worms. I agree with both of you really. I also happen to be an audio engineer and have done some recording work. I agree that a lot of stuff is currently over-compressed and unfortunately that is largely done because of the devices it is going to be playing on. It is the boombox mentality of playing it loud at the point where detail would be lost if the level of compression was not set where it is. You can even see this in the way that a fair number of live shows are mixed or the way that an average person will mix their sound for their living room speaker setup. That said, compression is a really critical tool to getting an appropriate sound on individual tracks and keeping proper balance between parts of the sound. In the right hands it can do very nice things like giving a rich dynamic range for soft stuff while not blowing away other parts at louder times.
Also, even with over-compression, really good DACs and speakers (particularly in-ear headphones) do make a difference in being able to pick out some of the details that are almost lost from the compression. (My original reference to compression was simply to the data storage algorithms though, but I like the discussion on acoustic compression as well.) I use a pair of Shure SE535s that I got as a warranty replacement of my old E5s. The 425s would have really been a bit better for technical work (the 535s have a slightly warm balanced sound due to the dual woofers) but it still isn't that far from level. Using them with my Galaxy S gives a pretty decent setup for phone based audio playback. (I also like the DAC on the Asus Transformer.) I've also got a Creative Professional 0404 for doing actual real audio work on my desktop.
Lossless isn't. It's still compressed from the original recordings to get to the audio recorded on a CD. Sure you can digitize the files on the CD to a format that will reproduce exactly what was on the CD, but at the end of the day compression is about portability. I am very much a true audiophile, but I mostly use 320 or 360kpbs encoding depending on the player I'm using simply to be able to have the collection portable. The DAC makes a far bigger deal anyway and there is no comparison between live sound from an analog or even a good digital board to what comes out of a CD. What really annoys me is the psycho-acoustic compressions that horribly distort music outside the "popular" frequency bands and the people who claim to be audiophiles and swear by them.
Video games are one of the few distractions that actually inspires people towards technology fields. Though yes, professional sports could be added to the list. His core point was that in most popular media and entertainment, there is not even a mention of engineering or science. It is simply stupid or average people doing stupid or average things. Video games frequently use scientists and engineers as main characters and make people engage in problem solving in many games. There is actually an entire subset of study on how to use gaming for more effective education. I can safely say from personal experience that my video game playing had a significant impact on my pursuit of a technology focused career.
Yeah, it can vary from person to person. The flicker on lower quality CRTs could be a problem for some I suppose, but I know many who the emitted light is the problem. So in the case of those who suffer from fatigue from the flicker, yes, it will make a difference, but those who are sensitive to light, it won't.
I think it is also ironic that ChromiumPC is atleast as close to ChromeOS or Chrome as ChromeBook is to ChromiumPC and I'm pretty sure that Google has the trademark on ChromeOS. If I was Google, I'd be suing the crap out of ISys for violating the ChromeOS trademark.
On the eyestrain thing, do you know the difference? The problem is emitted light vs reflected light. They are inherently different intensities of light and an LCD is still just as much emitted light as a CRT was, possibly worse since non-charged phosphors in CRTs didn't emit light while darkened LCD crystals still permit light through. Until you move to something like an e-ink reflective display, you are going to have the possibility of eye strain. Granted, properly adjusting your contrast ratio and screen brightness will help considerably, but it doesn't change the fact you are spending your day looking directly into a bunch of florescent light bulbs (or LEDs if you have an LED back lit LCD).
No, that just makes it more likely that people will try to zip through since they perceive it as having more time. What you actually want to increase is the delay between when one light goes red and the other goes green.
I LOL'd. Thank you for that.
Because if it isn't the cellphone there may be something else you need to do to fix the problem.
That's a nice image, but it's a standard rugadized pda. You can find similar hardware for doing work in factory environments and such where you potentially need to protect the electronics from more abuse than your average consumer electronics are designed to take. It really has nothing to do with preventing interference.
Because operating systems run the software that users tell it to run and a large portion of malware got there because users told the operating system to install it. It isn't the car manufacturers fault if the customer cuts their own brake line.
Yeah, but it is substantially less likely that both the browser and text will be compromised unless you bank from your phone. Note, I would never recommend banking from your phone with a txt message based 2 channel system. The two channels should always be on two separate devices or you are really making it single channel again. Also, if someone decides to attack you specifically, you are pretty much screwed. If they get really desperate, they can just break in to your home with a rather menacing looking wrench and beat the authorization out of you.
That actually isn't because if your system is compromised, the attacker can hijack the code you entered in the browser. Two channel isn't two channel if only one channel has to be compromised to break it. That said, there are plenty of ways to actually make that kind of a setup work, but mostly it involves sending a code along with the details of what is being attempted and then waiting to get that code as confirmation to do what was intended. If the details passed on one channel are wrong, then you as the user would never move the data from that channel to the other, so unless both channels are broken (they can get the code and enter it without your action) then you would be protected. Hope that makes sense. I'm realizing just how poorly understood a lot of these security principals are from reading the comments on here today (not specifically your's by the way, but other ones that have people claiming that there is no way to secure a compromised computer trying to make a transaction.)
Except if my device can validate a signature from the bank on the transaction that only would match if my transaction details are unaltered, then I would never enter the second token code.
See my description above of the correct scheme for this, it is the same as what the Commonwealth Bank of Australia does. As long as you have a secure device that can validate bank signed data, you can sign a request so that the bank knows you made a request, the bank can sign what the request they received is so you know that is what they received (unless their computer is compromised too, but we are worrying about client security here, so we'll ignore that scenario for now), you can then send them a validation with a second token signature that validates that the transaction they received is the transaction you authorized. Provided the token is secure and can not be generated by the attacker without the device, the system is secure to MIM.
Just because all communication from you goes through a single communication channel does not make it a single channel system. The number of channels is based on how many channels must be compromised to break the system. In the case of the text message for example, as long as you must take another step for your browser/computer to be able to say you approve the amount sent in the text message to the account sent in the text message, then both the text message sent to you and the message sent to/from your browser must both be compromised. Where you start getting tricky with that though is when you are working with a smartphone for mobile banking and text messages and the browser now both exist on the same device. This can still be overcome with the method I described earlier though (external hardware used to generate code to sign transaction, bank signs the transaction and returns it to user to be validated by external device and external device then generates a signature for the confirmation from the bank. This confirms to the bank that you made some request, confirms to you that the bank got your request unaltered and confirms to the bank that you acknowledged that the request they received was the request you sent. It can not be broken without compromising the external device and the communication channel and therefore is two channel and two factor. (What you have, what you know, provided that a password is part of the signing process.)
You could require a code per transaction and hash the descriptor of the transaction and return it. This return code could be validated to ensure that only the requested transaction occurred. If you did this as a two step process to make a transaction, it would protect against a compromised computer.
Ex,
I request $100 transferred to account ABC and I sign it with my access code from my token.
Bank validates that the token is valid and signs a response saying they wish to transfer $100 to ABC with their token.
I validate that the bank correctly received my transaction.
I sign the bank's receipt with my next code and return this to the bank to finalize my understanding and approval of the transaction.
Since the MIM can not return a valid response from the bank for my transaction, they can not alter it and since the bank works from that transaction when I validate it, the attacker is unable to generate the confirmation. The system gets to be kind of a pain, but a half measure could be taken by using an application and or TPM to handle a lot of the signing in software instead of using a token (or use a USB token). It weakens it a little if the attacker knows how to properly use the token, but it at least complicates the attack vector.
What I want to know is if the glasses will work with other 3DTVs and the feature will be supported on other TVs. I've got a 55" Bravia 3DTV and I would love to be able to use this feature. Really all it is is a different shutter pattern for the glasses, so there is no reasons they shouldn't make this available on any 3DTV that has compatible glasses.
Yeah, I agree that they need to be more forthcoming with detailed info. I was just defending that they are not untrustworthy as the previous poster had indicated. Though really, it is well understood how the system works and what information could potentially be compromised on their systems. It sounds like it was pretty much the worst case scenario that could occur (the situation I described is basically the worst possible case). It basically assumes that the token value is known and the only thing not known is the token that goes with a particular user. That said, I do realize now that the situation would actually be worse then though. If you can monitor someone's connection, you could gather their token and then run that timestamp against the known tokens to identify the pairing, granted you need to be able to MIM attack it, but it does raise my risk assessment by multiple orders of magnitude.
Also, specifically on the case of transferring the root key again, that leaves the key exposed and vulnerable. Even beyond convenience, do you trust your ability to exchange the key in the future securely or do you trust your ability to store it and not have to send it. The traditional rule for symmetric key exchange is to store securely rather than transmit if you can avoid it. Any time you transmit a key, you leave it open to compromise and once a key is compromised you can't uncompromise it and can't necessarily detect the compromise.
It isn't that simple, convenience always wins out over security. I will happily store your data for you in a way nobody will ever get to it (send it to dev\null). Unfortunately you can't get it either. Even the best designed security limits usability by the nature of what you are doing. The job of good design in security is to find the balancing point. Sure I could disable every single transfer of data out of a system without having every user of the system sign off on it so that nobody in the organization could collude with anyone else to hurt anyone in the organization, but is that really good security or is it just an overly burdensome system that offers no real benefit? Any system can and will be broken by a sufficiently motivated attacker with sufficient resources. The point of security is simply to set the balancing point between your possible loss, your costs and your usability at the ideal level. Anyone who doesn't understand this will never make a good security professional.
Last I knew, there are not air marshals on every flight. They are only on a small minority of flights as a random deterrent that they might be there. Also, that doesn't do anything about someone wanting to simply blow a plane up, it just stops hijackings which really would work anymore anyway.
In fairness to RSA, they did release updated best practices to their clients right away and had reason to believe (accurately) that the attackers were interested in the defense industry specifically, so they focused on fixing that first. Really, as long as you lock your system down if someone starts using the wrong RSA token with the wrong username repeatedly, then the chances of an actual penetration are still pretty minimal, at least for any sizable key-space. It's not a situation that would occur in almost any situation in real life, so setting the threshold for lock down to even 2 attempts would be sufficient. Sure it is still much less secure, but with a pool of say 100 users, you are still talking a .01% chance of a breach not being detected and shut down before being effective. That's still a very insignificant, particularly considering it leaves a very characteristic fingerprint of the attack that would make it rapidly obvious if someone was trying it on a large scale and they could take measures accordingly. (Statistically, a broad attack against all RSA clients would likely have a success, but it would still be complex to carry out quickly as usernames and passwords would need to be obtained for the targets as well.)