Not really weighing in on the making clothes analogy, but if you wanted a thermostat to control without the cloud. The Vera Lite controller can work independent of the Internet. http://getvera.com/controllers...
While their site provides conveniences like easier connectivity without port forwarding, the entire setup can be done without any connectivity to their site. Then couple that with Z-Wave devices like this Honeywell Z-Wave Thermostat I looked up (I haven't used it, but have a Trane Z-Wave thermostat and a 2GIG Z-Wave Thermostat): http://www.homedepot.com/p/Hon...
Personally, I've been writing my own node.js based z-wave controller using a Z-Wave USB stick plugged into a Raspberry Pi. But that's only by choice. I ran the Vera Lite for a couple years and it worked fine. Admitted, this is a 2 part solution, but the Vera Lite would be your Z-Wave controller for other devices such as light switches and such. For something you can buy at Lowe's or Home Depot: http://www.lowes.com/pd_650029...
S/MIME and PGP certainly address many similar issues such as email encryption and sender authenticity (which SSL does not necessarily do by the way), they approach some of the problems in different ways. The key difference I see between the two (and why PGP still has a role in this area) is how trust of signing keys is built.
S/MIME and x.509 certificates use a central authority to enforce certificate holder identity. PGP and its variants use a "web of trust" system which allows ad hoc trust networks to build up by acquaintences sign each others keys. As an analogy, x.509 is client/server while PGP is peer-to-peer. PGP's approach serves a role for those who do not have a central authority (i.e. certificate authority) in common, do not trust CA's, cost of a certificate from a reliable CA is too high, or other factors usually centering around CA's.
The above is a general idea and there are many variations on it that make the area more fuzzy. For example, S/MIME could potentially be implemented using PGP keys instead of x.509 or PGP could be implemented to require a particular signature (i.e. a CA) in order to use a key.
Moving to BOINC can allieviate this paranoia. The new BOINC infrastructure includes the ability to use the "Anonymous Platform," which means you get to compile on your own code and simply retrieve the workunits from them. All the source is available if you don't trust the project.
I recently went to a thesis defense studying some brainwave computer interface. There seems to be a lot of interesting study going on here. This particular thesis was studying a particular type of interface that focuses on what one of the commitee members called the "ah ha!" reaction. The implemented system used a scull cap with probes like an EEG on it that targeted a particular set of waves. The user would watch a screen interface and icons representing choices would flash randomly. Whenever the icon the user wanted flashed, they were instructed to count that as a flash in their head. After enough samples were taken, that selection was made. The experiment they did involved a user having a rebotic arm make a cup of coffee. This study measured the change in brainwave at a particular period of time. Also mentioned were other studies where immediate measurement of a 'focused'/'relaxed' change in another set of brainwaves to control a cursor on the screen. Both types were also non-invasive using EEG type technolgoy. Also mentioned were current experiments in invasive brain/computer interaction where direct measurement of neurons in monkeys allowed them to control a robotic arm of some sort.
You do have the option of decentralizing some of the BOINC operations. The server side components are pretty small and flexible. Eventually some information on the workunits processed returns to the centralized database, but data distribution and assimilation can actually happen on seperate servers as long as the workunit and result records on the central database are eventually updated.
That's exactly what the parent you are replying to said. He said nothing about the option of not distributing the source. Only that it is available upon request. You are 'Bzzzz'ing and high horse calling someone who said exactly what your correction says.
One of the things the paper brings out is there is a sort of online poverty you can be born into. By entering or participating in the system later than others. One of the points brought up in the study is that those entering the system later must overcome the established top end of the power curve if they hope to be in the top end of the power curve. Not just based on the merit of their participation but to overcome the momentum of the group think and popularity. The other point is that those outside the top part of the curve are part of the lopsided large portion of the system population that is far below average.
The other point is that you mention:
Sure, sometimes elitists will mod down a post they don't agree with (asy, almost anything pro-Microsoft) but for the most part the things that get modded down are either stupid, inflamitory, insulting, off-topic etc...
points to the phenomenon that even a slight tendency for something in a large, free system with many choices will likely result in this power curve gap. Hence, the slight tendency for people to mod down anything pro-Microsoft results in what is slashdot: a place very unlikely to show any pro-Microsoft material.
The study talks directly to this "natural" phenomenon you're talking about being a little more systematic than just vanilly free will. In rating type systems like k5, slashdot, advogato, etc. "Superstars" come out of the rating system. It shows how the rating gap wouldn't just be dependent on the quality of the person being rated. Those with high ratings would likely acquire more rating and those with neutral or low ratings would continue to below average into the "power curve." The study hardly talks at all about if this is "fair" or not, but it talks extensively about the momentum of popularity, groupthink, stuff like that. I think it's even more interesting in the momentum-like barriers to entry faced by new entries into the system.
This study is showing that the popular opinion that since everyone can post anything on any system at any time gives them an equal liklihood of being heard is erroneous. Any small imbalance in probability of tending to one site or the other will likely result in the "power curve." People who feel "left out on the Web" don't need to see a psychologist, they are feeling appropriately because the rift between the heards and heard-nots is big. It's not that it's not fair, it's that our misguided notion of if everyone can speak everyone will be heard by someone is misguided in a free system with many choices.
It might be expected to some, but it does point out something counterintuitive. None of the theory in the article makes reference to everyone reading every weblog with their 24 hours in a day. It's pointing out the phenomenon of there not being a more even distribution or bell curve like distribution. From my take, a population of 10 with all 10 starting weblogs power relationships would likely lead to one having say 4 of the readers, the second place having 2, and 4 to be distributed to the other 8. The equal distribution wouldn't be all 10 reading all 10 with thier precious 24 hours of the day it would be each blog having one of the others read it. Or maybe each one getting all 10 readers during different time periods.
Despite all the smartasses who like to point out how obvious something is once someone else does all the research and writes the paper on it, a lot of that phenom is not intuitive. Most dotcom era hippies lauded the advent of the Internet as a strike against The Man and everyone would be a publisher. This paper points out that in most free systems with many choices this is very unlikely to happen. I didn't notice it when it was happening hence me posting on this godforsaken blog.
Re:Anyone notice the inherent similarities
on
Analyzing Palladium
·
· Score: 1
between this and biometric security methods. Very strong security. When the single layer is cracked, there is no backup mechanism, and resecuring and reverification of user are almost impossible.
Keep in mind though that the goal of biometrics is to authenticate yourself to your gear and software, where this seems to be an attempt for an outsider to control the authentication and integrity of your gear. Previous trends seem to indicate the former goal as having many successful, layered solutions upon which to build whereas the latter continues to show shortcomings. Examples of the former include various techniques in 2-factor authentication, cryptographic techniques such as PKI, and the venerable old password. Examples of the latter include DVD CSS v. DeCSS, Digital satellite v. set top box/smartcard hackers, and regular old cable tv. These attempts by external parties control gear under someone else's control will normally fail due to the overwhelming advantage of the adversary by being on "home turf." It is, for the most part, easier to protect stuff under your control that "wants" to be protected than trying to protect stuff outside of your control against the will of the controller. Palladium seems to outline an entire system of authentication/integrity checking in a hostile environment (your computer, not Microsoft's) whereas biometrics is a single piece (strong authentication) in a larger comprehensive security solution normally in a less hostile environment (security for you by you).
with the switch from shared to switched band Local Area Networks snooping is almost impossible anymore.
This would only apply if employees were concerned with employers snooping internal communication. Unless these employees each have a personal line to the Internet, the shared pipe out provides a pretty good perch to sniff from.
On Cisco equipment, monitoring all traffic types is only possible if you have enable priveleges. Bosses usually dont and if they do they wouldnt know how to set up the nescessary listening apps (tcp, udp).
Switched networks aside, it's not the executives that are setting up monitoring. It's the net admin. If they can't set up a sniffer they shouldn't be in charge of this stuff. They also don't need anything too specific. Even the most rudimentary sniffer will be enough to get whatever an employer wants.
Along the lines of the point to point solutions such as SSL'ed web based e-mail, hushmail and the like, you're really just upping the ante for the system administrator. The article (if anyone actually ever reads the articles slashdot references) make a good point of keystroke grabbers, etc. It's always possible for an adept admin to trojan your box for "official business." If it ain't your box, you lose. Very few ifs, ands, or buts about it. Hell, a really persistent admin can grab PGP keys out of memory and escrow:) them for you.
Bruce Schneier's new book has great stuff on these extremes and how they aren't as extreme anymore. He puts it best throughout his book with the futility of trying to protect data using as system you don't control. He mostly looks at it from the angle of the user being the attacker, but obviously the concepts apply in the reverse. This time the chump sitting at the keyboard is us.
It's pretty sad that the bulk of the messages on this article fall into one of these three categories with very few falling into the latter. The semantic messages are those that want to argue about the term 'vaporware,' 'stable v. unstable releases,' 'deadlines,' etc. The pissing matches are just my OS is better than your OS wars (especially the venom spit between Linux and *BSD users.) And then real discussion.
I found a lot of good info in the real discussion on what's going on in the latest kernel of great interest since I'm running those 'test' releases. Some of the info makes me a little edgy:).
I guess my two cents is I don't think it matters if you are in a closed source model that has 'official' releases and no access until then or an open source model where you can pretty much pick up code in progress. The real responsibility of using software and systems is on the user of that software or system. If a binary only company consistently releases buggy software and claims that it's not buggy, you can't use it. If an open source company releases code that doesn't do what you need it to, you can't use it. We sit here and complain about the state of software and noone is willing to vote with their feet (not their dollars because that doesn't apply to open source in a lot of cases.) Too many people aren't willing to give up promised features in favor of stability and correctness. People give money to companies lie microsoft despite stability and correctness issues encouraging them to release software too soon. People use 'bleeding-edge' kernels because they want better SMP support or devfs or USB support despite the clear message that anything with an odd middle part of their version or 'test' or 'pre' in the version is asking for trouble. Once they get what they ask, demand, and whine all day about, they turn right around and cry about how something doesn't work or isn't the quality they want.
Be careful what you ask for, you just might get it. The people making the software aren't the ones who should change (e.g. open vs. closed source), it's the people using the software that should change.
1) Database passwords, admin passwords, ANY passwords shouldn't be stored on the Web server in plaintext.
How should authentication credentials be stored on the web server? If you own the server or are exploiting a part of it, you are accessing as the web server process. If the web server process can legitimately access the database, why can't the exploit? How do you propose storing the credentials, encryption? Then the key must be stored to decrypt to use the credentials. Attacker gets key instead of the credential, what's the difference. Store them hashed? If hashed credentials are sufficient for access, then obtaining the hash is just like obtaining credentials. Even storing credentials in a tamperproof device is useless if the web server process is performing the access.
It's not as dramatic as an architecture flaw of IIS. It's an implementation flaw. Credentials that are stored should have minimal access.
2) If an application management interface exists at all on the Web server (which I have some problems with), it should always run on a different port than the application itself and that port should be firewalled such that it can only be accessed from trusted (internal) IPs. The content directory structures for the application and application management should also be segregated.
What in-band application management interface exists inherently in the IIS architecture? Most exploits along these lines involve optional interfaces such as RDS, FrontPage Extensions, RAD tools, etc.
Again the dramatic rant is just glorifying yet another bad implementation of tools. The article and details do not give enough information as to how much of this exploit was due to bad choices of options, configuration, or strictly a software bug. If it's a bug, software has bugs and should be fixed and damage minimized. Damage could have been minimized or could have been rampant in this case regardless of the tools (IIS, Apache, etc.)
Again, regarding all the access control design you mention, I don't see how most of that relates to the architecture of IIS.
I'm no lover of IIS or any other web server at that. Any of the tools can be used correctly and minimize risk or incorrectly and hang your ass out. I also believe that IIS is conducive to bad administration due to its point and click mentality. I have to speak up however when people rant about inherent flaws, vulnerabilities, etc.
"Forty" was often used in the original languages of the region to poetically denote a big number.
This style was also reawakened by the modern rapper to denote large amounts of Malt Liquor. Usually Old English 800 or Colt 45.
Back on topic. The parent of this message suggested using Carnivore like engines to stop DOS types of attacks. If you mean a bridge like engine to filter traffic, this becomes dangerous because of the false positives generated by legitimate traffic matching attack signatures. With more and more big pipes going to normal users, how do you propose to distinguish between real traffic and malicious traffic? If you were referring to government sponsored engines like Carnivore, obviously the plot simply thickens.
Also, I find it interesting the posts regarding this article are split between "this system will never work," and "Linux has had this for years in the form of SYN Cookies." So which is it slashdot? Naysayer touting how smart they are or blind Linux zealotry?
Slashdot Mirror
Not really weighing in on the making clothes analogy, but if you wanted a thermostat to control without the cloud. The Vera Lite controller can work independent of the Internet.
http://getvera.com/controllers...
While their site provides conveniences like easier connectivity without port forwarding, the entire setup can be done without any connectivity to their site. Then couple that with Z-Wave devices like this Honeywell Z-Wave Thermostat I looked up (I haven't used it, but have a Trane Z-Wave thermostat and a 2GIG Z-Wave Thermostat):
http://www.homedepot.com/p/Hon...
Personally, I've been writing my own node.js based z-wave controller using a Z-Wave USB stick plugged into a Raspberry Pi. But that's only by choice. I ran the Vera Lite for a couple years and it worked fine. Admitted, this is a 2 part solution, but the Vera Lite would be your Z-Wave controller for other devices such as light switches and such. For something you can buy at Lowe's or Home Depot:
http://www.lowes.com/pd_650029...
S/MIME and PGP certainly address many similar issues such as email encryption and sender authenticity (which SSL does not necessarily do by the way), they approach some of the problems in different ways. The key difference I see between the two (and why PGP still has a role in this area) is how trust of signing keys is built.
S/MIME and x.509 certificates use a central authority to enforce certificate holder identity. PGP and its variants use a "web of trust" system which allows ad hoc trust networks to build up by acquaintences sign each others keys. As an analogy, x.509 is client/server while PGP is peer-to-peer. PGP's approach serves a role for those who do not have a central authority (i.e. certificate authority) in common, do not trust CA's, cost of a certificate from a reliable CA is too high, or other factors usually centering around CA's.
The above is a general idea and there are many variations on it that make the area more fuzzy. For example, S/MIME could potentially be implemented using PGP keys instead of x.509 or PGP could be implemented to require a particular signature (i.e. a CA) in order to use a key.
Moving to BOINC can allieviate this paranoia. The new BOINC infrastructure includes the ability to use the "Anonymous Platform," which means you get to compile on your own code and simply retrieve the workunits from them. All the source is available if you don't trust the project.
I recently went to a thesis defense studying some brainwave computer interface. There seems to be a lot of interesting study going on here. This particular thesis was studying a particular type of interface that focuses on what one of the commitee members called the "ah ha!" reaction. The implemented system used a scull cap with probes like an EEG on it that targeted a particular set of waves. The user would watch a screen interface and icons representing choices would flash randomly. Whenever the icon the user wanted flashed, they were instructed to count that as a flash in their head. After enough samples were taken, that selection was made. The experiment they did involved a user having a rebotic arm make a cup of coffee. This study measured the change in brainwave at a particular period of time. Also mentioned were other studies where immediate measurement of a 'focused'/'relaxed' change in another set of brainwaves to control a cursor on the screen. Both types were also non-invasive using EEG type technolgoy. Also mentioned were current experiments in invasive brain/computer interaction where direct measurement of neurons in monkeys allowed them to control a robotic arm of some sort.
You do have the option of decentralizing some of the BOINC operations. The server side components are pretty small and flexible. Eventually some information on the workunits processed returns to the centralized database, but data distribution and assimilation can actually happen on seperate servers as long as the workunit and result records on the central database are eventually updated.
That's exactly what the parent you are replying to said. He said nothing about the option of not distributing the source. Only that it is available upon request. You are 'Bzzzz'ing and high horse calling someone who said exactly what your correction says.
Haha that was fresh.
Direct, participatory democracy does scale, just not in the way most people thinks it does.
One of the things the paper brings out is there is a sort of online poverty you can be born into. By entering or participating in the system later than others. One of the points brought up in the study is that those entering the system later must overcome the established top end of the power curve if they hope to be in the top end of the power curve. Not just based on the merit of their participation but to overcome the momentum of the group think and popularity. The other point is that those outside the top part of the curve are part of the lopsided large portion of the system population that is far below average.
The other point is that you mention:
- Sure, sometimes elitists will mod down a post they don't agree with (asy, almost anything pro-Microsoft) but for the most part the things that get modded down are either stupid, inflamitory, insulting, off-topic etc...
points to the phenomenon that even a slight tendency for something in a large, free system with many choices will likely result in this power curve gap. Hence, the slight tendency for people to mod down anything pro-Microsoft results in what is slashdot: a place very unlikely to show any pro-Microsoft material.This is a great post that hits the story's point on the head.
The study talks directly to this "natural" phenomenon you're talking about being a little more systematic than just vanilly free will. In rating type systems like k5, slashdot, advogato, etc. "Superstars" come out of the rating system. It shows how the rating gap wouldn't just be dependent on the quality of the person being rated. Those with high ratings would likely acquire more rating and those with neutral or low ratings would continue to below average into the "power curve." The study hardly talks at all about if this is "fair" or not, but it talks extensively about the momentum of popularity, groupthink, stuff like that. I think it's even more interesting in the momentum-like barriers to entry faced by new entries into the system.
This study is showing that the popular opinion that since everyone can post anything on any system at any time gives them an equal liklihood of being heard is erroneous. Any small imbalance in probability of tending to one site or the other will likely result in the "power curve." People who feel "left out on the Web" don't need to see a psychologist, they are feeling appropriately because the rift between the heards and heard-nots is big. It's not that it's not fair, it's that our misguided notion of if everyone can speak everyone will be heard by someone is misguided in a free system with many choices.
It might be expected to some, but it does point out something counterintuitive. None of the theory in the article makes reference to everyone reading every weblog with their 24 hours in a day. It's pointing out the phenomenon of there not being a more even distribution or bell curve like distribution. From my take, a population of 10 with all 10 starting weblogs power relationships would likely lead to one having say 4 of the readers, the second place having 2, and 4 to be distributed to the other 8. The equal distribution wouldn't be all 10 reading all 10 with thier precious 24 hours of the day it would be each blog having one of the others read it. Or maybe each one getting all 10 readers during different time periods.
Despite all the smartasses who like to point out how obvious something is once someone else does all the research and writes the paper on it, a lot of that phenom is not intuitive. Most dotcom era hippies lauded the advent of the Internet as a strike against The Man and everyone would be a publisher. This paper points out that in most free systems with many choices this is very unlikely to happen. I didn't notice it when it was happening hence me posting on this godforsaken blog.
Keep in mind though that the goal of biometrics is to authenticate yourself to your gear and software, where this seems to be an attempt for an outsider to control the authentication and integrity of your gear. Previous trends seem to indicate the former goal as having many successful, layered solutions upon which to build whereas the latter continues to show shortcomings. Examples of the former include various techniques in 2-factor authentication, cryptographic techniques such as PKI, and the venerable old password. Examples of the latter include DVD CSS v. DeCSS, Digital satellite v. set top box/smartcard hackers, and regular old cable tv. These attempts by external parties control gear under someone else's control will normally fail due to the overwhelming advantage of the adversary by being on "home turf." It is, for the most part, easier to protect stuff under your control that "wants" to be protected than trying to protect stuff outside of your control against the will of the controller.
Palladium seems to outline an entire system of authentication/integrity checking in a hostile environment (your computer, not Microsoft's) whereas biometrics is a single piece (strong authentication) in a larger comprehensive security solution normally in a less hostile environment (security for you by you).
This would only apply if employees were concerned with employers snooping internal communication. Unless these employees each have a personal line to the Internet, the shared pipe out provides a pretty good perch to sniff from.
Switched networks aside, it's not the executives that are setting up monitoring. It's the net admin. If they can't set up a sniffer they shouldn't be in charge of this stuff. They also don't need anything too specific. Even the most rudimentary sniffer will be enough to get whatever an employer wants.
Along the lines of the point to point solutions such as SSL'ed web based e-mail, hushmail and the like, you're really just upping the ante for the system administrator. The article (if anyone actually ever reads the articles slashdot references) make a good point of keystroke grabbers, etc. It's always possible for an adept admin to trojan your box for "official business." If it ain't your box, you lose. Very few ifs, ands, or buts about it. Hell, a really persistent admin can grab PGP keys out of memory and escrow :) them for you.
Bruce Schneier's new book has great stuff on these extremes and how they aren't as extreme anymore. He puts it best throughout his book with the futility of trying to protect data using as system you don't control. He mostly looks at it from the angle of the user being the attacker, but obviously the concepts apply in the reverse. This time the chump sitting at the keyboard is us.
If it ain't yours, don't trust it.
StephenIt's pretty sad that the bulk of the messages on this article fall into one of these three categories with very few falling into the latter. The semantic messages are those that want to argue about the term 'vaporware,' 'stable v. unstable releases,' 'deadlines,' etc. The pissing matches are just my OS is better than your OS wars (especially the venom spit between Linux and *BSD users.) And then real discussion.
:).
I found a lot of good info in the real discussion on what's going on in the latest kernel of great interest since I'm running those 'test' releases. Some of the info makes me a little edgy
I guess my two cents is I don't think it matters if you are in a closed source model that has 'official' releases and no access until then or an open source model where you can pretty much pick up code in progress. The real responsibility of using software and systems is on the user of that software or system. If a binary only company consistently releases buggy software and claims that it's not buggy, you can't use it. If an open source company releases code that doesn't do what you need it to, you can't use it. We sit here and complain about the state of software and noone is willing to vote with their feet (not their dollars because that doesn't apply to open source in a lot of cases.) Too many people aren't willing to give up promised features in favor of stability and correctness. People give money to companies lie microsoft despite stability and correctness issues encouraging them to release software too soon. People use 'bleeding-edge' kernels because they want better SMP support or devfs or USB support despite the clear message that anything with an odd middle part of their version or 'test' or 'pre' in the version is asking for trouble. Once they get what they ask, demand, and whine all day about, they turn right around and cry about how something doesn't work or isn't the quality they want.
Be careful what you ask for, you just might get it. The people making the software aren't the ones who should change (e.g. open vs. closed source), it's the people using the software that should change.
How should authentication credentials be stored on the web server? If you own the server or are exploiting a part of it, you are accessing as the web server process. If the web server process can legitimately access the database, why can't the exploit? How do you propose storing the credentials, encryption? Then the key must be stored to decrypt to use the credentials. Attacker gets key instead of the credential, what's the difference. Store them hashed? If hashed credentials are sufficient for access, then obtaining the hash is just like obtaining credentials. Even storing credentials in a tamperproof device is useless if the web server process is performing the access.
It's not as dramatic as an architecture flaw of IIS. It's an implementation flaw. Credentials that are stored should have minimal access.
What in-band application management interface exists inherently in the IIS architecture? Most exploits along these lines involve optional interfaces such as RDS, FrontPage Extensions, RAD tools, etc.
Again the dramatic rant is just glorifying yet another bad implementation of tools. The article and details do not give enough information as to how much of this exploit was due to bad choices of options, configuration, or strictly a software bug. If it's a bug, software has bugs and should be fixed and damage minimized. Damage could have been minimized or could have been rampant in this case regardless of the tools (IIS, Apache, etc.)
Again, regarding all the access control design you mention, I don't see how most of that relates to the architecture of IIS.
I'm no lover of IIS or any other web server at that. Any of the tools can be used correctly and minimize risk or incorrectly and hang your ass out. I also believe that IIS is conducive to bad administration due to its point and click mentality. I have to speak up however when people rant about inherent flaws, vulnerabilities, etc.
Stephen"Forty" was often used in the original languages of the region to poetically denote a big number.
This style was also reawakened by the modern rapper to denote large amounts of Malt Liquor. Usually Old English 800 or Colt 45.
Back on topic. The parent of this message suggested using Carnivore like engines to stop DOS types of attacks. If you mean a bridge like engine to filter traffic, this becomes dangerous because of the false positives generated by legitimate traffic matching attack signatures. With more and more big pipes going to normal users, how do you propose to distinguish between real traffic and malicious traffic? If you were referring to government sponsored engines like Carnivore, obviously the plot simply thickens.
Also, I find it interesting the posts regarding this article are split between "this system will never work," and "Linux has had this for years in the form of SYN Cookies." So which is it slashdot? Naysayer touting how smart they are or blind Linux zealotry?