Turn on auditing of access failures for the whole filesystem and the HKLM portion of the Registry, and you may find that the problem is easily solved. It's just that someone was lazy and you have to do a bit of extra work to compensate.
"also allows some applications to run as a regular user instead of administrator."
Huzzah. Probably 90% of the Windows app.s that "need to run as administrator" are that way seemingly because the designer never saw a secure system and doesn't know how to code for one. Of course, reading the Logo Requirements would cure a number of bad habits, but that would extend your time-to-market by almost a day....
I've lost count of the number of "must be administrator" products that run just fine after minor changes to one or two ACLs. Or even just redirecting their internal bookkeeping to an *appropriate* place for users to be allowed to write.
Let's hope that some Third Parties notice this and do likewise.
It's called "single user mode" and it's pretty darned useful from time to time. It's also how all that other stuff gets onto the box in the first place.
You can remain compatible with old software for a long, long time without serious problems *if you plan ahead*. If you just keep throwing more kewl stuff into the box and stacking fix on top of fix on top of fix, well, then, like Ovid said, you get a big pile.
If security had been a part of the design process all along, they wouldn't need such a huge flag day now.
Oh, there's more to it than that. If you're talking about the U.S. government, it was *designed* to be inefficient. Think about it -- would you really want to subject yourself to an *efficient* bureaucracy?
Being able to point the vehicle "backward" was essential to getting home in the Mercury series, since the retro pack was on the back end strapped against the heat shield.
It just means they've got something specific to work on for SpaceShipTwo, plus some revisions to the pilot training. You probably had a few thrilling moments the first time *you* piloted a ship back from space, right?:-)
Seriously, telecoms would like to expand their busines as much as the next guy, and audio/video on demand promise a *huge* increase in bandwidth demand which they can then be paid to supply. DMCA is *so* broad that it's scaring off legitimate business. The telecoms can't have media types running around claiming that any electronic transmission of copyrighted material is illegal and evil -- it's bad for business.
Another way of looking at it is that the telecoms profit from the innovation of others, when they provide carriage for those innovations. So they want others to innovate in ways that generate more demand for the telecoms' services. DMCA is in their way, so they need it pushed *out* of their way. Notice that, as soon as they get the changes *they* want, they'll bow out, so if your interests are not entirely aligned with theirs, begin preparing *now* to take up the slack when that happens.
Stop draggin' my...stop draggin' my...stop draggin' my cow around! [Apologies to Weird Al]
The word is usually rendered "kowtow", although the actual Chinese word's sound is probably unrecognizably different from this if history is any guide.
"Them"? Who is "them"? "Them" is *us*. Look at your next-door neighbors -- they are (some of) the people who grant you the privilege of driving on the streets that you and they pay for and use in common.
Some of your neighbors make bricks, some make automobiles, and some make laws. Don't like the current laws? get a job making better ones.
Depends on how old you are. A long time ago, in a mindset far, far away, the norm used to be:
1. Gather and compose requirements. 2. Write specifications of something meeting those requirements. 3. Write code and documentation in parallel, from specifications. 4. Test, debug, repair code and documentation. Repeat until specifications met. 5. Release. 6. Collect problem reports, neat ideas, etc.; go to step 1 to design next version.
I left out a lot of bits where you go back to the people who wanted something and make sure you're still making what they wanted, but that's basically it: figure out what you need done, write it down in human language, then write code that does what you described.
Notice that coders and tech writers can work independently from the spec.s. This is good, because good coders and good tech writers tend to be personality types that clash frequently. Good spec.s will yield code and documentation that match closely, and any small differences can be ironed out during system testing. (This means that these two classes *do* have to communicate, just not every day.)
This worked well for a long time. Then came the PC revolution. And the PC guys decided to live by the assumption that "everything we know is wrong" and to try to do *everything* differently than it had been done previously. Thus the current design methodlessology:
1. Dream up some kewl gizmo. 2. Code like a maniac until you have something vaguely reminiscent of the original idea. 3. Write down what you remember about how it works until you get tired of writing and decide to skip the remaining details. Marketing or minimally-knowledgable volunteers can pad it out to a respectable length later. 4. Try to convince the world that they need your gizmo, whether they have a use for it or not. 5. Turn your back on your creation to pursue the next gizmo.
My guess is that step 7 is the culprit. You need to be sure that File and Print sharing *never* gets turned on at any interface connected to the outside world. But I wouldn't be at all surprised to find that the automagical network connection setter-upper doesn't bother checking this and doesn't give you the option either.
I'm attempting to cure SBC of good-OS-phobia by always sending detailed log extracts with my tech support requests. It couldn't hurt to give the techies more information than the typical MS "something broke somewhere, na-na na-na-na na!" nonmessage. Maybe someday one of them will convince his supervisor that "these Linux and *BSD guys are supporting *us* -- we should support *them* better."
Oh, it probably won't happen, but it least it won't fail to happen because I failed to try.
Another way to look at this is that there should have been a simple foolproof way to *remove the data and take them away with you*, rendering an instance of Mozilla (or your favorite browser) *unable* to cough up your personal data.
Slashdot Mirror
Turn on auditing of access failures for the whole filesystem and the HKLM portion of the Registry, and you may find that the problem is easily solved. It's just that someone was lazy and you have to do a bit of extra work to compensate.
"also allows some applications to run as a regular user instead of administrator."
Huzzah. Probably 90% of the Windows app.s that "need to run as administrator" are that way seemingly because the designer never saw a secure system and doesn't know how to code for one. Of course, reading the Logo Requirements would cure a number of bad habits, but that would extend your time-to-market by almost a day....
I've lost count of the number of "must be administrator" products that run just fine after minor changes to one or two ACLs. Or even just redirecting their internal bookkeeping to an *appropriate* place for users to be allowed to write.
Let's hope that some Third Parties notice this and do likewise.
Gee, triple-click Button 1 over the URL, single-click Button 2, and you are there. How hard could it be?
It's called "single user mode" and it's pretty darned useful from time to time. It's also how all that other stuff gets onto the box in the first place.
You can remain compatible with old software for a long, long time without serious problems *if you plan ahead*. If you just keep throwing more kewl stuff into the box and stacking fix on top of fix on top of fix, well, then, like Ovid said, you get a big pile.
If security had been a part of the design process all along, they wouldn't need such a huge flag day now.
Oh, there's more to it than that. If you're talking about the U.S. government, it was *designed* to be inefficient. Think about it -- would you really want to subject yourself to an *efficient* bureaucracy?
Cue reference to Asimov's "Trends".
*sigh* Excuse me -- $0.08. *Way* cheaper than the government effort.
Or it's about $0.70 per capita here in the U.S. How much did I pay to get from "what's a rocket" to Freedom 7? Probably a whole lot more than that.
I gather that happens quite often in flight test.
So you have the flight recorder data and can prove that it was coincidence and not, say, skill?
Being able to point the vehicle "backward" was essential to getting home in the Mercury series, since the retro pack was on the back end strapped against the heat shield.
It just means they've got something specific to work on for SpaceShipTwo, plus some revisions to the pilot training. You probably had a few thrilling moments the first time *you* piloted a ship back from space, right? :-)
They are not your friends. They just have interests that you share. They also have interests inimical to yours. That's the way business works.
When they work with you, enjoy the help. When they work against you, fight. Friendship doesn't come into it.
Because if you don't respect my copyright I won't give you any more of my works.
DMCA cuts down on the traffic they can bill for?
Seriously, telecoms would like to expand their busines as much as the next guy, and audio/video on demand promise a *huge* increase in bandwidth demand which they can then be paid to supply. DMCA is *so* broad that it's scaring off legitimate business. The telecoms can't have media types running around claiming that any electronic transmission of copyrighted material is illegal and evil -- it's bad for business.
Another way of looking at it is that the telecoms profit from the innovation of others, when they provide carriage for those innovations. So they want others to innovate in ways that generate more demand for the telecoms' services. DMCA is in their way, so they need it pushed *out* of their way. Notice that, as soon as they get the changes *they* want, they'll bow out, so if your interests are not entirely aligned with theirs, begin preparing *now* to take up the slack when that happens.
"cow-towing"
Stop draggin' my...stop draggin' my...stop draggin' my cow around! [Apologies to Weird Al]
The word is usually rendered "kowtow", although the actual Chinese word's sound is probably unrecognizably different from this if history is any guide.
Hmmm, I read "refused", not as, "gee, officer, I would if I could but I have none on me" but as, "I won't give it to you -- try and make me!"
"I don't have what you want" is not a refusal.
Whether the officer is still an officer a year later, however, is very much connected to the real reason.
"Them"? Who is "them"? "Them" is *us*. Look at your next-door neighbors -- they are (some of) the people who grant you the privilege of driving on the streets that you and they pay for and use in common.
Some of your neighbors make bricks, some make automobiles, and some make laws. Don't like the current laws? get a job making better ones.
Depends on how old you are. A long time ago, in a mindset far, far away, the norm used to be:
1. Gather and compose requirements.
2. Write specifications of something meeting those requirements.
3. Write code and documentation in parallel, from specifications.
4. Test, debug, repair code and documentation. Repeat until specifications met.
5. Release.
6. Collect problem reports, neat ideas, etc.; go to step 1 to design next version.
I left out a lot of bits where you go back to the people who wanted something and make sure you're still making what they wanted, but that's basically it: figure out what you need done, write it down in human language, then write code that does what you described.
Notice that coders and tech writers can work independently from the spec.s. This is good, because good coders and good tech writers tend to be personality types that clash frequently. Good spec.s will yield code and documentation that match closely, and any small differences can be ironed out during system testing. (This means that these two classes *do* have to communicate, just not every day.)
This worked well for a long time. Then came the PC revolution. And the PC guys decided to live by the assumption that "everything we know is wrong" and to try to do *everything* differently than it had been done previously. Thus the current design methodlessology:
1. Dream up some kewl gizmo.
2. Code like a maniac until you have something vaguely reminiscent of the original idea.
3. Write down what you remember about how it works until you get tired of writing and decide to skip the remaining details. Marketing or minimally-knowledgable volunteers can pad it out to a respectable length later.
4. Try to convince the world that they need your gizmo, whether they have a use for it or not.
5. Turn your back on your creation to pursue the next gizmo.
My guess is that step 7 is the culprit. You need to be sure that File and Print sharing *never* gets turned on at any interface connected to the outside world. But I wouldn't be at all surprised to find that the automagical network connection setter-upper doesn't bother checking this and doesn't give you the option either.
Any Roadrunner customers know for sure?
I'm attempting to cure SBC of good-OS-phobia by always sending detailed log extracts with my tech support requests. It couldn't hurt to give the techies more information than the typical MS "something broke somewhere, na-na na-na-na na!" nonmessage. Maybe someday one of them will convince his supervisor that "these Linux and *BSD guys are supporting *us* -- we should support *them* better."
Oh, it probably won't happen, but it least it won't fail to happen because I failed to try.
Another way to look at this is that there should have been a simple foolproof way to *remove the data and take them away with you*, rendering an instance of Mozilla (or your favorite browser) *unable* to cough up your personal data.
Indeed. Look at your SS card. See the legend "not for identification"?