Many people would say that poker isn't gambling either, specifically because you can be "good" at it, and because you can throw a hand. I dare you to be "good" at Keno or "throw" a spin of roulette. Even if you don't agree with that definition you probably shouldn't use poker as an example of what is or is not gambling unless you want your argument to be overshadowed by the comparison.
Conspiracy requires prior collaboration -- the person stealing the information would need to make plans with Assange to disseminate the information *before* committing his crime. And if he had done that he'd also be in violation of the Espionage Act of 1917, so you wouldn't need the conspiracy charge anyway.
That's my point. Even if they guy is a world-class a-hole, we still shouldn't be making up charges against him just because he's a political embarrassment.
AFAICT that's not true. The US doesn't have an Official Secrets Act. There's the Espionage Act of 1917 (18USC793), but A) parts of that were struck down 40 years ago as contrary to the first amendment (New York Times Co. v. United States and other similar cases), and B) it does not in forbid the dissemination of classified material by citizens in general unless they first had lawful access or made such dissemination with the intent of harming the US.
For the sake of argument, let's assume that releasing these documents was morally and/or pragmatically wrong/harmful. I'm not entirely convinced of that, but I'll cede the point for this discussion.
What actual *crime* was committed in releasing these documents, that would justify a criminal investigation, limited travel, and general harassment by the government? Certainly the person with original access to the documents committed a crime in releasing them to unauthorized persons, but once that happened, what further crimes have occurred that would justify governmental interference?
Or they could just install a capacitor, which is what's typically done for dying-gasp circuits. It's not like you need 4kJ to overwrite 4K of RAM, particularly if you design a circuit with rapid reset in mind -- for example, DRAM could be built with the ability to connect all its capacitors to a drain simultaneously (or in big chunks) rather than one word at a time.
That's a limitation of display technology though, not storage capacity. Even if you wanted, for example, 192-bit color (i.e. 10^57 colors), that's not even an order of magnitude more storage than today's typical image storage system.
In films that don't pretend to be 3D there's no conflict between the parallax and my focal distance, so I never have any reason to attempt to focus at some other depth. In fact, the limited field of focus is often used to show differing distances, to help make up for the lack of real depth information.
Plus it's *not* impossible to capture a re-focusable image -- you just need to capture the entire light field as opposed to the 2D projection of the light field captured by traditional photography. While not in common use, such devices actually exist: http://graphics.stanford.edu/papers/lfcamera/
This isn't for people who want to learn photography and take good pictures, it's for people who are shooting their friends in a bar at night to post on Your Face in a Tube and laugh about for a week before being forgotten -- it's merely intended to allow point-and-click shooting work more reliably in poor conditions on cheap equipment with inattentive and untrained operators.
If you want to run linux that's fine. I run lots of linux machines myself, where OS X is not an appropriate choice for a variety of reasons. But if you want to be take seriously you can't complain that OS X isn't UNIX-y enough based on the default choice of a case-preserving file system.
A) It's trivial to add another, case-sensitive partition to your system. The standard Apple tools allow this without even the need to seek a command line or a secondary boot disk.
B) Even if you're too lazy to resize your partitions, you can use disk images to simulate partitions. They mount just like regular partitions and again can be easily created and auto-mounted at login with the stock toolset.
C) While there are some apps that have lazy case conventions for file names, none of the base system does. So you can move the OS to a case-sensitive filesystem and just keep a case-preserving one around for "bad" apps that can't handle it (I'm looking at you Adobe). This one requires a reboot, but can still be done without a second boot disk, and without running the OS installer -- just copy the files around and resize the partitions. Or with a third-party tool and a separate boot disk you can convert in-place without copying anything.
D) All of the bad apps can be fixed with a simple rename or symlink to allow the file to be accessed be the expected name. It's sometimes a hassle to figure out what the file name is, but it's easy to fix once you do.
E) All major desktop OSes have had either case-insensitive or case-persrving file systems for decades -- DOS, Windows, OS/2, Mac OS, Mac OS X -- case sensitivity is not going to become the default in any desktop OS because it would confuse *most* computer users. Heck, many of the major file-sharing protocols, including those in use on UNIX systems, don't even *support* case-sensitive file names.
The gestures are handy. I use a trackball at my desktop, which has lots of buttons and doesn't require any arm movement or desk space, but I sometimes miss the gestures I can make on my laptop's trackpad, and I've been wanting a trackpad for my desktop for some time (in addition to the trackball, not as a replacement).
I'm not sure if I want one for $70, but I do want one. Does anybody know of a similar product that isn't so fraking expensive? I'm willing to get something smaller and I'm indifferent about Bluetooth, but I haven't been able to find anything that supports the sort of multi-finger gestures I want to use. Any suggestions?
Well-designed embedded systems have a boot watchdog -- if the system fails to boot properly X times in a row they will boot from the backup ROM that only allows re-flashing of the main firmware instead of the normal runtime firmware. You'll find the same thing on many non-emebedded systems with boot code, but typically those versions are manually activated with a jumper or somesuch. Your current motherboard might have such a thing if you looked.
For one thing, this design makes it much easier to do debugging and testing in the design phases, when you're actually writing the firmware, so that you don't have to burn chips externally every time you muck something up. For another, it ensures that nothing you can do in the field will make the device irreparably broken, short of actual hardware failure, which simplifies troubleshooting and reduces warranty and customer service costs.
I invite anyone and everyone to drive around my house 24/7 and capture whatever broadcast, unencrypted data I emit. (And that's not even what Google did -- they only grabbed a few seconds of data).
Frankly I'm not sure what part of my rant gave you the impression that the identity of the alleged perpetrator had any influence on my opinion of the behavior.
First, Google only gets passive captures, so they have to take what they can get and then parse it. They *necessarily* have to look at whole packets to figure out what's going on. They could then, after examining the packets, throw them out and keep only the data they're using in location services, but they had to capture it all in the first place. It seems plausible to me that they just didn't think it was important, or though it was worth saving in case they came up with a new way to process it later to improve their location services.
Second, they didn't keep encrypted data because there's no useful data to keep. There only thing sent in the clear on encrypted network is the MAC address, so there's no possible post processing or extra parsing they could possibly do to extract more information. It also seems plausible that they intentionally decided to exclude encrypted networks from their index as a courtesy to respect the privacy of encrypted networks.
It's possible that they're doing something evil -- though I'm hard pressed to come up with anything useful you could do with a 3-second packet capture -- but I can come up with plenty of plausible explanations for why they didn't immediately destroy the data. And even if the have evil plans, why is this so outrageous? Doesn't Google get like 15x as much useful information from everyone using their search engine and other services? If Google is being evil, shouldn't we be worried about that information much more than these one-time, very short packet captures from broadcast, unencrypted networks?
Why was it collected? My first two guess would be:
A) The system is intended to collect AP MAC addresses and SSIDs. Doing this requires capturing broadcast packets. As it turns out, you only need some of the packets, but because the capture is passive you have to take what you get and parse it to find what you want. So if you stored the data as it came in it's actually *extra* work to remove the parts of the capture you didn't use, and no one wrote that part because it wasn't important.
B) They wanted to collect all available data in case the in-situ processing fails -- then they can just re-run the data set instead of re-driving the route. Variations on this include "we may encounter new packet types we weren't expecting and want to do post-processing on them" or "we may invent new ways to provide location services based on data that we capture but didn't know at the time was useful".
It's also possible that they're doing something evil that we can't think of, or that they're just keeping the data around in case they think of something evil to do with it later. I agree, it is possible. But I don't think I'm giving Google a pass here -- given the very limited amount of data they collected from each network I have trouble imagining what that evil thing might be, or why we should consider it more important than the data mining that goes on in other contexts, like when you actually use Google services.
I also don't see how, given only a few seconds of passive signal capture, Google or anyone else *could* crack WEP or WPA keys, either in situ or via post-processing (other than pure brute force).
First, Google isn't getting traffic logs. They're getting a couple of seconds of network traffic which may or may not include any useful traffic. Even if you're actively browsing there's a good chance you didn't click on anything in those few seconds, or if you did, that they missed the 1 packet that had the URL in it. Conflating "traffic logs" with a few seconds of packet captures to make Google seem evil speaks more to your character than theirs.
Second, you and everyone else are welcome to circle my house 24/7 and log or otherwise record all of the broadcast, unencrypted data I emit. I'm not making any special exception for Google -- this information is already public by nature of being broadcast in plaintext.
Am I the only one who thinks this is overblown? For all the actually invasive data-mining that happens on a daily basis on the web and in real life, are we really concerned that Google captures a few seconds of broadcast, unencrypted network traffic? Is this a more important issue than the online and physical database breaches we see all time from other companies (and governments) -- many of those go entirely unnoticed, and even big stories from that category only get a day or two of news coverage, but people have been whining about this Google thing for weeks.
Even if you assume that Google really wanted to capture this data for some nefarious purpose, exactly what are people worried about? It's not at all clear to me that capturing a random 3 seconds of traffic from someone's open WiFi provides Google with any particularly useful or terribly private information. Ignoring the fact that anyone in the neighborhood could be doing continuous captures of the same AP, or that half of these WiFi networks are connected to broadcast-based uplinks (like cable modems), I just don't understand why this -- even if the intent is evil -- ranks high among the other privacy concerns in modern life.
This is relatively secure if and only if there's a significant variation in the length of the first word. If there's not -- for example, if the base words are mostly 4-5 characters -- then it's only a few times more complex than any standard dictionary-based password. It's better than *just* using a dictionary word -- for example, given a dictionary of 150,000 words you from 10^5 possibilities to 10^6 or 10^7 -- but it's still pretty week.
For comparison, if you used a character set that included upper and lower-case letters, 10 digits, and 10 other characters, you could have a 4-character password with 10^8 possibilities. If you can remember a 7-character random password that becomes ~10^12.
I might agree if you said "12+ characters provide enough protection against brute-force attacks even using only 52 symbols". Given random passwords that's probably true. I'm not sure I'd agree for passwords based on real words, but it's at least a valid point for debate. And I'd agree wholeheartedly if you said "having a large character set is more important for shorter passwords".
But there's great value in adding different character classes to your password, no matter the length.
A 12-character password that is predictably-cased has about 10^28 possible combinations. If you require nOn-prEdiCTaBle case that becomes 10^56. If you require non-predictable numbers (i.e. don't just slap them on the end) that becomes 10^66. If you require the 7 special symbols you use in your example, that becomes 10^74. To get the same number of possibilities with the predictable-case character set you'd need a password about 750 characters long.
You're also ignoring the use of frequency and other linguistic analyses on any phrase based on full English words to eliminate (or at least de-prioritize) a significant portion of the possibilities. Which exposes another benefit to increasing the number of character classes -- if you make non-predictable substitutions (i.e. not l33t speak) into your English words you can greatly hamper language-based analysis without the need to require truly random passwords.
You don't have to release it, but you never asserted copyright protections on it either. It doesn't seem unreasonable to tie the two together -- you can keep something secret OR assert copyright protections, but not both.
We do exactly the same thing with patents. You can have trade secrets and even take legal action to protect them and prevent them from being improperly shared. OR you can have patent, which makes the design public, but allows you to prohibit use of the design even in independent implementations. But you can't patent something and keep it a secret.
Given that reasoning, are you suggesting that the code isn't protected by copyright since it wasn't published? Because traditionally copyright protections have applied to both published and unpublished works.
I'd also argue that the source code is a fundamental component of the information needed to reproduce the work, which is the basis of copyright protections. Using the book analogy, it's not only possible to photograph and re-print a book on new paper, but also to typeset the underlying text and reproduce the story in another form. Isolating the source code from the binary is like limiting reproductions of books to photographs only, and making it illegal to re-typeset the text because the original TXT files were never made public.
A) I don't buy gas every day. So the oil company can only fuck with me once/week. And there is more than one oil company supplying my town.
B) There are actually a lot of places were it is illegal to run a 2+ kW generator all night, or where it would be unsafe or otherwise impractical to do so. Plus you'd have to transport fuel to it, which could be tricky if you needed to charge your car.
How about requiring a notary public's seal on loan documents for them to be enforceable? That would require lending institutions to reasonably verify someone's identity before issuing them credit, and works with 17th century technology.
It's not impossible to fool -- you could also have false ID, etc. -- but it's a lot more reliable than simply writing down a different SSN, and requires an additional fraud against the government to pull off.
Slashdot Mirror
Many people would say that poker isn't gambling either, specifically because you can be "good" at it, and because you can throw a hand. I dare you to be "good" at Keno or "throw" a spin of roulette. Even if you don't agree with that definition you probably shouldn't use poker as an example of what is or is not gambling unless you want your argument to be overshadowed by the comparison.
Conspiracy requires prior collaboration -- the person stealing the information would need to make plans with Assange to disseminate the information *before* committing his crime. And if he had done that he'd also be in violation of the Espionage Act of 1917, so you wouldn't need the conspiracy charge anyway.
That's my point. Even if they guy is a world-class a-hole, we still shouldn't be making up charges against him just because he's a political embarrassment.
AFAICT that's not true. The US doesn't have an Official Secrets Act. There's the Espionage Act of 1917 (18USC793), but A) parts of that were struck down 40 years ago as contrary to the first amendment (New York Times Co. v. United States and other similar cases), and B) it does not in forbid the dissemination of classified material by citizens in general unless they first had lawful access or made such dissemination with the intent of harming the US.
For the sake of argument, let's assume that releasing these documents was morally and/or pragmatically wrong/harmful. I'm not entirely convinced of that, but I'll cede the point for this discussion.
What actual *crime* was committed in releasing these documents, that would justify a criminal investigation, limited travel, and general harassment by the government? Certainly the person with original access to the documents committed a crime in releasing them to unauthorized persons, but once that happened, what further crimes have occurred that would justify governmental interference?
Or they could just install a capacitor, which is what's typically done for dying-gasp circuits. It's not like you need 4kJ to overwrite 4K of RAM, particularly if you design a circuit with rapid reset in mind -- for example, DRAM could be built with the ability to connect all its capacitors to a drain simultaneously (or in big chunks) rather than one word at a time.
That's a limitation of display technology though, not storage capacity. Even if you wanted, for example, 192-bit color (i.e. 10^57 colors), that's not even an order of magnitude more storage than today's typical image storage system.
In films that don't pretend to be 3D there's no conflict between the parallax and my focal distance, so I never have any reason to attempt to focus at some other depth. In fact, the limited field of focus is often used to show differing distances, to help make up for the lack of real depth information.
Plus it's *not* impossible to capture a re-focusable image -- you just need to capture the entire light field as opposed to the 2D projection of the light field captured by traditional photography. While not in common use, such devices actually exist: http://graphics.stanford.edu/papers/lfcamera/
This isn't for people who want to learn photography and take good pictures, it's for people who are shooting their friends in a bar at night to post on Your Face in a Tube and laugh about for a week before being forgotten -- it's merely intended to allow point-and-click shooting work more reliably in poor conditions on cheap equipment with inattentive and untrained operators.
If you want to run linux that's fine. I run lots of linux machines myself, where OS X is not an appropriate choice for a variety of reasons. But if you want to be take seriously you can't complain that OS X isn't UNIX-y enough based on the default choice of a case-preserving file system.
A) It's trivial to add another, case-sensitive partition to your system. The standard Apple tools allow this without even the need to seek a command line or a secondary boot disk.
B) Even if you're too lazy to resize your partitions, you can use disk images to simulate partitions. They mount just like regular partitions and again can be easily created and auto-mounted at login with the stock toolset.
C) While there are some apps that have lazy case conventions for file names, none of the base system does. So you can move the OS to a case-sensitive filesystem and just keep a case-preserving one around for "bad" apps that can't handle it (I'm looking at you Adobe). This one requires a reboot, but can still be done without a second boot disk, and without running the OS installer -- just copy the files around and resize the partitions. Or with a third-party tool and a separate boot disk you can convert in-place without copying anything.
D) All of the bad apps can be fixed with a simple rename or symlink to allow the file to be accessed be the expected name. It's sometimes a hassle to figure out what the file name is, but it's easy to fix once you do.
E) All major desktop OSes have had either case-insensitive or case-persrving file systems for decades -- DOS, Windows, OS/2, Mac OS, Mac OS X -- case sensitivity is not going to become the default in any desktop OS because it would confuse *most* computer users. Heck, many of the major file-sharing protocols, including those in use on UNIX systems, don't even *support* case-sensitive file names.
The gestures are handy. I use a trackball at my desktop, which has lots of buttons and doesn't require any arm movement or desk space, but I sometimes miss the gestures I can make on my laptop's trackpad, and I've been wanting a trackpad for my desktop for some time (in addition to the trackball, not as a replacement).
I'm not sure if I want one for $70, but I do want one. Does anybody know of a similar product that isn't so fraking expensive? I'm willing to get something smaller and I'm indifferent about Bluetooth, but I haven't been able to find anything that supports the sort of multi-finger gestures I want to use. Any suggestions?
Well-designed embedded systems have a boot watchdog -- if the system fails to boot properly X times in a row they will boot from the backup ROM that only allows re-flashing of the main firmware instead of the normal runtime firmware. You'll find the same thing on many non-emebedded systems with boot code, but typically those versions are manually activated with a jumper or somesuch. Your current motherboard might have such a thing if you looked.
For one thing, this design makes it much easier to do debugging and testing in the design phases, when you're actually writing the firmware, so that you don't have to burn chips externally every time you muck something up. For another, it ensures that nothing you can do in the field will make the device irreparably broken, short of actual hardware failure, which simplifies troubleshooting and reduces warranty and customer service costs.
Yes.
I invite anyone and everyone to drive around my house 24/7 and capture whatever broadcast, unencrypted data I emit. (And that's not even what Google did -- they only grabbed a few seconds of data).
Frankly I'm not sure what part of my rant gave you the impression that the identity of the alleged perpetrator had any influence on my opinion of the behavior.
First, Google only gets passive captures, so they have to take what they can get and then parse it. They *necessarily* have to look at whole packets to figure out what's going on. They could then, after examining the packets, throw them out and keep only the data they're using in location services, but they had to capture it all in the first place. It seems plausible to me that they just didn't think it was important, or though it was worth saving in case they came up with a new way to process it later to improve their location services.
Second, they didn't keep encrypted data because there's no useful data to keep. There only thing sent in the clear on encrypted network is the MAC address, so there's no possible post processing or extra parsing they could possibly do to extract more information. It also seems plausible that they intentionally decided to exclude encrypted networks from their index as a courtesy to respect the privacy of encrypted networks.
It's possible that they're doing something evil -- though I'm hard pressed to come up with anything useful you could do with a 3-second packet capture -- but I can come up with plenty of plausible explanations for why they didn't immediately destroy the data. And even if the have evil plans, why is this so outrageous? Doesn't Google get like 15x as much useful information from everyone using their search engine and other services? If Google is being evil, shouldn't we be worried about that information much more than these one-time, very short packet captures from broadcast, unencrypted networks?
Why was it collected? My first two guess would be:
A) The system is intended to collect AP MAC addresses and SSIDs. Doing this requires capturing broadcast packets. As it turns out, you only need some of the packets, but because the capture is passive you have to take what you get and parse it to find what you want. So if you stored the data as it came in it's actually *extra* work to remove the parts of the capture you didn't use, and no one wrote that part because it wasn't important.
B) They wanted to collect all available data in case the in-situ processing fails -- then they can just re-run the data set instead of re-driving the route. Variations on this include "we may encounter new packet types we weren't expecting and want to do post-processing on them" or "we may invent new ways to provide location services based on data that we capture but didn't know at the time was useful".
It's also possible that they're doing something evil that we can't think of, or that they're just keeping the data around in case they think of something evil to do with it later. I agree, it is possible. But I don't think I'm giving Google a pass here -- given the very limited amount of data they collected from each network I have trouble imagining what that evil thing might be, or why we should consider it more important than the data mining that goes on in other contexts, like when you actually use Google services.
I also don't see how, given only a few seconds of passive signal capture, Google or anyone else *could* crack WEP or WPA keys, either in situ or via post-processing (other than pure brute force).
First, Google isn't getting traffic logs. They're getting a couple of seconds of network traffic which may or may not include any useful traffic. Even if you're actively browsing there's a good chance you didn't click on anything in those few seconds, or if you did, that they missed the 1 packet that had the URL in it. Conflating "traffic logs" with a few seconds of packet captures to make Google seem evil speaks more to your character than theirs.
Second, you and everyone else are welcome to circle my house 24/7 and log or otherwise record all of the broadcast, unencrypted data I emit. I'm not making any special exception for Google -- this information is already public by nature of being broadcast in plaintext.
Am I the only one who thinks this is overblown? For all the actually invasive data-mining that happens on a daily basis on the web and in real life, are we really concerned that Google captures a few seconds of broadcast, unencrypted network traffic? Is this a more important issue than the online and physical database breaches we see all time from other companies (and governments) -- many of those go entirely unnoticed, and even big stories from that category only get a day or two of news coverage, but people have been whining about this Google thing for weeks.
Even if you assume that Google really wanted to capture this data for some nefarious purpose, exactly what are people worried about? It's not at all clear to me that capturing a random 3 seconds of traffic from someone's open WiFi provides Google with any particularly useful or terribly private information. Ignoring the fact that anyone in the neighborhood could be doing continuous captures of the same AP, or that half of these WiFi networks are connected to broadcast-based uplinks (like cable modems), I just don't understand why this -- even if the intent is evil -- ranks high among the other privacy concerns in modern life.
This is relatively secure if and only if there's a significant variation in the length of the first word. If there's not -- for example, if the base words are mostly 4-5 characters -- then it's only a few times more complex than any standard dictionary-based password. It's better than *just* using a dictionary word -- for example, given a dictionary of 150,000 words you from 10^5 possibilities to 10^6 or 10^7 -- but it's still pretty week.
For comparison, if you used a character set that included upper and lower-case letters, 10 digits, and 10 other characters, you could have a 4-character password with 10^8 possibilities. If you can remember a 7-character random password that becomes ~10^12.
I might agree if you said "12+ characters provide enough protection against brute-force attacks even using only 52 symbols". Given random passwords that's probably true. I'm not sure I'd agree for passwords based on real words, but it's at least a valid point for debate. And I'd agree wholeheartedly if you said "having a large character set is more important for shorter passwords".
But there's great value in adding different character classes to your password, no matter the length.
A 12-character password that is predictably-cased has about 10^28 possible combinations. If you require nOn-prEdiCTaBle case that becomes 10^56. If you require non-predictable numbers (i.e. don't just slap them on the end) that becomes 10^66. If you require the 7 special symbols you use in your example, that becomes 10^74. To get the same number of possibilities with the predictable-case character set you'd need a password about 750 characters long.
You're also ignoring the use of frequency and other linguistic analyses on any phrase based on full English words to eliminate (or at least de-prioritize) a significant portion of the possibilities. Which exposes another benefit to increasing the number of character classes -- if you make non-predictable substitutions (i.e. not l33t speak) into your English words you can greatly hamper language-based analysis without the need to require truly random passwords.
You don't have to release it, but you never asserted copyright protections on it either. It doesn't seem unreasonable to tie the two together -- you can keep something secret OR assert copyright protections, but not both.
We do exactly the same thing with patents. You can have trade secrets and even take legal action to protect them and prevent them from being improperly shared. OR you can have patent, which makes the design public, but allows you to prohibit use of the design even in independent implementations. But you can't patent something and keep it a secret.
Given that reasoning, are you suggesting that the code isn't protected by copyright since it wasn't published? Because traditionally copyright protections have applied to both published and unpublished works.
I'd also argue that the source code is a fundamental component of the information needed to reproduce the work, which is the basis of copyright protections. Using the book analogy, it's not only possible to photograph and re-print a book on new paper, but also to typeset the underlying text and reproduce the story in another form. Isolating the source code from the binary is like limiting reproductions of books to photographs only, and making it illegal to re-typeset the text because the original TXT files were never made public.
A) I don't buy gas every day. So the oil company can only fuck with me once/week. And there is more than one oil company supplying my town.
B) There are actually a lot of places were it is illegal to run a 2+ kW generator all night, or where it would be unsafe or otherwise impractical to do so. Plus you'd have to transport fuel to it, which could be tricky if you needed to charge your car.
How about requiring a notary public's seal on loan documents for them to be enforceable? That would require lending institutions to reasonably verify someone's identity before issuing them credit, and works with 17th century technology.
It's not impossible to fool -- you could also have false ID, etc. -- but it's a lot more reliable than simply writing down a different SSN, and requires an additional fraud against the government to pull off.
Only when it's dark and they reflect the sun. You can't see them at all during the day or when they're in the Earth's shadow.
And even if you could, and I gave you a magic missile that could reach them, could you aim it accurately with nothing more than a mechanical scope?