in NT4 and later fonts are parsed in kernel mode

Sometimes I feel like I must be the only geezer remaining who actually had the opportunity to use NT 3.51, so let me tell you: It was a GLORIOUS operating system.

EVERYTHING was client/server, and all the client stuff ran in Ring 3/User Mode.

Heck, you could even kill Windows, and run it as a multi-user "DOS" box.

But, of course, that meant that the video/graphics subsystem also ran as a client service, in User Mode, which [I guess] the suits perceived as being "slow", and therefore as being an impediment to the gaming experience which would come with the impending merger of code bases that we now know as Windows XP [2001].

So in 1996, some genius at MSFT decided to throw out all of the beauty and elegance and stability and security that had been NT 3.51, and to serve up, instead, the great big steaming pile of sh!t which was NT 4.0 [with its video/graphics subsystem subsumed into the kernel].

And the world was never again the same...

Good-bye akamai....

Sorry I don't have mod points for you.

More generally, Amazon is showing some seriously large gonads in all of this.

They are simultaneously treading on various different territories which were [separately] once the exclusive province of Google, Apple, Facebook, Blackberry, Akamai, and many, many others [anyone remember the Sears & Roebuck catalog?!?].

It will be very, very interesting to see how all of this plays out.

It certainly shows that, if nothing else, they aren't satisified with standing still.

Steve Ballmer, are you paying attention?!?



PS: In honor of the 10th Anniversary of 9/11, it should be noted that Akamai lost at least one top executive on American Airlines Flight 11.

[I don't know whether he was flying alone, or whether he had any Akamai assistants with him.]

If the form factor is correct, then plenty of recent Xeon/Opteron servers, with a free PCI slot, suddenly become AWESOME desktop platforms. Around here, you can get late model 4-core Xeons, with maybe 8GB of RAM, on Craigslist, from name-brand companies [HP, Dell, etc], for circa $500. And they will be of VASTLY higher quality [with esp. vastly better motherboards] than the consumer-oriented junk that those same companies are peddling.

Since the investigation in these countries tends to leak like a sieve, we got info that that particular country was paying someone mid-level in customer support dept. to give them data on customers.

All the corporate privacy/security policies [and, for that matter, government privacy/security LAWS] in the world aren't worth diddly squat in the presence of a determined mole.

I seem to recall that the key element of the plot of Dune involved a traitor at the heart of House Atreides...





PS: Wow, has it been almost 30 YEARS since Dune was released?!?

Yikes!!!

I feel old.

Old. Old. Old. Old. Old.

PPS: Man, you know that Virginia Madsen was a world-class piece of tail if she was as hawt in Sideways (2004) as she had been in Dune [if not even hawter?].

Whew.

by hiding data in content cached by certain ISPs transparent proxies

Okay, I'll say it: That's really evil.

Of course, if you miss even one of the 7 places the site hid the data, the other 6 are immediately restored from it next time you visit.

God, I'm starting to feel old.

7 places?!?

I think I might have just experienced a "get off my lawn" moment...

The Palin Hacker did far less than this, yet he's facing hard time in the federal pen; this case shouldn't be in the civil courts - it ought to be playing out in the CRIMINAL court system:



How Mark Zuckerberg Hacked Into Rival ConnectU In 2004
Mar. 5, 2010
http://www.businessinsider.com/how-mark-zuckerberg-hacked-connectu-2010-3

...At one point, Mark appears to have exploited a flaw in ConnectU's account verification process to create a fake Cameron Winklevoss account with a fake Harvard.edu email address.

In this new, fake profile, he listed Cameron's height as 7'4", his hair color as "Ayran Blond," and his eye color as "Sky Blue." He listed Cameron's "language" as "WASP-y."

Next, Mark appears to have logged into the accounts of some ConnectU users and changed their privacy settings to invisible. The idea here was apparently to make it harder for people to find friends on ConnectU, thus reducing its utility. Eventually, Mark appears to have gone a step further, deactivating about 20 ConnectU accounts entirely...



Zuckerberg is a psychopath - the specter of him being one of the wealthiest [and most powerful] people on the planet ought to send a chill down your spine.

The Sarah Palin hacker did less than this, and he was sentenced to hard time:



How Mark Zuckerberg Hacked Into Rival ConnectU In 2004
Mar. 5, 2010
http://www.businessinsider.com/how-mark-zuckerberg-hacked-connectu-2010-3

...At one point, Mark appears to have exploited a flaw in ConnectU's account verification process to create a fake Cameron Winklevoss account with a fake Harvard.edu email address.

In this new, fake profile, he listed Cameron's height as 7'4", his hair color as "Ayran Blond," and his eye color as "Sky Blue." He listed Cameron's "language" as "WASP-y."

Next, Mark appears to have logged into the accounts of some ConnectU users and changed their privacy settings to invisible. The idea here was apparently to make it harder for people to find friends on ConnectU, thus reducing its utility. Eventually, Mark appears to have gone a step further, deactivating about 20 ConnectU accounts entirely...

My 53 year old uncle is a senior professor... his IBM monstrosity that cost $100K... an input-compatible version of his Fortran 70 compiler... an array as a stack in a for loop to make program flow clear... the faculty mainframe in '87... FORTRAN was designed BEFORE the compiler was invented... a huge fuck-you to 40 years of software research...

LMFAO!!!

You go, Uncle Professor Dude - you go girl!!!

Abso-fscking-lutely hilarious!!!

Man, I haven't chuckled that hard in a while...

How Mark Zuckerberg Hacked Into Rival ConnectU In 2004
Mar. 5, 2010
http://www.businessinsider.com/how-mark-zuckerberg-hacked-connectu-2010-3

...At one point, Mark appears to have exploited a flaw in ConnectU's account verification process to create a fake Cameron Winklevoss account with a fake Harvard.edu email address.

In this new, fake profile, he listed Cameron's height as 7'4", his hair color as "Ayran Blond," and his eye color as "Sky Blue." He listed Cameron's "language" as "WASP-y."

Next, Mark appears to have logged into the accounts of some ConnectU users and changed their privacy settings to invisible. The idea here was apparently to make it harder for people to find friends on ConnectU, thus reducing its utility. Eventually, Mark appears to have gone a step further, deactivating about 20 ConnectU accounts entirely...

I don't know how their computers decide what to keep where. Some popular things (like Microsoft updates) I think get auto cached, others I think it is based on demand.

Gee, I hope that MSFT put on their thinking caps and did their homework when they were designing their "signing" algorithms.

'Cause I shudder to think what might happen if the locally-cached Akamai version of a security update were not [for what ever reason] quite the same as the official MSFT version.

Dittoes for hardware drivers, which very often are NOT signed in any way: Break into the Akamai server, upload your version of whatever, then pwn the user systems immediately upon downloading.

And don't think for a second that the Chinese Red Army and the Russian Army aren't devoting beaucoup $$$s & man-hours to precisely these kinds of attack vectors.

Bottom line: It's one thing to be caching relatively harmless stuff, like JPGs and MPGs and WAVs and GIFs and TXTs, but caching EXEs is a whole 'nother can of worms...

Isn't a water tower made out of, ah, metal?

And don't they get these things called, ah, thunderstorms in Florida?

And don't thunderstorms produce these surges of static electricity called, ah - help me out here - ah, lightning?

And, ah, wouldn't lightning be attracted to all that metal stuff?

Seriously - I hope that somebody put some long hard thought into how they are going to try to ground this thing.

And what the heck kind of surge protectors are going to be sitting at the ingress and egress points.

In 2000 they should have copied Apple again and based their next windows(that would become Vista) on a BSD or Linux kernel.

I have never heard anyone say a bad word about the actual NT Microkernel, or, for that matter, about Cutler et al's work on VMS [which, to this day, has a reputation as being one of the most rock-solid, 24x7x365, 5/6/7/8/9-sigma operating systems known to man].

Even the old embedded versions of NT, although they never gained all that much market share [vis-a-vis VXWorks], had a reputation for being very solid operating systems.

Now you might not like some of the cruft which has been bolted on top of the NT Microkernel [Win32, Win64, NTVDM's, DirectX, etc etc etc], but if anyone has a beef with the underlying microkernel, then I haven't heard about it.

It's probably more likely that kernel developers will just need to adjust defense mechanisms to account for a new set of attack vectors.

Right - that was my original point, up at something like the GGP or GGGP level of this thread.

The kernel guys [and/or the Intel guys] were really sloppy when Intel first introduced dual-cores with shared-cache - we had all sorts of exploits where one core could sniff from a cache which [ostensibly] was supposed to have been the under the purview of another core.

And I'm saying that the kernel/microkernel guys - in conjunction with the hardware guys writing the drivers [ATi and the various "free"-lancers], and even the "application" guys, like the DirectX team at Microsoft, and the OpenGL crew - will all need to buckle down and put on their thinking caps and ask themselves: How are we going to harden the kernel [microkernel] against any incestous attack vectors coming from a GPU core which lives on the same silicon as the CPU cores? [And then they need to burn a little midnight oil to produce a stable implementation of their plans.]

Eventually they will get it right [and hopefully AMD has put a fair amount of thought into this already], but if anyone gets sloppy [from the AMD CPU team to the kernel/microkernel teams to the ATi driver team to the "applications" guys at DirectX and OpenGL], then we could be looking at some great big gaping holes in the security model.

In the old days, there was a physical chipset which sat between the GPU and the CPU.

But in this architecture, there is no physical barrier - they're on the same silicon.

Look for the bad guys to try to force the graphics drivers to sneak over and sniff the memory of the CPUs - I can imagine how they might be able to load some code in a pr0n movie that could tell some pointer in a GPU driver to point to addresses of cache which [at least ostensibly] belong to a CPU, at which point they should be able to read the cache.

And if they're lucky, their specially-crafte pr0n-videos might even be able to WRITE to the CPU cache, at which point they can probably pwn the entire operating system.

Hopefully AMD has put some thought into their implementation, and has some sort of hardware safeguards that force the GPU to always act as the "slave" of its masters [the CPUs], but, if not, then all Hades could break loose.

[And Intel probably won't put nearly as much thought into their implementation as AMD did with theirs.]

Many of the improvements stem from eliminating the chip-to-chip linkage that adds latency to memory operations and consumes power - moving electrons across a chip takes less energy than moving these same electrons between two chips. The co-location of all key elements on one chip also allows a holistic approach to power management of the APU.

Dual-core shared-cache architectures wreaked havoc on kernel security when they were first introduced - and we still aren't entirely certain that our operating systems are fully secure against shared-cache exploits - we seem to get about a new one about every six to twelve months.

So are the kernel [& micro-kernel] and driver guys fairly confident that we won't be getting incestuous security problems when kernels and drivers start sharing the same silicon?

I predict an initial round of exploits as the kernel guys have to re-learn their approaches to hardening their operating systems against the graphics drivers.