Mathematics isn't really that different from prose. Theorems naturally follow from the axioms of the logic, so in a very real sense theorems are discoveries. All possible theorems are effectively fixed when the axioms of a logic are defined.
Equivalently, prose naturally follows from a sequence of words constructed from a vocabularly according to some grammar. All grammatically correct phrases are also fixed by that vocabularly and that grammar.
So really, prose and math are both discoveries in a very real sense. Now the question is: are axioms and grammars discoveries or inventions? I argued earlier that the answer is "both".
To claim that purely abstract concepts that have no representation in the physical world are discovered pretty much necessitates belief in a Platonic 'world of ideas'.
Then again, we might all be surprised what shows up in the real world. Certainly previously "purely theoretical" developments have been found in real phenomena.
but clearly mathmatics doesn't exist as some kind of absolute form.
The meaning of "exists" unnecessarily complicates any argument pertaining to math and logic. All theorems in math and logic follow directly from the axioms upon which it is founded. So all theorems are discoveries. The axioms themselves are often postulated, or invented, by observing something in the world around us, or a relationship in another math or logic. So axioms too are both invented, and discovered.
the egg comes first folks since the first instance of what we define as "a chicken" was a genetic aberration born to a non-chicken
The egg the first chicken hatched from was NOT a chicken egg though, it was an egg from the chicken's progenitor, as the hen constructs the eggs not the embryo (assuming it was hatched at all, and if it wasn't the chicken comes first anyway). The egg material and structure of the chicken's progenitor could differ from its mutated offspring, thus, a chicken hatched from its progenitor's egg, not from a chicken egg. This same argument can be extended inductively back to the creation of the first egg-bearing species, likely a singular or multi-cellular organism, from its a progentior, a non egg-bearing species, by whatever mechanism its progenitor reproduces. So in fact, contrary to popular belief, and your own deductive reasoning, the chicken came first.
Math is a tool [...] where the ideas have come from observing the world around us
You said it. Math and logic was discovered by observing the world around us, and the comonolity in many of these observed relationships was factored out into an invented symbolic language. So math and logic was both invented, and discovered.
All patent submissions must be accompanied by a physical prototype. The requirement for a physical device has fallen by the wayside, and reintroducing it would probably eliminate 99% of these silly applications.
Increasing patent fees is not the way forward, as this penalizes the real innovators: the little guys working out of their garage.
what should be banned are those useless coders who think that a language should do everything for you, thus making you lazy and bloated like your code.
While I can sympathize, that's just uncalled for. There are good reasons for introducing higher-level constructs which handle the aspects of programming that humans are bad at (memory management for instance), thus freeing them to handle the aspects of programming that they're actually good at (algorithm design).
Anyone who thinks otherwise is honestly deluded. C/C++ have their place in some low-level systems, though I would argue that Ada is probably a better choice in almost every case, but its prevalence in so much high-level application software is just negligent IMO. Software written in C/C++ will always have vulnerabilities unless it's subject to costly security audits, which almost no one will do, or the C/C++ compiler itself injects code to prevent such attacks (as many research projects are currently attempting to do).
I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!
Indeed, but these programmers are failing to heed age-old wisdom: detect errors at a low-level, handle them at a high level. Return values don't encourage this program structure, where "correct" code ends up being quite hairy due to all of the error passing.
Exceptions allow low-level errors to propagate to higher-level code which can abort the request, and retry it at a later date. That's what those programmers should have done: just let the error propagate. This is especially true of memory exhaustion errors. Exceptions are better than return values for larger programs. So the misuse of exceptions is a programmer problem, not a problem with the mechanism itself.
Mind you, if Address Space Layout Randomisation was turned on in the Flash executable on Vista, exploiting this hole would most likely (255 times out of 256) lead to a browser crash rather than arbitrary code execution
Are you sure about that? My skimming gave me the impression that all addressing used in this exploit was relative, which means address space randomization wouldn't have helped. Randomization just randomly places dynamically linked libraries, the start of the heap, and the stack, but that doesn't affect exploits on blobs of memory addressed using a relative offset.
Re:Skill and not language used?
on
The Return of Ada
·
· Score: 4, Funny
Let's imagine a language so obscure and difficult, that 90% of working programmers cannot gain sufficient mastery of it to understand what it is saying at first glance.
Wouldn't work. C++ is just such a language for example, but this provides no such barrier to poor programmers and poor code!;-)
Well, that and Ada's I/O is pretty terrible. Ever try reading in and storing an arbitrary length string? I'm fairly convinced it's not possible in Ada.
Show me some hardware that can do that, and it'll be a valid criticism. I believe the criticism you meant to level, was a dynamically sized string. This indeed was more difficult, but not at all impossible. I learned Ada95, and you could do it at least with the libraries available in that revision. Ada 2005 also fixed many such shortcomings in the standard library. Ada even has closures now!
Just provide a Petname toolbar. All the anti-phishing you'll ever need, and it doesn't submit your URLs or browsing info to third-party servers, like the Google toolbar and Microsoft's "anti-phishing" extensions do (a technique which will ultimately prove ineffectual IMO).
I forgot to mention earlier thoug, that quite often my sale will be deadlocked because another user is changing something. That might be more of an MSSQL-situation though.
From the descriptions the consultant gave me, this shouldn't happen. Nav is supposed to use row-level locking, not table-level. Perhaps that's one of the improvements in 5.0. Thanks for the input! I'm going to search online a bit more thoroughly to see if I can find any more testimonials like this and check out the specific changes in 5.0 to see if they've addressed these shortcomings.
Yup, Nav is modular. I know they released a new version in 2007, which they tout as a major improvement. I wasn't planning on using Nav for quoting or sales, as we already have custom software for that. I was interested in Nav primarily for the inventory management, accounting, bills of materials, and logistics; basically, order processing and accounting.
Inventory is NEVER right
Hmm, I suppose it depends what you mean by this. In my experience, inventory numbers are NEVER right because there are so many human factors involved (oh, we had to trash that one because it was damaged.. oh, we stopped using part Y in model X for reason Z, etc.). Periodic physical inventories are the only way to get truly accurate numbers in my experience. Of course, the company I've been working with does custom manufacturing, so finished products are rarely stocked, if ever. I can see how having wrong inventory numbers for "stock" merchandise would be a deal breaker. What sort of inventory do you deal with and what sorts of problems does Nav produce in these numbers?
Why would you use an ERP system on your point-of-sales systems? Perhaps you're thinking of another product. If not, some detail as to why you consider it crap would be appreciated. You can't please all of the people all of the time, but if there are some serious flaws I don't know about, I'm all ears.
Stupid MS branding. Microsoft Dynamics isn't actually a product, but a "suite" of products. The product you are referring to is MS Dynamics GP, formerly known as Great Plains, and the software I'm referring to is MS Dynamics NAV, formerly known as Navision and built in Denmark. Navision is most definitely suitable for medium+ sized businesses, and it's a good product from the presentations I've seen. Whether SAP was really designed to be anything but horrible is questionable.
Microsoft already has an SAP-like product line: Microsoft Dynamics. It's a better product built by a European company that MS bought out a few years ago. Why would MS buy SAP if they already have something better?
a) no mention of Bacon is made on the cycle collector page. b) it labels the collector conservative, where Bacon's is accurate. c) it mentions that your collector might fail to collect a garbage cycle, where by my recollection, Bacon's did not suffer this problem. Are you sure you're using Bacon's cycle collector? Perhaps these are simply the limitations of using C++. d) why all the different collectors? Why not just use Efficient On-the-Fly Cycle Collection and be done with it? It's not quite as performant as a generational tracing collector, but at least your code won't suffer so many impedance mismatches, and thus be easier to maintain and extend.
Why did they invent some ad-hoc cycle collection technique, when David Bacon designed a great one way back in 2001? Bacon's technique is even mentioned on the wikipedia page for reference counting!
I would say the user authenticates to the system using the token - something the user has.
But if this token were a YURL, ala Waterken web-calculus, then it's actually considered a capability. I think the correct way to look at it, is an authorization with an authentication step. Whatever system you plug it into must validate the token to ensure it names a resource on the current system (a sort of authentication), then invoke that resource to resume the session. YURLs go through this same process, as all services must validate data from untrusted sources. I think the important property is that it behaves like a capability to the user, so I'm not sure that it behaves like an authentication as you say.
You don't identify yourself to a car, you simply use a key (password), the car doesn't care who you are, nor does it need to. You can give out copies of the keys or loan the keys to someone else so they can drive your car. Same goes for the combination to a combination padlock for a bicycle-- the lock doesn't care who anyone is. Have I understood what you're getting at, naasking? Capability based security is much like password only access? Like keys to a car?
You pretty much have it. The "capabilities as keys" analogy has been used extensively before, and its accurate to a first approximation. Capabilities have stronger security properties than keys though, so don't take the metaphor too far. Here's a paper discussing the various forms of capabilities and debunking the myths promulgated about them over the years.
And using only a password to authenticate is also a good idea, provided the password is a cryptographically secure identifier.
I'm guessing that multi-user networked systems probably present the most interesting (and complicated) discussion.
If by "multi-user networked systems" you mean systems which host multiple competing interests which are mutually suspicious, then I agree. The vast majority of systems are computer programs communicating with other computer programs, some at the behest of a single user or multiple users, some based on a schedule, etc. If you can solve the problem of safe collaboration among mutually suspicious programs, then any other interaction I can think of falls out as a special case.
Part of the challenge (at least on the surface) is that in the case of an incoming network connection, the distinction between a "user" and a "program" seems a bit abstract.
Exactly, because there is no tangible distinction. Any "user" is communicating with you via some program, presumably under his control. It's programs all the way down.
I wno't try to go too far into those questions without first checking through the resources you've pointed to, which will take me some time.
I would note, though, that many industries operate under regulations that require authentication. This may partially be due to bad assumptions on the part of regulators.
Obviously I can't comment on any specifics without researching further, so you could be right. I would be disappointed if such legislation mandated a specific strategy to track information, rather than simply mandate that certain information be available should it be needed.
However, it also points toward a second reason why people use authentication: Sometimes it's not enough to know that an action is authorized; sometimes you have to keep track of who took each action.
Agreed! Delegation control and responsibility tracking are very important, which is why some capability folks designed Horton, which can be viewed as a sort of identity framework built on top of pure capabilities. Identities should only be used for reactive measures however, in case of abuse to identify the offending party and throttle or terminate abuse.
So, while you can decouple authentication from authorization to a point, I would still think you'd sometimes have to state "user has provided accurate identification" as a prerequisite of authorization (even if the authorization process isn't looking for any particular identity).
Whether the user/program intentionally or accidentally leaked his capability, you still have to revoke it to prevent abuse. I'm not sure what authentication gains you here. Identifying the capability is typically straightforward.
That said, I do think these make up a third category in this sense: Although they may be good candidates for a capability-based system, it remains true that I wouldn't generally "trust" a user as far as I could throw him.
Yes, there are no doubt other categories of systems. For instance, the KeyKOS capability operating system was used in early ATM systems starting in the 80s. I'm sure it had something to say on the subject. I hope you have time to research the rich literature of capability access control.:-)
Slashdot Mirror
But then mathematics is different from prose
Mathematics isn't really that different from prose. Theorems naturally follow from the axioms of the logic, so in a very real sense theorems are discoveries. All possible theorems are effectively fixed when the axioms of a logic are defined.
Equivalently, prose naturally follows from a sequence of words constructed from a vocabularly according to some grammar. All grammatically correct phrases are also fixed by that vocabularly and that grammar.
So really, prose and math are both discoveries in a very real sense. Now the question is: are axioms and grammars discoveries or inventions? I argued earlier that the answer is "both".
To claim that purely abstract concepts that have no representation in the physical world are discovered pretty much necessitates belief in a Platonic 'world of ideas'.
Then again, we might all be surprised what shows up in the real world. Certainly previously "purely theoretical" developments have been found in real phenomena.
but clearly mathmatics doesn't exist as some kind of absolute form.
The meaning of "exists" unnecessarily complicates any argument pertaining to math and logic. All theorems in math and logic follow directly from the axioms upon which it is founded. So all theorems are discoveries. The axioms themselves are often postulated, or invented, by observing something in the world around us, or a relationship in another math or logic. So axioms too are both invented, and discovered.
the egg comes first folks since the first instance of what we define as "a chicken" was a genetic aberration born to a non-chicken
The egg the first chicken hatched from was NOT a chicken egg though, it was an egg from the chicken's progenitor, as the hen constructs the eggs not the embryo (assuming it was hatched at all, and if it wasn't the chicken comes first anyway). The egg material and structure of the chicken's progenitor could differ from its mutated offspring, thus, a chicken hatched from its progenitor's egg, not from a chicken egg. This same argument can be extended inductively back to the creation of the first egg-bearing species, likely a singular or multi-cellular organism, from its a progentior, a non egg-bearing species, by whatever mechanism its progenitor reproduces. So in fact, contrary to popular belief, and your own deductive reasoning, the chicken came first.
Math is a tool [...] where the ideas have come from observing the world around us
You said it. Math and logic was discovered by observing the world around us, and the comonolity in many of these observed relationships was factored out into an invented symbolic language. So math and logic was both invented, and discovered.
such as business method patents. It would be easy to make prototypes of stupid computer patents (e.g., Amazon's one-click), so those are still in
No, the Supreme Court has repeatedly ruled that software simply running on a physical device is not eligible for a patent.
All patent submissions must be accompanied by a physical prototype. The requirement for a physical device has fallen by the wayside, and reintroducing it would probably eliminate 99% of these silly applications.
Increasing patent fees is not the way forward, as this penalizes the real innovators: the little guys working out of their garage.
Understood. Tools to assist in profiling still have a long way to go to help the hapless developers.
Excellent point! We'll never be sure without proof-carrying code, which raises the bar for attack to extraordinary levels.
what should be banned are those useless coders who think that a language should do everything for you, thus making you lazy and bloated like your code.
While I can sympathize, that's just uncalled for. There are good reasons for introducing higher-level constructs which handle the aspects of programming that humans are bad at (memory management for instance), thus freeing them to handle the aspects of programming that they're actually good at (algorithm design).
Anyone who thinks otherwise is honestly deluded. C/C++ have their place in some low-level systems, though I would argue that Ada is probably a better choice in almost every case, but its prevalence in so much high-level application software is just negligent IMO. Software written in C/C++ will always have vulnerabilities unless it's subject to costly security audits, which almost no one will do, or the C/C++ compiler itself injects code to prevent such attacks (as many research projects are currently attempting to do).
I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!
Indeed, but these programmers are failing to heed age-old wisdom: detect errors at a low-level, handle them at a high level. Return values don't encourage this program structure, where "correct" code ends up being quite hairy due to all of the error passing.
Exceptions allow low-level errors to propagate to higher-level code which can abort the request, and retry it at a later date. That's what those programmers should have done: just let the error propagate. This is especially true of memory exhaustion errors. Exceptions are better than return values for larger programs. So the misuse of exceptions is a programmer problem, not a problem with the mechanism itself.
Mind you, if Address Space Layout Randomisation was turned on in the Flash executable on Vista, exploiting this hole would most likely (255 times out of 256) lead to a browser crash rather than arbitrary code execution
Are you sure about that? My skimming gave me the impression that all addressing used in this exploit was relative, which means address space randomization wouldn't have helped. Randomization just randomly places dynamically linked libraries, the start of the heap, and the stack, but that doesn't affect exploits on blobs of memory addressed using a relative offset.
Let's imagine a language so obscure and difficult, that 90% of working programmers cannot gain sufficient mastery of it to understand what it is saying at first glance.
;-)
Wouldn't work. C++ is just such a language for example, but this provides no such barrier to poor programmers and poor code!
Well, that and Ada's I/O is pretty terrible. Ever try reading in and storing an arbitrary length string? I'm fairly convinced it's not possible in Ada.
Show me some hardware that can do that, and it'll be a valid criticism. I believe the criticism you meant to level, was a dynamically sized string. This indeed was more difficult, but not at all impossible. I learned Ada95, and you could do it at least with the libraries available in that revision. Ada 2005 also fixed many such shortcomings in the standard library. Ada even has closures now!
I am not seeing a C++ example in your link. Generic syntax is there, example? not really.
Personally, I'm glad the MS docs don't cater to the program-by-copy-paste crowd.
Just provide a Petname toolbar. All the anti-phishing you'll ever need, and it doesn't submit your URLs or browsing info to third-party servers, like the Google toolbar and Microsoft's "anti-phishing" extensions do (a technique which will ultimately prove ineffectual IMO).
I forgot to mention earlier thoug, that quite often my sale will be deadlocked because another user is changing something. That might be more of an MSSQL-situation though.
From the descriptions the consultant gave me, this shouldn't happen. Nav is supposed to use row-level locking, not table-level. Perhaps that's one of the improvements in 5.0. Thanks for the input! I'm going to search online a bit more thoroughly to see if I can find any more testimonials like this and check out the specific changes in 5.0 to see if they've addressed these shortcomings.
Yup, Nav is modular. I know they released a new version in 2007, which they tout as a major improvement. I wasn't planning on using Nav for quoting or sales, as we already have custom software for that. I was interested in Nav primarily for the inventory management, accounting, bills of materials, and logistics; basically, order processing and accounting.
Inventory is NEVER right
Hmm, I suppose it depends what you mean by this. In my experience, inventory numbers are NEVER right because there are so many human factors involved (oh, we had to trash that one because it was damaged.. oh, we stopped using part Y in model X for reason Z, etc.). Periodic physical inventories are the only way to get truly accurate numbers in my experience. Of course, the company I've been working with does custom manufacturing, so finished products are rarely stocked, if ever. I can see how having wrong inventory numbers for "stock" merchandise would be a deal breaker. What sort of inventory do you deal with and what sorts of problems does Nav produce in these numbers?
Why would you use an ERP system on your point-of-sales systems? Perhaps you're thinking of another product. If not, some detail as to why you consider it crap would be appreciated. You can't please all of the people all of the time, but if there are some serious flaws I don't know about, I'm all ears.
Stupid MS branding. Microsoft Dynamics isn't actually a product, but a "suite" of products. The product you are referring to is MS Dynamics GP, formerly known as Great Plains, and the software I'm referring to is MS Dynamics NAV, formerly known as Navision and built in Denmark. Navision is most definitely suitable for medium+ sized businesses, and it's a good product from the presentations I've seen. Whether SAP was really designed to be anything but horrible is questionable.
Microsoft already has an SAP-like product line: Microsoft Dynamics. It's a better product built by a European company that MS bought out a few years ago. Why would MS buy SAP if they already have something better?
a) no mention of Bacon is made on the cycle collector page.
b) it labels the collector conservative, where Bacon's is accurate.
c) it mentions that your collector might fail to collect a garbage cycle, where by my recollection, Bacon's did not suffer this problem. Are you sure you're using Bacon's cycle collector? Perhaps these are simply the limitations of using C++.
d) why all the different collectors? Why not just use Efficient On-the-Fly Cycle Collection and be done with it? It's not quite as performant as a generational tracing collector, but at least your code won't suffer so many impedance mismatches, and thus be easier to maintain and extend.
Why did they invent some ad-hoc cycle collection technique, when David Bacon designed a great one way back in 2001? Bacon's technique is even mentioned on the wikipedia page for reference counting!
I would say the user authenticates to the system using the token - something the user has.
But if this token were a YURL, ala Waterken web-calculus, then it's actually considered a capability. I think the correct way to look at it, is an authorization with an authentication step. Whatever system you plug it into must validate the token to ensure it names a resource on the current system (a sort of authentication), then invoke that resource to resume the session. YURLs go through this same process, as all services must validate data from untrusted sources. I think the important property is that it behaves like a capability to the user, so I'm not sure that it behaves like an authentication as you say.
You don't identify yourself to a car, you simply use a key (password), the car doesn't care who you are, nor does it need to. You can give out copies of the keys or loan the keys to someone else so they can drive your car. Same goes for the combination to a combination padlock for a bicycle-- the lock doesn't care who anyone is. Have I understood what you're getting at, naasking? Capability based security is much like password only access? Like keys to a car?
You pretty much have it. The "capabilities as keys" analogy has been used extensively before, and its accurate to a first approximation. Capabilities have stronger security properties than keys though, so don't take the metaphor too far. Here's a paper discussing the various forms of capabilities and debunking the myths promulgated about them over the years.
And using only a password to authenticate is also a good idea, provided the password is a cryptographically secure identifier.
I'm guessing that multi-user networked systems probably present the most interesting (and complicated) discussion.
:-)
If by "multi-user networked systems" you mean systems which host multiple competing interests which are mutually suspicious, then I agree. The vast majority of systems are computer programs communicating with other computer programs, some at the behest of a single user or multiple users, some based on a schedule, etc. If you can solve the problem of safe collaboration among mutually suspicious programs, then any other interaction I can think of falls out as a special case.
Part of the challenge (at least on the surface) is that in the case of an incoming network connection, the distinction between a "user" and a "program" seems a bit abstract.
Exactly, because there is no tangible distinction. Any "user" is communicating with you via some program, presumably under his control. It's programs all the way down.
I wno't try to go too far into those questions without first checking through the resources you've pointed to, which will take me some time.
A good start is Mark Miller's thesis, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.
I would note, though, that many industries operate under regulations that require authentication. This may partially be due to bad assumptions on the part of regulators.
Obviously I can't comment on any specifics without researching further, so you could be right. I would be disappointed if such legislation mandated a specific strategy to track information, rather than simply mandate that certain information be available should it be needed.
However, it also points toward a second reason why people use authentication: Sometimes it's not enough to know that an action is authorized; sometimes you have to keep track of who took each action.
Agreed! Delegation control and responsibility tracking are very important, which is why some capability folks designed Horton, which can be viewed as a sort of identity framework built on top of pure capabilities. Identities should only be used for reactive measures however, in case of abuse to identify the offending party and throttle or terminate abuse.
So, while you can decouple authentication from authorization to a point, I would still think you'd sometimes have to state "user has provided accurate identification" as a prerequisite of authorization (even if the authorization process isn't looking for any particular identity).
Whether the user/program intentionally or accidentally leaked his capability, you still have to revoke it to prevent abuse. I'm not sure what authentication gains you here. Identifying the capability is typically straightforward.
That said, I do think these make up a third category in this sense: Although they may be good candidates for a capability-based system, it remains true that I wouldn't generally "trust" a user as far as I could throw him.
Yes, there are no doubt other categories of systems. For instance, the KeyKOS capability operating system was used in early ATM systems starting in the 80s. I'm sure it had something to say on the subject. I hope you have time to research the rich literature of capability access control.