Installation programs are applications designed to deploy software, and most write to system directories and registry keys. These protected system locations are typically writeable only by an administrator user, which means that standard users do not have sufficient access to install programs. Windows Vista heuristically detects installation programs and requests administrator credentials or approval from the administrator user in order to run with access privileges. Windows Vista also heuristically detects updater and uninstallation programs. Note that a design goal of UAC is to prevent installations from being executed without the user's knowledge and consent since they write to protected areas of the file system and registry.
Installer Detection only applies to:
1. 32 bit executables
2. Applications without a requestedExecutionLevel
3. Interactive processes running as a Standard User with LUA enabled
Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:
Filename includes keywords like "install," "setup," "update," etc.
Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
Keywords in the side-by-side manifest embedded in the executable.
Keywords in specific StringTable entries linked in the executable.
Key attributes in the RC data linked in the executable.
Targeted sequences of bytes within the executable.
So Vista is going to randomly refuse to run stuff without an admin password because it thinks just maybe it might be an install program. Yay. One more reason not to upgrade.
IIRC, in Linux you have direct access to the hardware in a driver that resides entirely in kernel mode, and there is an instruction filtering process to prevent malicious operations. You are running the game in a regular user account, but at some level that user is executing arbitrary code in kernel mode.
Err... no. Yes, the driver runs in kernel mode. But it doesn't give you "direct access" to the hardware, or "execute arbitrary code". It passes you memory buffers that you fill with data, and it then processes the data. The only "instructions" that may pass between the two are shader control instructions, which aren't run on the CPU and don't have the option of direct memory access (that's a hardware restriction).
Is it truly open source, if you have to buy Microsoft's Visual Studio to build it?
Yes, at least according to the FSF. The GPL requires you to have no non-free dependencies *except* components included with your operating system or with your compiler.
Realistically, we'd all prefer if it built with gcc, but free software can depend on VS or the libraries that come with it (notably, of course, MFC).
You can code your web site in compliant HTML 3.2 and not even have to bother browser checking.
1. There's a lot of things that a lot of people want to do that HTML 3.2 can't. For these, they'll generally use HMTL 4 and/or CSS. 2. You assume all browsers correctly implement HTML 3.2 and have no display bugs. This is an invalid assumption.
It was autoloaded on pretty much all IE6 machines except Win2K and corporate machines that blocked it.
And the pirates who haven't hacked WGA (which is a substantial market segment). And those of us who haven't installed WGA on principle (which, I'll grant, is substantially smaller).
There's a moral difference between using a program somebody else has written outside the terms they've licensed it, and redistributing it outside of those terms.
If you have a Windows machine and the Hauppage software, I *think* (don't quote me on that - I don't use Windows some I'm not 100% on this) that you can rename the Hauppage dongle.bin file to something else and replace it with the mvpmc one (the Hauppage software has a stripped down DHCP and TFTP server).
Yes, that works. Its what I did when I first tried mvpmc, although I use a Linux TFTP server now (although its with the DHCP provided by my router).
That seems more an argument in favour of fixing the incompatibilities between browsers, rather than against the use of more complex Javascript.
In an ideal world, sure. Realistically, this isn't something I'm holding my breath for. MS have practically zero interest in interoperability with other browsers. Mozilla devs are only interested as far as it improves conformance to W3C recomendations (which MS routinely ignore). For stuff outside of standards, Mozilla has virtually no interest. Sticking to standards isn't viable when MS browsers don't work when you follow them.
Javascript is a fairly generic Turing-complete language, and I can't see feature of the language itself that would make creating a user interface particularly difficult. Indeed, the entire Firefox UI is essentially XUL and Javascript.
Yes, but XUL isn't available in a web context, where one must generally support a wider variety of browsers than just mozilla, with your own XUL packages installed locally. We're talking about AJAX apps here, not XUL development which is a completely different game with different rules.
The problem is in developing UIs that operating through the HTML DOM, not anything intrinsic to Javascript as a language. It's a library issue, not a compiler one, to compare it using the terms of desktop programming.
A wait-for-event primitive? What do you mean? Javascript allows one to create callback functions to a number of user-triggered events, and one can also easily trigger functions on custom events. Though the single threading is an issue, I'll grant.
When programming UIs in other environments, it is generally possible to call a function of some kind that displays a UI and waits for user response. JS has a limited version of this in the window.alert(), window.prompt() and window.confirm() methods. Other environments tend to allow the programmer rather more control over the format and behaviour of the dialog box that is shown (e.g. using the Win32 ExecuteDialog() API, or some object-oriented equivalent). Compare the following snippets:
//Standard JS function button1_onclick() { dlg=new mydialogbox(); dlg.okhandler=button1_onclick_dlgok; dlg.cancelhandler=button1_onclick_dlgcancel; dlg.show(); } function button1_onclick_dlgok() {//do stuff } function button1_onclick_dlgcancel() {//clean up without doing stuff }
or
//Some environment that does what I was talking about function button1_onclick() {
if (new mydialogbox().execute() == 1) {// do stuff
}
else
{// clean up without doing stuff
} }
The flow of control in the latter example is substantially easier to understand, but it is impossible to structure your code like this in the javascript environment, because there's no "wait for event/dispatch event" API available (which is how the 'execute' method in the latter example would work).
Again, it would appear you're more criticising the libraries, rather than the language.
Yes, I am. However in the context we're talking about (AJAX programming) you're stuck with the libraries you're given, so they become (at some level) one and the same thing. Yes, I'm aware of what javascript can do in different environments; I'm even considering using it as an extension language in my own apps. But that doesn't change the fact that writing advanced user interfaces using javascript in web browsers is more difficult than it should be.
Remembering that you really don't want to drain your batteries all the way (50% is a more reasonable day-to-day figure), that means that your 40-mile radius is chopped to 20 miles
I'd assume that the quoted 40 mile range is down to 50% charge (or whatever the recommended regular-use duty cycle for their battery technology is; with some battery types the figure is more like 70 or 80%).
Maybe if you can afford a $100K Tesla you wouldn't mind buying a new battery pack every year, but I don't think this would go over well with consumers.
The last time I did the maths (on a vehicle with lead-acids), the cost of replacement batteries was roughly the same as what you'd save in fuel terms. Battery prices may have dropped since then.
As has been stated many times over a plug-in car just offset the polution to our power generators
Yes, but:
1. EVs use less total power per mile driven. This one (as you'd know if you'd RTFA) is capable of generating its own power with a small onboard generator. No drain on the grid at all when you use that. 2. Large scale generators are (a) more efficient and (b) produce less pollution per unit of fuel than the combustion engine in a traditional vehicle. 3. There are alternative electricity production methods that don't rely on burning fossil fuels. 4. Power generation stations are typically in out-of-town areas that aren't struggling to cope with large scale polution already. Moving the polution there helps make the cities where larger numbers of people live more pleasant environments.
These factors combined make EVs substantially more environmentally sound: they use less resources, produce less pollution, and the pollution they do produce is less problematic.
This could lead to a true electric car with as much range as 310 miles that only needs 4-5 minutes to do a full recharge, obseleting internal combustion engines for passenger cars.
Assuming that somehow you can find some method of safely supplying the car with 120v at approximately 5,000 amps for those 5 minutes (giving a total of 50KWh, approximately enough for 5 hours driving [i.e. 300 miles @ 60MPH] with an average consumption of 10KW) without vapourising the charging circuit.
Does anyone know about how much solar panelling will add the to RPG of a smallish car? Assume California spring sun in a parking lot for 8.5 hours.
Depending on the size and efficiency of the panel, you'll get anywhere between 100 and 300 watts, I'd guess. Taking a midrange 200 watts, that's 1.7KWh. This will be realised into actual driving power at an efficiency of around 60%, giving about 1KWh of drive. Using US units, petrol has an energy density of 33KWh per gallon, of which approximately 30% may be realised in actual use. So this will save approximately 0.1 gallon per day.
With a Mac she now plugs in her digital camera to get photos as soon as I told her she didn't have to do a thing outside of plugging in the camera to the machine (no driver installs, no app installs)
Funny. Exactly the same happens with my XP machine. Why do you think this is unusual?
and she's been playing with iMovie, something she wouldn't have dreamed she could have done so easily on a Windows machine.
There are plenty of simple-to-use video editors available for Windows. The only difference is that they aren't included in the box to start with.
Microsoft, by making it more difficult (from what I've read - haven't tried it yet) to run Vista in any kind of virtual environment is not really helping the user base much.
I don't think Vista is any harder to virtualise than XP - other than being more demanding in terms of hardware requirements. It'll be tough to make Aero work under virtualisation because most virtual machine systems don't support 3d accel (yet). But vista should still work fine without that.
You may be getting confused by the licensing issue -- this doesn't really apply to the case of running vista on a mac. The issue is that (some versions of) XP's licence allow you to run a second copy of XP in a VM that's running inside the first copy. This has been removed from the vista home & ultimate editions licence. You can still run your first copy in a VM on some other OS if you want.
He praises Mac OS X for dimming toolbar buttons when windows are in the background, using the example of a Safari window behind a Finder window. Unfortunately, the reason the Safari window's toolbar buttons are dimmed is not that it's in the background, but that it's not displaying any page.
Frankly I didn't buy his argument at all. Looking at the different images he presented, I can't say that his point was right; he seemed to suggest that because the only way of telling the difference between an inactive and active window on vista was the difference in colour of the window control buttons and macs also faded control buttons inside the window, OSX was better. Regardless of whether this is true, he's ignoring the change of window title bar and border colour that happens on vista, and which makes quite an obvious difference, to my eyes much more obvious than the greying out of controls inside the window. Find the active window? Just look for the most brightly coloured title bar. Simple.
Some of his other points seem suspect, too. Running in a privileged account and relying on popup boxes to request confirmation of system-changing actions is less secure than running in an unprivileged account and having to enter a password. Well, of course. Perhaps he should have tried running the vista box with an unprivileged account instead. And while I'm not certain, since I haven't actually tried vista yet, I think he used a very convoluted way of pulling up his IP address. It takes only two clicks on my XP box, so I'd hope it was similarly easy on vista.
The author of the paper says things like "innovative new attack" and "next generation of server side injection."
Except it isn't "innovative" or "next generation". Everyone involved in javascript client-side programming has known this for years: if you let untrusted JS code execute, it can subvert your page in any way it wants. Hell, he doesn't even touch on the possibilities: it could, for instance, enumerate your functions and rewrite them, changing their behaviour in subtle ways that would be impossible with this technique. This is what happens when you run untrusted code in a dynamic language without sandboxing it so it doesn't have access to your own code. I dare say people working in (e.g.) LISP have known the potential issues with it since the 70s. These vulnerabilities are not new.
Consider, for example, the following example from the article:
As a final and better clarifying example of the consequences of this attack, let's consider an Ajax application developed for bank transfers. This application has a web dialog to confirm transactions and notifies the user via SMS for every bank transfer operation accomplished by an authenticated user.
If this Ajax interface is exposed to an XSS or to any related vulnerability, attacker will just have to inject the code and to wait for a bank transfer and then use the same code to redirect requests and responses to him.
Or the XSS-injected code could just perform the transaction itself without needing to parasitise the existing app. After all, it's already executing in an execution context that gives it access to everything it would need to do so (otherwise the existing app wouldn't be able to perform such a transaction). This might, at best, make developing such an attack slightly easier: instead of analysing the code of the app to determine how a transfer takes place, you could just sniff a few packets until you see data that looks like it might encode a transfer, then write your new XMLHttpRequest object to change the details. I don't think it's enough easier to warrant the excitement though. In fact, I think it might be harder.
A Request Splitting attack abuses flaws in asyncronous requests and allows to inject arbitrary headers when an Http request is built.
This isn't new either; it's simply the HTTP request smuggling attack method that was widely discussed last summer, initiated by a javascript program. This is simply a browser bug that should be fixed, nothing revolutionary. Certainly no more important than any of the tens of other security-domain-protection failure bugs discovered over the last few years.
The "auto-injection cross domain scripting" attack is the same thing used to inject a script, an obvious application of the above bug.
So what we have here is a browser bug that allows a previously-known attack vector to work in a new situation, and a new way of writing attacks which can't achieve anything that previous attacks couldn't do, and which is probably harder to write than the traditional way in most cases.
It's just a JavaScript library that allows the page to communicate with the server without clicking a link and bringing up a new page. How does that encourage poor development?
I'll take a stab at this. The problem is that it encourages people to write substantially more complex front-end code in javascript than was ever attempted prior to the development of AJAX. And front-end javascript is notoriously difficult to do right: there are a lot of browser incompatibilities that need workarounds, and many things that should be common in an application are actually very difficult to achieve, primarily because Javascript wasn't designed for this purpose -- its design goal was to allow small page modifications to be performed at the client, not to allow people to produce complete user interfaces. The fact that it is restricted to a single thread of execution and doesn't have a wait-for-event primitive makes some complex designs very hard to implement. Its handling of common user interface elements is basic and often difficult to work with.
All of these factors combine to make AJAX development substantially harder than equivalent development in more friendly environments (e.g. Java app development, native Windows, Linux or MacOS app development, etc.).
2. The Back button goes to the last page, as opposed to the last action, which is a good thing for true Web applications, since the Back button usually causes tons of problems (Ever seen "DON'T PRESS THE BACK BUTTON OR YOU COULD ACCIDENTALLY PAY FOR THIS PRODUCT TWICE"?).
The Post-and-Redirect design pattern (or the use of unique once-only form ids) solves this problem in almost all cases. Only badly written web apps still suffer from it.
Having skim read the article, it outlines how *if* you can execute malicious javascript for a website you can subvert the AJAX communication so that you can have man in the middle attacks etc.
However once an attacker can execute malicious javascript in the scope of the target website you're toast whether you are using AJAX or not.
Exactly. All competent web developers are aware that if javascript from a remote system can execute in the context of your page, you have no control over what it can do. Usually the answer is to "not do that". You rely on the browser's domain-based protection system to prevent other open pages injecting code into your page. You quote any user-supplied data to prevent XSS attacks. You don't have <script src="somewhere"> tags unless you trust "somewhere". And above all you don't exec() untrusted data. This is basic security practice, and applies to all languages, not just javascript: don't execute code that you don't trust in a context that gives it access to data you want to protect.
ARM processors have microcoded instructions (ldm/stm)... which certainly doesn't jive with most folk's definition of RISC.
Well, the definition I've seen used by processor designers who worked through the RISC revolution is usually something along the lines of "uses separate load/store instructions, rather than allowing operands of any instruction to be fetched from memory". There may be a little more nuance to the meaning than this, but that's the core of it. And what you're talking about are load / store instructions (although admittedly they load and store more than a single word). And looking at ARMs technical docs, I don't think they're implemented by microcoding, but rather with a pipeline stage that stalls for multiple cycles.
Slashdot Mirror
http://technet2.microsoft.com/WindowsVista/en/lib
Look for "installer detection".
Oh, jesus.
So Vista is going to randomly refuse to run stuff without an admin password because it thinks just maybe it might be an install program. Yay. One more reason not to upgrade.
IIRC, in Linux you have direct access to the hardware in a driver that resides entirely in kernel mode, and there is an instruction filtering process to prevent malicious operations. You are running the game in a regular user account, but at some level that user is executing arbitrary code in kernel mode.
Err... no. Yes, the driver runs in kernel mode. But it doesn't give you "direct access" to the hardware, or "execute arbitrary code". It passes you memory buffers that you fill with data, and it then processes the data. The only "instructions" that may pass between the two are shader control instructions, which aren't run on the CPU and don't have the option of direct memory access (that's a hardware restriction).
The two big problems with LUAs have been that there was no way to perform super-user actions without logging out and logging back in
You mean, other than right click/run as...? Or fast user switching?
Is it truly open source, if you have to buy Microsoft's Visual Studio to build it?
Yes, at least according to the FSF. The GPL requires you to have no non-free dependencies *except* components included with your operating system or with your compiler.
Realistically, we'd all prefer if it built with gcc, but free software can depend on VS or the libraries that come with it (notably, of course, MFC).
You can code your web site in compliant HTML 3.2 and not even have to bother browser checking.
1. There's a lot of things that a lot of people want to do that HTML 3.2 can't. For these, they'll generally use HMTL 4 and/or CSS.
2. You assume all browsers correctly implement HTML 3.2 and have no display bugs. This is an invalid assumption.
It was autoloaded on pretty much all IE6 machines except Win2K and corporate machines that blocked it.
And the pirates who haven't hacked WGA (which is a substantial market segment). And those of us who haven't installed WGA on principle (which, I'll grant, is substantially smaller).
There's a moral difference between using a program somebody else has written outside the terms they've licensed it, and redistributing it outside of those terms.
If you have a Windows machine and the Hauppage software, I *think* (don't quote me on that - I don't use Windows some I'm not 100% on this) that you can rename the Hauppage dongle.bin file to something else and replace it with the mvpmc one (the Hauppage software has a stripped down DHCP and TFTP server).
Yes, that works. Its what I did when I first tried mvpmc, although I use a Linux TFTP server now (although its with the DHCP provided by my router).
That seems more an argument in favour of fixing the incompatibilities between browsers, rather than against the use of more complex Javascript.
//Standard JS //do stuff //clean up without doing stuff
//Some environment that does what I was talking about // do stuff // clean up without doing stuff
In an ideal world, sure. Realistically, this isn't something I'm holding my breath for. MS have practically zero interest in interoperability with other browsers. Mozilla devs are only interested as far as it improves conformance to W3C recomendations (which MS routinely ignore). For stuff outside of standards, Mozilla has virtually no interest. Sticking to standards isn't viable when MS browsers don't work when you follow them.
Javascript is a fairly generic Turing-complete language, and I can't see feature of the language itself that would make creating a user interface particularly difficult. Indeed, the entire Firefox UI is essentially XUL and Javascript.
Yes, but XUL isn't available in a web context, where one must generally support a wider variety of browsers than just mozilla, with your own XUL packages installed locally. We're talking about AJAX apps here, not XUL development which is a completely different game with different rules.
The problem is in developing UIs that operating through the HTML DOM, not anything intrinsic to Javascript as a language. It's a library issue, not a compiler one, to compare it using the terms of desktop programming.
A wait-for-event primitive? What do you mean? Javascript allows one to create callback functions to a number of user-triggered events, and one can also easily trigger functions on custom events. Though the single threading is an issue, I'll grant.
When programming UIs in other environments, it is generally possible to call a function of some kind that displays a UI and waits for user response. JS has a limited version of this in the window.alert(), window.prompt() and window.confirm() methods. Other environments tend to allow the programmer rather more control over the format and behaviour of the dialog box that is shown (e.g. using the Win32 ExecuteDialog() API, or some object-oriented equivalent). Compare the following snippets:
function button1_onclick() {
dlg=new mydialogbox();
dlg.okhandler=button1_onclick_dlgok;
dlg.cancelhandler=button1_onclick_dlgcancel;
dlg.show();
}
function button1_onclick_dlgok() {
}
function button1_onclick_dlgcancel() {
}
or
function button1_onclick() {
if (new mydialogbox().execute() == 1) {
}
else
{
}
}
The flow of control in the latter example is substantially easier to understand, but it is impossible to structure your code like this in the javascript environment, because there's no "wait for event/dispatch event" API available (which is how the 'execute' method in the latter example would work).
Again, it would appear you're more criticising the libraries, rather than the language.
Yes, I am. However in the context we're talking about (AJAX programming) you're stuck with the libraries you're given, so they become (at some level) one and the same thing. Yes, I'm aware of what javascript can do in different environments; I'm even considering using it as an extension language in my own apps. But that doesn't change the fact that writing advanced user interfaces using javascript in web browsers is more difficult than it should be.
As for the fact that no other manufacturer is producing a pure electric vehicle... well... isn't that just sad?
It's also completely wrong. Peugeot-Citroen produce the Peugeot 106 Electric for general road use.
Remembering that you really don't want to drain your batteries all the way (50% is a more reasonable day-to-day figure), that means that your 40-mile radius is chopped to 20 miles
I'd assume that the quoted 40 mile range is down to 50% charge (or whatever the recommended regular-use duty cycle for their battery technology is; with some battery types the figure is more like 70 or 80%).
Maybe if you can afford a $100K Tesla you wouldn't mind buying a new battery pack every year, but I don't think this would go over well with consumers.
The last time I did the maths (on a vehicle with lead-acids), the cost of replacement batteries was roughly the same as what you'd save in fuel terms. Battery prices may have dropped since then.
6 hours. You'll need somebody very inattentive.
As has been stated many times over a plug-in car just offset the polution to our power generators
Yes, but:
1. EVs use less total power per mile driven. This one (as you'd know if you'd RTFA) is capable of generating its own power with a small onboard generator. No drain on the grid at all when you use that.
2. Large scale generators are (a) more efficient and (b) produce less pollution per unit of fuel than the combustion engine in a traditional vehicle.
3. There are alternative electricity production methods that don't rely on burning fossil fuels.
4. Power generation stations are typically in out-of-town areas that aren't struggling to cope with large scale polution already. Moving the polution there helps make the cities where larger numbers of people live more pleasant environments.
These factors combined make EVs substantially more environmentally sound: they use less resources, produce less pollution, and the pollution they do produce is less problematic.
This could lead to a true electric car with as much range as 310 miles that only needs 4-5 minutes to do a full recharge, obseleting internal combustion engines for passenger cars.
Assuming that somehow you can find some method of safely supplying the car with 120v at approximately 5,000 amps for those 5 minutes (giving a total of 50KWh, approximately enough for 5 hours driving [i.e. 300 miles @ 60MPH] with an average consumption of 10KW) without vapourising the charging circuit.
Does anyone know about how much solar panelling will add the to RPG of a smallish car? Assume California spring sun in a parking lot for 8.5 hours.
Depending on the size and efficiency of the panel, you'll get anywhere between 100 and 300 watts, I'd guess. Taking a midrange 200 watts, that's 1.7KWh. This will be realised into actual driving power at an efficiency of around 60%, giving about 1KWh of drive. Using US units, petrol has an energy density of 33KWh per gallon, of which approximately 30% may be realised in actual use. So this will save approximately 0.1 gallon per day.
With a Mac she now plugs in her digital camera to get photos as soon as I told her she didn't have to do a thing outside of plugging in the camera to the machine (no driver installs, no app installs)
Funny. Exactly the same happens with my XP machine. Why do you think this is unusual?
and she's been playing with iMovie, something she wouldn't have dreamed she could have done so easily on a Windows machine.
There are plenty of simple-to-use video editors available for Windows. The only difference is that they aren't included in the box to start with.
Microsoft, by making it more difficult (from what I've read - haven't tried it yet) to run Vista in any kind of virtual environment is not really helping the user base much.
I don't think Vista is any harder to virtualise than XP - other than being more demanding in terms of hardware requirements. It'll be tough to make Aero work under virtualisation because most virtual machine systems don't support 3d accel (yet). But vista should still work fine without that.
You may be getting confused by the licensing issue -- this doesn't really apply to the case of running vista on a mac. The issue is that (some versions of) XP's licence allow you to run a second copy of XP in a VM that's running inside the first copy. This has been removed from the vista home & ultimate editions licence. You can still run your first copy in a VM on some other OS if you want.
He praises Mac OS X for dimming toolbar buttons when windows are in the background, using the example of a Safari window behind a Finder window. Unfortunately, the reason the Safari window's toolbar buttons are dimmed is not that it's in the background, but that it's not displaying any page.
Frankly I didn't buy his argument at all. Looking at the different images he presented, I can't say that his point was right; he seemed to suggest that because the only way of telling the difference between an inactive and active window on vista was the difference in colour of the window control buttons and macs also faded control buttons inside the window, OSX was better. Regardless of whether this is true, he's ignoring the change of window title bar and border colour that happens on vista, and which makes quite an obvious difference, to my eyes much more obvious than the greying out of controls inside the window. Find the active window? Just look for the most brightly coloured title bar. Simple.
Some of his other points seem suspect, too. Running in a privileged account and relying on popup boxes to request confirmation of system-changing actions is less secure than running in an unprivileged account and having to enter a password. Well, of course. Perhaps he should have tried running the vista box with an unprivileged account instead. And while I'm not certain, since I haven't actually tried vista yet, I think he used a very convoluted way of pulling up his IP address. It takes only two clicks on my XP box, so I'd hope it was similarly easy on vista.
Except it isn't "innovative" or "next generation". Everyone involved in javascript client-side programming has known this for years: if you let untrusted JS code execute, it can subvert your page in any way it wants. Hell, he doesn't even touch on the possibilities: it could, for instance, enumerate your functions and rewrite them, changing their behaviour in subtle ways that would be impossible with this technique. This is what happens when you run untrusted code in a dynamic language without sandboxing it so it doesn't have access to your own code. I dare say people working in (e.g.) LISP have known the potential issues with it since the 70s. These vulnerabilities are not new.
Consider, for example, the following example from the article:
Or the XSS-injected code could just perform the transaction itself without needing to parasitise the existing app. After all, it's already executing in an execution context that gives it access to everything it would need to do so (otherwise the existing app wouldn't be able to perform such a transaction). This might, at best, make developing such an attack slightly easier: instead of analysing the code of the app to determine how a transfer takes place, you could just sniff a few packets until you see data that looks like it might encode a transfer, then write your new XMLHttpRequest object to change the details. I don't think it's enough easier to warrant the excitement though. In fact, I think it might be harder.
This isn't new either; it's simply the HTTP request smuggling attack method that was widely discussed last summer, initiated by a javascript program. This is simply a browser bug that should be fixed, nothing revolutionary. Certainly no more important than any of the tens of other security-domain-protection failure bugs discovered over the last few years.
The "auto-injection cross domain scripting" attack is the same thing used to inject a script, an obvious application of the above bug.
So what we have here is a browser bug that allows a previously-known attack vector to work in a new situation, and a new way of writing attacks which can't achieve anything that previous attacks couldn't do, and which is probably harder to write than the traditional way in most cases.
It's just a JavaScript library that allows the page to communicate with the server without clicking a link and bringing up a new page. How does that encourage poor development?
I'll take a stab at this. The problem is that it encourages people to write substantially more complex front-end code in javascript than was ever attempted prior to the development of AJAX. And front-end javascript is notoriously difficult to do right: there are a lot of browser incompatibilities that need workarounds, and many things that should be common in an application are actually very difficult to achieve, primarily because Javascript wasn't designed for this purpose -- its design goal was to allow small page modifications to be performed at the client, not to allow people to produce complete user interfaces. The fact that it is restricted to a single thread of execution and doesn't have a wait-for-event primitive makes some complex designs very hard to implement. Its handling of common user interface elements is basic and often difficult to work with.
All of these factors combine to make AJAX development substantially harder than equivalent development in more friendly environments (e.g. Java app development, native Windows, Linux or MacOS app development, etc.).
2. The Back button goes to the last page, as opposed to the last action, which is a good thing for true Web applications, since the Back button usually causes tons of problems (Ever seen "DON'T PRESS THE BACK BUTTON OR YOU COULD ACCIDENTALLY PAY FOR THIS PRODUCT TWICE"?).
The Post-and-Redirect design pattern (or the use of unique once-only form ids) solves this problem in almost all cases. Only badly written web apps still suffer from it.
The rest of your points are good, though.
Having skim read the article, it outlines how *if* you can execute malicious javascript for a website you can subvert the AJAX communication so that you can have man in the middle attacks etc.
However once an attacker can execute malicious javascript in the scope of the target website you're toast whether you are using AJAX or not.
Exactly. All competent web developers are aware that if javascript from a remote system can execute in the context of your page, you have no control over what it can do. Usually the answer is to "not do that". You rely on the browser's domain-based protection system to prevent other open pages injecting code into your page. You quote any user-supplied data to prevent XSS attacks. You don't have <script src="somewhere"> tags unless you trust "somewhere". And above all you don't exec() untrusted data. This is basic security practice, and applies to all languages, not just javascript: don't execute code that you don't trust in a context that gives it access to data you want to protect.
What? I thought it was fud, notfud.
What do you mean that isn't a single tag...?
ARM processors have microcoded instructions (ldm/stm) ... which certainly doesn't jive with most folk's definition of RISC.
Well, the definition I've seen used by processor designers who worked through the RISC revolution is usually something along the lines of "uses separate load/store instructions, rather than allowing operands of any instruction to be fetched from memory". There may be a little more nuance to the meaning than this, but that's the core of it. And what you're talking about are load / store instructions (although admittedly they load and store more than a single word). And looking at ARMs technical docs, I don't think they're implemented by microcoding, but rather with a pipeline stage that stalls for multiple cycles.