There were two known cases of *prototype* 5200s with batteries manufactured by Sony "catching fire".
From then on, the 5200 had the reputation of the PowerBook that "caught fire", but there were no know or reported incidents.
I guess basically what I'm saying is this: you're lying, or trolling, or both. I kind of think you're trolling because you say it's "pretty embarrassing" to explain that. No it's not. It's not embarrassing at all. If your freaking laptop really did catch fire, it's not because of something you did. But since no consumer issues were logged for the PowerBook 5200 on this issue - and when verified, that is an *extremely serious issue* that requires action - I don't believe you.
Also, Apple has, over the years, maintained a fairly consistent number one position in initial quality, lack of need for repairs, and product support, according to Consumer Reports. This has been consistently maintained, and remains so to this day. Also, the iPod destroys your mass production argument.
Good troll, though. This could replace the "ok, so I'm sitting here and it's taking 17 minutes to copy a 4 meg file from my Power Mac G5" one!
...the vast majority of MacBook Pro owners don't have any issues at all, and Apple typically addresses issues the inevitable issues that do exist in product revisions.
And they usually come from the same place, as the followup notes:
A php-based web application (forum, blog, CMS, etc.) that has an exploit, usually php injection, whereby various script/botnet kiddie tools and irc-related items are installed, usually in/tmp or/var/tmp. Perhaps they'll install a php shell too. Sometimes, they'll try to run a rootkit against the local machine.
This is nothing new, and doesn't really have anything to do with "Macs". It has more to do with php and people not keeping their php-based web applications up to date than anything[1]. It is interesting, though, that since Mac OS X is essentially a UNIX, that it's certainly vulnerable to a whole slew of this family of exploits.
[1] Just as a Mac sitting on the internet with apache and ssh open doesn't really test anything beyond the security of the default configurations of apache and OpenSSH on that OS and architecture. And that's exactly the point.
Well, that's kind of a catch-22: they already have the technology and hardware/software pieces to do this, but it needs to be certified. And it's the local governments and municipalities that are, in part, part of the certification process.
We can't say Diebold doesn't have it. But governmental entities who are supposedly clamoring for this certainly aren't in any rush to certify it. I understand and appreciate that it is a complex process, but the point is that the capability is there, and needs to be certified, and can then be purchased and used by any state/county/locale that wishes. It's not as if Diebold refused to add this capability. The onus is now on certification entities, not Diebold.
Gee, I would think that with all of the bitching and griping about individual external audit trails for electronic voting machines that Diebold would be trumpeting it from the front page of their voting machine home page if it was available.
They don't because although this is a huge issue in the alternative press and political blogs, this really isn't a big thing on their radar. As big as some other things are, anyway. They're also still trying to push the concept that this can be done reliably electronically.
Can you point me at some documentation about their individual voter reciepts?
A spokesperson for Diebold told the Toledo Blade that it currently has the receipt-printing technology, but is waiting for governments to certify the new version.
Diebold (and Sequoia, ES&S, and Hart Intercivic) will happily build and deploy any technologies that municipalities will pay for.
Yes, because as historical elections have shown, paper ballots are tamper-proof. No one has ever been known to rig or steal an election when a paper trail existed.
So, damned if you do, damned if you don't?
The fact is, a paper trail ensures nothing. It can be falsified, albeit with somewhat more difficulty than purely electronic records. Diebold's primary concern shouldn't be a random voter physically tampering with a machine, it should be the people charged with operating and safeguarding the machine. They have access, and as they're working an election, they almost certainly have strong personal political views that could motivate a "correction" of the results.
*Nothing* is ever guaranteed. The key is to arrive at a system that can be ensured to have at least some semblance of accuracy.
But the local county election officials have been the ones running our elections forever, and that hasn't changed. If you're arguing they should prevent tampering with the machines, including *inviting* tampering from third parties (such as was the case here), I'm 100% in agreement.
Sorry, but Diebold has had accessory equipment to add a paper trail at the voting station for at least 18 months. Diebold, like many large contract vendors, doesn't list all of their specific products and components on the web site and instead talks about the systems from a general standpoint.
All three major electronic voting manufacturers already have the ability to add permanent, individual voter-verified paper audit trails to their products. Don't believe people who make it seem like companies like Diebold are resisting. They aren't. They'll build - and sell - whatever municipalities will buy.
The roadblock, as it turns out, is often local election boards. First, the new paper verification systems NEED to go through the government certification process - remember, it's the e-voting watchdogs who are chastising non-certified patches/updates being put into place; the paper audit systems need to go through the same certification process. Further, many municipalities can't understand why they should be forcing paper audit trails; after all, they think, they are just getting away from paper ballots - why should they be arguing for paper ballots (and all the headaches that go along with them, ON TOP of the headaches they already have from learning to deal with e-voting), when they just got away from it?
Since EVERY SINGLE VOTER who uses these machines is a potential hacker looking to alter election results, why is Diebold so concerned?
Because EVERY SINGLE VOTER isn't allowed a level of access to the machines to presumably perform an audit or otherwise tamper with and/or view the inner workings of the machines.
The solution is quite simple:
- Have a permanent, voter verifiable, auditable, and recountable paper trail (a feature Diebold and ES&S both offer)
- Have an open source system (which actually isn't at all required if the above condition is met)
(a)(1) Each advisory committee meeting shall be open to the public.
(2) Except when the President determines otherwise for reasons of national security, timely notice of each such meeting shall be published in the Federal Register, and the Adminis- trator shall prescribe regulations to provide for other types of public notice to insure that all interested persons are notified of such meeting prior thereto.
(3) Interested persons shall be permitted to attend, appear before, or file statements with any advisory committee, subject to such reasonable rules or regulations as the Administra- tor may prescribe.
FACA makes it very clear that closed meetings can be held, and that public notice must be given of such meetings. That's it.
In an emergent situation where a closed meeting is required, waiting for it to get into the Federal Register or newspapers is ridiculous and unnecessary. Ample public notice can be given by other channels in 2006 that weren't possible in 1972.
If you argue that not only notice, but time to bring a court challenge, is what is required, then I may agree with your line of reasoning. However, I also believe that sometimes emergency meetings of federal advisory committees may be needed without excessive lead time.
Judging from your post, it sounds like you have no concept of the fact that federal advisory council meetings have been able to be closed for nigh on 34 years, and the only thing that this would change is the generally accepted 15-day notice of the closed meeting to the Federal Register, which isn't even required by the statute. The meeting is still closed, in either instance. 15-day notice or not. How is that "surrendering rights" or "freedom"? Please, explain that to me.
We live in a society based on rule of law and rights tempered with responsibility, including delegated responsibility that we implicitly grant to government. Bottom line? Someone trying to make a mountain out of a molehill. Even the submission makes it appear as if the "new" aspect of this is closed meetings.
Oops. It isn't. Such meetings have been able to be closed for three and a half decades with notice, and with no notice for the prior couple centuries, since there was no requirement for any notice. The "notice" aspect was created to allow for public notification of a closed meeting of an advisory board, so that the public would still have reasonable mechanisms to obtain more information. Note that in the statute, nothing specific is required for notice, other than it be given.
Notice can still be given, and an advisory committee on critical public infrastructure can have a closed meeting when deemed necessary, as it would have been able to since 1776 and 1976. And now, 2006. But without having to arbitrarily wait 15 days between the notice and the closed meeting.
Please note that even with a 15 day notice, there is NO PUBLIC RECOURSE, and no process to open the meeting. It is a NOTICE ONLY. So if you want to trumpet about "rights", why don't you learn what you're talking about first.
Except that meetings of such advisory committees have already been able to be closed to the public for 34 years (and could also be closed to the public with NO notice before that).
FACA stipulated a reasonable notice to the public when a meeting was to be closed, so as to advise the public where additional information may be obtained, or information about when the results of such a meeting may become public, or when future public meetings may occur.
That was in 1972.
The meetings were still closed.
In 2006, there is no reason to give 15 days notice of a closed meeting of a federal advisory board. Ample information can be broadly provided to meet the statue, which specifically states:
(a)(1) Each advisory committee meeting shall be open to the public.
(2) Except when the President determines otherwise for reasons of national security, timely notice of each such meeting shall be published in the Federal Register, and the Adminis- trator shall prescribe regulations to provide for other types of public notice to insure that all interested persons are notified of such meeting prior thereto.
(3) Interested persons shall be permitted to attend, appear before, or file statements with any advisory committee, subject to such reasonable rules or regulations as the Administra- tor may prescribe.
Public notice of a closed meeting can reasonably happen a lot more quickly in 2006 than it could in 1972. Remember, the meeting is still closed.
Under FACA, such federal advisory meetings can already be closed, and have been able to be closed for over three decades. However, a 15-day public notice must be given for such a closure.
The net result, however, is that the meeting is still closed.
This change allows for the Critical Infrastructure Partnership Advisory Council to have closed meetings in an emergency without giving a 15-day notice that it is going to have a closed meeting.
I think that critical public infrastructure protection outweighs any need for a 15-day notice of a closed meeting.
The "government" has had weapons that the "citizens" cannot (easily) gain access to for more than a century. How is this different?
Or is this just a pulpit for you since you caught the article early?
(The "government" will ALWAYS have more sophisticated weaponry, because it is pooling the resources of the citizenry to design, develop, build, and purchase such weaponry. Your discussion is interesting for a philosophical debate; nothing more.)
No, the "funny part" is that people were aware of it, but later, executive management viewed it as too much of a liability/exposure - this is probably so, from certain perspectives. You can read her thoughts on it here. I routinely do interviews for the press, and have been involved with projects that have received national exposure that aren't strictly UW-related, such as Grants.gov for Mac OS X, a package which Grants.gov and Northrop Grumman now officially distribute themselves.
And appleintelfaq.com and ipodbatteryfaq.com just picked up the default contact information I use on DirectNIC, where other domains I administer for UW are registered. Since they're hosted off campus, have nothing to do with the university, and don't use university DNS, there was never any issue with either domain. I've changed the contact information appropriately.
If you really are affiliated with the university and have something to say to me, why don't you stop by my office or email me instead of anonymously trolling me on slashdot? Thanks!
Re:Even if this one isn't real...
on
WinXP on a Mac, Hoax?
·
· Score: 2, Informative
The real benefit to most people will come from running Windows alongside Mac OS X in a "virtual machine" environment, in a window or even full screen, with, for example, a hotkey to switch back and forth between Mac OS X and Windows. To many users who prefer Mac OS X, particularly in enterprise, academic, and research environments, but who also have the occasional applications (usually administrative) that require Windows, this configuration would be a holy grail of sorts. And in this configuration, Windows wouldn't be running in emulation, but it would be running at essentially the native speed of the underlying hardware (with the exception of graphics and disk I/O performance). It will be *much* faster than any emulation ever has been, and there will no doubt be several open source (qemu, xen, wine) and commercial (vmware, Virtual PC) that will allow running Windows (or Windows software) in various capacities. Intel's Virtualization Technology (VT), allowing multiple operating systems to run in separate hardware "partitions" on one processor, make these prospects even more efficient and exciting from a technical standpoint. That scenario *will* happen; it's only a matter of time of the software coming to the platform now that the Intel Macs are shipping.
As to the question, however, of why someone would want to install Windows directly, or "dual boot", here are some answers:
- Gaming. This is probably the primary reason. Since even virtual machine solutions typically still emulate some aspects of video, to get the full performance Windows still has to be running natively directly on the hardware.
- Best possible performance. For those who want Windows and their Windows applications to run as best as they possibly can, again, running Windows directly is required.
- A desire to run Windows (for whatever reason, whether it be preference, desire, necessity, etc.) on quality Apple hardware, while also having the option to run Mac OS X.
- Other applications for which direct hardware access is required.
- Becuase you can. No reason at all other than to "do it".
There are many other arguments for Apple's x86 transition being a potential trojan horse into environments that otherwise avoided Apple hardware because of requirements for Windows. Being able to run Windows in supported vm environments, such as VMware, could be a huge boon to Mac OS X/Apple adoption in certain sectors. The ability to directly boot Windows, even if officially unsupported by Apple, is also very attractive to some.
...Amit Singh from IBM and kernelthread.com (slashdotted 16 times for excellent technical articles on various bits of internals of Apple hardware and Mac OS X) has his own legacy boot solution as well. From a rejected submission:
It appears that Amit Singh of IBM Almaden Research Center, of kernelthread.com and author of Mac OS X Internals, has devised a method to allow legacy, or BIOS-based, booting on Intel-based Macs, which they're calling "BAMBIOS". This means operating systems that currently only support legacy booting, such as many Linux distributions that don't yet support EFI, or things like Windows XP and the forthcoming Windows Vista (the 32-bit version of which will lack EFI support), will now be able to run on Intel-based Macs without modification (and completely legally). There is also another solution from "narf2006", described here and shown in this flickr set of photos. narf2006's solution is awaiting verification by Colin for the $12,000 pot. Time to get that MacBook Pro you've been waiting on for the best of both worlds, everyone...
So even if narf2006's solution isn't real, Amit's solution most certainly is, since he has a great deal of credibility. One way or another, we'll all be able to boot Windows directly on our Intel-based Macs.
This will be great news for people interested in Windows gaming on an Intel-based Mac (who really need the direct video access) and/or people who just want to do it NOW; however, a virtualization solution running under Mac OS X, such as VMware or Parallels, will be the real holy grail for most users. Most people don't want/need/care about the highest graphics and I/O performance; just the ability to run Windows side-by-side with Mac OS X at a speed that is more than usable, and to also have some capability to seamlessly share things like clipboards and files between the environments (as a nice VM environment would most certainly do). Not to mention not having to reboot.
In any case, even dual booting will be a welcome capability. It remains to be seen how convoluted the process is...
Also, I just spoke with Colin Nederkoorn (the guy running the contest) moments ago, and narf2006's solution has NOT been submitted to him yet. He said that narf2006 said he's "cleaning it up" and will be submitting it "later this week". So, no one, including Colin, has actually seen this solution working yet. Also, he apparently hasn't been in communication with Amit on the BAMBIOS solution as yet...
For the record, no, the passwords are not the same.
(And for those wondering, the NetID/username is the non-private part of our NetID credential.)
Also, I'd hope that one would also understand that going after other machines in that way is bad form, and doesn't speak to Mac OS X's security (or insecurity), but rather to the practice of having strong/different passwords across multiple secure systems.
That was the IP of the machine before it moved to its new network. As I described in another post, there are two minis, both identical, with one on the new network so the cutover would be transparent.
The new IP is 72.33.255.254, and will remain as such. Once DNS has propagated sufficiently, the original host will go away.
No, my position is not funded or "rewarded" by Apple.
Also, I can't say I've *ever* gotten a "freebie" anything from Apple in 22 years other than a couple of T-shirts. Oh, and a nice pen once. I've also never heard of anyone in enterprise or education getting free flat panels and iPods from Apple (except for the free iPod promotions they've had when people buy certain laptops).
Also, since Mac OS X is used *heavily* in education, particularly at large research universities, and diversity of computing platforms is important to avail faculty, staff, and students of the best resources to do their jobs, I'm sure many are interested in the general security of a typical Mac OS X machine with a couple of typical services running on the internet, especially in the wake of such misleading press coverage of the same. The only interests I represent are those of the University of Wisconsin - Madison.
And yes, this challenge is sanctioned. I'm glad that the University of Wisconsin supports the genuine interests of its faculty, staff, and students, and encourages individual thought, research, discovery, and exploration. That's why it's a great place to be!
Mac OS X is not invulnerable. It, like any other operating system, has security deficiencies in various aspects of the software. Some are technical in nature, and others lend themselves to social engineering trickery. However, the general architecture and design philosophy of Mac OS X, in addition to usage of open source components for most network-accessible services that receive intense peer scrutiny from the community, make Mac OS X a very secure operating system. There have been serious vulnerabilities in Mac OS X that could be taken advantage of; however, most Mac OS X "vulnerabilities" to date have relied on typical trojan social engineering tactics, not genuine vulnerabilities. The recent Safari vulnerability was promptly addressed by Apple, as are any exploits reported to Apple. Apple does a fairly good job with regard to security, and has greatly improved its reporting processes after pressure from institutional Mac OS X users: Apple is responsive to security concerns with Mac OS X, which is one of the most important pieces of the security picture.
The "Mac OS X hacked under 30 minutes" story doesn't mention that local access was granted to the system. While local privilege escalation exploits can certainly be dangerous - and used in conjunction with things like the above Safari exploit - this isn't very informative with regard to the general security of a Mac OS X machine sitting on the Internet.
Of course, I'd have no problem with this if the original article had actually talked about it meaningfully in the context of a local privilege escalation and explored the implications; instead, they just made it sound like you could throw a patched OS X box onto the internet and it'd get owned. The average reader would leave with that *distinct* impression, and most of the subsequent coverage of it talked about it exactly in that fashion.
Mac OS X has had several local privilege escalation vulnerabilities, just as other OSes have had. Apple fixes them when they become known. (Also, and this is another discussion, but what can Apple do if the "hacker's" claims are correct, i.e., that the vulnerability is unknown to Apple? It doesn't prove that Mac OS X is "insecure"; all it "proves" is that open scrutiny is difficult with closed source pieces, and that some people intentionally and knowingly refuse to give vendors a chance to fix problems.)
- Keep your machine patched - Don't randomly open ports for services you don't use - Have a personal firewall/router - Don't run software you don't trust
And this doesn't "prove" anything, except that the initial ZDnet article was totally vague and sensationalistic, making it seem to an average person reading that article that a Mac OS X box could just be "hacked" by being on the internet. That is wrong, and I'm showing that. Simple. It's all explained on http://test.doit.wisc.edu/
Yes, this is approved. But it's getting moved to its own/29 today...unfortunately, that didn't happen before slashdot got to it.;-)
There is an identical clone of that Mac mini waiting to go on the new network, and our DNS TTL is currently set to 5 minutes, so when the cutover happens, it should be pretty transparent.
And the whole point isn't that the test "isn't the same". This is how most Mac OS X machines will appear to outside entities on the internet. The original article - and definitely before it was updated - left people with the impression that a Mac OS X machine could be owned in 30 minutes just by being connected to the internet, without the user "doing" anything, and the subsequent coverage of this in most press proves it. None speak to the fact that a local account was given, or even explore the implications. What could have been a useful article was useless, vague sensationalism. I updated the bottom of the page this morning:
Update
The ZDnet article has been updated to include the sentence, "Participants were given local client access to the target computer and invited to try their luck." But might it not have been interesting to explore:
- What are the implications of local account access, and under what conditions might a computer be used in that way?
- How can such access normally be obtained? Do home users behind firewalls and with no ports open need to worry? How can a vendor fix the claimed local privilege escalation vulnerabilities when they are not informed of the issue?
- What are the moral and ethical implications of knowing about allegedly severe vulnerabilities in products, like the "hacker" they interviewed, and actively choosing to NOT give the vendor an opportunity to fix the problem(s)?
- How might a Linux or BSD distribution, other commercial UNIXes, or Windows stand up to a similar challenge, where anyone who wishes is given local account access?
- A discussion about how since much of OS X is closed, this might make it more difficult for the community to discover - and report and fix - potential vulnerabilities in the closed pieces
...and things of that nature, instead of leaving people with the impression that any Mac OS X machine connected to the Internet can be taken over in 30 minutes?
Slashdot Mirror
There were two known cases of *prototype* 5200s with batteries manufactured by Sony "catching fire".
From then on, the 5200 had the reputation of the PowerBook that "caught fire", but there were no know or reported incidents.
I guess basically what I'm saying is this: you're lying, or trolling, or both. I kind of think you're trolling because you say it's "pretty embarrassing" to explain that. No it's not. It's not embarrassing at all. If your freaking laptop really did catch fire, it's not because of something you did. But since no consumer issues were logged for the PowerBook 5200 on this issue - and when verified, that is an *extremely serious issue* that requires action - I don't believe you.
Also, Apple has, over the years, maintained a fairly consistent number one position in initial quality, lack of need for repairs, and product support, according to Consumer Reports. This has been consistently maintained, and remains so to this day. Also, the iPod destroys your mass production argument.
Good troll, though. This could replace the "ok, so I'm sitting here and it's taking 17 minutes to copy a 4 meg file from my Power Mac G5" one!
...the vast majority of MacBook Pro owners don't have any issues at all, and Apple typically addresses issues the inevitable issues that do exist in product revisions.
And they usually come from the same place, as the followup notes:
/tmp or /var/tmp. Perhaps they'll install a php shell too. Sometimes, they'll try to run a rootkit against the local machine.
A php-based web application (forum, blog, CMS, etc.) that has an exploit, usually php injection, whereby various script/botnet kiddie tools and irc-related items are installed, usually in
This is nothing new, and doesn't really have anything to do with "Macs". It has more to do with php and people not keeping their php-based web applications up to date than anything[1]. It is interesting, though, that since Mac OS X is essentially a UNIX, that it's certainly vulnerable to a whole slew of this family of exploits.
[1] Just as a Mac sitting on the internet with apache and ssh open doesn't really test anything beyond the security of the default configurations of apache and OpenSSH on that OS and architecture. And that's exactly the point.
Well, that's kind of a catch-22: they already have the technology and hardware/software pieces to do this, but it needs to be certified. And it's the local governments and municipalities that are, in part, part of the certification process.
We can't say Diebold doesn't have it. But governmental entities who are supposedly clamoring for this certainly aren't in any rush to certify it. I understand and appreciate that it is a complex process, but the point is that the capability is there, and needs to be certified, and can then be purchased and used by any state/county/locale that wishes. It's not as if Diebold refused to add this capability. The onus is now on certification entities, not Diebold.
Gee, I would think that with all of the bitching and griping about individual external audit trails for electronic voting machines that Diebold would be trumpeting it from the front page of their voting machine home page if it was available.
They don't because although this is a huge issue in the alternative press and political blogs, this really isn't a big thing on their radar. As big as some other things are, anyway. They're also still trying to push the concept that this can be done reliably electronically.
Can you point me at some documentation about their individual voter reciepts?
Here is one of several tangential mentions, this one focusing on Ohio, where Diebold machines are used in much of the state:
A spokesperson for Diebold told the Toledo Blade that it currently has the receipt-printing technology, but is waiting for governments to certify the new version.
Diebold (and Sequoia, ES&S, and Hart Intercivic) will happily build and deploy any technologies that municipalities will pay for.
Yes, because as historical elections have shown, paper ballots are tamper-proof. No one has ever been known to rig or steal an election when a paper trail existed.
So, damned if you do, damned if you don't?
The fact is, a paper trail ensures nothing. It can be falsified, albeit with somewhat more difficulty than purely electronic records. Diebold's primary concern shouldn't be a random voter physically tampering with a machine, it should be the people charged with operating and safeguarding the machine. They have access, and as they're working an election, they almost certainly have strong personal political views that could motivate a "correction" of the results.
*Nothing* is ever guaranteed. The key is to arrive at a system that can be ensured to have at least some semblance of accuracy.
But the local county election officials have been the ones running our elections forever, and that hasn't changed. If you're arguing they should prevent tampering with the machines, including *inviting* tampering from third parties (such as was the case here), I'm 100% in agreement.
Sorry, but Diebold has had accessory equipment to add a paper trail at the voting station for at least 18 months. Diebold, like many large contract vendors, doesn't list all of their specific products and components on the web site and instead talks about the systems from a general standpoint.
All three major electronic voting manufacturers already have the ability to add permanent, individual voter-verified paper audit trails to their products. Don't believe people who make it seem like companies like Diebold are resisting. They aren't. They'll build - and sell - whatever municipalities will buy.
The roadblock, as it turns out, is often local election boards. First, the new paper verification systems NEED to go through the government certification process - remember, it's the e-voting watchdogs who are chastising non-certified patches/updates being put into place; the paper audit systems need to go through the same certification process. Further, many municipalities can't understand why they should be forcing paper audit trails; after all, they think, they are just getting away from paper ballots - why should they be arguing for paper ballots (and all the headaches that go along with them, ON TOP of the headaches they already have from learning to deal with e-voting), when they just got away from it?
Since EVERY SINGLE VOTER who uses these machines is a potential hacker looking to alter election results, why is Diebold so concerned?
Because EVERY SINGLE VOTER isn't allowed a level of access to the machines to presumably perform an audit or otherwise tamper with and/or view the inner workings of the machines.
The solution is quite simple:
- Have a permanent, voter verifiable, auditable, and recountable paper trail (a feature Diebold and ES&S both offer)
- Have an open source system (which actually isn't at all required if the above condition is met)
Where did the information come from? The statute:
(a)(1) Each advisory committee meeting shall be open to the public.
(2) Except when the President determines otherwise for reasons of national security, timely
notice of each such meeting shall be published in the Federal Register, and the Adminis-
trator shall prescribe regulations to provide for other types of public notice to insure that all
interested persons are notified of such meeting prior thereto.
(3) Interested persons shall be permitted to attend, appear before, or file statements with
any advisory committee, subject to such reasonable rules or regulations as the Administra-
tor may prescribe.
FACA makes it very clear that closed meetings can be held, and that public notice must be given of such meetings. That's it.
In an emergent situation where a closed meeting is required, waiting for it to get into the Federal Register or newspapers is ridiculous and unnecessary. Ample public notice can be given by other channels in 2006 that weren't possible in 1972.
If you argue that not only notice, but time to bring a court challenge, is what is required, then I may agree with your line of reasoning. However, I also believe that sometimes emergency meetings of federal advisory committees may be needed without excessive lead time.
Judging from your post, it sounds like you have no concept of the fact that federal advisory council meetings have been able to be closed for nigh on 34 years, and the only thing that this would change is the generally accepted 15-day notice of the closed meeting to the Federal Register, which isn't even required by the statute. The meeting is still closed, in either instance. 15-day notice or not. How is that "surrendering rights" or "freedom"? Please, explain that to me.
We live in a society based on rule of law and rights tempered with responsibility, including delegated responsibility that we implicitly grant to government. Bottom line? Someone trying to make a mountain out of a molehill. Even the submission makes it appear as if the "new" aspect of this is closed meetings.
Oops. It isn't. Such meetings have been able to be closed for three and a half decades with notice, and with no notice for the prior couple centuries, since there was no requirement for any notice. The "notice" aspect was created to allow for public notification of a closed meeting of an advisory board, so that the public would still have reasonable mechanisms to obtain more information. Note that in the statute, nothing specific is required for notice, other than it be given.
Notice can still be given, and an advisory committee on critical public infrastructure can have a closed meeting when deemed necessary, as it would have been able to since 1776 and 1976. And now, 2006. But without having to arbitrarily wait 15 days between the notice and the closed meeting.
Please note that even with a 15 day notice, there is NO PUBLIC RECOURSE, and no process to open the meeting. It is a NOTICE ONLY. So if you want to trumpet about "rights", why don't you learn what you're talking about first.
Except that meetings of such advisory committees have already been able to be closed to the public for 34 years (and could also be closed to the public with NO notice before that).
FACA stipulated a reasonable notice to the public when a meeting was to be closed, so as to advise the public where additional information may be obtained, or information about when the results of such a meeting may become public, or when future public meetings may occur.
That was in 1972.
The meetings were still closed.
In 2006, there is no reason to give 15 days notice of a closed meeting of a federal advisory board. Ample information can be broadly provided to meet the statue, which specifically states:
(a)(1) Each advisory committee meeting shall be open to the public.
(2) Except when the President determines otherwise for reasons of national security, timely
notice of each such meeting shall be published in the Federal Register, and the Adminis-
trator shall prescribe regulations to provide for other types of public notice to insure that all
interested persons are notified of such meeting prior thereto.
(3) Interested persons shall be permitted to attend, appear before, or file statements with
any advisory committee, subject to such reasonable rules or regulations as the Administra-
tor may prescribe.
Public notice of a closed meeting can reasonably happen a lot more quickly in 2006 than it could in 1972. Remember, the meeting is still closed.
So, your quote isn't very relevant. At all.
Under FACA, such federal advisory meetings can already be closed, and have been able to be closed for over three decades. However, a 15-day public notice must be given for such a closure.
The net result, however, is that the meeting is still closed.
This change allows for the Critical Infrastructure Partnership Advisory Council to have closed meetings in an emergency without giving a 15-day notice that it is going to have a closed meeting.
I think that critical public infrastructure protection outweighs any need for a 15-day notice of a closed meeting.
dada21,
Are you being serious?
The "government" has had weapons that the "citizens" cannot (easily) gain access to for more than a century. How is this different?
Or is this just a pulpit for you since you caught the article early?
(The "government" will ALWAYS have more sophisticated weaponry, because it is pooling the resources of the citizenry to design, develop, build, and purchase such weaponry. Your discussion is interesting for a philosophical debate; nothing more.)
...is no "law" at all.
If the submitter wants to troll about the military, the least he could do is spell Asimov's name correctly.
What makes a "robot"? Progressively more complex machinery has been able to inflict bodily harm, and kill, for quite some time.
No, the "funny part" is that people were aware of it, but later, executive management viewed it as too much of a liability/exposure - this is probably so, from certain perspectives. You can read her thoughts on it here. I routinely do interviews for the press, and have been involved with projects that have received national exposure that aren't strictly UW-related, such as Grants.gov for Mac OS X, a package which Grants.gov and Northrop Grumman now officially distribute themselves.
And appleintelfaq.com and ipodbatteryfaq.com just picked up the default contact information I use on DirectNIC, where other domains I administer for UW are registered. Since they're hosted off campus, have nothing to do with the university, and don't use university DNS, there was never any issue with either domain. I've changed the contact information appropriately.
If you really are affiliated with the university and have something to say to me, why don't you stop by my office or email me instead of anonymously trolling me on slashdot? Thanks!
The real benefit to most people will come from running Windows alongside Mac OS X in a "virtual machine" environment, in a window or even full screen, with, for example, a hotkey to switch back and forth between Mac OS X and Windows. To many users who prefer Mac OS X, particularly in enterprise, academic, and research environments, but who also have the occasional applications (usually administrative) that require Windows, this configuration would be a holy grail of sorts. And in this configuration, Windows wouldn't be running in emulation, but it would be running at essentially the native speed of the underlying hardware (with the exception of graphics and disk I/O performance). It will be *much* faster than any emulation ever has been, and there will no doubt be several open source (qemu, xen, wine) and commercial (vmware, Virtual PC) that will allow running Windows (or Windows software) in various capacities. Intel's Virtualization Technology (VT), allowing multiple operating systems to run in separate hardware "partitions" on one processor, make these prospects even more efficient and exciting from a technical standpoint. That scenario *will* happen; it's only a matter of time of the software coming to the platform now that the Intel Macs are shipping.
As to the question, however, of why someone would want to install Windows directly, or "dual boot", here are some answers:
- Gaming. This is probably the primary reason. Since even virtual machine solutions typically still emulate some aspects of video, to get the full performance Windows still has to be running natively directly on the hardware.
- Best possible performance. For those who want Windows and their Windows applications to run as best as they possibly can, again, running Windows directly is required.
- A desire to run Windows (for whatever reason, whether it be preference, desire, necessity, etc.) on quality Apple hardware, while also having the option to run Mac OS X.
- Other applications for which direct hardware access is required.
- Becuase you can. No reason at all other than to "do it".
There are many other arguments for Apple's x86 transition being a potential trojan horse into environments that otherwise avoided Apple hardware because of requirements for Windows. Being able to run Windows in supported vm environments, such as VMware, could be a huge boon to Mac OS X/Apple adoption in certain sectors. The ability to directly boot Windows, even if officially unsupported by Apple, is also very attractive to some.
Hopefully this answers your questions.
...Amit Singh from IBM and kernelthread.com (slashdotted 16 times for excellent technical articles on various bits of internals of Apple hardware and Mac OS X) has his own legacy boot solution as well. From a rejected submission:
It appears that Amit Singh of IBM Almaden Research Center, of kernelthread.com and author of Mac OS X Internals, has devised a method to allow legacy, or BIOS-based, booting on Intel-based Macs, which they're calling "BAMBIOS". This means operating systems that currently only support legacy booting, such as many Linux distributions that don't yet support EFI, or things like Windows XP and the forthcoming Windows Vista (the 32-bit version of which will lack EFI support), will now be able to run on Intel-based Macs without modification (and completely legally). There is also another solution from "narf2006", described here and shown in this flickr set of photos. narf2006's solution is awaiting verification by Colin for the $12,000 pot. Time to get that MacBook Pro you've been waiting on for the best of both worlds, everyone...
So even if narf2006's solution isn't real, Amit's solution most certainly is, since he has a great deal of credibility. One way or another, we'll all be able to boot Windows directly on our Intel-based Macs.
This will be great news for people interested in Windows gaming on an Intel-based Mac (who really need the direct video access) and/or people who just want to do it NOW; however, a virtualization solution running under Mac OS X, such as VMware or Parallels, will be the real holy grail for most users. Most people don't want/need/care about the highest graphics and I/O performance; just the ability to run Windows side-by-side with Mac OS X at a speed that is more than usable, and to also have some capability to seamlessly share things like clipboards and files between the environments (as a nice VM environment would most certainly do). Not to mention not having to reboot.
In any case, even dual booting will be a welcome capability. It remains to be seen how convoluted the process is...
Also, I just spoke with Colin Nederkoorn (the guy running the contest) moments ago, and narf2006's solution has NOT been submitted to him yet. He said that narf2006 said he's "cleaning it up" and will be submitting it "later this week". So, no one, including Colin, has actually seen this solution working yet. Also, he apparently hasn't been in communication with Amit on the BAMBIOS solution as yet...
For the record, no, the passwords are not the same.
(And for those wondering, the NetID/username is the non-private part of our NetID credential.)
Also, I'd hope that one would also understand that going after other machines in that way is bad form, and doesn't speak to Mac OS X's security (or insecurity), but rather to the practice of having strong/different passwords across multiple secure systems.
Someone should tell the Army to at least have the url http://army.mil/ work. ;-)
(It seems only http://www.army.mil/ works...something about sites are configured like that bugs me.)
That was the IP of the machine before it moved to its new network. As I described in another post, there are two minis, both identical, with one on the new network so the cutover would be transparent.
The new IP is 72.33.255.254, and will remain as such. Once DNS has propagated sufficiently, the original host will go away.
No, my position is not funded or "rewarded" by Apple.
Also, I can't say I've *ever* gotten a "freebie" anything from Apple in 22 years other than a couple of T-shirts. Oh, and a nice pen once. I've also never heard of anyone in enterprise or education getting free flat panels and iPods from Apple (except for the free iPod promotions they've had when people buy certain laptops).
Also, since Mac OS X is used *heavily* in education, particularly at large research universities, and diversity of computing platforms is important to avail faculty, staff, and students of the best resources to do their jobs, I'm sure many are interested in the general security of a typical Mac OS X machine with a couple of typical services running on the internet, especially in the wake of such misleading press coverage of the same. The only interests I represent are those of the University of Wisconsin - Madison.
And yes, this challenge is sanctioned. I'm glad that the University of Wisconsin supports the genuine interests of its faculty, staff, and students, and encourages individual thought, research, discovery, and exploration. That's why it's a great place to be!
I say that on the actual site itself:
Mac OS X is not invulnerable. It, like any other operating system, has security deficiencies in various aspects of the software. Some are technical in nature, and others lend themselves to social engineering trickery. However, the general architecture and design philosophy of Mac OS X, in addition to usage of open source components for most network-accessible services that receive intense peer scrutiny from the community, make Mac OS X a very secure operating system. There have been serious vulnerabilities in Mac OS X that could be taken advantage of; however, most Mac OS X "vulnerabilities" to date have relied on typical trojan social engineering tactics, not genuine vulnerabilities. The recent Safari vulnerability was promptly addressed by Apple, as are any exploits reported to Apple. Apple does a fairly good job with regard to security, and has greatly improved its reporting processes after pressure from institutional Mac OS X users: Apple is responsive to security concerns with Mac OS X, which is one of the most important pieces of the security picture.
The "Mac OS X hacked under 30 minutes" story doesn't mention that local access was granted to the system. While local privilege escalation exploits can certainly be dangerous - and used in conjunction with things like the above Safari exploit - this isn't very informative with regard to the general security of a Mac OS X machine sitting on the Internet.
Of course, I'd have no problem with this if the original article had actually talked about it meaningfully in the context of a local privilege escalation and explored the implications; instead, they just made it sound like you could throw a patched OS X box onto the internet and it'd get owned. The average reader would leave with that *distinct* impression, and most of the subsequent coverage of it talked about it exactly in that fashion.
Mac OS X has had several local privilege escalation vulnerabilities, just as other OSes have had. Apple fixes them when they become known. (Also, and this is another discussion, but what can Apple do if the "hacker's" claims are correct, i.e., that the vulnerability is unknown to Apple? It doesn't prove that Mac OS X is "insecure"; all it "proves" is that open scrutiny is difficult with closed source pieces, and that some people intentionally and knowingly refuse to give vendors a chance to fix problems.)
Corsaire - Securing Mac OS X Tiger
NSA - Mac OS X Security Configuration Guide (not yet updated for Mac OS X 10.4)
Apple - Common Criteria configuration guide
And for the "average joe"?
- Keep your machine patched
- Don't randomly open ports for services you don't use
- Have a personal firewall/router
- Don't run software you don't trust
And this doesn't "prove" anything, except that the initial ZDnet article was totally vague and sensationalistic, making it seem to an average person reading that article that a Mac OS X box could just be "hacked" by being on the internet. That is wrong, and I'm showing that. Simple. It's all explained on http://test.doit.wisc.edu/
Yes, this is approved. But it's getting moved to its own /29 today...unfortunately, that didn't happen before slashdot got to it. ;-)
There is an identical clone of that Mac mini waiting to go on the new network, and our DNS TTL is currently set to 5 minutes, so when the cutover happens, it should be pretty transparent.
And the whole point isn't that the test "isn't the same". This is how most Mac OS X machines will appear to outside entities on the internet. The original article - and definitely before it was updated - left people with the impression that a Mac OS X machine could be owned in 30 minutes just by being connected to the internet, without the user "doing" anything, and the subsequent coverage of this in most press proves it. None speak to the fact that a local account was given, or even explore the implications. What could have been a useful article was useless, vague sensationalism. I updated the bottom of the page this morning:
Update
The ZDnet article has been updated to include the sentence, "Participants were given local client access to the target computer and invited to try their luck." But might it not have been interesting to explore:
- What are the implications of local account access, and under what conditions might a computer be used in that way?
- How can such access normally be obtained? Do home users behind firewalls and with no ports open need to worry?
How can a vendor fix the claimed local privilege escalation vulnerabilities when they are not informed of the issue?
- What are the moral and ethical implications of knowing about allegedly severe vulnerabilities in products, like the "hacker" they interviewed, and actively choosing to NOT give the vendor an opportunity to fix the problem(s)?
- How might a Linux or BSD distribution, other commercial UNIXes, or Windows stand up to a similar challenge, where anyone who wishes is given local account access?
- A discussion about how since much of OS X is closed, this might make it more difficult for the community to discover - and report and fix - potential vulnerabilities in the closed pieces
...and things of that nature, instead of leaving people with the impression that any Mac OS X machine connected to the Internet can be taken over in 30 minutes?