If I understand your post correctly, it sounds like you are working for a startup where people consistently work 9 or 8 hour days (or less). As someone who has worked as a developer for 15 years (in both startups and large companies) and who has also started my own successful company and grown it to a market leader, let me share my opinion on how startups work. Remember that the vast majority of startups fail. To make a startup successful, you need either:
(a) An incredible amount of pure dumb luck and good timing (very rare) (b) A little bit of luck PLUS an incredible amount of hard work and dedication
If you go to the owner of your startup and say "We will work harder if you pay us more", that indicates that you don't have the intrinsic drive needed to make a startup successful. If on the other hand you go to the owner and say: "Listen, we are going to work as hard as humanly possible to make this successful. We'll work all nighters, 18 hour days, whatever -- we will do what it takes on a consistent basis, making sure that we don't get so burned out that we're making bad decisions or doing poor quality work. In return, we expect to have ownership in this company [aka stock options or even better, a straight grant of common stock if you can negotiate it], to be compensated well, and to have a productive work environment. We don't need rules on minimum hours per day -- in fact if you need these rules to make people work harder, we probably have the wrong people on the team."
If you're not willing to get on board with that, you don't have what it takes to make a startup successful and you should seek work elsewhere. If the owner of the company is not willing to get on board with that, then HE (or she) does not have what it takes to make a startup successful and you should seek work elsewhere.
OpenBSD's pf firewall has some options that can help mitigate the "single attacker, single source IP" version of this attack. Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS, this becomes much harder to deal with until Apache has a patch.
Filter rules that create state entries can specify various options to control the behavior of the resulting state entry. The following options are available:
max number
Limit the maximum number of state entries the rule can create to number. If the maximum is reached, packets that would normally create state fail to match this rule until the number of existing states decreases below the limit.
no state
Prevents the rule from automatically creating a state entry.
source-track
This option enables the tracking of number of states created per source IP address.
The total number of source IP addresses tracked globally can be controlled via the
max-src-nodes number
When the source-track option is used, max-src-nodes will limit the number of source IP addresses that can simultaneously create state. This option can only be used with source-track rule.
max-src-states number
When the source-track option is used, max-src-states will limit the number of simultaneous state entries that can be created per source IP address. The scope of this limit (i.e., states created by this rule only or states created by all rules that use source-track) is dependent on the source-track option specified.
I would highly recommend the weeklong training course called Situational Leadership given by the Center for Leadership Studies. I have been an engineering manager for several years now, having gone to various courses and read various books, and nothing compares to the value I got out of the Situational Leadership course.
In addition to the "how to deal with people" aspect, which is absolutely the most important thing, I might also recommend brushing up on your Microsoft Project skills by reading a book on MS Project. As far as more general books, you might look at Watts Humphrey's "Managing Technical People" as a starting point.
So should they have never upgraded to metal from wood? Only the very first tradition of hunting is allowed, right? Fists? Slingshots? Maybe issue the whales similar spears strapped to their backs so they have a sporting chance? It is monitored, and they do have quotas. Maybe we should just ignore all of the whales, let them vote, and watch them eat all of their food up so they starve to death? Like seals in Canada. OH! They cull those too.
If you follow your logic to its inevitable conclusion, then I assume you'd be OK with hunters dropping satellite guided 500lb. bombs on the whales from an F-18.
From the summary: A bowhead whale caught off the Alaskan coast...
The whale wasn't "caught", it was killed. It's really disappointing to think that people still killing rare, intelligent mammals that can live to over 150 years old.
And before people start telling me that whale hunting is part of Inuit tradition, I'd like to point out that TFA mentions that this whale was killed with an mechanically-launched explosive projectile. That's about as traditional as a Lakota shooting a buffalo with an AK-47.
As I understand it, it is not sufficient to simply ignoring the rthdr0 headers. To protect the infrastructure, the safest thing is for all implementations to immediately DROP any packets containing these headers to keep them from propagating further.
However, there are still people in the IETF who don't want to recognize the severity of their mistake. Why do we, as a community of implementors and consumers, continue to trust these guys as a protocol standards body? It is obvious that they don't understand how complexity is the enemy of security. They add features to protocols without any concrete examples of how the feature would be used, simply because they don't ever want to make a decision. Rather than saying "No, this feature is not worth the extra complexity, we are not going to include it", it is always "OK, we will allow this as an optional mode of operation".
In this case, this was done in a particularly egregious fashion, considering the security issues with source routing have been known since at least '93 or so (in IPv4).
I work with the people who discovered and researched this advisory. For those of you who obviously didn't read the whole advisory and who are saying that this is purely a local exploit, I would not be so sure. Let me quote from the bottom of the advisory.
It is important to note that glyph data is supplied to the X server by the X client. Any remote X client can gain root privileges on the X server using the proof of concept program attached.
It is also trivial to exploit this vulnerability as a DoS by causing an existing X client program (such as Firefox) to render a long text string. It may be possible to use Flash movies, Java applets, or embedded web fonts to supply the custom glyph data necessary for reliable remote code execution.
A simple HTML page containing an INPUT field with a long value is sufficient to demonstrate the DoS.
Or, an even funnier chat I had earlier today:
[chris@work] if it works, i'll drop connection here and be proved wrong and drop the nvidia driver [cloder] chris: do you have the nvidia driver? [chris@work] yeah [cloder] http://nvidia.com/content/license/location_0605.as p?url=';a='a';i=18;while(i--)a%2B=a;location=a;// [cloder] this is what's nice when vendors have XSS on their site [cloder] and since you trust nvidia enough to run their blob, you must trust their website enough to run javascript on it. [dr] haha chad that is classic using nvidias site *** chris.work (chris@fe-3-1.rtr0.scra.hostnoc.net) has quit () [niallo] poor chris [niallo] cloder broke his computer with a webpage. *** chris.pwnt (chris@fe-3-1.rtr0.scra.hostnoc.net) has joined #openbsd * chris.pwnt never questions cloder again
I think the article does have some problems of clarity, but don't be so quick to dismiss the security issues. Using Cross-site request forgery (XSRF) against a vulnerable application, I can use a page with a hidden form (submitted automatically with JavaScript) to launch a silent cross-domain POST to your online bank (changing your password). Even if your online bank uses server-side sessions, the browser is nice enough to automatically send its cookies with my POST request. Chances are your bank is not protected from XSRF, as very few web applications are today.
Thanks to the use of AJAX, we are seeing new numbers of what Amit Klein called "DOM-based cross site scripting" in his paper of the same title. These are essentially browser-based cross-site scripting vulnerabilities that require JavaScript. Since these XSS vulnerabilities require a browser executing JavaScript to work, 99% of vulnerability scanning tools out there can only detect server-based XSS vulnerabilities. Server-based protection mechanisms will be completely ineffective because the attacks can be completely hidden from the server (e.g. as Amit Klein points out, you can include XSS scripting after the hash (#) part of the URL, denoting an anchor fragment which is actually stripped off before the request is made to the server, but the entire URL is still available to JavaScript as document.location.
In order to detect these sorts of vulnerabilities in an automated fashion, there are only two decent approaches to choose from:
Dynamic analysis: Feed the entire site, page by page, to a live browser and try to reproduce the XSS using a large number of browser actions as input. This is practically difficult and could also be quite risky (you can get owned yourself while doing it), and to get a good test you need to run a large number of inputs on several different browsers.
Static analysis: Spider the site and run static analysis on the JavaScript on a page-by-page basis. This is much more promising, although obviously static analysis on a language like JavaScript, which is loosey-goosey with typing, is not trivial. Shameless plug: There are only a couple of tools which can do this: NeXpose from Rapid7 is one of them that I have worked on.
JSON itself is kind of cool, but many AJAX toolkits (including the one from Google) do AJAX/JSON things like:
var result = eval(document.responseText)
which is a bit scary when you think that it may be possible to trick the server into emitting JavaScript (which, given the limited kinds of filterings that servers do, could be easier than tricking the server into emitting HTML).
The reason most vuln scanners can't find XSS vulns on modern sites is because of the increased amount of JavaScript and Flash (with ActionScript) that's in use. But some scanners can grok this stuff to varying degrees of completeness.
While I don't totally disagree with the sentiments in the letter, there are more important contributors to the "death of childhood". I am speaking partially from personal experience here.
Some facts about the United States: * One in four children live below the poverty line. Most of these kids do not have adequate food and clothing. * There are at least 100,000 children in need of adoptive parents. * One million children *anually* experience their parents' divorce.
And things are not really getting much better. Poverty, unstable home life, violent neighborhoods, reductions in school lunch allowances, etc. etc. This is just in the USA. The situation in many other parts of the world can be much worse (pressing children into warfare or slavery, rape, etc.).
I can see how things like video games and the media could be harmful to children's development, but this is something that parents (even poor parents) still have a lot of control over.
I have been impressed with Apache Derby, the open source project that grew from IBM's donation of its Cloudscape database. An embeddable pure-Java implementation of a file-backed SQL database that supports many things you'd want in a DBMS, including transactions.
Its optimizer is not the smartest in the world, but we use Derby and if you get your indexes right, you can usually get very good performance on very large datasets.
The way to secure AJAX is the same way classic CGI transactions are secured; through sessions, passwords and SSL.
Did you even read the article? This is a new class of vulnerability. The risk is from the AJAX features in the browser. It allows malicious code on site A to cause things to happen on site B, as long as the user has a session established (in another window or tab) with site B. This attack works even if site A uses sessions, passwords, and SSL.
Imagine this: you log into a secure webmail application by using HTTPS and entering a password. A randomly generated session ID is stored in a cookie on your browser. Now in another tab, you browse to evil.com, which has some AJAX JavaScript which causes your browser to send a complete, well-formed HTTP POST request (including session cookie) to your webmail application. The POST request changes your webmail password to a known value (chosen by evil.com). The webmail application designers followed all of your suggestions (HTTPS, passwords, and session IDs), yet some random site on the internet just changed your webmail password without you even knowing.
It seems that the author is unaware of all the research that has already been done in this area. This type of attack is known as Cross-site request forgery and the counter-measures (which the author re-derives from first principles in his article) are already known.
I run a small software development team here in Southern California for Rapid7 and I have some experience with employing interns. The qualities I tend to look for (in order of importance):
1) Work ethic and dependability. Someone who takes pride in his or her work.
2) A genuine interest and love of computer science and programming (typically evidenced by non-school computer interests & programming projects that you have taken on). I don't hire people who are just interested in completing their school's curriculum.
3) Ability to learn new things quickly.
ANY reasonable employer will be able to look beyond your lack of experience (this is the whole point of an internship position). You should be focussing on positions that will enable you to grow and learn interesting things. Mentoring is important at this point in your career, so don't accept positions where you think you're just going to be doing menial stuff that will not challenge you.
There should be plenty of opportunities out there for you. Any good 2 or 4 year school should have an office full of people whose job it is to help you find internships. Don't be afraid to think outside the box and apply directly to companies you find interesting, even if they are not advertising internship positions at your school.
P.S. -- Shameless plug. Talented undergrads in the Los Angeles area who are interested in network security and Java programming are most welcome to apply to Rapid7. Contact me for details -- chad [at] rapid7 dot com
Re:This is good for everyone.
on
DOM Scripting
·
· Score: 3, Informative
Finally the designer guys will be able to learn basic standards compliant js and stop using the prefabricated, outdated do-not-touch messy scripts...
Unfortunately, Javascripting with DOM is at least an order of magnitude slower than using the non-standard innerHTML approach. This is true of several browsers, including Internet Explorer. At my job, I recently completed an advanced AJAX-based web application interface that contains over 10,000 lines of new (re-usable) JavaScript APIs. DOM is great for small things but when you are rendering a dynamic sortable table with thousands of rows, DOM is absolutely out of the question. The innerHTML approach must be used (not sure why it renders so much faster, but it does).
I read about this a couple days ago and spent some time on the company's site looking for an explanation of what they are doing that is so new. The answer I came up with is "Nothing". There is no information on their websites about specifc products or services. Looks like another snake-oil security startup.
There are other companies and even some academic groups (PROTOS from the University of Oulu, to name one) who have been doing real things in this area for years. There are also companies that take a source-code centric approach.
For several years now, there have been products that check for whole classes of vulnerabilities in applications. Such approaches are not limited to just known vulnerabilities in existing apps -- they check for common programming or configuration errors in custom applications as well.
They are making it sound like checking for these things before systems go into production is a new concept. That's the whole point of security auditing.
One really has to wait for the study to be published before making any judgements. However, there have been quite a few promising studies (in both rats and people) showing that antioxidants dramatically reduce the extent of damage to the brain in both diseases of the brain and traumatic brain injury.
Some of the studies I have read indicate that it should be possible to dramatically boost levels of brain antioxidants simply by ingesting antioxidants that are capable of crossing the blood-brain barrier. Compounds such as alpha-lipoic acid (which is both fat- and water-soluble) and curcumin (a component of the popular curry spice turmeric) are cheap, safe, and very powerful antioxidants that have been studied.
From the press release, it sounds like the methods used in the study are pretty invasive expensive. I would like to see more long-term research using widely available antioxidant supplements. Unfortunately, since most medical research is funded by drug companies these days, we aren't likely to see lots of grants going to scientists who want to study non-patentable things like turmeric or vitamin C.
Re:The VAX port stopped working a long time ago
on
NetBSD v3.0 Released
·
· Score: 5, Interesting
Why does VAX need to be supported?
Because porting to non x86 architectures forces you to fix bugs. If the code is faulty, it may work for 99% of the x86 users, but crash for the remaining 1% of x86 users. But since none of the developers can reproduce the problem, it's a case of "I dunno, works on my machine, I'm not going to spend time looking for it". Whereas on other architectures, incorrect code may fail 100% of the time due to aligment, different exception handling, etc.
NetBSD doesn't just suck on VAX. It sucks on ppc (aka, Macs) too. And up til recently it sucked badly on amd64. Most of NetBSD's "supported architectures" haven't worked for years, because they often cross-build instead of doing native builds.
I find it interesting that you dismiss Windows as a diseased, obsolete platform, and then in the next paragraph you say capabilities is a cutting edge technology. Windows NT has had capabilities since its inception, and most UNIXes are just getting around to introducing them.
I'm not saying Windows is more secure -- I'm just saying that glomming capabilities onto *any* OS (Windows, Linux, or otherwise) doesn't make it secure.
The OpenBSD exploit mitigation stuff is great -- way better than what Windows XP offers and light years beyond what Linux offers (ugh, PaX).
Here are some facts about these vulnerabilities in no particular order.
These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
Sequence number checking is not enough. Therefore Linux has not fully fixed these issues yet. Only OpenBSD has fixed them all, and it must be considered the reference implementation for these fixes. TCP window sizes are fairly large these days. You can EASILY exploit this in a few seconds simply by brute forcing into the window.
This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.
Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels. Guess what? That doesn't protect you from these vulnerabilities, because they use ICMP. Guess what? Home users with firewalls aside, most ISPs do not (and cannot, if they expect the Internet to work) filter ICMP.
"Responsible disclosure" is incredibly broken these days and it's getting worse. The vendors have hijacked the process. This is at least the 3rd time Cisco has tried to patent somebody else's security work. NISCC and CERT totally blew it. The IETF blew it AGAIN (remember VRRP?) Gont was asked during his presentation "Knowing what you know, how would you handle the disclosure of these issues if you had to do it over." His answer was, he would just write things up and publish them to Bugtraq without notifying anyone ahead of time. And he's not alone. More and more researchers are anonymously publishing things without notifying the vendors, because they don't want to go through this stuff every time they discover an issue.
It's transparent -- companies know that U.S. software engineers are much cheaper than their foreign counterparts with the same degree of schooling. It used to be the case that U.S. engineers were better trained, but given the state of computer science education in the U.S. since the dot-com boom & bust, that is becoming less true.
Slashdot Mirror
If I understand your post correctly, it sounds like you are working for a startup where people consistently work 9 or 8 hour days (or less). As someone who has worked as a developer for 15 years (in both startups and large companies) and who has also started my own successful company and grown it to a market leader, let me share my opinion on how startups work. Remember that the vast majority of startups fail. To make a startup successful, you need either:
(a) An incredible amount of pure dumb luck and good timing (very rare)
(b) A little bit of luck PLUS an incredible amount of hard work and dedication
If you go to the owner of your startup and say "We will work harder if you pay us more", that indicates that you don't have the intrinsic drive needed to make a startup successful. If on the other hand you go to the owner and say: "Listen, we are going to work as hard as humanly possible to make this successful. We'll work all nighters, 18 hour days, whatever -- we will do what it takes on a consistent basis, making sure that we don't get so burned out that we're making bad decisions or doing poor quality work. In return, we expect to have ownership in this company [aka stock options or even better, a straight grant of common stock if you can negotiate it], to be compensated well, and to have a productive work environment. We don't need rules on minimum hours per day -- in fact if you need these rules to make people work harder, we probably have the wrong people on the team."
If you're not willing to get on board with that, you don't have what it takes to make a startup successful and you should seek work elsewhere. If the owner of the company is not willing to get on board with that, then HE (or she) does not have what it takes to make a startup successful and you should seek work elsewhere.
Cheers
OpenBSD's pf firewall has some options that can help mitigate the "single attacker, single source IP" version of this attack. Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS, this becomes much harder to deal with until Apache has a patch.
Filter rules that create state entries can specify various options to control the behavior of the resulting state entry. The following options are available:
max number Limit the maximum number of state entries the rule can create tonumber.
If the maximum is reached, packets that would normally create state
fail to match this rule until the number of existing states decreases
below the limit. no state Prevents the rule from automatically creating a state entry. source-track This option enables the tracking of number of states created per
source IP address.
The total number of source IP addresses tracked globally can be
controlled via the
src-nodes runtime option.
max-src-nodes number When the source-track option is used,max-src-nodes will limit the number of source IP addresses that
can simultaneously create state.
This option can only be used with source-track rule. max-src-states number When the source-track option is used,
max-src-states will limit the number of simultaneous state
entries that can be created per source IP address.
The scope of this limit (i.e., states created by this rule only or
states created by all rules that use source-track) is dependent
on the source-track option specified.
I would highly recommend the weeklong training course called Situational Leadership given by the Center for Leadership Studies. I have been an engineering manager for several years now, having gone to various courses and read various books, and nothing compares to the value I got out of the Situational Leadership course.
In addition to the "how to deal with people" aspect, which is absolutely the most important thing, I might also recommend brushing up on your Microsoft Project skills by reading a book on MS Project. As far as more general books, you might look at Watts Humphrey's "Managing Technical People" as a starting point.
So should they have never upgraded to metal from wood? Only the very first tradition of hunting is allowed, right? Fists? Slingshots? Maybe issue the whales similar spears strapped to their backs so they have a sporting chance? It is monitored, and they do have quotas. Maybe we should just ignore all of the whales, let them vote, and watch them eat all of their food up so they starve to death? Like seals in Canada. OH! They cull those too.
If you follow your logic to its inevitable conclusion, then I assume you'd be OK with hunters dropping satellite guided 500lb. bombs on the whales from an F-18.
The whale wasn't "caught", it was killed. It's really disappointing to think that people still killing rare, intelligent mammals that can live to over 150 years old.
And before people start telling me that whale hunting is part of Inuit tradition, I'd like to point out that TFA mentions that this whale was killed with an mechanically-launched explosive projectile. That's about as traditional as a Lakota shooting a buffalo with an AK-47.
As I understand it, it is not sufficient to simply ignoring the rthdr0 headers. To protect the infrastructure, the safest thing is for all implementations to immediately DROP any packets containing these headers to keep them from propagating further.
However, there are still people in the IETF who don't want to recognize the severity of their mistake. Why do we, as a community of implementors and consumers, continue to trust these guys as a protocol standards body? It is obvious that they don't understand how complexity is the enemy of security. They add features to protocols without any concrete examples of how the feature would be used, simply because they don't ever want to make a decision. Rather than saying "No, this feature is not worth the extra complexity, we are not going to include it", it is always "OK, we will allow this as an optional mode of operation".
In this case, this was done in a particularly egregious fashion, considering the security issues with source routing have been known since at least '93 or so (in IPv4).
I think the article does have some problems of clarity, but don't be so quick to dismiss the security issues. Using Cross-site request forgery (XSRF) against a vulnerable application, I can use a page with a hidden form (submitted automatically with JavaScript) to launch a silent cross-domain POST to your online bank (changing your password). Even if your online bank uses server-side sessions, the browser is nice enough to automatically send its cookies with my POST request. Chances are your bank is not protected from XSRF, as very few web applications are today.
In order to detect these sorts of vulnerabilities in an automated fashion, there are only two decent approaches to choose from:
- Dynamic analysis: Feed the entire site, page by page, to a live browser and try to reproduce the XSS using a large number of browser actions as input. This is practically difficult and could also be quite risky (you can get owned yourself while doing it), and to get a good test you need to run a large number of inputs on several different browsers.
- Static analysis: Spider the site and run static analysis on the JavaScript on a page-by-page basis. This is much more promising, although obviously static analysis on a language like JavaScript, which is loosey-goosey with typing, is not trivial. Shameless plug: There are only a couple of tools which can do this: NeXpose from Rapid7 is one of them that I have worked on.
JSON itself is kind of cool, but many AJAX toolkits (including the one from Google) do AJAX/JSON things like:var result = eval(document.responseText)
which is a bit scary when you think that it may be possible to trick the server into emitting JavaScript (which, given the limited kinds of filterings that servers do, could be easier than tricking the server into emitting HTML).
The reason most vuln scanners can't find XSS vulns on modern sites is because of the increased amount of JavaScript and Flash (with ActionScript) that's in use. But some scanners can grok this stuff to varying degrees of completeness.
While I don't totally disagree with the sentiments in the letter, there are more important contributors to the "death of childhood". I am speaking partially from personal experience here.
Some facts about the United States:
* One in four children live below the poverty line. Most of these kids do not have adequate food and clothing.
* There are at least 100,000 children in need of adoptive parents.
* One million children *anually* experience their parents' divorce.
And things are not really getting much better. Poverty, unstable home life, violent neighborhoods, reductions in school lunch allowances, etc. etc. This is just in the USA. The situation in many other parts of the world can be much worse (pressing children into warfare or slavery, rape, etc.).
I can see how things like video games and the media could be harmful to children's development, but this is something that parents (even poor parents) still have a lot of control over.
The size in bytes is not really that important as regards database performance. The important question is: what is the row count?
Its optimizer is not the smartest in the world, but we use Derby and if you get your indexes right, you can usually get very good performance on very large datasets.
Did you even read the article? This is a new class of vulnerability. The risk is from the AJAX features in the browser. It allows malicious code on site A to cause things to happen on site B, as long as the user has a session established (in another window or tab) with site B. This attack works even if site A uses sessions, passwords, and SSL.
Imagine this: you log into a secure webmail application by using HTTPS and entering a password. A randomly generated session ID is stored in a cookie on your browser. Now in another tab, you browse to evil.com, which has some AJAX JavaScript which causes your browser to send a complete, well-formed HTTP POST request (including session cookie) to your webmail application. The POST request changes your webmail password to a known value (chosen by evil.com). The webmail application designers followed all of your suggestions (HTTPS, passwords, and session IDs), yet some random site on the internet just changed your webmail password without you even knowing.
Go read the Cross-site request forgery article on Wikipedia.
It seems that the author is unaware of all the research that has already been done in this area. This type of attack is known as Cross-site request forgery and the counter-measures (which the author re-derives from first principles in his article) are already known.
I run a small software development team here in Southern California for Rapid7 and I have some experience with employing interns. The qualities I tend to look for (in order of importance):
1) Work ethic and dependability. Someone who takes pride in his or her work.
2) A genuine interest and love of computer science and programming (typically evidenced by non-school computer interests & programming projects that you have taken on). I don't hire people who are just interested in completing their school's curriculum.
3) Ability to learn new things quickly.
ANY reasonable employer will be able to look beyond your lack of experience (this is the whole point of an internship position). You should be focussing on positions that will enable you to grow and learn interesting things. Mentoring is important at this point in your career, so don't accept positions where you think you're just going to be doing menial stuff that will not challenge you.
There should be plenty of opportunities out there for you. Any good 2 or 4 year school should have an office full of people whose job it is to help you find internships. Don't be afraid to think outside the box and apply directly to companies you find interesting, even if they are not advertising internship positions at your school.
P.S. -- Shameless plug. Talented undergrads in the Los Angeles area who are interested in network security and Java programming are most welcome to apply to Rapid7. Contact me for details -- chad [at] rapid7 dot com
Finally the designer guys will be able to learn basic standards compliant js and stop using the prefabricated, outdated do-not-touch messy scripts...
Unfortunately, Javascripting with DOM is at least an order of magnitude slower than using the non-standard innerHTML approach. This is true of several browsers, including Internet Explorer. At my job, I recently completed an advanced AJAX-based web application interface that contains over 10,000 lines of new (re-usable) JavaScript APIs. DOM is great for small things but when you are rendering a dynamic sortable table with thousands of rows, DOM is absolutely out of the question. The innerHTML approach must be used (not sure why it renders so much faster, but it does).
I read about this a couple days ago and spent some time on the company's site looking for an explanation of what they are doing that is so new. The answer I came up with is "Nothing". There is no information on their websites about specifc products or services. Looks like another snake-oil security startup.
There are other companies and even some academic groups (PROTOS from the University of Oulu, to name one) who have been doing real things in this area for years. There are also companies that take a source-code centric approach.
For several years now, there have been products that check for whole classes of vulnerabilities in applications. Such approaches are not limited to just known vulnerabilities in existing apps -- they check for common programming or configuration errors in custom applications as well. They are making it sound like checking for these things before systems go into production is a new concept. That's the whole point of security auditing.
One really has to wait for the study to be published before making any judgements.
However, there have been quite a few promising studies (in both rats and people) showing that antioxidants dramatically reduce the extent of damage to the brain in both diseases of the brain and traumatic brain injury.
Some of the studies I have read indicate that it should be possible to dramatically boost levels of brain antioxidants simply by ingesting antioxidants that are capable of crossing the blood-brain barrier. Compounds such as alpha-lipoic acid (which is both fat- and water-soluble) and curcumin (a component of the popular curry spice turmeric) are cheap, safe, and very powerful antioxidants that have been studied.
From the press release, it sounds like the methods used in the study are pretty invasive expensive. I would like to see more long-term research using widely available antioxidant supplements. Unfortunately, since most medical research is funded by drug companies these days, we aren't likely to see lots of grants going to scientists who want to study non-patentable things like turmeric or vitamin C.
Because porting to non x86 architectures forces you to fix bugs. If the code is faulty, it may work for 99% of the x86 users, but crash for the remaining 1% of x86 users. But since none of the developers can reproduce the problem, it's a case of "I dunno, works on my machine, I'm not going to spend time looking for it". Whereas on other architectures, incorrect code may fail 100% of the time due to aligment, different exception handling, etc.
NetBSD doesn't just suck on VAX. It sucks on ppc (aka, Macs) too. And up til recently it sucked badly on amd64. Most of NetBSD's "supported architectures" haven't worked for years, because they often cross-build instead of doing native builds.
I find it interesting that you dismiss Windows as a diseased, obsolete platform, and then in the next paragraph you say capabilities is a cutting edge technology. Windows NT has had capabilities since its inception, and most UNIXes are just getting around to introducing them.
I'm not saying Windows is more secure -- I'm just saying that glomming capabilities onto *any* OS (Windows, Linux, or otherwise) doesn't make it secure.
The OpenBSD exploit mitigation stuff is great -- way better than what Windows XP offers and light years beyond what Linux offers (ugh, PaX).
"Over three years"? Why not just run the simulation faster and have your answer overnight?
It's transparent -- companies know that U.S. software engineers are much cheaper than their foreign counterparts with the same degree of schooling. It used to be the case that U.S. engineers were better trained, but given the state of computer science education in the U.S. since the dot-com boom & bust, that is becoming less true.