Linked by Thom Holwerda on Wed 5th Jan 2011 22:09 UTC
Windows And this is part two of the story: Microsoft has just confirmed the next version of Windows NT (referring to it as NT for clarity's sake) will be available for ARM - or more specifically, SoCs from NVIDIA, Qualcomm, and Texas Instruments. Also announced today at CES is Microsoft Office for ARM. Both Windows NT and Microsoft Office were shown running on ARM during a press conference for the fact at CES in Las Vegas.
Thread beginning with comment 456154
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: BC
by lucas_maximus on Thu 6th Jan 2011 10:22 UTC in reply to "RE[2]: BC"
lucas_maximus
Member since:
2009-08-18

The essential features for malware are that: (1) the API must be consistent (so that source code can be recompiled),


1) This is also a necessary for 3rd parties to write good software for a platform that can run on multiple version of the same operating system on multiple platforms.

(2) trade secret source code with binary only executables which are routinely distributed and installed by end users.


Which isn't really a problem if people download the closed source executables from a reputable source i.e. the distributor.

If you downloaded a shell script for Unix/Linux without understanding from a random site and not understanding how it worked and just ran it, it would cause havok on your system as well.

Ergo the problem is user education not the fact that it is closed source. Funnily enough as a educated user I have no problems with viruses and malware even though I use both open and closed source applications.

But you will continue to push your anti-window/anti closed source agenda at every opportunity.

Edited 2011-01-06 10:24 UTC

Reply Parent Score: 1

RE[4]: BC
by lemur2 on Thu 6th Jan 2011 11:58 in reply to "RE[3]: BC"
lemur2 Member since:
2007-02-17

"The essential features for malware are that: (1) the API must be consistent (so that source code can be recompiled),


1) This is also a necessary for 3rd parties to write good software for a platform that can run on multiple version of the same operating system on multiple platforms.

(2) trade secret source code with binary only executables which are routinely distributed and installed by end users.


Which isn't really a problem if people download the closed source executables from a reputable source i.e. the distributor.

If you downloaded a shell script for Unix/Linux without understanding from a random site and not understanding how it worked and just ran it, it would cause havok on your system as well.

Ergo the problem is user education not the fact that it is closed source. Funnily enough as a educated user I have no problems with viruses and malware even though I use both open and closed source applications.

But you will continue to push your anti-window/anti closed source agenda at every opportunity.
"

There is indeed a great deal of closed-source software, which is distributed as binary executables only, which is perfectly good and functional software.

The problem is that almost all malware is also distributed as closed-source binary executables only, and that (being closed source) there is no way that anyone other than the creators of any given piece of such software can tell the difference. No amount of user education will change the fact that no-one (other than the authors of the software) can tell if a given closed-source binary executable does or does not contain new malware.

This fact is only relevant to this topic becasue someone stated that Windows for ARM would initially be free of malware, which is true, but my point is that there is nothing about ARM that would mean that this remains true for long.

It is "made-for-Windows", and "distributed via closed-source binary executables", that characterises 99% of existing malware. x86/x86_64 versus ARM really doesn't come into the picture. Just as Microsoft can fairly readily make a version of MS Office for ARM, so can malware authors also rapidly make an ARM version of their trojan malware in a similar fashion. It merely has to become worth their while.

BTW ... my agenda is merely to point out facts such as these to everybody, so they can make good decisions for themselves regarding which software they choose to run on their hardware. I make absolutely no apology for this agenda.

What exactly is your agenda in trying to disparage mine?

Edited 2011-01-06 12:10 UTC

Reply Parent Score: 2

RE[5]: BC
by lemur2 on Thu 6th Jan 2011 12:34 in reply to "RE[4]: BC"
lemur2 Member since:
2007-02-17

This fact is only relevant to this topic becasue someone stated that Windows for ARM would initially be free of malware, which is true, but my point is that there is nothing about ARM that would mean that this remains true for long.

It is "made-for-Windows", and "distributed via closed-source binary executables", that characterises 99% of existing malware. x86/x86_64 versus ARM really doesn't come into the picture. Just as Microsoft can fairly readily make a version of MS Office for ARM, so can malware authors also rapidly make an ARM version of their trojan malware in a similar fashion. It merely has to become worth their while.


Actually, it occurs to me that if Windows on ARM does gain appreciable market share, such that it does become worthwhile for malware authors to port their Windows malware (which is almost all malware) to ARM, then existing virus databases will be useless. Any re-compiled-for-ARM malware will have a different binary "signature" than the x86/x86_64 malware does.

This will open up the beginning of a "golden age" for Windows-for-ARM malware, until some lengthy time later when the antivirus and anti-malware scanner authors can build up a similar signature databse for the new for-Windows-for-ARM malware binaries.

Edited 2011-01-06 12:39 UTC

Reply Parent Score: 1

RE[5]: BC
by Neolander on Thu 6th Jan 2011 13:24 in reply to "RE[4]: BC"
Neolander Member since:
2010-03-08

The problem is that almost all malware is also distributed as closed-source binary executables only, and that (being closed source) there is no way that anyone other than the creators of any given piece of such software can tell the difference. No amount of user education will change the fact that no-one (other than the authors of the software) can tell if a given closed-source binary executable does or does not contain new malware.

At least a part of malware can be blocked without knowing how a program works internally, by using a capability-based security model. If the binary blob is sandboxed, it can only do the amount of harm it has been allowed to do.

Most desktop applications, as an example, don't need full access to the user's home folder. Really, they don't. Most of the time, they use this access to open either private config files, or user-designated files. Thus, if we only allow desktop apps to access their config files and user-designated files, we just got rid of that part of malware which used this universal access to the user's home folder for privacy violation or silently deleting and corrupting files without the user knowing.

It's exactly the same tactic as preventing forkbombing by not allowing a process to fork an infinite amount of times by default. Seriously, what kind of non-system software would require that with honest intents ?

This doesn't block the "please enter your facebook password in the form below" kind of malware, though... But at least, the user is conscious of what he's doing now. Only then may user education work.

Edited 2011-01-06 13:32 UTC

Reply Parent Score: 1

RE[5]: BC
by lucas_maximus on Thu 6th Jan 2011 15:10 in reply to "RE[4]: BC"
lucas_maximus Member since:
2009-08-18

The problem is that almost all malware is also distributed as closed-source binary executables only, and that (being closed source) there is no way that anyone other than the creators of any given piece of such software can tell the difference. No amount of user education will change the fact that no-one (other than the authors of the software) can tell if a given closed-source binary executable does or does not contain new malware.


And that is why you get the software from the original author, and guess what ... if you educate someone to always get the software from the original author ... mmmmm.

Furthermore if someone is so uneducated as to how to to avoid threats how will it being open source help ??? A malware author can just offer an "alternative download source" and stick a key logger in there for example ... having the source won't help because the uneducated simply won't know any different.

Also you obviously haven't heard of a checksum then? They use this on Unix/Linux Binary packages as well and also can be used on any file to validate it's integrity.

For example I remember Windows XP service pack 1 having a checksum key on in the installer properties ... if this didn't match what Microsoft had you had a duff/dodgy download.

BTW ... my agenda is merely to point out facts such as these to everybody, so they can make good decisions for themselves regarding which software they choose to run on their hardware. I make absolutely no apology for this agenda.


The thing is you "facts" aren't facts. They are opinions from someone that IMO doesn't really have any practical experience of developing or deploying software.

Unless you work directly in the software industry as a developer or a manager for a development team you simply don't understand the landscape and the issues that developers face.

Also you are biased in thinking that open sourcing everything is a cure to all software problems. This IMO couldn't be further from the truth.

What exactly is your agenda in trying to disparage mine?


Because I think you are biased and do not presents the facts fairly.

Reply Parent Score: 2

RE[4]: BC
by lemur2 on Thu 6th Jan 2011 12:49 in reply to "RE[3]: BC"
lemur2 Member since:
2007-02-17

If you downloaded a shell script for Unix/Linux without understanding from a random site and not understanding how it worked and just ran it, it would cause havok on your system as well.


True (providing one goes through the step of making the script executable after downloading it).

This is an excellent reason to avoid the practice of simply downloading software from some random site, making it executable, and then running it.

Fortuantely, it is entirely possible to install and run a complete Linux desktop (open source) software ensemble without ever once having to do such a thing.

Sticking to such a process as a self-imposed policy is the one known and well-proven way to be utterly certain to completely avoid malware and yet still be able to run a complete desktop software ensemble.

Reply Parent Score: 2

RE[5]: BC
by lucas_maximus on Thu 6th Jan 2011 15:15 in reply to "RE[4]: BC"
lucas_maximus Member since:
2009-08-18

This is an excellent reason to avoid the practice of simply downloading software from some random site, making it executable, and then running it.


You need to be educated not to do this, what if someone for example was following commands from a website and one part was to run rm -rf ~/ ... their home directory would be blown away ... however the system is safe.

I see on various Linux forums incorrect advice given to new users everyday, just look at Ubuntu forums. I saw this on there for example

dd /<somefile> /dev/sda

Which would blow away someone whole hardrive.

Fortuantely, it is entirely possible to install and run a complete Linux desktop (open source) software ensemble without ever once having to do such a thing.


Also is is possible with a Windows, MacOSX, Solaris, FreeBSD, Haiku, Amiga, OpenBSD etc. etc. as well.

Sticking to such a process as a self-imposed policy is the one known and well-proven way to be utterly certain to completely avoid malware and yet still be able to run a complete desktop software ensemble.


Which again requires that you have a certain level of competence in the first place i.e. you have a certain set of specialist knowledge ... you have been educated in this certain area of expertise.

Edited 2011-01-06 15:19 UTC

Reply Parent Score: 2

RE[5]: BC
by malxau on Thu 6th Jan 2011 15:20 in reply to "RE[4]: BC"
malxau Member since:
2005-12-04

True (providing one goes through the step of making the script executable after downloading it). This is an excellent reason to avoid the practice of simply downloading software from some random site, making it executable, and then running it. Fortuantely, it is entirely possible to install and run a complete Linux desktop (open source) software ensemble without ever once having to do such a thing.


Really?

1. It is possible, but very, very difficult, to get a booting system without taking binary code from a source you didn't generate yourself. Typically people use distributions as a starting point. But just like binary code on Windows, this relies on a chain of trust - that the binaries are not malware infested. If I want to create my own distribution tomorrow, users can't know whether to trust me or not. In the end, users have to decide trust by word of mouth - what works, what doesn't - just like Windows.

2. Even when compiling by source, it's common to blindly execute code. Consider how autoconf/configure scripts work. Do you really read configure scripts before running them? Source availability gives a means to ensure trustworthiness, but that is only as effective as user habits. As the volume of source running on people's machines increases, and assuming a human's ability to read code does not increase, the practicality of reviewing code decreases over time. Again, this relies on others reviewing the code, and building up communities based on which code is trustworthy and which isn't, which isn't that different to binary components above.

Reply Parent Score: 2