As someone who uses TwinView under Linux, may I ask what is wrong with TwinView? I thought it emulated all of the relevant Xinerama stuff. What am I missing? (I cannot comment on the configuration as I do not use Ubuntu.)
My windows maximize to one monitor and dialog boxes appear in the middle of one of my monitors. The most major problem I have encountered is that the fullscreen mode of StepMania 3.9 (latest stable release) appears centered between the two monitors. I restart X in single monitor mode as a workaround, but I think the problem is with StepMania not the nVidia driver because the beta properly uses only my primary monitor (unfortunately it is very unstable).
Country code TLDs are useful for referencing sites which only apply to a specific country like government websites or businesses which only do business in one country. On the other hand, the use of TLDs for language selection like Google.fr, etc. is a hack: HTTP already supports language selection with the Accept-Language header. Wikipedia links to a blog post discussing real world use of the header.
This article suggests a sane way to handle gTLDs and includes discussions of the various problems like the ones you mention (TLDs being meaningless and trademarks). Unfortunately, that does not appear to be what ICANN is actually doing. As usual it just appears that they are trying to encourage more domain registrations which earn them money without actually improving the usefulness of the DNS system.
This article explains how properly done TLDs could actually be a good idea. Under his scheme, you could set your computer's DNS to by default append $YourFavoriteGTLD which agrees with you on that point and get just that. I recommend against setting that for.com in your current DNS setup unless you really like CNET. The gTLD idea sounds similar, but I do not have much faith in ICANN handling it well.
I apologize for citing a source in order to make my comment meaningful even to people who have not read Asimov's robot books. In the future I will work hard to make sure my comments are as obscure and badly referenced as possible.
Seriously, problems with the Laws of Robotics is a central recurring theme in those books. Anyone who has actually read some of Asimov's robot stories should be aware that the laws don't work.
If you do not care about my references, then I recommend against clicking links in my posts.
As I have stated before, Asimov's Laws of Robotics do not constitute a recommendation for rules which make a robot safe but rather a thought experiment arguing that no such set of rules exists.
You have pretty much described the usage pattern for a slightly old (Pentium-M) 12" laptop one of my friends has. They use it as a thin client via XDMCP when on the LAN with their desktop and use it as a regular Linux computer when elsewhere.
In the US, at least, labeling food as organic requires that it meets the US's organic certification requirements. Wikipedia suggests that other countries have similar laws. I am not well-versed in the issue, so perhaps you disagree with the requirements for marking food as "organic".
On the other hand, the term "open source" is not legally regulated and not trademarked. However, it is commonly understood to refer to software covered by a license meeting The Open Source Definition.
My wife and I are just at the point where we're talking about kids, but I think what we'd do is not allow them to have an email account until we felt they were old enough to understand what porn is and why we don't want them looking at it.
I do not want to start a flame war here, but I am wondering what your reasoning is for that. You are talking about kids younger than 10 years old; aren't they just going to be uninterested in porn? Why do you care if they accidentally happen upon it and have to navigate away?
Note that Facebook and MySpace both have public and private messaging systems where the private systems are pretty much e-mail except limited to their site. On the up side, these systems seem to be pretty spam resistant. For some reason, the younger generation seems to prefer these systems to normal e-mail. Now that I think of it, they also both have their own IM systems.
Okay, so debit cards are insufficiently protected by the law, but identity theft via website hacking and/or phishing is protected. That sounds like a sane reason to invalidate mcgrew's example.
On the other hand, the assertion that banks care about security strikes me as ridiculous. Why are we still using authentication systems where logging in involves transferring all of the knowledge needed to log in as opposed to some sort of challenge response? Randomly asking security questions helps this a little, but the system is fundamentally broken. Even training the user to be okay typing the information needed to access their bank account into a web browser is a bad idea.
Admittedly, this is not entirely the fault of the bank, although they could at least be using some sort of security token to make phished passwords have a very short lifetime. Stronger security requires browser cooperation. Properly implemented http://en.wikipedia.org/wiki/Digest_access_authentication">digest authentication (different color dialog from the weak basic HTTP auth?) would make phishing worthless -- if you could convince users to only type their password into a safe dialog which seems unlikely unless every website used secure authentication so the browser could warn loudly about any insecure authentication. Support for public key auth would be even better because then the user would never be tempted to type in their password on a phishing site if they did not have one. It has problems with being able to log in from multiple computers because a key has to be setup on each computer, but I suspect that is not an issue for most users because they only bank from one computer anyway. Of course, the key could be stolen by spyware but they spyware could be running a keylogger just a easily.
I believe you that banks put a good amount of effort into their internal security, but most are still using plaintext passwords over HTTPS or some authentication measure of equivalent quality. There does not seem to be a strong focus on actually making identity theft via gaining access to a person's bank login information hard.
That said, DNSSEC does not help much in that area because HTTPS already verifies domains, and someone in the position to poison DNS is probably in position to fake unencrypted/unsigned communications from the bank anyway.
As a supporter of the Unix philosophy of "one app, one function", I think the proper solution here would be an app that does basic setup of the configuration files. Maybe it would come with a few templates and ask some questions with explanations to fill in the blanks. That way it can be separate and the people who know what they are doing can just not install it, but simple use cases can be covered with limited knowledge.
How do digital signatures allow easy harvesting of email addresses?
Certificates must be centrally stored or related to a trusted central authority. With this, you only have to break that central authority to get all the valid e-mail addresses. In addition, if all e-mail had to be signed, then people wouldn't be able to use throwaway e-mail addresses as easily, so every "give us your e-mail" would mean that a valid e-mail address was being harvested.
For certificates to be meaningful someone has to sign them and the person looking at the certificate needs to know and to some extent trust the public key of the signing authority. There is no reason that signing authority needs to know every e-mail address they have signed a certificate for. Especially in the case of a set of CAs (like the current HTTPS setup), the CA could possibly sign a signing key for an organization granting that key rights to sign any email address under a certain domain. Another method could involve WoT to sign keys in a distributed matter (which unfortunately does not work very well; see: the number of PGP encrypted emails in your inbox) or DNSSEC to provide a signing key or set of signing keys for a domain via DNS.
Your other concern implies that making a certificate is somehow difficult. An anonymous e-mail service (or you using your own personal domain/subdomain or with a signing key limited to signing any address like you+something@example.com) could easily just generate a brand new certificate for every e-mail it sends. If you generate throwaways they are probably only for receiving e-mail anyway, so they would not need their own keys unless you want that e-mail to be encrypted... and I thought this discussion was just about signing e-mails.
Because today there isn't a central certificate authority that is required to be used by everyone sending e-mail. This idea would make that a reality. That CA would have all the private keys for all the certs in a one-stop shop for the government. Encrypting wouldn't do any good, because it would be done using one of the same keys that was available in the CA.
The CA signs your public key. It should never need to see your private key. If their process is such that they generate the key for you, then it is broken. That is a problem with the CA, not the idea of signed certificates.
The CA does have the power to generate a new fake certificate for any e-mail address. This would only fool people who had not received e-mail from that address before, though. Although if it was used just after an old certificate expired, then the attack could be transparent, so government coercion is still a reason to be weary of a centralized system, but reading your e-mail becomes a coordinated active attack because they have to trick you and the people you communicate with into accepting different keys.
He is giving an example an attacker getting access to his debit card and the bank taking no liability for it. You are free to complain about him whining because you think he should be the one liable not the bank (that is a different, irrelevant argument), but the topic of discussion is that the bank customer is liable not the bank. This means the bank has no incentive to improve their security. In fact, better security probably costs more -- at least the cost of paying someone to figure out how to fix problems with their current procedures -- so they have a direct financial incentive to keep the security at the current status quo. Although, if the other banks improve, competition may force them to make changes.
The difference is who has the right to ask for the source. The GPL says anyone who gets the binaries can ask for the source. The Affero GPL says that anyone who connects to the program running on a server can ask for the source.
Ah, I was thinking about the privacy/"who owns the data?" concerns with relation to the entity running the service who you are essentially giving your data to, which is a real legal issue considering most services seem to claim more rights than they need. But that is a different discussion. The government, on the other hand, should never be looking at anyone's data without a warrant (or, in the worst case, an after-the-fact review by the FISA court if it applies to the instance). I apologize for the confusion. I do not think I actually disagree with you.
There is the pretty clear difference in that your password is not a "lock" on your data. It is simply how you let the service know it is okay to send your data over the internet and let you edit it. An actual lock for "cloud" services would be for the data to be encrypted and only decrypted client-side.
Perhaps somehow it could be decrypted by Javascript with a passphrase entered client-side. There are lots of problems with that approach the main two that occur to me are (1) the service probably wants to serve ads based off your data, which it cannot do if it only has encrypted copies and (2) there is no way for the user to tell the difference between what I described and the current process of logging into Google Docs.
On the other hand, it might work okay for using S3 as file server like another poster mentioned. Unfortunately, if the data is encrypted, then it has to be decrypted on the computer doing the calculations. I suppose an encrypted index could be stored on the S3 file server, but this seems like it is getting a bit ridiculous.
To be fair, WoW and Steam do support downloading a lot of game content over the internet. Actually playing them probably does not use much bandwidth, though.
You could use a script like the one Wikimedia Commons has which detects the client's supported players and selects one. It would probably be trivial to add a Flash check in addition to the others and fall back to FLV if necessary. The script will use the <video> element if it can. On my system it uses the Totem browser plugin.
Firefox will use the platform's normal video support according to this blog post. That is, DirectShow on Windows, QuickTime on Mac, and gstreamer on Linux. H.264 is supported by all of those with the proper plugins, but that gets us right back to the reason why the popular video sites do not use <embed> or <object> which sites used to do for video before FLV became popular and some sites still do: the client has to have the right codecs. Getting the user to have Flash installed is, in practice, easier than getting them to have the right video codecs despite how annoying the Flash requirement may be for the small minority of users who do not use Windows or Mac OS X or simply want the web to be sane and non-proprietary.
Bugmenot allows site owners to opt-out if that type of problem applies. The summary says that Facebook.com is not listed on bugmenot, with a link to bugmenot showing
This site has been barred from the bugmenot system.
Slashdot Mirror
As someone who uses TwinView under Linux, may I ask what is wrong with TwinView? I thought it emulated all of the relevant Xinerama stuff. What am I missing? (I cannot comment on the configuration as I do not use Ubuntu.)
My windows maximize to one monitor and dialog boxes appear in the middle of one of my monitors. The most major problem I have encountered is that the fullscreen mode of StepMania 3.9 (latest stable release) appears centered between the two monitors. I restart X in single monitor mode as a workaround, but I think the problem is with StepMania not the nVidia driver because the beta properly uses only my primary monitor (unfortunately it is very unstable).
Country code TLDs are useful for referencing sites which only apply to a specific country like government websites or businesses which only do business in one country. On the other hand, the use of TLDs for language selection like Google.fr, etc. is a hack: HTTP already supports language selection with the Accept-Language header. Wikipedia links to a blog post discussing real world use of the header.
This article suggests a sane way to handle gTLDs and includes discussions of the various problems like the ones you mention (TLDs being meaningless and trademarks). Unfortunately, that does not appear to be what ICANN is actually doing. As usual it just appears that they are trying to encourage more domain registrations which earn them money without actually improving the usefulness of the DNS system.
This article explains how properly done TLDs could actually be a good idea. Under his scheme, you could set your computer's DNS to by default append $YourFavoriteGTLD which agrees with you on that point and get just that. I recommend against setting that for .com in your current DNS setup unless you really like CNET. The gTLD idea sounds similar, but I do not have much faith in ICANN handling it well.
I apologize for citing a source in order to make my comment meaningful even to people who have not read Asimov's robot books. In the future I will work hard to make sure my comments are as obscure and badly referenced as possible.
Seriously, problems with the Laws of Robotics is a central recurring theme in those books. Anyone who has actually read some of Asimov's robot stories should be aware that the laws don't work.
If you do not care about my references, then I recommend against clicking links in my posts.
As I have stated before, Asimov's Laws of Robotics do not constitute a recommendation for rules which make a robot safe but rather a thought experiment arguing that no such set of rules exists.
You have pretty much described the usage pattern for a slightly old (Pentium-M) 12" laptop one of my friends has. They use it as a thin client via XDMCP when on the LAN with their desktop and use it as a regular Linux computer when elsewhere.
Ah, I think that qualifies as the requirements for "organic" being badly written.
In the US, at least, labeling food as organic requires that it meets the US's organic certification requirements. Wikipedia suggests that other countries have similar laws. I am not well-versed in the issue, so perhaps you disagree with the requirements for marking food as "organic".
On the other hand, the term "open source" is not legally regulated and not trademarked. However, it is commonly understood to refer to software covered by a license meeting The Open Source Definition.
My wife and I are just at the point where we're talking about kids, but I think what we'd do is not allow them to have an email account until we felt they were old enough to understand what porn is and why we don't want them looking at it.
I do not want to start a flame war here, but I am wondering what your reasoning is for that. You are talking about kids younger than 10 years old; aren't they just going to be uninterested in porn? Why do you care if they accidentally happen upon it and have to navigate away?
Note that Facebook and MySpace both have public and private messaging systems where the private systems are pretty much e-mail except limited to their site. On the up side, these systems seem to be pretty spam resistant. For some reason, the younger generation seems to prefer these systems to normal e-mail. Now that I think of it, they also both have their own IM systems.
I don't know about the banks, but I know the Yahoo one is handled by storing a cookie, which the phishing site would not be able to read.
Okay, so debit cards are insufficiently protected by the law, but identity theft via website hacking and/or phishing is protected. That sounds like a sane reason to invalidate mcgrew's example.
On the other hand, the assertion that banks care about security strikes me as ridiculous. Why are we still using authentication systems where logging in involves transferring all of the knowledge needed to log in as opposed to some sort of challenge response? Randomly asking security questions helps this a little, but the system is fundamentally broken. Even training the user to be okay typing the information needed to access their bank account into a web browser is a bad idea.
Admittedly, this is not entirely the fault of the bank, although they could at least be using some sort of security token to make phished passwords have a very short lifetime. Stronger security requires browser cooperation. Properly implemented http://en.wikipedia.org/wiki/Digest_access_authentication">digest authentication (different color dialog from the weak basic HTTP auth?) would make phishing worthless -- if you could convince users to only type their password into a safe dialog which seems unlikely unless every website used secure authentication so the browser could warn loudly about any insecure authentication. Support for public key auth would be even better because then the user would never be tempted to type in their password on a phishing site if they did not have one. It has problems with being able to log in from multiple computers because a key has to be setup on each computer, but I suspect that is not an issue for most users because they only bank from one computer anyway. Of course, the key could be stolen by spyware but they spyware could be running a keylogger just a easily.
I believe you that banks put a good amount of effort into their internal security, but most are still using plaintext passwords over HTTPS or some authentication measure of equivalent quality. There does not seem to be a strong focus on actually making identity theft via gaining access to a person's bank login information hard.
That said, DNSSEC does not help much in that area because HTTPS already verifies domains, and someone in the position to poison DNS is probably in position to fake unencrypted/unsigned communications from the bank anyway.
As a supporter of the Unix philosophy of "one app, one function", I think the proper solution here would be an app that does basic setup of the configuration files. Maybe it would come with a few templates and ask some questions with explanations to fill in the blanks. That way it can be separate and the people who know what they are doing can just not install it, but simple use cases can be covered with limited knowledge.
How do digital signatures allow easy harvesting of email addresses?
Certificates must be centrally stored or related to a trusted central authority. With this, you only have to break that central authority to get all the valid e-mail addresses. In addition, if all e-mail had to be signed, then people wouldn't be able to use throwaway e-mail addresses as easily, so every "give us your e-mail" would mean that a valid e-mail address was being harvested.
For certificates to be meaningful someone has to sign them and the person looking at the certificate needs to know and to some extent trust the public key of the signing authority. There is no reason that signing authority needs to know every e-mail address they have signed a certificate for. Especially in the case of a set of CAs (like the current HTTPS setup), the CA could possibly sign a signing key for an organization granting that key rights to sign any email address under a certain domain. Another method could involve WoT to sign keys in a distributed matter (which unfortunately does not work very well; see: the number of PGP encrypted emails in your inbox) or DNSSEC to provide a signing key or set of signing keys for a domain via DNS.
Your other concern implies that making a certificate is somehow difficult. An anonymous e-mail service (or you using your own personal domain/subdomain or with a signing key limited to signing any address like you+something@example.com) could easily just generate a brand new certificate for every e-mail it sends. If you generate throwaways they are probably only for receiving e-mail anyway, so they would not need their own keys unless you want that e-mail to be encrypted... and I thought this discussion was just about signing e-mails.
Because today there isn't a central certificate authority that is required to be used by everyone sending e-mail. This idea would make that a reality. That CA would have all the private keys for all the certs in a one-stop shop for the government. Encrypting wouldn't do any good, because it would be done using one of the same keys that was available in the CA.
The CA signs your public key. It should never need to see your private key. If their process is such that they generate the key for you, then it is broken. That is a problem with the CA, not the idea of signed certificates.
The CA does have the power to generate a new fake certificate for any e-mail address. This would only fool people who had not received e-mail from that address before, though. Although if it was used just after an old certificate expired, then the attack could be transparent, so government coercion is still a reason to be weary of a centralized system, but reading your e-mail becomes a coordinated active attack because they have to trick you and the people you communicate with into accepting different keys.
He is giving an example an attacker getting access to his debit card and the bank taking no liability for it. You are free to complain about him whining because you think he should be the one liable not the bank (that is a different, irrelevant argument), but the topic of discussion is that the bank customer is liable not the bank. This means the bank has no incentive to improve their security. In fact, better security probably costs more -- at least the cost of paying someone to figure out how to fix problems with their current procedures -- so they have a direct financial incentive to keep the security at the current status quo. Although, if the other banks improve, competition may force them to make changes.
The difference is who has the right to ask for the source. The GPL says anyone who gets the binaries can ask for the source. The Affero GPL says that anyone who connects to the program running on a server can ask for the source.
*Checks Wikipedia to make sure a "depth queue" isn't some advanced data structure he has never heard of.
A person is smart. People are dumb, panicky, dangerous animals, and you know it.
Ah, I was thinking about the privacy/"who owns the data?" concerns with relation to the entity running the service who you are essentially giving your data to, which is a real legal issue considering most services seem to claim more rights than they need. But that is a different discussion. The government, on the other hand, should never be looking at anyone's data without a warrant (or, in the worst case, an after-the-fact review by the FISA court if it applies to the instance). I apologize for the confusion. I do not think I actually disagree with you.
There is the pretty clear difference in that your password is not a "lock" on your data. It is simply how you let the service know it is okay to send your data over the internet and let you edit it. An actual lock for "cloud" services would be for the data to be encrypted and only decrypted client-side.
Perhaps somehow it could be decrypted by Javascript with a passphrase entered client-side. There are lots of problems with that approach the main two that occur to me are (1) the service probably wants to serve ads based off your data, which it cannot do if it only has encrypted copies and (2) there is no way for the user to tell the difference between what I described and the current process of logging into Google Docs.
On the other hand, it might work okay for using S3 as file server like another poster mentioned. Unfortunately, if the data is encrypted, then it has to be decrypted on the computer doing the calculations. I suppose an encrypted index could be stored on the S3 file server, but this seems like it is getting a bit ridiculous.
To be fair, WoW and Steam do support downloading a lot of game content over the internet. Actually playing them probably does not use much bandwidth, though.
You could use a script like the one Wikimedia Commons has which detects the client's supported players and selects one. It would probably be trivial to add a Flash check in addition to the others and fall back to FLV if necessary. The script will use the <video> element if it can. On my system it uses the Totem browser plugin.
Firefox will use the platform's normal video support according to this blog post. That is, DirectShow on Windows, QuickTime on Mac, and gstreamer on Linux. H.264 is supported by all of those with the proper plugins, but that gets us right back to the reason why the popular video sites do not use <embed> or <object> which sites used to do for video before FLV became popular and some sites still do: the client has to have the right codecs. Getting the user to have Flash installed is, in practice, easier than getting them to have the right video codecs despite how annoying the Flash requirement may be for the small minority of users who do not use Windows or Mac OS X or simply want the web to be sane and non-proprietary.
This site has been barred from the bugmenot system.