I don't see a fundamental difference. You don't need to fake the brain, only the transmitted "measurements".
My whole argument about biometrics security properties being tightly local is exactly the constraint needed to make an argument that you "would require compromising the target machine".
"The sensors would record the persons brain waves. Just as when registering a fingerprint for an iPhones Touch ID, multiple readings would be needed to collect a complete initial record. Our research has confirmed that a combination of pictures like this would evoke brain wave readings that are unique to a particular person, and consistent from one login attempt to another." -- TFA
This suggest that one would simply need such a "complete initial record" to pose as your brain. That would make sense as attackers and the "real" authenticator would then have the same information. You certainly don't want two different systems authenticating off the "complete initial record".
Maybe some difference in information can be maintained in a secrecy of the images show in the "real" scenario, but it should be quite hard make that difference remain. At least some of it would leek every time you authenticate.
For this to work, I think you would essentially need the brain to work as a cryptographic secure hash-function. Maybe it really does, but I think such a claim requires quite a bit more than "Our research has found that the new brain password would be very hard for attackers to figure out, even if they tried to use the old brainwave readings as an aid" and "demonstrated to provide 100% identification accuracy in a pool of 50 participants"
Biometrics cannot replace any secrets. They can, at best, be used to authenticate local presence in closed systems.
"Authentication" via remote biometric measurement carries absolutely no guarantee that actual bio was involved and thus does not have any valid security properties.
Such remote usage is *bad* both ways: An attacker can replay biometrics and a non-attacker cannot recover from biometric information copying,... ever!
Think about that every time you show your fingerprint to random scanners. You are effectively giving away your
(lifetime) biometric to the scanner so it can simulate it to the authentication software. It could choose to store and forward to others and pretend that your finger is there at will. You are effectively trusting *every* scanner not to do this.
I've read through the paper (draft) now, and it seems like they really only show correlation between a group they call Harbingers and "Failure" of products.The group of Harbingers is characterized by purchasing at a discount. soooo,
I would lean more towards a conclusion like: "Stores that experience low sales apparently place products on discount and there is individual price elasticity".
The figure on page 38 shows that "Avg. Profit relative to existing Products in the Category" has a strong bias against "products that flopped" already at *Week1* relative to "Products that survived". That is *right* away, there is a systematic bias that seems constant so if I were to look at data after that I would be *highly* suspicious about directions of causality.
In addition, most of the article is vast amounts of bread-text that seem to support circular reasoning.
Can anyone find a place where they actually come up a direction of causality?
Proving the direction of causality being *from* the "harbingers"-group picking loosers could be supported by
1. Define the set of Harbingers
2. Introduce a number of new products.
2a. in half the shops at fixed prices
2b. in half the shops let the shop set the price
3. Show that the Harbingers from step1 purchase the same relative amount of the products in scenarios 2a and 2b.
Note, Separating the two parts without interference may be hard:)
An online summary of a newspaper pay-walled newspaper reporting on an article... quoting the original with sentences like "At least, according to a group of researchers..." and "n a study published in the Journal of Marketing Research, researchers...".
Anyone have an actual link to the actual paper? I have a nagging suspicion that this may actually be an artifact of how the analysis is done.
Perhaps the security is adequate if that is the best plan.
Security is not about making absolutely sure, it's about:
1. Lowering likelyhood: Making it reasonably hard to break, so that the bad guys will go somehere else. 2. Spend wisely: Not spending more to defend that the likelyhood of loss times (value lost + value bad guys gain) (in general terms)
BTW:
a. Round up the likelyhood, the bad guys are better than you at getting ideas. b. Destroy sensitive and remove generally valuable parts to reduce the bad guys value c. The value lost is *not* the money spent on the lost property. Perhaps you wasted a small bit of effort making it? pehaps you can recreate new and better cheaper?
I think the value of the space-shuttle is mainly sentimental and image-loss on theft, so you should probably not spend more than a simple escort -- mainly to prevent traffic-problems.
Look at the libstdc++ for GCC and some of the boost project code.
That code has production quality, is written in a style that actually utilizes c++. Beware that c++ recently got quite a few new features that have not gotten too much usage in libstdc++ and boot you may want to read up on that separately.
In general, stay away from tutorials on the web, they are mostly written by people who have little or no experience and thinks they should teach the world about for loops or whatever because they just made one that doesn't crash themselves.
As a side note: that goes doubly for javascript, a much better search term to find quality code is ecmascript, unfortunatly there is no such good discriminating search-word for c++.
Today, quantum computers are *very* limited in size. The number 15 has been succesfully factored into the primes 3 and 5.
There is no really promising ways to produce large amounts (~1000) qbits. I strongly suspect that the difficulty in generating qbits is (at least) exponential in the amount of qbits to produce.
qbits cannot be composed after they creation (at least with known physics), so I am definatly *not* holding my breath for quantum computers to break RSA-2048 or AES256.
When RSA is broken (when it takes less than a few hundred years on average to find a secret key), we already have multiple other crypto-systems ready. Elliptic versions of RSA are *already* part of standard-implementations in browsers and they shift the amount of qbits required with several orders of magnitude (with known math).
Perhaps people do not appreciate what their sysadmins do because the sysadmin is not helping but hindering them?
My best experience ever with sysadmins was at DAIMI (now Department of Computer Science) at the University of Aarhus, Denmark. Perhaps you can compare what you do to them?
They ran by the priciple of freedom under responsibility (traced, of couser:) The system was not down for any annoying period of time while I was there.
Sysadmins were:
Incredibly service-minded,
Running stuf was allow-by-default, of course this was UNIX, so you could mostly trash your own stuff:)
Active logging of who spawned what and used how much CPU/disk/net, and an email asking why when you were outside the norm
Limited disk-quatas, but you could simply extend your own quota by running a command and giving a reason, the space was immediatly awarded to you for use -- if the reason was not good enough they would email you
Allowed most anything as long as it didn't interfere with the other peoples ability to use the system.
The "gateway" methodology splits the world into inside and outside, not a usefull split, since there are *always* bad guys on the inside.
However, it nicely ensures that spendings on hosting and applications is filtered through a limited number of suppliers, reducing competition and stifling innovation -- the american way;)
There needs to be more hands-on exposure to real, complex code, or better yet, production code.
I don't think so.
Exposing people to "real-world" code in a teaching siutuation kills focus on the subject. It also bogs down people in all of the bugs and problems that are not related to the subject of study.
It may well be that education is getting worse, but complexity from the real world does not make for a better education. I hear this often by people wishing for "ready-made" people from the education systems.
In the courses I took where we integrated with existing stuff (changing compilers, using modelling tools for state-spaces, partial evaluation), most of the time was spent on integrating. That time spent in integration taught me a lot about the product integrated with, but next to nothing usefull outside the context of integration with the product.
Education is a statistical invenstment in rather abstract knowledge, some of which you will apply -- with a bit of adaption, and some you may never use.
Apprenticeship can be applied to areas where knowledge is hard to quantify to abstract rules. It relies on the brain to "pick up" on things by trying to do them, getting a bit of help along the way.
You seem to suggest that the education-system should be able to solve problems that the apprenticeship model is much more suited for? Perhaps driven by a wish for "ready-made" employees from the education system?
Often, the code generated by compilers can be improved, but:
1. Does it really matter? will *anyone* notice the hours you spent optimizing?
2. How does it work on another CPU (family)? it's *really* hard to know these days, all your work may very well be in vain, or even harmfull on another CPU, especially in the IA32 architecture
Is ASM/CPU-level optimization *really* the way that you get the best competitive edge for the application/lib/...?
I enjoy doing optimizations (I'm a computer scientist with a interest in algorithms, datastructures, type-theory and all those wonderfull theoretic branches) but when working in the "software-industry", factors to success are different, and in my book they are something like:
1. Ability to fullfill customer needs
2. Ability to fullfill customer requirements (not the same as needs:)
3. Amount of bugs, and to some extent their "severity" (small bugs can easily kill large apps, not because the program crashes, but because of the human nature)
4. Time it takes to fix bugs
ASM- or CPU-level optimizations is *very* rarely the place where you can compete with others. Before *any* optimizations on the syntax level: run a profiler. A profiler gives you an idea of which part of your program (or, more likely, datastructures) you should be focusing on.
Some core math-processing, like compression/decompression, bigints and the like may benefit from ASM-level optimization but they are often outdated within a few months by newer CPU's so even there it's best to defer ASM-optimization untill the last possible minute.
If you find yourself cursing over a bad OSS compiler you may wish to contribute an analysis and optimization for it, although it's sometimes hard to get under the skin of them quickly.
A similar tax was introduced on CD and DVD in.dk to cover expenses due to a law that went along with it, allowing copying from borrowed originals, for example from libraries.
The law that allowed copying has since been revoked, but the tax is stille there.
Can I use X-SIP-provider instead of Wengo ? NO?
on
OpenWengo Code Camp
·
· Score: 1
The point in my post is that reasoning, like you did, on a boundary-condition of a discrete sectioning of continuity, doesn't make much sense.
The sectioning into species makes a lot of sense -- it makes it much easier to organize knowledge, but when applying it in boundary conditions it has no value.
Apparently, crap came first, the argument is plain stupid.
The egg clearly came first since chickens evolved from species already laying eggs.
If you ask if a specific chicken came before a specific chicken-egg, then probably yes, depending on the time of the laying/conception/[your preferred existance-deciding moment].
If you ask if a specific chicken came before it's own egg, then obvously, no, which is well-established by the laws of causality.
But, that those aside, in the more transcendal (and usual) interpretation the question doesn't make sense since development of a species is continuous and the whole concept of species is trying to break that continuous development into discrete steps. That process is bound to have boundary problems and the system of species should not be applied in those conditions.
It's really not that hard. You can stop supporting something when the interest in it's continuation is sufficiently low. This is nessesarily not an objective measure, and therefore you can't make a "list" of what to support.
For commercial software, this means when profits are too small compared to investment in continued support.
For non-commercial software, you can stop support when the main developers of the software are no longer concerned with supporting the outdated code. If someone gets concerned about the support, they can always contribute a patch that re-establishes support.
Most people who advance coding standards talk about how braces should be put and whether there should be used braces in one-line if's, maybe they even mention the horrible and feared Hungarian Notation. I have yet to find out how any of this *actually* helps understanding code.
Readable code is a prerequisite for understandable code, education is a prerequisite for understanding.
Coding-standards is trying to apply a method of syntax to an education-problem, it's not gonna work. Don't think that coding-standards will give you readability, much less understanding.
My advice is to get a few people with experience, solid, broad knowledge of the language and a pragmatic attitude to sit down and pair-program with the people who write hard-to-understand code and those who have a hard time understanding code that should have been easy to understand.
Let people present idioms, discuss patterns and create a place where "readability" is a code-quality and a goal. (BTW: Don't fall into the "everthing is a pattern"-trap) This is not a coding standard, it's an education of "this-way-works-well-for-this-and-that".
Promote knowledge of the language standard-library, instead of duplicating it yourself. Learn to shun "wrappers". Use the language-features for what they were meant to do, not for insert-really-cunning-hack-here. Model things as they are, instead of cutting coreners or adding complexity.
Check out c2.com http://c2.com/cgi/wiki?WelcomeVisitors it's really a place worth knowing. Read the dialogs, they may not all be truly insightfull but they provide you with excellent examples of what people think about in development and why it's not that easy to do-the-right-thing.
One specific thing i've found is that most people write code by copying (atleast a skeleton) from somewhere else. Accept this, and to give them something *proper* to copy from, short, complete programs -- taken from real situations, Not crappy code-project articles where people try to show off how complicated a technique they can master.
Slashdot Mirror
I don't see a fundamental difference. You don't need to fake the brain, only the transmitted "measurements".
My whole argument about biometrics security properties being tightly local is exactly the constraint needed to make an argument that you "would require compromising the target machine".
"The sensors would record the persons brain waves. Just as when registering a fingerprint for an iPhones Touch ID, multiple readings would be needed to collect a complete initial record. Our research has confirmed that a combination of pictures like this would evoke brain wave readings that are unique to a particular person, and consistent from one login attempt to another." -- TFA
This suggest that one would simply need such a "complete initial record" to pose as your brain. That would make sense as attackers and the "real" authenticator would then have the same information. You certainly don't want two different systems authenticating off the "complete initial record".
Maybe some difference in information can be maintained in a secrecy of the images show in the "real" scenario, but it should be quite hard make that difference remain. At least some of it would leek every time you authenticate.
For this to work, I think you would essentially need the brain to work as a cryptographic secure hash-function. Maybe it really does, but I think such a claim requires quite a bit more than "Our research has found that the new brain password would be very hard for attackers to figure out, even if they tried to use the old brainwave readings as an aid" and "demonstrated to provide 100% identification accuracy in a pool of 50 participants"
Biometrics cannot replace any secrets. They can, at best, be used to authenticate local presence in closed systems.
"Authentication" via remote biometric measurement carries absolutely no guarantee that actual bio was involved and thus does not have any valid security properties.
Such remote usage is *bad* both ways: An attacker can replay biometrics and a non-attacker cannot recover from biometric information copying,... ever!
Think about that every time you show your fingerprint to random scanners. You are effectively giving away your (lifetime) biometric to the scanner so it can simulate it to the authentication software. It could choose to store and forward to others and pretend that your finger is there at will. You are effectively trusting *every* scanner not to do this.
Nice angle on the story there /.
I would lean more towards a conclusion like: "Stores that experience low sales apparently place products on discount and there is individual price elasticity".
The figure on page 38 shows that "Avg. Profit relative to existing Products in the Category" has a strong bias against "products that flopped" already at *Week1* relative to "Products that survived". That is *right* away, there is a systematic bias that seems constant so if I were to look at data after that I would be *highly* suspicious about directions of causality.
In addition, most of the article is vast amounts of bread-text that seem to support circular reasoning.
Can anyone find a place where they actually come up a direction of causality?
Proving the direction of causality being *from* the "harbingers"-group picking loosers could be supported by
Note, Separating the two parts without interference may be hard :)
An online summary of a newspaper pay-walled newspaper reporting on an article... quoting the original with sentences like "At least, according to a group of researchers ..." and "n a study published in the Journal of Marketing Research, researchers ...".
Anyone have an actual link to the actual paper? I have a nagging suspicion that this may actually be an artifact of how the analysis is done.
I sincerely hope this is a prank, even if it's apparently from a biology department.
They seem to be from a biology department, not CS :)
Perhaps the security is adequate if that is the best plan.
Security is not about making absolutely sure, it's about:
1. Lowering likelyhood: Making it reasonably hard to break, so that the bad guys will go somehere else.
2. Spend wisely: Not spending more to defend that the likelyhood of loss times (value lost + value bad guys gain) (in general terms)
BTW:
a. Round up the likelyhood, the bad guys are better than you at getting ideas.
b. Destroy sensitive and remove generally valuable parts to reduce the bad guys value
c. The value lost is *not* the money spent on the lost property. Perhaps you wasted a small bit of effort making it? pehaps you can recreate new and better cheaper?
I think the value of the space-shuttle is mainly sentimental and image-loss on theft, so you should probably not spend more than a simple escort -- mainly to prevent traffic-problems.
Look at the libstdc++ for GCC and some of the boost project code.
That code has production quality, is written in a style that actually utilizes c++. Beware that c++ recently got quite a few new features that have not gotten too much usage in libstdc++ and boot you may want to read up on that separately.
There is an *excellent* FAQ on most of the fine-grained aspects of c++ at http://www.parashift.com/c++-faq-lite/
In general, stay away from tutorials on the web, they are mostly written by people who have little or no experience and thinks they should teach the world about for loops or whatever because they just made one that doesn't crash themselves.
As a side note: that goes doubly for javascript, a much better search term to find quality code is ecmascript, unfortunatly there is no such good discriminating search-word for c++.
I always kinda liked this saying by WC:
“You can always count on Americans to do the right thing - after they've tried everything else.” -- Winston Churchhill
(Actually, it applies in other places too :)
DONT PANIC!
Today, quantum computers are *very* limited in size. The number 15 has been succesfully factored into the primes 3 and 5.
There is no really promising ways to produce large amounts (~1000) qbits. I strongly suspect that the difficulty in generating qbits is (at least) exponential in the amount of qbits to produce.
qbits cannot be composed after they creation (at least with known physics), so I am definatly *not* holding my breath for quantum computers to break RSA-2048 or AES256.
When RSA is broken (when it takes less than a few hundred years on average to find a secret key), we already have multiple other crypto-systems ready. Elliptic versions of RSA are *already* part of standard-implementations in browsers and they shift the amount of qbits required with several orders of magnitude (with known math).
My best experience ever with sysadmins was at DAIMI (now Department of Computer Science) at the University of Aarhus, Denmark. Perhaps you can compare what you do to them?
They ran by the priciple of freedom under responsibility (traced, of couser :) The system was not down for any annoying period of time while I was there.
Sysadmins were:
The "gateway" methodology splits the world into inside and outside, not a usefull split, since there are *always* bad guys on the inside.
;)
However, it nicely ensures that spendings on hosting and applications is filtered through a limited number of suppliers, reducing competition and stifling innovation -- the american way
--
Helge
That's rather a blanket statement.
I learned many usefull techniques at school, and they are usefull even if *other* things are also usefull.
I don't think any of the things i learned had a negative impact on any of the items in your list. Some were even helpfull.
Specification, Management, and Quality assurance processes does not *produce* anything. You cannot "declare" applications into existance.
Why not just use monkeys and a really clear spec, an extra manger and some really rigid QA
I don't think so.
Exposing people to "real-world" code in a teaching siutuation kills focus on the subject. It also bogs down people in all of the bugs and problems that are not related to the subject of study.
It may well be that education is getting worse, but complexity from the real world does not make for a better education. I hear this often by people wishing for "ready-made" people from the education systems.
In the courses I took where we integrated with existing stuff (changing compilers, using modelling tools for state-spaces, partial evaluation), most of the time was spent on integrating. That time spent in integration taught me a lot about the product integrated with, but next to nothing usefull outside the context of integration with the product.
Education is a statistical invenstment in rather abstract knowledge, some of which you will apply -- with a bit of adaption, and some you may never use.
Apprenticeship can be applied to areas where knowledge is hard to quantify to abstract rules. It relies on the brain to "pick up" on things by trying to do them, getting a bit of help along the way.
You seem to suggest that the education-system should be able to solve problems that the apprenticeship model is much more suited for? Perhaps driven by a wish for "ready-made" employees from the education system?
Nice. Factory, Singleton, A sort of Strategy -- what a good program, that's excellent :)
;)
Perhaps, with a few refactorings, this could become the HelloWorld of tomorrow. You could declare an interface for MessageBody
And now, back to the real world.
Often, the code generated by compilers can be improved, but:
:)
1. Does it really matter? will *anyone* notice the hours you spent optimizing?
2. How does it work on another CPU (family)? it's *really* hard to know these days, all your work may very well be in vain, or even harmfull on another CPU, especially in the IA32 architecture
Is ASM/CPU-level optimization *really* the way that you get the best competitive edge for the application/lib/...?
I enjoy doing optimizations (I'm a computer scientist with a interest in algorithms, datastructures, type-theory and all those wonderfull theoretic branches) but when working in the "software-industry", factors to success are different, and in my book they are something like:
1. Ability to fullfill customer needs
2. Ability to fullfill customer requirements (not the same as needs
3. Amount of bugs, and to some extent their "severity" (small bugs can easily kill large apps, not because the program crashes, but because of the human nature)
4. Time it takes to fix bugs
ASM- or CPU-level optimizations is *very* rarely the place where you can compete with others. Before *any* optimizations on the syntax level: run a profiler. A profiler gives you an idea of which part of your program (or, more likely, datastructures) you should be focusing on.
Some core math-processing, like compression/decompression, bigints and the like may benefit from ASM-level optimization but they are often outdated within a few months by newer CPU's so even there it's best to defer ASM-optimization untill the last possible minute.
If you find yourself cursing over a bad OSS compiler you may wish to contribute an analysis and optimization for it, although it's sometimes hard to get under the skin of them quickly.
A similar tax was introduced on CD and DVD in .dk to cover expenses due to a law that went along with it, allowing copying from borrowed originals, for example from libraries.
The law that allowed copying has since been revoked, but the tax is stille there.
From the FAQ: http://www.openwengo.org/index.php/openwengo/publi c/homePage/openwengo/public/faq
Can I use <other_SIP_provider> instead of Wengo ?
This feature is planned for the NG release.
Because it's so hard to implement? it's not there yet...
I suggest you implement it -- your're going to have a hard time getting people onboard on yet another "we will be *the* VOIP provider"-scheme.
The point in my post is that reasoning, like you did, on a boundary-condition of a discrete sectioning of continuity, doesn't make much sense.
The sectioning into species makes a lot of sense -- it makes it much easier to organize knowledge, but when applying it in boundary conditions it has no value.
Yeah, you could tell by it being so funny
Apparently, crap came first, the argument is plain stupid.
The egg clearly came first since chickens evolved from species already laying eggs.
If you ask if a specific chicken came before a specific chicken-egg, then probably yes, depending on the time of the laying/conception/[your preferred existance-deciding moment].
If you ask if a specific chicken came before it's own egg, then obvously, no, which is well-established by the laws of causality.
But, that those aside, in the more transcendal (and usual) interpretation the question doesn't make sense since development of a species is continuous and the whole concept of species is trying to break that continuous development into discrete steps. That process is bound to have boundary problems and the system of species should not be applied in those conditions.
It's really not that hard. You can stop supporting something when the interest in it's continuation is sufficiently low. This is nessesarily not an objective measure, and therefore you can't make a "list" of what to support.
For commercial software, this means when profits are too small compared to investment in continued support.
For non-commercial software, you can stop support when the main developers of the software are no longer concerned with supporting the outdated code. If someone gets concerned about the support, they can always contribute a patch that re-establishes support.
Most people who advance coding standards talk about how braces should be put and whether there should be used braces in one-line if's, maybe they even mention the horrible and feared Hungarian Notation. I have yet to find out how any of this *actually* helps understanding code.
Readable code is a prerequisite for understandable code, education is a prerequisite for understanding.
Coding-standards is trying to apply a method of syntax to an education-problem, it's not gonna work. Don't think that coding-standards will give you readability, much less understanding.
My advice is to get a few people with experience, solid, broad knowledge of the language and a pragmatic attitude to sit down and pair-program with the people who write hard-to-understand code and those who have a hard time understanding code that should have been easy to understand.
Let people present idioms, discuss patterns and create a place where "readability" is a code-quality and a goal. (BTW: Don't fall into the "everthing is a pattern"-trap) This is not a coding standard, it's an education of "this-way-works-well-for-this-and-that".
Promote knowledge of the language standard-library, instead of duplicating it yourself. Learn to shun "wrappers". Use the language-features for what they were meant to do, not for insert-really-cunning-hack-here. Model things as they are, instead of cutting coreners or adding complexity.
Check out c2.com http://c2.com/cgi/wiki?WelcomeVisitors it's really a place worth knowing. Read the dialogs, they may not all be truly insightfull but they provide you with excellent examples of what people think about in development and why it's not that easy to do-the-right-thing.
One specific thing i've found is that most people write code by copying (atleast a skeleton) from somewhere else. Accept this, and to give them something *proper* to copy from, short, complete programs -- taken from real situations, Not crappy code-project articles where people try to show off how complicated a technique they can master.