I'm a security expert of some kind, but you are of course spot on. The more flexibility you have, the bigger the attack service. And things like a scripting language may add a lot of flexibility. Of course, there are ways to mitigate the risk. Having sites run in there own sandbox (including the scripts) for instance. Or having plugins run in their own process, so they don't have direct access to browser data.
The current set of web-browsers and web standards do make a pretty brittle system. I've always wondered for instance if we wouldn't have been better off if a single page view could only come from a single server. Adding all this kind of functionality certainly won't make it safer. That said, it may still be a lot safer than a browser with plugins for flash, shockwave, pdf, silverlight added. Initially at least it is more likely that we have all these plugins *and* HTML 5, so that means less safety whichever way you look at it.
Having a secure browser (and web standard) sounds like a good idea, but the trick is to decide which parts should be included. My bank site itself uses quite a lot of HTML features that I would like to have excluded for safety reasons. I'm not so sure that my bank wants to do away with their fancy GUI though. And they are one of the less obnoxious ones.
We should therefore not take it face value, but dismissing it entirely because it comes from a security firm is just as stupid. This is Slashdot, lets discuss this on technical merit of the arguments, not on some notion of politics.
We've got two internet PC's at work that use a P4 HT (I work in a high secure environment). They are much more suitable for use as a room heater. Maybe you should upgrade to one of those - no flash required. Note that you actually need to use the off- or suspend button to turn the heater off.
I don't know, there are not that many apps that can't run on my HTC Hero, and I upgraded it from 1.5 to 2.1 just a while ago. I never had any serious issue *with regards to version control with any app. I must admit that I wonder about the lack of support for modularization (e.g. OSGi) but in practice that problem has not cropped up yet - at least not for consumers.
And this is modded informative? Sure, if you have a secret key you will have to distribute it to use it. That seems to have been the case for DHCP (which is obviously not - yet - suited for asymmetric encryption due to cost/latency constraints). But you'll be famous if you can retrieve a asymmetric private key from encrypted content that you distributed together with the public key. Most standardized encryption systems in are safe from plain text attacks (e.g. 3DES, AES, RSA and Elliptic Curves).
The big problem with DRM is that you need to distribute the key to decrypt the stream in the first place. If that eco-system is not completely airtight (manufacturers of players and players) then you will run into trouble. Because you can retrieve the playing key or the content if it isn't. This becomes worse when you don't have a flexible key management system - the reason why there is one in the Blu-ray spec. But the Blu-ray spec can rely on high end / hardware accelerated processors - I presume DHCP can't.
Scare tactics seem to be a good way of making money; you act like there are not other "benefits" than making money directly from the person that is being sued.
They were probably afraid that SHA-1 was going to be broken so badly that you cannot use any normal key derivation method. I'm currently researching this topic (key derivation), and although there are almost no real standards to speak of, this must be the idiots way to do it.
It's hell of a lot harder, but once the statistical analysis is in place and the right conclusions can be retrieved from them (setup a server and perform tests locally) the computer will do the job. But yes, it will take an awful amount of requests, for practicality a bot net will probably be needed.
On the one hand you are absolutely right. On the other hand, they make it an encrypted cookie for nothing. If you encrypt something the overall idea with developers will be that it is a safe place to store data.
So it comes down to 3 culprits:
- no (H)MAC used to protect the data (always a bad thing, as one of the first posters correctly pointed out): BAD PROTOCOL
- too much information leaked by default ASP.NET implementation
- bad decision to put sensitive data in a cookie by the application engineers
And it could even come to 4 culprits:
- bad documentation - if you provide encrypted cookies in a framework: document what they should be used for
"This is a non-issue as long as you realize that what is encrypted can be decrypted"...
That statement is not true in any pragmatical sense. I can create random secret AES key, encrypt a piece of plain text with it and send it to you. Then throw away the key. Call me back when you've decrypted it. You can specify any size, but anything over 10 MB will be a bugger to upload.
Of course, the cookie should mostly be used to keep session state, not bank details, I'm with you there.
Not so, you are forgetting side channel attacks, in particular side channel attacks based on computation time.
I.e. different exceptions thrown at different locations will take a specific amount of time, which can be leaked and used by performing statistical analysis.
Sounds far fetched, but it works beautifully in practice. Of course, it is still way better than throwing stack traces around.
Oh, and make sure the user gets an easy to understand message and that the server *logs* the exception.
Sure, fine, that's what I said. *Unless* there are inherent advantages. But you guys act like all smaller process technology will always result in better chips. I can however remember quite a few x86 chips where smaller die size did not *directly* result in better chips. And if the architecture has changed then anything can happen.
Of course, if early reviews state that the g2 blows the nexus out of the water, or if there are other indications that the new chip is better, fine, just wait for it to be released. Personally, I would wait a bit to see if power consumption has indeed improved or is still in par. Dual core means double transistors at some point in the architecture, and although ARM power management is famous for it's efficiency, I'm a bit skeptical about that.
A smaller process? Unless there are inherent advantages (price, power usage), I don't see how that would influence a buying decision. It's nice for HTC and possibly the manufacturer, but that does not concern me.
Nice, a scientificly book on food. On the other hand anyone that is interested in quickly preparing a meal does not have to look further to the (by now very old, but venerable) "How to prepare your input" by no-one else than Andrew S. Tanenbaum (aka Andy for students/friends).
www.cs.vu.nl/~ast/home/how_to_prep.ps
Important note: Last time I saw him he still looked healthy to me:)
It's not very friendly to any other user either if you ask me.
(But the content of posts can be pretty high - as the GGP illustrates - and the moderator system usually works - somewhat. So we take the awkwardness of the editing system together with the advantages. Slashdot maintainers, that does not mean that we don't want a better editor, thank you very much.)
Yes, and if you use units (and generally you do) then make it clear what units each parameter expects. I am in crypto and I am always guessing if things are in bits or bytes. In physics it is even more important - fortunately students of physics will probably be more inclined to describe the units they expect. Also, the names of the parameters are even more important than those in the source files. Basically, if you have e.g. a configuration file, it should be thought of as part of the user interface.
Personally I describe *what* the code does. If it contains several (small) steps, I try to put little markers in as well. If there are certain uncommon techniques I am using, or when an API call is sufficiently unclear, I document that too, but normally the code itself should be self descriptive. I refactor quite a bit during coding, it happens only a few times that I am happy with the names of the identifiers at the first go. Fortunately the Eclipse Java IDE has good support for refactoring. Finally, whenever I still have to do implement, debug or test a method I will mark it using an identifier in a comment. Currently I am using Eclipse tasks for this, using NOTE: (this class should be refactored), WARNING: (this class is not thread safe), DEBUG: (remove these System.out.println statement) and of course the dreaded TODO: (freakin' implement the stuff already). TODO: is always accompanied by an exception (in Java: throw new IllegalStateException("Not implemented")) of course.
Normally my design don't go to method level. They do normally include a system overview and a module overview though, and a view per module of how the *main* classes are related to each other. Personally I don't design each and every method - that's for the implementation phase. I'll just run JavaDoc after I've finished; at least JavaDoc is more likely to be up to date than a separate design document. You *must* document each and every method that is publicly available or that can be overwritten by a child class (protected methods in Java).
I've described Java, but the same techniques should go for any programming language (although the tool support might be lacking for most alternatives).
I spent some quality years programming basic and - later on - machine code (there weren't too many assemblers lying around I, as a kid, I didn't know about them). Then I got to high school and thought that blind, 10 finger typing would be useful. For this I had to stay at school for 2 hours without lessons (I didn't do any homework at high school, so this was a bore). Imagine my surprise when I found out that typing was done using actual *typewriters*, placed next to the computer class. Dropped it after 5 minutes, got some typing tutorials for my computer and I'm probably the fastest writer of documentation at my software engineering job.
Then again, the IDIOTS at the "Vrije Universiteit" still required me to learn emacs and VI to do compiler construction and operating systems. That didn't end well - and I still absolutely abhor text editors like those.
Not really, but their track record is not so good, especially regarding justice.
"But European governments are doing it too?!?!?"
Yes, and even though they do weird things, they do have a better track record.
"But it's oh-so-wonderful Google!!!"
Google has been very nice up till now, but strength tends to be abused. We should be vigilant without necessarily harming Google.
"OH NOES!!!! SOMEONE TELL ME WHAT TO THINK!!!!"
We should take a very good look at Google from time to time. The Texas attorney general is, however, probably the least competent person to do so.
I've looked up the attorney general and this part gave away what he's after:
"Defending Tort Reform
Texas has been recognized among the best in the nation at attracting new businesses and recruiting new medical personnel due to the state’s successful tort reforms. General Abbott has successfully defended legal challenges to Texas’s tort reform laws helping create a stable environment to attract new businesses and create new jobs."
This guy is not after Google to help the little man for certain. Actually, there is evil in Texas, and I might just have found a part of it.
I think we should start an inquiry about bias with Texas attorneys, not Google. It seems that they are too embedded in the old boys network to have anything to do with justice.
Look at the companies that file complaints: three companies that anyone would rather filter out than in. Seems to me that these aren't the companies that warrant the investigation. So I've got a very strong feeling this other company is behind it.
For me, this is just a big ploy to get to the page-rank algorithm. It would not be hard to leak it when the investigation starts for real.
It was better (and certainly faster) than anything before - but I don't think it was quite ready for prime time. At the end their results seemed have serious issues with it. Actually, I don't think Google is that great either - I cannot filter out all "add your own review" from the various sites. This is probably due to Google actually *not* manually altering the search results (although they have seemed to get better).
Altavista will probably always be remembered as the one that started the search engine wars for real. And Google as the winner - for now.
Slashdot Mirror
This would be more like "I believe it when I don't see it fodder".
You're a bit late to the game, so we'll call it grammar neo-Nazism if you don't mind.
18 to 5
I'm a security expert of some kind, but you are of course spot on. The more flexibility you have, the bigger the attack service. And things like a scripting language may add a lot of flexibility. Of course, there are ways to mitigate the risk. Having sites run in there own sandbox (including the scripts) for instance. Or having plugins run in their own process, so they don't have direct access to browser data.
The current set of web-browsers and web standards do make a pretty brittle system. I've always wondered for instance if we wouldn't have been better off if a single page view could only come from a single server. Adding all this kind of functionality certainly won't make it safer. That said, it may still be a lot safer than a browser with plugins for flash, shockwave, pdf, silverlight added. Initially at least it is more likely that we have all these plugins *and* HTML 5, so that means less safety whichever way you look at it.
Having a secure browser (and web standard) sounds like a good idea, but the trick is to decide which parts should be included. My bank site itself uses quite a lot of HTML features that I would like to have excluded for safety reasons. I'm not so sure that my bank wants to do away with their fancy GUI though. And they are one of the less obnoxious ones.
We should therefore not take it face value, but dismissing it entirely because it comes from a security firm is just as stupid. This is Slashdot, lets discuss this on technical merit of the arguments, not on some notion of politics.
We've got two internet PC's at work that use a P4 HT (I work in a high secure environment). They are much more suitable for use as a room heater. Maybe you should upgrade to one of those - no flash required. Note that you actually need to use the off- or suspend button to turn the heater off.
I don't know, there are not that many apps that can't run on my HTC Hero, and I upgraded it from 1.5 to 2.1 just a while ago. I never had any serious issue *with regards to version control with any app. I must admit that I wonder about the lack of support for modularization (e.g. OSGi) but in practice that problem has not cropped up yet - at least not for consumers.
And this is modded informative? Sure, if you have a secret key you will have to distribute it to use it. That seems to have been the case for DHCP (which is obviously not - yet - suited for asymmetric encryption due to cost/latency constraints). But you'll be famous if you can retrieve a asymmetric private key from encrypted content that you distributed together with the public key. Most standardized encryption systems in are safe from plain text attacks (e.g. 3DES, AES, RSA and Elliptic Curves).
The big problem with DRM is that you need to distribute the key to decrypt the stream in the first place. If that eco-system is not completely airtight (manufacturers of players and players) then you will run into trouble. Because you can retrieve the playing key or the content if it isn't. This becomes worse when you don't have a flexible key management system - the reason why there is one in the Blu-ray spec. But the Blu-ray spec can rely on high end / hardware accelerated processors - I presume DHCP can't.
Scare tactics seem to be a good way of making money; you act like there are not other "benefits" than making money directly from the person that is being sued.
They were probably afraid that SHA-1 was going to be broken so badly that you cannot use any normal key derivation method. I'm currently researching this topic (key derivation), and although there are almost no real standards to speak of, this must be the idiots way to do it.
It's hell of a lot harder, but once the statistical analysis is in place and the right conclusions can be retrieved from them (setup a server and perform tests locally) the computer will do the job. But yes, it will take an awful amount of requests, for practicality a bot net will probably be needed.
On the one hand you are absolutely right. On the other hand, they make it an encrypted cookie for nothing. If you encrypt something the overall idea with developers will be that it is a safe place to store data.
So it comes down to 3 culprits:
- no (H)MAC used to protect the data (always a bad thing, as one of the first posters correctly pointed out): BAD PROTOCOL
- too much information leaked by default ASP.NET implementation
- bad decision to put sensitive data in a cookie by the application engineers
And it could even come to 4 culprits:
- bad documentation - if you provide encrypted cookies in a framework: document what they should be used for
"This is a non-issue as long as you realize that what is encrypted can be decrypted"...
That statement is not true in any pragmatical sense. I can create random secret AES key, encrypt a piece of plain text with it and send it to you. Then throw away the key. Call me back when you've decrypted it. You can specify any size, but anything over 10 MB will be a bugger to upload.
Of course, the cookie should mostly be used to keep session state, not bank details, I'm with you there.
Not so, you are forgetting side channel attacks, in particular side channel attacks based on computation time.
I.e. different exceptions thrown at different locations will take a specific amount of time, which can be leaked and used by performing statistical analysis.
Sounds far fetched, but it works beautifully in practice. Of course, it is still way better than throwing stack traces around.
Oh, and make sure the user gets an easy to understand message and that the server *logs* the exception.
Sure, fine, that's what I said. *Unless* there are inherent advantages. But you guys act like all smaller process technology will always result in better chips. I can however remember quite a few x86 chips where smaller die size did not *directly* result in better chips. And if the architecture has changed then anything can happen.
Of course, if early reviews state that the g2 blows the nexus out of the water, or if there are other indications that the new chip is better, fine, just wait for it to be released. Personally, I would wait a bit to see if power consumption has indeed improved or is still in par. Dual core means double transistors at some point in the architecture, and although ARM power management is famous for it's efficiency, I'm a bit skeptical about that.
A smaller process? Unless there are inherent advantages (price, power usage), I don't see how that would influence a buying decision. It's nice for HTC and possibly the manufacturer, but that does not concern me.
Nice, a scientificly book on food. On the other hand anyone that is interested in quickly preparing a meal does not have to look further to the (by now very old, but venerable) "How to prepare your input" by no-one else than Andrew S. Tanenbaum (aka Andy for students/friends).
www.cs.vu.nl/~ast/home/how_to_prep.ps
Important note: Last time I saw him he still looked healthy to me :)
It's not very friendly to any other user either if you ask me.
(But the content of posts can be pretty high - as the GGP illustrates - and the moderator system usually works - somewhat. So we take the awkwardness of the editing system together with the advantages. Slashdot maintainers, that does not mean that we don't want a better editor, thank you very much.)
Yeah, but I solved that by removing all the porn from my computer at work.
Yes, and if you use units (and generally you do) then make it clear what units each parameter expects. I am in crypto and I am always guessing if things are in bits or bytes. In physics it is even more important - fortunately students of physics will probably be more inclined to describe the units they expect. Also, the names of the parameters are even more important than those in the source files. Basically, if you have e.g. a configuration file, it should be thought of as part of the user interface.
Personally I describe *what* the code does. If it contains several (small) steps, I try to put little markers in as well. If there are certain uncommon techniques I am using, or when an API call is sufficiently unclear, I document that too, but normally the code itself should be self descriptive. I refactor quite a bit during coding, it happens only a few times that I am happy with the names of the identifiers at the first go. Fortunately the Eclipse Java IDE has good support for refactoring. Finally, whenever I still have to do implement, debug or test a method I will mark it using an identifier in a comment. Currently I am using Eclipse tasks for this, using NOTE: (this class should be refactored), WARNING: (this class is not thread safe), DEBUG: (remove these System.out.println statement) and of course the dreaded TODO: (freakin' implement the stuff already). TODO: is always accompanied by an exception (in Java: throw new IllegalStateException("Not implemented")) of course.
Normally my design don't go to method level. They do normally include a system overview and a module overview though, and a view per module of how the *main* classes are related to each other. Personally I don't design each and every method - that's for the implementation phase. I'll just run JavaDoc after I've finished; at least JavaDoc is more likely to be up to date than a separate design document. You *must* document each and every method that is publicly available or that can be overwritten by a child class (protected methods in Java).
I've described Java, but the same techniques should go for any programming language (although the tool support might be lacking for most alternatives).
I spent some quality years programming basic and - later on - machine code (there weren't too many assemblers lying around I, as a kid, I didn't know about them). Then I got to high school and thought that blind, 10 finger typing would be useful. For this I had to stay at school for 2 hours without lessons (I didn't do any homework at high school, so this was a bore). Imagine my surprise when I found out that typing was done using actual *typewriters*, placed next to the computer class. Dropped it after 5 minutes, got some typing tutorials for my computer and I'm probably the fastest writer of documentation at my software engineering job.
Then again, the IDIOTS at the "Vrije Universiteit" still required me to learn emacs and VI to do compiler construction and operating systems. That didn't end well - and I still absolutely abhor text editors like those.
"If TEXAS does it, it must be E-V-I-L."
Not really, but their track record is not so good, especially regarding justice.
"But European governments are doing it too?!?!?"
Yes, and even though they do weird things, they do have a better track record.
"But it's oh-so-wonderful Google!!!"
Google has been very nice up till now, but strength tends to be abused. We should be vigilant without necessarily harming Google.
"OH NOES!!!! SOMEONE TELL ME WHAT TO THINK!!!!"
We should take a very good look at Google from time to time. The Texas attorney general is, however, probably the least competent person to do so.
I've looked up the attorney general and this part gave away what he's after:
"Defending Tort Reform
Texas has been recognized among the best in the nation at attracting new businesses and recruiting new medical personnel due to the state’s successful tort reforms. General Abbott has successfully defended legal challenges to Texas’s tort reform laws helping create a stable environment to attract new businesses and create new jobs."
This guy is not after Google to help the little man for certain. Actually, there is evil in Texas, and I might just have found a part of it.
I think we should start an inquiry about bias with Texas attorneys, not Google. It seems that they are too embedded in the old boys network to have anything to do with justice.
Look at the companies that file complaints: three companies that anyone would rather filter out than in. Seems to me that these aren't the companies that warrant the investigation. So I've got a very strong feeling this other company is behind it.
For me, this is just a big ploy to get to the page-rank algorithm. It would not be hard to leak it when the investigation starts for real.
It was better (and certainly faster) than anything before - but I don't think it was quite ready for prime time. At the end their results seemed have serious issues with it. Actually, I don't think Google is that great either - I cannot filter out all "add your own review" from the various sites. This is probably due to Google actually *not* manually altering the search results (although they have seemed to get better).
Altavista will probably always be remembered as the one that started the search engine wars for real. And Google as the winner - for now.