no matter how much you secure the internet browser it is a high risk application by the very nature of what it does (browse complex content created by unknown sources)
Indeed, which is why it should not contain mechanisms for that content to request privilege escalation.
protected mode adds another layer of security
Unfortunately, neither protected mode not IE by themselves provide a very high level of security.
You can completely own the iexplore process and still you can not do any attacks you claim are possible from a protected mode instance of IE
There are things that IE must be able to do to function as a browser. It must be able to read and write temporary internet files. It must be able to read its own configuration. It must be able to open files in your profile. It must be able to open TCP/IP connections to web sites. It must be able to send mail. It must be able to create windows and other graphical user interface objects. It must be able to make system calls. These are the things that I claim are possible from a protected mode instance of IE, because they must be possible from IE. These are all things that can be used to mount secondary attacks.
"Defense in depth" typically involves multiple layers of protection, each of which is designed as securely as it can be. Putting a leaky wall in front of a sandbox that allows secondary attacks is a terribly weak "defense in depth". Putting a firewall in front of network services that can not be disabled is not "defense in depth". Running IE inside a temporary virtual machine firewalled outside that VM's trust boundary to only allow TCP/IP connections to a logging web proxy, or running a KHTML-based browser in a chrooted environment, these are defense in depth where each of the layers involved constitutes a significant defense.
But IE inside protected mode? That's inviting a vampire into your spare bedroom and hoping he doesn't interpret it as carte blanche access to the rest of your house.
Interesting that BootCamp keeps Apple clear of being accused of Tivoization:)
Tivoization doesn't mean "you can't boot other operating systems", really. It means "you can't even install software, period". It'd be nice to be able to replace all the software down to the ROMs, but there's always something you don't have source and spec for if only things like GPU and hard drive firmware... Tivoization is about the system as a whole.
Am I right in thinking that Apple is going to have to support the use of other OS's on all their future hardware that uses GPL3 software?
There's no GPL code in the kernel. They'll need to keep letting you install your own version of the GPLed software they DO ship, though... like they already do.
But are you sure about the applications on the iPhone being an entirely different thing from the widgets on Dashboard?
Dashboard provides a significantly extended API, including the ability to run native code components, that does not exist in Safari on OS X or Windows. Safari is based on Webkit, a variant of KHTML, which gives the application the responsibility for providing extensions to the base environment, Dashboard is also based on Webkit but it is a different application than Safari and provides different extensions. Even getting Dashboard widgets that don't use the Dashboard API running directly in Safari takes a bit of fiddling (not a lot, but some).
I have a high degree of confidence that since iPhone-directed applets can be prototyped on Safari in Windows the iPhone does not provide the Dashboard extensions.
Yes, there are similarities between Dashboard widgets and iPhone apps, but less than between them and Facebook widgets, Palm PQAs, Firefox extensions, Active Desktop applets, WML pages, and any other HTML-based applet environments.
In decades, I have never known even one user to have much technical knowledge. They just want to use computers as a tool, not make computers a time-consuming profession.
You're an optimist. Even the users who DO have technical knowledge get caught by this.
For most of the past fifteen years I have been a system admin for a network of software developers.
I have had several of them come to me and say "Peter, I just clicked OK (or Open, or whatever it was in this case) on that window again and I think I have a virus."
Note that word again.
These are smart guys. We're talking PhD egnineers who've been programming for a living since that meant coding pads and punched cards. Approval dialogs are so frequently presented, and so easy to reflexively select the default action, that people like this are *still* making the same mistake multiple times.
The most effective thing I ever did in that job, from the point of view of desktop security, was to ban Internet Explorer in our division. That pretty much stopped that kind of incident. When they integrated IT and overrode me, and put a "standard load" with a version of IE "locked down" as tight as Corporate could stand, I started getting people coming to me with that story again.
By default it will ask users if they want to install controls after first showing them the signature information.
In other words, it's enabled by default. The fact that an approval dialog is displayed first is irrelevant: Windows trains people to automatically approve such dialogs, by reflex, because they're presented with them all the time.
Completely false - it is trivial to disable activex controls and it can be done without launching the browser (right click on IE in your start menu, chose internet properties.)
You misunderstand what I mean. I'm not talking about the user deciding that some component should be disabled, I'm talking about disabling the ability for Internet Explorer to run any already-installed ActiveX controls at all. You can't do that, because IE is implemented as a shell around a group of such controls, including the HTML control itself.
I'm not sure I understand your sentences here, but IE does run 'distinct instances'
All instances of IE use the same settings, and grant the same rights to objects they display. Therefore, from a security point of view, they're a single instance.
it runs IE instances in protected mode
That is an attempt to mitigate the fact that IE is not inherently secure. The problem is that security is like sex... once you're penetrated you're fucked. If an attacker can run code on your computer, even if they protected mode is everything that Microsoft claims (and it isn't), a remote exploit still grants them a beachead to launch further attacks using any resources available to IE... which include the ability to run applications (to attempt a local privilege escalation attack), make network connections (to attempt remote exploits against other systems on the LAN from behind the perimeter firewall), send mail (as part of a spam botnet), and read local resources (to extract security tokens for offline decryption, harvest addresses for secondary attacks, and so on).
Actually, the user makes the decision and the app hosting IE can not override this - the user will always be prompted - some would call this a security feature.
Yes, a lot of people mistake the omnipresent approval dialogs in Windows for a security feature. Unfortunately, they're terribly mistaken... they're actually a sign of an inherently insecure application.
An inherently secure application doesn't ask a user "I'm about to do something stupid, should I go ahead?". It's designed so that it doesn't need to do stupid things.
If your editor word-wraps and auto-formats then you're probably working with a 60-70 character line, no matter how many characters are in the statement, just like the fellow who's breaking it up manually. This has nothing to do with the size of identifiers.
Personally, I like writing in what I think of as "lisp style".
// Lisp style: lay out your code based on expressions, whether they're separate statements or not.
I am pretty sure that holographic data storage can be modified to use no moving parts at all
Sure, so long as you don't want to store more bits than you have transducers. There's lots of ways to store data in charged or magnetised material with no moving parts: RAM, ROM, core memory. The problem is that you usually need to build a physical sensor of some kind for every bit that you want to store, which severely limits the capacity of the device.
In some cases you can store multiple bits per sensor by having a mechanism to cycle storage locations past a sensor. There's a few approaches here, like acoustic storage (descendants of the mercury delay line in EDSAC) and bubble memory, but they have their own problems.
The closest to a system with "no moving parts" is one that uses a steerable short-wavelength beam in free-space to share a sensor between a number of locations. This can provide a constant increase in capacity per sensor, at the cost of increasing the time required to address a given location. You still need many many sensors to read a significant amount of data.
If you have ever made a holograph in a physics class, you will remember that nothing was moving there
Magnets have no moving parts, either... but you can't read more than one bit per magnet. The illusion that holographic storage would need no moving parts only exists because you're using a high density grid of moving sensors that you're so familiar with you don't notice you're using them.
Secure software doesn't mean "software that has no security holes". It means "software that is designed so that failure doesn't create security holes". Secure software is, by default, inherently safe. Secure software provides feedback on errors. Secure software can not be unlocked except from the "outside". Secure software provides interfaces and protocols with no paths leading to elevated privileges. Secure software provides fault isolation and user-visible and managable layering.
Secure software may have bugs that lead to exploitable vulnerabilities, but fixing these bugs will not break third-party components that depend on public interfaces and protocols exposed by the software, because the privileges exposed by the vulnerability are never intended to be exposed.
For example, if an interface in a secure application provides an object (file, script, applet, web page,...) more privileges than the application itself normally provides, then:
(1) That interface is disabled by default. Ideally, there is no code path in the application that leads to that interface. (2) Enabling that interface requires a deliberate premeditated action by the user or administrator. Ideally, this action involves a plug-in or other component in a distinct repository from the one that the application normally uses, and running a new instance of the application (or a new shell around the application) that has access to that repository. (3) Enabling that interface in one instance of the application does not enable it in any other instance. (4) An instance of the application with that interface enabled can not be accessed by any request to an instance of the application with that interface disabled. (5) The mechanism by which a user launches the modified instance of the application is clearly distinct. (6) The modified instance of the application does not include a mechanism to load new objects through protocols that are normally used to access untrusted data, except using addresses (URIs, file paths, etcetera) that are provided by the application itself, or by launching a new instance of itself without any unsafe interfaces enabled.
The poster child for applications that violate these rules is Internet Explorer. In Internet Explorer, it is possible for a webpage to request an applet it provides be installed and run, through a mechanism called "ActiveX".
(1) It is enabled by default. (2) It is not possible to launch IE in a way that prevents access to ActiveX plugins already installed. (3) There is only one pool of plugins for IE. Worse, there is one pool of plugins shared among all applications that use the HTML control. (4) You can't disable it, all you can do is tell IE to avoid "unsafe" controls, and even then the default behavior for "unsafe" controls is risky. (5) There's no distinct instance of IE... rather there's a set of heuristics for the HTML control to use to try and guess whether the document being viewed should be considered "safe" or not. (6) The HTML control makes the decision as to whether to load an object, not the application.
Most browsers have *some* shortcomings in this area, but few to anywhere near the extent of IE, and none are designed so that fixing these shortcomings will break working applications until they are redesigned to access the browser through a new API.
Except if you develop it as a webapp with offline mode, e.g. using something like Google Gears, right ?
You can't write an application using Google Gears on the iPhone without installing the Google Gears plugin, which you can't do, because you can't install any native code.
You are making the mistake of thinking "3rd party development == C coders."
No, I'm making the mistake of thinking "applications" == "things that run on the phone".
Web applets? I've used them on my Palm and Pocket PC, years before the iPhone was a twinkle in Steve's eye. Every device has these... they *also* run software on the device itself, so you can use them with the battery-eating radio shut down.
One of the most popular classes of applications on the Palm, for example, are input methods. You want something faster than their predictive keyboard? Sorry, you're out of luck. You want an eBook reader that doesn't require you to be online the whole time you're reading? Uh-uh, you don't get that. An aplication I use all the time is a shopping list app... that I couldn't use on the iPhone even if it was available as a web applet because there's a big fat dead area near the back of my neighborhood supermarket.
This doesn't mean that it won't be a popular device. A lot of people seem happy with fancy dumb phones, but claiming that this is in any way comparable to the ability to run real native applications, or that being able to run web applets is some kind of unique feature of the iPhone, is just daft. That's something the competition has been doing for almost a decade now, and unless the people writing the applets are particularly stupid they're almost all going to work on any handheld. Certainly the only ones I've found that are iPhone-only are ones that explicitly check to see if they're running on one.
The whole "no native API" thing on the iPhone is a ludicrous idea in the first place.
The Xbox was designed to sell for less than the cost of manufacture and make up for it with games sales, and the end-users of the Xbox have a reason to WANT it to be locked down - to prevent other users cheating them.
The iPhone has a nice fat 40%+ margin built in, and iPhone users don't (so far as I know) run around shooting each other with bluetooth bullets. Locking down the iPhone makes no more sense than locking down the Treo or Pocket PC.
You haven't had a problem. That's great. Other people have.
Now... I don't think anyone claiming this is a surprise is being completely honest. This is similar to the iPod battery replacement policy, and everyone's known about that for years, and people have been pointing out that the battery isn't field-replaceable pretty much since the iPhone was announced.
How can Stallman be the reason for free software, when there was a thriving free software community before he even started penning the GNU manifesto? The first free (as in speech) UNIX environment was released by Bell Labs in the '70s, as a set of libraries and a Ratfor compiler under the name "Software Tools". The Software Tools virtual OS eventually became a very comlete hosted UNIX environment for the minicomputers and mainframes of the '70s and early '80s. The first free (as in speech) C compilers were published in the late '70s by Dr Dobbs' Journal, and developed for over a decade - I did a port of one to the 6809 in 1983.
BSD was given a free license due to Stallman and the FSF's efforts.
Um, that doesn't happen to be the case.
The reason that USL backed down on the USL-CSRG lawsuit was to cut a cross-licensing knot: System V was using BSD software in violation of AT&T and USL's contracts with UCB (they didn't provide proper attribution for the components they used), and they decided to cut their losses while they still had something to sell to Novell.
The FSF wasn't in the picture, their attention was all on their own HURD project... in fact the FSF was strongly opposing the BSD license, and it's still opposed to the kind of unencumbered release of software that the BSD license represents. They denigrate their *own* library license (and they renamed it to the "lesser" license later on).
Hell, the FSF's support of Linux was lukewarm at first. RMS seemed pretty ticked off (in print at least) that Linus didn't call his OS "GNU something".
Whether or not the FSF existed, the AT&T-free BSD code base would still have come out, at about the time it did. The AT&T-free release was initiated, carried through, and completed by members and ex-members of the Berkeley Computer Science Research Group, and by negotiations between the Regents of the University of California and AT&T and subsequent owners of the UNIX license.
You can't argue that BSD's example would have influenced Torvalds to have opened up Linux, or that its free license would have had him contribute to BSD instead of his own system
Um, I don't know what you're getting at here. At the time I'm referring to, there was no Linux yet. Linus was still messing about with Minix. Linus has said, in as many words, that if the AT&T-free BSD had been ready a year earlier he would have been using that instead of going on to develop Linux.
Without Linus Torvalds, we would be in a relatively similar boat, running BSD-based systems in place of Linux-based systems.
Er, yes, I already mentioned that too. Without either of them the BSD code base would have ended up in the same place.
It is possible to play SL and never once buy a "sex gen" product, if that's what bothers you. And of course it's also possible to play it without selling pirated copies of someone else's products. Unless you were hoping to do either of these things, what's stopping you?
OOXML is XML -- if you want to extract plain text from it just feed it through a XML parser and strip all the tags.
Precisely my point. If the layout and non-text information in the file matters, then you've thrown it away. If it doesn't, then why are you bothering to put it in the archive?
You can do something similar with Office's format, but the solution will be far less perfect and contain lots of junk.
Yes, and (as I noted) I've done the same thing, and it's a relatively crude way of reverse-engineering the format.
On a spectrum of "what's a good archive format" OOXML is a bit better than older office formats.
But compared to even something like HTML that's got an open specification that's actually open enough to have multiple independent implementations, and easy enough to implement that you can do it in BASIC for display on a dumb terminal, OOXML is just daft.
Yeh, licenses that limit redistribution, or limit redistribution of modified code, are the kiss off death for projects. One of the things that made UNIX really successful in the academic community early on is that so long as your school had a compatible source license you could get other people's distributions and work with them. That's probably why the BSD license is so liberal.
But this isn't something that's really all that different now. There's still packages that have licenses like that, like qmail. They're a huge roadblock to wide acceptance. Of course both the Minix and Qmail authors also have authors who have very strong opinions on technical subjects that are more important than the broadest distribution to them. But there have been open source projects inspired by UNIX that *don't* have those kinds of restrictions all the way back to the '70s. If we had good cheap 32-bit personal computers with MMUs in 1980, then we'd probably be using a descendent of MINT or OMU or the Software Tools VOS...
OK, the deal is this. Let's say you have a bunch of files in some old format, and a spec for that format, and you need some information out of those files. That spec ill be useful to you if - and only if - the cost of implementing that format from the spec is less than the cost of losing those files, AND it's less than the cost of reverse-engineering enough of the format to extract the information you want from the files.
The OOXML spec is huge (expensive to implement from the spec) and complex, and the meaning of many components can't really be determined without looking at the way Office behaves (so it's incomplete, this implementing a reader for it will require a fair amount of trial and error). Reverse-engineering Office's format may be much easier, depending on what information you're looking for... just extracting the text strings from a Word document has often been MY preferred method of reverse-engineering it...
Which means that OOXML is a poor archival format... unless you want to lock people who want to use the archives in the meantime into using Microsoft Office to read them.
Without Richard Stallman we would still have Linux. Without Linus Torvalds, we wouldn't.
Without Richard Stallman Linus would have had to use another compiler, of which there were at least three available at the time. Without Richard Stallman he would have used a different license, but that wouldn't have kept people from joining up to work on Linux... using a different license didn't keep people from working on BSD, and it didn't even keep people from working on Minix... which wasn't freely redistributable by any means.
Heck, without William Jolitz we might not have had Linux. Jolitz redirected a lot of the interest in BSD Net/2 and BSD Lite into 386BSD for a couple of years, and never went anywhere with it. Linus has written that if the fully open-source BSD had been ready even a year sooner, he would have worked on it and there wouldn't be a Linux. But there might have been a better BSD... because a lot of the reason Linux was developed so effectively early on is that Linus is a genuinely nice guy, as well as a good project leader *and* technically competent.
But either way, there were multiple projects and source trees developed duing the '80s that would have produced the same kind of open source environment we have now, with or without Richard Stallman. The details might have been different without him... it's hard to say... but the idea that he was *necessary* for any of this? No.
What copyright means, and why DRM doesn't matter.
on
Woz on Open Source, DRM
·
· Score: 3, Insightful
You're off on the wrong foot right from the start in that article. You write "It's the right of HE who own the material to put in whatever form they want." which is true, but it's got nothing to do with copyright, or DRM, or anything else.
Copyright is fundamentally very simple. It's the right to make a copy.
In practice that's pretty complex, because... what's a copy? If you decide to get really technical, when you read a book or listen to a song, you're making a copy of it. It's low fidelity, unless you've got an unlikely good memory, but by your logic an artist should have the right to sue you if you hum the time or recite the story in public. Oh, I'm sure that you wouldn't go that far... but it's where the logic leads.
Copyright law is complex because copyright law is mostly about defining EXACTLY what a copy is. And when a copy is subject to copyright. There's been licenses on software that are based on the theory that you're making a copy of the software when you install it on your computer, but there's nothing about copyright restrictions preventing you from making a temporary copy of the images in a video when you play it on your TV. Unless you do it in a public place... then it's a performance. And you're allowed to make a personal copy of a movie off your TV if it was broadcast, which is a kind of public performance though your playing it isn't, or even if it's on a DVD... but not if you're playing it from a rented DVD, whether it's a public performance or not, and not if you're seeing it in a movie, which is another kind of public performance.
So, first off, while an artist has a right to use whatever format they want, that doesn't mean you don't have the right to make a recording in another format... for your own use. Apple got attacked for their "RIP, MIX, BURN" advertising campaign... but it turns out that in the US it's legal to "RIP, MIX, BURN". And it's legal to do that even if the music was DRMed to begin with.
So that's the second thing. The main reason for DRM is to try and create new rights. The DMCA is a really useful tool, because it makes it illegal to use "technical means" to bypass DRM. So while the law doesn't say that an artist has the right to prevent you from making a personal copy of an HD DVD, they're *creating* that right by gluing together bits of the law. This kind of thing happens all the time, the law says one thing, someone comes up with a way to make it mean something else, and sometimes the law gets changed to say that the other thing is really in there, or it gets changed to say the other thing was an unintended side effect and it's really OK to eat peanuts on church after all.
This kind of thing also ends up making the definition of a "copy" trickier.
And people aren't stupid. They look at the way things work, and they look at DRM, and they go "you know, you're treating your fans like shit". So they either treat the artists like shit in return, or they decide they don't like the music enough to put up with being treated like shit. So there's actually competition, and market forces, and all that America and Apple Pie stuff, and what it does it makes DRM into something that provides an advantage for the artists who don't use it. Particularly the ones who aren't selling that well, yet... so they put stuff out that's not restricted, and people discover it, and they go "hey, this is good stuff", and they go "hey, this guy is cool", and they buy his stuff. And there's guys who've made it this way.
And these artists aren't signing with EMI. So EMI's not getting their cut, so this gives EMI a reason to go DRM-free... maybe they can sign a few of the hot new internet artists who'd otherwise be going through CDbaby and eMusic and getting earplay through last.fm. Because, you know, the Internet isn't going away.
I hate the "Napster clones". I think Napster should have been slapped down HARD, right off, because their whole business model was deliberately about setting up cutouts so they could get a cut of copyright violati
Come on, not only was it the grand-daddy, great-grand-daddy, and multi-dimensional n-parent of everything from lunar lander to flight simulators, but it was the most popular videogame in the world for over a decade!
First smartarse who points out that it was the ONLY videogame in the world will just be proving my point.
According to Apple, Leopard will allow you to use existing 32-bit drivers and 64-bit applications in the same system with the same OS version:
Driver compatibility.
Because of its universal nature, with Leopard you don't need a new set of drivers -- or devices. New 64-bit applications work just fine with your existing printers, storage devices, and PCI cards. Even better, if you upgrade to new 64-bit-capable drivers, your 32-bit applications will also benefit from the increased throughput.
Microsoft's making the problem worse in Vista, because they changed a lot of the driver APIs in Vista to support its enhanced DRM. Even if they supported 32-bit drivers in Vista existing 32-bit drivers wouldn't be DRM-friendly: even many 64-bit drivers from previous versions of Windows don't work.
Slashdot Mirror
no matter how much you secure the internet browser it is a high risk application by the very nature of what it does (browse complex content created by unknown sources)
Indeed, which is why it should not contain mechanisms for that content to request privilege escalation.
protected mode adds another layer of security
Unfortunately, neither protected mode not IE by themselves provide a very high level of security.
You can completely own the iexplore process and still you can not do any attacks you claim are possible from a protected mode instance of IE
There are things that IE must be able to do to function as a browser. It must be able to read and write temporary internet files. It must be able to read its own configuration. It must be able to open files in your profile. It must be able to open TCP/IP connections to web sites. It must be able to send mail. It must be able to create windows and other graphical user interface objects. It must be able to make system calls. These are the things that I claim are possible from a protected mode instance of IE, because they must be possible from IE. These are all things that can be used to mount secondary attacks.
"Defense in depth" typically involves multiple layers of protection, each of which is designed as securely as it can be. Putting a leaky wall in front of a sandbox that allows secondary attacks is a terribly weak "defense in depth". Putting a firewall in front of network services that can not be disabled is not "defense in depth". Running IE inside a temporary virtual machine firewalled outside that VM's trust boundary to only allow TCP/IP connections to a logging web proxy, or running a KHTML-based browser in a chrooted environment, these are defense in depth where each of the layers involved constitutes a significant defense.
But IE inside protected mode? That's inviting a vampire into your spare bedroom and hoping he doesn't interpret it as carte blanche access to the rest of your house.
"I challenge you to find a hundredth as many Graphic Artists who prefer the keyboard as who prefer the mouse when either will perform a given action."
r /keyboard-shortcuts.htmlu ts-glance_ shortcuts.htmla tsheet.htmll .php?url=shortcut
http://www.photoshopsupport.com/tutorials/jennife
http://www.sitepoint.com/article/photoshop-shortc
http://www.heathrowe.com/tuts/shortcuts.asp
http://user.fundy.net/morris/?photoshop01.shtml
http://www.zenhaiku.com/archives/useful_photoshop
http://www.creativetechs.com/iq/photoshop_cs2_che
http://www.spoono.com/photoshop/tutorials/tutoria
First there were CLI editors like TECO and they were Ok
... sucky.
Then came the came the command sequence editor like vi and they were good.
Then came the hot key editors like Emacs and WordStar and they were
Then came the command style editors like Brief and Elvis, and they were good again
And then came nvi and it was excellent
And that's really the end of the line.
Interesting that BootCamp keeps Apple clear of being accused of Tivoization:)
Tivoization doesn't mean "you can't boot other operating systems", really. It means "you can't even install software, period". It'd be nice to be able to replace all the software down to the ROMs, but there's always something you don't have source and spec for if only things like GPU and hard drive firmware... Tivoization is about the system as a whole.
Am I right in thinking that Apple is going to have to support the use of other OS's on all their future hardware that uses GPL3 software?
There's no GPL code in the kernel. They'll need to keep letting you install your own version of the GPLed software they DO ship, though... like they already do.
But are you sure about the applications on the iPhone being an entirely different thing from the widgets on Dashboard?
Dashboard provides a significantly extended API, including the ability to run native code components, that does not exist in Safari on OS X or Windows. Safari is based on Webkit, a variant of KHTML, which gives the application the responsibility for providing extensions to the base environment, Dashboard is also based on Webkit but it is a different application than Safari and provides different extensions. Even getting Dashboard widgets that don't use the Dashboard API running directly in Safari takes a bit of fiddling (not a lot, but some).
I have a high degree of confidence that since iPhone-directed applets can be prototyped on Safari in Windows the iPhone does not provide the Dashboard extensions.
Yes, there are similarities between Dashboard widgets and iPhone apps, but less than between them and Facebook widgets, Palm PQAs, Firefox extensions, Active Desktop applets, WML pages, and any other HTML-based applet environments.
In decades, I have never known even one user to have much technical knowledge. They just want to use computers as a tool, not make computers a time-consuming profession.
You're an optimist. Even the users who DO have technical knowledge get caught by this.
For most of the past fifteen years I have been a system admin for a network of software developers.
I have had several of them come to me and say "Peter, I just clicked OK (or Open, or whatever it was in this case) on that window again and I think I have a virus."
Note that word again.
These are smart guys. We're talking PhD egnineers who've been programming for a living since that meant coding pads and punched cards. Approval dialogs are so frequently presented, and so easy to reflexively select the default action, that people like this are *still* making the same mistake multiple times.
The most effective thing I ever did in that job, from the point of view of desktop security, was to ban Internet Explorer in our division. That pretty much stopped that kind of incident. When they integrated IT and overrode me, and put a "standard load" with a version of IE "locked down" as tight as Corporate could stand, I started getting people coming to me with that story again.
By default it will ask users if they want to install controls after first showing them the signature information.
In other words, it's enabled by default. The fact that an approval dialog is displayed first is irrelevant: Windows trains people to automatically approve such dialogs, by reflex, because they're presented with them all the time.
Completely false - it is trivial to disable activex controls and it can be done without launching the browser (right click on IE in your start menu, chose internet properties.)
You misunderstand what I mean. I'm not talking about the user deciding that some component should be disabled, I'm talking about disabling the ability for Internet Explorer to run any already-installed ActiveX controls at all. You can't do that, because IE is implemented as a shell around a group of such controls, including the HTML control itself.
I'm not sure I understand your sentences here, but IE does run 'distinct instances'
All instances of IE use the same settings, and grant the same rights to objects they display. Therefore, from a security point of view, they're a single instance.
it runs IE instances in protected mode
That is an attempt to mitigate the fact that IE is not inherently secure. The problem is that security is like sex... once you're penetrated you're fucked. If an attacker can run code on your computer, even if they protected mode is everything that Microsoft claims (and it isn't), a remote exploit still grants them a beachead to launch further attacks using any resources available to IE... which include the ability to run applications (to attempt a local privilege escalation attack), make network connections (to attempt remote exploits against other systems on the LAN from behind the perimeter firewall), send mail (as part of a spam botnet), and read local resources (to extract security tokens for offline decryption, harvest addresses for secondary attacks, and so on).
Actually, the user makes the decision and the app hosting IE can not override this - the user will always be prompted - some would call this a security feature.
Yes, a lot of people mistake the omnipresent approval dialogs in Windows for a security feature. Unfortunately, they're terribly mistaken... they're actually a sign of an inherently insecure application.
An inherently secure application doesn't ask a user "I'm about to do something stupid, should I go ahead?". It's designed so that it doesn't need to do stupid things.
Personally, I like writing in what I think of as "lisp style".
I am pretty sure that holographic data storage can be modified to use no moving parts at all
Sure, so long as you don't want to store more bits than you have transducers. There's lots of ways to store data in charged or magnetised material with no moving parts: RAM, ROM, core memory. The problem is that you usually need to build a physical sensor of some kind for every bit that you want to store, which severely limits the capacity of the device.
In some cases you can store multiple bits per sensor by having a mechanism to cycle storage locations past a sensor. There's a few approaches here, like acoustic storage (descendants of the mercury delay line in EDSAC) and bubble memory, but they have their own problems.
The closest to a system with "no moving parts" is one that uses a steerable short-wavelength beam in free-space to share a sensor between a number of locations. This can provide a constant increase in capacity per sensor, at the cost of increasing the time required to address a given location. You still need many many sensors to read a significant amount of data.
If you have ever made a holograph in a physics class, you will remember that nothing was moving there
Magnets have no moving parts, either... but you can't read more than one bit per magnet. The illusion that holographic storage would need no moving parts only exists because you're using a high density grid of moving sensors that you're so familiar with you don't notice you're using them.
Secure software doesn't mean "software that has no security holes". It means "software that is designed so that failure doesn't create security holes". Secure software is, by default, inherently safe. Secure software provides feedback on errors. Secure software can not be unlocked except from the "outside". Secure software provides interfaces and protocols with no paths leading to elevated privileges. Secure software provides fault isolation and user-visible and managable layering.
...) more privileges than the application itself normally provides, then:
Secure software may have bugs that lead to exploitable vulnerabilities, but fixing these bugs will not break third-party components that depend on public interfaces and protocols exposed by the software, because the privileges exposed by the vulnerability are never intended to be exposed.
For example, if an interface in a secure application provides an object (file, script, applet, web page,
(1) That interface is disabled by default. Ideally, there is no code path in the application that leads to that interface.
(2) Enabling that interface requires a deliberate premeditated action by the user or administrator. Ideally, this action involves a plug-in or other component in a distinct repository from the one that the application normally uses, and running a new instance of the application (or a new shell around the application) that has access to that repository.
(3) Enabling that interface in one instance of the application does not enable it in any other instance.
(4) An instance of the application with that interface enabled can not be accessed by any request to an instance of the application with that interface disabled.
(5) The mechanism by which a user launches the modified instance of the application is clearly distinct.
(6) The modified instance of the application does not include a mechanism to load new objects through protocols that are normally used to access untrusted data, except using addresses (URIs, file paths, etcetera) that are provided by the application itself, or by launching a new instance of itself without any unsafe interfaces enabled.
The poster child for applications that violate these rules is Internet Explorer. In Internet Explorer, it is possible for a webpage to request an applet it provides be installed and run, through a mechanism called "ActiveX".
(1) It is enabled by default.
(2) It is not possible to launch IE in a way that prevents access to ActiveX plugins already installed.
(3) There is only one pool of plugins for IE. Worse, there is one pool of plugins shared among all applications that use the HTML control.
(4) You can't disable it, all you can do is tell IE to avoid "unsafe" controls, and even then the default behavior for "unsafe" controls is risky.
(5) There's no distinct instance of IE... rather there's a set of heuristics for the HTML control to use to try and guess whether the document being viewed should be considered "safe" or not.
(6) The HTML control makes the decision as to whether to load an object, not the application.
Most browsers have *some* shortcomings in this area, but few to anywhere near the extent of IE, and none are designed so that fixing these shortcomings will break working applications until they are redesigned to access the browser through a new API.
I see no big problem apart from having to port some Java code to a different platform.
There's no Java on the iPhone. Sorry.
How much effort would it take to build a dashboard-widget runner on top of KHTML?
There's no Dashboard support on the iPhone, either.
Except if you develop it as a webapp with offline mode, e.g. using something like Google Gears, right ?
You can't write an application using Google Gears on the iPhone without installing the Google Gears plugin, which you can't do, because you can't install any native code.
You are making the mistake of thinking "3rd party development == C coders."
No, I'm making the mistake of thinking "applications" == "things that run on the phone".
Web applets? I've used them on my Palm and Pocket PC, years before the iPhone was a twinkle in Steve's eye. Every device has these... they *also* run software on the device itself, so you can use them with the battery-eating radio shut down.
One of the most popular classes of applications on the Palm, for example, are input methods. You want something faster than their predictive keyboard? Sorry, you're out of luck. You want an eBook reader that doesn't require you to be online the whole time you're reading? Uh-uh, you don't get that. An aplication I use all the time is a shopping list app... that I couldn't use on the iPhone even if it was available as a web applet because there's a big fat dead area near the back of my neighborhood supermarket.
This doesn't mean that it won't be a popular device. A lot of people seem happy with fancy dumb phones, but claiming that this is in any way comparable to the ability to run real native applications, or that being able to run web applets is some kind of unique feature of the iPhone, is just daft. That's something the competition has been doing for almost a decade now, and unless the people writing the applets are particularly stupid they're almost all going to work on any handheld. Certainly the only ones I've found that are iPhone-only are ones that explicitly check to see if they're running on one.
I hope that Apple is sensible about this.
The whole "no native API" thing on the iPhone is a ludicrous idea in the first place.
The Xbox was designed to sell for less than the cost of manufacture and make up for it with games sales, and the end-users of the Xbox have a reason to WANT it to be locked down - to prevent other users cheating them.
The iPhone has a nice fat 40%+ margin built in, and iPhone users don't (so far as I know) run around shooting each other with bluetooth bullets. Locking down the iPhone makes no more sense than locking down the Treo or Pocket PC.
You haven't had a problem. That's great. Other people have.
Now... I don't think anyone claiming this is a surprise is being completely honest. This is similar to the iPod battery replacement policy, and everyone's known about that for years, and people have been pointing out that the battery isn't field-replaceable pretty much since the iPhone was announced.
But... it's still a big issue.
It's just an issue we've actually known about.
How can Stallman be the reason for free software, when there was a thriving free software community before he even started penning the GNU manifesto? The first free (as in speech) UNIX environment was released by Bell Labs in the '70s, as a set of libraries and a Ratfor compiler under the name "Software Tools". The Software Tools virtual OS eventually became a very comlete hosted UNIX environment for the minicomputers and mainframes of the '70s and early '80s. The first free (as in speech) C compilers were published in the late '70s by Dr Dobbs' Journal, and developed for over a decade - I did a port of one to the 6809 in 1983.
BSD was given a free license due to Stallman and the FSF's efforts.
Um, that doesn't happen to be the case.
The reason that USL backed down on the USL-CSRG lawsuit was to cut a cross-licensing knot: System V was using BSD software in violation of AT&T and USL's contracts with UCB (they didn't provide proper attribution for the components they used), and they decided to cut their losses while they still had something to sell to Novell.
The FSF wasn't in the picture, their attention was all on their own HURD project... in fact the FSF was strongly opposing the BSD license, and it's still opposed to the kind of unencumbered release of software that the BSD license represents. They denigrate their *own* library license (and they renamed it to the "lesser" license later on).
Hell, the FSF's support of Linux was lukewarm at first. RMS seemed pretty ticked off (in print at least) that Linus didn't call his OS "GNU something".
Whether or not the FSF existed, the AT&T-free BSD code base would still have come out, at about the time it did. The AT&T-free release was initiated, carried through, and completed by members and ex-members of the Berkeley Computer Science Research Group, and by negotiations between the Regents of the University of California and AT&T and subsequent owners of the UNIX license.
You can't argue that BSD's example would have influenced Torvalds to have opened up Linux, or that its free license would have had him contribute to BSD instead of his own system
Um, I don't know what you're getting at here. At the time I'm referring to, there was no Linux yet. Linus was still messing about with Minix. Linus has said, in as many words, that if the AT&T-free BSD had been ready a year earlier he would have been using that instead of going on to develop Linux.
Without Linus Torvalds, we would be in a relatively similar boat, running BSD-based systems in place of Linux-based systems.
Er, yes, I already mentioned that too. Without either of them the BSD code base would have ended up in the same place.
It is possible to play SL and never once buy a "sex gen" product, if that's what bothers you. And of course it's also possible to play it without selling pirated copies of someone else's products. Unless you were hoping to do either of these things, what's stopping you?
Ok, just finally realized that OOXML is the MS format and not the Open Office one.
:p
No prize for guessing why they used that name.
OOXML is XML -- if you want to extract plain text from it just feed it through a XML parser and strip all the tags.
Precisely my point. If the layout and non-text information in the file matters, then you've thrown it away. If it doesn't, then why are you bothering to put it in the archive?
You can do something similar with Office's format, but the solution will be far less perfect and contain lots of junk.
Yes, and (as I noted) I've done the same thing, and it's a relatively crude way of reverse-engineering the format.
On a spectrum of "what's a good archive format" OOXML is a bit better than older office formats.
But compared to even something like HTML that's got an open specification that's actually open enough to have multiple independent implementations, and easy enough to implement that you can do it in BASIC for display on a dumb terminal, OOXML is just daft.
Yeh, licenses that limit redistribution, or limit redistribution of modified code, are the kiss off death for projects. One of the things that made UNIX really successful in the academic community early on is that so long as your school had a compatible source license you could get other people's distributions and work with them. That's probably why the BSD license is so liberal.
But this isn't something that's really all that different now. There's still packages that have licenses like that, like qmail. They're a huge roadblock to wide acceptance. Of course both the Minix and Qmail authors also have authors who have very strong opinions on technical subjects that are more important than the broadest distribution to them. But there have been open source projects inspired by UNIX that *don't* have those kinds of restrictions all the way back to the '70s. If we had good cheap 32-bit personal computers with MMUs in 1980, then we'd probably be using a descendent of MINT or OMU or the Software Tools VOS...
OK, the deal is this. Let's say you have a bunch of files in some old format, and a spec for that format, and you need some information out of those files. That spec ill be useful to you if - and only if - the cost of implementing that format from the spec is less than the cost of losing those files, AND it's less than the cost of reverse-engineering enough of the format to extract the information you want from the files.
The OOXML spec is huge (expensive to implement from the spec) and complex, and the meaning of many components can't really be determined without looking at the way Office behaves (so it's incomplete, this implementing a reader for it will require a fair amount of trial and error). Reverse-engineering Office's format may be much easier, depending on what information you're looking for... just extracting the text strings from a Word document has often been MY preferred method of reverse-engineering it...
Which means that OOXML is a poor archival format... unless you want to lock people who want to use the archives in the meantime into using Microsoft Office to read them.
Without Richard Stallman we would still have Linux. Without Linus Torvalds, we wouldn't.
Without Richard Stallman Linus would have had to use another compiler, of which there were at least three available at the time. Without Richard Stallman he would have used a different license, but that wouldn't have kept people from joining up to work on Linux... using a different license didn't keep people from working on BSD, and it didn't even keep people from working on Minix... which wasn't freely redistributable by any means.
Heck, without William Jolitz we might not have had Linux. Jolitz redirected a lot of the interest in BSD Net/2 and BSD Lite into 386BSD for a couple of years, and never went anywhere with it. Linus has written that if the fully open-source BSD had been ready even a year sooner, he would have worked on it and there wouldn't be a Linux. But there might have been a better BSD... because a lot of the reason Linux was developed so effectively early on is that Linus is a genuinely nice guy, as well as a good project leader *and* technically competent.
But either way, there were multiple projects and source trees developed duing the '80s that would have produced the same kind of open source environment we have now, with or without Richard Stallman. The details might have been different without him... it's hard to say... but the idea that he was *necessary* for any of this? No.
You're off on the wrong foot right from the start in that article. You write "It's the right of HE who own the material to put in whatever form they want." which is true, but it's got nothing to do with copyright, or DRM, or anything else.
Copyright is fundamentally very simple. It's the right to make a copy.
In practice that's pretty complex, because... what's a copy? If you decide to get really technical, when you read a book or listen to a song, you're making a copy of it. It's low fidelity, unless you've got an unlikely good memory, but by your logic an artist should have the right to sue you if you hum the time or recite the story in public. Oh, I'm sure that you wouldn't go that far... but it's where the logic leads.
Copyright law is complex because copyright law is mostly about defining EXACTLY what a copy is. And when a copy is subject to copyright. There's been licenses on software that are based on the theory that you're making a copy of the software when you install it on your computer, but there's nothing about copyright restrictions preventing you from making a temporary copy of the images in a video when you play it on your TV. Unless you do it in a public place... then it's a performance. And you're allowed to make a personal copy of a movie off your TV if it was broadcast, which is a kind of public performance though your playing it isn't, or even if it's on a DVD... but not if you're playing it from a rented DVD, whether it's a public performance or not, and not if you're seeing it in a movie, which is another kind of public performance.
So, first off, while an artist has a right to use whatever format they want, that doesn't mean you don't have the right to make a recording in another format... for your own use. Apple got attacked for their "RIP, MIX, BURN" advertising campaign... but it turns out that in the US it's legal to "RIP, MIX, BURN". And it's legal to do that even if the music was DRMed to begin with.
So that's the second thing. The main reason for DRM is to try and create new rights. The DMCA is a really useful tool, because it makes it illegal to use "technical means" to bypass DRM. So while the law doesn't say that an artist has the right to prevent you from making a personal copy of an HD DVD, they're *creating* that right by gluing together bits of the law. This kind of thing happens all the time, the law says one thing, someone comes up with a way to make it mean something else, and sometimes the law gets changed to say that the other thing is really in there, or it gets changed to say the other thing was an unintended side effect and it's really OK to eat peanuts on church after all.
This kind of thing also ends up making the definition of a "copy" trickier.
And people aren't stupid. They look at the way things work, and they look at DRM, and they go "you know, you're treating your fans like shit". So they either treat the artists like shit in return, or they decide they don't like the music enough to put up with being treated like shit. So there's actually competition, and market forces, and all that America and Apple Pie stuff, and what it does it makes DRM into something that provides an advantage for the artists who don't use it. Particularly the ones who aren't selling that well, yet... so they put stuff out that's not restricted, and people discover it, and they go "hey, this is good stuff", and they go "hey, this guy is cool", and they buy his stuff. And there's guys who've made it this way.
And these artists aren't signing with EMI. So EMI's not getting their cut, so this gives EMI a reason to go DRM-free... maybe they can sign a few of the hot new internet artists who'd otherwise be going through CDbaby and eMusic and getting earplay through last.fm. Because, you know, the Internet isn't going away.
I hate the "Napster clones". I think Napster should have been slapped down HARD, right off, because their whole business model was deliberately about setting up cutouts so they could get a cut of copyright violati
Come on, not only was it the grand-daddy, great-grand-daddy, and multi-dimensional n-parent of everything from lunar lander to flight simulators, but it was the most popular videogame in the world for over a decade!
First smartarse who points out that it was the ONLY videogame in the world will just be proving my point.
(I've played OXO. OXO isn't even in the running)
According to Apple, Leopard will allow you to use existing 32-bit drivers and 64-bit applications in the same system with the same OS version:
Driver compatibility.
Because of its universal nature, with Leopard you don't need a new set of drivers -- or devices. New 64-bit applications work just fine with your existing printers, storage devices, and PCI cards. Even better, if you upgrade to new 64-bit-capable drivers, your 32-bit applications will also benefit from the increased throughput.
Microsoft's making the problem worse in Vista, because they changed a lot of the driver APIs in Vista to support its enhanced DRM. Even if they supported 32-bit drivers in Vista existing 32-bit drivers wouldn't be DRM-friendly: even many 64-bit drivers from previous versions of Windows don't work.