The Habeus approach is interesting, but since they've patented it, they could easily make it the only game in town. In particular, I concerned that they might be able to tax any email sent/received!
I'd prefer to see methods where there is no centralized authority.
Decentralization removes the danger of a single point of failure (and the taxes that often come from one).
It's certainly true that inappropriate tools sometimes contribute to security problems. But the more serious issue is that too many programmers don't know how to write secure code.
It's certainly true that avoiding C/C++ eliminates some buffer overflow attacks, but note that there are things to watch out for in every language.
I agree that there's an overuse of C/C++ in cases where they don't make sense, but switching to
another language while failing to get the programmers trained won't solve the problem.
There's a free book (and slides) already available
if you want to learn how to write secure programs
for Linux and Unix, it's the
Secure Programming for Linux and Unix HOWTO.
Take it, read it, use it.
It's already included in many Linux distribution's documentation.
It is a good idea to get colleges to teach about writing secure programs. Currently, almost all programmers get out to the real world without knowing how to write secure programs, and they're writing the programs exposed to the entire Internet. That needs to change.
I would define engineering as the application
of scientific knowledge to the solution of
practical problems. In the field,
"software engineering" implies knowledge of not
just algorithms, but also of knowledge of
how to organize people and processes so that
they can solve large-scale problems.
Dictionaries generally lag the use of the
language, so it's not surprising that some
dictionaries presume that science only includes
the physical sciences.
In short, there is a software engineering
field, because there's a field that applies
scientific knowledge to solve practical
problems.
Yes, the science is immature.
A great deal of the current information
consists of rules-of-thumb based on statistical
analysis of past projects.
(e.g., cost and schedule models).
But that's how many other engineering
disciplines started too.
Computer scientists are necessary to
identify the basics, just as physicists
and chemists are needed to identify fundamental
scientific properties needed to build a bridge.
But physicists and chemists shouldn't be
designing or building bridges, unless they are
also engineers.
You need people who can bridge the gap between
the science and the problem to produce an answer.
It just makes sense that, if you're a government organization acquiring software, you should consider your open source software options. One problem with some government organizations is that they write request for proposals (RFPs), send them out, and presume that the only solutions available are those from the respondants. Since open source software / Free Software (OSS/FS) projects generally don't reply to RFPs, they're likely to be missed, even if they're perfect for the job. Hopefully, this law will at least make some people go to the web and examine their OSS/FS options.
If you're interested in writing
secure programs (instead of installing /
configuring existing programs to be secure),
take a look at my freely-available book:
Secure Programming for Linux and Unix HOWTO.
KDE advocate advocates KDE! Yawn. Freedesktop.org.
on
Has GNOME Become LAME?
·
· Score: 1
Wow, a KDE advocate advocates KDE!
That must be exciting!! Well, not really.
I prefer GNOME; its licensing scheme,
basic goals, and many of its technical decisions
have been overall quite good.
The "few preferences" approach is grossly
misunderstood. It's not that they're trying to
eliminate the ability to set preferences... it's
that they're trying to make sure that software
"does the right thing" without needing to
set preferences.
The canonical example is the option that you
need to set in order for the software function
to work (e.g., emacs cut and paste).
There's no need for an option to make the
software work: it should work correctly ALL THE
TIME.
Is GNOME perfect? No. Nor is KDE.
Others prefer KDE.
Fine, enjoy KDE.
Really, what needs to happen is standard
setting so that applications work correctly
no matter what environment the user chooses, and
no matter what toolkit the developer chooses.
Please
support Freedesktop.org, who really
represent the way forward.
Google isn't "evil" for choosing to use a legal mechanism open to it.
But it's still clear
that software patents are far more
harmful than helpful, and this patent is
yet another demonstration of the problem.
The only reason to allow patents in the US is,
as the US Constitution states,
"to promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."
Does anyone seriously think that Google would
not have developed this approach
if it couldn't patent it?
I certainly don't.
Google is constantly trying to tweak its
approach, and doesn't need any patents to do so.
So, the government is supporting yet another
monopoly over an idea, without receiving
really anything useful in return.
Making the patent application public isn't
useful, for example; the 20-year term is
essentially eternity in the software business,
so it's unreasonable to believe that supporting
this monopoly will improve innovation overall.
The primary innovation will be other people
working around the patent, instead of working
to improve on the idea.
Thus, patents for software continuing to fail
to promote innovation in software.
Innovation in software happened for decades
without software.
Professors Bessen and Maskin, two economists at the Massachusetts Institute of Technology (MIT), have demonstrated that introducing patenting into the software economy only has economic usefulness if a monopoly is the most useful form of software production. This is concerning, because few believe that a monopoly is truly the most useful (or desirable) form of software production. Bessen and Maskin also demonstrated a statistical correlation between the spread of patentability in the United States and a decline in innovation in software. In particular, between 1987 and 1994 , software patents issuance rose 195%, yet real company funded R&Ds fell by 21% in these industries while rising by 25% in industries in general.
Go read their report.
Other information is available at places such as
the
wikipedia entry on software patents.
You said that "We have tried very hard to get a true CC Linux for our contracts but the "Secure" OS needs the following: A page of memory when freed must be cleared. This includes Virtual memory saved to disk or even laying around in memory." But that's not true in general, and indeed, even those who require clearing generally only require it before or when it's allocated - which is what GNU/Linux provides.
First, a few clarifications about the CC itself. The CC lets users pick the requirements that they want, and vendors to state the requirements they happen to meet. The CC by itself doesn't require you to have this particular requirement. Instead, what's happening is that the CC defines a standard set of security requirements, and users are supposed to then identify the requirements they believe they need (using something called a "Protection Profile" (PP)). Then vendors can show whether or not they meet them. Now, it may be true that your customers are imposing this requirement for their needs, but that's different than claiming anything general about the CC.
More specifically, I suspect you're talking about the CC requirements in FDP_RIP (Residual Information Protection). But the CC is like a Chinese Menu; whether or not users want it is determined by users, and whether or not a vendor provides it (and someone is willing to pay to evaluate the function) is another.
And in the CC, even if you select FDP_RIP as a requirement, there's a choice about WHEN you erase information (it may be set by the user, or stated by the vendor).
For example, the
Controlled Access Protection Profile (CAPP) corresponds more-or-less to the old "Orange Book" C2 level. There are other PPs that apply
to operating systems, too.
But the CAPP was used to evaluate other
operating systems, so it's fair to use it
as an example.
The CAPP does select the
CC function FDP_RIP.2, "Object Residual Information Protection" requirement, so
users who are requiring CAPP will require it.
But its text simply says that "The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all objects."
There's a clarifying note in the CAPP that "Clearing the information content of resources on deallocation from objects is sufficient to satisfy this requirement, if unallocated resources will not accumulate new information until they are allocated again."
It also includes a similar "Subject Residual Information Protection" requirement, stating that "The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all subjects."
See CAPP sections 5.2.3 and 5.2.4.
(Oh, a few quick definitions first for those who don't know.
Oversimplifying things, think of "subject" as Linux thread/process, and "object" as data such as filesystem objects, network packets, or memory.
A "TOE" is the Target of Evaluation (think "this particular version of GNU/Linux configured a particular way"), and a "TSF" is the TOE security functions (it's the subset of the system responsible for security, including the Linux kernel, processes that run as root, and setuid root programs).
Go look at the CC for more official definitions; I'm just trying to give the jist.)
In the CC, users can determine if they want to require clearing data when it's deallocated, or when it's allocated. It appears that the CAPP (and probably many other PPs) only require it by the time it's allocated (the clarifying text hopefully makes it clear that you can clear it earlier, as long as you don't seep data back into it later).
Thus, even if you mean CC requirements like FDP_RIP.2, it appears that GNU/Linux may meet it as long as the PP specifies that it's just when it's allocated - a common user choice.
There's no requirement in the CAPP that the erasure happen when the object/subject is freed - merely that the erasure happen some time before it's reused.
Alan Cox's response actually sounds like evidence that GNU/Linux might meet this requirement!
Pages are cleared before being handed to another process - that handles one issue.
Disk blocks are retrieved as empty disk blocks.
And, for crashing, there's a slower mode that would probably be required for use in a secured situation - but that's okay, you just specify that for this kind of use, you have to turn on that configuration option.
There is a known bug in older Linux kernels - many network drivers don't clear out their data, so you can get some information leakage via network packets.
That's already been patched (I forget when).
It's worth noting that many other operating systems over the years have had that problem too, it's a standard thing to look for in an evaluation.
Of course, intentions are great, but the real test is if it really happens. An evaluation would look over the evidence to determine if it's reasonable to believe that all residual information really is getting cleared. How much effort would be expended to do this examination depends on the EAL level.
I take this as an encouraging step,
especially since they note that the final
goal is to certify both Oracle and the
underlying GNU/Linux system at EAL 4.
This sort of thing makes it much easier to
deploy GNU/Linux widely in governments;
it will be much easier for governments to
base operating system acquisition decisions based
on factors like functionality, cost, flexibility,
and lock-in.
The article is very short on details, though.
Starting small (EAL 2) is probably a good idea -
especially since I know of no
open source software / Free Software that's
gone through a full, normal
Common Criteria evaluation
(so it would be a first test case).
EAL 4 only measures the evaluation effort - it
doesn't specify what security functions will
be evaluated (nor what threats, assumptions,
organizational security policies,
configuration, etc. will be used).
Hopefully Oracle and Red Hat will include
security functions based on a widely-accepted
"Protection Profile" (a document that specifies
what the users want, including the threats to
be countered and the security functions that
need to be provided). Currently, the U.S. DoD
strongly encourages only purchasing products that
have been evaluated to meet not just an EAL level,
but meet a "government-approved" PP.
Evaluations are specific to a particular
configuration, so this would mean that those
who need the evaluated version would need to
get the Red Hat distribution named here -
not the inexpensive version used by many.
That's a side-effect worth noting.
Unfortunately, the "picking up your marbles" article uses nonstandard terminology and thus may end up confusing many readers. For example, it seems to equate "Free Software" with copylefting licenses (like the GPL), and "Open Source" with non-copylefting licenses (like the BSD license). That's extremely confusing; the standard definitions for both Open Source and Free Software include both the GPL and the BSD licenses. Also, "Shared Source" is still proprietary; trying to claim it isn't just confuses things. Proprietary software comes in at least two varieties: secret source, and "shared source".
Licenses are confusing enough without using nonstandard, inconsistent terminology.
Hopefully, the article will get updated - it makes interesting points, and the shifting terminology is unfortunate.
For the moment, I would recommend Bero's article instead if you're looking for an article opposing "shared source".
At one time, I recall that there were some serious
patent issues with SVG. Basically, SVG wasn't really an open standard, because it was patent royalty encumbered - giving an automatic disadvantage to those who weren't patent holders, making it impossible to implement using open source software / free software, and
discouraging implementation in any place where expenses have to be kept down (including some small businesses and mass market devices).
If this is true, that's a real victory for the new W3C policy (and for the world in general).
Thanks to all.
Please let me know if I'm misinterpreting something.
If the sender is on the whitelist, accept the email.
(Spammers can forge their addresses, but they then have to figure out
who to forge as... and anti-fraud measures make this dangerous).
If the subject line includes a "password" set by the receiver,
accept the message.
Otherwise, reply back to the sender a message that's configurable by
the receiver-to-be, saying that they need to include the password in
the subject line & here's how to figure it out. Spammers won't get the
message, or won't read the responses. Real users will include the password.
Include various measures to prevent email loops: detect null senders,
vacation messages, and remember who you sent replies to (and after a few
tries, start dropping them).
This has already been suggested as a Mozilla mail enchancement, as
Mozilla bug 187044. If you like the idea,
by all means vote for it at Mozilla and/or encourage other email programs to add it.
The danger with filters is that even if they're based on good statistics or heuristics, they're just that - statistics and hueristics - and they can sometimes mistakenly throw away valuable
email. A password email system, however, is deterministic - in particular,
it always lets in email from those you trust and
those able to respond to your challenge.
I think challenge-response email passwords, combined with filters (which wouldn't have to be as selective), could go a long way to controlling
spam.
Perhaps new phones could listen for a local
signal that said "no noise"? Then, phones that
could vibrate could do so. People who REALLY
need to take the call can do so. And text
messages would quietly get through.
I also like the idea of charging a fee to get
through. Combine the two ideas, and you'll
get a situation where if people call, and they
pay the fee, the person who needs to get the call
gets the call.. but doesn't unduly
disturb his neighbor. Instead, he can quietly
get out of the theater or whatever.
It's fair to ask "why bother", but I think this is
a smart move by this group.
Making it easy to run open source software /
Free Software (OSS/FS) on Microsoft Windows makes it
much easier for people to transition to
OSS/FS systems over time, if they choose to do
so... and thus more likely that the use of
OSS/FS systems (like GNU/Linux) will increase.
People do not buy operating systems, generally. People buy applications, and then buy whatever operating system is needed to run the application.
In particular,
most people don't care if Windows or GNU/Linux is "better". The primary thing most people want to know is which one runs the applications they need. For example, they want to know what runs Word, or at least, which one can read and edit Word files easily.
And once they start using a set of applications, they don't want to immediately switch to a different set of applications - especially
since some may be home-built and require
some time to re-develop.
People are willing to make slow transitions, but massive all-at-once transitions are risky and painful.
Thus, if you want users already using a proprietary operating system to switch to GNU/Linux, you're better off first getting them to use OSS/FS applications on whatever operating system they're currently using.
A user who uses Windows with Internet Explorer, Outlook, and Microsoft Word will usually not be willing to instantaneously switch to the Linux kernel, Mozilla, and Open Office; the time
to do the transition is quite painful.
But a Windows user is probably willing to try out Mozilla - the pain is quite low. Installing Open Office is not risky.. and look at the money they save (if they aren't pirating, which is becoming more dangerous due to the BSA etc.).
This has already happened, for example, with the compiler suite gcc. For many years gcc only ran on proprietary operating systems.
But because it was freely available for those proprietary systems, and was a good product, people increasingly used gcc.
Increasingly, code was written that required the gcc compiler, or at least was only known to work with it.
Once an OSS/FS kernel became available, developers were more willing to switch to it... because their application (gcc) was already running on it.
Imagine that more and more users begin to install Open Office because it cost less than the proprietary alternatives (Word Perfect, Microsoft Office). Now imagine that they send their documents to other people.
Those other people will be incentivized to also use Open Office, in part because it's the
safest approach (no concerns of subtle incompatibilities) and it's easy
(there's no harm in loading both Open Office and Microsoft Office on the same system).
Then, due to network effects, more &
more people do this;
I suspect this effect would be especially strong in less developed countries, where there is
just no money for proprietary products,
Microsoft's products are less firmly established
(in some cases),
Microsoft is viewed with suspicion, and where
recent trade agreements (e.g., efforts to
join the WTO) makes it slightly more
dangerous to pirate.
Now imagine a place where most people using
Microsoft Windows also use Open Office, and
many use Mozilla, at least some times.
They may not have considered using GNU/Linux
before, but suddenly you've greatly eased
transition.
And each step made sense to the user:
they added Open Office due to price or due to
compatibility with other users, and then
could switch to GNU/Linux for the same reason.
Indeed, this group should encourage
the Business Software Alliance (BSA)'s
enforcement actions,
especially in other countries.
The BSA's tactics are often reprehensible,
in particular the BSA's presumption that
organizations are guilty until proven innocent
(even though, in many cases, the problem is
simply that some licensing paperwork has been
lost).
But that can work to the advantage of anyone
recommending that OSS/FS be considered.
Imagine an organization presented with
these options: (1) use the
current application software, whose rental
agreements are getting costlier and which they'll
have to carefully track (or be subject to
stiff fines), (2) new application software
that is a "work-alike" and doesn't require them
to throw away their operating systems
(as well as all the specialized programs
built on that operating system), or
(3) replacing all operating systems and
all applications all at once.
Option 3 is completely impractical, but option 1
is getting expensive enough to make option 2
worth considering.
I expect the name of this CD will have to change, or they'll have to remove a few of the products. The FSF certainly permits its programs to run on proprietary operating systems - indeed, for many years they ran only on proprietary systems - I'm sure they won't want the name "GNU" (the key FSF project) associated with some programs that don't meet the "Free Software" definition. According to the web site, some applications don't permit redistribution of modified programs, and that fundamentally contradicts the FSF definition of "Free Software". But this won't be hard to fix, really - just remove a few programs (none of the most critical ones) or change the name.
Whining would be worthless. Polite letters asking Apple to please support Ogg Vorbis across their product line (especially product A, B, and C) would probably be read. If you currently use their product (and would pay for an upgrade that supported Ogg Vorbis), or have decided to NOT buy one of their products because it doesn't support Ogg Vorbis, say so - that will be more likely to get their attention.
I've already let Apple know. If you want Apple to support Ogg Vorbis, you should too.
I think you're looking too short-range.
Look at what happened with gcc. Once gcc became a powerful C compiler, available on non-free platforms, it became extremely widespread, and eventually a massive amount of code became dependent on _gcc_ instead of a proprietary alternative. Then, once the Free operating systems became more mature, people MUCH more easily ported to them.
The same can occur here, too. It's very difficult to get Word users to switch to Linux! But if the majority of word processor users (for example) used Open Office (or Abiword or KWord), then they'd find it essentially trivial to switch.
People don't buy operating systems. They buy applications, and then get the operating system to run it. If you want people to use your operating system, you need to get them to use the applications that run on your operating system.
If you're interested writing secure applications for Linux/Unix systems, take a look at my free book,
Secure Programming for Linux and Unix HOWTO,
available at
http://www.dwheeler.com/secure-programs.
Ah! That's great news! I retract what I said.
It's not clear to me that this can handle most real Flash files, but I suspect the developers are already handling that.
There is a Japanese study, simply called the
Linux white paper 2003, that studies current use of Linux in Japan. If you don't read Japanese, a summary of
the material is available in
Why OSS/FS? Look at the Numbers! in the market share section. Look for the point that starts with "A Japanese survey found widespread use and support for GNU/Linux;
overall use of GNU/Linux jumped from 35.5% in 2001 to 64.3% in 2002 of
Japanese corporations, and GNU/Linux was the most popular platform for
small projects." Note that this is the percentage of corporations using it at all, not the number of total machines, but it certainly suggests interest by the Japanese corporate world. Various other statistics are quoted as well.
I agree with the Slate article that spam is killing email. However, the article claims that laws and legislation aren't working, and this is nonsense. The problem isn't that the laws aren't working... it's that laws have not yet been seriously tried. In a few states, the partial anti-spam laws are actually having an effect. But until the majority of countries make spam illegal with fines (including as a U.S. federal law and an EU law), spam will continue to make email difficult to use.
If it was clearly illegal to send unsolited bulk email (spam) to anyone in the U.S. or Europe, and a hefty fine backed that up, it would force spammers to move to smaller countries. Those countries would then quickly get blacklisted: "Fix your laws, or you can't do business with us." There will still be spam, but it will be much, much rarer because it would be more dangerous. You could also fine companies that pay for spam - a few hefty payments would at least eliminate a lot of commercial spam.
A partial alternative would be to require (by law) automatable marking (say "ADV:" as the first characters in the subject line) and forbidding source forging. Again, could spammers disobey the law? Sure, murder still happens too. But by making it legally a crime, with real penalties, we certainly reduce the number of perpetrators.
There's actually quite a bit of Linux use in Japan.
A Japanese paper called the
Linux white paper 2003 found that
overall use of GNU/Linux jumped from 35.5% in 2001 to 64.3% in 2002 by
Japanese corporations, and GNU/Linux was the most popular platform for
small projects.
It also found that 49.3% of IT solution vendors support Linux in Japan, as well as a number of other interesting statistics.
Slashdot Mirror
If you don't like spam, take a look at my guarded email protocol: http://www.dwheeler.com/guarded-email.
The Habeus approach is interesting, but since they've patented it, they could easily make it the only game in town. In particular, I concerned that they might be able to tax any email sent/received! I'd prefer to see methods where there is no centralized authority. Decentralization removes the danger of a single point of failure (and the taxes that often come from one).
This problem is so serious that I give away a book explaining how to write secure programs in Linux and Unix. See my Secure Programming for Linux and Unix HOWTO.
It's certainly true that avoiding C/C++ eliminates some buffer overflow attacks, but note that there are things to watch out for in every language. I agree that there's an overuse of C/C++ in cases where they don't make sense, but switching to another language while failing to get the programmers trained won't solve the problem.
It is a good idea to get colleges to teach about writing secure programs. Currently, almost all programmers get out to the real world without knowing how to write secure programs, and they're writing the programs exposed to the entire Internet. That needs to change.
In short, there is a software engineering field, because there's a field that applies scientific knowledge to solve practical problems. Yes, the science is immature. A great deal of the current information consists of rules-of-thumb based on statistical analysis of past projects. (e.g., cost and schedule models). But that's how many other engineering disciplines started too.
Computer scientists are necessary to identify the basics, just as physicists and chemists are needed to identify fundamental scientific properties needed to build a bridge. But physicists and chemists shouldn't be designing or building bridges, unless they are also engineers. You need people who can bridge the gap between the science and the problem to produce an answer.
For quantitative evidence showing that any software acquisition should consider their OSS/FS alternatives, see my paper Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!.
If you're interested in writing secure programs (instead of installing / configuring existing programs to be secure), take a look at my freely-available book: Secure Programming for Linux and Unix HOWTO.
If you're writing programs that are supposed to be secure, take a peek at my freely-available book: Secure Programming for Linux and Unix HOWTO.
I prefer GNOME; its licensing scheme, basic goals, and many of its technical decisions have been overall quite good. The "few preferences" approach is grossly misunderstood. It's not that they're trying to eliminate the ability to set preferences... it's that they're trying to make sure that software "does the right thing" without needing to set preferences. The canonical example is the option that you need to set in order for the software function to work (e.g., emacs cut and paste). There's no need for an option to make the software work: it should work correctly ALL THE TIME. Is GNOME perfect? No. Nor is KDE.
Others prefer KDE. Fine, enjoy KDE.
Really, what needs to happen is standard setting so that applications work correctly no matter what environment the user chooses, and no matter what toolkit the developer chooses. Please support Freedesktop.org, who really represent the way forward.
The only reason to allow patents in the US is, as the US Constitution states, "to promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."
Does anyone seriously think that Google would not have developed this approach if it couldn't patent it? I certainly don't. Google is constantly trying to tweak its approach, and doesn't need any patents to do so. So, the government is supporting yet another monopoly over an idea, without receiving really anything useful in return. Making the patent application public isn't useful, for example; the 20-year term is essentially eternity in the software business, so it's unreasonable to believe that supporting this monopoly will improve innovation overall. The primary innovation will be other people working around the patent, instead of working to improve on the idea.
Thus, patents for software continuing to fail to promote innovation in software. Innovation in software happened for decades without software.
Professors Bessen and Maskin, two economists at the Massachusetts Institute of Technology (MIT), have demonstrated that introducing patenting into the software economy only has economic usefulness if a monopoly is the most useful form of software production. This is concerning, because few believe that a monopoly is truly the most useful (or desirable) form of software production. Bessen and Maskin also demonstrated a statistical correlation between the spread of patentability in the United States and a decline in innovation in software. In particular, between 1987 and 1994 , software patents issuance rose 195%, yet real company funded R&Ds fell by 21% in these industries while rising by 25% in industries in general. Go read their report. Other information is available at places such as the wikipedia entry on software patents.
First, a few clarifications about the CC itself. The CC lets users pick the requirements that they want, and vendors to state the requirements they happen to meet. The CC by itself doesn't require you to have this particular requirement. Instead, what's happening is that the CC defines a standard set of security requirements, and users are supposed to then identify the requirements they believe they need (using something called a "Protection Profile" (PP)). Then vendors can show whether or not they meet them. Now, it may be true that your customers are imposing this requirement for their needs, but that's different than claiming anything general about the CC.
More specifically, I suspect you're talking about the CC requirements in FDP_RIP (Residual Information Protection). But the CC is like a Chinese Menu; whether or not users want it is determined by users, and whether or not a vendor provides it (and someone is willing to pay to evaluate the function) is another. And in the CC, even if you select FDP_RIP as a requirement, there's a choice about WHEN you erase information (it may be set by the user, or stated by the vendor).
For example, the Controlled Access Protection Profile (CAPP) corresponds more-or-less to the old "Orange Book" C2 level. There are other PPs that apply to operating systems, too. But the CAPP was used to evaluate other operating systems, so it's fair to use it as an example. The CAPP does select the CC function FDP_RIP.2, "Object Residual Information Protection" requirement, so users who are requiring CAPP will require it. But its text simply says that "The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all objects." There's a clarifying note in the CAPP that "Clearing the information content of resources on deallocation from objects is sufficient to satisfy this requirement, if unallocated resources will not accumulate new information until they are allocated again." It also includes a similar "Subject Residual Information Protection" requirement, stating that "The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all subjects." See CAPP sections 5.2.3 and 5.2.4.
(Oh, a few quick definitions first for those who don't know. Oversimplifying things, think of "subject" as Linux thread/process, and "object" as data such as filesystem objects, network packets, or memory. A "TOE" is the Target of Evaluation (think "this particular version of GNU/Linux configured a particular way"), and a "TSF" is the TOE security functions (it's the subset of the system responsible for security, including the Linux kernel, processes that run as root, and setuid root programs). Go look at the CC for more official definitions; I'm just trying to give the jist.)
In the CC, users can determine if they want to require clearing data when it's deallocated, or when it's allocated. It appears that the CAPP (and probably many other PPs) only require it by the time it's allocated (the clarifying text hopefully makes it clear that you can clear it earlier, as long as you don't seep data back into it later).
Thus, even if you mean CC requirements like FDP_RIP.2, it appears that GNU/Linux may meet it as long as the PP specifies that it's just when it's allocated - a common user choice. There's no requirement in the CAPP that the erasure happen when the object/subject is freed - merely that the erasure happen some time before it's reused.
Alan Cox's response actually sounds like evidence that GNU/Linux might meet this requirement! Pages are cleared before being handed to another process - that handles one issue. Disk blocks are retrieved as empty disk blocks. And, for crashing, there's a slower mode that would probably be required for use in a secured situation - but that's okay, you just specify that for this kind of use, you have to turn on that configuration option.
There is a known bug in older Linux kernels - many network drivers don't clear out their data, so you can get some information leakage via network packets. That's already been patched (I forget when). It's worth noting that many other operating systems over the years have had that problem too, it's a standard thing to look for in an evaluation.
Of course, intentions are great, but the real test is if it really happens. An evaluation would look over the evidence to determine if it's reasonable to believe that all residual information really is getting cleared. How much effort would be expended to do this examination depends on the EAL level.
The article is very short on details, though. Starting small (EAL 2) is probably a good idea - especially since I know of no open source software / Free Software that's gone through a full, normal Common Criteria evaluation (so it would be a first test case). EAL 4 only measures the evaluation effort - it doesn't specify what security functions will be evaluated (nor what threats, assumptions, organizational security policies, configuration, etc. will be used). Hopefully Oracle and Red Hat will include security functions based on a widely-accepted "Protection Profile" (a document that specifies what the users want, including the threats to be countered and the security functions that need to be provided). Currently, the U.S. DoD strongly encourages only purchasing products that have been evaluated to meet not just an EAL level, but meet a "government-approved" PP.
Evaluations are specific to a particular configuration, so this would mean that those who need the evaluated version would need to get the Red Hat distribution named here - not the inexpensive version used by many. That's a side-effect worth noting.
Unfortunately, the "picking up your marbles" article uses nonstandard terminology and thus may end up confusing many readers. For example, it seems to equate "Free Software" with copylefting licenses (like the GPL), and "Open Source" with non-copylefting licenses (like the BSD license). That's extremely confusing; the standard definitions for both Open Source and Free Software include both the GPL and the BSD licenses. Also, "Shared Source" is still proprietary; trying to claim it isn't just confuses things. Proprietary software comes in at least two varieties: secret source, and "shared source". Licenses are confusing enough without using nonstandard, inconsistent terminology. Hopefully, the article will get updated - it makes interesting points, and the shifting terminology is unfortunate. For the moment, I would recommend Bero's article instead if you're looking for an article opposing "shared source".
According to http://www.w3.org/2001/07/SVG10-IPR-statements.htm l
and
http://www.w3.org/Graphics/SVG/Disclosures,
this appears to have been resolved to permit
royalty-free use.
If this is true, that's a real victory for the new W3C policy (and for the world in general). Thanks to all. Please let me know if I'm misinterpreting something.
Here's how challenge-response works:
This has already been suggested as a Mozilla mail enchancement, as Mozilla bug 187044. If you like the idea, by all means vote for it at Mozilla and/or encourage other email programs to add it.
The danger with filters is that even if they're based on good statistics or heuristics, they're just that - statistics and hueristics - and they can sometimes mistakenly throw away valuable email. A password email system, however, is deterministic - in particular, it always lets in email from those you trust and those able to respond to your challenge. I think challenge-response email passwords, combined with filters (which wouldn't have to be as selective), could go a long way to controlling spam.
Perhaps new phones could listen for a local signal that said "no noise"? Then, phones that could vibrate could do so. People who REALLY need to take the call can do so. And text messages would quietly get through. I also like the idea of charging a fee to get through. Combine the two ideas, and you'll get a situation where if people call, and they pay the fee, the person who needs to get the call gets the call.. but doesn't unduly disturb his neighbor. Instead, he can quietly get out of the theater or whatever.
People do not buy operating systems, generally. People buy applications, and then buy whatever operating system is needed to run the application. In particular, most people don't care if Windows or GNU/Linux is "better". The primary thing most people want to know is which one runs the applications they need. For example, they want to know what runs Word, or at least, which one can read and edit Word files easily. And once they start using a set of applications, they don't want to immediately switch to a different set of applications - especially since some may be home-built and require some time to re-develop. People are willing to make slow transitions, but massive all-at-once transitions are risky and painful.
Thus, if you want users already using a proprietary operating system to switch to GNU/Linux, you're better off first getting them to use OSS/FS applications on whatever operating system they're currently using. A user who uses Windows with Internet Explorer, Outlook, and Microsoft Word will usually not be willing to instantaneously switch to the Linux kernel, Mozilla, and Open Office; the time to do the transition is quite painful. But a Windows user is probably willing to try out Mozilla - the pain is quite low. Installing Open Office is not risky.. and look at the money they save (if they aren't pirating, which is becoming more dangerous due to the BSA etc.).
This has already happened, for example, with the compiler suite gcc. For many years gcc only ran on proprietary operating systems. But because it was freely available for those proprietary systems, and was a good product, people increasingly used gcc. Increasingly, code was written that required the gcc compiler, or at least was only known to work with it. Once an OSS/FS kernel became available, developers were more willing to switch to it... because their application (gcc) was already running on it.
Imagine that more and more users begin to install Open Office because it cost less than the proprietary alternatives (Word Perfect, Microsoft Office). Now imagine that they send their documents to other people. Those other people will be incentivized to also use Open Office, in part because it's the safest approach (no concerns of subtle incompatibilities) and it's easy (there's no harm in loading both Open Office and Microsoft Office on the same system). Then, due to network effects, more & more people do this; I suspect this effect would be especially strong in less developed countries, where there is just no money for proprietary products, Microsoft's products are less firmly established (in some cases), Microsoft is viewed with suspicion, and where recent trade agreements (e.g., efforts to join the WTO) makes it slightly more dangerous to pirate. Now imagine a place where most people using Microsoft Windows also use Open Office, and many use Mozilla, at least some times. They may not have considered using GNU/Linux before, but suddenly you've greatly eased transition. And each step made sense to the user: they added Open Office due to price or due to compatibility with other users, and then could switch to GNU/Linux for the same reason.
Indeed, this group should encourage the Business Software Alliance (BSA)'s enforcement actions, especially in other countries. The BSA's tactics are often reprehensible, in particular the BSA's presumption that organizations are guilty until proven innocent (even though, in many cases, the problem is simply that some licensing paperwork has been lost). But that can work to the advantage of anyone recommending that OSS/FS be considered. Imagine an organization presented with these options: (1) use the current application software, whose rental agreements are getting costlier and which they'll have to carefully track (or be subject to stiff fines), (2) new application software that is a "work-alike" and doesn't require them to throw away their operating systems (as well as all the specialized programs built on that operating system), or (3) replacing all operating systems and all applications all at once. Option 3 is completely impractical, but option 1 is getting expensive enough to make option 2 worth considering.
I expect the name of this CD will have to change, or they'll have to remove a few of the products. The FSF certainly permits its programs to run on proprietary operating systems - indeed, for many years they ran only on proprietary systems - I'm sure they won't want the name "GNU" (the key FSF project) associated with some programs that don't meet the "Free Software" definition. According to the web site, some applications don't permit redistribution of modified programs, and that fundamentally contradicts the FSF definition of "Free Software". But this won't be hard to fix, really - just remove a few programs (none of the most critical ones) or change the name.
A quick look at their contact page at http://www.apple.com/contact suggests a few possibilities, such as their Apple.com feedback page or sending email to their Quicktime Feedback address, quicktime@apple.com. Or both. Perhaps there's a better way, hopefully someone here will post it.
Whining would be worthless. Polite letters asking Apple to please support Ogg Vorbis across their product line (especially product A, B, and C) would probably be read. If you currently use their product (and would pay for an upgrade that supported Ogg Vorbis), or have decided to NOT buy one of their products because it doesn't support Ogg Vorbis, say so - that will be more likely to get their attention.
I've already let Apple know. If you want Apple to support Ogg Vorbis, you should too.
The same can occur here, too. It's very difficult to get Word users to switch to Linux! But if the majority of word processor users (for example) used Open Office (or Abiword or KWord), then they'd find it essentially trivial to switch.
People don't buy operating systems. They buy applications, and then get the operating system to run it. If you want people to use your operating system, you need to get them to use the applications that run on your operating system.
You can find the original MITRE 2002 report here.
If you're interested writing secure applications for Linux/Unix systems, take a look at my free book, Secure Programming for Linux and Unix HOWTO, available at http://www.dwheeler.com/secure-programs.
Thanks for the info!
There is a Japanese study, simply called the Linux white paper 2003, that studies current use of Linux in Japan. If you don't read Japanese, a summary of the material is available in Why OSS/FS? Look at the Numbers! in the market share section. Look for the point that starts with "A Japanese survey found widespread use and support for GNU/Linux; overall use of GNU/Linux jumped from 35.5% in 2001 to 64.3% in 2002 of Japanese corporations, and GNU/Linux was the most popular platform for small projects." Note that this is the percentage of corporations using it at all, not the number of total machines, but it certainly suggests interest by the Japanese corporate world. Various other statistics are quoted as well.
If it was clearly illegal to send unsolited bulk email (spam) to anyone in the U.S. or Europe, and a hefty fine backed that up, it would force spammers to move to smaller countries. Those countries would then quickly get blacklisted: "Fix your laws, or you can't do business with us." There will still be spam, but it will be much, much rarer because it would be more dangerous. You could also fine companies that pay for spam - a few hefty payments would at least eliminate a lot of commercial spam.
A partial alternative would be to require (by law) automatable marking (say "ADV:" as the first characters in the subject line) and forbidding source forging. Again, could spammers disobey the law? Sure, murder still happens too. But by making it legally a crime, with real penalties, we certainly reduce the number of perpetrators.
For more info, see http://www.dwheeler.com/essays/stopspam.html
If you don't read Japanese, you can find a summary of interesting results in Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers! ; look for the text starting with "A Japanese survey found".