Fancy semantics. If the founding fathers wanted to guarantee you health care it would have been written into the constitution. They had doctors then. They could have formed an anti-disease department. They didn't. Why? Because the governed people of the time would have never stood for it. They were independent and self sufficient. The US didn't have any professional fire fighters until the mid 1800s. The US Marshals were created only after the constitution was signed. In addition, the germ theory of disease dates to 1835, so I can't quite see how doctors in the late 1700s could combat disease when they didn't even know what it was. Yes, they had doctors, but doctors at that time were not particularly effective, and a national health service would not have been particularly useful with the technology available at that time.
So just because a national health service didn't make sense back then, doesn't mean that it doesn't make sense now.
If an ISP can do a man-in-the-middle on HTTPS then anybody can and HTTPS is useless. The whole point is to secure the connection before any data is transmitted, and securing the connection requires a unique certificate. Hm. You may be right. I'd thought that with control of the DNS servers and a random Verisign certificate you might have been able to do something, but not without changing the address bar of the browser. A man in the middle attack is still possible, but it seems rather easily detectable, unless there's some way of doing it I haven't thought of.
And when you can trick the user into executing something, it's trivial to trick him also into giving the malware elevated privileges, provided you promise him something. Send someone a "tool" that promises 20% more speed or ram, but since it has to hook deeply into the system, it will require root privileges.
Yes, you won't fall for it. But the average clueless user? After all, this thingamajig is gonna do something with your system to make it run faster, so it's kinda logic that it will need system privs. The root problem is that computer users don't know what software to trust, and what software not to trust. An experienced computer user would not trust the application you describe, but as you point out, the average clueless user would be suckered right in. So why are we leaving the process of trust as an entirely manual process? The operating system should automatically be able to determine trustworthy programs from untrustworthy ones.
The problem now becomes: how does the OS know what's trustworthy? Linux distros sign their packages, so that you can be reasonably sure they don't contain malware. We could lock down desktops so they only run applications signed by trusted parties. This would increase security, but also severely damage the software ecosystem - imagine if you couldn't produce an application for Windows unless you paid Microsoft a license!
The solution, I think, is to formalise the informal trust network we all have in our heads. I tend to trust the FSF, so if the FSF says that an application isn't malware, I'm inclined to trust it. The FSF might in turn trust Debian, so if Debian trusts something, and I trust the FSF, then by association I trust Debian's word as well. In essense, I'm talking about a distributed trust network. Combine this with a sliding scale of privileges, such that applications that require greater privileges also require greater trust, and you have a security system that is flexible enough to cope with even the most clueless of internet users.
The ISP can still do "man in the middle". The ISP can afford to purchase a crypto key that the typical browser will accept without question. In turn, the ISP can talk to the site (using HTTPS), and then (re)encrypt to the user browser. They can do this in theory. In practice, I suspect they'd have a lot of explaining to do if they did. Performing a man in the middle attack on the channel between a customer and, say, their bank is not going to go down well.
Not to mention that today's "strongly encrypted message" is tomorrow's "barely encrypted message." Not really. There have been algorithms that have been flawed, or key sizes that were naively small, but there haven't been any quantum leaps in decryption. RSA has lasted over 30 years, and is still no closer to being broken.
As you didn't provide any more information regarding those rights for the U.S. Citizen, you are doing the same thing as the Parent Poster. I believe the original post was making the argument that the US Citizen, by actions like this is losing those rights. Or at least in danger of doing so. To quote the original post:
"Land of the Free"
So much for that slogan - The US and China (or even cold war Russia) are not really that different. Whilst there is a dangerous erosion of freedom in the US, it has not ceased to be a democracy, and the First Amendment has not been repealed. One could argue that the US government frequently oversteps its bounds, but at least those bounds still exist. The Chinese government has no such restrictions upon its actions.
Furthermore, the US has yet to ship millions of its citizens to remote gulags, so the original poster's comparison to the USSR is even worse exaggeration.
I don't disagree, I think that encryption is a fine thing, and should be used more often. However, I do not believe that my right to privacy exists regardless of the technological possibilities to interfere with it. You make a good point. Perhaps it is unwise to rely only on technological solutions without also enforcing legal limits. If the government happens upon some way to crack public key encryption, we'd certainly want restrictions on government data-mining in place.
That said, if someone does produce an algorithm that can crack strong encryption in a feasible time frame, I suspect that government snooping of emails would be the least of our worries.
The US and China (or even cold war Russia) are not really that different. When trying to convince people of the dangers of government control, hyperbole like this doesn't help. A US citizen still has considerably more rights than a Chinese citizen.
Also, you can't reasonably expect any privacy in email unless you encrypt its contents.
What you don't seem to understand is that the taking care of its citizens is not one of the government's jobs. The government has at most three jobs: providing for the common defense, maintaining order, and regulating commerce. One could argue that common defense, maintaining order and regulating commerce all fall under the umbrella of "taking care of its citizens". Governments provide police officers to keep their citizens safe from crime, fire departments to keep them safe from fires, armies to keep them safe from foreign powers - so why not a department to keep them safe from disease?
I'd argue that a government has the obligation to protect the liberty and the lives of its citizens. A national health service is one way to fulfill that obligation.
The singularity nuts essentially claim that, (a) it's possible to build a better-than-human AI, and (b) it's possible to get a lot more intelligent than humans currently are.
Neither assertion seems particularly far-fetched to me.
* regular {} blocks instead of semantic whitespace I don't think this fits particularly well into Python's philosophy. {} are largely redundant, and whilst whitespace seems to cause you some issue, I've never had a problem with it. Lamdba's might benefit from this, but any multi-line lambda should be indented anyway, so you might as well use whitespace for that, too.
* non-trivial lambda-statements This would be on my personal wishlist. Maybe some syntactic sugar that would turn this:
* explicit scoping of variables like with the "var"-keyword in Javascript The nonlocal keyword in Python 3000 goes some way to rectifying this. It's not as neat as "var" in my opinion, but I can see why they shied away from explicit declarations.
* ++ and its friends x += 1 is more explicit, and I don't think that many Pythonists would welcome an increment operator.
* ternary statements Already in Python 2.5:
x = a if b else c
* switch statements, preferably supporting strings. I tend to agree with you. A "switch" or "case" statement would be nice, especially if it was like the one in Ruby.
Linus has no intention of licensing the kernel under GPLv3. TiVO doesn't have a problem. That's not what TiVO thinks.
TiVO likely uses some utilities and libraries from the GNU Project, such as glibc and coreutils, and when GNU switches to GPL3, they won't be able to make use of future versions or patches from that source.
Genuine intelligence is built upon the progression of: Gas, liquid, solid, single cell life, plant life, animal life, consciousness...intelligence Even if we are incapable of designing a machine more intelligent than us, what's to stop us using genetic algorithms to evolve artificial life into something that's measurably more intelligent than we are?
Encryption cracking can be relatively parallel, especially with PGP - tell each computer to take a certain set of prime combinations to check. Cracking modern encryption protocols can only be done through improving decryption algorithms, or finding flaws in the encryption process. Brute forcing keys of any significant length isn't feasible, even for Storm Worm.
Screw up? 5 of 8 LoCo servers were hit. They're for use to organize local regional events, translate, and the like. This is the Ubuntu equivalent of getting your LUG webserver hacked. Ah, my mistake. I saw "production servers" in the title, and the story link didn't do anything to disabuse me of my assumption that these were important servers.
The real test is how they react to this, and how they clean up their mess. Everyone screws up, but what separates good people from bad is how they react to problems and screw-ups. I use Ubuntu, and I love it to bits, but let's not make excuses simply because they're a popular open source organisation/community. It was a screw-up of epic proportions, a complete lack of anything remotely resembling competent security, and if any other company messed up this badly, there'd be no shortage of people pointing out how stupid their mistake was.
Even worse, how are you going to restrict every application to certain actions? Is the user supposed to configure the security settings for every single program he installs? I think it's quite possible for an operating system to be both secure and simple to use. Let me outline a hypothetical desktop operating system that deals with security issues in perhaps a more sane and safe manner.
A user downloads an application from a website. Applications in this OS have metadata which states what access they require from the system. In this case, the application requires access to the screensaver graphics API, network access to send and receive data to setiathome.com, and localized disk storage space of no more than 10Mb. Further, each application is cryptographically signed; these signatures are vetted via a web of trust, with the OS set up by default to trusting several dedicated industry security groups, which in turn trust smaller groups, and so forth. Trust is relative, with some organisations trusted more than others.
The user sees this as a screensaver icon superimposed with network traffic arrows. When the user clicks on the icon to install it, they get a human-readable set of significant access categories: in this case, the OS tells the user that it will send and receive data over the internet to setiathome.com, and acts as a screensaver. The application has a reasonable security rating, and combined with its low access requirements, doesn't rate any OS intervention. The user has the option to install, or cancel.
Now consider a malicious hacker, who wishes creates a piece of malware that masquerades as a screensaver, but instead compromises the system and steals the user's financial data. The application requests access to the screensaver API for appearences sake, and requess access to send and receive data to settiathome.com, a fake domain registered by the hacker. This would be enough to fool the casual user, who may not notice the extra 't'.
Unfortunately, the hacker has a problem. His application is going to have a rather low security rating, as he can hardly get his app vetted by anyone who is considered respectable by the trust network. Further, he has to request access to log the user's keystrokes, and for his application to be run constantly in the background, rather than just when the screensaver timeout occurs. The very requirements that the hacker needs to do any damage, are the ones that the OS is never going to grant.
But what if he gets a little smarter? What if he's going a more direct route, sniffing the hard drive for any financial documents? His malware can masquerade as a text editor, which is a plausible excuse to require read and write access to general files. Unfortunately, whilst a text editor might be cleared for normal documents, it won't be for documents that contain sensitive or financial data. But maybe some application is poorly written, and saves financial documents with the wrong security settings. Even in such a case, the malware will be thwarted; text editors typically only need access to the OS's file chooser GUI. Unrestricted file access without user intervention isn't going to impress the OS.
In summary, the trick to good security is, I feel, extremely fine-grained access control combined with a scalable distributed trust network. There are some things in the open source world that approach this ideal, but nothing widely implemented or remotely user friendly. Security just doesn't sell at the moment, and with Windows setting the bar so low, there's little incentive for everyone else to improve.
The only reason XP seems passable, in terms of security, is because the bar is set so low. In general, modern operating system security is absolutely terrible. In fact, the concept of computer security barely even exists outside dedicated server systems. We accept it is both because we have become used to this state of affairs, and because good security is extremely difficult for a layperson to judge. If Microsoft says something is secure, how is the general public to know any different?
For instance, if a user executes an email attachment purporting to be a screensaver, we expect the operating system to be compromised. Why? Anything claiming to be screensaver should not be allowed to do anything but draw pictures on the screen. Goatse should be the worst it's capable of. And yet we live in a world where running a screensaver can root your machine, log your keys and mouse movements, and hand your bank account details to any script kiddie with two braincells. That's not just bad: it's absolutely god-awful.
DRM makes piracy *harder*. Not impossible, just harder, and that's all it takes to be effective.
The problem with DRM is that it's not only effective at slowing piracy, it's effective at locking consumers out of their own content. I'd disagree with this. The cost of breaking DRM is a one time fee for pirates; once an unprotected version of the data has been released, the proverbial genie is out of the proverbial bottle. Large content holders, like the organisations that make up the MPAA, want the benefits of distributing their data across a large range of devices, and to the greatest possible proportion of the public, whilst trying to keep a small set of keys secret and hidden. We have problems securing even dedicated data centres from attack; how likely is it that the MPAA et all can pull off their DRM with flawless security even as they are franchising out the algorithms to dozens of third-party hardware manufacturers?
I doubt that DRM can significantly slow down piracy. Historically, DRM schemes tend to be cracked rather more quickly than the average life-cycle of a storage format, or even the latest summer blockbuster. Indeed, the presence of DRM may even encourage piracy in some quarters; a while ago a game I bought stopped working because I had swapped in a new DVD drive, and rather than mess around with tech support trying to get a new key, it was easier and faster to download a cracked copy of the game over bittorrent.
Guybrush frequently boasts that he can hold his breath for ten minutes. In fact it's the only piratey thing Guybrush is really good at. What?! Sir, that is outright slander!
Sure, at the beginning of the first game Guybrush was rather lacking in piratical skills, but since then he has become a master of swordsmanship on both land and sea, has captained several ships, and has battled with countless pirates, cannibals, the undead and monkeys. If that's not solid pirate material, I don't know what is.
If the unicorn is invisible, how can it be pink? It can't;)
To quote Wikipedia:
The Invisible Pink Unicorn (IPU) is the goddess of a satiric parody religion aimed at theistic beliefs, which takes the form of a unicorn that is paradoxically both invisible and pink. These attributes serve to satirize the contradictions in properties that some attribute to a theistic God.
I guess you don't believe in God, but you can't say he doesn't exist either so get off the high horse. If you'd like to refute that, I'll need proof that something doesn't exist. Have fun with that. One cannot disprove the existence of the Flying Spaghetti Monster, either, or the existence of invisible pink unicorns. The set of disprovable entities is extremely large, and to say that God is at least the equal of a giant pile of sentient pasta is not setting the bar very high.
And my personal favourite - just claim you support Bush. Your reputation would instantly tank. Absolute reputation systems will always have this problem, as in real life, reputation is subjective. Some people believe Bush is a strong leader who is responding decisively to the genuine threat of Islamic terrorism; others believe he is a barely articulate shaved chimp and international war criminal.
Any successful global reputation system would therefore have to be subjective itself, otherwise it would be inaccurate for a considerable number of people. In a relative reputation system, debunking 911 conspiracy theories would earn you negative reputation amongst the conspiracy theorists, but positive reputation amongst those with slightly more common sense.
Functional programming languages describe how a certain problem is structured. Procedural languages describe the steps to solve that problem. For many things like validating forms, applying business rules, etc., that latter is a more straightforward approach. I'd argue it's more a question of mindset. Do you have more experience programming in functional languages, or in procedural ones? If the latter, is it any wonder that programming in a functional language seems more difficult?
Also, perhaps the differences are less pronounced than you think. For instance, in Python, we might write:
def main():
print "What is your name? ",
name = raw_input()
print "Hello " + name
Which could be written in Haskell as:
main = putStr "What is your name? " >> getLine >>= (\name -> putStrLn ("Hello " ++ name))
But with a little syntactic sugar, courtesy of Haskell's do-notation:
main = do
putStr "What is your name? "
name <- getLine
putStrLn ("Hello " ++ name)
More than a passing resemblance to the procedural Python code! So I don't think it's necessarily true that functional languages are less adept at solving these types of problems. I'd agree that Haskell is probably more difficult to learn, especially coming from a procedural background, but I'd say that was more to do with Haskell's type system more than it's functional approach. Haskell's type system is powerful and strict to such a degree that it makes languages like Java look almost weakly typed in comparison, but in return for this extra complexity at compile time, there tend to be far fewer runtime bugs.
Another difference is that the development environments for OO languages are very mature. Creating a GUI using Eclipse, VS.NET or Delphi is as easy as point-and-click. I know of no such environment for Haskell. This is true, however there are several functional languages designed to interoperate with existing environments. Scala, a JVM-based functional language, and F#, a CLI language, are two of the most well known. Scala has a plugin for Eclipse, so one could design a GUI graphically and write the logic in a functional language. I believe something similar is being developed for F# and Visual Studio.
Slashdot Mirror
So just because a national health service didn't make sense back then, doesn't mean that it doesn't make sense now.
Yes, you won't fall for it. But the average clueless user? After all, this thingamajig is gonna do something with your system to make it run faster, so it's kinda logic that it will need system privs. The root problem is that computer users don't know what software to trust, and what software not to trust. An experienced computer user would not trust the application you describe, but as you point out, the average clueless user would be suckered right in. So why are we leaving the process of trust as an entirely manual process? The operating system should automatically be able to determine trustworthy programs from untrustworthy ones.
The problem now becomes: how does the OS know what's trustworthy? Linux distros sign their packages, so that you can be reasonably sure they don't contain malware. We could lock down desktops so they only run applications signed by trusted parties. This would increase security, but also severely damage the software ecosystem - imagine if you couldn't produce an application for Windows unless you paid Microsoft a license!
The solution, I think, is to formalise the informal trust network we all have in our heads. I tend to trust the FSF, so if the FSF says that an application isn't malware, I'm inclined to trust it. The FSF might in turn trust Debian, so if Debian trusts something, and I trust the FSF, then by association I trust Debian's word as well. In essense, I'm talking about a distributed trust network. Combine this with a sliding scale of privileges, such that applications that require greater privileges also require greater trust, and you have a security system that is flexible enough to cope with even the most clueless of internet users.
So much for that slogan - The US and China (or even cold war Russia) are not really that different. Whilst there is a dangerous erosion of freedom in the US, it has not ceased to be a democracy, and the First Amendment has not been repealed. One could argue that the US government frequently oversteps its bounds, but at least those bounds still exist. The Chinese government has no such restrictions upon its actions.
Furthermore, the US has yet to ship millions of its citizens to remote gulags, so the original poster's comparison to the USSR is even worse exaggeration. I don't disagree, I think that encryption is a fine thing, and should be used more often. However, I do not believe that my right to privacy exists regardless of the technological possibilities to interfere with it. You make a good point. Perhaps it is unwise to rely only on technological solutions without also enforcing legal limits. If the government happens upon some way to crack public key encryption, we'd certainly want restrictions on government data-mining in place.
That said, if someone does produce an algorithm that can crack strong encryption in a feasible time frame, I suspect that government snooping of emails would be the least of our worries.
Also, you can't reasonably expect any privacy in email unless you encrypt its contents.
I'd argue that a government has the obligation to protect the liberty and the lives of its citizens. A national health service is one way to fulfill that obligation.
The singularity nuts essentially claim that, (a) it's possible to build a better-than-human AI, and (b) it's possible to get a lot more intelligent than humans currently are. Neither assertion seems particularly far-fetched to me.
Thank you, thank you; I'll be here all night.
TiVO likely uses some utilities and libraries from the GNU Project, such as glibc and coreutils, and when GNU switches to GPL3, they won't be able to make use of future versions or patches from that source.
I'm guessing English is not your first language, because nothing you've written makes the slightest bit of sense.
Either that, or you're a malfunctioning propaganda bot from Skynet </tinfoil-hat>
Gas, liquid, solid, single cell life, plant life, animal life, consciousness...intelligence Even if we are incapable of designing a machine more intelligent than us, what's to stop us using genetic algorithms to evolve artificial life into something that's measurably more intelligent than we are?
A user downloads an application from a website. Applications in this OS have metadata which states what access they require from the system. In this case, the application requires access to the screensaver graphics API, network access to send and receive data to setiathome.com, and localized disk storage space of no more than 10Mb. Further, each application is cryptographically signed; these signatures are vetted via a web of trust, with the OS set up by default to trusting several dedicated industry security groups, which in turn trust smaller groups, and so forth. Trust is relative, with some organisations trusted more than others.
The user sees this as a screensaver icon superimposed with network traffic arrows. When the user clicks on the icon to install it, they get a human-readable set of significant access categories: in this case, the OS tells the user that it will send and receive data over the internet to setiathome.com, and acts as a screensaver. The application has a reasonable security rating, and combined with its low access requirements, doesn't rate any OS intervention. The user has the option to install, or cancel.
Now consider a malicious hacker, who wishes creates a piece of malware that masquerades as a screensaver, but instead compromises the system and steals the user's financial data. The application requests access to the screensaver API for appearences sake, and requess access to send and receive data to settiathome.com, a fake domain registered by the hacker. This would be enough to fool the casual user, who may not notice the extra 't'.
Unfortunately, the hacker has a problem. His application is going to have a rather low security rating, as he can hardly get his app vetted by anyone who is considered respectable by the trust network. Further, he has to request access to log the user's keystrokes, and for his application to be run constantly in the background, rather than just when the screensaver timeout occurs. The very requirements that the hacker needs to do any damage, are the ones that the OS is never going to grant.
But what if he gets a little smarter? What if he's going a more direct route, sniffing the hard drive for any financial documents? His malware can masquerade as a text editor, which is a plausible excuse to require read and write access to general files. Unfortunately, whilst a text editor might be cleared for normal documents, it won't be for documents that contain sensitive or financial data. But maybe some application is poorly written, and saves financial documents with the wrong security settings. Even in such a case, the malware will be thwarted; text editors typically only need access to the OS's file chooser GUI. Unrestricted file access without user intervention isn't going to impress the OS.
In summary, the trick to good security is, I feel, extremely fine-grained access control combined with a scalable distributed trust network. There are some things in the open source world that approach this ideal, but nothing widely implemented or remotely user friendly. Security just doesn't sell at the moment, and with Windows setting the bar so low, there's little incentive for everyone else to improve.
The only reason XP seems passable, in terms of security, is because the bar is set so low. In general, modern operating system security is absolutely terrible. In fact, the concept of computer security barely even exists outside dedicated server systems. We accept it is both because we have become used to this state of affairs, and because good security is extremely difficult for a layperson to judge. If Microsoft says something is secure, how is the general public to know any different?
For instance, if a user executes an email attachment purporting to be a screensaver, we expect the operating system to be compromised. Why? Anything claiming to be screensaver should not be allowed to do anything but draw pictures on the screen. Goatse should be the worst it's capable of. And yet we live in a world where running a screensaver can root your machine, log your keys and mouse movements, and hand your bank account details to any script kiddie with two braincells. That's not just bad: it's absolutely god-awful.
The problem with DRM is that it's not only effective at slowing piracy, it's effective at locking consumers out of their own content. I'd disagree with this. The cost of breaking DRM is a one time fee for pirates; once an unprotected version of the data has been released, the proverbial genie is out of the proverbial bottle. Large content holders, like the organisations that make up the MPAA, want the benefits of distributing their data across a large range of devices, and to the greatest possible proportion of the public, whilst trying to keep a small set of keys secret and hidden. We have problems securing even dedicated data centres from attack; how likely is it that the MPAA et all can pull off their DRM with flawless security even as they are franchising out the algorithms to dozens of third-party hardware manufacturers?
I doubt that DRM can significantly slow down piracy. Historically, DRM schemes tend to be cracked rather more quickly than the average life-cycle of a storage format, or even the latest summer blockbuster. Indeed, the presence of DRM may even encourage piracy in some quarters; a while ago a game I bought stopped working because I had swapped in a new DVD drive, and rather than mess around with tech support trying to get a new key, it was easier and faster to download a cracked copy of the game over bittorrent.
Sure, at the beginning of the first game Guybrush was rather lacking in piratical skills, but since then he has become a master of swordsmanship on both land and sea, has captained several ships, and has battled with countless pirates, cannibals, the undead and monkeys. If that's not solid pirate material, I don't know what is.
To quote Wikipedia:
If you'd like to refute that, I'll need proof that something doesn't exist. Have fun with that. One cannot disprove the existence of the Flying Spaghetti Monster, either, or the existence of invisible pink unicorns. The set of disprovable entities is extremely large, and to say that God is at least the equal of a giant pile of sentient pasta is not setting the bar very high.
Any successful global reputation system would therefore have to be subjective itself, otherwise it would be inaccurate for a considerable number of people. In a relative reputation system, debunking 911 conspiracy theories would earn you negative reputation amongst the conspiracy theorists, but positive reputation amongst those with slightly more common sense.
Also, perhaps the differences are less pronounced than you think. For instance, in Python, we might write: Which could be written in Haskell as: But with a little syntactic sugar, courtesy of Haskell's do-notation: More than a passing resemblance to the procedural Python code! So I don't think it's necessarily true that functional languages are less adept at solving these types of problems. I'd agree that Haskell is probably more difficult to learn, especially coming from a procedural background, but I'd say that was more to do with Haskell's type system more than it's functional approach. Haskell's type system is powerful and strict to such a degree that it makes languages like Java look almost weakly typed in comparison, but in return for this extra complexity at compile time, there tend to be far fewer runtime bugs. Another difference is that the development environments for OO languages are very mature. Creating a GUI using Eclipse, VS.NET or Delphi is as easy as point-and-click. I know of no such environment for Haskell. This is true, however there are several functional languages designed to interoperate with existing environments. Scala, a JVM-based functional language, and F#, a CLI language, are two of the most well known. Scala has a plugin for Eclipse, so one could design a GUI graphically and write the logic in a functional language. I believe something similar is being developed for F# and Visual Studio.