Intel appears to be proposing to turn the x86 software market into an Apple-style apps store, and it's doing so in the name of security. One casualty will be anti-virus software as we know it. Speaking at IDF this week about Intel's purchase of anti-malware monger McAfee, CEO Paul Otellini spoke of a need to move from a "known …
This makes no sense
What the heck is Mr. Otellini talking about? He clearly knows nothing about what "signing" code means. There have been signed apps in Android and the iOS that have done bad things - like steal passwords, copy your private data, etc.
Plus, if anti-virus companies were to just go away due to the magic of "signing", wouldn't that have made Intel's purchase of McAfee utterly stupid?
So now Intel will be censoring apps because the boobies are too bouncy?
First it starts with protection from malware, but how long will it be before some bright politician decides it's time to start censoring all the "unclean" content on the internet, and passes laws the force intel to censor for "moral" reasons.
They can't do it now, but with this new system, they'll have no excuses not to.
very good, now ban Windows.
Problem solved, you can go home now.
I'm a Mac user and have an iPhone. I appreciate that iPhone apps I choose
to instal are verified. However, on my Mac(s) I enjoy installing whatever I want. And the OS
does a good job at warning me abot potentially dodgy apps. Maybe this is what Intel is going for with integrated security on their chips? Not a techie, just wondering.
As a linux user...
... I see nothing wrong with creating trusted repositories of software. It's how it's done in the linux world.
Repositories look after their own content, the user selects software from the repo. There's absolutely nothing to stop users adding extra software sources if they decide they need and/or trust them. There's also nothing to stop you downloading and installing stuff at random from the internet if you want to, though it's less advisable.
A similar system for windows (I'm guessing that's what the article is about, though it's not clear as it just mentions "x86" a lot) would probably be a step in the right direction, so long as it's not actually going to try to prevent people from running things from other sources.
Safe programming languages are all well and good, but the runtime still has to be safe, and someone has to write that in an unsafe language.
And I'm pretty sure ActiveX had a lot more wrong with it than a few buffer overflows....
Either way they are not the only solution. You can have as many safe languages as you like, but if users are to be free to install what they like then people will get malware.
Just because something's written in C# doesn't mean it can't keylog or raid your mail address book. People will always need to be careful where they get software from, unless they are willing to completely give up on freedom.
I'm not, though my mother might be.
AFAIK the main issue of ActiveX was that some corpo-programmers hacked up a C program, signed it and distributed it.
The bad guys then loaded these ActiveX controls in their websites and used all weaknesses, including buffer overflows, executing as Admin, because the control was signed by HP, Dell etc.
You could argue the control should never have worked in that context (but only on xxx.hp.com or xxx.dell.com), but ActiveX was specifically meant to be an applet technology. Actually it was one of these bad microsoft hacks, which appear when they don't have the time to think something through rigorously. Like RC4 protecting Office documents by using the same IV all the time and so on. Or that UAC thingy...
"No need for an anti-virus vendor."
So why then the recent purchase? If you go this route you need not thier expertise just to vet applications for the Istore. (iStore Apple, Istore Intel?) Curiouser and curiouser...
So every Word macro has to be signed? Yeah, right.
If he means it, that's interesting. We've all hacked up a scripting framework at one time or another. So you sign $yourlanguage to let it run. But how will Intel's hardware know when the data being read by $yourlanguage is in fact a script being executed?
Though sceptical, I wouldn't altogether dismiss it. Fifteen years on from when Perl's taint-checking for untrusted inputs showed you *can* make a clear distinction between safe and unsafe use of data, it's about time someone broke new ground.
Guess this means we'll need a sign-it flag in every compiler, and "save as signed" in every text editor that might be used for an executable script. Well, erm, they must surely have thought through how developers work, mustn't they?
 Is that still true for younger folks who have grown up with Larry's or Guido's and other such little hacks at their fingertips? I suspect it still is!
Umm, no ?
"Only allowing a system to run "trusted" code would inherently prevent malware that's spread through email or rogue websites from executing."
Not unless you've solved the halting problem it wont - I can still send the 'wrong' data and make my nicely signed app do anything it likes.
Memo to the author
Linux community and the FOSS culture in general is not about freedom of code, it is about the freedom of the end-user. This is what really bothers the corporate software vendors. It's not about giving away software for free (even Microsoft does this), it is about a way to allow users to escape vendor abuse.
Sorry but I have to shout it out loud.
- The land of Milk and Sammy: Free music app touted by Samsung
- The long war on 'DRAM price fixing' is over: Claim YOUR spoils now (It's worth a few beers)
- Privacy warriors lob sueball at Facebook buyout of WhatsApp
- Dell thuds down low-cost lap workstation for
cheapfrugal creatives or engineers
- 20 Freescale staff on vanished Malaysia Airlines flight MH370