> Having different users for different purposes is the essence of security.
IMO, privileges should be granted to or withheld from applications, more than users. Sure, you have to have restricted user accounts, for situations where users who don't trust one another use the same system (e.g., public access stations), but for a single-user (or family) workstation, substantially the majority case on the desktop, it's more important to restrict what certain *applications* can do.
Some applications do need to be able to do pretty much anything. The shell comes to mind here. But many applications don't. A web browser needs to have access to the network, read access to the directory tree where the browser itself is installed, read/write access to the user's browser profile (where bookmarks and stuff are stored), read/write access to the user's download directory, and the ability to print. For most users that's enough. Some users might also want to grant it the ability to launch a text editor (for things like View Source), a mail reader (for mailto: links) or certain other apps (e.g., Acrobat Reader). There is *no* reason for the web browser to be allowed to launch arbitrary apps, execute arbitrary code from sources external to itself (except maybe certain designated plugins), write files to arbitrary locations, access the user's mail and address books and personal documents, or many of the other things that, under the current security model in just about every OS, any app the user executes is allowed to do.
For too long, security has focused on the user, rather than the application. Any given application, you either have to trust it fully and give it free reign to do whatever it likes with your data, or completely eschew using it. (Yes, you can create a separate user account, but this is cumbersome and in many cases impractical. It works okay for servers and daemons, not so well for desktop-type applications.)
Of course, pointing out this problem is *way* easier than fixing it.
> Exploit yes, root exploit, no, not unless the user is running as an > Administrator.
The Win32 API has unfixable[1] design flaws in the message-passing system that result in what amounts to a privilege escalation vulnerability. When you combine that with an otherwise non-root remote exploit, the result is remote root (err, LocalSystem) capability. To date, as far as we know, nobody has managed to _automate_ the local root exploit portion, meaning that an intelligent attacker has to be involved to make this work. So far. Of course, a lot of desktop users run as Administrator... so the motivation for an attacker or worm writer to automate the privilege escalation is not very high in the general case.
[1] Unless MS chooses to break backward compatibility.
> > This is a web browser. It's not the most complicated thing in the world. > Built one of these, have you? Do tell, do tell.
Am I allowed to use modules off the CPAN? I figure if I use WWW::Mechanize and HTML::Tree, I could throw together a working browser with a fairly crude interface and no image support in maybe two days, three tops, one day if no unexpected difficulties pop up. Granted, it wouldn't be pulling many users away from Mozilla at that point. But it would basically work.
The problem with IE isn't that web browsers are hard to make. (There are almost as many web browsers as there are Tetris clones; they *can't* be all that terribly hard to make.) The problem with IE, security-wise, is that Microsoft's official security policy for *years* has been, get the app working first, then add features, and then worry about security afterward if problems crop up.
> I'd maybe lend more credibility to your statement if you weren't the bug > submitter (and thus very biased). It might be major to you, but few people > will be affected by this problem because a) not many people use compressed > drives and b) not everyone runs windows.
You're arguing the wrong thing, or your argument is unclear. First, if you look closely, it's not the submitter who marked the bug as major initially, so he's echoing someone else on that point. (The someone else is not a name I recognize as being very active in the Mozilla community, but that is neither here nor there; my point is, accusing the submitter of being the only one who things the bug is major is unfair.)
Second, you reason from "not everyone" to "few". Non sequiteur. If (as is probably the case) it is true that few will feel the direct impact of this bug, it is not because few use Windows; Windows is one of the three major platforms and has lots of users running Mozilla.org browsers. The fact that the bug is platform-specific is significant for a different reason.
Probably the real reason it has not been fixed yet is because it involves the behavior of Windows API functions with respect to NTFS properties. (There is a secondary reason, which I'll get to presently.) Not only is the issue highly platform-specific, but it involves *arcane* features of the platform in question. Many developers, including many developers who use Windows, do not have experience dealing with that sort of thing. Someone will probably have to do research. In fact, if you look at the bug, you'll see that people have been doing research. You see the results of this in comments 4 and 7. Research takes time.
It is also worth noting that it is marked as "major" because it potentially has security implications. This does not mean that it is major as bugs with security implications go. Quite the contrary; as security issues go it is rather minor. (More on that in a moment.) The fact that the assignee (and the qa, Hixie) has left it marked "Major" indicates to me that Mozilla.org takes all security issues seriously.
Having said that it is minor as security issues go, I need to present the reasoning behind that statement. Foremost, this only impacts the filesystem permissions given to a downloaded file. Filesystem permissions are of vital importance on a server, but on a Windows desktop they usually don't matter at all. Windows desktops almost always have only one real user (and, frankly, doing otherwise is an enormous security issue, much larger than this little thing we're talking about, due to the presense of certain API design flaws that make it possible for any user, even a guest user, to get arbitrary privileges by passing strategic messages to privileged processes).
Also, we're talking here about a file that has been downloaded using a web browser. There are situations where its permissions would matter (so yes, it needs to be fixed), but those situations are not the dominant case, not by quite a long shot.
Third, the bug in question results in the file downloaded not having the same permissions as the folder where it is located, but if the folder in question has strict permissions at all, then it would be quite difficult for anyone without the necessary permissions to get to the file, since that would involve navigating through a directory whose contents can't be listed. It might actually be easier to exploit the API and get localsystem privs. (Yes, there is an edge case where the directory's privileges merely prevent modifications, and the bug has a greater potential impact there.)
Finally, and perhaps most significantly, the permissions that the file gets are the same permissions it would get if the user downloaded it to the temp directory and then moved it to its final destination (which is exactly what is happening, in fact) using, say
> In fact, that's the only purpose I'd recommend for IE. (that, and > downloading a better browser
For downloading a browser, there's the ftp client that comes with Windows, although what I usually do is download the browser on another system and transfer it via a CIFS fileshare.
> Shall we detract points for not supporting every asinine scripting > language ever invented?
I'm willing to subtract points from any browser that doesn't support client-side Perl scripting. (Yeah, yeah, so far that's pretty much all of them; so if a browser does implement it, it'll have a leg up, okay?)
> Strange alien-looking freaky fish are found in other trenches (read: high > pressure), and this place has been completely isolated. Are we too crazy > to expect creatures bigger than people deep down there?
You realize this is under the central plateu of Antarctica, right? Microbes seem more likely.
> The temperature might be a problem though.
Not just the temperature; there would be *very* limited plant life, which means very limited food supply. The antarctic coasts are different, because you have currents bringing in stuff (food!) from other parts of the ocean; this is landlocked, surrounded by the coldest, dryest, and arguably most hostile environment on the planet. You'll find microbes, sure, but probably not a lot of very large critters.
> The Wired article calls Mozilla stripped dows and lacking features
Which is just wrong. Mozilla (the Seamonkey suite, I mean) has a *lot* more features than IE or Firefox. (With Firefox, you can get many of those features back, plus a few others, but you have to install a gob of extensions to do it. This wouldn't bug me so much if I could go down a checklist and just turn on the ones I want, hit one button, and have them be automatically installed next time I restart the browser, and the next time I install an upgrade it would remember that preference and install all the same ones automatically.)
The list of features that Mozilla has that IE doesn't have is lengthy in the extreme, including some relatively major things like tabbed browsing, the DOM inspector (which is *vital* for web developers), and alphachannel transparency. The guy who called it "stripped down" is the same guy who said "now, finally" when talking about the googlebar, which is several years old -- the article was obviously written by a journalist who didn't really know the subject well.
I'm in love with the CPAN. I especially like search.cpan.org -- I have a bookmark keyword set up in Mozilla for it, and it's the one I use most often, more often than the keyword for dictionary.com, probably even more often than the one for Google. I don't just use it to find new modules, either; I use it to quickly check the docs for modules I already use. Every language should have a mirrored public repository like the CPAN, complete with an automatic installer like CPAN.pm that comes standard with the language tools.
Yes, good string-handling is essential. I used to like BASIC for that, but then I discovered elisp. The buffers in elisp are exceedingly handy for this. They're like strings on steroids, only that really doesn't do them justice. The ability to place markers is particularly nifty: you can mark a spot in the buffer, and then you can modify the contents of the buffer, and the marker still marks the "right" place, even though it may be a different number of characters into the buffer. There are other cool things about buffers too.
Or you can just use "0 but true". However, 1 but false is trickier, and it's interesting values of undef (e.g., an undefined value that carries an unthrown exception so that if the calling code _needed_ a defined return value it can throw the exception and thus generate the most meaningful error possible) that really demonstrate the flexibility of Perl6's improvements in the integration between the various paradigms, especially between the contextual and object-oriented paradigms. (Support for functional paradigm is also seeing huge improvements.)
The ability to return a value that knows how to properly represent itself as a string, a number, an object, or a routine, depending on the calling code's context, is going to be highly useful; I predict that it will revolutionise the context-oriented programming paradigm and thus lead multiparadigmatic languages to new heights of convenience and expressiveness.
> Dunno why cell-phones don't have the same right though
Because, the caller is paying for the call (if it's non-local). What you're paying for is the wirelessness, roaming, and all that sort of jazz. This is not the same as a toll-free number, where the called party pays the whole bill.
I'm sure it's possible to have a cellphone with a toll-free number. I don't want to know what the monthly bill would be, though, especially if you give the number out pretty freely.
> increasing security ALWAYS entails tradeoffs vs. functionality and convienience
In theory, it always means that. In practice, some of the things being traded off are of no value to the vast overwhelming majority of us. For example, the tradeoffs involved in using Pegasus Mail instead of Outlook are in almost all cases negligible, and there are more advantages than only security as far as that goes.
Your point is basically right, though. Security is not a feature that you add. Security is knowing the implications of your setup and being aware of the ramifications of your choices.
> I eat at McDonald's BK, KFC, Wendy's for a reason - I know what I'm getting
Yeah, as long as you steer clear of evenings and weekends when they put the bad help on.
> McDonald's couldn't care less if you order nothing but a small coffee and a > cup of water
Nope, you can do that, no problem. Of course, they've priced the small coffee and the water so that they don't lose money if you do that. (They don't make as much as if you buy an Extra Value Meal, but still it completely covers the costs associated with serving you, so you're not hurting them at all.)
You want to make McDonald's hate you? Go through their drivethrough at about 11:50am and sit at the speaker saying "Hmmmm...." and trying to figure out what you want to order for about ten or twelve minutes, all the while having lengthy and loud non-order-realted conversations with your passengers. Periodically laugh hysterically, say, "Now, where was I", and go back to figuring out the part of your order you already went over a couple of minutes ago, only revise it in some arcane way. ("You're sure that comes with three packets of Sweet-N-Low, right? I need three packets with that. No, better make that four. Four should be enough, shouldn't it honey? Hey, did you hear the one about the bear and the gorilla?")
They lose money if you tie up a register for a long time during a busy time, _especially_ at lunchtime and _extra_ especially in the drivethrough. Nothing you can (legally) do (without assistance from an expensive lawyer) will annoy them more than this.
> Some companies have tried shifting to everyday low pricing styles like > Walmart, but this has not generally been successful.
I don't know about _generally_, but it seems to be doing okay for Wal-Mart, at least in this area. Last time I saw an available parking space within a hundred yards of their front door, we were driving past on the way to some relatives' place on Christmas afternoon. And from the usual cart-traffic conditions inside, it doesn't appear many people are using their parking lot to patronize other establishments.
> That's a loss leader. As a customer, I consider the use of loss leaders to > be sneaky at best, deceptive or even fraudulent at worst
Depends. When grocery stores do it, you can walk into the store, put the item in your cart, and go check out without being questioned. Sure, you have to walk past a bunch of tempting items and resist the urge to put them in your cart, but you have to do that any time you go into a grocery store anyway, so it's no different from the usual, only some of the people with no willpower are wasting their money in the store with the loss leader instead of doing the same thing in the other store. This kind of loss leader is IMO valid way to bank on human psychology. (Sometimes they run out toward the end of the sale, but any grocery store I've ever dealt with will give you a raincheck on request in that case. When it's a holiday special, such as Thanksgiving turkeys, they make a point of having enough that they don't run out. We always get two turkeys at Thanksgiving and keep one in the freezer for later.)
However, if you walk into the store for an advertised product and cannot leave with (just) that product without being harrassed by salespeople trying to get you to buy a different, higher-profit, more expensive, or additional product, that's not (just) a loss-leader: it's bait-and-switch, which is a different thing and (if proven) is (theoretically) illegal (at least in some jurisdictions) (OSIAT) (IANAL).
> The point is, if just about anything electronic doesn't break within the > first year -- where it's covered by law -- then it'll probably last ten > years or more.
This falls apart for some kinds of items (such as hard drives and (CRT) monitors). Monitors frequently fail after 2-6 years, and hard drives seem to fail after a random amount of time; failure after six months or after six years is _about_ equally likely, in my estimation.
It's still true that the first few hours of use bear an increased risk of breakdown, though, compared to any other timeframe of equal length.
And it's still a good rule of thumb. Many things are most likely to fail in the first year or after a long time.
> Isn't GNU Emacs really at version number 1.21.x.y
I thought it was 0.21.x.y, and that Emacs hadn't reached version 1.0 yet. I'm pretty sure two versions previous it was 0.19.x.y, on the grounds that it was not yet sufficiently feature-complete to be called 1.0. IMO, Emacs is still not sufficiently feature-complete to be considered 1.0. I have a whole list of features Emacs needs before it can properly be considered a text editor. (The fact that it's orders of magnitude closer than any *other* so-called excuse for a text editor is irrelevant; I want my text editor to be *fully* feature-complete, darnit.) Some of the most glaring omissions...
* elisp doesn't have a fork mechanism or lazy evaluation. It needs both;
I should be able to read the first message in Gnus while the others are
downloaded, for example. * An alternative set of keybindings is needed where all the usual keys do
the same things as in other applications; it should be possible to switch
to this set of bindings atomically in one fell swoop (and then of course
individual bindings could still be changed if desired). * Graphics support is still very poor. * Emacs seriously needs a better web browser. W3 is interesting, but it's
not as useful as the browsers on other platforms, most notably Mozilla.
What we really need is a Mozilla port to Emacs. Which leads me to... * We seriously need a C/C++ compiler that targets Emacs, and the standard
libraries and things.
There are other things, but those are just some of the biggies.
Until we have these things (and everything else), Emacs should stay with the major version number 0, to indicate that it is not yet feature-complete.
In most languages, the logical operations short-circuit if possible (except xor, for which this is never possible). In the case of 0 and 1, the 1 never gets evaluated, and in the case of 1 or 0, the 0 never gets evaluated. There's *definitely* no multiplication going on.
Of course, in Perl6 it will be possible to have a value of 0 that is true or even a value of 1 that is false, using properties (see the notes in the Apocalypse article (number 12 IIRC) about "interesting values of undef", but by default 0 will still be false and 1 true in boolean context, just like you would expect.
> Bryan Mack, who created the hoax on November 18, 1997
I'm stone cold certain that I first had this hoax (or something *very* similar; it definitely involved Bill Gates' being able to track how many people forwarded the message and donating money if enough people did it) forwarded to me when I was in college. I graduated in May of 1997. That puts it well before November of 1997. Frankly I'm pretty sure it was before any part of 1997.
Slashdot Mirror
> Having different users for different purposes is the essence of security.
IMO, privileges should be granted to or withheld from applications, more than
users. Sure, you have to have restricted user accounts, for situations where
users who don't trust one another use the same system (e.g., public access
stations), but for a single-user (or family) workstation, substantially the
majority case on the desktop, it's more important to restrict what certain
*applications* can do.
Some applications do need to be able to do pretty much anything. The shell
comes to mind here. But many applications don't. A web browser needs to have
access to the network, read access to the directory tree where the browser
itself is installed, read/write access to the user's browser profile (where
bookmarks and stuff are stored), read/write access to the user's download
directory, and the ability to print. For most users that's enough. Some
users might also want to grant it the ability to launch a text editor (for
things like View Source), a mail reader (for mailto: links) or certain other
apps (e.g., Acrobat Reader). There is *no* reason for the web browser to be
allowed to launch arbitrary apps, execute arbitrary code from sources external
to itself (except maybe certain designated plugins), write files to arbitrary
locations, access the user's mail and address books and personal documents,
or many of the other things that, under the current security model in just
about every OS, any app the user executes is allowed to do.
For too long, security has focused on the user, rather than the application.
Any given application, you either have to trust it fully and give it free
reign to do whatever it likes with your data, or completely eschew using it.
(Yes, you can create a separate user account, but this is cumbersome and
in many cases impractical. It works okay for servers and daemons, not so
well for desktop-type applications.)
Of course, pointing out this problem is *way* easier than fixing it.
> Exploit yes, root exploit, no, not unless the user is running as an
> Administrator.
The Win32 API has unfixable[1] design flaws in the message-passing system
that result in what amounts to a privilege escalation vulnerability. When
you combine that with an otherwise non-root remote exploit, the result is
remote root (err, LocalSystem) capability. To date, as far as we know,
nobody has managed to _automate_ the local root exploit portion, meaning that
an intelligent attacker has to be involved to make this work. So far.
Of course, a lot of desktop users run as Administrator... so the motivation
for an attacker or worm writer to automate the privilege escalation is not
very high in the general case.
[1] Unless MS chooses to break backward compatibility.
> > This is a web browser. It's not the most complicated thing in the world.
> Built one of these, have you? Do tell, do tell.
Am I allowed to use modules off the CPAN? I figure if I use WWW::Mechanize
and HTML::Tree, I could throw together a working browser with a fairly crude
interface and no image support in maybe two days, three tops, one day if no
unexpected difficulties pop up. Granted, it wouldn't be pulling many users
away from Mozilla at that point. But it would basically work.
The problem with IE isn't that web browsers are hard to make. (There are
almost as many web browsers as there are Tetris clones; they *can't* be all
that terribly hard to make.) The problem with IE, security-wise, is that
Microsoft's official security policy for *years* has been, get the app
working first, then add features, and then worry about security afterward
if problems crop up.
> I'd maybe lend more credibility to your statement if you weren't the bug
> submitter (and thus very biased). It might be major to you, but few people
> will be affected by this problem because a) not many people use compressed
> drives and b) not everyone runs windows.
You're arguing the wrong thing, or your argument is unclear. First, if you
look closely, it's not the submitter who marked the bug as major initially,
so he's echoing someone else on that point. (The someone else is not a name
I recognize as being very active in the Mozilla community, but that is
neither here nor there; my point is, accusing the submitter of being the
only one who things the bug is major is unfair.)
Second, you reason from "not everyone" to "few". Non sequiteur. If (as is
probably the case) it is true that few will feel the direct impact of this
bug, it is not because few use Windows; Windows is one of the three major
platforms and has lots of users running Mozilla.org browsers. The fact that
the bug is platform-specific is significant for a different reason.
Probably the real reason it has not been fixed yet is because it involves
the behavior of Windows API functions with respect to NTFS properties.
(There is a secondary reason, which I'll get to presently.) Not only is the
issue highly platform-specific, but it involves *arcane* features of the
platform in question. Many developers, including many developers who use
Windows, do not have experience dealing with that sort of thing. Someone
will probably have to do research. In fact, if you look at the bug, you'll
see that people have been doing research. You see the results of this in
comments 4 and 7. Research takes time.
It is also worth noting that it is marked as "major" because it potentially
has security implications. This does not mean that it is major as bugs with
security implications go. Quite the contrary; as security issues go it is
rather minor. (More on that in a moment.) The fact that the assignee (and
the qa, Hixie) has left it marked "Major" indicates to me that Mozilla.org
takes all security issues seriously.
Having said that it is minor as security issues go, I need to present the
reasoning behind that statement. Foremost, this only impacts the filesystem
permissions given to a downloaded file. Filesystem permissions are of vital
importance on a server, but on a Windows desktop they usually don't matter
at all. Windows desktops almost always have only one real user (and, frankly,
doing otherwise is an enormous security issue, much larger than this little
thing we're talking about, due to the presense of certain API design flaws
that make it possible for any user, even a guest user, to get arbitrary
privileges by passing strategic messages to privileged processes).
Also, we're talking here about a file that has been downloaded using a web
browser. There are situations where its permissions would matter (so yes,
it needs to be fixed), but those situations are not the dominant case, not
by quite a long shot.
Third, the bug in question results in the file downloaded not having the
same permissions as the folder where it is located, but if the folder in
question has strict permissions at all, then it would be quite difficult
for anyone without the necessary permissions to get to the file, since that
would involve navigating through a directory whose contents can't be listed.
It might actually be easier to exploit the API and get localsystem privs.
(Yes, there is an edge case where the directory's privileges merely prevent
modifications, and the bug has a greater potential impact there.)
Finally, and perhaps most significantly, the permissions that the file gets
are the same permissions it would get if the user downloaded it to the temp
directory and then moved it to its final destination (which is exactly what
is happening, in fact) using, say
> In fact, that's the only purpose I'd recommend for IE. (that, and
> downloading a better browser
For downloading a browser, there's the ftp client that comes with Windows,
although what I usually do is download the browser on another system and
transfer it via a CIFS fileshare.
> Shall we detract points for not supporting every asinine scripting
> language ever invented?
I'm willing to subtract points from any browser that doesn't support
client-side Perl scripting. (Yeah, yeah, so far that's pretty much all of
them; so if a browser does implement it, it'll have a leg up, okay?)
> Strange alien-looking freaky fish are found in other trenches (read: high
> pressure), and this place has been completely isolated. Are we too crazy
> to expect creatures bigger than people deep down there?
You realize this is under the central plateu of Antarctica, right?
Microbes seem more likely.
> The temperature might be a problem though.
Not just the temperature; there would be *very* limited plant life, which
means very limited food supply. The antarctic coasts are different, because
you have currents bringing in stuff (food!) from other parts of the ocean;
this is landlocked, surrounded by the coldest, dryest, and arguably most
hostile environment on the planet. You'll find microbes, sure, but probably
not a lot of very large critters.
Does this mean that rpmdrake will also be coming to Fedora?
> The Wired article calls Mozilla stripped dows and lacking features
Which is just wrong. Mozilla (the Seamonkey suite, I mean) has a *lot* more
features than IE or Firefox. (With Firefox, you can get many of those features
back, plus a few others, but you have to install a gob of extensions to do it.
This wouldn't bug me so much if I could go down a checklist and just turn on
the ones I want, hit one button, and have them be automatically installed next
time I restart the browser, and the next time I install an upgrade it would
remember that preference and install all the same ones automatically.)
The list of features that Mozilla has that IE doesn't have is lengthy in the
extreme, including some relatively major things like tabbed browsing, the DOM
inspector (which is *vital* for web developers), and alphachannel transparency.
The guy who called it "stripped down" is the same guy who said "now, finally"
when talking about the googlebar, which is several years old -- the article
was obviously written by a journalist who didn't really know the subject well.
I'm in love with the CPAN. I especially like search.cpan.org -- I have a
bookmark keyword set up in Mozilla for it, and it's the one I use most often,
more often than the keyword for dictionary.com, probably even more often than
the one for Google. I don't just use it to find new modules, either; I use
it to quickly check the docs for modules I already use. Every language should
have a mirrored public repository like the CPAN, complete with an automatic
installer like CPAN.pm that comes standard with the language tools.
> a standardized documentation feature
Oh, like POD (in Perl) or docstrings (in elisp)?
Yes, good string-handling is essential. I used to like BASIC for that, but
then I discovered elisp. The buffers in elisp are exceedingly handy for this.
They're like strings on steroids, only that really doesn't do them justice.
The ability to place markers is particularly nifty: you can mark a spot in
the buffer, and then you can modify the contents of the buffer, and the
marker still marks the "right" place, even though it may be a different number
of characters into the buffer. There are other cool things about buffers too.
If you want simple syntax, it's not C that you want. The lisp-based languages
all have much simpler syntax.
> Perl already uses '0E0'
Or you can just use "0 but true". However, 1 but false is trickier, and it's
interesting values of undef (e.g., an undefined value that carries an unthrown
exception so that if the calling code _needed_ a defined return value it can
throw the exception and thus generate the most meaningful error possible)
that really demonstrate the flexibility of Perl6's improvements in the
integration between the various paradigms, especially between the contextual
and object-oriented paradigms. (Support for functional paradigm is also seeing
huge improvements.)
The ability to return a value that knows how to properly represent itself as
a string, a number, an object, or a routine, depending on the calling code's
context, is going to be highly useful; I predict that it will revolutionise
the context-oriented programming paradigm and thus lead multiparadigmatic
languages to new heights of convenience and expressiveness.
> Dunno why cell-phones don't have the same right though
Because, the caller is paying for the call (if it's non-local). What you're
paying for is the wirelessness, roaming, and all that sort of jazz. This is
not the same as a toll-free number, where the called party pays the whole bill.
I'm sure it's possible to have a cellphone with a toll-free number. I don't
want to know what the monthly bill would be, though, especially if you give
the number out pretty freely.
> increasing security ALWAYS entails tradeoffs vs. functionality and convienience
In theory, it always means that. In practice, some of the things being
traded off are of no value to the vast overwhelming majority of us. For
example, the tradeoffs involved in using Pegasus Mail instead of Outlook
are in almost all cases negligible, and there are more advantages than only
security as far as that goes.
Your point is basically right, though. Security is not a feature that you add.
Security is knowing the implications of your setup and being aware of the
ramifications of your choices.
> I eat at McDonald's BK, KFC, Wendy's for a reason - I know what I'm getting
Yeah, as long as you steer clear of evenings and weekends when they put
the bad help on.
> McDonald's couldn't care less if you order nothing but a small coffee and a
> cup of water
Nope, you can do that, no problem. Of course, they've priced the small coffee
and the water so that they don't lose money if you do that. (They don't make
as much as if you buy an Extra Value Meal, but still it completely covers the
costs associated with serving you, so you're not hurting them at all.)
You want to make McDonald's hate you? Go through their drivethrough at about
11:50am and sit at the speaker saying "Hmmmm...." and trying to figure out what
you want to order for about ten or twelve minutes, all the while having lengthy
and loud non-order-realted conversations with your passengers. Periodically
laugh hysterically, say, "Now, where was I", and go back to figuring out the
part of your order you already went over a couple of minutes ago, only revise
it in some arcane way. ("You're sure that comes with three packets of
Sweet-N-Low, right? I need three packets with that. No, better make that
four. Four should be enough, shouldn't it honey? Hey, did you hear the one
about the bear and the gorilla?")
They lose money if you tie up a register for a long time during a busy
time, _especially_ at lunchtime and _extra_ especially in the drivethrough.
Nothing you can (legally) do (without assistance from an expensive lawyer)
will annoy them more than this.
> Some companies have tried shifting to everyday low pricing styles like
> Walmart, but this has not generally been successful.
I don't know about _generally_, but it seems to be doing okay for Wal-Mart, at
least in this area. Last time I saw an available parking space within a
hundred yards of their front door, we were driving past on the way to some
relatives' place on Christmas afternoon. And from the usual cart-traffic
conditions inside, it doesn't appear many people are using their parking lot
to patronize other establishments.
> That's a loss leader. As a customer, I consider the use of loss leaders to
> be sneaky at best, deceptive or even fraudulent at worst
Depends. When grocery stores do it, you can walk into the store, put the
item in your cart, and go check out without being questioned. Sure, you
have to walk past a bunch of tempting items and resist the urge to put them
in your cart, but you have to do that any time you go into a grocery store
anyway, so it's no different from the usual, only some of the people with
no willpower are wasting their money in the store with the loss leader
instead of doing the same thing in the other store. This kind of loss
leader is IMO valid way to bank on human psychology. (Sometimes they run
out toward the end of the sale, but any grocery store I've ever dealt with
will give you a raincheck on request in that case. When it's a holiday
special, such as Thanksgiving turkeys, they make a point of having enough
that they don't run out. We always get two turkeys at Thanksgiving and
keep one in the freezer for later.)
However, if you walk into the store for an advertised product and cannot
leave with (just) that product without being harrassed by salespeople trying
to get you to buy a different, higher-profit, more expensive, or additional
product, that's not (just) a loss-leader: it's bait-and-switch, which is
a different thing and (if proven) is (theoretically) illegal (at least in
some jurisdictions) (OSIAT) (IANAL).
> The point is, if just about anything electronic doesn't break within the
> first year -- where it's covered by law -- then it'll probably last ten
> years or more.
This falls apart for some kinds of items (such as hard drives and (CRT)
monitors). Monitors frequently fail after 2-6 years, and hard drives seem
to fail after a random amount of time; failure after six months or after
six years is _about_ equally likely, in my estimation.
It's still true that the first few hours of use bear an increased risk of
breakdown, though, compared to any other timeframe of equal length.
And it's still a good rule of thumb. Many things are most likely to fail
in the first year or after a long time.
> Isn't GNU Emacs really at version number 1.21.x.y
I thought it was 0.21.x.y, and that Emacs hadn't reached version 1.0 yet. I'm
pretty sure two versions previous it was 0.19.x.y, on the grounds that it was
not yet sufficiently feature-complete to be called 1.0. IMO, Emacs is still
not sufficiently feature-complete to be considered 1.0. I have a whole list
of features Emacs needs before it can properly be considered a text editor.
(The fact that it's orders of magnitude closer than any *other* so-called
excuse for a text editor is irrelevant; I want my text editor to be *fully*
feature-complete, darnit.) Some of the most glaring omissions...
* elisp doesn't have a fork mechanism or lazy evaluation. It needs both;
I should be able to read the first message in Gnus while the others are
downloaded, for example.
* An alternative set of keybindings is needed where all the usual keys do
the same things as in other applications; it should be possible to switch
to this set of bindings atomically in one fell swoop (and then of course
individual bindings could still be changed if desired).
* Graphics support is still very poor.
* Emacs seriously needs a better web browser. W3 is interesting, but it's
not as useful as the browsers on other platforms, most notably Mozilla.
What we really need is a Mozilla port to Emacs. Which leads me to...
* We seriously need a C/C++ compiler that targets Emacs, and the standard
libraries and things.
There are other things, but those are just some of the biggies.
Until we have these things (and everything else), Emacs should stay with
the major version number 0, to indicate that it is not yet feature-complete.
In most languages, the logical operations short-circuit if possible (except xor,
for which this is never possible). In the case of 0 and 1, the 1 never gets
evaluated, and in the case of 1 or 0, the 0 never gets evaluated. There's
*definitely* no multiplication going on.
Of course, in Perl6 it will be possible to have a value of 0 that is true or
even a value of 1 that is false, using properties (see the notes in the
Apocalypse article (number 12 IIRC) about "interesting values of undef", but
by default 0 will still be false and 1 true in boolean context, just like
you would expect.
HTH.HAND.
That's a bitwise operation. In boolean terms, 3 and 2 evaluates to true.
> This isn't to say I'm really happy with how Mozilla does things. I would
> MUCH prefer it if I had the "trusted sites" concept in Mozilla/FireFox
It is possible to do this sort of thing with custom capability policies.
There's admittedly no UI for most of it though.
> Bryan Mack, who created the hoax on November 18, 1997
I'm stone cold certain that I first had this hoax (or something *very*
similar; it definitely involved Bill Gates' being able to track how many
people forwarded the message and donating money if enough people did it)
forwarded to me when I was in college. I graduated in May of 1997. That
puts it well before November of 1997. Frankly I'm pretty sure it was
before any part of 1997.