Yes, that is how you can be certain (up to the strength of your encryption algorithm). The in-between is the "maybe". That is, sure someone could be sniffing, but you are making it take more work.
As I said in a later post, self-signed certs are better than plain-text. Not much better, but they are better. They require the man-in-the-middle to start on the first first time you connect to a given server and continue for every subsequent visit in order to be completely undetected. Of course, if you notice much later, then you still have let a lot of data get through to the attacker. If you really cared about that data, you would have verified the certificate or avoided using an unprotected connection. (I think most users know that they should not submit credit card info if there is no lock icon.)
Bullshit, a self signed cert contains almost *NO* protection at all compared to a pure plaintext session. If anything, firefox needs to be more paranoid about things like sending things like session cookies, and posts with password fields in clear text.
When a cert failure occurs, there needs to be more than just an "OK" button to click through.
If you want proof, just sit at an airport with cain open for an hour. I think someone like you would be shocked at how many VPN and email credentials for some major fortune 500 companies you can grab.
Thank you for providing the best argument for more self-signed certs/opportunistic encryption. Self-signed certs provide security in two main ways (relative to plain unencrypted HTTP):
Eavesdroppers must be active. The number of sessions they can watch at a time is limited by CPU and outgoing bandwidth. They cannot disconnect before a session ends, which leads into
Although you cannot verify the server the first time, you can verify that you are connecting to the same server every other time. If those people in the airport on their laptops used such methods then almost certainly their first connection to those servers would have been from inside their corporate network where there are almost definitely no attackers. Then later in the airport, if someone tried to eavesdrop, their computers would notice the self-signed cert had a different signature than expected and would refuse to send any sensitive information.
On the other hand, something like davidwr's proposal should be used to make sure self-signed sites do not instill much more trust in users than a plain HTTP site because, as you said, it still provides no real guarantees.
Yes, you are right. The problem is that there should be a level of security in between. As davidwr's comment above suggests, we should not make an unverified encrypted session look like a verified one, but as I discussed in a previous post, it does do some good to encrypt. In addition to what I said there, you have the SSH-style key verification mechanism: if the certificate is different from the last time, the browser should be very unhappy. (Unless the old certificate has already expired, of course.)
True, it is still possible that someone is eavesdropping, but the difference is that passive eavesdropping is no longer enough. It is the same as the idea behind opportunistic encryption: eavesdropping is not impossible, but by making it require active effort, it is a lot harder.
Would a weather channel and Tetris and E-mail app be cool? Sure. Oh yeah, those don't require 3D acceleration and will all run very happily in 256MB of RAM.
You mean like how CDs with DRM are not allowed to show the trademarked CD logo because the DRM breaks the audio CD specification in some subtle way, but no one notices and everyone just buys those CDs anyway?
One of the reasons for copyrights (and patents too) is to reduce reliance on trade secrets.
Wrong. The reason "for copyrights" is to spur creativity, while patents are meant to spur the distribution of ideas. Hence, trade secrets are only related to patents, not copyrights.
I think Microsoft would disagree if someone released the source to their WMP DRM. I suspect they consider the details of how it works a trade secret which they would not be willing to patent with a precise description of how it works.
Even with the original copyright term of 14+14 years, by the end of term, the executables of any software would be unusable without the help of some sort of specialized backwards compatibility software like an emulator or WoW, wine, etc. On the other hand, given the source code, the software could possibly be updated to run on modern systems and may have some use.
On the other hand, the idea of releasing source with every copyright protected program would be a problem for trade secrets as you said and probably for other reasons. I remember another post had once suggested the solution that the source code could go on file with the Library of Congress but only be released for public viewing once the copyright had expired.
Re:Require digital signing; people will catch on f
on
Spammers Choose GMail
·
· Score: 1
At least if you have some sort of trust infrastructure (web of trust or paid signing like SSL certs), then completely untrusted e-mail gets a bump to its spam score. If such a system were in place long enough, then any real person would have their key signed by a lot of people.
There is a major problem with this idea, though: if spammers can take over computers to send spam from them, it is probably not much more work to sign their key with that user's key. Other users could sign an assertion that that key is being used for spam, but I suspect that would not be effective, especially because spammers have access to a lot of computers.
The other way keys help is that if people usually know their recipient's key, then any e-mail sent to only one person and not encrypted with their key is suspect. Encrypting each message separately would make sending spam a good amount more computationally expensive.
How responsable would you be for the content stored on your Nano Data Center... I can see tons and tons of lawsuits.
This is why freenet encrypts. I do not see how a network like this could get around that with current copyright laws.
This could be a good way to distribute malware, being that we'd (presumably) have access to someone else's data within our datacenter. What would stop me from replacing the content of the datacenter side of my box. Physical access is a bad idea.
Of course, getting a random untrusted party to distribute your data for you is a bad idea. The solutions include (1) using a big semi-trusted party like is common now (YouTube, Flickr, etc.), (2) only having trusted parties host your data (doesn't help much because the person viewing your data does not know who you trust and if they did you could just use option (3)), (3) sign the data. By signing it, the viewer just needs your key and a web of trust leading to you to verify they have the right data and not some substituted malware. (Of course, the original data could be malware.)
There is also a privacy issue. If we know what is on our datacenter, we could track incoming requests and build a database of users/ips that like whatever content we are serving.
That is a serious problem. Using something like tor or freenet to avoid it just slows things down too much.
What about advances in hyrdogen fuel cell technology to the point where your water heater is replaced by a combination unit that heats water for your house, and also supplies electricity, yet still runs off of natural gas (BTW this is available in Japan as we speak)?
Probably Singularity, F#, Spec#, Sing#,.... Actually, just look at their Wikipedia page yourself: Microsoft Research. I may not be a big fan of Windows (see: my sig), but Microsoft Research does some cool stuff.
No, really, you don't. You mean, you like that you can avoid command line and do everything via GUIs easily. That is a good goal, but it should not be accomplished by making monolithic GUI programs. That goes against an important part of the Unix philosophy which is sorely missing from many modern GUIs: "Write programs that do one thing and do it well." If the CLI uses the same code as the GUI (or the GUI is just a fancy frontend for the CLI as is the case for some CD/DVD ripping programs I have used on Linux), then you have less duplication of effort, and therefore instead of different GUIs spending their time reimplementing the same functionality they could spend time perfecting their interfaces.
Google does not want to use zero knowledge apps for anything because in addition to using the user information to make recommendations to keep users on their site longer, they use it to decide which ads to display. Also, I am not sure how well zero knowledge concepts mix with search applications where the server is basing its decisions on a huge index.
What is with the Twitter hate? Seriously, I want to know. I have barely encountered Twitter, and I have certainly not seen any "hype" about it, so maybe I just missed a wave of annoying news articles about it.
The only use of Twitter I have seen is Fred of MegaTokyo's status feed which gives info on how far along Fred is with a comic or why a comic is late. Anyone who is familiar with MegaTokyo is probably familiar with MegaTokyo's common delays, so this info is very useful. The three most recent Twitter statuses appear on the website.
Another poster mentioned that he also has a Twitter feed for website status and has the most recent one appear on the site.
I usually see jokes about constant status updates via Twitter, but, well, no one is forcing you to read them; they are for the people who care about that person's status. Occasionally I am interested in when the next MegaTokyo comic will be posted, so I check his Twitter. I do not see how this is much different from IM status messages: usually if I want to get a vague idea of what my friends are up to, I can check their AIM away messages.
You mean, "parallel programming is hard with current popular programming languages/libraries. Instead of going down to C for the parts of your program that need to be fast/parallelized, use a functional programming language or Erlang, and the compiler can automatically parallelize the parts of your program for which that is easy. Microsoft recently added F# to their collection of.NET languages to make this easier for.NET developers. Or if if you do not want to change languages, consider libraries like ThreadWeaver which try to make threading easier.
Copyleft is a technical term in the field of copyright licenses. The GPLv3 (like the GPLv2) is a copyleft license. It seems proper for them to use the term.
It means the code can not be in Ubuntu, Red Hat, SUSE, or Xandros because they all have commercial versions. In addition, the related free as in a beer distros related to them would also stay away from them: Fedora, Debian, etc.
The paradigm they're talking about is one in which users get a service from someone running a rack full of servers. For instance, if I write a letter in my web-app word-processor, somewhere there's got to be a server that's storing my document. The person running the service needs to pay their elecric bill. How are they going to do it? Well, they could make their users look at ads, but that won't work if the app is really user-modifiable, because someone will come out with a version that doesn't show the ads. They could charge the user a monthly fee, but that won't work, because the article proposes to set up the service so that the provider knows absolutely nothing about the user, not even his username.
There is a difference though. If the data is really securely encrypted, then it could be transferred to a server under someone else's control because it is not really sensitive. That is, you do not need a single entity capable of hosting the data of everyone who wants to use Clipperz-style applications. Some sort of load-balancing could be used involving mirroring data on other servers and distributing users among servers. Perhaps the main server could server just serve a checksum and a redirect.
If the apps can be made distributed in this fashion, then a large network of servers donating a small amount of CPU/bandwidth each could possibly support the application. Remember that the server really only has to serve the static Javascript code/HTML/images for the application in additional to acting as a storage and retrieval system for encrypted chunks of data (the latter being the hard part)
The idea behind Clipperz's "zero-knowledge" systems is to limit privacy concerns by limiting what data the web server even has. If the web server does not have your data (in a readable, unencrypted form), then it does not matter what privacy legislation is or is not in effect, especially considering, as another poster pointed out, that the internet is global and there could be several country's laws affecting any given transaction.
Slashdot Mirror
Yes, that is how you can be certain (up to the strength of your encryption algorithm). The in-between is the "maybe". That is, sure someone could be sniffing, but you are making it take more work.
As I said in a later post, self-signed certs are better than plain-text. Not much better, but they are better. They require the man-in-the-middle to start on the first first time you connect to a given server and continue for every subsequent visit in order to be completely undetected. Of course, if you notice much later, then you still have let a lot of data get through to the attacker. If you really cared about that data, you would have verified the certificate or avoided using an unprotected connection. (I think most users know that they should not submit credit card info if there is no lock icon.)
Bullshit, a self signed cert contains almost *NO* protection at all compared to a pure plaintext session. If anything, firefox needs to be more paranoid about things like sending things like session cookies, and posts with password fields in clear text.
When a cert failure occurs, there needs to be more than just an "OK" button to click through.
If you want proof, just sit at an airport with cain open for an hour. I think someone like you would be shocked at how many VPN and email credentials for some major fortune 500 companies you can grab.
Thank you for providing the best argument for more self-signed certs/opportunistic encryption. Self-signed certs provide security in two main ways (relative to plain unencrypted HTTP):
On the other hand, something like davidwr's proposal should be used to make sure self-signed sites do not instill much more trust in users than a plain HTTP site because, as you said, it still provides no real guarantees.
Yes, you are right. The problem is that there should be a level of security in between. As davidwr's comment above suggests, we should not make an unverified encrypted session look like a verified one, but as I discussed in a previous post, it does do some good to encrypt. In addition to what I said there, you have the SSH-style key verification mechanism: if the certificate is different from the last time, the browser should be very unhappy. (Unless the old certificate has already expired, of course.)
True, it is still possible that someone is eavesdropping, but the difference is that passive eavesdropping is no longer enough. It is the same as the idea behind opportunistic encryption: eavesdropping is not impossible, but by making it require active effort, it is a lot harder.
Would a weather channel and Tetris and E-mail app be cool? Sure. Oh yeah, those don't require 3D acceleration and will all run very happily in 256MB of RAM.
(Emphasis added)
You haven't used the Wii's weather channel, have you?
You mean like how CDs with DRM are not allowed to show the trademarked CD logo because the DRM breaks the audio CD specification in some subtle way, but no one notices and everyone just buys those CDs anyway?
One of the reasons for copyrights (and patents too) is to reduce reliance on trade secrets.
Wrong. The reason "for copyrights" is to spur creativity, while patents are meant to spur the distribution of ideas. Hence, trade secrets are only related to patents, not copyrights.
I think Microsoft would disagree if someone released the source to their WMP DRM. I suspect they consider the details of how it works a trade secret which they would not be willing to patent with a precise description of how it works.
Even with the original copyright term of 14+14 years, by the end of term, the executables of any software would be unusable without the help of some sort of specialized backwards compatibility software like an emulator or WoW, wine, etc. On the other hand, given the source code, the software could possibly be updated to run on modern systems and may have some use.
On the other hand, the idea of releasing source with every copyright protected program would be a problem for trade secrets as you said and probably for other reasons. I remember another post had once suggested the solution that the source code could go on file with the Library of Congress but only be released for public viewing once the copyright had expired.
At least if you have some sort of trust infrastructure (web of trust or paid signing like SSL certs), then completely untrusted e-mail gets a bump to its spam score. If such a system were in place long enough, then any real person would have their key signed by a lot of people.
There is a major problem with this idea, though: if spammers can take over computers to send spam from them, it is probably not much more work to sign their key with that user's key. Other users could sign an assertion that that key is being used for spam, but I suspect that would not be effective, especially because spammers have access to a lot of computers.
The other way keys help is that if people usually know their recipient's key, then any e-mail sent to only one person and not encrypted with their key is suspect. Encrypting each message separately would make sending spam a good amount more computationally expensive.
How responsable would you be for the content stored on your Nano Data Center... I can see tons and tons of lawsuits.
This is why freenet encrypts. I do not see how a network like this could get around that with current copyright laws.
This could be a good way to distribute malware, being that we'd (presumably) have access to someone else's data within our datacenter. What would stop me from replacing the content of the datacenter side of my box. Physical access is a bad idea.
Of course, getting a random untrusted party to distribute your data for you is a bad idea. The solutions include (1) using a big semi-trusted party like is common now (YouTube, Flickr, etc.), (2) only having trusted parties host your data (doesn't help much because the person viewing your data does not know who you trust and if they did you could just use option (3)), (3) sign the data. By signing it, the viewer just needs your key and a web of trust leading to you to verify they have the right data and not some substituted malware. (Of course, the original data could be malware.)
There is also a privacy issue. If we know what is on our datacenter, we could track incoming requests and build a database of users/ips that like whatever content we are serving.
That is a serious problem. Using something like tor or freenet to avoid it just slows things down too much.
What about advances in hyrdogen fuel cell technology to the point where your water heater is replaced by a combination unit that heats water for your house, and also supplies electricity, yet still runs off of natural gas (BTW this is available in Japan as we speak)?
Sounds cool, link?
Probably Singularity, F#, Spec#, Sing#, .... Actually, just look at their Wikipedia page yourself: Microsoft Research. I may not be a big fan of Windows (see: my sig), but Microsoft Research does some cool stuff.
No, really, you don't. You mean, you like that you can avoid command line and do everything via GUIs easily. That is a good goal, but it should not be accomplished by making monolithic GUI programs. That goes against an important part of the Unix philosophy which is sorely missing from many modern GUIs: "Write programs that do one thing and do it well." If the CLI uses the same code as the GUI (or the GUI is just a fancy frontend for the CLI as is the case for some CD/DVD ripping programs I have used on Linux), then you have less duplication of effort, and therefore instead of different GUIs spending their time reimplementing the same functionality they could spend time perfecting their interfaces.
Google does not want to use zero knowledge apps for anything because in addition to using the user information to make recommendations to keep users on their site longer, they use it to decide which ads to display. Also, I am not sure how well zero knowledge concepts mix with search applications where the server is basing its decisions on a huge index.
What is with the Twitter hate? Seriously, I want to know. I have barely encountered Twitter, and I have certainly not seen any "hype" about it, so maybe I just missed a wave of annoying news articles about it.
The only use of Twitter I have seen is Fred of MegaTokyo's status feed which gives info on how far along Fred is with a comic or why a comic is late. Anyone who is familiar with MegaTokyo is probably familiar with MegaTokyo's common delays, so this info is very useful. The three most recent Twitter statuses appear on the website.
Another poster mentioned that he also has a Twitter feed for website status and has the most recent one appear on the site.
I usually see jokes about constant status updates via Twitter, but, well, no one is forcing you to read them; they are for the people who care about that person's status. Occasionally I am interested in when the next MegaTokyo comic will be posted, so I check his Twitter. I do not see how this is much different from IM status messages: usually if I want to get a vague idea of what my friends are up to, I can check their AIM away messages.
Nobody is paying the computer manufacturers to install Firefox, so they're not bothering to install Firefox.
Mozilla has a ton of money lying around from Google. They could pay them.
Well, parallel programming is hard.
You mean, "parallel programming is hard with current popular programming languages/libraries. Instead of going down to C for the parts of your program that need to be fast/parallelized, use a functional programming language or Erlang, and the compiler can automatically parallelize the parts of your program for which that is easy. Microsoft recently added F# to their collection of .NET languages to make this easier for .NET developers. Or if if you do not want to change languages, consider libraries like ThreadWeaver which try to make threading easier.
Intel is finally catching up to AMD on that front with Nehalem.
Copyleft is a technical term in the field of copyright licenses. The GPLv3 (like the GPLv2) is a copyleft license. It seems proper for them to use the term.
The SWF 9 spec was linked from the /. summary. Is it really so much trouble to finish reading the summary before posting?
Yeah, I know, I know. I must be new here.
It means the code can not be in Ubuntu, Red Hat, SUSE, or Xandros because they all have commercial versions. In addition, the related free as in a beer distros related to them would also stay away from them: Fedora, Debian, etc.
That is what Firefox 3 does with self-signed SSL certs.
Built-in? Included maybe, but what is the point of having an extension that works fine as an extension built-in?
The paradigm they're talking about is one in which users get a service from someone running a rack full of servers. For instance, if I write a letter in my web-app word-processor, somewhere there's got to be a server that's storing my document. The person running the service needs to pay their elecric bill. How are they going to do it? Well, they could make their users look at ads, but that won't work if the app is really user-modifiable, because someone will come out with a version that doesn't show the ads. They could charge the user a monthly fee, but that won't work, because the article proposes to set up the service so that the provider knows absolutely nothing about the user, not even his username.
There is a difference though. If the data is really securely encrypted, then it could be transferred to a server under someone else's control because it is not really sensitive. That is, you do not need a single entity capable of hosting the data of everyone who wants to use Clipperz-style applications. Some sort of load-balancing could be used involving mirroring data on other servers and distributing users among servers. Perhaps the main server could server just serve a checksum and a redirect.
If the apps can be made distributed in this fashion, then a large network of servers donating a small amount of CPU/bandwidth each could possibly support the application. Remember that the server really only has to serve the static Javascript code/HTML/images for the application in additional to acting as a storage and retrieval system for encrypted chunks of data (the latter being the hard part)
The idea behind Clipperz's "zero-knowledge" systems is to limit privacy concerns by limiting what data the web server even has. If the web server does not have your data (in a readable, unencrypted form), then it does not matter what privacy legislation is or is not in effect, especially considering, as another poster pointed out, that the internet is global and there could be several country's laws affecting any given transaction.