ASP.NET MVC along with the other "web MVC" have really little to do with the real MVC as in the original smalltalk MVC described by Trygve Reenskaugs MVC. Web MVCs are bastardizations of the original concept, often only riding the name for recognition. I blame Struts and RoR for starting this trend.

I believe grand parent was referring to the original MVC which was a way to design interactive, event-driven GUIs. The original MVC was a recursive concept: The view could itself be a "tool" that in turn followed the MVC pattern. See http://heim.ifi.uio.no/~trygve...

As far as "web MVCs" goes, ASP.NET MVC is a really good one. But real MVC it is not. But that's a lost cause. An entire generation of developers have grown up believing that RoR and Struts were examples of MVC. In actuality, the designers og Struts and RoR grossly misunderstood the concept.

This is bad. Research has shown that extra crypto operations needed for DRM will add to energy consumption and contribute to global warming. This is an immoral product!

Uhm. From WhatIs.com:

LEGO is an abbreviation (though not an initialism) of Leg godt, danish for "play well" - or perhaps more like "have fun (playing)"

So it appears that it is an acronym

Windows 64 bit has an absolute kernel-driver signing requirement. Windows 32 bit has for compatibility reasons a more "soft" requirement - that's where you'll get the warning box instead. Reason: Windows is still compatible with drivers from the XP/2000 era and will still load those. At that time nobody had considered driver signing, and the vendor may now be defunct. An absolute requirement would render devices unusable. The signing requirement was in force when 64 bit was introduced, and MS reckons that all drivers for 64 bit must have been signed, thus the signing requirement is non-negotiable on x64.

You *can* load non-signed drivers by attaching a kernel mode debugger. This is to facilitate development of drivers without a long signing roundtrip.

Yes, it is binding. Legal estoppel is the term. It is used when you act in good faith on a promise. It is in fact one of the strongest contract types you can imagine, because it is considered a one-sided contract that you do not even have to accept (like you do with e.g. license terms). If you can show that you acted on the promise, a patent case against you will be dismissed.

There is a big difference between mitigation and prevention. Secure boot is a prevention mechanism: It prevents the system from booting if the boot chain has been tampered with. You can boot from external media such as an USB key and salvage data, but the system will not boot by itself.

What you are suggesting is a mitigation mechanism. As I wrote above, code running in a security context cannot protect effectively against code running in the same security context. It can only try to *mitigate* such attacks, but mitigation are speed bumps compared to prevention, which are road blocks

Windows certainly has it's share of mitigation mechanisms. First there are all the anti-exploit mitigation mechanisms which are designed to thwart an exploit from getting foothold, even when a vulnerability exists in 3rd party code. These are stack overflow/underflow prevention, DEP/ASLR, heap encryption/checksumming, safe structured exception handling (SafeSEH) etc etc.

Then there are the built-in running mechanisms such as ELAM, patchguard etc. Patchguard will checksum central kernel tables, and if malware tries to gain foothold in the (running) system by patching into e.g. the page table, patchguard will react to the checksum discrepancy and halt the system.

Secure Boot prevents a compromised system from ever starting. Your suggested mechanism is already there - Windows will *try* to prevent unauthorized patching. But that is mitigation and far less effective than prevention.

Consider yourself corrected. UAC has nothing to do with drivers. Kernel mode drivers under Windows *must* be signed by a recognized authority. If a driver is tampered with, the kernel will refuse to load it. If a driver is unsigned, the kernel will refuse to load it. On x64 systems, the user can *not* opt to override this warning.

UAC prompts has to do with integrity levels - which is a way to divide processes, files, registry keys etc into "trust zones" and isolate processes running with lower trust (lower integrity level) from accessing resources having higher trust (higher integrity level). Even when your account has admin rights, the admin rights are stripped from your token at login, i.e. you are running as a standard user without any special privileges. Windows saves the "full" token, but it is not active. When you start a process based on an image that declares in its manifest that it must run as admin, Windows will issue the UAC prompt on a separate secured desktop. If you accept the elevation (that your admin privileges can be used for the process), Windows starts the new process with the "full" token - and with high integrity level.

Sorry, but no. If you knew anything about threat modelling and OS design, you would know that code running at a trust level cannot protect against other code running with the same trust. The x86 architecture does have 4 levels, but for a number of reasons (mostly portability) practically no OSes use more than 2 levels (rings): protected/kernel and user mode.

What you are proposing is using a 3rd ring - something more privileged than kernel mode. This would constitute a major architectural redesign and would trash portability/compatibility with other architectures.

The fact is that UEFI Secure Boot is a very effective mechanism for blocking boot sector infections. As Windows has grown ever more resilient against permanent infections (app/driver signing, checksum tables, strong named assembly cache etc) malware authors were forced into infecting at an earlier stage of the boot process, if they wanted to take up permanent residence.

The OS kernel mode MUST have the capability to write all sectors of the disk. It can effectively block usermode apps from writing such sectors, but if kernel mode driver contains a vuln, rogue code can bypass any security mechanisms enforced by the kernel. It can just jump to the address efter the security check or control the IO itself.

Bootkits exists for Wndows. It was a real threat. A few unscrupolous individuals (lookng at you Garett) chose to instigate a FUD campaign, deliberately misrepresenting facts and knowlingly failing to correct misunderstandings when they advanced their case.

And you are still part of that.

Agreed.

Consider the situation where an attacker has actually compromised a server key - either it was leaked, brute forces, a vulnerability exploited. It happens and big parts of the certificate system such as revocation lists, OCSP, validity periods etc are concerned with this. Or consider the situation where a vulnerability allows the attacker to *fake* the fact that he has the private key.

Many systems are set up to warn or outright block if they are not able to check revocation for a certain time period. Seems to me, that with this extension an attacker can use the time from when the key is actually compromised until the breach is discovered/reported and gain permanent foothold instead of a temporary one.

This capability seems too dangerous to even have in the protocol - even if one can argue that it is protected. It broadens the attack surface in a significant way.

Of course, all security is a balance between risks, consequences and cost. Maybe, if this capability significantly lowers some other risk, it could outweigh the risk incurred by the increased attack surface. But color me skeptical.

Ok, try this: You browse the Internet using Firefox. Lots of vulnerabilities discovered each month, 4 remote code executions already in 2015. An attacker has infected an add or a legitimate or fringe site you visit. Attack code executes and the attacker now runs his code in your Firefox. The malicious code hooks into X. The code can intercept the lock screen, but it can *also* monitor each and every keystroke entered into ANY other window - including terminal windows - without you noticing it. Lock the screen and unlock it and your password is compromised. Run a sudo in a terminal window and you are pwned!

How's that?

Nice try. But no, you are BSing.

Scoth: "Windows has had the ctrl-alt-del to log in/unlock since literally the first version of Windows NT, 3.1, in 1993. "

You: "In 1993, Windows didn't have an NT kernel."

AC: "In 1993, Windows NT 3.1 was released. Not to say that the non-NT product line ended at the same time."
(AC factually correct here: Windows NT 3.1 was released in July 1993)

operaghost: "Windows NT 3.1 didn't have an NT kernel? Color me confused. No, scratch that-- color you wrong."

You: "Go to a typical computer store in 1993, ask for Windows, and they wouldn't give you an NT kernel."
(now you try to deflect; why bring in the "typical computer store"? the issue was *Windows NT*)

So, your claim was that Windows NT didn't have an NT kernel. The TFA was about Windows NT, and Windows NT certainly HAD the NT kernel, it certainly HAD the "attention sequence" Ctrl-Alt-Del, and it certainly WAS released and available.

And you are dishonest.

Except in Windows. Since Vista user interface privilege isolation prevents unauthorized processes from grabbing keyboard/mouse events or sending messages to windows owned by another process, even if that process is running as the same user. To be allowed to grab keyboard/mouse, the process must have declared that intent in the manifest *and* it must have been launched from an installed location (program files or windows system). Furthermore, such hooking/messaging is also masked out at the intrinsic level by UAC - specifically by integrity levels. A lower integrity process is simply not allowed - manifest or not - to send messages or install keyboard/mouse hooks at a higher integrity level process.

X is especially bad in this regard, as it does not even protect against shatter attacks and eavesdropping on windows from *another users* processes. If you elevate to root - e.g. sudo from a terminal window - any other process can *still* eavesdrop on keyboard events.

An access control system where everyone (with access?) can grant access to others sounds bad. However, I don't think that's the only alternative to me-us-everyone rwx. In fact, I don't know that such a system that exists at all. You usually needs to be the owner of a resource (or in the "owners" group) to grant privileges in a DAC system. Some systems also allows owners to grant specific rights on the security attributes to non-owners - i.e. the right to grant access.

How about a system where only owners or designated security administrators can grant/deny access? The issue here was that a developer *wanted* access to a file from a non-owner and non-group member account. Lacking finer grained ACLs, that leaves only "everyone".

It sounds like you believe that discretionary access control (DAC) is the alternative to Unix filesystem permissions. It's not. Unix filesystem permissions is itself a DAC system, albeit a very limited one. DAC only means that the owner of a resource (or a designated security administrator of a resource) can grant access to others. Because the creator of a file is often considered the owner, creators can often grant access to whom they choose.

However, if a user has been granted "read" access to a resource he can usually not grant it to someone else, unless he is the owner. Do you know of a system where, by default, you can grant the same permissions that you have been granted?

An attacker who has exploited a Firefox vulnerability (there are still many found and patched each month) is running as a *local user* on your machine. Trying to explain these types of vulnerabilities away is disingenuous, if not downright complacent.

Unix/Linuxs permission system is 70-era bit-saving stupid. There is no other way to put it.

While this is clearly a mistake by someone packaging the distro, they were certainly not helped by a system where you cannot adequately express permissions. ACLs are available, but they are still kludges and they fell like a bolt-on with many tools still not recognizing them.

When a developer meets the limit of what can be expressed with a single-group me-us-everybody, he will often look for the path of least resistance. Unfortunately that is often relaxing permissions along the coarse-grained me-us-everyone, often ending up with everyone as in this case.

Windows Image backup does *reverse* incremental: An image of the disk is stored as a vhd (virtual hard drive) along with reverse increments so that previous versions can be created. You can attach the vhd and use the "previous versions" feature to go back in time.