...of our crappy internal 'team event' videos - the cheese factor in these videos have been increasing over the past couple of years (we lost major acting talent when Brian Valentine left), and (from what I've heard) there is an all-out arms race to produce the worst video possible. Yes. Strange.
Like idiots, though, they forgot that this kind of thing leaks, and that people outside the company don't have the context that comes with the joke.
So Bruce ServicePack will win 'worst team event video of all time' - it probably killed off the goofy team event video.
Thursday, April 17, 2008
Saturday, April 12, 2008
Collapsing?
This just in from Computerworld:
April 10, 2008 (Computerworld) Calling the situation "untenable" and describing Windows as "collapsing," a pair of Gartner analysts yesterday said Microsoft Corp. must make radical changes to its operating system or risk becoming a has-been.
OK, that sounds bad. You have my attention...
Among Microsoft's problems, the pair said, is Windows' rapidly-expanding code base, which makes it virtually impossible to quickly craft a new version with meaningful changes. That was proved by Vista, they said, when Microsoft -- frustrated by lack of progress during the five-year development effort on the new operating -- hit the "reset" button and dropped back to the more stable code of Windows Server 2003 as the foundation of Vista.
If anything, the fact that we could reset back to a good code base and port over our good Alpha Longhorn features indicates that it actually is doable to 'quickly craft a new version [of Windows] with meaningful changes'.
"This is a large part of the reason [why] Windows Vista delivered primarily incremental improvements," they said. In turn, that became one of the reasons why businesses pushed back Vista deployment plans. "Most users do not understand the benefits of Windows Vista or do not see Vista as being better enough than Windows XP to make incurring the cost and pain of migration worthwhile."
Big corporations, in my experience, want a new version of Windows with 'incremental improvements' - they do not want to retrain thousands of workers every couple of years. There are a lot of companies out there that use Group Policy to make XP (or Vista) look like Windows 2000 (Classic mode, classic start menu, etc) - They want the newer OS, for better perf, hardware support and security, but they don't want their users to notice the change.
It takes too long for Microsoft to build the next version, the company is being beaten by others in the innovation arena, and in the future -- perhaps as soon as the next three years -- it's going to have trouble competing with Web applications and small, specialized devices.
Don't think so. Your computer will be your primary residence for your data for the foreseeable future.Every user has a primary computer where all their data is stored - and your iPhone/smartphone still has to be tethered that computer to get your contacts/music/photos/email accounts. That is not going to change anytime soon.
It will (someday your data will primarily live in the 'cloud', not on a fragile laptop), but not that soon - not for the average American.
"Apple introduced its iPhone running OS X, but Microsoft requires a different product on handhelds because Windows Vista is too large, which makes application development, support and the user experience all more difficult," according to Silver and MacDonald.
iPhone and your Mac laptop do not run the same OS.
Your Windows Mobile phone and your Windows laptop do not run the same OS.
In both cases, a lot of the APIs and libraries look the same. And there is a bunch of code reuse.
It has been this way ever since Longhorn was nothing more than a codename.
This is like saying a company failed because their truck engine could not be scaled down for use in their motorcycles. No duh.
Their advice to Microsoft took several forms, but one road they urged the software giant to take was virtualization. "We envision a very modular and virtualized world," said the researchers, who spelled out a future where virtualization -- specifically a hypervisor -- is standard on client as well as server versions of Windows.
"An OS, in this case Windows, will ride atop the hypervisor, but it will be much thinner, smaller and modular than it is today. Even the Win32 API set should be a module that can be deployed to maintain support for traditional Windows applications on some devices, but other[s] may not have that module installed."
The devil is in the details, isn't it? What makes you think this approach is going the be 'thinner, smaller and [more] modular'?
Backward compatibility with older applications should also be supported via virtualization. "Backward compatibility is a losing proposition for Microsoft; while it keeps people locked into Windows, it also often keeps them from upgrading," said the analysts. "[But] using built-in virtualization, compatibility modules could be layered atop Win32, or not, as needed."
Honestly - appcompat takes up a small amount of my time. It isn't very hard to support older APIs/applications. In the spots in Vista where we significantly broke appcompat we could see the problems coming a mile away (The Session 0 security fix, for example.)Silver and MacDonald also called on Microsoft to make it easier to move to newer versions of Windows, re-think how it licenses Windows and come up with a truly modular operating system that can grow or shrink as needed.
?The SKU story in Windows, in my opinion, is stupid - all you need is a Home SKU, a Business SKU. Done - end of story. (Marketing, are you reading this?)
Wrt grow or shrink: Huh? You can already install/uninstall just about ever usermode part of Windows Vista.
Take Windows Movie Maker: If you don't use it, it doesn't run. Doesn't slow down Vista startup. Doesn't chew up memory when it is not running. If you don't like fact that is taking up (i dunno) 10mb of disk space on your 100GB disk, you can uninstall it. What is the problem here?
Thursday, April 3, 2008
OK...so...
aka "How to never by annoyed by UAC again"
My last post was a lame April Fool's joke. I wasn't seriously proposing that we replace the UAC prompt with a Captcha. It would kinda sorta make sense in some scenarios, but we've already solved the problem* differently. And captchas are annoying. Necessary evil, but annoying. (Isn't it truly weird that Captchas are the first step to Bladerunner-esque interrogations?)
*What problem? One of the things AUC addresses: If you are an admin user on Vista, your applications (mostly) run in normal user context - that is the core feature of UAC on Vista. If any (potentially) malicious software is running on your computer (in user context), you don't want it to be able to silently elevate to system context and open up firewall ports/reconfigure your system/etc.
(Yes, malware, even in user context, can probably send your credit card details to the other side other planet...malware running in system context is worse though, as it can reconfigure anything on the system to turn your computer into a spam zombie or botnet node/spy on other users/etc.)
If we didn't prompt the user before launching code in system context (from user context), malware could do literally anything to your machine (without you knowing) as soon as you doubleclicked on SeeParisHiltonNaked.exe. (Replace Paris Hilton with whoever you really really want to see in the nude.)
The AUC prompt is displayed on a dark background because it is running in a different screen session - the malware (back in user context) can't see the prompt/automatically click on it/etc. (If we displayed a captcha at this point (instead of an Allow/Cancel prompt) the malware back in user context won't be able to see it, or perform any action on it. The black frame means that only you, the user, and the Windows OS, can see (or interact with) any content on the screen.)
So - UAC prompts: Neccesary evil. Well...Neccesary evil to protect you from true evil.
Unless...
Unless, of course, you generally know what you are doing.
You can easily configure UAC to never prompt you. You do, of course, need to be careful when downloading and running any software downloaded from the internet - you don't want random code from the internet to be able to get into system context on your machine.
But, if you always go "Hmm, is this a good idea to do this?" when you see the UAC shield on a button/menu...you don't need to see a UAC prompt, do you?
If you are a user with administrator priviledges:
To remove the prompt - run gpedit.msc, go to Local Computer Policy - Computer Configuration - Windows Settings - Security Settings - Local Policies - Security Options.
Look for 'User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode' in the list on the right, and set it to 'Elevate without prompting'
Then, run 'gpupdate' from an elevated command prompt.
And you'll never see any UAC prompts, ever again.
But you have to promise to never run random executables off of the internet - stick to adobe.com or Paint.Net - stuff people trust. Stay away from SeeHarrisonFordNaked.exe.
My last post was a lame April Fool's joke. I wasn't seriously proposing that we replace the UAC prompt with a Captcha. It would kinda sorta make sense in some scenarios, but we've already solved the problem* differently. And captchas are annoying. Necessary evil, but annoying. (Isn't it truly weird that Captchas are the first step to Bladerunner-esque interrogations?)
*What problem? One of the things AUC addresses: If you are an admin user on Vista, your applications (mostly) run in normal user context - that is the core feature of UAC on Vista. If any (potentially) malicious software is running on your computer (in user context), you don't want it to be able to silently elevate to system context and open up firewall ports/reconfigure your system/etc.
(Yes, malware, even in user context, can probably send your credit card details to the other side other planet...malware running in system context is worse though, as it can reconfigure anything on the system to turn your computer into a spam zombie or botnet node/spy on other users/etc.)
If we didn't prompt the user before launching code in system context (from user context), malware could do literally anything to your machine (without you knowing) as soon as you doubleclicked on SeeParisHiltonNaked.exe. (Replace Paris Hilton with whoever you really really want to see in the nude.)
The AUC prompt is displayed on a dark background because it is running in a different screen session - the malware (back in user context) can't see the prompt/automatically click on it/etc. (If we displayed a captcha at this point (instead of an Allow/Cancel prompt) the malware back in user context won't be able to see it, or perform any action on it. The black frame means that only you, the user, and the Windows OS, can see (or interact with) any content on the screen.)
So - UAC prompts: Neccesary evil. Well...Neccesary evil to protect you from true evil.
Unless...
Unless, of course, you generally know what you are doing.
You can easily configure UAC to never prompt you. You do, of course, need to be careful when downloading and running any software downloaded from the internet - you don't want random code from the internet to be able to get into system context on your machine.
But, if you always go "Hmm, is this a good idea to do this?" when you see the UAC shield on a button/menu...you don't need to see a UAC prompt, do you?
If you are a user with administrator priviledges:
To remove the prompt - run gpedit.msc, go to Local Computer Policy - Computer Configuration - Windows Settings - Security Settings - Local Policies - Security Options.
Look for 'User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode' in the list on the right, and set it to 'Elevate without prompting'
Then, run 'gpupdate' from an elevated command prompt.
And you'll never see any UAC prompts, ever again.
But you have to promise to never run random executables off of the internet - stick to adobe.com or Paint.Net - stuff people trust. Stay away from SeeHarrisonFordNaked.exe.
Tuesday, April 1, 2008
SecCanWest
I haven't been able to get complete details from the whole SecCanWest thing; so Windows Vista wasn't compromised, but Adobe Flash was? *Sigh*
Security is very very hard.
(Don't worry, Adobe: There is an easy heuristic for determining the number of security issues remaining in a codebase: For every security issue you find, another security issue is bound to exist. You can use that to determine the actual number of security bugs in your code. This heuristic applies to any codebase on any OS.)
It sounds like UAC worked, though.
One of the areas of most active user feedback in Vista is UAC - people hate typing in their password to (for example) install random software.
Users already have far too many passwords (I've seen some studies that say that the average (average!) Information Worker has to remember 14 password already. Ridiculous.
In my personal experience, it seems that most users have no idea what their Windows user account password it - it just isn't something they use *that* often. Compared to, say, their Hotmail password. Or their Windows Live Hotmail password. Or their Windows Live Hotmail with Passport password.
Also, it is a pretty well-established fact that as soon as somebody has physical access to your machine, it is game-over from a security standpoint. (Heck, they could look at the disk sectors with a microscope, and read your documents. Probably. That's how microscopes work, right?)
When the user is attempting to install software we need to verify that that *the actual user* is the one granting admin access to the software installer; not a bit of user-context malware.
This is why the UAC prompt appears in the blacked-out special session (to stop UI automation from any bit of malware that might be running in your user context already from keylogging your password and doing a runas with admin creds later.)
So, we need to verify and prove that a human is granting permission for the software install. Any human close to the keyboard will do, as physical access to the machine == you can administer the machine. So really, you don't need a human with an admin user account; you just need a human. Or rather: you just need to prove that you have a human at the keyboard.
What kinds of proofs are used today to prove to software that a human is at the keyboard, instead of a robot? I, for one, can think of a solution that is pretty popular already - you might too, if you take a look around the web.
Security is very very hard.
(Don't worry, Adobe: There is an easy heuristic for determining the number of security issues remaining in a codebase: For every security issue you find, another security issue is bound to exist. You can use that to determine the actual number of security bugs in your code. This heuristic applies to any codebase on any OS.)
It sounds like UAC worked, though.
One of the areas of most active user feedback in Vista is UAC - people hate typing in their password to (for example) install random software.
Users already have far too many passwords (I've seen some studies that say that the average (average!) Information Worker has to remember 14 password already. Ridiculous.
In my personal experience, it seems that most users have no idea what their Windows user account password it - it just isn't something they use *that* often. Compared to, say, their Hotmail password. Or their Windows Live Hotmail password. Or their Windows Live Hotmail with Passport password.
Also, it is a pretty well-established fact that as soon as somebody has physical access to your machine, it is game-over from a security standpoint. (Heck, they could look at the disk sectors with a microscope, and read your documents. Probably. That's how microscopes work, right?)
When the user is attempting to install software we need to verify that that *the actual user* is the one granting admin access to the software installer; not a bit of user-context malware.
This is why the UAC prompt appears in the blacked-out special session (to stop UI automation from any bit of malware that might be running in your user context already from keylogging your password and doing a runas with admin creds later.)
So, we need to verify and prove that a human is granting permission for the software install. Any human close to the keyboard will do, as physical access to the machine == you can administer the machine. So really, you don't need a human with an admin user account; you just need a human. Or rather: you just need to prove that you have a human at the keyboard.
What kinds of proofs are used today to prove to software that a human is at the keyboard, instead of a robot? I, for one, can think of a solution that is pretty popular already - you might too, if you take a look around the web.
Subscribe to:
Posts (Atom)