Did you actually expect the government to improve security? These are the same people who keep telling us that the TSA makes us safer. For the most part, congresspeople don't even understand the most basic aspects of meatspace security. How could they possibly understand cybersecurity, which is orders of magnitude more complex? If you asked all of the U.S. Congress what a buffer overflow is, you would probably have fewer than twenty people who could answer the question, and I would not be entirely surprised if not a single one of them could answer it. And I can just about guarantee that none of them could construct even the most basic threat assessment for even the most simple network protocol.
No, Congress will create an organization whose job it is to understand it, but they'll give it a mission statement that is entirely perpendicular to anything that would actually improve cybersecurity. Then, when things don't improve, they'll say that it needs more funding. All the while, they'll be siphoning off hundreds of millions of dollars to overpriced contractors in their districts so that when they leave the public sector, they'll have cushy consulting jobs waiting for them. Sadly, this is the way Congress usually does things. They don't take the time to understand the issues, and instead let a bunch of lobbyists write laws that almost invariably only serve to make the problem worse.
For this reason, government is almost never the answer to this sort of thing. Industry standards bodies are. Until our congresspeople are clueful enough to understand that cybersecurity is fundamentally a problem caused by bugs in software, not a social problem caused by evil, malicious "hackers", they cannot possibly do anything but cause harm. Improving cybersecurity by trying to catch the hackers is like protecting a chicken coop by trying to catch all the wolves in the country. There will always be more wolves. What the coop needs is not traps, but rather walls and fences. Similarly, the only way government can usefully improve cybersecurity is by hiring computer security experts to serve as a cybersecurity swat team that does nothing but review code and software designs upon request from government agencies, private businesses, and open source projects. That level of scrutiny is useful. Anything else is a waste of time, money, and civil liberties, with no hope whatsoever of positively affecting our nation's cybersecurity.
Just keep the government out of the way and the companies themselves will take care of it. No need for worries.
You're half right. The correct solution for cybersecurity is pretty much the same as everything else: let businesses manage their own security, but provide harsh penalties for companies that fail to protect the privacy of their customers' information. For example, if a company's failed security causes your SSN to become available to somebody else, they have to pay someone to provide credit protection services for you for the rest of your life. If a company leaks other types of information that could be used for identity theft, it's a fine of $1000 per account per incident, payable to an account that helps people who are the victims of identity theft as a result. And so on. Then, get the government out of the way, and let the companies find ways to keep from losing their shirts.
Another useful thing the government could do is to expand its program of reviewing open source code (and, ideally, closed source code) for security vulnerabilities. If the systems are secure in the first place, then none of the stupid surveillance crap they're trying to ram down our throats would be useful. The only reason it is even ostensibly useful is that the quality of most code out there ranges from bad to worse....
What the government should not do is use this as an excuse to become more of a nanny state, to require specific security policies, require specific password schemes, require specific... well, pretty much anything. As soon as you do that, you create a homogeneous attack surface in which everybody is equally unprepared for new types of attacks, in which every password is probably shared across every website (because they all have the same standards), etc. Better to have the bad guys regularly demonstrating the flaws of a few weak systems than suddenly demonstrating flaws across every website because they all were forced to use some standardized, government-designed software system. At least if there are choices, people with common sense can lean towards working with companies that do things the right way.
Introduced by a Democrat and co-sponsored by a Republican is a good thing. It might have a better chance of getting through committees and the Senate, even though this looks a lot like election year posturing.
Actually, it's a bad thing. Whenever those two parties agree, only one thing is certain: the American public are going to get screwed. This is one of the worst possible patent reform laws that could realistically be passed. Anyone who truly understands intellectual property would know that the way to prevent patent trolls is through fixing the loopholes that they take advantage of. This means:
Pass laws that strengthen the doctrine of laches so that those who should reasonably have known that patent infringement was taking place have about a one year window to bring a lawsuit, or else they can never sue that particular plaintiff again. Patent trolls almost invariably wait to sue until the alleged patent violator can no longer realistically remove the functionality or engineer around it, and until the alleged patent violator's sales volume is high enough to make it a very expensive case if they lose. Remove that incentive, and you cut trolls off at the knees.
Pass laws that absolutely require a functioning implementation created by the plaintiff, not just a description of that implementation, before the plaintiff actually gains the right to sue. At the core of patent trolling is suing over ideas with no concrete implementations. Remove that ability, and you deal the trolls a death blow.
Pass laws that redefine obviousness more broadly so that if anyone unaffiliated with the patent holder published a paper suggesting a similar solution prior to the earlier of A. the patent approval date or B. the date at which the patent holder first released a product exemplifying the patent, the patent can be invalidated by a simple administrative process. Redefine obviousness to mean "obvious to an expert in the field, given the problem it attempts to solve", not "obvious to a person with average skills, without being told the problem it attempts to solve". This would, of course, eliminate 99% of software patents, but given that 99% of software patents are patently crap, that would undoubtedly be a good improvement.
Pass laws that allow anyone to challenge a patent through an administrative process at any time, by paying a fee not to exceed $100, and by providing evidence of prior art that should have invalidated the patent, had it been considered when the patent was originally evaluated.
Pass laws that mandate a longer public comment period after a patent is published, extending up to the date at which the patent is actually approved, in which the general public is allowed to discuss the patent and submit additional prior art at a convenient website.
Pass laws that reduce the duration of patents depending on the rate of progress in the industry. The software industry goes through complete design cycles every four or five years. If patents lasted only four or five years, it would greatly reduce the ability of a patent to cripple the industry.
Pass laws that limit the ability to sell patents such that a company who buys a patent can only sue over that patent if they continued to manufacture a product or provide a service that exemplified that patent for at least a year or two after the purchase of the patent (or if they are actively manufacturing or providing such a product or service at the time of the lawsuit, during that initial period of time). This greatly reduces the viability of holding companies that exist solely to monetize patents.
Make patents expire automatically if the patent holder ceases to manufacture products or make services available that exemplify the patent for a period of a year or more. This basically eliminates the viability of holding companies that exist solely to monetize patents.
Deregulation of generation has improved reliability and added features like Demand Response to incent demand curtailment.
Deregulation brought us the Enron collapse, rolling blackouts through California, etc. From what I've seen, deregulation has mainly brought us escalating prices and decreasing quality of service.
And demand curtailment isn't beneficial, at least when you're talking about consumers. Businesses have funds to upgrade equipment. Consumers generally don't. Unfortunately, when deregulation causes "features" like Demand Response, the consumers are the ones who invariably get shafted. You don't see businesses cutting their power consumption, for the most part. Instead, you see people coming home to houses that are 90 degrees, and sweating for two or three hours because their air conditioner refuses to turn on.
Thus, you need to build transmission lines to carry the generation from the supply to the demand.
You have to do that anyway. If you don't, eventually, you aren't going to be able to provide power to the customers. Hacks like Demand Response prolong the amount of time we can get by without upgrading the grid, but as the population increases, that will not continue to be enough for very long. That buys us a couple of years—maybe even four or five if you're lucky—but every year that the industry delays upgrading the grid brings us another year closer to rolling blackouts because of insufficient grid capacity, and when it finally does hit the breaking point, there's going to be a lot of finger pointing, but there won't be anything anyone can do, because it takes time to run the additional power lines.
Nothing the government owns/manages is efficient.
Guess that's why the TVA can afford to provide power at an average of 7.9 cents per kWh, while California's privatized power grid that you claim is so wonderful costs around twice that much on average. Or why TVA has consistently beaten the national average by about 20%. But keep telling yourself that government can't possibly do anything efficiently. Maybe if you repeat that lie often enough, some other people might even start to believe you.
Also, changing building codes to require more energy efficient houses and buildings would also greatly improve the capacity of the existing structure.
Only in the very long term. Building code changes only kick in when you are either building a new building or massively renovating an existing one. And most existing buildings that don't meet energy efficiency standards also cannot be easily be retrofitted to comply with them, so short of red-tagging people's homes, even if you mandated energy efficiency in building code, it would take decades to reach even 20% compliance.
Besides, there are some popular home designs that are fundamentally incompatible with energy efficiency requirements—open beam ceilings, for example. You can't just pass laws and demand that everyone design their houses the way you want them to be designed simply because you think protecting power company profits is more important than individual freedom. That's the very definition of corporatism/fascism, and that's what gets us ridiculous laws like bans on standard incandescent bulbs (to artificially prop up the American CFL industry that otherwise couldn't compete with the dirt-cheap cost of traditional bulbs from China, which basically ended up propping up the Chinese CFL industry instead) or plastic grocery bags (ostensibly to reduce plastic waste, but really resulting in local businesses making extra profit by charging 10 cents apiece for paper bags that in most civilized parts of the country, stores give out for free). As a rule, whenever government passes regulations that effectively ban product categories for reasons other than serious safety problems, they've gone off the deep end and need to be reined in.
We've know for a while that the US receives enough sunlight to provide all the power we need.
Yeah. My reaction was, "Oh my gosh! NREL just stated as a fact something that we've all taken for granted as being obviously a fact for at least a couple of decades! Like, wow!"
Dealing with the variability of solar power and it's inability to follow load along with providing storage or other renewable sources to provide power at night.
Either use a worldwide superconducting power grid or use excess power or heat during the day to pump water uphill, spin up flywheels, heat up any number of fluids and store them underground (e.g. molten salt), charge batteries/capacitors, etc. That's a solvable problem. The hard part is to solve it cheaply.
In common usage, the term "cloud" refers to an alternative to setting up servers yourself, in which somebody else maintains all the infrastructure for you so that you don't have to. In principle, you could become a cloud provider, but then other people would presumably be at your mercy. Either way, a private server with a single user is not generally considered to be a cloud. It is just a private server.
India's electricity is provided by a centrally controlled government entity.
I neither said nor implied that India's electric grid was private. India's electric grid is screwed up because their government hasn't spent the money to improve it. Our power grid is screwed up because private industry hasn't improved it. Both methods can fail miserably, and almost invariably do.
That's the whole point of my proposal. TVA is not the government, nor is it a for-profit corporation. It is a government-owned non-profit corporation. By law, its profits must go back into improvements in the grid. This means that it has neither the problems of directly government-run power grids (where improvements take a back seat to the political crisis of the day) nor of corporate-run power grids (where improvements take a back seat to profit distributions).
Yeah. Americans need to take a good look. This is the United States in a few years if the power companies have their way. Want to know why they're so heavily behind forced conservation measures? It's because our power grid is aging, and is not growing at a rate that keeps up with the growth of demand. Worse, instead of improving it as a nonprofit or government-owned utility would, they're giving excess profits to their stockholders while pressuring everyone to do stupid hacks like adding emergency cutoffs on air conditioning so they can let your house hit a hundred degrees to save power, forcing everyone to use those crappy CFL bulbs, paying people to replace their old refrigerators, and other temporary bandaids that merely delay the inevitable, but don't really solve the problem.
What this proves is that for-profit corporations simply cannot be trusted to maintain such a critical resource. Their natural tendency is to operate on razor-thin margins to turn maximum profit. When they screw up, the government ends up declaring a state of emergency and paying for the losses, so having that infrastructure in private hands is basically nothing more than government subsidizing a bunch of wealthy fat cats on Wall Street. Wouldn't it be nice if instead of paying Wall Street billionaires, the government instead spent that money to actually improve the power grid?
We need to convince the U.S. government that this is an important problem to solve now, before we have more widespread blackouts that take out a huge swath of the U.S. like the one last September in southern California, Arizona, and parts of Mexico. The only way that's going to happen is if our government steps up to the plate and builds a government-owned and government-managed power infrastructure. What we need is the nationwide equivalent of TVA, but with a network of modern, superconducting power lines crisscrossing the country.
UNIX isn't 20 years old. UNIX is over 40 years old...
That was an arbitrary number, and was not intended to imply that UNIX had only been around for twenty years. The point of that number was to show that naïve users are not a new problem in the UNIX world.
And, if the percentage of developers who are malicious is constant (or increases over time), the more developers, the more malicious developers.
True, but protecting against malicious apps isn't the intended purpose of sandboxing. A malicious app, given a choice, would probably not choose to ship as a sandboxed app in the first place.
Besides, if the percentage of developers who are malicious is constant, the percentage of users who happen to choose the malicious app should at best remain constant. And the more apps you have out there, the harder it will be to come up with a trojan that looks different enough from other apps with great reviews to convince people to try it. That should actually reduce the percentage of people affected by malicious apps. And increasing the number of apps should also decrease the percentage of users successfully attacked by buffer overflow exploits and similar, because of wider technodiversity.
To the extent that the percentage of developers who are malicious increases over time, that breaks the equation, but such a change is likely to be caused by the targets becoming juicier.:-)
O RLY? Not when I started using UNIX. UUCP, for example, didn't show up until V7 in 1979, and most UNIX sites didn't have ARPANET access back then.
Let me restate that more precisely. UNIX boxes being networked is not a recent phenomenon. That said, networking isn't required. The old "Hi, this is Chris from the helpdesk. Could you type a diagnostic command on your terminal for me? Okay. Type rm -rf *" prank dates back as far as I can remember, and is in part caused by a lack of privilege separation between different tasks that the user can perform.:-)
So are you saying the Multics folks should have anticipated drive-by downloads?
No, and I'm not saying that the UNIX designers necessarily should have, either. What I'm saying is that the weaknesses were always there; they simply weren't known or fully understood, and they didn't matter all that much because there weren't enough malicious coders looking for them.
But it is none the less weird that if dialysis was invented today, it would be considered a drug under than doctrine.
Not really. Any time you're connecting a device into somebody's veins or putting liquids into somebody's chest cavity, the government should regulate the safety and efficacy of the treatment. It's not like we're talking about foot massages here....
...in a world with lots more application developers, more naive users, and access to the Intertubes being common, it's not so good any more.
I'm not sure I agree with that. There were always a high percentage of naïve users. I remember the UNIX users of a couple of decades back, and sure, some of us were compiling our own tools and stuff, but 90% of them were just professors running PINE (which had at least a couple of remote security holes over the years). And the larger number of developers actually makes things better, not worse. The more apps that serve a particular purpose, the fewer users that use any one of them, and thus the fewer users that will be affected by an attack on it. And UNIX boxes were almost always networked.
What's different now is not so much that the security model is no longer adequate, but rather that the target has become juicier, so it is now worth attacking UNIX users where it was not worth bothering with them before. Twenty years ago, if you cracked access to a UNIX box as an ordinary user, you pretty much got the ability to read one person's email, impersonate that person on ytalk, and once in a blue moon, maybe find something slightly interesting, but most of the time, you'd fail. So if you cracked a UNIX box, you tried to get root access because you usually needed to look through dozens or even hundreds of accounts to find anything of value.
These days, that same ordinary user account is now the sole account on somebody's home computer, and it nets you the user's bank account info, personal files, and the ability to inject code into the user's web browser to let you sniff his or her login passwords. And that user is probably now doing his or her banking online, which wasn't even a possibility twenty years ago. And now instead of a security hole affecting tens or hundreds of thousands of users, it could potentially affect hundreds of millions.
If anything, the risk of most types of exploit is lower now than twenty years ago because far less code is written in pure C, which reduces the risk of buffer overflows pretty dramatically. The problem is, it only takes one mistake, and because the stakes are so much higher, there are lot more people looking for that one mistake....:-)
Yeah. They get to climb into a real shuttle for a test firing. And every now and then, a little robot decides to launch them into orbit with no oxygen, food, or long-range communications gear.
I am sure I read all the documentation last year, I didn't remember anything about security-scoped bookmarks. Thank you for the tip I will look into it.
They weren't added until 10.7.3. They added a lot of enhancements to sandboxing in various Lion software updates. If you are basing your opinion of sandboxing on what existed way back at 10.7.0, you probably should go back and read the updated documentation.
As for screenshots, preferences and stuff I will need to make something that submits the data to a webpage or something, since you can't launch mail with those files I think.
Possibly correct. That said, launching Mail is probably the wrong way to do it anyway unless you want the user mucking with the message on the way to you.:-D
So attackers then target that daemon as it has system-wide access? Marvellous.
First, it's running as the user, just outside the sandbox. Second, it has a very small attack surface—all it does is accept a request for either a load dialog or a save dialog—which should make it very difficult to attack. Third, it is not a daemon in the traditional sense. You cannot connect to it except from a process running as the user. Thus, it should not be possible to compromise it until after you have already compromised some other process running as the user.
It's actually pretty straightforward. The UNIX security model sucks. It assumes that attacks come from the outside, and is designed to protect the user from other users on the same system. In the UNIX model, everything run by a particular user has the same rights as the user. In practice, that just isn't a viable security model anymore.
Consider this scenario: you have a web browser. When everything is working, you trust that the browser is not malicious, so you run it as yourself. Later, you go to a web page and, because of a bug in that browser, somebody is able to execute arbitrary code. Under the UNIX model, that browser can send all your files to a server in Croatia, encrypt them, and extort money from you in exchange for getting your data back.
The only way to prevent such a scenario in a traditional UNIX permission system is to run each application as a separate user. That might be practical for a power user, but it would be insane for most folks. And if you ever wanted to open that JPEG file that you saved with the web browser, you'd have to go in and either change the owner (Finder running as root is a terrifying thought) or set really scary ACLs. No matter how you cut it, that's not user-friendly.
A modern security model must be fundamentally built on the principle of distrust. Distrust everything. Any app could potentially become malicious at any time, whether because the app developer put in a backdoor or because somebody exploited a buffer overflow. It is, therefore, the responsibility of the operating system to not only protect the user from other users on the system, but also from flaws in other applications being run by the same user.
The result is a sandboxing model, in which applications are allowed to open only files that the user has explicitly authorized them to open. Although the user sees a standard file open dialog, when running in a sandbox, the application is not in charge of displaying that dialog. Instead, a system daemon called pboxd (the "powerbox daemon") displays the dialog. When the user chooses to allow that application access to a resource, that daemon then extends the application's sandbox to allow access to that file. In this way, the application has access to exactly the files or folders to which the user has granted it access. No more, no less.
Such a security model is really the only sane security model you can come up with. By using user intent rather than an arcane set of permissions, the user is able to open files in whatever application the user chooses, trusting the operating system to ensure that those applications do not have access to files that the user has not allowed those applications to open. This significantly reduces the benefits gained from attacking security holes in an application.
That's not to say that some apps don't need broader access (e.g. Finder), but it is a worthwhile goal to minimize the number of apps with that level of access, as they are the juiciest targets for attack.
Did you know there is no setting which allows an application to write files in a user selected folder, no you have to ask the user for every file to save manually.
That's not true at all. The standard com.apple.security.files.user-selected.read-write entitlements can handle that very easily. All you have to do is use a standard open dialog to let the user choose a folder, and then write arbitrary crap into that folder or any subfolder within it. Then, save a security-scoped bookmark to that folder if you need to retain access to that folder on future launches. Where things get awkward with that arrangement is when the user copies those files to another machine or restores from a backup. At that point, you'll have to ask the user to open the folder containing the file "foo.wav" or whatever. Then, you can scour the files in there, create security-scoped bookmarks for all of them, and repeat for any other folders full of files.
A much better solution for that problem is to store each project in a self-contained bundle (a folder with an extension, e.g. a.rtfd file, as supported by TextEdit). If you do that, everything just magically works, because instead of opening a project file, the user is opening a folder that contains everything related to a given project. For obvious reasons, that approach is strongly recommended unless you absolutely have to reference files outside of the project for some reason.
Also I want to make screenshots and mail the screenshot,preferences file and log file to me, when the user has a problem he likes me to look at.
That isn't allowed because you aren't allowed to see other apps' windows. It would be a fairly serious security violation if an app could take pictures of other apps that are running and then mail them to the app developer. The same goes for log files that contain data from other applications, preferences files written by other applications, etc. However, there is no reason you can't capture an image of each of your own windows, store a copy of your own log messages in your own file, or send your own preferences file.
But magnetic Buckyballs are not inherently unsafe. They are inherently unsafe for small children. Same as darts, marbles, balloons, plastic bags inside products, gumballs, and hundreds of other things that have no real utility. Targeting this one product while not banning all of those other products I listed above is a clear example of a double standard.
The CPSC is wrong. There's no grey area here. The product is plainly labeled. I present to you Exhibit A. As you can plainly see, almost half of one side of the box is a giant warning label telling people:
Keep Away From All Children!!
Do not put in nose or mouth.
Swallowed magnets can stick to
intestines causing serious injury or death.
Seek immediate medical attention if
magnets are swallowed or inhaled.
I'm sorry, but you really can't get much more clear than that. If the parents truly did not know about this risk, then they were grossly negligent in their use of the product. Period. Countless legal cases have upheld the principle that a manufacturer cannot be held responsible for harm caused when a product is used in a grossly negligent way. I can't believe you're seriously arguing to the contrary.
Sorry, my bad. You're right. The middle setting is the default setting. So the original poster wasn't correct, even by default, even for newly downloaded apps.
That's not a citation. That's a book of thousands of cases, and in all likelihood none of them are relevant case law, given the nature of the product in question. Show me one instance where all of the following are true:
The product was intended for use by adults.
It was unsafe for use by small children.
The reason it was unsafe for small children was not due to a trivial flaw in construction or design that could easily be rectified (e.g. kids choking on a knob that should have been fastened on better), but rather was an inherent property of the product.
The product's labeling clearly indicated that the product was unsafe for children.
The product could fairly easily be kept away from small children (as opposed to lawn darts, which tend to fall where they want to fall).
The product was banned anyway even though there were zero reports of deaths attributed to the product.
This is a matter of settled law. Juries and judges don't agree with you.
Citation needed. To the best of my knowledge, the opposite is true. Product liability law requires clear labeling of toys, precisely because not all toys are appropriate to have around small children.
Dart sets, air rifles, go-karts, balloons, Easy-Bake ovens, anything with parts of the right size to cause choking, anything wrapped in a plastic bag—these are all examples of products that are intended for adults or older children that are legal to sell because they're clearly marketed as such, but that could cause serious injuries (and in some cases, even death) in the hands of small children. How can you justify targeting a single product that meets those criteria while allowing all the rest? Or are you arguing that we have to live in a padded world with no risks?
For most users upgrading from a previous OS, the vast majority of the apps loaded by the system won't have been signed by Apple, but will still load. That makes the statement pretty much completely wrong. As I said, the check only occurs at first launch of a given app, not every launch, so once you have done the whole control-click thing to force it to let you launch a new app, you can freely run apps that are not signed by Apple, even when in the strictest Gatekeeper mode.
Also, the fact that Gatekeeper can be turned on (in the more lax mode) while still allowing apps not signed by Apple to launch (even when you just downloaded them) makes that statement even more wrong.
For a non-power-user who doesn't want to learn about Gatekeeper and security, and who has no non-Mac-App-Store applications installed, yes, the original poster's description was a good first approximation, but it is a drastic oversimplification that, if spoken to a power user, could lead those folks to knee-jerk disable Gatekeeper, which would weaken their security for no good reason. For those reasons, such oversimplifications, at least on a tech site, are dangerously wrong.:-)
Slashdot Mirror
I think you just the whole thing.
Did you actually expect the government to improve security? These are the same people who keep telling us that the TSA makes us safer. For the most part, congresspeople don't even understand the most basic aspects of meatspace security. How could they possibly understand cybersecurity, which is orders of magnitude more complex? If you asked all of the U.S. Congress what a buffer overflow is, you would probably have fewer than twenty people who could answer the question, and I would not be entirely surprised if not a single one of them could answer it. And I can just about guarantee that none of them could construct even the most basic threat assessment for even the most simple network protocol.
No, Congress will create an organization whose job it is to understand it, but they'll give it a mission statement that is entirely perpendicular to anything that would actually improve cybersecurity. Then, when things don't improve, they'll say that it needs more funding. All the while, they'll be siphoning off hundreds of millions of dollars to overpriced contractors in their districts so that when they leave the public sector, they'll have cushy consulting jobs waiting for them. Sadly, this is the way Congress usually does things. They don't take the time to understand the issues, and instead let a bunch of lobbyists write laws that almost invariably only serve to make the problem worse.
For this reason, government is almost never the answer to this sort of thing. Industry standards bodies are. Until our congresspeople are clueful enough to understand that cybersecurity is fundamentally a problem caused by bugs in software, not a social problem caused by evil, malicious "hackers", they cannot possibly do anything but cause harm. Improving cybersecurity by trying to catch the hackers is like protecting a chicken coop by trying to catch all the wolves in the country. There will always be more wolves. What the coop needs is not traps, but rather walls and fences. Similarly, the only way government can usefully improve cybersecurity is by hiring computer security experts to serve as a cybersecurity swat team that does nothing but review code and software designs upon request from government agencies, private businesses, and open source projects. That level of scrutiny is useful. Anything else is a waste of time, money, and civil liberties, with no hope whatsoever of positively affecting our nation's cybersecurity.
You're half right. The correct solution for cybersecurity is pretty much the same as everything else: let businesses manage their own security, but provide harsh penalties for companies that fail to protect the privacy of their customers' information. For example, if a company's failed security causes your SSN to become available to somebody else, they have to pay someone to provide credit protection services for you for the rest of your life. If a company leaks other types of information that could be used for identity theft, it's a fine of $1000 per account per incident, payable to an account that helps people who are the victims of identity theft as a result. And so on. Then, get the government out of the way, and let the companies find ways to keep from losing their shirts.
Another useful thing the government could do is to expand its program of reviewing open source code (and, ideally, closed source code) for security vulnerabilities. If the systems are secure in the first place, then none of the stupid surveillance crap they're trying to ram down our throats would be useful. The only reason it is even ostensibly useful is that the quality of most code out there ranges from bad to worse....
What the government should not do is use this as an excuse to become more of a nanny state, to require specific security policies, require specific password schemes, require specific... well, pretty much anything. As soon as you do that, you create a homogeneous attack surface in which everybody is equally unprepared for new types of attacks, in which every password is probably shared across every website (because they all have the same standards), etc. Better to have the bad guys regularly demonstrating the flaws of a few weak systems than suddenly demonstrating flaws across every website because they all were forced to use some standardized, government-designed software system. At least if there are choices, people with common sense can lean towards working with companies that do things the right way.
Actually, it's a bad thing. Whenever those two parties agree, only one thing is certain: the American public are going to get screwed. This is one of the worst possible patent reform laws that could realistically be passed. Anyone who truly understands intellectual property would know that the way to prevent patent trolls is through fixing the loopholes that they take advantage of. This means:
Deregulation brought us the Enron collapse, rolling blackouts through California, etc. From what I've seen, deregulation has mainly brought us escalating prices and decreasing quality of service.
And demand curtailment isn't beneficial, at least when you're talking about consumers. Businesses have funds to upgrade equipment. Consumers generally don't. Unfortunately, when deregulation causes "features" like Demand Response, the consumers are the ones who invariably get shafted. You don't see businesses cutting their power consumption, for the most part. Instead, you see people coming home to houses that are 90 degrees, and sweating for two or three hours because their air conditioner refuses to turn on.
You have to do that anyway. If you don't, eventually, you aren't going to be able to provide power to the customers. Hacks like Demand Response prolong the amount of time we can get by without upgrading the grid, but as the population increases, that will not continue to be enough for very long. That buys us a couple of years—maybe even four or five if you're lucky—but every year that the industry delays upgrading the grid brings us another year closer to rolling blackouts because of insufficient grid capacity, and when it finally does hit the breaking point, there's going to be a lot of finger pointing, but there won't be anything anyone can do, because it takes time to run the additional power lines.
Guess that's why the TVA can afford to provide power at an average of 7.9 cents per kWh, while California's privatized power grid that you claim is so wonderful costs around twice that much on average. Or why TVA has consistently beaten the national average by about 20%. But keep telling yourself that government can't possibly do anything efficiently. Maybe if you repeat that lie often enough, some other people might even start to believe you.
Only in the very long term. Building code changes only kick in when you are either building a new building or massively renovating an existing one. And most existing buildings that don't meet energy efficiency standards also cannot be easily be retrofitted to comply with them, so short of red-tagging people's homes, even if you mandated energy efficiency in building code, it would take decades to reach even 20% compliance.
Besides, there are some popular home designs that are fundamentally incompatible with energy efficiency requirements—open beam ceilings, for example. You can't just pass laws and demand that everyone design their houses the way you want them to be designed simply because you think protecting power company profits is more important than individual freedom. That's the very definition of corporatism/fascism, and that's what gets us ridiculous laws like bans on standard incandescent bulbs (to artificially prop up the American CFL industry that otherwise couldn't compete with the dirt-cheap cost of traditional bulbs from China, which basically ended up propping up the Chinese CFL industry instead) or plastic grocery bags (ostensibly to reduce plastic waste, but really resulting in local businesses making extra profit by charging 10 cents apiece for paper bags that in most civilized parts of the country, stores give out for free). As a rule, whenever government passes regulations that effectively ban product categories for reasons other than serious safety problems, they've gone off the deep end and need to be reined in.
N
Yeah. My reaction was, "Oh my gosh! NREL just stated as a fact something that we've all taken for granted as being obviously a fact for at least a couple of decades! Like, wow!"
Either use a worldwide superconducting power grid or use excess power or heat during the day to pump water uphill, spin up flywheels, heat up any number of fluids and store them underground (e.g. molten salt), charge batteries/capacitors, etc. That's a solvable problem. The hard part is to solve it cheaply.
In common usage, the term "cloud" refers to an alternative to setting up servers yourself, in which somebody else maintains all the infrastructure for you so that you don't have to. In principle, you could become a cloud provider, but then other people would presumably be at your mercy. Either way, a private server with a single user is not generally considered to be a cloud. It is just a private server.
I neither said nor implied that India's electric grid was private. India's electric grid is screwed up because their government hasn't spent the money to improve it. Our power grid is screwed up because private industry hasn't improved it. Both methods can fail miserably, and almost invariably do.
That's the whole point of my proposal. TVA is not the government, nor is it a for-profit corporation. It is a government-owned non-profit corporation. By law, its profits must go back into improvements in the grid. This means that it has neither the problems of directly government-run power grids (where improvements take a back seat to the political crisis of the day) nor of corporate-run power grids (where improvements take a back seat to profit distributions).
Indeed. It's a battle of Wils.
Yeah. Americans need to take a good look. This is the United States in a few years if the power companies have their way. Want to know why they're so heavily behind forced conservation measures? It's because our power grid is aging, and is not growing at a rate that keeps up with the growth of demand. Worse, instead of improving it as a nonprofit or government-owned utility would, they're giving excess profits to their stockholders while pressuring everyone to do stupid hacks like adding emergency cutoffs on air conditioning so they can let your house hit a hundred degrees to save power, forcing everyone to use those crappy CFL bulbs, paying people to replace their old refrigerators, and other temporary bandaids that merely delay the inevitable, but don't really solve the problem.
What this proves is that for-profit corporations simply cannot be trusted to maintain such a critical resource. Their natural tendency is to operate on razor-thin margins to turn maximum profit. When they screw up, the government ends up declaring a state of emergency and paying for the losses, so having that infrastructure in private hands is basically nothing more than government subsidizing a bunch of wealthy fat cats on Wall Street. Wouldn't it be nice if instead of paying Wall Street billionaires, the government instead spent that money to actually improve the power grid?
We need to convince the U.S. government that this is an important problem to solve now, before we have more widespread blackouts that take out a huge swath of the U.S. like the one last September in southern California, Arizona, and parts of Mexico. The only way that's going to happen is if our government steps up to the plate and builds a government-owned and government-managed power infrastructure. What we need is the nationwide equivalent of TVA, but with a network of modern, superconducting power lines crisscrossing the country.
That was an arbitrary number, and was not intended to imply that UNIX had only been around for twenty years. The point of that number was to show that naïve users are not a new problem in the UNIX world.
True, but protecting against malicious apps isn't the intended purpose of sandboxing. A malicious app, given a choice, would probably not choose to ship as a sandboxed app in the first place.
Besides, if the percentage of developers who are malicious is constant, the percentage of users who happen to choose the malicious app should at best remain constant. And the more apps you have out there, the harder it will be to come up with a trojan that looks different enough from other apps with great reviews to convince people to try it. That should actually reduce the percentage of people affected by malicious apps. And increasing the number of apps should also decrease the percentage of users successfully attacked by buffer overflow exploits and similar, because of wider technodiversity.
To the extent that the percentage of developers who are malicious increases over time, that breaks the equation, but such a change is likely to be caused by the targets becoming juicier. :-)
Let me restate that more precisely. UNIX boxes being networked is not a recent phenomenon. That said, networking isn't required. The old "Hi, this is Chris from the helpdesk. Could you type a diagnostic command on your terminal for me? Okay. Type rm -rf *" prank dates back as far as I can remember, and is in part caused by a lack of privilege separation between different tasks that the user can perform. :-)
No, and I'm not saying that the UNIX designers necessarily should have, either. What I'm saying is that the weaknesses were always there; they simply weren't known or fully understood, and they didn't matter all that much because there weren't enough malicious coders looking for them.
Not really. Any time you're connecting a device into somebody's veins or putting liquids into somebody's chest cavity, the government should regulate the safety and efficacy of the treatment. It's not like we're talking about foot massages here....
I'm not sure I agree with that. There were always a high percentage of naïve users. I remember the UNIX users of a couple of decades back, and sure, some of us were compiling our own tools and stuff, but 90% of them were just professors running PINE (which had at least a couple of remote security holes over the years). And the larger number of developers actually makes things better, not worse. The more apps that serve a particular purpose, the fewer users that use any one of them, and thus the fewer users that will be affected by an attack on it. And UNIX boxes were almost always networked.
What's different now is not so much that the security model is no longer adequate, but rather that the target has become juicier, so it is now worth attacking UNIX users where it was not worth bothering with them before. Twenty years ago, if you cracked access to a UNIX box as an ordinary user, you pretty much got the ability to read one person's email, impersonate that person on ytalk, and once in a blue moon, maybe find something slightly interesting, but most of the time, you'd fail. So if you cracked a UNIX box, you tried to get root access because you usually needed to look through dozens or even hundreds of accounts to find anything of value.
These days, that same ordinary user account is now the sole account on somebody's home computer, and it nets you the user's bank account info, personal files, and the ability to inject code into the user's web browser to let you sniff his or her login passwords. And that user is probably now doing his or her banking online, which wasn't even a possibility twenty years ago. And now instead of a security hole affecting tens or hundreds of thousands of users, it could potentially affect hundreds of millions.
If anything, the risk of most types of exploit is lower now than twenty years ago because far less code is written in pure C, which reduces the risk of buffer overflows pretty dramatically. The problem is, it only takes one mistake, and because the stakes are so much higher, there are lot more people looking for that one mistake.... :-)
Could Mars have oil? Film at 11.
Yeah. They get to climb into a real shuttle for a test firing. And every now and then, a little robot decides to launch them into orbit with no oxygen, food, or long-range communications gear.
No, wait....
They weren't added until 10.7.3. They added a lot of enhancements to sandboxing in various Lion software updates. If you are basing your opinion of sandboxing on what existed way back at 10.7.0, you probably should go back and read the updated documentation.
Possibly correct. That said, launching Mail is probably the wrong way to do it anyway unless you want the user mucking with the message on the way to you. :-D
First, it's running as the user, just outside the sandbox. Second, it has a very small attack surface—all it does is accept a request for either a load dialog or a save dialog—which should make it very difficult to attack. Third, it is not a daemon in the traditional sense. You cannot connect to it except from a process running as the user. Thus, it should not be possible to compromise it until after you have already compromised some other process running as the user.
It's actually pretty straightforward. The UNIX security model sucks. It assumes that attacks come from the outside, and is designed to protect the user from other users on the same system. In the UNIX model, everything run by a particular user has the same rights as the user. In practice, that just isn't a viable security model anymore.
Consider this scenario: you have a web browser. When everything is working, you trust that the browser is not malicious, so you run it as yourself. Later, you go to a web page and, because of a bug in that browser, somebody is able to execute arbitrary code. Under the UNIX model, that browser can send all your files to a server in Croatia, encrypt them, and extort money from you in exchange for getting your data back.
The only way to prevent such a scenario in a traditional UNIX permission system is to run each application as a separate user. That might be practical for a power user, but it would be insane for most folks. And if you ever wanted to open that JPEG file that you saved with the web browser, you'd have to go in and either change the owner (Finder running as root is a terrifying thought) or set really scary ACLs. No matter how you cut it, that's not user-friendly.
A modern security model must be fundamentally built on the principle of distrust. Distrust everything. Any app could potentially become malicious at any time, whether because the app developer put in a backdoor or because somebody exploited a buffer overflow. It is, therefore, the responsibility of the operating system to not only protect the user from other users on the system, but also from flaws in other applications being run by the same user.
The result is a sandboxing model, in which applications are allowed to open only files that the user has explicitly authorized them to open. Although the user sees a standard file open dialog, when running in a sandbox, the application is not in charge of displaying that dialog. Instead, a system daemon called pboxd (the "powerbox daemon") displays the dialog. When the user chooses to allow that application access to a resource, that daemon then extends the application's sandbox to allow access to that file. In this way, the application has access to exactly the files or folders to which the user has granted it access. No more, no less.
Such a security model is really the only sane security model you can come up with. By using user intent rather than an arcane set of permissions, the user is able to open files in whatever application the user chooses, trusting the operating system to ensure that those applications do not have access to files that the user has not allowed those applications to open. This significantly reduces the benefits gained from attacking security holes in an application.
That's not to say that some apps don't need broader access (e.g. Finder), but it is a worthwhile goal to minimize the number of apps with that level of access, as they are the juiciest targets for attack.
That's not true at all. The standard com.apple.security.files.user-selected.read-write entitlements can handle that very easily. All you have to do is use a standard open dialog to let the user choose a folder, and then write arbitrary crap into that folder or any subfolder within it. Then, save a security-scoped bookmark to that folder if you need to retain access to that folder on future launches. Where things get awkward with that arrangement is when the user copies those files to another machine or restores from a backup. At that point, you'll have to ask the user to open the folder containing the file "foo.wav" or whatever. Then, you can scour the files in there, create security-scoped bookmarks for all of them, and repeat for any other folders full of files.
A much better solution for that problem is to store each project in a self-contained bundle (a folder with an extension, e.g. a .rtfd file, as supported by TextEdit). If you do that, everything just magically works, because instead of opening a project file, the user is opening a folder that contains everything related to a given project. For obvious reasons, that approach is strongly recommended unless you absolutely have to reference files outside of the project for some reason.
That isn't allowed because you aren't allowed to see other apps' windows. It would be a fairly serious security violation if an app could take pictures of other apps that are running and then mail them to the app developer. The same goes for log files that contain data from other applications, preferences files written by other applications, etc. However, there is no reason you can't capture an image of each of your own windows, store a copy of your own log messages in your own file, or send your own preferences file.
That's almost invariably a sign of either bad laws or bad judges setting bad precedents. Just saying.
But magnetic Buckyballs are not inherently unsafe. They are inherently unsafe for small children. Same as darts, marbles, balloons, plastic bags inside products, gumballs, and hundreds of other things that have no real utility. Targeting this one product while not banning all of those other products I listed above is a clear example of a double standard.
The CPSC is wrong. There's no grey area here. The product is plainly labeled. I present to you Exhibit A. As you can plainly see, almost half of one side of the box is a giant warning label telling people:
I'm sorry, but you really can't get much more clear than that. If the parents truly did not know about this risk, then they were grossly negligent in their use of the product. Period. Countless legal cases have upheld the principle that a manufacturer cannot be held responsible for harm caused when a product is used in a grossly negligent way. I can't believe you're seriously arguing to the contrary.
Sorry, my bad. You're right. The middle setting is the default setting. So the original poster wasn't correct, even by default, even for newly downloaded apps.
That's not a citation. That's a book of thousands of cases, and in all likelihood none of them are relevant case law, given the nature of the product in question. Show me one instance where all of the following are true:
Citation needed. To the best of my knowledge, the opposite is true. Product liability law requires clear labeling of toys, precisely because not all toys are appropriate to have around small children.
Dart sets, air rifles, go-karts, balloons, Easy-Bake ovens, anything with parts of the right size to cause choking, anything wrapped in a plastic bag—these are all examples of products that are intended for adults or older children that are legal to sell because they're clearly marketed as such, but that could cause serious injuries (and in some cases, even death) in the hands of small children. How can you justify targeting a single product that meets those criteria while allowing all the rest? Or are you arguing that we have to live in a padded world with no risks?
For most users upgrading from a previous OS, the vast majority of the apps loaded by the system won't have been signed by Apple, but will still load. That makes the statement pretty much completely wrong. As I said, the check only occurs at first launch of a given app, not every launch, so once you have done the whole control-click thing to force it to let you launch a new app, you can freely run apps that are not signed by Apple, even when in the strictest Gatekeeper mode.
Also, the fact that Gatekeeper can be turned on (in the more lax mode) while still allowing apps not signed by Apple to launch (even when you just downloaded them) makes that statement even more wrong.
For a non-power-user who doesn't want to learn about Gatekeeper and security, and who has no non-Mac-App-Store applications installed, yes, the original poster's description was a good first approximation, but it is a drastic oversimplification that, if spoken to a power user, could lead those folks to knee-jerk disable Gatekeeper, which would weaken their security for no good reason. For those reasons, such oversimplifications, at least on a tech site, are dangerously wrong. :-)