The open-audit link seems to be to a piece of software that is unrelated to the text of the summary. Rather than being anything related to people willing to help audit software, it's actually a tool for auditing your network.
In addition, whilst it does seem to be GPL, you need to provide a name, and email to download it.
The theory of crypto sure, but actually implementing it is much more about programming rather than about math. Most of the attacks on crypto implementations are side channel attacks not attacks on the basic maths that underlies the primitives. The implementation is much harder than the maths.
It seems to a be common belief that morality is only possible when there is a religious basis for it, do you think it's possible to separate the two concepts in the mind of an audience, and if so how?
Perhaps some Nicholas Fisk would fit - I really enjoyed the StarStormers books and Trillions when I was a child. I also loved the older scifi like Jules Verne.
That's true, though openssl has had the ability to add empty fragments to avoid the chosen plain text attack I suspect you're referring to for many years. What's strange is that the chosen solution (polarSSL) doesn't seem to have support for OCSP which is the main way to quickly revoke bad keys - particularly important in the light of the recent diginotar breach.
Really? I've worked with the bindings perl, python and Java, and also worked on bindings to a couple of different javascript interpreters. The python one was by far the best documented. There are a bunch of tools around like swig that will give the same effect for C code for perl and python (or simple C++ code). For more complex C++ sip does a decent job for python, but doesn't support other languages.
I guess I'm wondering what the criteria you're using to make this statement are?
> including styles, theming, remote access, config databases, scalability, and GUI scripting.
Styles - not unless you count colour schemes which were available on platforms like win3.1 already. Theming - not at all Remote Access - only the basics that X11 provided for it. Config Databases - nothing beyond Xt resources which were a pretty much failed implementation from the start. Scalability - don't make me laugh. GUI Scripting - did you ever try tooltalk?
CDE was a poor implementation of existing ideas and brought nothing new to the table.
Ok, a plasmoid is generally a visualisation of a Data Engine. There can be many plasmoids for the same data engine (eg. this means that if we write 10 task bars then the back end code is all shared). Unlike an application a plasmoid doesn't have its own process, and simply responds to changes in the underlying data engine (because of various bits of wizardry this means that they will consume less battery power too btw). In a model-view design, you can consider a plasmoid to be a pure view. That said, many of the current plasmoids blur this by including model functionality - this is likely to become less prevelant as we determine what data engines we need.
No, I don't think that google will maliciously modify this code but I do think it should be signed anyway. Signing it proves that the code is unmodified. Signing the code also prevents attacks like DNS cache poisoning which (unless google are offering to serve this code via HTTPS) mean that someone other than google can maliciously insert modified versions of the code. BTW if you think that big sites only store session IDs in cookies then you're not seeing the same crap I see every day from multinationals.
I'm afraid you have no guarantee the code is unmodified - that's why I suggested it should be signed. You're also wrong about the cookies as they are accessible from javascript using document.cookie which means that any malicious script could access them (and even send them to a 3rd party). There is an HTTPOnly flag on cookies (an extension added in IE6sp1 but that flag has to be specifically set (see http://www.owasp.org/index.php/HTTPOnly for more details).
Well, one effect of this would be to allow google to execute scripts in the security context of any site using their copy of the code. The same issue occurs for urchin.js etc. If your site needs to comply with regulations like PCI DSS or similar then you shouldn't be doing this as it means google has access to your cookies, can change your content etc. etc.
For many common sites that aren't processing sensitive information however, sharing this code is probably a very good idea. Even better would be if google provided a signed version of the code so that you could see if it has been changed.
Certainly, free speech is something I will happily defend, freedom of movement etc. too. I just don't feel that having the source code to all software you use is a moral issue.
I disagree. I've written an awful lot of open source software (which just happens to also be 'free software' according to Stallman's definition. The ideals expressed in the open source definition ring much truer to me than those espoused by the FSF. The problem I have is that I disagree with the premise that closed-source software is morally wrong, I don't believe it is. For me, the big win of 'open source' has been that provides a framework for describing what I'm doing without having to sign up to a moral argument I think is bogus.
For people who want to check out the RC without reinstalling KDE (and without risking breaking your existing setup) there's a live CD available at: http://home.kde.org/~binner/kde-four-live/ Have a lot of fun!
I have to agree with microsoft here, some of the suggestions that were made for the ES4 standard were quite frankly mad. The current draft has removed some of the more ridiculous ideas like the adding in the E4X support which involved introducing new syntax for dealing with XML. I don't think that adding domain specific features like this to the core language makes sense at all in a language that is general purpose. The spec still seems to suggest trying to form some sort of hybrid of prototype and class based OO which I suspect will lead to both bad implementations and unmaintainable code. The ES4 group also seems to have decided that simply gluing on features from python is a good idea (for example list comprehensions), I like python but I'm not sure that this is the best approach to extending javascript.
I think that some of the work the WHAT WG group have done is actually much closer to what the ES4 group should be looking at - making a standard library that is richer. For example the HTML 5 draft has an API for SQL that could easily be used as the basis for a new standard object in JS.
This has been old news for years, there are much bigger and more real problems out there in commercial sites. Before I worry about CSRF, I'd far rather people sorted out SQL injection and XSS which are ridiculously common. If a site is (reasonably) secure (something I rarely see) then modern frameworks like django already provide tools that eliminate this issue see http://www.djangoproject.com/documentation/csrf/
I read the article, and I'm still wondering what the 'new' part is. The text doesn't mention anything that hasn't been around for ages, is this a bad article or bad research?
Slashdot Mirror
The open-audit link seems to be to a piece of software that is unrelated to the text of the summary. Rather than being anything related to people willing to help audit software, it's actually a tool for auditing your network.
In addition, whilst it does seem to be GPL, you need to provide a name, and email to download it.
> Crypto is about math, not programming
The theory of crypto sure, but actually implementing it is much more about programming rather than about math. Most of the attacks on crypto implementations are side channel attacks not attacks on the basic maths that underlies the primitives. The implementation is much harder than the maths.
It seems to a be common belief that morality is only possible when there is a religious basis for it, do you think it's possible to separate the two concepts in the mind of an audience, and if so how?
Perhaps some Nicholas Fisk would fit - I really enjoyed the StarStormers books and Trillions when I was a child. I also loved the older scifi like Jules Verne.
http://en.wikipedia.org/wiki/Nicholas_Fisk
tar cf - somedir | ssh remote@remotehost 'tar xf -'
A nice way to get things moved around. a similar trick is:
tar cf - somedir | (cd /a/local/path; tar xf - )
Which lets you copy things around a local file system.
That's true, though openssl has had the ability to add empty fragments to avoid the chosen plain text attack I suspect you're referring to for many years. What's strange is that the chosen solution (polarSSL) doesn't seem to have support for OCSP which is the main way to quickly revoke bad keys - particularly important in the light of the recent diginotar breach.
Really? I've worked with the bindings perl, python and Java, and also worked on bindings to a couple of different javascript interpreters. The python one was by far the best documented. There are a bunch of tools around like swig that will give the same effect for C code for perl and python (or simple C++ code). For more complex C++ sip does a decent job for python, but doesn't support other languages.
I guess I'm wondering what the criteria you're using to make this statement are?
It's accountants that rain from the sky http://www.mcs.csueastbay.edu/~malek/Surrealism/magritte2.jpg
Would /you/ trust a bomb built by a humanities student?
It's difficult to say from the information provided, but it sounds like someone just rediscovered XML entity attacks (as I did a few years ago). Assuming it is the same thing, here are some references from 2002 and 2006 with more details:
http://www.securiteam.com/securitynews/6D0100A5PU.html
http://www.sift.com.au/assets/downloads/SIFT-XML-Port-Scanning-v1-00.pdf
I've used these attacks in real-world tests and they are still surprisingly effective - just not new.
> including styles, theming, remote access, config databases, scalability, and GUI scripting.
Styles - not unless you count colour schemes which were available on platforms like win3.1 already.
Theming - not at all
Remote Access - only the basics that X11 provided for it.
Config Databases - nothing beyond Xt resources which were a pretty much failed implementation from the start.
Scalability - don't make me laugh.
GUI Scripting - did you ever try tooltalk?
CDE was a poor implementation of existing ideas and brought nothing new to the table.
Ok, a plasmoid is generally a visualisation of a Data Engine. There can be many plasmoids for the same data engine (eg. this means that if we write 10 task bars then the back end code is all shared). Unlike an application a plasmoid doesn't have its own process, and simply responds to changes in the underlying data engine (because of various bits of wizardry this means that they will consume less battery power too btw). In a model-view design, you can consider a plasmoid to be a pure view. That said, many of the current plasmoids blur this by including model functionality - this is likely to become less prevelant as we determine what data engines we need.
One difference is that we're doing lots of stuff using an ARGB visual (ie. true translucency). It seems these code paths haven't really been tested.
> The problem was that the KDE team didn't want to miss the Ubuntu Long Term Support edition
I'm afraid this information is just plain wrong.
No, I don't think that google will maliciously modify this code but I do think it should be signed anyway. Signing it proves that the code is unmodified. Signing the code also prevents attacks like DNS cache poisoning which (unless google are offering to serve this code via HTTPS) mean that someone other than google can maliciously insert modified versions of the code. BTW if you think that big sites only store session IDs in cookies then you're not seeing the same crap I see every day from multinationals.
I'm afraid you have no guarantee the code is unmodified - that's why I suggested it should be signed. You're also wrong about the cookies as they are accessible from javascript using document.cookie which means that any malicious script could access them (and even send them to a 3rd party). There is an HTTPOnly flag on cookies (an extension added in IE6sp1 but that flag has to be specifically set (see http://www.owasp.org/index.php/HTTPOnly for more details).
Well, one effect of this would be to allow google to execute scripts in the security context of any site using their copy of the code. The same issue occurs for urchin.js etc. If your site needs to comply with regulations like PCI DSS or similar then you shouldn't be doing this as it means google has access to your cookies, can change your content etc. etc.
For many common sites that aren't processing sensitive information however, sharing this code is probably a very good idea. Even better would be if google provided a signed version of the code so that you could see if it has been changed.
Who can remember what was at memory address 0x3CA?
Hint: think tapes, the vertical blank interupt and the *load command.
Answer in rot13:
Vg pbagnvarq gur syntf jura ybnqvat n svyr naq yrg lbh *ybnq tnzrf gung jrer 'cebgrpgrq' gb bayl nyybj *eha vs lbh znfxrq bhg gur zbfg fvtavsvpnag ovg. Guvf jnf hfrq ol cerggl zhpu rirel purng jevggra sbe OOP tnzrf.
Certainly, free speech is something I will happily defend, freedom of movement etc. too. I just don't feel that having the source code to all software you use is a moral issue.
I disagree. I've written an awful lot of open source software (which just happens to also be 'free software' according to Stallman's definition. The ideals expressed in the open source definition ring much truer to me than those espoused by the FSF. The problem I have is that I disagree with the premise that closed-source software is morally wrong, I don't believe it is. For me, the big win of 'open source' has been that provides a framework for describing what I'm doing without having to sign up to a moral argument I think is bogus.
For people who want to check out the RC without reinstalling KDE (and without risking breaking your existing setup) there's a live CD available at:
http://home.kde.org/~binner/kde-four-live/
Have a lot of fun!
I have to agree with microsoft here, some of the suggestions that were made for the ES4 standard were quite frankly mad. The current draft has removed some of the more ridiculous ideas like the adding in the E4X support which involved introducing new syntax for dealing with XML. I don't think that adding domain specific features like this to the core language makes sense at all in a language that is general purpose. The spec still seems to suggest trying to form some sort of hybrid of prototype and class based OO which I suspect will lead to both bad implementations and unmaintainable code. The ES4 group also seems to have decided that simply gluing on features from python is a good idea (for example list comprehensions), I like python but I'm not sure that this is the best approach to extending javascript.
I think that some of the work the WHAT WG group have done is actually much closer to what the ES4 group should be looking at - making a standard library that is richer. For example the HTML 5 draft has an API for SQL that could easily be used as the basis for a new standard object in JS.
This has been old news for years, there are much bigger and more real problems out there in commercial sites. Before I worry about CSRF, I'd far rather people sorted out SQL injection and XSS which are ridiculously common. If a site is (reasonably) secure (something I rarely see) then modern frameworks like django already provide tools that eliminate this issue see http://www.djangoproject.com/documentation/csrf/
I'll just add that if the system really works as described then making a certain percentage of crap connections (10%?) would completely defeat it.
I read the article, and I'm still wondering what the 'new' part is. The text doesn't mention anything that hasn't been around for ages, is this a bad article or bad research?