<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_01_18_1535222</id>
	<title>What's Holding Back Encryption?</title>
	<author>CmdrTaco</author>
	<datestamp>1263831240000</datestamp>
	<htmltext><a href="mailto:nine.times@gmail.com" rel="nofollow">nine-times</a> writes <i>"After many years in IT, I've been surprised to notice how much of my traffic is still unencrypted.  A lot of businesses that I interact with (both business and personal) are still using unencrypted FTP, and very few people use any kind of encryption for email.  Most websites are still using unencrypted HTTP.  DNSSEC seems to be picking up some steam, but still doesn't seem to be widely used.  I would have thought there would be a concerted effort to move toward encryption for the sake of security, but it doesn't seem to be happening.
I wanted to ask the Slashdot community, what do you think the hold up is?  Are the existing protocols somehow not good enough?  Are the protocols fine, but not supported well enough in software?  Is it too complicated to manage the various encryption protocols and keys?  Is it ignorance or apathy on the part of the IT community, and that we've failed to demand it from our vendors?"</i></htmltext>
<tokenext>nine-times writes " After many years in IT , I 've been surprised to notice how much of my traffic is still unencrypted .
A lot of businesses that I interact with ( both business and personal ) are still using unencrypted FTP , and very few people use any kind of encryption for email .
Most websites are still using unencrypted HTTP .
DNSSEC seems to be picking up some steam , but still does n't seem to be widely used .
I would have thought there would be a concerted effort to move toward encryption for the sake of security , but it does n't seem to be happening .
I wanted to ask the Slashdot community , what do you think the hold up is ?
Are the existing protocols somehow not good enough ?
Are the protocols fine , but not supported well enough in software ?
Is it too complicated to manage the various encryption protocols and keys ?
Is it ignorance or apathy on the part of the IT community , and that we 've failed to demand it from our vendors ?
"</tokentext>
<sentencetext>nine-times writes "After many years in IT, I've been surprised to notice how much of my traffic is still unencrypted.
A lot of businesses that I interact with (both business and personal) are still using unencrypted FTP, and very few people use any kind of encryption for email.
Most websites are still using unencrypted HTTP.
DNSSEC seems to be picking up some steam, but still doesn't seem to be widely used.
I would have thought there would be a concerted effort to move toward encryption for the sake of security, but it doesn't seem to be happening.
I wanted to ask the Slashdot community, what do you think the hold up is?
Are the existing protocols somehow not good enough?
Are the protocols fine, but not supported well enough in software?
Is it too complicated to manage the various encryption protocols and keys?
Is it ignorance or apathy on the part of the IT community, and that we've failed to demand it from our vendors?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809830</id>
	<title>Re:Costs?</title>
	<author>zn0k</author>
	<datestamp>1263839460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>(Oh, and bass-ackward companies like Apple are also holding back encryption. The iPhone can't do Secure Email after all this time? Really, Apple? Really?)</p></div></blockquote><p>It does IMAP over SSL, POP3 over SSL, SMTP over SSL and ActiveSync over SSL. What else do you need it to do?</p></div>
	</htmltext>
<tokenext>( Oh , and bass-ackward companies like Apple are also holding back encryption .
The iPhone ca n't do Secure Email after all this time ?
Really , Apple ?
Really ? ) It does IMAP over SSL , POP3 over SSL , SMTP over SSL and ActiveSync over SSL .
What else do you need it to do ?</tokentext>
<sentencetext>(Oh, and bass-ackward companies like Apple are also holding back encryption.
The iPhone can't do Secure Email after all this time?
Really, Apple?
Really?)It does IMAP over SSL, POP3 over SSL, SMTP over SSL and ActiveSync over SSL.
What else do you need it to do?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810362</id>
	<title>Re:Costs?</title>
	<author>TheRaven64</author>
	<datestamp>1263841980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Depends on what you mean by encrypted mail.  If you're talking S/MIME, then you're probably right. Most, however, can do IMAP and SMTP over TLS.  For a corporate network, you can do the signing on the server for outgoing mail (after authenticating the SMTP connection) and verify S/MIME signatures for incoming mail before it hits the user's inbox.</htmltext>
<tokenext>Depends on what you mean by encrypted mail .
If you 're talking S/MIME , then you 're probably right .
Most , however , can do IMAP and SMTP over TLS .
For a corporate network , you can do the signing on the server for outgoing mail ( after authenticating the SMTP connection ) and verify S/MIME signatures for incoming mail before it hits the user 's inbox .</tokentext>
<sentencetext>Depends on what you mean by encrypted mail.
If you're talking S/MIME, then you're probably right.
Most, however, can do IMAP and SMTP over TLS.
For a corporate network, you can do the signing on the server for outgoing mail (after authenticating the SMTP connection) and verify S/MIME signatures for incoming mail before it hits the user's inbox.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810832</id>
	<title>Complexity</title>
	<author>pr0f3550r</author>
	<datestamp>1263844260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>People don't understand encryption and so they don't use/insist on it. Moreover, it is usually that thing that gets in the way when they want to be productive. I once saw the security manager at our company spend months specially crafting a security policy for the company and then sought board approval so that he could reign in the CEO and COO anytime they balked at the policies and procedures put in place. This is the 'iron fist' rule which does more to educate than any other tool. When forced to go through the hoop many times, the process becomes simpler.

The lesson to be learned here is to design systems that security is understood and mandated. That education and knowledge transfer become mandatory and not optional. This also helps to illustrate and point out the stumbling blocks for poorly designed or cumbersome systems.

For instance, ClearOS provides only 2 factor OpenVPN configurations for client VPN access to the network. Because key/password authentication is mandatory, efforts are made so that user key self-service is provided. If another method were provided that caused less friction, then the users would not sufficiently test/validate the process, training, or education of the secure method.</htmltext>
<tokenext>People do n't understand encryption and so they do n't use/insist on it .
Moreover , it is usually that thing that gets in the way when they want to be productive .
I once saw the security manager at our company spend months specially crafting a security policy for the company and then sought board approval so that he could reign in the CEO and COO anytime they balked at the policies and procedures put in place .
This is the 'iron fist ' rule which does more to educate than any other tool .
When forced to go through the hoop many times , the process becomes simpler .
The lesson to be learned here is to design systems that security is understood and mandated .
That education and knowledge transfer become mandatory and not optional .
This also helps to illustrate and point out the stumbling blocks for poorly designed or cumbersome systems .
For instance , ClearOS provides only 2 factor OpenVPN configurations for client VPN access to the network .
Because key/password authentication is mandatory , efforts are made so that user key self-service is provided .
If another method were provided that caused less friction , then the users would not sufficiently test/validate the process , training , or education of the secure method .</tokentext>
<sentencetext>People don't understand encryption and so they don't use/insist on it.
Moreover, it is usually that thing that gets in the way when they want to be productive.
I once saw the security manager at our company spend months specially crafting a security policy for the company and then sought board approval so that he could reign in the CEO and COO anytime they balked at the policies and procedures put in place.
This is the 'iron fist' rule which does more to educate than any other tool.
When forced to go through the hoop many times, the process becomes simpler.
The lesson to be learned here is to design systems that security is understood and mandated.
That education and knowledge transfer become mandatory and not optional.
This also helps to illustrate and point out the stumbling blocks for poorly designed or cumbersome systems.
For instance, ClearOS provides only 2 factor OpenVPN configurations for client VPN access to the network.
Because key/password authentication is mandatory, efforts are made so that user key self-service is provided.
If another method were provided that caused less friction, then the users would not sufficiently test/validate the process, training, or education of the secure method.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810406</id>
	<title>Encryption Ensmyption</title>
	<author>wtbname</author>
	<datestamp>1263842160000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p>I'd settle for my damn financial sites not forcing me to arbitrary length limited passwords with only alpha numeric characters.</p><p>SPECIAL CHARACTERS and spaces ARE VALID PASSWORD CHARACTERS. STOP LIMITING MY CHOICE IN PASSWORDS.</p><p>If I want to set my password to</p><p>"*?@&gt;     $}}\% v      ^{@:&gt;#     &gt;&gt;@@*     &amp;&amp;^\%      &pound;&#220;&#196;-AbN-</p><p>Your site needs to accept that.</p></htmltext>
<tokenext>I 'd settle for my damn financial sites not forcing me to arbitrary length limited passwords with only alpha numeric characters.SPECIAL CHARACTERS and spaces ARE VALID PASSWORD CHARACTERS .
STOP LIMITING MY CHOICE IN PASSWORDS.If I want to set my password to " * ?
@ &gt; $ } } \ % v ^ { @ : &gt; # &gt; &gt; @ @ * &amp;&amp; ^ \ %       -AbN-Your site needs to accept that .</tokentext>
<sentencetext>I'd settle for my damn financial sites not forcing me to arbitrary length limited passwords with only alpha numeric characters.SPECIAL CHARACTERS and spaces ARE VALID PASSWORD CHARACTERS.
STOP LIMITING MY CHOICE IN PASSWORDS.If I want to set my password to"*?
@&gt;     $}}\% v      ^{@:&gt;#     &gt;&gt;@@*     &amp;&amp;^\%      £ÜÄ-AbN-Your site needs to accept that.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816782</id>
	<title>Re:Costs?</title>
	<author>Dan541</author>
	<datestamp>1263932340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p> Training everyone to exchange S/MIME keys, for example, is just too damn hard.</p></div><p>Many of us are still training people not to download the latest screen savers. Or install the latest cool app that someone was kind enough to email to them.</p></div>
	</htmltext>
<tokenext>Training everyone to exchange S/MIME keys , for example , is just too damn hard.Many of us are still training people not to download the latest screen savers .
Or install the latest cool app that someone was kind enough to email to them .</tokentext>
<sentencetext> Training everyone to exchange S/MIME keys, for example, is just too damn hard.Many of us are still training people not to download the latest screen savers.
Or install the latest cool app that someone was kind enough to email to them.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808996</id>
	<title>Encryption is demanding</title>
	<author>Anonymous</author>
	<datestamp>1263835920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Encryption is pretty demanding on hardware. A normal webserver without a cryptographic accelerator can serve say 100x more webpages unencrypted then with a full HTTPS encryption.</htmltext>
<tokenext>Encryption is pretty demanding on hardware .
A normal webserver without a cryptographic accelerator can serve say 100x more webpages unencrypted then with a full HTTPS encryption .</tokentext>
<sentencetext>Encryption is pretty demanding on hardware.
A normal webserver without a cryptographic accelerator can serve say 100x more webpages unencrypted then with a full HTTPS encryption.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810980</id>
	<title>needs industry to introduce as standard</title>
	<author>DaveGod</author>
	<datestamp>1263844980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>People aren't going to implement encryption, but their software might implement and do it all for them.</p><p>The consumer mindset is that if it was important the software would take care of it for them. If that sounds like criticism, well it is, but not of consumers. They should be right, partly because they think they are paying (in $ or advert eyeballs) for the software to take care of whatever is important, and partly because it simply wont work any other way. It would be pointless if I installed encryption software on my email client, because I'd need to get everyone I email to have compatible encryption and for them to use it.   </p><p>It shouldn't even take much industry co-operation to get the ball rolling, according to <a href="http://www.campaignmonitor.com/stats/email-clients/" title="campaignmonitor.com">this</a> [campaignmonitor.com] more than half of email is conducted through MS clients. Add Yahoo, Google and Apple and you have 90\% (admittedly, some of those clients are quite old). </p></htmltext>
<tokenext>People are n't going to implement encryption , but their software might implement and do it all for them.The consumer mindset is that if it was important the software would take care of it for them .
If that sounds like criticism , well it is , but not of consumers .
They should be right , partly because they think they are paying ( in $ or advert eyeballs ) for the software to take care of whatever is important , and partly because it simply wont work any other way .
It would be pointless if I installed encryption software on my email client , because I 'd need to get everyone I email to have compatible encryption and for them to use it .
It should n't even take much industry co-operation to get the ball rolling , according to this [ campaignmonitor.com ] more than half of email is conducted through MS clients .
Add Yahoo , Google and Apple and you have 90 \ % ( admittedly , some of those clients are quite old ) .</tokentext>
<sentencetext>People aren't going to implement encryption, but their software might implement and do it all for them.The consumer mindset is that if it was important the software would take care of it for them.
If that sounds like criticism, well it is, but not of consumers.
They should be right, partly because they think they are paying (in $ or advert eyeballs) for the software to take care of whatever is important, and partly because it simply wont work any other way.
It would be pointless if I installed encryption software on my email client, because I'd need to get everyone I email to have compatible encryption and for them to use it.
It shouldn't even take much industry co-operation to get the ball rolling, according to this [campaignmonitor.com] more than half of email is conducted through MS clients.
Add Yahoo, Google and Apple and you have 90\% (admittedly, some of those clients are quite old). </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809272</id>
	<title>Encrypting What?</title>
	<author>Anonymous</author>
	<datestamp>1263837060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The techniques discussed here address only the data in transit.  While IO haven't seen anything other than anecdotes, my sense is that the successful attacks have been at the server/database/file level;  i.e., static data.</p><p>There, I've seen the network guys and the application people pointing fingers at each other saying "encryption is HIS job, not mine.", when it's BOTH their jobs, IMO, since different techniques apply.</p></htmltext>
<tokenext>The techniques discussed here address only the data in transit .
While IO have n't seen anything other than anecdotes , my sense is that the successful attacks have been at the server/database/file level ; i.e. , static data.There , I 've seen the network guys and the application people pointing fingers at each other saying " encryption is HIS job , not mine .
" , when it 's BOTH their jobs , IMO , since different techniques apply .</tokentext>
<sentencetext>The techniques discussed here address only the data in transit.
While IO haven't seen anything other than anecdotes, my sense is that the successful attacks have been at the server/database/file level;  i.e., static data.There, I've seen the network guys and the application people pointing fingers at each other saying "encryption is HIS job, not mine.
", when it's BOTH their jobs, IMO, since different techniques apply.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809306</id>
	<title>HTTP(S)? Marketing/profitability &amp; IPv4</title>
	<author>Anonymous</author>
	<datestamp>1263837240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>First, keep in mind that name-based virtual hosting with HTTPS is very limited.  With few exceptions, you're quite restricted in your ability to host multiple SSL-encrypted sites on a single IP address.  Most often, one must instead assign each SSL-encrypted virtualhost to a dedicated IP address.  If every website was, today, to switch to HTTPS-only operation, and if the RIRs were to allow it, we would immediately run out of IPv4 addresses.  You can argue that we should instead be using IPv6, and I might agree, but we're simply not there yet.</p><p>Secondly, performance is a major consideration for many companies. This is especially true for internet marketing &amp; advertising efforts, for whom every millisecond matters in their ability to serve their content.  Advertisers are unlikely to prefer SSL over unencrypted content.  Worse, marketers are those most likely to desire poor security practices in order to gather information and track users, while also being those that provide means of financial sustainability for many sites.  That is, if the marketing companies won't go for it, the companies being paid by the marketing companies won't go for it.</p><p>Thirdly, cookies and other domain-specific security measures may not be functional via HTTPS, depending on the browser's security configuration.  Some browsers provide warnings or block unencrypted content sourced by encrypted pages, or originating from another domain.  These security profile of the browser may be much different for SSL-protected sites than for unencrypted pages.  Ultimately, this would prevent, discourage, and limit advertising efforts which (again) drive the sustainability of many sites.</p></htmltext>
<tokenext>First , keep in mind that name-based virtual hosting with HTTPS is very limited .
With few exceptions , you 're quite restricted in your ability to host multiple SSL-encrypted sites on a single IP address .
Most often , one must instead assign each SSL-encrypted virtualhost to a dedicated IP address .
If every website was , today , to switch to HTTPS-only operation , and if the RIRs were to allow it , we would immediately run out of IPv4 addresses .
You can argue that we should instead be using IPv6 , and I might agree , but we 're simply not there yet.Secondly , performance is a major consideration for many companies .
This is especially true for internet marketing &amp; advertising efforts , for whom every millisecond matters in their ability to serve their content .
Advertisers are unlikely to prefer SSL over unencrypted content .
Worse , marketers are those most likely to desire poor security practices in order to gather information and track users , while also being those that provide means of financial sustainability for many sites .
That is , if the marketing companies wo n't go for it , the companies being paid by the marketing companies wo n't go for it.Thirdly , cookies and other domain-specific security measures may not be functional via HTTPS , depending on the browser 's security configuration .
Some browsers provide warnings or block unencrypted content sourced by encrypted pages , or originating from another domain .
These security profile of the browser may be much different for SSL-protected sites than for unencrypted pages .
Ultimately , this would prevent , discourage , and limit advertising efforts which ( again ) drive the sustainability of many sites .</tokentext>
<sentencetext>First, keep in mind that name-based virtual hosting with HTTPS is very limited.
With few exceptions, you're quite restricted in your ability to host multiple SSL-encrypted sites on a single IP address.
Most often, one must instead assign each SSL-encrypted virtualhost to a dedicated IP address.
If every website was, today, to switch to HTTPS-only operation, and if the RIRs were to allow it, we would immediately run out of IPv4 addresses.
You can argue that we should instead be using IPv6, and I might agree, but we're simply not there yet.Secondly, performance is a major consideration for many companies.
This is especially true for internet marketing &amp; advertising efforts, for whom every millisecond matters in their ability to serve their content.
Advertisers are unlikely to prefer SSL over unencrypted content.
Worse, marketers are those most likely to desire poor security practices in order to gather information and track users, while also being those that provide means of financial sustainability for many sites.
That is, if the marketing companies won't go for it, the companies being paid by the marketing companies won't go for it.Thirdly, cookies and other domain-specific security measures may not be functional via HTTPS, depending on the browser's security configuration.
Some browsers provide warnings or block unencrypted content sourced by encrypted pages, or originating from another domain.
These security profile of the browser may be much different for SSL-protected sites than for unencrypted pages.
Ultimately, this would prevent, discourage, and limit advertising efforts which (again) drive the sustainability of many sites.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812322</id>
	<title>Re:encryption alone</title>
	<author>Anonymous</author>
	<datestamp>1263807840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>But accounts still get compromised left and right.</p></div></blockquote><p>More accurately, the Windows machines of users with Blizzard accounts are compromised left and right as a means to compromise a Blizzard account.   The system gets compromised and then phones home with account credentials as users log in.  Blizzard combats this with a key chain authenticator.  Doesn't stop the machine from being infected but insures that when the user name/password makes it to the wrong hands it is not useful because the attackers don't have the 3rd login credential (which is time sensitive and cryptographically generated by a separate physical device).</p></div>
	</htmltext>
<tokenext>But accounts still get compromised left and right.More accurately , the Windows machines of users with Blizzard accounts are compromised left and right as a means to compromise a Blizzard account .
The system gets compromised and then phones home with account credentials as users log in .
Blizzard combats this with a key chain authenticator .
Does n't stop the machine from being infected but insures that when the user name/password makes it to the wrong hands it is not useful because the attackers do n't have the 3rd login credential ( which is time sensitive and cryptographically generated by a separate physical device ) .</tokentext>
<sentencetext>But accounts still get compromised left and right.More accurately, the Windows machines of users with Blizzard accounts are compromised left and right as a means to compromise a Blizzard account.
The system gets compromised and then phones home with account credentials as users log in.
Blizzard combats this with a key chain authenticator.
Doesn't stop the machine from being infected but insures that when the user name/password makes it to the wrong hands it is not useful because the attackers don't have the 3rd login credential (which is time sensitive and cryptographically generated by a separate physical device).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813844</id>
	<title>Re:Thoughts on Email and DNSSEC</title>
	<author>ThrowAwaySociety</author>
	<datestamp>1263815580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>vanyel,</p><p>Please remove the extraneous text from the bottom of your message. It is unprofessional and may distract outside clients.</p><p>Also, please use our company's standard disclaimer signature, per our policy on email security.</p><p>Thanks,</p><p>Your Boss.</p></htmltext>
<tokenext>vanyel,Please remove the extraneous text from the bottom of your message .
It is unprofessional and may distract outside clients.Also , please use our company 's standard disclaimer signature , per our policy on email security.Thanks,Your Boss .</tokentext>
<sentencetext>vanyel,Please remove the extraneous text from the bottom of your message.
It is unprofessional and may distract outside clients.Also, please use our company's standard disclaimer signature, per our policy on email security.Thanks,Your Boss.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810454</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808980</id>
	<title>The costs overweight the benefits.</title>
	<author>kikito</author>
	<datestamp>1263835860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The same happens with telephone conversations, or radio emissions. Except in some specific cases, it is just not worth the hassle.</p></htmltext>
<tokenext>The same happens with telephone conversations , or radio emissions .
Except in some specific cases , it is just not worth the hassle .</tokentext>
<sentencetext>The same happens with telephone conversations, or radio emissions.
Except in some specific cases, it is just not worth the hassle.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810958</id>
	<title>Re:People don't see the value</title>
	<author>sgrover</author>
	<datestamp>1263844860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><blockquote><div><p>When more people start to realize that it's a good idea to force their opponents into doing expensive and risky things, then they will choose to do that and start to use (poorly-authenticated) key exchange.  Once encryption with poorly-authenticated key exchange becomes more common, people will start to see a benefit to improving their authentication, so they'll attend more key-signing parties, or exert market forces within crippled single-signer systems to have cheaper CAs, or whatever</p></div><div><p>You must live in an ideal world.  Very few people I know even think at this level.  The only way "people" will change is if the tool they use changes.  This IT thing is not so simple that just anybody can understand all aspects of it, and frankly I prefer it that way.  I'd rather a nurse know how to fix ME, than how to fix a computer.  But if you want that nurse to use encryption to make the world more "secure", then you need to make sure the tools do it for them without them needing to know the details.

Now tie in that idea with the concept of lazy programmers.  Until the programming eco system changes so that encryption is the ONLY way to communicate, then the lazy programmers will hold back everyone else.  (I'm not talking about Lazy as in worthless, I'm talking about the concept of achieving a required task with the minimum of effort or costs).  Have you tried to program an encrypted system lately?  It isn't "simple" yet, and probably never will be.  Same as achieving "security" is a nebulous but desirable goal.</p></div></blockquote></div></div>
	</htmltext>
<tokenext>When more people start to realize that it 's a good idea to force their opponents into doing expensive and risky things , then they will choose to do that and start to use ( poorly-authenticated ) key exchange .
Once encryption with poorly-authenticated key exchange becomes more common , people will start to see a benefit to improving their authentication , so they 'll attend more key-signing parties , or exert market forces within crippled single-signer systems to have cheaper CAs , or whateverYou must live in an ideal world .
Very few people I know even think at this level .
The only way " people " will change is if the tool they use changes .
This IT thing is not so simple that just anybody can understand all aspects of it , and frankly I prefer it that way .
I 'd rather a nurse know how to fix ME , than how to fix a computer .
But if you want that nurse to use encryption to make the world more " secure " , then you need to make sure the tools do it for them without them needing to know the details .
Now tie in that idea with the concept of lazy programmers .
Until the programming eco system changes so that encryption is the ONLY way to communicate , then the lazy programmers will hold back everyone else .
( I 'm not talking about Lazy as in worthless , I 'm talking about the concept of achieving a required task with the minimum of effort or costs ) .
Have you tried to program an encrypted system lately ?
It is n't " simple " yet , and probably never will be .
Same as achieving " security " is a nebulous but desirable goal .</tokentext>
<sentencetext>When more people start to realize that it's a good idea to force their opponents into doing expensive and risky things, then they will choose to do that and start to use (poorly-authenticated) key exchange.
Once encryption with poorly-authenticated key exchange becomes more common, people will start to see a benefit to improving their authentication, so they'll attend more key-signing parties, or exert market forces within crippled single-signer systems to have cheaper CAs, or whateverYou must live in an ideal world.
Very few people I know even think at this level.
The only way "people" will change is if the tool they use changes.
This IT thing is not so simple that just anybody can understand all aspects of it, and frankly I prefer it that way.
I'd rather a nurse know how to fix ME, than how to fix a computer.
But if you want that nurse to use encryption to make the world more "secure", then you need to make sure the tools do it for them without them needing to know the details.
Now tie in that idea with the concept of lazy programmers.
Until the programming eco system changes so that encryption is the ONLY way to communicate, then the lazy programmers will hold back everyone else.
(I'm not talking about Lazy as in worthless, I'm talking about the concept of achieving a required task with the minimum of effort or costs).
Have you tried to program an encrypted system lately?
It isn't "simple" yet, and probably never will be.
Same as achieving "security" is a nebulous but desirable goal.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809940</id>
	<title>Re:People don't see the value</title>
	<author>Anonymous</author>
	<datestamp>1263840000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><blockquote><div><p> And people won't be encrypting until they get over their foolish attitude that it's pointless to force attackers to use MitM instead of passive snooping.</p></div> </blockquote></div><p>Yeah. Tell that to browsers.</p><p>BFU encounters HTTPS site with self-signed certificate and what happens? Red site (or even better, site with same design as "timeout/exception") with something like "this could be another site blablabla something like malware blablabla".</p><p>Simple solution for that, just don't use this irritating "s" in http://.</p></div>
	</htmltext>
<tokenext>And people wo n't be encrypting until they get over their foolish attitude that it 's pointless to force attackers to use MitM instead of passive snooping .
Yeah. Tell that to browsers.BFU encounters HTTPS site with self-signed certificate and what happens ?
Red site ( or even better , site with same design as " timeout/exception " ) with something like " this could be another site blablabla something like malware blablabla " .Simple solution for that , just do n't use this irritating " s " in http : // .</tokentext>
<sentencetext> And people won't be encrypting until they get over their foolish attitude that it's pointless to force attackers to use MitM instead of passive snooping.
Yeah. Tell that to browsers.BFU encounters HTTPS site with self-signed certificate and what happens?
Red site (or even better, site with same design as "timeout/exception") with something like "this could be another site blablabla something like malware blablabla".Simple solution for that, just don't use this irritating "s" in http://.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810472</id>
	<title>Re:More direct costs.</title>
	<author>TheRaven64</author>
	<datestamp>1263842460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A self-signed certificate is fine if the certificate is distributed out of band.  For corporate use, you generate a certificate, sign another certificate with it, and then put the original on a USB key in a safe.  Then you put the public key for the first certificate in the trusted CAs list for the image that you use when you install your OS of choice on new machines.  Then you use the second certificate to sign the certificates that you use for your Intranet and your corporate mail servers.  It still costs CPU time (although not a huge amount), but it doesn't cost very much.</htmltext>
<tokenext>A self-signed certificate is fine if the certificate is distributed out of band .
For corporate use , you generate a certificate , sign another certificate with it , and then put the original on a USB key in a safe .
Then you put the public key for the first certificate in the trusted CAs list for the image that you use when you install your OS of choice on new machines .
Then you use the second certificate to sign the certificates that you use for your Intranet and your corporate mail servers .
It still costs CPU time ( although not a huge amount ) , but it does n't cost very much .</tokentext>
<sentencetext>A self-signed certificate is fine if the certificate is distributed out of band.
For corporate use, you generate a certificate, sign another certificate with it, and then put the original on a USB key in a safe.
Then you put the public key for the first certificate in the trusted CAs list for the image that you use when you install your OS of choice on new machines.
Then you use the second certificate to sign the certificates that you use for your Intranet and your corporate mail servers.
It still costs CPU time (although not a huge amount), but it doesn't cost very much.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809012</id>
	<title>One Word:</title>
	<author>louzerr</author>
	<datestamp>1263835980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Verisign.  Because of the ridiculous cost of THEIR certificates, and that browsers don't seem to properly recognize any certs but ones from Verisign.  People either use fake certs (encrypted traffic, but no verification of trust), or simply don't bother.</p><p>Also, because so many sites pull in images and other content from non-origin servers, webmasters do not know how to build a proper SSL site in most cases.  It's tricky to do right (not impossible - just tricky), and most web designers / site administrators simply give up on SSL, rather than try to learn how to implement it properly.</p></htmltext>
<tokenext>Verisign .
Because of the ridiculous cost of THEIR certificates , and that browsers do n't seem to properly recognize any certs but ones from Verisign .
People either use fake certs ( encrypted traffic , but no verification of trust ) , or simply do n't bother.Also , because so many sites pull in images and other content from non-origin servers , webmasters do not know how to build a proper SSL site in most cases .
It 's tricky to do right ( not impossible - just tricky ) , and most web designers / site administrators simply give up on SSL , rather than try to learn how to implement it properly .</tokentext>
<sentencetext>Verisign.
Because of the ridiculous cost of THEIR certificates, and that browsers don't seem to properly recognize any certs but ones from Verisign.
People either use fake certs (encrypted traffic, but no verification of trust), or simply don't bother.Also, because so many sites pull in images and other content from non-origin servers, webmasters do not know how to build a proper SSL site in most cases.
It's tricky to do right (not impossible - just tricky), and most web designers / site administrators simply give up on SSL, rather than try to learn how to implement it properly.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809610</id>
	<title>Re:Seriously?</title>
	<author>OrangeCatholic</author>
	<datestamp>1263838560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Actually I think people do nothing because keeping the internet the same, gets more people online.  It's over 15 years since I got online and it's only in the past year that people know what "Tivo" is.  Hell, if I drove in to Kansas I bet they still don't.  And they sure as hell don't have Tivo in Juarez, Mexico.
<br> <br>
So at what point will there be a critical mass of people online where the internet can evolve again?  Well, we've already seen one evolution - web forums and facebook.  And both of them are stunningly stupid.  The second evolution is YouTube and Hulu.  Err.  I'll take Hulu over Facebook, but these are more likely to kill television than create something superior.
<br> <br>
I don't think IT is low-cost/low-budget.  More like low standards.  And it will only get worse with each new 14-year-old girl or Latina housewife who gets online.  They offer <i>nothing</i> from an IT perspective except end-user testing.  Which is valuable but, they can't build squat themselves.</htmltext>
<tokenext>Actually I think people do nothing because keeping the internet the same , gets more people online .
It 's over 15 years since I got online and it 's only in the past year that people know what " Tivo " is .
Hell , if I drove in to Kansas I bet they still do n't .
And they sure as hell do n't have Tivo in Juarez , Mexico .
So at what point will there be a critical mass of people online where the internet can evolve again ?
Well , we 've already seen one evolution - web forums and facebook .
And both of them are stunningly stupid .
The second evolution is YouTube and Hulu .
Err. I 'll take Hulu over Facebook , but these are more likely to kill television than create something superior .
I do n't think IT is low-cost/low-budget .
More like low standards .
And it will only get worse with each new 14-year-old girl or Latina housewife who gets online .
They offer nothing from an IT perspective except end-user testing .
Which is valuable but , they ca n't build squat themselves .</tokentext>
<sentencetext>Actually I think people do nothing because keeping the internet the same, gets more people online.
It's over 15 years since I got online and it's only in the past year that people know what "Tivo" is.
Hell, if I drove in to Kansas I bet they still don't.
And they sure as hell don't have Tivo in Juarez, Mexico.
So at what point will there be a critical mass of people online where the internet can evolve again?
Well, we've already seen one evolution - web forums and facebook.
And both of them are stunningly stupid.
The second evolution is YouTube and Hulu.
Err.  I'll take Hulu over Facebook, but these are more likely to kill television than create something superior.
I don't think IT is low-cost/low-budget.
More like low standards.
And it will only get worse with each new 14-year-old girl or Latina housewife who gets online.
They offer nothing from an IT perspective except end-user testing.
Which is valuable but, they can't build squat themselves.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810704</id>
	<title>Re:More direct costs.</title>
	<author>TerranFury</author>
	<datestamp>1263843540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>a self-signed certificate is barely better than raw http.</p></div><p>I wouldn't go that far.  It guarantees that nobody can eavesdrop on the conversation you're having.  You just might not be talking to the person you think you're talking to.  That said, once you've stored the cert, it does guarantee that you're talking to the same person you talked to last time.</p><p>For file servers, I think this is fine most of the time.</p><p>I mean, compare this to SSH.  How do you know you're talking to the server you think you're talking to?  ~/.ssh/known\_hosts .  Which behaves exactly as the above.</p></div>
	</htmltext>
<tokenext>a self-signed certificate is barely better than raw http.I would n't go that far .
It guarantees that nobody can eavesdrop on the conversation you 're having .
You just might not be talking to the person you think you 're talking to .
That said , once you 've stored the cert , it does guarantee that you 're talking to the same person you talked to last time.For file servers , I think this is fine most of the time.I mean , compare this to SSH .
How do you know you 're talking to the server you think you 're talking to ?
~ /.ssh/known \ _hosts .
Which behaves exactly as the above .</tokentext>
<sentencetext>a self-signed certificate is barely better than raw http.I wouldn't go that far.
It guarantees that nobody can eavesdrop on the conversation you're having.
You just might not be talking to the person you think you're talking to.
That said, once you've stored the cert, it does guarantee that you're talking to the same person you talked to last time.For file servers, I think this is fine most of the time.I mean, compare this to SSH.
How do you know you're talking to the server you think you're talking to?
~/.ssh/known\_hosts .
Which behaves exactly as the above.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815584</id>
	<title>not necessary most of the time</title>
	<author>Eil</author>
	<datestamp>1263830040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> A lot of businesses that I interact with (both business and personal) are still using unencrypted FTP, and very few people use any kind of encryption for email. Most websites are still using unencrypted HTTP.</p></div></blockquote><p>Not encrypting FTP or email is pretty inexcusable if you're going over the public Internet.</p><p>However, most websites use plaintext HTTP most of the time because there's nothing to hide. It's expected that a site will switch into SSL mode when entering a password or displaying personal or financial information, but other than that, there's really not an incentive to encrypt normal web traffic. If someone snooped on my connection and saw spurts of HTTPS traffic coming from IPs assigned to Slashdot and CNN, all they have to do visit those sites themselves to see what I'm reading.</p><p>(Although I really do wish Slashdot would at least allow logins and comment submissions over SSL.)</p></div>
	</htmltext>
<tokenext>A lot of businesses that I interact with ( both business and personal ) are still using unencrypted FTP , and very few people use any kind of encryption for email .
Most websites are still using unencrypted HTTP.Not encrypting FTP or email is pretty inexcusable if you 're going over the public Internet.However , most websites use plaintext HTTP most of the time because there 's nothing to hide .
It 's expected that a site will switch into SSL mode when entering a password or displaying personal or financial information , but other than that , there 's really not an incentive to encrypt normal web traffic .
If someone snooped on my connection and saw spurts of HTTPS traffic coming from IPs assigned to Slashdot and CNN , all they have to do visit those sites themselves to see what I 'm reading .
( Although I really do wish Slashdot would at least allow logins and comment submissions over SSL .
)</tokentext>
<sentencetext> A lot of businesses that I interact with (both business and personal) are still using unencrypted FTP, and very few people use any kind of encryption for email.
Most websites are still using unencrypted HTTP.Not encrypting FTP or email is pretty inexcusable if you're going over the public Internet.However, most websites use plaintext HTTP most of the time because there's nothing to hide.
It's expected that a site will switch into SSL mode when entering a password or displaying personal or financial information, but other than that, there's really not an incentive to encrypt normal web traffic.
If someone snooped on my connection and saw spurts of HTTPS traffic coming from IPs assigned to Slashdot and CNN, all they have to do visit those sites themselves to see what I'm reading.
(Although I really do wish Slashdot would at least allow logins and comment submissions over SSL.
)
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842</id>
	<title>I'll tell you what it is...</title>
	<author>multipart/mixed</author>
	<datestamp>1263835320000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>...encrypted communications are too bloody hard to debug!</p><p>With unencrypted protocols, I can whip out the packet sniffer and find out *exactly* what's going on. With encrypted protocols, I have to write reports like "we have verified our software configuration and believe it to be correct; perhaps the problem is at your end?"</p><p>Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode.  Maybe even with a "relax the crypto" configuration flag we can throw during debug.</p></htmltext>
<tokenext>...encrypted communications are too bloody hard to debug ! With unencrypted protocols , I can whip out the packet sniffer and find out * exactly * what 's going on .
With encrypted protocols , I have to write reports like " we have verified our software configuration and believe it to be correct ; perhaps the problem is at your end ?
" Maybe we need to come up with a standard way of encrypting things , that our packet sniffers somehow know how to decode .
Maybe even with a " relax the crypto " configuration flag we can throw during debug .</tokentext>
<sentencetext>...encrypted communications are too bloody hard to debug!With unencrypted protocols, I can whip out the packet sniffer and find out *exactly* what's going on.
With encrypted protocols, I have to write reports like "we have verified our software configuration and believe it to be correct; perhaps the problem is at your end?
"Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode.
Maybe even with a "relax the crypto" configuration flag we can throw during debug.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809780</id>
	<title>Re:People don't see the value</title>
	<author>SanityInAnarchy</author>
	<datestamp>1263839280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>using a self-signed cert is barely better than using plaintext.</p></div><p>I'm going to argue that it's potentially <i>worse,</i> because it gives a false sense of security.</p><p><div class="quote"><p>get over their foolish attitude that it's pointless to force attackers to use MitM instead of passive snooping.</p></div><p>It has a point right now, which is more or less security through being a harder target. If you get everyone doing it, I doubt it will help very much -- MitM is painfully easy to do over wireless, and there's at least one freely available tool which does it.</p><p><div class="quote"><p>Once encryption with poorly-authenticated key exchange becomes more common, people will start to see a benefit to improving their authentication,</p></div><p>More likely, people will say, "I'm safe, aren't I? I'm encrypted!" And then they'll go right back to ignoring us.</p><p>Think about anti-virus. We say, "Pay attention to your security!" They say, "Ok, I'll buy some anti-virus!" And then they go right back to watching porn on IE and downloading BonziBuddy.</p><p><div class="quote"><p>exert market forces within crippled single-signer systems to have cheaper CAs,</p></div><p>It costs something on the order of $20/year for a cert. Sure, EV certs cost more, as do wildcard certs, etc, but the base cost isn't bad.</p><p>And yeah, I would much rather see a web-of-trust scheme, or at least some more decentralization of CAs, but that really doesn't seem like the problem here. Remember, we're still talking about pretty much every organization Doing It Wrong -- I'd suggest it has much more to do with getting authorization to pay for <i>anything,</i> and with the hardware costs.</p></div>
	</htmltext>
<tokenext>using a self-signed cert is barely better than using plaintext.I 'm going to argue that it 's potentially worse , because it gives a false sense of security.get over their foolish attitude that it 's pointless to force attackers to use MitM instead of passive snooping.It has a point right now , which is more or less security through being a harder target .
If you get everyone doing it , I doubt it will help very much -- MitM is painfully easy to do over wireless , and there 's at least one freely available tool which does it.Once encryption with poorly-authenticated key exchange becomes more common , people will start to see a benefit to improving their authentication,More likely , people will say , " I 'm safe , are n't I ?
I 'm encrypted !
" And then they 'll go right back to ignoring us.Think about anti-virus .
We say , " Pay attention to your security !
" They say , " Ok , I 'll buy some anti-virus !
" And then they go right back to watching porn on IE and downloading BonziBuddy.exert market forces within crippled single-signer systems to have cheaper CAs,It costs something on the order of $ 20/year for a cert .
Sure , EV certs cost more , as do wildcard certs , etc , but the base cost is n't bad.And yeah , I would much rather see a web-of-trust scheme , or at least some more decentralization of CAs , but that really does n't seem like the problem here .
Remember , we 're still talking about pretty much every organization Doing It Wrong -- I 'd suggest it has much more to do with getting authorization to pay for anything , and with the hardware costs .</tokentext>
<sentencetext>using a self-signed cert is barely better than using plaintext.I'm going to argue that it's potentially worse, because it gives a false sense of security.get over their foolish attitude that it's pointless to force attackers to use MitM instead of passive snooping.It has a point right now, which is more or less security through being a harder target.
If you get everyone doing it, I doubt it will help very much -- MitM is painfully easy to do over wireless, and there's at least one freely available tool which does it.Once encryption with poorly-authenticated key exchange becomes more common, people will start to see a benefit to improving their authentication,More likely, people will say, "I'm safe, aren't I?
I'm encrypted!
" And then they'll go right back to ignoring us.Think about anti-virus.
We say, "Pay attention to your security!
" They say, "Ok, I'll buy some anti-virus!
" And then they go right back to watching porn on IE and downloading BonziBuddy.exert market forces within crippled single-signer systems to have cheaper CAs,It costs something on the order of $20/year for a cert.
Sure, EV certs cost more, as do wildcard certs, etc, but the base cost isn't bad.And yeah, I would much rather see a web-of-trust scheme, or at least some more decentralization of CAs, but that really doesn't seem like the problem here.
Remember, we're still talking about pretty much every organization Doing It Wrong -- I'd suggest it has much more to do with getting authorization to pay for anything, and with the hardware costs.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816346</id>
	<title>Encryption makes it hard to read</title>
	<author>uninformedLuddite</author>
	<datestamp>1263840000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>At least that's what the NSA, CIA, TFI, FBI, DEA, ONI, ATF, CIA, NGA, DHS, DIA, DOD, DOE, INR, NRO, ISR, RIAA, BSAA, and the Children's Television Workshop have all said at some stage.<br>
The <a href="http://www.encyclopedia.com/doc/1P2-602403.html" title="encyclopedia.com" rel="nofollow">DOJ insisted</a> [encyclopedia.com] back in 1999 that its agents need the ability to secretly enter private property and disable security on personal computers. Apparently SELinux has a back door built in using NSAKEY as the password.</htmltext>
<tokenext>At least that 's what the NSA , CIA , TFI , FBI , DEA , ONI , ATF , CIA , NGA , DHS , DIA , DOD , DOE , INR , NRO , ISR , RIAA , BSAA , and the Children 's Television Workshop have all said at some stage .
The DOJ insisted [ encyclopedia.com ] back in 1999 that its agents need the ability to secretly enter private property and disable security on personal computers .
Apparently SELinux has a back door built in using NSAKEY as the password .</tokentext>
<sentencetext>At least that's what the NSA, CIA, TFI, FBI, DEA, ONI, ATF, CIA, NGA, DHS, DIA, DOD, DOE, INR, NRO, ISR, RIAA, BSAA, and the Children's Television Workshop have all said at some stage.
The DOJ insisted [encyclopedia.com] back in 1999 that its agents need the ability to secretly enter private property and disable security on personal computers.
Apparently SELinux has a back door built in using NSAKEY as the password.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812726</id>
	<title>Re:Encryption is too hard</title>
	<author>Anonymous</author>
	<datestamp>1263810000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Re Email..</p><p>It'd be great if a large email provider used TLS for their email</p></htmltext>
<tokenext>Re Email..It 'd be great if a large email provider used TLS for their email</tokentext>
<sentencetext>Re Email..It'd be great if a large email provider used TLS for their email</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809544</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810170</id>
	<title>Re:Costs?</title>
	<author>Anonymous</author>
	<datestamp>1263840960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You don't know what you are talking about.</p></htmltext>
<tokenext>You do n't know what you are talking about .</tokentext>
<sentencetext>You don't know what you are talking about.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810114</id>
	<title>(A)pathetic Users</title>
	<author>Tony Stark</author>
	<datestamp>1263840780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The biggest problem with encryption and security in general is the user.  The user wants everything out of the box and as easy as possible.  I run across way too many home users who don't even have a login password on Windows.  I've been trying to use PGP for email for years but I can't get anyone else I communicate with to use it.  Most likely even if they did, their passphrases would still be things like "password" or any other password no no's.  It's not even a matter of educating the user anymore. A lot of educated users still just don't care.  If it's not something they're interested in, they won't do it.  Striking the balance between convenience and security has become and impossible task because in the end convenience (read: laziness) will trump all.</htmltext>
<tokenext>The biggest problem with encryption and security in general is the user .
The user wants everything out of the box and as easy as possible .
I run across way too many home users who do n't even have a login password on Windows .
I 've been trying to use PGP for email for years but I ca n't get anyone else I communicate with to use it .
Most likely even if they did , their passphrases would still be things like " password " or any other password no no 's .
It 's not even a matter of educating the user anymore .
A lot of educated users still just do n't care .
If it 's not something they 're interested in , they wo n't do it .
Striking the balance between convenience and security has become and impossible task because in the end convenience ( read : laziness ) will trump all .</tokentext>
<sentencetext>The biggest problem with encryption and security in general is the user.
The user wants everything out of the box and as easy as possible.
I run across way too many home users who don't even have a login password on Windows.
I've been trying to use PGP for email for years but I can't get anyone else I communicate with to use it.
Most likely even if they did, their passphrases would still be things like "password" or any other password no no's.
It's not even a matter of educating the user anymore.
A lot of educated users still just don't care.
If it's not something they're interested in, they won't do it.
Striking the balance between convenience and security has become and impossible task because in the end convenience (read: laziness) will trump all.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812138</id>
	<title>Short answer</title>
	<author>Anonymous</author>
	<datestamp>1263807120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>TME.</p></htmltext>
<tokenext>TME .</tokentext>
<sentencetext>TME.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814480</id>
	<title>Re:What's the problem?</title>
	<author>Anonymous</author>
	<datestamp>1263819660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yes, but you still have to worry about a MitM attack where somebody at the post office copies your DVDs.</p><p>If we could just track down and eliminate Mallory, now that would make a difference!</p></htmltext>
<tokenext>Yes , but you still have to worry about a MitM attack where somebody at the post office copies your DVDs.If we could just track down and eliminate Mallory , now that would make a difference !</tokentext>
<sentencetext>Yes, but you still have to worry about a MitM attack where somebody at the post office copies your DVDs.If we could just track down and eliminate Mallory, now that would make a difference!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814266</id>
	<title>Re:Signed certificates</title>
	<author>Anonymous</author>
	<datestamp>1263818040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>On the other hand, encrypting everything has got it's own disadvantages, such as throwing away the entire caching infrastructure for the web.</htmltext>
<tokenext>On the other hand , encrypting everything has got it 's own disadvantages , such as throwing away the entire caching infrastructure for the web .</tokentext>
<sentencetext>On the other hand, encrypting everything has got it's own disadvantages, such as throwing away the entire caching infrastructure for the web.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809134</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813402</id>
	<title>Enough to make it not always worth the effort.</title>
	<author>Red Reaper</author>
	<datestamp>1263813300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As mentioned in a previous post, encryption tends to break many of the other types of security measures we have come to rely upon.

Intrusion prevention and detection systems do not always work with encrypted traffic very well; the same goes for mail and web filters. You cannot always trust that which is encrypted and can be as much of a security risk as it is added security.

Those types of systems capable of scanning encrypted content can present privacy concerns depending on how they are implemented. Additionally, these systems are not always capable of scanning all types of encrypted traffic, particularly when dealing with proprietary implementations or specs that deviate from a standard.

I am not saying that encryption is worthless, however its pros and cons need to be weighed against other aspects of security carefully to ensure that your network gets the best combination of protection and usability that it can have.</htmltext>
<tokenext>As mentioned in a previous post , encryption tends to break many of the other types of security measures we have come to rely upon .
Intrusion prevention and detection systems do not always work with encrypted traffic very well ; the same goes for mail and web filters .
You can not always trust that which is encrypted and can be as much of a security risk as it is added security .
Those types of systems capable of scanning encrypted content can present privacy concerns depending on how they are implemented .
Additionally , these systems are not always capable of scanning all types of encrypted traffic , particularly when dealing with proprietary implementations or specs that deviate from a standard .
I am not saying that encryption is worthless , however its pros and cons need to be weighed against other aspects of security carefully to ensure that your network gets the best combination of protection and usability that it can have .</tokentext>
<sentencetext>As mentioned in a previous post, encryption tends to break many of the other types of security measures we have come to rely upon.
Intrusion prevention and detection systems do not always work with encrypted traffic very well; the same goes for mail and web filters.
You cannot always trust that which is encrypted and can be as much of a security risk as it is added security.
Those types of systems capable of scanning encrypted content can present privacy concerns depending on how they are implemented.
Additionally, these systems are not always capable of scanning all types of encrypted traffic, particularly when dealing with proprietary implementations or specs that deviate from a standard.
I am not saying that encryption is worthless, however its pros and cons need to be weighed against other aspects of security carefully to ensure that your network gets the best combination of protection and usability that it can have.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813032</id>
	<title>Re:Talking out loud ...</title>
	<author>Anonymous</author>
	<datestamp>1263811500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>ever use slang in conversation?  congratulations, you are using a form of verbal encryption.  albeit a weak one.</p></htmltext>
<tokenext>ever use slang in conversation ?
congratulations , you are using a form of verbal encryption .
albeit a weak one .</tokentext>
<sentencetext>ever use slang in conversation?
congratulations, you are using a form of verbal encryption.
albeit a weak one.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809320</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809422</id>
	<title>Because encryption is a bigger problem</title>
	<author>Anonymous</author>
	<datestamp>1263837720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Encryption is a big problem to handle.</p><p>You are more likely to lose your keys than your privacy; there's just so many ways to get it wrong, even on the lowly USB memory stick, and end up losing your own data.</p></htmltext>
<tokenext>Encryption is a big problem to handle.You are more likely to lose your keys than your privacy ; there 's just so many ways to get it wrong , even on the lowly USB memory stick , and end up losing your own data .</tokentext>
<sentencetext>Encryption is a big problem to handle.You are more likely to lose your keys than your privacy; there's just so many ways to get it wrong, even on the lowly USB memory stick, and end up losing your own data.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810454</id>
	<title>Thoughts on Email and DNSSEC</title>
	<author>vanyel</author>
	<datestamp>1263842340000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1</p><p>I've been digitally signing all my email for about 15 years; I *tried* to encrypt all my mail, but I've run into two problems: inertia on the part of other people, and poor application support.  Thunderbird in particular has had a bug report for "encrypt when possible" for years, complete with a detailed operation to address some of the issues, and no one who has development expertise in Thunderbird will implement it.  With that, the people who have keys can start using it regularly and then there's a good reason to get other people to get keys and start using them.  Without it, it's "ok, does this person have a key or not" and it's just too much bother for most.  Thunderbird isn't the only one: I've looked at other mail programs, and it's always all or nothing.  That should be a *choice* (it does have its place), but without a "when possible", there's no graceful transition option.</p><p>Then there's DNSSEC, which I've tried to implement.  It's a voracious consumer of random numbers because of the vast number of keys you need (if you're hosting a large number of domains, as we do).  I bought a usb dongle that is a hardware random number generator, and it *still* takes forever (days) to re-sign our domains, something you are supposed to do monthly.</p><p>FWIW...<br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.9 (Darwin)</p><p>iEYEARECAAYFAktUpfIACgkQIQ3y7i+rW6HDnQCgteApON+rI177T8Ggh8NUPFN0<br>NIIAoP0gOKvUy636m03supXrmDaCDtQZ<br>=9RCk<br>-----END PGP SIGNATURE-----</p></htmltext>
<tokenext>-----BEGIN PGP SIGNED MESSAGE-----Hash : SHA1I 've been digitally signing all my email for about 15 years ; I * tried * to encrypt all my mail , but I 've run into two problems : inertia on the part of other people , and poor application support .
Thunderbird in particular has had a bug report for " encrypt when possible " for years , complete with a detailed operation to address some of the issues , and no one who has development expertise in Thunderbird will implement it .
With that , the people who have keys can start using it regularly and then there 's a good reason to get other people to get keys and start using them .
Without it , it 's " ok , does this person have a key or not " and it 's just too much bother for most .
Thunderbird is n't the only one : I 've looked at other mail programs , and it 's always all or nothing .
That should be a * choice * ( it does have its place ) , but without a " when possible " , there 's no graceful transition option.Then there 's DNSSEC , which I 've tried to implement .
It 's a voracious consumer of random numbers because of the vast number of keys you need ( if you 're hosting a large number of domains , as we do ) .
I bought a usb dongle that is a hardware random number generator , and it * still * takes forever ( days ) to re-sign our domains , something you are supposed to do monthly.FWIW...-----BEGIN PGP SIGNATURE-----Version : GnuPG v1.4.9 ( Darwin ) iEYEARECAAYFAktUpfIACgkQIQ3y7i + rW6HDnQCgteApON + rI177T8Ggh8NUPFN0NIIAoP0gOKvUy636m03supXrmDaCDtQZ = 9RCk-----END PGP SIGNATURE-----</tokentext>
<sentencetext>-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1I've been digitally signing all my email for about 15 years; I *tried* to encrypt all my mail, but I've run into two problems: inertia on the part of other people, and poor application support.
Thunderbird in particular has had a bug report for "encrypt when possible" for years, complete with a detailed operation to address some of the issues, and no one who has development expertise in Thunderbird will implement it.
With that, the people who have keys can start using it regularly and then there's a good reason to get other people to get keys and start using them.
Without it, it's "ok, does this person have a key or not" and it's just too much bother for most.
Thunderbird isn't the only one: I've looked at other mail programs, and it's always all or nothing.
That should be a *choice* (it does have its place), but without a "when possible", there's no graceful transition option.Then there's DNSSEC, which I've tried to implement.
It's a voracious consumer of random numbers because of the vast number of keys you need (if you're hosting a large number of domains, as we do).
I bought a usb dongle that is a hardware random number generator, and it *still* takes forever (days) to re-sign our domains, something you are supposed to do monthly.FWIW...-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.9 (Darwin)iEYEARECAAYFAktUpfIACgkQIQ3y7i+rW6HDnQCgteApON+rI177T8Ggh8NUPFN0NIIAoP0gOKvUy636m03supXrmDaCDtQZ=9RCk-----END PGP SIGNATURE-----</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817308</id>
	<title>Re:Expertise</title>
	<author>Anonymous</author>
	<datestamp>1263896040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Must be real fun typing that username in, eh?</p></htmltext>
<tokenext>Must be real fun typing that username in , eh ?</tokentext>
<sentencetext>Must be real fun typing that username in, eh?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809366</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809676</id>
	<title>Re:encryption alone</title>
	<author>Anonymous</author>
	<datestamp>1263838860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p>is not the whole solution.</p></div><p>Sure, it'd help...  It'd be another layer of protection.  Another bit of security <b>theater</b>.  </p></div><p>FTFY.  As long as the user remains the weakest link, most additional security measures are nothing but theater.  I dont care if your security is a safe, buried 50 feet down in a random desert.  If you write down the location, tell someone the code, etc... it is only security based on the apathy of the attacker.</p></div>
	</htmltext>
<tokenext>is not the whole solution.Sure , it 'd help... It 'd be another layer of protection .
Another bit of security theater .
FTFY. As long as the user remains the weakest link , most additional security measures are nothing but theater .
I dont care if your security is a safe , buried 50 feet down in a random desert .
If you write down the location , tell someone the code , etc... it is only security based on the apathy of the attacker .</tokentext>
<sentencetext>is not the whole solution.Sure, it'd help...  It'd be another layer of protection.
Another bit of security theater.
FTFY.  As long as the user remains the weakest link, most additional security measures are nothing but theater.
I dont care if your security is a safe, buried 50 feet down in a random desert.
If you write down the location, tell someone the code, etc... it is only security based on the apathy of the attacker.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30828922</id>
	<title>Re:What's the purpose of encryption if it's defeat</title>
	<author>bingoUV</author>
	<datestamp>1263929160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Or---when in debugging mode you could send some insensitive unencrypted traffic. That way, people can have their encryption and network debuggers can have their not-encryption.</p></div><p>But the "bug" appears only when the encryption is turned on. Only for data for which encryption is turned on. Now what?</p></div>
	</htmltext>
<tokenext>Or---when in debugging mode you could send some insensitive unencrypted traffic .
That way , people can have their encryption and network debuggers can have their not-encryption.But the " bug " appears only when the encryption is turned on .
Only for data for which encryption is turned on .
Now what ?</tokentext>
<sentencetext>Or---when in debugging mode you could send some insensitive unencrypted traffic.
That way, people can have their encryption and network debuggers can have their not-encryption.But the "bug" appears only when the encryption is turned on.
Only for data for which encryption is turned on.
Now what?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811670</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809522</id>
	<title>Re:Signed certificates</title>
	<author>sjwest</author>
	<datestamp>1263838200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'd be pro if</p><p>1. i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etc<br>2. i could create keys without firefox complaining like two year old about them<br>3. I can do external and internal networks via two cheap network cards - put the price up and maybe we talk<br>4. Im still going to need a firewall, a virus thingy, and a copy of spam assassin<br>5. There's security in obscurity<br>6. I'd rather not have a password like 'Rabbit09876cluckTHE-cHicken' and have to type it in for disk encryption each time, or have truecrypt keyfile of amazing length that probably constitutes a security risk all on its own</p><p>Until the ssl 'industry' comes to its senses or gets replaced I'm happy to do without</p></htmltext>
<tokenext>I 'd be pro if1 .
i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etc2 .
i could create keys without firefox complaining like two year old about them3 .
I can do external and internal networks via two cheap network cards - put the price up and maybe we talk4 .
Im still going to need a firewall , a virus thingy , and a copy of spam assassin5 .
There 's security in obscurity6 .
I 'd rather not have a password like 'Rabbit09876cluckTHE-cHicken ' and have to type it in for disk encryption each time , or have truecrypt keyfile of amazing length that probably constitutes a security risk all on its ownUntil the ssl 'industry ' comes to its senses or gets replaced I 'm happy to do without</tokentext>
<sentencetext>I'd be pro if1.
i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etc2.
i could create keys without firefox complaining like two year old about them3.
I can do external and internal networks via two cheap network cards - put the price up and maybe we talk4.
Im still going to need a firewall, a virus thingy, and a copy of spam assassin5.
There's security in obscurity6.
I'd rather not have a password like 'Rabbit09876cluckTHE-cHicken' and have to type it in for disk encryption each time, or have truecrypt keyfile of amazing length that probably constitutes a security risk all on its ownUntil the ssl 'industry' comes to its senses or gets replaced I'm happy to do without</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808800</id>
	<title>Nutshell</title>
	<author>Anonymous</author>
	<datestamp>1263835080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Businesses don't give a shit about encryption because there isn't any accountability on their part.</p><p>Your information is stolen? Too fucking bad. That's your problem. </p><p>Show me one company that got sued or whatever and had to pay for their stupidity with regards to information being stolen or lost.</p></htmltext>
<tokenext>Businesses do n't give a shit about encryption because there is n't any accountability on their part.Your information is stolen ?
Too fucking bad .
That 's your problem .
Show me one company that got sued or whatever and had to pay for their stupidity with regards to information being stolen or lost .</tokentext>
<sentencetext>Businesses don't give a shit about encryption because there isn't any accountability on their part.Your information is stolen?
Too fucking bad.
That's your problem.
Show me one company that got sued or whatever and had to pay for their stupidity with regards to information being stolen or lost.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808902</id>
	<title>it's all about perception</title>
	<author>cybernga</author>
	<datestamp>1263835500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>since most people consider their daily transactions ( FTP , mail , what-have-you ) safe, there is no need to go for anything more

even if the IT staff understands the risks, any attempt to actually implement something will cause a stone-throwing for "breaking something that was working just fine" even if the downtime is minimal.</htmltext>
<tokenext>since most people consider their daily transactions ( FTP , mail , what-have-you ) safe , there is no need to go for anything more even if the IT staff understands the risks , any attempt to actually implement something will cause a stone-throwing for " breaking something that was working just fine " even if the downtime is minimal .</tokentext>
<sentencetext>since most people consider their daily transactions ( FTP , mail , what-have-you ) safe, there is no need to go for anything more

even if the IT staff understands the risks, any attempt to actually implement something will cause a stone-throwing for "breaking something that was working just fine" even if the downtime is minimal.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808882</id>
	<title>first question: does it *need* encrypting</title>
	<author>Anonymous</author>
	<datestamp>1263835440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Most websites are still using unencrypted HTTP"</p><p>that's cause most websites aren't serving up any content that needs encrypting. If you were only looking at banks etc, then maybe I'd worry.<br>Encrypting lolcats is just a waste of cpu cycles.</p><p>As for email, I only use my own mailserver or gmail these days, both of which are using ssl encrypted imap... If your emails contain sensitive information etc, you probably shouldn't be using hotmail etc<nobr> <wbr></nobr>:p</p></htmltext>
<tokenext>" Most websites are still using unencrypted HTTP " that 's cause most websites are n't serving up any content that needs encrypting .
If you were only looking at banks etc , then maybe I 'd worry.Encrypting lolcats is just a waste of cpu cycles.As for email , I only use my own mailserver or gmail these days , both of which are using ssl encrypted imap... If your emails contain sensitive information etc , you probably should n't be using hotmail etc : p</tokentext>
<sentencetext>"Most websites are still using unencrypted HTTP"that's cause most websites aren't serving up any content that needs encrypting.
If you were only looking at banks etc, then maybe I'd worry.Encrypting lolcats is just a waste of cpu cycles.As for email, I only use my own mailserver or gmail these days, both of which are using ssl encrypted imap... If your emails contain sensitive information etc, you probably shouldn't be using hotmail etc :p</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810386</id>
	<title>Re:I have encrypted this post</title>
	<author>Myopic</author>
	<datestamp>1263842100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I feel the pain of people living in the UK. It's not a free country, even though it masquerades as one. It doesn't have freedom zero (self defense) and it doesn't have freedom one (self expression). It isn't a real democracy, either, although thankfully it is a sort-of-half-way democracy. It surprises me, actually, that democracy gained a toe-hold there, but never fully blossomed; and that democracy was insufficient to provide all the basic freedoms.</p><p>The United States certainly has its problems, but at least here I can kill people who are trying to kill me; and I can say deeply offensive and contrarian things with impunity.</p></htmltext>
<tokenext>I feel the pain of people living in the UK .
It 's not a free country , even though it masquerades as one .
It does n't have freedom zero ( self defense ) and it does n't have freedom one ( self expression ) .
It is n't a real democracy , either , although thankfully it is a sort-of-half-way democracy .
It surprises me , actually , that democracy gained a toe-hold there , but never fully blossomed ; and that democracy was insufficient to provide all the basic freedoms.The United States certainly has its problems , but at least here I can kill people who are trying to kill me ; and I can say deeply offensive and contrarian things with impunity .</tokentext>
<sentencetext>I feel the pain of people living in the UK.
It's not a free country, even though it masquerades as one.
It doesn't have freedom zero (self defense) and it doesn't have freedom one (self expression).
It isn't a real democracy, either, although thankfully it is a sort-of-half-way democracy.
It surprises me, actually, that democracy gained a toe-hold there, but never fully blossomed; and that democracy was insufficient to provide all the basic freedoms.The United States certainly has its problems, but at least here I can kill people who are trying to kill me; and I can say deeply offensive and contrarian things with impunity.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811670</id>
	<title>What's the purpose of encryption if it's defeated?</title>
	<author>jonaskoelker</author>
	<datestamp>1263848220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode. Maybe even with a "relax the crypto" configuration flag we can throw during debug.</p></div><p>And then only let the government and government-approved network administrators have packet sniffers, to avoid the black hats having them?  Except that the Nigerian government could hand them out to any Nigerian if it felt like it, so we need trade embargoes, and...</p><p>Exactly what's the point of encrypting something if information will still leak out of the encrypted packets?</p><p>Or---when in debugging mode you could send some insensitive unencrypted traffic.  That way, people can have their encryption and network debuggers can have their not-encryption.</p></div>
	</htmltext>
<tokenext>Maybe we need to come up with a standard way of encrypting things , that our packet sniffers somehow know how to decode .
Maybe even with a " relax the crypto " configuration flag we can throw during debug.And then only let the government and government-approved network administrators have packet sniffers , to avoid the black hats having them ?
Except that the Nigerian government could hand them out to any Nigerian if it felt like it , so we need trade embargoes , and...Exactly what 's the point of encrypting something if information will still leak out of the encrypted packets ? Or---when in debugging mode you could send some insensitive unencrypted traffic .
That way , people can have their encryption and network debuggers can have their not-encryption .</tokentext>
<sentencetext>Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode.
Maybe even with a "relax the crypto" configuration flag we can throw during debug.And then only let the government and government-approved network administrators have packet sniffers, to avoid the black hats having them?
Except that the Nigerian government could hand them out to any Nigerian if it felt like it, so we need trade embargoes, and...Exactly what's the point of encrypting something if information will still leak out of the encrypted packets?Or---when in debugging mode you could send some insensitive unencrypted traffic.
That way, people can have their encryption and network debuggers can have their not-encryption.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808892</id>
	<title>Invisible threat</title>
	<author>famebait</author>
	<datestamp>1263835440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Suppliers give priority to what their customers nag about, and they nag about the problems they see and feel every day.  Only those who get attacked <i>and</i> discover it see the threat of unencrypted traffic.</htmltext>
<tokenext>Suppliers give priority to what their customers nag about , and they nag about the problems they see and feel every day .
Only those who get attacked and discover it see the threat of unencrypted traffic .</tokentext>
<sentencetext>Suppliers give priority to what their customers nag about, and they nag about the problems they see and feel every day.
Only those who get attacked and discover it see the threat of unencrypted traffic.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811762</id>
	<title>Re:encryption alone</title>
	<author>Stradivarius</author>
	<datestamp>1263805500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc...</p></div><p>There is value in those things. There is also a point after which you get diminishing returns, and in fact may make your security worse. For example:</p><p>1. If you make the age requirement too short, then nobody can remember their passwords.  So they start working around it by picking less secure passwords, writing them on stickies, or flooding your helpdesk with password-reset requests.</p><p>2. Complexity requirements are good up to a point, but when you start requiring too many different types of characters you just get people resorting to the equivalent of P4ssword! so they can actually remember the stupid thing.  That may meet your complexity metric but a dictionary attack program will probably crack it quickly.</p><p>IMO we need to move away from such a heavy reliance on passwords, and towards some sort of two-factor system.  When an individual has to create dozens of different passwords for their work systems, banks, retailers, email providers, and who knows what else, it becomes way too much to manage, and people take shortcuts as a result.  They share passwords among different entities, or create weak passwords, etc.</p><p><div class="quote"><p>Even if the business and/or customers complain about "impact", there's always a way to win the argument for establishing and enforcing IT policies that make sense. You have to be willing to save users from themselves.</p></div><p>This is the sort of statement that drives even security-conscious users nuts.  Concern about "impact" is not "complaining".  It is acknowledging that security policies can have a big impact on people's abilities to do their job effectively.  A policy that makes IT sleep easier at night may also be the policy that grinds a worker's progress to a halt.  Good security is a collaborative process between IT and their users to find the right balance for the circumstances.</p></div>
	</htmltext>
<tokenext>the weakest link is actually the sysadmin , who is n't enforcing appropriate password complexity , length , age , etc...There is value in those things .
There is also a point after which you get diminishing returns , and in fact may make your security worse .
For example : 1 .
If you make the age requirement too short , then nobody can remember their passwords .
So they start working around it by picking less secure passwords , writing them on stickies , or flooding your helpdesk with password-reset requests.2 .
Complexity requirements are good up to a point , but when you start requiring too many different types of characters you just get people resorting to the equivalent of P4ssword !
so they can actually remember the stupid thing .
That may meet your complexity metric but a dictionary attack program will probably crack it quickly.IMO we need to move away from such a heavy reliance on passwords , and towards some sort of two-factor system .
When an individual has to create dozens of different passwords for their work systems , banks , retailers , email providers , and who knows what else , it becomes way too much to manage , and people take shortcuts as a result .
They share passwords among different entities , or create weak passwords , etc.Even if the business and/or customers complain about " impact " , there 's always a way to win the argument for establishing and enforcing IT policies that make sense .
You have to be willing to save users from themselves.This is the sort of statement that drives even security-conscious users nuts .
Concern about " impact " is not " complaining " .
It is acknowledging that security policies can have a big impact on people 's abilities to do their job effectively .
A policy that makes IT sleep easier at night may also be the policy that grinds a worker 's progress to a halt .
Good security is a collaborative process between IT and their users to find the right balance for the circumstances .</tokentext>
<sentencetext>the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc...There is value in those things.
There is also a point after which you get diminishing returns, and in fact may make your security worse.
For example:1.
If you make the age requirement too short, then nobody can remember their passwords.
So they start working around it by picking less secure passwords, writing them on stickies, or flooding your helpdesk with password-reset requests.2.
Complexity requirements are good up to a point, but when you start requiring too many different types of characters you just get people resorting to the equivalent of P4ssword!
so they can actually remember the stupid thing.
That may meet your complexity metric but a dictionary attack program will probably crack it quickly.IMO we need to move away from such a heavy reliance on passwords, and towards some sort of two-factor system.
When an individual has to create dozens of different passwords for their work systems, banks, retailers, email providers, and who knows what else, it becomes way too much to manage, and people take shortcuts as a result.
They share passwords among different entities, or create weak passwords, etc.Even if the business and/or customers complain about "impact", there's always a way to win the argument for establishing and enforcing IT policies that make sense.
You have to be willing to save users from themselves.This is the sort of statement that drives even security-conscious users nuts.
Concern about "impact" is not "complaining".
It is acknowledging that security policies can have a big impact on people's abilities to do their job effectively.
A policy that makes IT sleep easier at night may also be the policy that grinds a worker's progress to a halt.
Good security is a collaborative process between IT and their users to find the right balance for the circumstances.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810556</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810086</id>
	<title>Re:Signed certificates</title>
	<author>Anonymous</author>
	<datestamp>1263840600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>More generally speaking, key management and authentication are holding up encryption. Certificates are just one form of managing and authenticating public keys.</p></htmltext>
<tokenext>More generally speaking , key management and authentication are holding up encryption .
Certificates are just one form of managing and authenticating public keys .</tokentext>
<sentencetext>More generally speaking, key management and authentication are holding up encryption.
Certificates are just one form of managing and authenticating public keys.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812492</id>
	<title>Re:More direct costs.</title>
	<author>swillden</author>
	<datestamp>1263808860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>a self-signed certificate is barely better than raw http</p></div><p>I disagree.  A self-signed certificate isn't as good as a certificate that verifies the identity of the server, but it's significantly better than raw http, especially if your browser keeps track of which self-signed certs come from which sites, and alerts you when the cert changes.

</p><p>I think in this respect the behavior of current browsers with self-signed certificates is unfortunate.  What I'd like to see is for the browser to silently accept self-signed certificates but not to show the "secure" lock icon.  That should be reserved for sites with proper certificates, so that users don't think that they have a secure connection when they might be subject to a MITM attack.  I'd also like to see browsers complain LOUDLY when a site that used to have one self-signed certificate (or proper certificate) suddenly starts providing another one.  Particularly if the previous certificate isn't revoked or expired.

</p><p>The security model of self-signed certificates would then be very similar to that of SSH server keys.  The first time you SSH to a machine, you're asked if you want to connect, since this is an unknown key.  Thereafter connections succeed silently, as long as the server continues providing the stored key.  But if the server key changes, connections are ABORTED and you have to take specific corrective action before SSH will allow you to connect again.  With that model, MITM attacks are possible, but only if the attacker gets in on the very first connection.

</p><p>I think if our browsers handled it similarly, we could easily move to a model where HTTPS is the default.  Eventually, we could "deprecate" raw HTTP, by having the browser provide a visual indication that this site is "unsecure" (meaning less secure than the norm).</p></div>
	</htmltext>
<tokenext>a self-signed certificate is barely better than raw httpI disagree .
A self-signed certificate is n't as good as a certificate that verifies the identity of the server , but it 's significantly better than raw http , especially if your browser keeps track of which self-signed certs come from which sites , and alerts you when the cert changes .
I think in this respect the behavior of current browsers with self-signed certificates is unfortunate .
What I 'd like to see is for the browser to silently accept self-signed certificates but not to show the " secure " lock icon .
That should be reserved for sites with proper certificates , so that users do n't think that they have a secure connection when they might be subject to a MITM attack .
I 'd also like to see browsers complain LOUDLY when a site that used to have one self-signed certificate ( or proper certificate ) suddenly starts providing another one .
Particularly if the previous certificate is n't revoked or expired .
The security model of self-signed certificates would then be very similar to that of SSH server keys .
The first time you SSH to a machine , you 're asked if you want to connect , since this is an unknown key .
Thereafter connections succeed silently , as long as the server continues providing the stored key .
But if the server key changes , connections are ABORTED and you have to take specific corrective action before SSH will allow you to connect again .
With that model , MITM attacks are possible , but only if the attacker gets in on the very first connection .
I think if our browsers handled it similarly , we could easily move to a model where HTTPS is the default .
Eventually , we could " deprecate " raw HTTP , by having the browser provide a visual indication that this site is " unsecure " ( meaning less secure than the norm ) .</tokentext>
<sentencetext>a self-signed certificate is barely better than raw httpI disagree.
A self-signed certificate isn't as good as a certificate that verifies the identity of the server, but it's significantly better than raw http, especially if your browser keeps track of which self-signed certs come from which sites, and alerts you when the cert changes.
I think in this respect the behavior of current browsers with self-signed certificates is unfortunate.
What I'd like to see is for the browser to silently accept self-signed certificates but not to show the "secure" lock icon.
That should be reserved for sites with proper certificates, so that users don't think that they have a secure connection when they might be subject to a MITM attack.
I'd also like to see browsers complain LOUDLY when a site that used to have one self-signed certificate (or proper certificate) suddenly starts providing another one.
Particularly if the previous certificate isn't revoked or expired.
The security model of self-signed certificates would then be very similar to that of SSH server keys.
The first time you SSH to a machine, you're asked if you want to connect, since this is an unknown key.
Thereafter connections succeed silently, as long as the server continues providing the stored key.
But if the server key changes, connections are ABORTED and you have to take specific corrective action before SSH will allow you to connect again.
With that model, MITM attacks are possible, but only if the attacker gets in on the very first connection.
I think if our browsers handled it similarly, we could easily move to a model where HTTPS is the default.
Eventually, we could "deprecate" raw HTTP, by having the browser provide a visual indication that this site is "unsecure" (meaning less secure than the norm).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786</id>
	<title>Re:Costs?</title>
	<author>Bert64</author>
	<datestamp>1263839280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't think many other phones can do encrypted email out of the box either, tho third party apps are available for some.</p><p>Nobody cares, large companies, even companies working in the security market don't use encrypted email and often don't even understand how to use it... Then you have mail setups which stamp disclaimers or signatures on mail (thus breaking signatures), not to mention exchange that likes to create an html counterpart to your (encrypted) plaintext mail, thus breaking PGP completely...</p></htmltext>
<tokenext>I do n't think many other phones can do encrypted email out of the box either , tho third party apps are available for some.Nobody cares , large companies , even companies working in the security market do n't use encrypted email and often do n't even understand how to use it... Then you have mail setups which stamp disclaimers or signatures on mail ( thus breaking signatures ) , not to mention exchange that likes to create an html counterpart to your ( encrypted ) plaintext mail , thus breaking PGP completely.. .</tokentext>
<sentencetext>I don't think many other phones can do encrypted email out of the box either, tho third party apps are available for some.Nobody cares, large companies, even companies working in the security market don't use encrypted email and often don't even understand how to use it... Then you have mail setups which stamp disclaimers or signatures on mail (thus breaking signatures), not to mention exchange that likes to create an html counterpart to your (encrypted) plaintext mail, thus breaking PGP completely...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808834</id>
	<title>maybe not apathy, nor ignorace</title>
	<author>AverageJoe8686</author>
	<datestamp>1263835260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Maybe it's more of an issue of ready availability and accessibility. Plus (I think) some businesses may think that it's an unwarranted cost which should only be used for money transactions or whatever.
But then again I'm talking outta my arse here with no previous knowledge.</htmltext>
<tokenext>Maybe it 's more of an issue of ready availability and accessibility .
Plus ( I think ) some businesses may think that it 's an unwarranted cost which should only be used for money transactions or whatever .
But then again I 'm talking outta my arse here with no previous knowledge .</tokentext>
<sentencetext>Maybe it's more of an issue of ready availability and accessibility.
Plus (I think) some businesses may think that it's an unwarranted cost which should only be used for money transactions or whatever.
But then again I'm talking outta my arse here with no previous knowledge.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808910</id>
	<title>There are a number of problems</title>
	<author>cdrguru</author>
	<datestamp>1263835560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>First big problem is you simply cannot send encrypted email to someone without a prior relationship.  They aren't going to "get it" and they aren't going to be bothered to figure out why they can't read your email - just delete it.</p><p>The second problem is that if you want to be seen doing something "real", you need to spend some money on a "real" certificate.  At a corporate level it might seem to make sense to have a corporate level certificate that then signs individual certificates.  But this doesn't seem to be "real" enough.</p><p>Finally, most people understand that email is insecure and unreliable.  They get a few Viagra ads every day and this reinforces the idea that it is insecure.  They call people to make sure their email went through - because email is unreliable.  Encryption would be another layer of trouble on top of all that insecurity and unreliability for no apparent benefit.</p></htmltext>
<tokenext>First big problem is you simply can not send encrypted email to someone without a prior relationship .
They are n't going to " get it " and they are n't going to be bothered to figure out why they ca n't read your email - just delete it.The second problem is that if you want to be seen doing something " real " , you need to spend some money on a " real " certificate .
At a corporate level it might seem to make sense to have a corporate level certificate that then signs individual certificates .
But this does n't seem to be " real " enough.Finally , most people understand that email is insecure and unreliable .
They get a few Viagra ads every day and this reinforces the idea that it is insecure .
They call people to make sure their email went through - because email is unreliable .
Encryption would be another layer of trouble on top of all that insecurity and unreliability for no apparent benefit .</tokentext>
<sentencetext>First big problem is you simply cannot send encrypted email to someone without a prior relationship.
They aren't going to "get it" and they aren't going to be bothered to figure out why they can't read your email - just delete it.The second problem is that if you want to be seen doing something "real", you need to spend some money on a "real" certificate.
At a corporate level it might seem to make sense to have a corporate level certificate that then signs individual certificates.
But this doesn't seem to be "real" enough.Finally, most people understand that email is insecure and unreliable.
They get a few Viagra ads every day and this reinforces the idea that it is insecure.
They call people to make sure their email went through - because email is unreliable.
Encryption would be another layer of trouble on top of all that insecurity and unreliability for no apparent benefit.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809466</id>
	<title>When will Hotmail finally implement full-SSL?</title>
	<author>Anonymous</author>
	<datestamp>1263837900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>When will Hotmail finally implement full-SSL? Gmail has had this for a long time now.</p></htmltext>
<tokenext>When will Hotmail finally implement full-SSL ?
Gmail has had this for a long time now .</tokentext>
<sentencetext>When will Hotmail finally implement full-SSL?
Gmail has had this for a long time now.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809476</id>
	<title>Why not slap encryption everywhere?</title>
	<author>Anonymous</author>
	<datestamp>1263837960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's the keys, stupid.</p></htmltext>
<tokenext>It 's the keys , stupid .</tokentext>
<sentencetext>It's the keys, stupid.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809160</id>
	<title>Re:Because it's a PITA - Pain In the Ass!</title>
	<author>OrangeCatholic</author>
	<datestamp>1263836580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&gt;It's not needed.
<br> <br>
You're clearly not anti-facist.  Everybody says "oh, the criminals only go after what's important. Just protect that."
<br> <br>
Actually, facists go after the <i>mundane</i>.  In Germany it was your name that got you killed.  Try encrypting that.</htmltext>
<tokenext>&gt; It 's not needed .
You 're clearly not anti-facist .
Everybody says " oh , the criminals only go after what 's important .
Just protect that .
" Actually , facists go after the mundane .
In Germany it was your name that got you killed .
Try encrypting that .</tokentext>
<sentencetext>&gt;It's not needed.
You're clearly not anti-facist.
Everybody says "oh, the criminals only go after what's important.
Just protect that.
"
 
Actually, facists go after the mundane.
In Germany it was your name that got you killed.
Try encrypting that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810312</id>
	<title>Re:Costs?</title>
	<author>Isao</author>
	<datestamp>1263841620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Windows Mobile, Blackberry.</htmltext>
<tokenext>Windows Mobile , Blackberry .</tokentext>
<sentencetext>Windows Mobile, Blackberry.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810176</id>
	<title>Re:Because it's a PITA - Pain In the Ass!</title>
	<author>zaffir</author>
	<datestamp>1263841020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'd like to add that key management is a huge pain in the ass, as well.</p></htmltext>
<tokenext>I 'd like to add that key management is a huge pain in the ass , as well .</tokentext>
<sentencetext>I'd like to add that key management is a huge pain in the ass, as well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813708</id>
	<title>Government Endorsement?</title>
	<author>tif</author>
	<datestamp>1263814800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I believe that the US Post Office should take the lead here.  Even 10 years ago, I thought that the USPO was the perfect "official" entity to manage keys.  The post office currently serves a sort of official role in guaranteeing safe deliverly of your mail (more or less).  If the USPO had official processes for proving you are who you say you are and keeping your public key, then the US Government could safely allow digitally signed emails to represent contracts, etc.  Once you reach that point, it seems like signed emails would become the norm for business transactions.  Furthermore, once you have all the keys and government endorsement, it seems like encryption would follow very quickly.</p><p>Even better, it would become trivial to filter out any non-signed emails as spam, and for any signed spam to be prosecuted.</p><p>--Paul</p></htmltext>
<tokenext>I believe that the US Post Office should take the lead here .
Even 10 years ago , I thought that the USPO was the perfect " official " entity to manage keys .
The post office currently serves a sort of official role in guaranteeing safe deliverly of your mail ( more or less ) .
If the USPO had official processes for proving you are who you say you are and keeping your public key , then the US Government could safely allow digitally signed emails to represent contracts , etc .
Once you reach that point , it seems like signed emails would become the norm for business transactions .
Furthermore , once you have all the keys and government endorsement , it seems like encryption would follow very quickly.Even better , it would become trivial to filter out any non-signed emails as spam , and for any signed spam to be prosecuted.--Paul</tokentext>
<sentencetext>I believe that the US Post Office should take the lead here.
Even 10 years ago, I thought that the USPO was the perfect "official" entity to manage keys.
The post office currently serves a sort of official role in guaranteeing safe deliverly of your mail (more or less).
If the USPO had official processes for proving you are who you say you are and keeping your public key, then the US Government could safely allow digitally signed emails to represent contracts, etc.
Once you reach that point, it seems like signed emails would become the norm for business transactions.
Furthermore, once you have all the keys and government endorsement, it seems like encryption would follow very quickly.Even better, it would become trivial to filter out any non-signed emails as spam, and for any signed spam to be prosecuted.--Paul</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809104</id>
	<title>Re:I have encrypted this post</title>
	<author>Anonymous</author>
	<datestamp>1263836400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one"</p><p>Yes, encryption won't stop government oppression, but it will slow it down.  It's not just the fact that they can still harass one person, it's the fact that with everybody encrypting their communications the government's ability to data mine email and do covert spying on its own citizens becomes much harder.</p></htmltext>
<tokenext>" The fun part is that the ( UK ) cops can demand a decryption key for that , and lock me up when I inevitably fail to provide one " Yes , encryption wo n't stop government oppression , but it will slow it down .
It 's not just the fact that they can still harass one person , it 's the fact that with everybody encrypting their communications the government 's ability to data mine email and do covert spying on its own citizens becomes much harder .</tokentext>
<sentencetext>"The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one"Yes, encryption won't stop government oppression, but it will slow it down.
It's not just the fact that they can still harass one person, it's the fact that with everybody encrypting their communications the government's ability to data mine email and do covert spying on its own citizens becomes much harder.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813592</id>
	<title>Re:Why?</title>
	<author>Mr. Freeman</author>
	<datestamp>1263814200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>No one is saying you should.<br><br>The question specifically mentions businesses and things that need to be secure (like email, banking, etc.).  Clearly, your website does not need to be secure and is thus not at all related to the topic at hand.</htmltext>
<tokenext>No one is saying you should.The question specifically mentions businesses and things that need to be secure ( like email , banking , etc. ) .
Clearly , your website does not need to be secure and is thus not at all related to the topic at hand .</tokentext>
<sentencetext>No one is saying you should.The question specifically mentions businesses and things that need to be secure (like email, banking, etc.).
Clearly, your website does not need to be secure and is thus not at all related to the topic at hand.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810042</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809170</id>
	<title>encryption is no panacea</title>
	<author>Anonymous</author>
	<datestamp>1263836640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>because encryption breaks things and makes them run slower.  Caching proxies fail with encryption.  Error rates increase with every level of complexity, and fixing them gets less likely.  Making computer work together is still hard, so making it artificially harder is retarded.  I hate DNS-SEC, and I hate the push for encryption for no reason.</p><p>As another poster said, the bulk of security problems are not solved by encryption.  Many problems are caused by poor attempts at encryption.</p><p>
&nbsp; - deadshift</p></htmltext>
<tokenext>because encryption breaks things and makes them run slower .
Caching proxies fail with encryption .
Error rates increase with every level of complexity , and fixing them gets less likely .
Making computer work together is still hard , so making it artificially harder is retarded .
I hate DNS-SEC , and I hate the push for encryption for no reason.As another poster said , the bulk of security problems are not solved by encryption .
Many problems are caused by poor attempts at encryption .
  - deadshift</tokentext>
<sentencetext>because encryption breaks things and makes them run slower.
Caching proxies fail with encryption.
Error rates increase with every level of complexity, and fixing them gets less likely.
Making computer work together is still hard, so making it artificially harder is retarded.
I hate DNS-SEC, and I hate the push for encryption for no reason.As another poster said, the bulk of security problems are not solved by encryption.
Many problems are caused by poor attempts at encryption.
  - deadshift</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30818794</id>
	<title>Why use encryption?</title>
	<author>dublinclontarf</author>
	<datestamp>1263914400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Why use encryption?
The Government, and not necessarily your own.

Why would a government care about the content you view from websites?
I moved to China 6 months ago and am sick of half the internet being blocked, I can't talk to my friends or family on facebook, my porn is cut off and plenty more.

And China is only at the forefront, Australia is close behind followed by the UK(in the "free" world), and every other despot country with internet.</htmltext>
<tokenext>Why use encryption ?
The Government , and not necessarily your own .
Why would a government care about the content you view from websites ?
I moved to China 6 months ago and am sick of half the internet being blocked , I ca n't talk to my friends or family on facebook , my porn is cut off and plenty more .
And China is only at the forefront , Australia is close behind followed by the UK ( in the " free " world ) , and every other despot country with internet .</tokentext>
<sentencetext>Why use encryption?
The Government, and not necessarily your own.
Why would a government care about the content you view from websites?
I moved to China 6 months ago and am sick of half the internet being blocked, I can't talk to my friends or family on facebook, my porn is cut off and plenty more.
And China is only at the forefront, Australia is close behind followed by the UK(in the "free" world), and every other despot country with internet.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812874</id>
	<title>It costs more</title>
	<author>Anonymous</author>
	<datestamp>1263810720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The CPU requirements for handling encrypted traffic are a lot higher than for http.</p><p>It costs MONEY - and it's not a linear scaling - doing 1/10th of the transactions/CPU needs more than 10x the number of CPU's since you have to spread load - which imposes more load on the system.</p></htmltext>
<tokenext>The CPU requirements for handling encrypted traffic are a lot higher than for http.It costs MONEY - and it 's not a linear scaling - doing 1/10th of the transactions/CPU needs more than 10x the number of CPU 's since you have to spread load - which imposes more load on the system .</tokentext>
<sentencetext>The CPU requirements for handling encrypted traffic are a lot higher than for http.It costs MONEY - and it's not a linear scaling - doing 1/10th of the transactions/CPU needs more than 10x the number of CPU's since you have to spread load - which imposes more load on the system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809404</id>
	<title>Re:Apathy</title>
	<author>camperdave</author>
	<datestamp>1263837600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Here's another meh for you.  If I send someone an encrypted email, can the recipient read it, or do they have to have their email set up too.  My guess is they have to set up as well, but I can't be bothered to check.</htmltext>
<tokenext>Here 's another meh for you .
If I send someone an encrypted email , can the recipient read it , or do they have to have their email set up too .
My guess is they have to set up as well , but I ca n't be bothered to check .</tokentext>
<sentencetext>Here's another meh for you.
If I send someone an encrypted email, can the recipient read it, or do they have to have their email set up too.
My guess is they have to set up as well, but I can't be bothered to check.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809620</id>
	<title>Re:I have encrypted this post</title>
	<author>badzilla</author>
	<datestamp>1263838620000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p>I got in A LOT OF TROUBLE when I decrypted that! Next time at least have the decency to flag it NSFW.</p></htmltext>
<tokenext>I got in A LOT OF TROUBLE when I decrypted that !
Next time at least have the decency to flag it NSFW .</tokentext>
<sentencetext>I got in A LOT OF TROUBLE when I decrypted that!
Next time at least have the decency to flag it NSFW.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809114</id>
	<title>It'd be nice to see...</title>
	<author>Anonymous</author>
	<datestamp>1263836400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>...the crypto responsibility moved to the network where it belongs.  It can and should be completely transparent to the end-user, and non-optional.</p><p>Want to send something via FTP/telnet/http?  Fine, go ahead.  We'll encrypt/decrypt it silently on your behalf anyway.  No need to give it a second thought.  Want to encrypt it yourself?  Fine, go  ahead.  We'll encrypt/decrypt it all again, our way.</p></htmltext>
<tokenext>...the crypto responsibility moved to the network where it belongs .
It can and should be completely transparent to the end-user , and non-optional.Want to send something via FTP/telnet/http ?
Fine , go ahead .
We 'll encrypt/decrypt it silently on your behalf anyway .
No need to give it a second thought .
Want to encrypt it yourself ?
Fine , go ahead .
We 'll encrypt/decrypt it all again , our way .</tokentext>
<sentencetext>...the crypto responsibility moved to the network where it belongs.
It can and should be completely transparent to the end-user, and non-optional.Want to send something via FTP/telnet/http?
Fine, go ahead.
We'll encrypt/decrypt it silently on your behalf anyway.
No need to give it a second thought.
Want to encrypt it yourself?
Fine, go  ahead.
We'll encrypt/decrypt it all again, our way.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809576</id>
	<title>You are Perceived to have Nefarious Intentions</title>
	<author>Nethemas the Great</author>
	<datestamp>1263838440000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>Among the myriad reasons...  Those that bother with encryption on anything other than a shopping cart are generally perceived to have nefarious intentions.  As the old saying goes... "what do you have to hide if you're not doing anything wrong?"  Beyond that:
<ul>
<li>Government arms can compel you to produce the key or face obstruction charges...so what the point.  Espionage business or personal isn't really on peoples minds.  Survey people around you and see how many know anything about the Google-China deal.</li><li>Encryption technology was/is banned from export.  Distribution of software with out of the gate support while satisfying relevant laws is a <a href="http://www.infosecnews.org/hypermail/9803/0079.html" title="infosecnews.org">pain/expensive</a> [infosecnews.org].</li><li>[En/de]cryption is processor intensive.  Servers have to have significantly more power to handle the same number of people.</li><li>People are oblivious to the information they're making available and the ramifications there of.  Take Facebook/MySpace for example, both are a dataminer's/identity thief's candy store.</li><li>Authority signed security certificates are expensive.  Self-signed certificates produce wonderfully scary messages in web browsers and are vulnerable to MIM attack.   No certificate (unencrypted) sites are displayed in the browser as if everything was perfectly alright, safe, and secure. </li></ul></htmltext>
<tokenext>Among the myriad reasons... Those that bother with encryption on anything other than a shopping cart are generally perceived to have nefarious intentions .
As the old saying goes... " what do you have to hide if you 're not doing anything wrong ?
" Beyond that : Government arms can compel you to produce the key or face obstruction charges...so what the point .
Espionage business or personal is n't really on peoples minds .
Survey people around you and see how many know anything about the Google-China deal.Encryption technology was/is banned from export .
Distribution of software with out of the gate support while satisfying relevant laws is a pain/expensive [ infosecnews.org ] .
[ En/de ] cryption is processor intensive .
Servers have to have significantly more power to handle the same number of people.People are oblivious to the information they 're making available and the ramifications there of .
Take Facebook/MySpace for example , both are a dataminer 's/identity thief 's candy store.Authority signed security certificates are expensive .
Self-signed certificates produce wonderfully scary messages in web browsers and are vulnerable to MIM attack .
No certificate ( unencrypted ) sites are displayed in the browser as if everything was perfectly alright , safe , and secure .</tokentext>
<sentencetext>Among the myriad reasons...  Those that bother with encryption on anything other than a shopping cart are generally perceived to have nefarious intentions.
As the old saying goes... "what do you have to hide if you're not doing anything wrong?
"  Beyond that:

Government arms can compel you to produce the key or face obstruction charges...so what the point.
Espionage business or personal isn't really on peoples minds.
Survey people around you and see how many know anything about the Google-China deal.Encryption technology was/is banned from export.
Distribution of software with out of the gate support while satisfying relevant laws is a pain/expensive [infosecnews.org].
[En/de]cryption is processor intensive.
Servers have to have significantly more power to handle the same number of people.People are oblivious to the information they're making available and the ramifications there of.
Take Facebook/MySpace for example, both are a dataminer's/identity thief's candy store.Authority signed security certificates are expensive.
Self-signed certificates produce wonderfully scary messages in web browsers and are vulnerable to MIM attack.
No certificate (unencrypted) sites are displayed in the browser as if everything was perfectly alright, safe, and secure. </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811154</id>
	<title>Re:People don't see the value</title>
	<author>Sloppy</author>
	<datestamp>1263845940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Think of all of those free WiFi access points. Your employee sits down in a cafe and connects with its access point. Well, he thinks it's their access point. Actually it's run by the guy renting the flat above the cafe. He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate.</p></div></blockquote><p>That's bad.  But you've got the same risk with plaintext.  Unauthenticated crypto is no worse.  And it has an advantage over plaintext, even when MitM attacks are attempted:</p><blockquote><div><p>Your employee connect to your corporate Intranet with it and, unless you distributed the certificate out of band..</p></div></blockquote><p>(attackers have no way of knowing whether or not that has happened, so every MitM carries risk of detection)</p><blockquote><div><p>.. and your employees know not to allow connecting when the certificate verification fails, he's just handed his login details to a stranger.</p></div></blockquote><p>And if just one employee <em>does</em> know what the verification failure means, then the word is now out: MitM <em>happens</em>; it's not merely a theoretical risk that cypherpunks need to worry about, it's every day reality that Joe Average needs to worry about.  A memo goes out: "someone tried to MitM attack Jones at Cafe Greaso!"</p><p>Self-signed certs give you a fighting chance that plaintext doesn't give you.  I'm not saying it's as good as authenticated crypto -- it's not.  But it's far better than not encrypting at all.  If certification is too much of a pain in the ass, then worry about it later if you must delay, but that shouldn't be stopping people from encrypting.</p></div>
	</htmltext>
<tokenext>Think of all of those free WiFi access points .
Your employee sits down in a cafe and connects with its access point .
Well , he thinks it 's their access point .
Actually it 's run by the guy renting the flat above the cafe .
He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate.That 's bad .
But you 've got the same risk with plaintext .
Unauthenticated crypto is no worse .
And it has an advantage over plaintext , even when MitM attacks are attempted : Your employee connect to your corporate Intranet with it and , unless you distributed the certificate out of band.. ( attackers have no way of knowing whether or not that has happened , so every MitM carries risk of detection ) .. and your employees know not to allow connecting when the certificate verification fails , he 's just handed his login details to a stranger.And if just one employee does know what the verification failure means , then the word is now out : MitM happens ; it 's not merely a theoretical risk that cypherpunks need to worry about , it 's every day reality that Joe Average needs to worry about .
A memo goes out : " someone tried to MitM attack Jones at Cafe Greaso !
" Self-signed certs give you a fighting chance that plaintext does n't give you .
I 'm not saying it 's as good as authenticated crypto -- it 's not .
But it 's far better than not encrypting at all .
If certification is too much of a pain in the ass , then worry about it later if you must delay , but that should n't be stopping people from encrypting .</tokentext>
<sentencetext>Think of all of those free WiFi access points.
Your employee sits down in a cafe and connects with its access point.
Well, he thinks it's their access point.
Actually it's run by the guy renting the flat above the cafe.
He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate.That's bad.
But you've got the same risk with plaintext.
Unauthenticated crypto is no worse.
And it has an advantage over plaintext, even when MitM attacks are attempted:Your employee connect to your corporate Intranet with it and, unless you distributed the certificate out of band..(attackers have no way of knowing whether or not that has happened, so every MitM carries risk of detection).. and your employees know not to allow connecting when the certificate verification fails, he's just handed his login details to a stranger.And if just one employee does know what the verification failure means, then the word is now out: MitM happens; it's not merely a theoretical risk that cypherpunks need to worry about, it's every day reality that Joe Average needs to worry about.
A memo goes out: "someone tried to MitM attack Jones at Cafe Greaso!
"Self-signed certs give you a fighting chance that plaintext doesn't give you.
I'm not saying it's as good as authenticated crypto -- it's not.
But it's far better than not encrypting at all.
If certification is too much of a pain in the ass, then worry about it later if you must delay, but that shouldn't be stopping people from encrypting.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30826230</id>
	<title>Re:HTTP(S)? Marketing/profitability &amp; IPv4</title>
	<author>Macrat</author>
	<datestamp>1263903480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>You can argue that we should instead be using IPv6, and I might agree, but we're simply not there yet.</p></div><p>Are we there yet?</p></div>
	</htmltext>
<tokenext>You can argue that we should instead be using IPv6 , and I might agree , but we 're simply not there yet.Are we there yet ?</tokentext>
<sentencetext>You can argue that we should instead be using IPv6, and I might agree, but we're simply not there yet.Are we there yet?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809306</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809232</id>
	<title>Re:Because it's a PITA - Pain In the Ass!</title>
	<author>mr crypto</author>
	<datestamp>1263836880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Agreed.  People switch between computers at home, work, and public workstations and don't have a universal login to make it 'just work' anywhere.  It also definitely suffers from the "if everyone would just use OUR system it would be easy" problem.  Try coming up with your own solution and run through setup scenarios for different users (including your mother) and you'll find that there are too many steps.  Even just doing authentication is tough to make simple (relies on contacting some central authority).</p></htmltext>
<tokenext>Agreed .
People switch between computers at home , work , and public workstations and do n't have a universal login to make it 'just work ' anywhere .
It also definitely suffers from the " if everyone would just use OUR system it would be easy " problem .
Try coming up with your own solution and run through setup scenarios for different users ( including your mother ) and you 'll find that there are too many steps .
Even just doing authentication is tough to make simple ( relies on contacting some central authority ) .</tokentext>
<sentencetext>Agreed.
People switch between computers at home, work, and public workstations and don't have a universal login to make it 'just work' anywhere.
It also definitely suffers from the "if everyone would just use OUR system it would be easy" problem.
Try coming up with your own solution and run through setup scenarios for different users (including your mother) and you'll find that there are too many steps.
Even just doing authentication is tough to make simple (relies on contacting some central authority).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809428</id>
	<title>Solutions Exist - But some oxes may get gored</title>
	<author>wevets</author>
	<datestamp>1263837720000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Having worked in a company that makes Ethernet adapters that implements IPsec offload, I can tell you EXACTLY what's holding up encryption across the network:  Cisco and possibly a few other network hardware vendors.  The problem is that they can't see into encrypted traffic, and they want to "own the network".  If they can't see into the traffic for deep packet inspection, route optimization, traffic steering, etc. all their fancy hardware becomes pretty neigh useless.  And encrypted traffic cannot be viewed by "lumps in the network".  And these "lump makers" are, unfortunately, influential enough to make commercial implementation difficult by others.
In fact, the best, most effective encryption is done as high up the stack as possible so as to protect the traffic from as many lower layers as possible.  And, if you study the problem carefully, you'll see that you actually need encryption at several layers to properly protect the entire attack surface.  But you either have to do this cleverly with existing protocols - possibly getting into vendor-specific solutions that would need to be standardized, - or create new protocols.  Just applying SSL/TLS to everything is not the answer.
As I said, solutions exist even at some large companies that could bring them to market inspite of Cisco.   But to bring them to market, there needs to be some market pull from the user community for effective cross-network encryption, which, so far, does not exist.</htmltext>
<tokenext>Having worked in a company that makes Ethernet adapters that implements IPsec offload , I can tell you EXACTLY what 's holding up encryption across the network : Cisco and possibly a few other network hardware vendors .
The problem is that they ca n't see into encrypted traffic , and they want to " own the network " .
If they ca n't see into the traffic for deep packet inspection , route optimization , traffic steering , etc .
all their fancy hardware becomes pretty neigh useless .
And encrypted traffic can not be viewed by " lumps in the network " .
And these " lump makers " are , unfortunately , influential enough to make commercial implementation difficult by others .
In fact , the best , most effective encryption is done as high up the stack as possible so as to protect the traffic from as many lower layers as possible .
And , if you study the problem carefully , you 'll see that you actually need encryption at several layers to properly protect the entire attack surface .
But you either have to do this cleverly with existing protocols - possibly getting into vendor-specific solutions that would need to be standardized , - or create new protocols .
Just applying SSL/TLS to everything is not the answer .
As I said , solutions exist even at some large companies that could bring them to market inspite of Cisco .
But to bring them to market , there needs to be some market pull from the user community for effective cross-network encryption , which , so far , does not exist .</tokentext>
<sentencetext>Having worked in a company that makes Ethernet adapters that implements IPsec offload, I can tell you EXACTLY what's holding up encryption across the network:  Cisco and possibly a few other network hardware vendors.
The problem is that they can't see into encrypted traffic, and they want to "own the network".
If they can't see into the traffic for deep packet inspection, route optimization, traffic steering, etc.
all their fancy hardware becomes pretty neigh useless.
And encrypted traffic cannot be viewed by "lumps in the network".
And these "lump makers" are, unfortunately, influential enough to make commercial implementation difficult by others.
In fact, the best, most effective encryption is done as high up the stack as possible so as to protect the traffic from as many lower layers as possible.
And, if you study the problem carefully, you'll see that you actually need encryption at several layers to properly protect the entire attack surface.
But you either have to do this cleverly with existing protocols - possibly getting into vendor-specific solutions that would need to be standardized, - or create new protocols.
Just applying SSL/TLS to everything is not the answer.
As I said, solutions exist even at some large companies that could bring them to market inspite of Cisco.
But to bring them to market, there needs to be some market pull from the user community for effective cross-network encryption, which, so far, does not exist.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30823894</id>
	<title>Re:There are a number of problems</title>
	<author>Abcd1234</author>
	<datestamp>1263892680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>First big problem is you simply cannot send encrypted email to someone without a prior relationship. </i></p><p>What?  Every email client I've come across will happily use the standard keyservers (like MIT's) for retrieving public keys.  No prior relationship required.  The person just needs to publish their key on one of those servers, an operation which is incredibly easy (and automated by some key management software, such as Seahorse on Ubuntu).</p><p><i>The second problem is that if you want to be seen doing something "real", you need to spend some money on a "real" certificate. </i></p><p>BS.  Are you saying PGP isn't "real"?</p><p><i>Encryption would be another layer of trouble on top of all that insecurity and unreliability for no apparent benefit.</i></p><p>No, encryption would be a layer which would *remove* the insecurity and unreliability.  If everyone signed their emails, it would be trivial to have the server filter out emails that don't have valid signatures.</p></htmltext>
<tokenext>First big problem is you simply can not send encrypted email to someone without a prior relationship .
What ? Every email client I 've come across will happily use the standard keyservers ( like MIT 's ) for retrieving public keys .
No prior relationship required .
The person just needs to publish their key on one of those servers , an operation which is incredibly easy ( and automated by some key management software , such as Seahorse on Ubuntu ) .The second problem is that if you want to be seen doing something " real " , you need to spend some money on a " real " certificate .
BS. Are you saying PGP is n't " real " ? Encryption would be another layer of trouble on top of all that insecurity and unreliability for no apparent benefit.No , encryption would be a layer which would * remove * the insecurity and unreliability .
If everyone signed their emails , it would be trivial to have the server filter out emails that do n't have valid signatures .</tokentext>
<sentencetext>First big problem is you simply cannot send encrypted email to someone without a prior relationship.
What?  Every email client I've come across will happily use the standard keyservers (like MIT's) for retrieving public keys.
No prior relationship required.
The person just needs to publish their key on one of those servers, an operation which is incredibly easy (and automated by some key management software, such as Seahorse on Ubuntu).The second problem is that if you want to be seen doing something "real", you need to spend some money on a "real" certificate.
BS.  Are you saying PGP isn't "real"?Encryption would be another layer of trouble on top of all that insecurity and unreliability for no apparent benefit.No, encryption would be a layer which would *remove* the insecurity and unreliability.
If everyone signed their emails, it would be trivial to have the server filter out emails that don't have valid signatures.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808910</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30818508</id>
	<title>Re:Costs?</title>
	<author>coofercat</author>
	<datestamp>1263912420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Keys-by-DNS (or similar) is pretty much where I think things need to go.</p><p>I've always wondered why we needed SSL-for-http, SSL-for-smtp and SSL-for-other\_protocol. Why don't we just have a generic "ssh to someone" protocol which can forward the packets to the right service on the remote server (perhaps a sort of TCP-S protocol or something?). Of course, key management is really the problem.</p><p>Back to costs: Who's gonna spend the time (and money) trying to convince the world it needs keys-by-DNS when no one uses keys-by-DNS yet? It's probably worse than you might think because SSL's already been done, and the vast majority of normal people in the world don't need much more than that.</p></htmltext>
<tokenext>Keys-by-DNS ( or similar ) is pretty much where I think things need to go.I 've always wondered why we needed SSL-for-http , SSL-for-smtp and SSL-for-other \ _protocol .
Why do n't we just have a generic " ssh to someone " protocol which can forward the packets to the right service on the remote server ( perhaps a sort of TCP-S protocol or something ? ) .
Of course , key management is really the problem.Back to costs : Who 's gon na spend the time ( and money ) trying to convince the world it needs keys-by-DNS when no one uses keys-by-DNS yet ?
It 's probably worse than you might think because SSL 's already been done , and the vast majority of normal people in the world do n't need much more than that .</tokentext>
<sentencetext>Keys-by-DNS (or similar) is pretty much where I think things need to go.I've always wondered why we needed SSL-for-http, SSL-for-smtp and SSL-for-other\_protocol.
Why don't we just have a generic "ssh to someone" protocol which can forward the packets to the right service on the remote server (perhaps a sort of TCP-S protocol or something?).
Of course, key management is really the problem.Back to costs: Who's gonna spend the time (and money) trying to convince the world it needs keys-by-DNS when no one uses keys-by-DNS yet?
It's probably worse than you might think because SSL's already been done, and the vast majority of normal people in the world don't need much more than that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811642</id>
	<title>Re:encryption alone</title>
	<author>turbidostato</author>
	<datestamp>1263848100000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>"the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc..."</p><p>Who the hell do you think a sysadmin is?  Stablishing policies is way beyond his duties.  He can *counsel* about how technical means can help to acomplish a policy but he is not the one to build the policy in first place, much less to enforce anyone on his own.</p></htmltext>
<tokenext>" the weakest link is actually the sysadmin , who is n't enforcing appropriate password complexity , length , age , etc... " Who the hell do you think a sysadmin is ?
Stablishing policies is way beyond his duties .
He can * counsel * about how technical means can help to acomplish a policy but he is not the one to build the policy in first place , much less to enforce anyone on his own .</tokentext>
<sentencetext>"the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc..."Who the hell do you think a sysadmin is?
Stablishing policies is way beyond his duties.
He can *counsel* about how technical means can help to acomplish a policy but he is not the one to build the policy in first place, much less to enforce anyone on his own.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810556</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812520</id>
	<title>Re:encryption alone</title>
	<author>BlueParrot</author>
	<datestamp>1263809040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>as long as you've got users who'll click on random executables and use their kid's name as a password and share their credentials with someone else, encryption isn't really going to get you very far.</p></div></blockquote><p>It can get you pretty damn far if you do what Swedish banks do and use one of these:</p><p><a href="http://www.swedbanksjuharad.se/bildarkivet/motiv/7131/Webb\_Liten.jpg" title="swedbanksjuharad.se">http://www.swedbanksjuharad.se/bildarkivet/motiv/7131/Webb\_Liten.jpg</a> [swedbanksjuharad.se]</p><p>You get one of those from your bank ( you have to pick it up in person ), use it to encrypt your PIN before even typing it into your computer, then you use it to sign any account and transaction details you send them, including the receiving account number as well as the amount of money to send. The little device itself has no means of exchanging information with the rest of teh world except the LCD window and the number keys. You literally perform the encryption "manually" as far as the computer is concerned. Ok, it's not perfect in the sense that if your computer gets owned they can eavesdrop on your sessions and get information about your transactions, but at least they won't be able to withdraw any cash.</p><p>My main point about this is that security is not a black or white thing, and encrypting transactions can dramatically reduce the number of possible attacks available. That it may be possible to get personal information about me if they own my computer is not quite the same as being able to withdraw all my savings if the bank used a software implementation.</p></div>
	</htmltext>
<tokenext>as long as you 've got users who 'll click on random executables and use their kid 's name as a password and share their credentials with someone else , encryption is n't really going to get you very far.It can get you pretty damn far if you do what Swedish banks do and use one of these : http : //www.swedbanksjuharad.se/bildarkivet/motiv/7131/Webb \ _Liten.jpg [ swedbanksjuharad.se ] You get one of those from your bank ( you have to pick it up in person ) , use it to encrypt your PIN before even typing it into your computer , then you use it to sign any account and transaction details you send them , including the receiving account number as well as the amount of money to send .
The little device itself has no means of exchanging information with the rest of teh world except the LCD window and the number keys .
You literally perform the encryption " manually " as far as the computer is concerned .
Ok , it 's not perfect in the sense that if your computer gets owned they can eavesdrop on your sessions and get information about your transactions , but at least they wo n't be able to withdraw any cash.My main point about this is that security is not a black or white thing , and encrypting transactions can dramatically reduce the number of possible attacks available .
That it may be possible to get personal information about me if they own my computer is not quite the same as being able to withdraw all my savings if the bank used a software implementation .</tokentext>
<sentencetext>as long as you've got users who'll click on random executables and use their kid's name as a password and share their credentials with someone else, encryption isn't really going to get you very far.It can get you pretty damn far if you do what Swedish banks do and use one of these:http://www.swedbanksjuharad.se/bildarkivet/motiv/7131/Webb\_Liten.jpg [swedbanksjuharad.se]You get one of those from your bank ( you have to pick it up in person ), use it to encrypt your PIN before even typing it into your computer, then you use it to sign any account and transaction details you send them, including the receiving account number as well as the amount of money to send.
The little device itself has no means of exchanging information with the rest of teh world except the LCD window and the number keys.
You literally perform the encryption "manually" as far as the computer is concerned.
Ok, it's not perfect in the sense that if your computer gets owned they can eavesdrop on your sessions and get information about your transactions, but at least they won't be able to withdraw any cash.My main point about this is that security is not a black or white thing, and encrypting transactions can dramatically reduce the number of possible attacks available.
That it may be possible to get personal information about me if they own my computer is not quite the same as being able to withdraw all my savings if the bank used a software implementation.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811412</id>
	<title>Re:Because it's a PITA - Pain In the Ass!</title>
	<author>R2.0</author>
	<datestamp>1263847080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Thanks for the explanation of PITA - for a minute there I was thinking it was a gyro recipe.</p></htmltext>
<tokenext>Thanks for the explanation of PITA - for a minute there I was thinking it was a gyro recipe .</tokentext>
<sentencetext>Thanks for the explanation of PITA - for a minute there I was thinking it was a gyro recipe.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812180</id>
	<title>Server Name Indication</title>
	<author>Kaseijin</author>
	<datestamp>1263807360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>First, keep in mind that name-based virtual hosting with HTTPS is very limited. With few exceptions, you're quite restricted in your ability to host multiple SSL-encrypted sites on a single IP address. Most often, one must instead assign each SSL-encrypted virtualhost to a dedicated IP address. If every website was, today, to switch to HTTPS-only operation, and if the RIRs were to allow it, we would immediately run out of IPv4 addresses.</p></div><p>This is effectively true, but it gives the impression that the problem is inherent to the protocol. The main obstacle to secure name-based virtual hosting is that Microsoft won't implement Server Name Indication for Windows XP.</p></div>
	</htmltext>
<tokenext>First , keep in mind that name-based virtual hosting with HTTPS is very limited .
With few exceptions , you 're quite restricted in your ability to host multiple SSL-encrypted sites on a single IP address .
Most often , one must instead assign each SSL-encrypted virtualhost to a dedicated IP address .
If every website was , today , to switch to HTTPS-only operation , and if the RIRs were to allow it , we would immediately run out of IPv4 addresses.This is effectively true , but it gives the impression that the problem is inherent to the protocol .
The main obstacle to secure name-based virtual hosting is that Microsoft wo n't implement Server Name Indication for Windows XP .</tokentext>
<sentencetext>First, keep in mind that name-based virtual hosting with HTTPS is very limited.
With few exceptions, you're quite restricted in your ability to host multiple SSL-encrypted sites on a single IP address.
Most often, one must instead assign each SSL-encrypted virtualhost to a dedicated IP address.
If every website was, today, to switch to HTTPS-only operation, and if the RIRs were to allow it, we would immediately run out of IPv4 addresses.This is effectively true, but it gives the impression that the problem is inherent to the protocol.
The main obstacle to secure name-based virtual hosting is that Microsoft won't implement Server Name Indication for Windows XP.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809306</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809134</id>
	<title>Re:Signed certificates</title>
	<author>DavidTC</author>
	<datestamp>1263836460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>And there are plenty of places that MitM would not be relevant.</p><p>
For example, email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used (vs. web browsing where people may never return) should be fine with unsigned encryption, as all they need to do is store the cert fingerprint and make a fuss if it changes.</p><p>
But, yes, this is exactly the point I've been making for years. All TCP/IP connections should be opportunistically encrypted, period. Including web pages. There's no reason not to. No, not even CPU. (If the server load is high enough that it matters, by all means, disable it for that server, but it should still be the default.)</p><p>
Even if it's not the default, make it easy enough to flip on, so that web designers can flip it on for their password and account pages without having to buy a damn cert and get a new IP and other nonsense.</p><p>
I just had to set up Thunderbird on a new computer, and I noticed, instead of prompting me what sort of email connection (IMAP or POP3) I had, and making me fill out info, it just asked for the server name, and tried the connection itself, prompting me with the ones it found. But the awesome thing was, it actually suggested using an \_encrypted\_ connection. So, yay, maybe people will actually start using them. (I wonder how many people check their email without even meaning to, via background processes, over open wifi.)</p><p>
The interesting thing about SSL is that the cert is not actually needed, at all. You can use a SSL connection without a cert on <b>either</b> side, just like you can use one with a cert on both sides.</p><p>
Sadly, absolutely nothing seems to support this.</p></htmltext>
<tokenext>And there are plenty of places that MitM would not be relevant .
For example , email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used ( vs. web browsing where people may never return ) should be fine with unsigned encryption , as all they need to do is store the cert fingerprint and make a fuss if it changes .
But , yes , this is exactly the point I 've been making for years .
All TCP/IP connections should be opportunistically encrypted , period .
Including web pages .
There 's no reason not to .
No , not even CPU .
( If the server load is high enough that it matters , by all means , disable it for that server , but it should still be the default .
) Even if it 's not the default , make it easy enough to flip on , so that web designers can flip it on for their password and account pages without having to buy a damn cert and get a new IP and other nonsense .
I just had to set up Thunderbird on a new computer , and I noticed , instead of prompting me what sort of email connection ( IMAP or POP3 ) I had , and making me fill out info , it just asked for the server name , and tried the connection itself , prompting me with the ones it found .
But the awesome thing was , it actually suggested using an \ _encrypted \ _ connection .
So , yay , maybe people will actually start using them .
( I wonder how many people check their email without even meaning to , via background processes , over open wifi .
) The interesting thing about SSL is that the cert is not actually needed , at all .
You can use a SSL connection without a cert on either side , just like you can use one with a cert on both sides .
Sadly , absolutely nothing seems to support this .</tokentext>
<sentencetext>And there are plenty of places that MitM would not be relevant.
For example, email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used (vs. web browsing where people may never return) should be fine with unsigned encryption, as all they need to do is store the cert fingerprint and make a fuss if it changes.
But, yes, this is exactly the point I've been making for years.
All TCP/IP connections should be opportunistically encrypted, period.
Including web pages.
There's no reason not to.
No, not even CPU.
(If the server load is high enough that it matters, by all means, disable it for that server, but it should still be the default.
)
Even if it's not the default, make it easy enough to flip on, so that web designers can flip it on for their password and account pages without having to buy a damn cert and get a new IP and other nonsense.
I just had to set up Thunderbird on a new computer, and I noticed, instead of prompting me what sort of email connection (IMAP or POP3) I had, and making me fill out info, it just asked for the server name, and tried the connection itself, prompting me with the ones it found.
But the awesome thing was, it actually suggested using an \_encrypted\_ connection.
So, yay, maybe people will actually start using them.
(I wonder how many people check their email without even meaning to, via background processes, over open wifi.
)
The interesting thing about SSL is that the cert is not actually needed, at all.
You can use a SSL connection without a cert on either side, just like you can use one with a cert on both sides.
Sadly, absolutely nothing seems to support this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815548</id>
	<title>Re:More direct costs.</title>
	<author>Eil</author>
	<datestamp>1263829380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>It costs a nonzero amount to get a certificate at all, and a self-signed certificate is barely better than raw http.</p></div></blockquote><p>Well, the question was about encryption rather than trust. Trust is a whole different topic. Nobody has yet come up with a good trust model for the public Internet. The one that exists right now is next to worthless for two reasons: 1) Criminals who exploit novice Internet users never bother with using SSL on their phishing sites 2) greater than 99\% of all Internet users who encounter an SSL certificate problem simply click "Okay, proceed" without bothering to understand what the warning is trying to tell them. In terms of trust alone, SSL on the public Internet is as bad or worse as any security theatre you'll find in an airport.</p><p>A self-signed certificate, however, gets you encryption without trust. That in itself is valuable to someone like me. It's incredibly unlikely that anyone would want to target me specifically to pose as my email/web server. I'm mainly concerned about preventing eavesdroppers from picking up the contents of my traffic by sniffing the wifi or compromising a router along the way. And if they did, the chances are pretty high that I would be trying to access my server using a client that already has the certificate saved, so I would likely be warned if the certificate changed in any way.</p><p>Finally, a lot of people fail to realize that there are plenty of situations where you can have both encryption and relative trust without needing the services of a public certificate authority. Anyone can set up their own CA and distribute the root certificate to all computers and devices that need them. This works fine for a corporate intranet or VPN, for example.</p></div>
	</htmltext>
<tokenext>It costs a nonzero amount to get a certificate at all , and a self-signed certificate is barely better than raw http.Well , the question was about encryption rather than trust .
Trust is a whole different topic .
Nobody has yet come up with a good trust model for the public Internet .
The one that exists right now is next to worthless for two reasons : 1 ) Criminals who exploit novice Internet users never bother with using SSL on their phishing sites 2 ) greater than 99 \ % of all Internet users who encounter an SSL certificate problem simply click " Okay , proceed " without bothering to understand what the warning is trying to tell them .
In terms of trust alone , SSL on the public Internet is as bad or worse as any security theatre you 'll find in an airport.A self-signed certificate , however , gets you encryption without trust .
That in itself is valuable to someone like me .
It 's incredibly unlikely that anyone would want to target me specifically to pose as my email/web server .
I 'm mainly concerned about preventing eavesdroppers from picking up the contents of my traffic by sniffing the wifi or compromising a router along the way .
And if they did , the chances are pretty high that I would be trying to access my server using a client that already has the certificate saved , so I would likely be warned if the certificate changed in any way.Finally , a lot of people fail to realize that there are plenty of situations where you can have both encryption and relative trust without needing the services of a public certificate authority .
Anyone can set up their own CA and distribute the root certificate to all computers and devices that need them .
This works fine for a corporate intranet or VPN , for example .</tokentext>
<sentencetext>It costs a nonzero amount to get a certificate at all, and a self-signed certificate is barely better than raw http.Well, the question was about encryption rather than trust.
Trust is a whole different topic.
Nobody has yet come up with a good trust model for the public Internet.
The one that exists right now is next to worthless for two reasons: 1) Criminals who exploit novice Internet users never bother with using SSL on their phishing sites 2) greater than 99\% of all Internet users who encounter an SSL certificate problem simply click "Okay, proceed" without bothering to understand what the warning is trying to tell them.
In terms of trust alone, SSL on the public Internet is as bad or worse as any security theatre you'll find in an airport.A self-signed certificate, however, gets you encryption without trust.
That in itself is valuable to someone like me.
It's incredibly unlikely that anyone would want to target me specifically to pose as my email/web server.
I'm mainly concerned about preventing eavesdroppers from picking up the contents of my traffic by sniffing the wifi or compromising a router along the way.
And if they did, the chances are pretty high that I would be trying to access my server using a client that already has the certificate saved, so I would likely be warned if the certificate changed in any way.Finally, a lot of people fail to realize that there are plenty of situations where you can have both encryption and relative trust without needing the services of a public certificate authority.
Anyone can set up their own CA and distribute the root certificate to all computers and devices that need them.
This works fine for a corporate intranet or VPN, for example.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809926</id>
	<title>THis is topical</title>
	<author>Anonymous</author>
	<datestamp>1263839880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>FUD</p><p>I've been looking into putting TLS on my mail server.  The instructions are not very clear.  It seems certain that I will require a 3rd party certificate.  But I don't find anyone offering a TLS certicate; only SSL.  I'm assuming that an SSL certicate is what I need but NOBODY says that; you know what happens when you assume.</p><p>Then there is the cost.  They do cost and it is not a one time cost.  The certificate system does appear to be structured to maximize cost.  Right now, you have either a self-signed certificate or a 3rd party certificate.  How about a self-signed certificate that is authenticated against my 3rd party certificate?</p><p>It occurs to me that TLS could be used to reduce SPAM.  AFAIK, most spam is sent by spambots.  If all legit mail servers used TLS and spambots didn't have access to a verifiable certificate then they would not be able to operate.</p></htmltext>
<tokenext>FUDI 've been looking into putting TLS on my mail server .
The instructions are not very clear .
It seems certain that I will require a 3rd party certificate .
But I do n't find anyone offering a TLS certicate ; only SSL .
I 'm assuming that an SSL certicate is what I need but NOBODY says that ; you know what happens when you assume.Then there is the cost .
They do cost and it is not a one time cost .
The certificate system does appear to be structured to maximize cost .
Right now , you have either a self-signed certificate or a 3rd party certificate .
How about a self-signed certificate that is authenticated against my 3rd party certificate ? It occurs to me that TLS could be used to reduce SPAM .
AFAIK , most spam is sent by spambots .
If all legit mail servers used TLS and spambots did n't have access to a verifiable certificate then they would not be able to operate .</tokentext>
<sentencetext>FUDI've been looking into putting TLS on my mail server.
The instructions are not very clear.
It seems certain that I will require a 3rd party certificate.
But I don't find anyone offering a TLS certicate; only SSL.
I'm assuming that an SSL certicate is what I need but NOBODY says that; you know what happens when you assume.Then there is the cost.
They do cost and it is not a one time cost.
The certificate system does appear to be structured to maximize cost.
Right now, you have either a self-signed certificate or a 3rd party certificate.
How about a self-signed certificate that is authenticated against my 3rd party certificate?It occurs to me that TLS could be used to reduce SPAM.
AFAIK, most spam is sent by spambots.
If all legit mail servers used TLS and spambots didn't have access to a verifiable certificate then they would not be able to operate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809892</id>
	<title>FTP would be dead</title>
	<author>randallman</author>
	<datestamp>1263839760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>
FTP would be dead if Microsoft would adopt the SSH suite, since SSH has the exact same capabilities as FTP.  SSH is the swiss army knife of encrypted networking.  Port tunneling is very useful.  Less known, but also very nice is the ability to use pipes like this:
</p><p>

<tt>echo "hello" | ssh remote\_host "cat &gt; hello.txt"</tt>

</p><p>
You could use it to make a large backup without consuming disk space on the local machine.
</p><p>

<tt>tar -zc directory\_to\_backup | ssh remote\_host "cat &gt; backup.tar.gz"</tt>

</p><p>It also works very well with rsync.  Combine with hard links for a
<a href="http://www.mikerubel.org/computers/rsync\_snapshots/" title="mikerubel.org">great backup strategy</a> [mikerubel.org].
</p><p>I like to see the surprise from Microsoft centric developers when they discover what SSH can do.  They seem to all have this false assumption that it's just for getting a shell on a remote UNIX system.
</p><p>
Though I haven't kept up with SSH development on Windows, two applications I've used on Windows are:
<a href="http://winscp.net/eng/index.php" title="winscp.net">WinSCP</a> [winscp.net] and
<a href="http://www.chiark.greenend.org.uk/~sgtatham/putty/" title="greenend.org.uk">PUTTY</a> [greenend.org.uk]
<a href="http://sshwindows.sourceforge.net/" title="sourceforge.net">sshwindows</a> [sourceforge.net] also looks interesting as I use cygwin + SSH
</p></htmltext>
<tokenext>FTP would be dead if Microsoft would adopt the SSH suite , since SSH has the exact same capabilities as FTP .
SSH is the swiss army knife of encrypted networking .
Port tunneling is very useful .
Less known , but also very nice is the ability to use pipes like this : echo " hello " | ssh remote \ _host " cat &gt; hello.txt " You could use it to make a large backup without consuming disk space on the local machine .
tar -zc directory \ _to \ _backup | ssh remote \ _host " cat &gt; backup.tar.gz " It also works very well with rsync .
Combine with hard links for a great backup strategy [ mikerubel.org ] .
I like to see the surprise from Microsoft centric developers when they discover what SSH can do .
They seem to all have this false assumption that it 's just for getting a shell on a remote UNIX system .
Though I have n't kept up with SSH development on Windows , two applications I 've used on Windows are : WinSCP [ winscp.net ] and PUTTY [ greenend.org.uk ] sshwindows [ sourceforge.net ] also looks interesting as I use cygwin + SSH</tokentext>
<sentencetext>
FTP would be dead if Microsoft would adopt the SSH suite, since SSH has the exact same capabilities as FTP.
SSH is the swiss army knife of encrypted networking.
Port tunneling is very useful.
Less known, but also very nice is the ability to use pipes like this:


echo "hello" | ssh remote\_host "cat &gt; hello.txt"


You could use it to make a large backup without consuming disk space on the local machine.
tar -zc directory\_to\_backup | ssh remote\_host "cat &gt; backup.tar.gz"

It also works very well with rsync.
Combine with hard links for a
great backup strategy [mikerubel.org].
I like to see the surprise from Microsoft centric developers when they discover what SSH can do.
They seem to all have this false assumption that it's just for getting a shell on a remote UNIX system.
Though I haven't kept up with SSH development on Windows, two applications I've used on Windows are:
WinSCP [winscp.net] and
PUTTY [greenend.org.uk]
sshwindows [sourceforge.net] also looks interesting as I use cygwin + SSH
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810042</id>
	<title>Why?</title>
	<author>jaygridley</author>
	<datestamp>1263840420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Why should I go drop $1000+ for a SSL cert from Verisign for my website when its not passing any sensitive/confidential information "just because"?</htmltext>
<tokenext>Why should I go drop $ 1000 + for a SSL cert from Verisign for my website when its not passing any sensitive/confidential information " just because " ?</tokentext>
<sentencetext>Why should I go drop $1000+ for a SSL cert from Verisign for my website when its not passing any sensitive/confidential information "just because"?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810734</id>
	<title>It's not necessary</title>
	<author>Evilclicker</author>
	<datestamp>1263843720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>First of all HTTPS is totally unnecessary for 99.9\% of the internet.  The VAST MAJORITY of content is static, or dynamic but doesn't change per user, so it's not generally unneeded.  HTTPS adds cost and complexity to the site that is probably not even necessary.

Second, encrypted email is nice, but also typically unnecessary.  Think about the majority of emails you send?  Are you sending credit card numbers and social security numbers in your email?  No, chances are you saying "Bill slept with Jan last night" or some other stupid BS that nobody really cares about.  Even in company email it's generally something like Did you do this? No, ok.  However, in company email it's a little different because the mail server is behind a FW anyway so again, encryption becomes unnecessary unless you're trying to hide something from the employees.

As for FTP, seriously?  Are we transferring bank account numbers via FTP now?  Last time I checked FTP was just used for transferring random files, and assuming you don't have some CIA top secret documents you're transferring via FTP for some strange reason, it's perfectly fine.  It's not like it's that hard to setup SFTP if you really need it, but chances are, you don't.

In summary, you must not be in the IT field or you would know that the general consensus is make it easy and usable.  Security is only a concern when private data is really an issue (CC/SS/etc), and all of those type of sites are properly secured.  And just in case you haven't noticed, every encryption technology that has ever been created, has already been cracked anyway, so it doesn't even matter if these technologies are used, they can still be cracked, and the data read.  I'm betting the sheer volume of traffic over the internet is security enough.. nobody has enough time to go through all that.</htmltext>
<tokenext>First of all HTTPS is totally unnecessary for 99.9 \ % of the internet .
The VAST MAJORITY of content is static , or dynamic but does n't change per user , so it 's not generally unneeded .
HTTPS adds cost and complexity to the site that is probably not even necessary .
Second , encrypted email is nice , but also typically unnecessary .
Think about the majority of emails you send ?
Are you sending credit card numbers and social security numbers in your email ?
No , chances are you saying " Bill slept with Jan last night " or some other stupid BS that nobody really cares about .
Even in company email it 's generally something like Did you do this ?
No , ok. However , in company email it 's a little different because the mail server is behind a FW anyway so again , encryption becomes unnecessary unless you 're trying to hide something from the employees .
As for FTP , seriously ?
Are we transferring bank account numbers via FTP now ?
Last time I checked FTP was just used for transferring random files , and assuming you do n't have some CIA top secret documents you 're transferring via FTP for some strange reason , it 's perfectly fine .
It 's not like it 's that hard to setup SFTP if you really need it , but chances are , you do n't .
In summary , you must not be in the IT field or you would know that the general consensus is make it easy and usable .
Security is only a concern when private data is really an issue ( CC/SS/etc ) , and all of those type of sites are properly secured .
And just in case you have n't noticed , every encryption technology that has ever been created , has already been cracked anyway , so it does n't even matter if these technologies are used , they can still be cracked , and the data read .
I 'm betting the sheer volume of traffic over the internet is security enough.. nobody has enough time to go through all that .</tokentext>
<sentencetext>First of all HTTPS is totally unnecessary for 99.9\% of the internet.
The VAST MAJORITY of content is static, or dynamic but doesn't change per user, so it's not generally unneeded.
HTTPS adds cost and complexity to the site that is probably not even necessary.
Second, encrypted email is nice, but also typically unnecessary.
Think about the majority of emails you send?
Are you sending credit card numbers and social security numbers in your email?
No, chances are you saying "Bill slept with Jan last night" or some other stupid BS that nobody really cares about.
Even in company email it's generally something like Did you do this?
No, ok.  However, in company email it's a little different because the mail server is behind a FW anyway so again, encryption becomes unnecessary unless you're trying to hide something from the employees.
As for FTP, seriously?
Are we transferring bank account numbers via FTP now?
Last time I checked FTP was just used for transferring random files, and assuming you don't have some CIA top secret documents you're transferring via FTP for some strange reason, it's perfectly fine.
It's not like it's that hard to setup SFTP if you really need it, but chances are, you don't.
In summary, you must not be in the IT field or you would know that the general consensus is make it easy and usable.
Security is only a concern when private data is really an issue (CC/SS/etc), and all of those type of sites are properly secured.
And just in case you haven't noticed, every encryption technology that has ever been created, has already been cracked anyway, so it doesn't even matter if these technologies are used, they can still be cracked, and the data read.
I'm betting the sheer volume of traffic over the internet is security enough.. nobody has enough time to go through all that.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808816</id>
	<title>There's no reason to encrypt HTTP</title>
	<author>Anonymous</author>
	<datestamp>1263835200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>There's no reason to encrypt HTTP requests that don't contain personal information.</p></htmltext>
<tokenext>There 's no reason to encrypt HTTP requests that do n't contain personal information .</tokentext>
<sentencetext>There's no reason to encrypt HTTP requests that don't contain personal information.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809366</id>
	<title>Expertise</title>
	<author>Anonymous</author>
	<datestamp>1263837480000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Until a couple of years ago, I was a consultant for a large three-letter firm (not IBM) that got a project to implement an internal certificate authority that would be trusted by external partners, in support of email encryption.</p><p>Some other projects came up that I needed to do and we started searching for someone else within this 20,000+ employee technology company that could do the project and had at least some familiarity with PKI issues.</p><p>There was noone.</p><p>Couple that with the fact that we were getting the CA signed by an internal division of the company with a globally-trusted root CA, and that division had precisely two employees.  To run a public root CA.</p><p>I've been in IT for over 15 years, and I think the number of people I've met in that time who see PKI as anything other than a magical black box can be counted on one hand with fingers left over.</p></htmltext>
<tokenext>Until a couple of years ago , I was a consultant for a large three-letter firm ( not IBM ) that got a project to implement an internal certificate authority that would be trusted by external partners , in support of email encryption.Some other projects came up that I needed to do and we started searching for someone else within this 20,000 + employee technology company that could do the project and had at least some familiarity with PKI issues.There was noone.Couple that with the fact that we were getting the CA signed by an internal division of the company with a globally-trusted root CA , and that division had precisely two employees .
To run a public root CA.I 've been in IT for over 15 years , and I think the number of people I 've met in that time who see PKI as anything other than a magical black box can be counted on one hand with fingers left over .</tokentext>
<sentencetext>Until a couple of years ago, I was a consultant for a large three-letter firm (not IBM) that got a project to implement an internal certificate authority that would be trusted by external partners, in support of email encryption.Some other projects came up that I needed to do and we started searching for someone else within this 20,000+ employee technology company that could do the project and had at least some familiarity with PKI issues.There was noone.Couple that with the fact that we were getting the CA signed by an internal division of the company with a globally-trusted root CA, and that division had precisely two employees.
To run a public root CA.I've been in IT for over 15 years, and I think the number of people I've met in that time who see PKI as anything other than a magical black box can be counted on one hand with fingers left over.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810282</id>
	<title>Re:Costs?</title>
	<author>Anonymous</author>
	<datestamp>1263841560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Don't forget ass-backward company Microsoft - Outlook doesn't support OpenPGP, you need a plugin to be able to read and send PGP encrypted email. Combine this with the fact that although everybody has to follow a mandatory IT course in secondary school, people aren't educated at all about how the internet works and they won't see the benefit and won't install any plugin. The only way this will change, especially in the corporate world, is when Microsoft makes applying encryption the default in Outlook. But realistically that won't happen, because you'd have to ask the user to create a key, distribute the public key, and so on. Users will simply click "Cancel", probably even if the dialog pops up every single time you click "Send".</p></htmltext>
<tokenext>Do n't forget ass-backward company Microsoft - Outlook does n't support OpenPGP , you need a plugin to be able to read and send PGP encrypted email .
Combine this with the fact that although everybody has to follow a mandatory IT course in secondary school , people are n't educated at all about how the internet works and they wo n't see the benefit and wo n't install any plugin .
The only way this will change , especially in the corporate world , is when Microsoft makes applying encryption the default in Outlook .
But realistically that wo n't happen , because you 'd have to ask the user to create a key , distribute the public key , and so on .
Users will simply click " Cancel " , probably even if the dialog pops up every single time you click " Send " .</tokentext>
<sentencetext>Don't forget ass-backward company Microsoft - Outlook doesn't support OpenPGP, you need a plugin to be able to read and send PGP encrypted email.
Combine this with the fact that although everybody has to follow a mandatory IT course in secondary school, people aren't educated at all about how the internet works and they won't see the benefit and won't install any plugin.
The only way this will change, especially in the corporate world, is when Microsoft makes applying encryption the default in Outlook.
But realistically that won't happen, because you'd have to ask the user to create a key, distribute the public key, and so on.
Users will simply click "Cancel", probably even if the dialog pops up every single time you click "Send".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815460</id>
	<title>Re:Costs?</title>
	<author>Anonymous</author>
	<datestamp>1263828420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Key management, while an important issue to consider, (as is creating a PKI for your organization) is not whats holding use of encryption back.</p><p>Email clients can already do that. Using Outlook combined with PGP desktop, one can automatically sync keys with the PGP keyserver, or an internal source. S/MIME keys are automatically exchanged when I send you an email. Contained inside the certificate w/ signature I just emailed you is the public key.</p></htmltext>
<tokenext>Key management , while an important issue to consider , ( as is creating a PKI for your organization ) is not whats holding use of encryption back.Email clients can already do that .
Using Outlook combined with PGP desktop , one can automatically sync keys with the PGP keyserver , or an internal source .
S/MIME keys are automatically exchanged when I send you an email .
Contained inside the certificate w/ signature I just emailed you is the public key .</tokentext>
<sentencetext>Key management, while an important issue to consider, (as is creating a PKI for your organization) is not whats holding use of encryption back.Email clients can already do that.
Using Outlook combined with PGP desktop, one can automatically sync keys with the PGP keyserver, or an internal source.
S/MIME keys are automatically exchanged when I send you an email.
Contained inside the certificate w/ signature I just emailed you is the public key.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810900</id>
	<title>Re:Signed certificates</title>
	<author>Anonymous</author>
	<datestamp>1263844620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>For example, email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used (vs. web browsing where people may never return) should be fine with unsigned encryption.</p></div><p>Indeed.  What's more, I'd argue that the <em>content</em> of these sites is usually sufficient proof that they are who they purport to be.  Say I SSH into my home media server.  I believe that I'm talking to the machine I think I am if-and-only-if it has the 2 TB of media I expect it to have.  That -- especially if public keys are stored by clients, a la SSH -- is all the authentication most users need.</p></div>
	</htmltext>
<tokenext>For example , email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used ( vs. web browsing where people may never return ) should be fine with unsigned encryption.Indeed .
What 's more , I 'd argue that the content of these sites is usually sufficient proof that they are who they purport to be .
Say I SSH into my home media server .
I believe that I 'm talking to the machine I think I am if-and-only-if it has the 2 TB of media I expect it to have .
That -- especially if public keys are stored by clients , a la SSH -- is all the authentication most users need .</tokentext>
<sentencetext>For example, email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used (vs. web browsing where people may never return) should be fine with unsigned encryption.Indeed.
What's more, I'd argue that the content of these sites is usually sufficient proof that they are who they purport to be.
Say I SSH into my home media server.
I believe that I'm talking to the machine I think I am if-and-only-if it has the 2 TB of media I expect it to have.
That -- especially if public keys are stored by clients, a la SSH -- is all the authentication most users need.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809134</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812832</id>
	<title>There is no escape</title>
	<author>UBfusion</author>
	<datestamp>1263810540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>+1 Insightful - I wonder why this was not the topic of the first comment.</p><p>I don't want to sound pessimistic or paranoid, but from the signs so far I firmly believe that soon the use of encryption will be reason enough for any obscure organisation to raid my house/office/computer.</p><p>This is the main reason I do not practice or even consider any kind of encryption. After 20+ years of being online, I think that any sudden change of online behaviour from my static IP will raise a flag on this or another continent. Therefore, I prefer obscurity through transparency: I take special care everyday to visit xxx sites, check new conspiracy theories, visit celeb and gov sites etc like any normal curious person. However I avoid the googleplex, facebook and all permanent records of any personal details on social networks.</p><p>Yes, I know about proxies, anonymizers, Tor etc, but I consider these as the orange flags because using them also can be interpreted as changes of online behaviour. There is no escape.</p></htmltext>
<tokenext>+ 1 Insightful - I wonder why this was not the topic of the first comment.I do n't want to sound pessimistic or paranoid , but from the signs so far I firmly believe that soon the use of encryption will be reason enough for any obscure organisation to raid my house/office/computer.This is the main reason I do not practice or even consider any kind of encryption .
After 20 + years of being online , I think that any sudden change of online behaviour from my static IP will raise a flag on this or another continent .
Therefore , I prefer obscurity through transparency : I take special care everyday to visit xxx sites , check new conspiracy theories , visit celeb and gov sites etc like any normal curious person .
However I avoid the googleplex , facebook and all permanent records of any personal details on social networks.Yes , I know about proxies , anonymizers , Tor etc , but I consider these as the orange flags because using them also can be interpreted as changes of online behaviour .
There is no escape .</tokentext>
<sentencetext>+1 Insightful - I wonder why this was not the topic of the first comment.I don't want to sound pessimistic or paranoid, but from the signs so far I firmly believe that soon the use of encryption will be reason enough for any obscure organisation to raid my house/office/computer.This is the main reason I do not practice or even consider any kind of encryption.
After 20+ years of being online, I think that any sudden change of online behaviour from my static IP will raise a flag on this or another continent.
Therefore, I prefer obscurity through transparency: I take special care everyday to visit xxx sites, check new conspiracy theories, visit celeb and gov sites etc like any normal curious person.
However I avoid the googleplex, facebook and all permanent records of any personal details on social networks.Yes, I know about proxies, anonymizers, Tor etc, but I consider these as the orange flags because using them also can be interpreted as changes of online behaviour.
There is no escape.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810226</id>
	<title>Re:Encryption is too hard</title>
	<author>Anonymous</author>
	<datestamp>1263841260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>As for Google they just made https the default for browsing Gmail, so yay for that.</p><p>As for having some kind of private key system, Google will never do that without having a backdoor or copy of the key that allows them to scan the email and add their relevant ads.</p></htmltext>
<tokenext>As for Google they just made https the default for browsing Gmail , so yay for that.As for having some kind of private key system , Google will never do that without having a backdoor or copy of the key that allows them to scan the email and add their relevant ads .</tokentext>
<sentencetext>As for Google they just made https the default for browsing Gmail, so yay for that.As for having some kind of private key system, Google will never do that without having a backdoor or copy of the key that allows them to scan the email and add their relevant ads.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809544</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810556</id>
	<title>Re:encryption alone</title>
	<author>jarocho</author>
	<datestamp>1263842880000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>In a sense, though, the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc... As well as, in a corporate context, not locking-down the network and machine and user profile, so that keylogging executables aren't so much of a problem. Even if the business and/or customers complain about "impact", there's always a way to win the argument for establishing and enforcing IT policies that make sense. You have to be willing to save users from themselves.</htmltext>
<tokenext>In a sense , though , the weakest link is actually the sysadmin , who is n't enforcing appropriate password complexity , length , age , etc... As well as , in a corporate context , not locking-down the network and machine and user profile , so that keylogging executables are n't so much of a problem .
Even if the business and/or customers complain about " impact " , there 's always a way to win the argument for establishing and enforcing IT policies that make sense .
You have to be willing to save users from themselves .</tokentext>
<sentencetext>In a sense, though, the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc... As well as, in a corporate context, not locking-down the network and machine and user profile, so that keylogging executables aren't so much of a problem.
Even if the business and/or customers complain about "impact", there's always a way to win the argument for establishing and enforcing IT policies that make sense.
You have to be willing to save users from themselves.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809308</id>
	<title>Business email</title>
	<author>freedumb2000</author>
	<datestamp>1263837240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>In the case of email I am not using encryption because none of my business contacts are. It is kind of like with MS Word. I would love to use something different and I never mail out doc files, only PDF, but if everyone else is doing it's hard to stand your ground.</htmltext>
<tokenext>In the case of email I am not using encryption because none of my business contacts are .
It is kind of like with MS Word .
I would love to use something different and I never mail out doc files , only PDF , but if everyone else is doing it 's hard to stand your ground .</tokentext>
<sentencetext>In the case of email I am not using encryption because none of my business contacts are.
It is kind of like with MS Word.
I would love to use something different and I never mail out doc files, only PDF, but if everyone else is doing it's hard to stand your ground.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809718</id>
	<title>two words....Key Management</title>
	<author>Anonymous</author>
	<datestamp>1263839040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The problem with Encryption is not the protocols it is the management. Until Windows automagically installs and sets it up for you it is not likely to get heavily used outside of places where the expertise already exists.</p></htmltext>
<tokenext>The problem with Encryption is not the protocols it is the management .
Until Windows automagically installs and sets it up for you it is not likely to get heavily used outside of places where the expertise already exists .</tokentext>
<sentencetext>The problem with Encryption is not the protocols it is the management.
Until Windows automagically installs and sets it up for you it is not likely to get heavily used outside of places where the expertise already exists.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815470</id>
	<title>US Government</title>
	<author>Anonymous</author>
	<datestamp>1263828540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>One word: ITAR.<br>http://en.wikipedia.org/wiki/ITAR</p></htmltext>
<tokenext>One word : ITAR.http : //en.wikipedia.org/wiki/ITAR</tokentext>
<sentencetext>One word: ITAR.http://en.wikipedia.org/wiki/ITAR</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817212</id>
	<title>Re:VS Electronic-Arts</title>
	<author>IBBoard</author>
	<datestamp>1263894900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I can understand EA doing it - after all, they're 'just' a games company - but the one that really makes me laugh/cry is the British Computing Society. They're the professional organisation for IT-related careers in the UK and <i>they</i> send you your actual password! Of all the places that I'd expect decent security from, the nationally (possibly internationally) recognised organisation for IT pros would be it, but apparently not.</p></htmltext>
<tokenext>I can understand EA doing it - after all , they 're 'just ' a games company - but the one that really makes me laugh/cry is the British Computing Society .
They 're the professional organisation for IT-related careers in the UK and they send you your actual password !
Of all the places that I 'd expect decent security from , the nationally ( possibly internationally ) recognised organisation for IT pros would be it , but apparently not .</tokentext>
<sentencetext>I can understand EA doing it - after all, they're 'just' a games company - but the one that really makes me laugh/cry is the British Computing Society.
They're the professional organisation for IT-related careers in the UK and they send you your actual password!
Of all the places that I'd expect decent security from, the nationally (possibly internationally) recognised organisation for IT pros would be it, but apparently not.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810164</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812324</id>
	<title>Someone must be making money off identity theft</title>
	<author>rwa2</author>
	<datestamp>1263807900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Maybe the insurance companies?</p><p>I want to know why I still have to guard my SSN and my mother's maiden name like it's some sort of dirty secret.  No one should be able to open up a credit card in my name unless they somehow got the request signed with my private key.</p></htmltext>
<tokenext>Maybe the insurance companies ? I want to know why I still have to guard my SSN and my mother 's maiden name like it 's some sort of dirty secret .
No one should be able to open up a credit card in my name unless they somehow got the request signed with my private key .</tokentext>
<sentencetext>Maybe the insurance companies?I want to know why I still have to guard my SSN and my mother's maiden name like it's some sort of dirty secret.
No one should be able to open up a credit card in my name unless they somehow got the request signed with my private key.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809672</id>
	<title>Practicality</title>
	<author>Kjella</author>
	<datestamp>1263838800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I work with a vendor that implemented a nice secure upload facility for their support services. I'm sure it's secure, but I haven't been able to use it at a single customer yet because of firewalls and plugin blockers and who knows what else. So instead of using the plain HTTP which they so kindly removed, I now email everything to them instead. Luckily they got an intelligent script that'll parse mail and file it to my case.</p></htmltext>
<tokenext>I work with a vendor that implemented a nice secure upload facility for their support services .
I 'm sure it 's secure , but I have n't been able to use it at a single customer yet because of firewalls and plugin blockers and who knows what else .
So instead of using the plain HTTP which they so kindly removed , I now email everything to them instead .
Luckily they got an intelligent script that 'll parse mail and file it to my case .</tokentext>
<sentencetext>I work with a vendor that implemented a nice secure upload facility for their support services.
I'm sure it's secure, but I haven't been able to use it at a single customer yet because of firewalls and plugin blockers and who knows what else.
So instead of using the plain HTTP which they so kindly removed, I now email everything to them instead.
Luckily they got an intelligent script that'll parse mail and file it to my case.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813160</id>
	<title>It's the money grubbing root authorities...</title>
	<author>n0tWorthy</author>
	<datestamp>1263812100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>that have led us to this. Certificates should cost no more than $10 yet Verisign wants $1000 for a 1 year enhanced web site certificate. Thawte wants $995 for 2 years. Out and out piracy is my opinion. I'm pretty sure that there would be a lot more security in the small businesses I support if I could buy them certificates for  $25.</p></htmltext>
<tokenext>that have led us to this .
Certificates should cost no more than $ 10 yet Verisign wants $ 1000 for a 1 year enhanced web site certificate .
Thawte wants $ 995 for 2 years .
Out and out piracy is my opinion .
I 'm pretty sure that there would be a lot more security in the small businesses I support if I could buy them certificates for $ 25 .</tokentext>
<sentencetext>that have led us to this.
Certificates should cost no more than $10 yet Verisign wants $1000 for a 1 year enhanced web site certificate.
Thawte wants $995 for 2 years.
Out and out piracy is my opinion.
I'm pretty sure that there would be a lot more security in the small businesses I support if I could buy them certificates for  $25.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811192</id>
	<title>Encryption is not always a good thing</title>
	<author>junglebeast</author>
	<datestamp>1263846120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Sure, everything could be encrypted but encryption data requires more bandwidth to transmit the same amount of data.  This would make your internet connection appear slower.  It also requires more processing power to encrypt and decrypt, which again, would make the internet appear slower for the end-user.

It's not just about speed.  Because of the increased computational effort, it would require more power to do equivalent tasks.  This means laptop batteries would not last as long, and it would increase greenhouse gas emissions because ultimately that means power plants would have to produce more power.

For sending important private data, sure, encrypt that stuff...but let's not all get paranoid and ask that EVERYTHING be encrypted.</htmltext>
<tokenext>Sure , everything could be encrypted but encryption data requires more bandwidth to transmit the same amount of data .
This would make your internet connection appear slower .
It also requires more processing power to encrypt and decrypt , which again , would make the internet appear slower for the end-user .
It 's not just about speed .
Because of the increased computational effort , it would require more power to do equivalent tasks .
This means laptop batteries would not last as long , and it would increase greenhouse gas emissions because ultimately that means power plants would have to produce more power .
For sending important private data , sure , encrypt that stuff...but let 's not all get paranoid and ask that EVERYTHING be encrypted .</tokentext>
<sentencetext>Sure, everything could be encrypted but encryption data requires more bandwidth to transmit the same amount of data.
This would make your internet connection appear slower.
It also requires more processing power to encrypt and decrypt, which again, would make the internet appear slower for the end-user.
It's not just about speed.
Because of the increased computational effort, it would require more power to do equivalent tasks.
This means laptop batteries would not last as long, and it would increase greenhouse gas emissions because ultimately that means power plants would have to produce more power.
For sending important private data, sure, encrypt that stuff...but let's not all get paranoid and ask that EVERYTHING be encrypted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811862</id>
	<title>What's holding back encryption?</title>
	<author>Sir\_Real</author>
	<datestamp>1263805860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is easy.  It's not worth it.  The losses attributable to "not encrypting" something are less than the cost of "encrypting everything" and managing it.  It doesn't hurt enough yet.  Wait till we get a large scale breach of a service like alt.com or adultfriendfinder.  You will then see some action.  Capitalism is not pro-active unless it's clearly profitable and has little risk.</p></htmltext>
<tokenext>This is easy .
It 's not worth it .
The losses attributable to " not encrypting " something are less than the cost of " encrypting everything " and managing it .
It does n't hurt enough yet .
Wait till we get a large scale breach of a service like alt.com or adultfriendfinder .
You will then see some action .
Capitalism is not pro-active unless it 's clearly profitable and has little risk .</tokentext>
<sentencetext>This is easy.
It's not worth it.
The losses attributable to "not encrypting" something are less than the cost of "encrypting everything" and managing it.
It doesn't hurt enough yet.
Wait till we get a large scale breach of a service like alt.com or adultfriendfinder.
You will then see some action.
Capitalism is not pro-active unless it's clearly profitable and has little risk.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809542</id>
	<title>I can only answer for myself</title>
	<author>obarthelemy</author>
	<datestamp>1263838260000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>But I'm not really using encryption because</p><p>1- I don't have much of value to encrypt. Clearly, that's not the case for everyone, but encrypting my to-do list, address book, birthday list, and pathetic attempts at programming seem very much overkill.<br>2- I don't feel confident I would do encryption right. I COULD encrypt my password list, but right now it's on a piece of paper hidden somewhere. If it were on my PC or cellphone, even encrypted, I'm not confident that i would be using a secure encryption method, nor that it wouldn't be short-circuited by a trojan/keylogger<br>3- I'm afraid I'll get encrypted out of my data. A few times a year, I have to clean up my HD and recover broken files. What happens when the files are encrypted on top of it ? Any way to recover them ?<br>4- Is encryption reliable ? what if I can't recover my data after I encrypted it ?<br>5- I'm not sure what programs I should use. Windows has some basic stuff, then there's PGP, Truecrypt...</p></htmltext>
<tokenext>But I 'm not really using encryption because1- I do n't have much of value to encrypt .
Clearly , that 's not the case for everyone , but encrypting my to-do list , address book , birthday list , and pathetic attempts at programming seem very much overkill.2- I do n't feel confident I would do encryption right .
I COULD encrypt my password list , but right now it 's on a piece of paper hidden somewhere .
If it were on my PC or cellphone , even encrypted , I 'm not confident that i would be using a secure encryption method , nor that it would n't be short-circuited by a trojan/keylogger3- I 'm afraid I 'll get encrypted out of my data .
A few times a year , I have to clean up my HD and recover broken files .
What happens when the files are encrypted on top of it ?
Any way to recover them ? 4- Is encryption reliable ?
what if I ca n't recover my data after I encrypted it ? 5- I 'm not sure what programs I should use .
Windows has some basic stuff , then there 's PGP , Truecrypt.. .</tokentext>
<sentencetext>But I'm not really using encryption because1- I don't have much of value to encrypt.
Clearly, that's not the case for everyone, but encrypting my to-do list, address book, birthday list, and pathetic attempts at programming seem very much overkill.2- I don't feel confident I would do encryption right.
I COULD encrypt my password list, but right now it's on a piece of paper hidden somewhere.
If it were on my PC or cellphone, even encrypted, I'm not confident that i would be using a secure encryption method, nor that it wouldn't be short-circuited by a trojan/keylogger3- I'm afraid I'll get encrypted out of my data.
A few times a year, I have to clean up my HD and recover broken files.
What happens when the files are encrypted on top of it ?
Any way to recover them ?4- Is encryption reliable ?
what if I can't recover my data after I encrypted it ?5- I'm not sure what programs I should use.
Windows has some basic stuff, then there's PGP, Truecrypt...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809014</id>
	<title>Ethan Hunt</title>
	<author>holophrastic</author>
	<datestamp>1263835980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Outside of our industry of computers and internets, security is handled wiht a simple motto -- secure what needs securing.  With the knowledge that Ethan Hunt will always be able to break in, the question is not "what is insecure" but "what is being stolen".  You don't need to secure something that no one wants.</p><p>Your home is easy to break into.  Maybe you have a lock.  Maybe you have a dead-bolt.  Your locks can be carded, your dead-bolt can be picked.</p><p>You wouldn't want real security at your front door, because you'd be trapped outside more often than an actual burgler.</p><p>The same is true of computer security.  If no one is breaking in, why would you want to slow everything down.  My FTP traffic isn't that important.  It's just code, and very few people think they want it.</p></htmltext>
<tokenext>Outside of our industry of computers and internets , security is handled wiht a simple motto -- secure what needs securing .
With the knowledge that Ethan Hunt will always be able to break in , the question is not " what is insecure " but " what is being stolen " .
You do n't need to secure something that no one wants.Your home is easy to break into .
Maybe you have a lock .
Maybe you have a dead-bolt .
Your locks can be carded , your dead-bolt can be picked.You would n't want real security at your front door , because you 'd be trapped outside more often than an actual burgler.The same is true of computer security .
If no one is breaking in , why would you want to slow everything down .
My FTP traffic is n't that important .
It 's just code , and very few people think they want it .</tokentext>
<sentencetext>Outside of our industry of computers and internets, security is handled wiht a simple motto -- secure what needs securing.
With the knowledge that Ethan Hunt will always be able to break in, the question is not "what is insecure" but "what is being stolen".
You don't need to secure something that no one wants.Your home is easy to break into.
Maybe you have a lock.
Maybe you have a dead-bolt.
Your locks can be carded, your dead-bolt can be picked.You wouldn't want real security at your front door, because you'd be trapped outside more often than an actual burgler.The same is true of computer security.
If no one is breaking in, why would you want to slow everything down.
My FTP traffic isn't that important.
It's just code, and very few people think they want it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810706</id>
	<title>The Government can't read it</title>
	<author>0p7imu5\_P2im3</author>
	<datestamp>1263843540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The fact of the matter is that the CIA and NSA have their hands so deep in all the tech companies pockets that none of them want to make it easy for fear of losing the government funding or monopoly protection that those government agencies provide.</htmltext>
<tokenext>The fact of the matter is that the CIA and NSA have their hands so deep in all the tech companies pockets that none of them want to make it easy for fear of losing the government funding or monopoly protection that those government agencies provide .</tokentext>
<sentencetext>The fact of the matter is that the CIA and NSA have their hands so deep in all the tech companies pockets that none of them want to make it easy for fear of losing the government funding or monopoly protection that those government agencies provide.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810484</id>
	<title>Re:Expertise</title>
	<author>Anonymous</author>
	<datestamp>1263842520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What is ironic is that a properly administered infrastructure would mean a great boon to privacy.</p><p>Setting the ID debate aside, Picture an ID card with a smart card on it.  The private key on the smart card is signed by the state with a certificate saying that the person who the key belongs to is above 21 and is of legal drinking age.  Now when the cardholder hits a bar and the card gets scanned, the establishment gets the one key point of information they need by law, and no more.  They don't need someone's birthdate, just proof they are over 21.</p><p>Similar with degrees awarded by colleges.  A college can make a certificate saying that so and so got a M. S. in chainsaw fencing on May of 2009, and an accrediation agency can sign the college's key.  This allows sufficiant proof of a college degree, but without requiring invasive searches.</p></htmltext>
<tokenext>What is ironic is that a properly administered infrastructure would mean a great boon to privacy.Setting the ID debate aside , Picture an ID card with a smart card on it .
The private key on the smart card is signed by the state with a certificate saying that the person who the key belongs to is above 21 and is of legal drinking age .
Now when the cardholder hits a bar and the card gets scanned , the establishment gets the one key point of information they need by law , and no more .
They do n't need someone 's birthdate , just proof they are over 21.Similar with degrees awarded by colleges .
A college can make a certificate saying that so and so got a M. S. in chainsaw fencing on May of 2009 , and an accrediation agency can sign the college 's key .
This allows sufficiant proof of a college degree , but without requiring invasive searches .</tokentext>
<sentencetext>What is ironic is that a properly administered infrastructure would mean a great boon to privacy.Setting the ID debate aside, Picture an ID card with a smart card on it.
The private key on the smart card is signed by the state with a certificate saying that the person who the key belongs to is above 21 and is of legal drinking age.
Now when the cardholder hits a bar and the card gets scanned, the establishment gets the one key point of information they need by law, and no more.
They don't need someone's birthdate, just proof they are over 21.Similar with degrees awarded by colleges.
A college can make a certificate saying that so and so got a M. S. in chainsaw fencing on May of 2009, and an accrediation agency can sign the college's key.
This allows sufficiant proof of a college degree, but without requiring invasive searches.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809366</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813062</id>
	<title>Re:What's the problem?</title>
	<author>HeckRuler</author>
	<datestamp>1263811680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>So, presuming you handed one of the DVDs to you mother in person (otherwise I'd ask who you handed said DVD to in order for it to arrive at your mother's), then there is now a DVD located in the house of little old lady which is vital to proving a comment on slashdot wrong.

Gentlemen, my mission is clear, I must be off...</htmltext>
<tokenext>So , presuming you handed one of the DVDs to you mother in person ( otherwise I 'd ask who you handed said DVD to in order for it to arrive at your mother 's ) , then there is now a DVD located in the house of little old lady which is vital to proving a comment on slashdot wrong .
Gentlemen , my mission is clear , I must be off.. .</tokentext>
<sentencetext>So, presuming you handed one of the DVDs to you mother in person (otherwise I'd ask who you handed said DVD to in order for it to arrive at your mother's), then there is now a DVD located in the house of little old lady which is vital to proving a comment on slashdot wrong.
Gentlemen, my mission is clear, I must be off...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809566</id>
	<title>Re:Inertia</title>
	<author>Pascal Sartoretti</author>
	<datestamp>1263838380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Remember back in the day when the OpenBSD guys said Enough Already and
pretty much dropped telnet, rsh, rcp, rlogin, etc.  for the SSH suite of
tools?  Yeah, a bit of growing pains at the time but no one would want to go
back.</p> </div><p>I am looking forward for OpenBSD to drop IPv4 use only IPv6...</p></div>
	</htmltext>
<tokenext>Remember back in the day when the OpenBSD guys said Enough Already and pretty much dropped telnet , rsh , rcp , rlogin , etc .
for the SSH suite of tools ?
Yeah , a bit of growing pains at the time but no one would want to go back .
I am looking forward for OpenBSD to drop IPv4 use only IPv6.. .</tokentext>
<sentencetext>Remember back in the day when the OpenBSD guys said Enough Already and
pretty much dropped telnet, rsh, rcp, rlogin, etc.
for the SSH suite of
tools?
Yeah, a bit of growing pains at the time but no one would want to go
back.
I am looking forward for OpenBSD to drop IPv4 use only IPv6...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808872</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813698</id>
	<title>Smart Card</title>
	<author>K-tWizel</author>
	<datestamp>1263814680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Most large (and some mid) companies employ a SmartCard of some kind for access to the building.  Adding a smart card with a chip then help authenticate getting into the building and (with certs on the chip/card) auth the user onto the network and provide for digital signatures and encryption.  Most companies also have a policy governing levels of protected information and how it is shared.  There is a bit of 'heavy lifting' as far as implementation and it would come down to how much risk is acceptable.  I have worked in both environments and hybrids in-between.  SmartCard logon as building ID is the smoothest and easiest for the user as well since a single PIN is needed with the SmartCard.  With most people familiar with Bank ATMs, this should be a no brain-er</htmltext>
<tokenext>Most large ( and some mid ) companies employ a SmartCard of some kind for access to the building .
Adding a smart card with a chip then help authenticate getting into the building and ( with certs on the chip/card ) auth the user onto the network and provide for digital signatures and encryption .
Most companies also have a policy governing levels of protected information and how it is shared .
There is a bit of 'heavy lifting ' as far as implementation and it would come down to how much risk is acceptable .
I have worked in both environments and hybrids in-between .
SmartCard logon as building ID is the smoothest and easiest for the user as well since a single PIN is needed with the SmartCard .
With most people familiar with Bank ATMs , this should be a no brain-er</tokentext>
<sentencetext>Most large (and some mid) companies employ a SmartCard of some kind for access to the building.
Adding a smart card with a chip then help authenticate getting into the building and (with certs on the chip/card) auth the user onto the network and provide for digital signatures and encryption.
Most companies also have a policy governing levels of protected information and how it is shared.
There is a bit of 'heavy lifting' as far as implementation and it would come down to how much risk is acceptable.
I have worked in both environments and hybrids in-between.
SmartCard logon as building ID is the smoothest and easiest for the user as well since a single PIN is needed with the SmartCard.
With most people familiar with Bank ATMs, this should be a no brain-er</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811224</id>
	<title>The reason is caching issues vs. browser rules...</title>
	<author>jamesivie</author>
	<datestamp>1263846300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Most browsers still have a warning that cannot be bypassed whenever unencrypted content is linked on an encrypted page.  The existence of this warning assumes that the end-users understand the basic HTML security model (laughable in the vast majority of cases) and that the server code is buggy and might allow secure data to be sent insecurely.  This prevents caching of items on encrypted pages that really should be cacheable (most css, most images, most flash, most javascript).  Using SSL despite the lack of caching reduces website performance and increases hosting costs (so that's not likely to happen except when the added security is worth the added cost and wait).  IMHO there should be some kind of explicit unsecure-data-within-a-secure-page protocol (httpu://? httpp://) that prevents the browser warning but allows unsecured css/images/javascript/flash/etc. within secure HTML.  This way, all those items could be cached at any point along the way (proxy servers, browser, etc.), and we could still provide warnings for buggy websites that unintentionally included content with <a href="http://./" title="." rel="nofollow">http://./</a> [.]  A one-time warning similar to the "switching to secure!" warnings could be included for security-paranoid users, and a different icon for pages with this type of content could be used.  Ideally, for those same paranoid users, there'd also be a way to quickly asses WHICH items on the page were insecure, like a button that turns on/off the display of either the secure or the insecure parts of the page.</p></htmltext>
<tokenext>Most browsers still have a warning that can not be bypassed whenever unencrypted content is linked on an encrypted page .
The existence of this warning assumes that the end-users understand the basic HTML security model ( laughable in the vast majority of cases ) and that the server code is buggy and might allow secure data to be sent insecurely .
This prevents caching of items on encrypted pages that really should be cacheable ( most css , most images , most flash , most javascript ) .
Using SSL despite the lack of caching reduces website performance and increases hosting costs ( so that 's not likely to happen except when the added security is worth the added cost and wait ) .
IMHO there should be some kind of explicit unsecure-data-within-a-secure-page protocol ( httpu : // ?
httpp : // ) that prevents the browser warning but allows unsecured css/images/javascript/flash/etc .
within secure HTML .
This way , all those items could be cached at any point along the way ( proxy servers , browser , etc .
) , and we could still provide warnings for buggy websites that unintentionally included content with http : //./ [ .
] A one-time warning similar to the " switching to secure !
" warnings could be included for security-paranoid users , and a different icon for pages with this type of content could be used .
Ideally , for those same paranoid users , there 'd also be a way to quickly asses WHICH items on the page were insecure , like a button that turns on/off the display of either the secure or the insecure parts of the page .</tokentext>
<sentencetext>Most browsers still have a warning that cannot be bypassed whenever unencrypted content is linked on an encrypted page.
The existence of this warning assumes that the end-users understand the basic HTML security model (laughable in the vast majority of cases) and that the server code is buggy and might allow secure data to be sent insecurely.
This prevents caching of items on encrypted pages that really should be cacheable (most css, most images, most flash, most javascript).
Using SSL despite the lack of caching reduces website performance and increases hosting costs (so that's not likely to happen except when the added security is worth the added cost and wait).
IMHO there should be some kind of explicit unsecure-data-within-a-secure-page protocol (httpu://?
httpp://) that prevents the browser warning but allows unsecured css/images/javascript/flash/etc.
within secure HTML.
This way, all those items could be cached at any point along the way (proxy servers, browser, etc.
), and we could still provide warnings for buggy websites that unintentionally included content with http://./ [.
]  A one-time warning similar to the "switching to secure!
" warnings could be included for security-paranoid users, and a different icon for pages with this type of content could be used.
Ideally, for those same paranoid users, there'd also be a way to quickly asses WHICH items on the page were insecure, like a button that turns on/off the display of either the secure or the insecure parts of the page.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764</id>
	<title>encryption alone</title>
	<author>bugs2squash</author>
	<datestamp>1263834960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>is not the whole solution.</htmltext>
<tokenext>is not the whole solution .</tokentext>
<sentencetext>is not the whole solution.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808844</id>
	<title>Apathy</title>
	<author>maino82</author>
	<datestamp>1263835320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I know at my company a lot of it is apathy. We have an unencrypted FTP site where clients can upload/download stuff at their leisure. It's not sensitive material, so no one really cares if something happens to it or if someone gets hold of what's up there. Probably not the best attitude, but if the higher ups don't concern themselves with it, I don't concern myself with it too much either.

That being said, for internal stuff and for access to project files from offsite, I did set up an SSH account on a segregated virtual machine that we can gain access to via SFTP. I also gave out separate keys for each individual in our organization. If a key becomes compromised I can simply issue a new one to the key holder without having to inconvenience everyone else. Still probably not ideal (I'm not a security expert by any stretch of the imagination), but better than nothing.</htmltext>
<tokenext>I know at my company a lot of it is apathy .
We have an unencrypted FTP site where clients can upload/download stuff at their leisure .
It 's not sensitive material , so no one really cares if something happens to it or if someone gets hold of what 's up there .
Probably not the best attitude , but if the higher ups do n't concern themselves with it , I do n't concern myself with it too much either .
That being said , for internal stuff and for access to project files from offsite , I did set up an SSH account on a segregated virtual machine that we can gain access to via SFTP .
I also gave out separate keys for each individual in our organization .
If a key becomes compromised I can simply issue a new one to the key holder without having to inconvenience everyone else .
Still probably not ideal ( I 'm not a security expert by any stretch of the imagination ) , but better than nothing .</tokentext>
<sentencetext>I know at my company a lot of it is apathy.
We have an unencrypted FTP site where clients can upload/download stuff at their leisure.
It's not sensitive material, so no one really cares if something happens to it or if someone gets hold of what's up there.
Probably not the best attitude, but if the higher ups don't concern themselves with it, I don't concern myself with it too much either.
That being said, for internal stuff and for access to project files from offsite, I did set up an SSH account on a segregated virtual machine that we can gain access to via SFTP.
I also gave out separate keys for each individual in our organization.
If a key becomes compromised I can simply issue a new one to the key holder without having to inconvenience everyone else.
Still probably not ideal (I'm not a security expert by any stretch of the imagination), but better than nothing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810876</id>
	<title>Re:I have encrypted this post</title>
	<author>Rainer</author>
	<datestamp>1263844500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Simple solution:<br> <br>

Use one time pad encryption.<br>
Hand out the key that produces the desired plaintext.</htmltext>
<tokenext>Simple solution : Use one time pad encryption .
Hand out the key that produces the desired plaintext .</tokentext>
<sentencetext>Simple solution: 

Use one time pad encryption.
Hand out the key that produces the desired plaintext.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811690</id>
	<title>Cost and Lack or Windows sFTP support</title>
	<author>HannethCom</author>
	<datestamp>1263848340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As odd as it may sound, there are many companies willing to pay tens of thousands of dollars a year on maintaining and making changes to their web site, but some of these don't want to pay $300 a year for a security certificate, even if they pay for an expensive security system to be written.<br>
<br>
As for secure FTP, some people don't want to download a separate FTP client, they just want to use what is built into Windows, and I don't think that supports sFTP. You also have to pay for a cert.</htmltext>
<tokenext>As odd as it may sound , there are many companies willing to pay tens of thousands of dollars a year on maintaining and making changes to their web site , but some of these do n't want to pay $ 300 a year for a security certificate , even if they pay for an expensive security system to be written .
As for secure FTP , some people do n't want to download a separate FTP client , they just want to use what is built into Windows , and I do n't think that supports sFTP .
You also have to pay for a cert .</tokentext>
<sentencetext>As odd as it may sound, there are many companies willing to pay tens of thousands of dollars a year on maintaining and making changes to their web site, but some of these don't want to pay $300 a year for a security certificate, even if they pay for an expensive security system to be written.
As for secure FTP, some people don't want to download a separate FTP client, they just want to use what is built into Windows, and I don't think that supports sFTP.
You also have to pay for a cert.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810186</id>
	<title>"Most websites" don't require HTTPS.</title>
	<author>mrspecialhead</author>
	<datestamp>1263841020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Most websites are still using unencrypted HTTP."<nobr> <wbr></nobr>...and should be unless security is specifically required as a priority.  Pick the right tool.</p></htmltext>
<tokenext>" Most websites are still using unencrypted HTTP .
" ...and should be unless security is specifically required as a priority .
Pick the right tool .</tokentext>
<sentencetext>"Most websites are still using unencrypted HTTP.
" ...and should be unless security is specifically required as a priority.
Pick the right tool.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809080</id>
	<title>Why?</title>
	<author>Anonymous</author>
	<datestamp>1263836280000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext>For most of the Web surfing that I do, full https encryption simply isn't needed. Why do I need encryption (which adds another quite significant protocol layer) to surf Slashdot or CNN or xkcd?<br>
<br>
OK, granted, I probably should use encryption or TOR for that last one or the 'raptors will catch on. But other than that... why?</htmltext>
<tokenext>For most of the Web surfing that I do , full https encryption simply is n't needed .
Why do I need encryption ( which adds another quite significant protocol layer ) to surf Slashdot or CNN or xkcd ?
OK , granted , I probably should use encryption or TOR for that last one or the 'raptors will catch on .
But other than that... why ?</tokentext>
<sentencetext>For most of the Web surfing that I do, full https encryption simply isn't needed.
Why do I need encryption (which adds another quite significant protocol layer) to surf Slashdot or CNN or xkcd?
OK, granted, I probably should use encryption or TOR for that last one or the 'raptors will catch on.
But other than that... why?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809472</id>
	<title>WAY too baroque and fragile</title>
	<author>david.emery</author>
	<datestamp>1263837960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>PKI might be theoretically secure, but it is to damn complex to set up and maintain in the face of issuing and then managing certs including expiration of same, email addresses that change causing a cascading exchange of certs, case mismatch between the sender's email address, e.g. "joe.blow@example.com" might not match a cert issued to "Joe.Blow@Example.com", etc.</p><p>Same thing's true for trying to set up https on websites.  But I'm disappointed at how many corporate high-confidence (e.g. bank) websites don't start off with https these days. They can make the purely server-side investment.  Unlike email and point-to-point connections, at least web server security is encapsulated on the server.</p><p>Another problem is that most of the time you just want a simple "did this message come from who you thought it did", but the cert authorities add to this confirmed identity.  That means you have to pay a company like Verisign a lot of money for an identity cert where they require you to show up with your passport, etc,.  Again, -overkill- for what most people need, mostly they want to make sure there's no interference with subsequent messages from the same sender.</p><p>The error messages in general are not helpful, in part due to bad human factors engineering and in part due to policies that want to prevent covert channels (akin to the lack of distinction between 'file doesn't exist' and 'file exists, but you don't have access')</p><p>It took me several years to get reliable PKI certs working for encrypted email on Thunderbird, but all that broke when I moved my mail over to Apple Mail.app.  I'll probably have to move back to Thunderbird (even though there are things about T-bird that I actively despise.)  Part of that complexity is exchanging individual certificates with others, and part of that is trying to connect to external corporate LDAP servers to get certificates for new correspondents.  (Seems that most mailers assume a single internal LDAP server, and don't provide support for connecting to ldap.xyz.com for XYZ employee certs, ldap.abc.com for ABC employee certs, etc.)</p><p>And then there's Smart Cards/Common Access Cards, which work OK if someone who knows what they're doing configures a Windows machine, installing third party software, etc, etc.  A security measure that only works on Windows is questionable (and that's before the well-documented problems with Windows vulnerabilities, allowing people to get 'inside the firewall'.  Just ask Google, Adobe, etc...)</p><p>As someone who's been using personal computers for over 30 years, if -I- don't have patience with this, it's certainly not ready for mom-and-pop.</p></htmltext>
<tokenext>PKI might be theoretically secure , but it is to damn complex to set up and maintain in the face of issuing and then managing certs including expiration of same , email addresses that change causing a cascading exchange of certs , case mismatch between the sender 's email address , e.g .
" joe.blow @ example.com " might not match a cert issued to " Joe.Blow @ Example.com " , etc.Same thing 's true for trying to set up https on websites .
But I 'm disappointed at how many corporate high-confidence ( e.g .
bank ) websites do n't start off with https these days .
They can make the purely server-side investment .
Unlike email and point-to-point connections , at least web server security is encapsulated on the server.Another problem is that most of the time you just want a simple " did this message come from who you thought it did " , but the cert authorities add to this confirmed identity .
That means you have to pay a company like Verisign a lot of money for an identity cert where they require you to show up with your passport , etc, .
Again , -overkill- for what most people need , mostly they want to make sure there 's no interference with subsequent messages from the same sender.The error messages in general are not helpful , in part due to bad human factors engineering and in part due to policies that want to prevent covert channels ( akin to the lack of distinction between 'file does n't exist ' and 'file exists , but you do n't have access ' ) It took me several years to get reliable PKI certs working for encrypted email on Thunderbird , but all that broke when I moved my mail over to Apple Mail.app .
I 'll probably have to move back to Thunderbird ( even though there are things about T-bird that I actively despise .
) Part of that complexity is exchanging individual certificates with others , and part of that is trying to connect to external corporate LDAP servers to get certificates for new correspondents .
( Seems that most mailers assume a single internal LDAP server , and do n't provide support for connecting to ldap.xyz.com for XYZ employee certs , ldap.abc.com for ABC employee certs , etc .
) And then there 's Smart Cards/Common Access Cards , which work OK if someone who knows what they 're doing configures a Windows machine , installing third party software , etc , etc .
A security measure that only works on Windows is questionable ( and that 's before the well-documented problems with Windows vulnerabilities , allowing people to get 'inside the firewall' .
Just ask Google , Adobe , etc... ) As someone who 's been using personal computers for over 30 years , if -I- do n't have patience with this , it 's certainly not ready for mom-and-pop .</tokentext>
<sentencetext>PKI might be theoretically secure, but it is to damn complex to set up and maintain in the face of issuing and then managing certs including expiration of same, email addresses that change causing a cascading exchange of certs, case mismatch between the sender's email address, e.g.
"joe.blow@example.com" might not match a cert issued to "Joe.Blow@Example.com", etc.Same thing's true for trying to set up https on websites.
But I'm disappointed at how many corporate high-confidence (e.g.
bank) websites don't start off with https these days.
They can make the purely server-side investment.
Unlike email and point-to-point connections, at least web server security is encapsulated on the server.Another problem is that most of the time you just want a simple "did this message come from who you thought it did", but the cert authorities add to this confirmed identity.
That means you have to pay a company like Verisign a lot of money for an identity cert where they require you to show up with your passport, etc,.
Again, -overkill- for what most people need, mostly they want to make sure there's no interference with subsequent messages from the same sender.The error messages in general are not helpful, in part due to bad human factors engineering and in part due to policies that want to prevent covert channels (akin to the lack of distinction between 'file doesn't exist' and 'file exists, but you don't have access')It took me several years to get reliable PKI certs working for encrypted email on Thunderbird, but all that broke when I moved my mail over to Apple Mail.app.
I'll probably have to move back to Thunderbird (even though there are things about T-bird that I actively despise.
)  Part of that complexity is exchanging individual certificates with others, and part of that is trying to connect to external corporate LDAP servers to get certificates for new correspondents.
(Seems that most mailers assume a single internal LDAP server, and don't provide support for connecting to ldap.xyz.com for XYZ employee certs, ldap.abc.com for ABC employee certs, etc.
)And then there's Smart Cards/Common Access Cards, which work OK if someone who knows what they're doing configures a Windows machine, installing third party software, etc, etc.
A security measure that only works on Windows is questionable (and that's before the well-documented problems with Windows vulnerabilities, allowing people to get 'inside the firewall'.
Just ask Google, Adobe, etc...)As someone who's been using personal computers for over 30 years, if -I- don't have patience with this, it's certainly not ready for mom-and-pop.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809390</id>
	<title>ignorance and stupidity</title>
	<author>theyulman</author>
	<datestamp>1263837600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In many cases, the very reason that encryption was not part of a corporate security policy is...well ignorance and/or stupidity on the management part.
<br>
<br>
They would rather rely on security by obscurity.</htmltext>
<tokenext>In many cases , the very reason that encryption was not part of a corporate security policy is...well ignorance and/or stupidity on the management part .
They would rather rely on security by obscurity .</tokentext>
<sentencetext>In many cases, the very reason that encryption was not part of a corporate security policy is...well ignorance and/or stupidity on the management part.
They would rather rely on security by obscurity.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813804</id>
	<title>Re:More direct costs.</title>
	<author>shmlco</author>
	<datestamp>1263815340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"It also costs a nonzero amount in server CPU usage and/or dedicated hardware to do the crypto itself...."</p><p>I think the rule of thumb was that a server could handle ten HTTP requests for every HTTPS request. Therefore a popular web site (like Slashdot) might find its infrastructure costs increased significantly, with little added benefit. Could add dedicated SSL-enabled network cards, but those are fairly expensive too.</p></htmltext>
<tokenext>" It also costs a nonzero amount in server CPU usage and/or dedicated hardware to do the crypto itself.... " I think the rule of thumb was that a server could handle ten HTTP requests for every HTTPS request .
Therefore a popular web site ( like Slashdot ) might find its infrastructure costs increased significantly , with little added benefit .
Could add dedicated SSL-enabled network cards , but those are fairly expensive too .</tokentext>
<sentencetext>"It also costs a nonzero amount in server CPU usage and/or dedicated hardware to do the crypto itself...."I think the rule of thumb was that a server could handle ten HTTP requests for every HTTPS request.
Therefore a popular web site (like Slashdot) might find its infrastructure costs increased significantly, with little added benefit.
Could add dedicated SSL-enabled network cards, but those are fairly expensive too.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809190</id>
	<title>Re:I'll tell you what it is...</title>
	<author>Anonymous</author>
	<datestamp>1263836700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>...encrypted communications are too bloody hard to debug!</p><p>With unencrypted protocols, I can whip out the packet sniffer and find out *exactly* what's going on. With encrypted protocols, I have to write reports like "we have verified our software configuration and believe it to be correct; perhaps the problem is at your end?"</p><p>Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode.  Maybe even with a "relax the crypto" configuration flag we can throw during debug.</p></div><p>. . . wireshark</p></div>
	</htmltext>
<tokenext>...encrypted communications are too bloody hard to debug ! With unencrypted protocols , I can whip out the packet sniffer and find out * exactly * what 's going on .
With encrypted protocols , I have to write reports like " we have verified our software configuration and believe it to be correct ; perhaps the problem is at your end ?
" Maybe we need to come up with a standard way of encrypting things , that our packet sniffers somehow know how to decode .
Maybe even with a " relax the crypto " configuration flag we can throw during debug.. . .
wireshark</tokentext>
<sentencetext>...encrypted communications are too bloody hard to debug!With unencrypted protocols, I can whip out the packet sniffer and find out *exactly* what's going on.
With encrypted protocols, I have to write reports like "we have verified our software configuration and believe it to be correct; perhaps the problem is at your end?
"Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode.
Maybe even with a "relax the crypto" configuration flag we can throw during debug.. . .
wireshark
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811758</id>
	<title>Not needed</title>
	<author>Anonymous</author>
	<datestamp>1263805500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The reason that most traffic is not encrypted is simply that encryption is unnecessary for most traffic. Does slashdot need to be encrypted? Arguably, there are some things out there that should be encrypted and aren't, but the basic answer to your question is that most traffic isn't very sensitive.</p></htmltext>
<tokenext>The reason that most traffic is not encrypted is simply that encryption is unnecessary for most traffic .
Does slashdot need to be encrypted ?
Arguably , there are some things out there that should be encrypted and are n't , but the basic answer to your question is that most traffic is n't very sensitive .</tokentext>
<sentencetext>The reason that most traffic is not encrypted is simply that encryption is unnecessary for most traffic.
Does slashdot need to be encrypted?
Arguably, there are some things out there that should be encrypted and aren't, but the basic answer to your question is that most traffic isn't very sensitive.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</id>
	<title>People don't see the value</title>
	<author>Anonymous</author>
	<datestamp>1263837780000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>It costs a nonzero amount to get a certificate at all, and a self-signed certificate is barely better than raw http.</p></div></blockquote><p>To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.</p><p>There won't be a push for improving the cert system (e.g. by moving to an OpenPGP WoT or something) until more people are encrypting,  And people won't be encrypting until they get over their foolish attitude that it's pointless to force attackers to use MitM instead of passive snooping.</p><p>When more people start to realize that it's a good idea to force their opponents into doing expensive and risky things, then they will choose to do that and start to use (poorly-authenticated) key exchange.  Once encryption with poorly-authenticated key exchange becomes more common, people will start to see a benefit to improving their authentication, so they'll attend more key-signing parties, or exert market forces within crippled single-signer systems to have cheaper CAs, or whatever.</p></div>
	</htmltext>
<tokenext>It costs a nonzero amount to get a certificate at all , and a self-signed certificate is barely better than raw http.To answer the original question , the thing holding back encryption is the above mistaken attitude , that using a self-signed cert is barely better than using plaintext.There wo n't be a push for improving the cert system ( e.g .
by moving to an OpenPGP WoT or something ) until more people are encrypting , And people wo n't be encrypting until they get over their foolish attitude that it 's pointless to force attackers to use MitM instead of passive snooping.When more people start to realize that it 's a good idea to force their opponents into doing expensive and risky things , then they will choose to do that and start to use ( poorly-authenticated ) key exchange .
Once encryption with poorly-authenticated key exchange becomes more common , people will start to see a benefit to improving their authentication , so they 'll attend more key-signing parties , or exert market forces within crippled single-signer systems to have cheaper CAs , or whatever .</tokentext>
<sentencetext>It costs a nonzero amount to get a certificate at all, and a self-signed certificate is barely better than raw http.To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.There won't be a push for improving the cert system (e.g.
by moving to an OpenPGP WoT or something) until more people are encrypting,  And people won't be encrypting until they get over their foolish attitude that it's pointless to force attackers to use MitM instead of passive snooping.When more people start to realize that it's a good idea to force their opponents into doing expensive and risky things, then they will choose to do that and start to use (poorly-authenticated) key exchange.
Once encryption with poorly-authenticated key exchange becomes more common, people will start to see a benefit to improving their authentication, so they'll attend more key-signing parties, or exert market forces within crippled single-signer systems to have cheaper CAs, or whatever.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809158</id>
	<title>well, duh</title>
	<author>zogger</author>
	<datestamp>1263836580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://en.wikipedia.org/wiki/Stonecutters" title="wikipedia.org" rel="nofollow">The answer got leaked a long time ago</a> [wikipedia.org]</p></htmltext>
<tokenext>The answer got leaked a long time ago [ wikipedia.org ]</tokentext>
<sentencetext>The answer got leaked a long time ago [wikipedia.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817342</id>
	<title>Encryption is either pointless or forbidden</title>
	<author>BugHappy</author>
	<datestamp>1263896520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><b>
There are two kinds of encryption:
<br> <br>
- The one that stops your little sister (SSL used to admin firewalls, to fuel VPNs, or RC4 used in Remote-Desktop, etc.)
<br>
- The one that puts your company into big trouble because governments will crunch your company if it does not "comply".
<br> <br>
This may help to understand why encryption is not widely used: <i>it is either pointless or forbidden</i>.
</b></htmltext>
<tokenext>There are two kinds of encryption : - The one that stops your little sister ( SSL used to admin firewalls , to fuel VPNs , or RC4 used in Remote-Desktop , etc .
) - The one that puts your company into big trouble because governments will crunch your company if it does not " comply " .
This may help to understand why encryption is not widely used : it is either pointless or forbidden .</tokentext>
<sentencetext>
There are two kinds of encryption:
 
- The one that stops your little sister (SSL used to admin firewalls, to fuel VPNs, or RC4 used in Remote-Desktop, etc.
)

- The one that puts your company into big trouble because governments will crunch your company if it does not "comply".
This may help to understand why encryption is not widely used: it is either pointless or forbidden.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812972</id>
	<title>Re:Costs?</title>
	<author>Anonymous</author>
	<datestamp>1263811140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>(Oh, and bass-ackward companies like Apple are also holding back encryption. The iPhone can't do Secure Email after all this time? Really, Apple? Really?)</p></div><p>iPhone mail client supports secure email at least imap and pop with ssl/tls is working never checked smtp</p></div>
	</htmltext>
<tokenext>( Oh , and bass-ackward companies like Apple are also holding back encryption .
The iPhone ca n't do Secure Email after all this time ?
Really , Apple ?
Really ? ) iPhone mail client supports secure email at least imap and pop with ssl/tls is working never checked smtp</tokentext>
<sentencetext>(Oh, and bass-ackward companies like Apple are also holding back encryption.
The iPhone can't do Secure Email after all this time?
Really, Apple?
Really?)iPhone mail client supports secure email at least imap and pop with ssl/tls is working never checked smtp
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811514</id>
	<title>A closely related issue</title>
	<author>Aram Fingal</author>
	<datestamp>1263847500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The use of digital signatures in email is closely related to encryption because it requires the same PKI.  That may end up being the driving force because of the increasing sophistication of phishing.  The institution I work for is now frequently attacked with phishing emails.  Our help desk is constantly answering questions about whether a particular email is phishing or not.  What's even worse is the people who don't call (and don't know how to smell a phish).  We are dealing with hundreds of compromised accounts per year because of phishing.  I think this is not only a compelling reason to start authenticating email with digital signatures but also to integrate the recognition of digital signatures into our spam filtering.</p></htmltext>
<tokenext>The use of digital signatures in email is closely related to encryption because it requires the same PKI .
That may end up being the driving force because of the increasing sophistication of phishing .
The institution I work for is now frequently attacked with phishing emails .
Our help desk is constantly answering questions about whether a particular email is phishing or not .
What 's even worse is the people who do n't call ( and do n't know how to smell a phish ) .
We are dealing with hundreds of compromised accounts per year because of phishing .
I think this is not only a compelling reason to start authenticating email with digital signatures but also to integrate the recognition of digital signatures into our spam filtering .</tokentext>
<sentencetext>The use of digital signatures in email is closely related to encryption because it requires the same PKI.
That may end up being the driving force because of the increasing sophistication of phishing.
The institution I work for is now frequently attacked with phishing emails.
Our help desk is constantly answering questions about whether a particular email is phishing or not.
What's even worse is the people who don't call (and don't know how to smell a phish).
We are dealing with hundreds of compromised accounts per year because of phishing.
I think this is not only a compelling reason to start authenticating email with digital signatures but also to integrate the recognition of digital signatures into our spam filtering.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812654</id>
	<title>cryptography laws</title>
	<author>astar</author>
	<datestamp>1263809700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>openbsd is rather secure, at least until you put applications on it.  part of this is cryptography as a os service.  so in the us, the os is a export restricted munition and so the openbsd people do not allow us citizens to work on the os.  I speculate that this  has a negative effect on development of the os.  since associated projects like openssl are widely used, one might think there are negative impacts on the use of cryptography in the us.</p></htmltext>
<tokenext>openbsd is rather secure , at least until you put applications on it .
part of this is cryptography as a os service .
so in the us , the os is a export restricted munition and so the openbsd people do not allow us citizens to work on the os .
I speculate that this has a negative effect on development of the os .
since associated projects like openssl are widely used , one might think there are negative impacts on the use of cryptography in the us .</tokentext>
<sentencetext>openbsd is rather secure, at least until you put applications on it.
part of this is cryptography as a os service.
so in the us, the os is a export restricted munition and so the openbsd people do not allow us citizens to work on the os.
I speculate that this  has a negative effect on development of the os.
since associated projects like openssl are widely used, one might think there are negative impacts on the use of cryptography in the us.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814344</id>
	<title>The Feds are holding back encryption :(</title>
	<author>Anonymous</author>
	<datestamp>1263818580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Link to relevant information....</p><p>http://www.bis.doc.gov/encryption/default.htm</p><p>It's a shame that a mathematical transformation of information is considered a weapon (of mass destruction).<nobr> <wbr></nobr>:(</p><p>Slashdot CAPTCHA: skulls</p><p>(how apt)<nobr> <wbr></nobr>:P</p></htmltext>
<tokenext>Link to relevant information....http : //www.bis.doc.gov/encryption/default.htmIt 's a shame that a mathematical transformation of information is considered a weapon ( of mass destruction ) .
: ( Slashdot CAPTCHA : skulls ( how apt ) : P</tokentext>
<sentencetext>Link to relevant information....http://www.bis.doc.gov/encryption/default.htmIt's a shame that a mathematical transformation of information is considered a weapon (of mass destruction).
:(Slashdot CAPTCHA: skulls(how apt) :P</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808826</id>
	<title>Not needed</title>
	<author>DerPflanz</author>
	<datestamp>1263835260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think it is simply not needed. Why would you put effort in encrypting a public website, or your e-mails to your grandmother to feed your cat while you're away.</p><p>Risk = damage x probability. Probability (sniffing email/web traffic) is extremely low on most data, as is damage. I think logins should be encrypted, but not (public) data.</p></htmltext>
<tokenext>I think it is simply not needed .
Why would you put effort in encrypting a public website , or your e-mails to your grandmother to feed your cat while you 're away.Risk = damage x probability .
Probability ( sniffing email/web traffic ) is extremely low on most data , as is damage .
I think logins should be encrypted , but not ( public ) data .</tokentext>
<sentencetext>I think it is simply not needed.
Why would you put effort in encrypting a public website, or your e-mails to your grandmother to feed your cat while you're away.Risk = damage x probability.
Probability (sniffing email/web traffic) is extremely low on most data, as is damage.
I think logins should be encrypted, but not (public) data.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809548</id>
	<title>No single reason</title>
	<author>Anonymous</author>
	<datestamp>1263838260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>An interesting take is the paper titled "why johnny can't encrypt" (no link, only a google away). That clearly shows lack of user education. And that in turn shows a plethora of problems. Such as there are:</p><p>People have no idea why it is needed. And then it gets worse. We haven't figured out how to make it as easy as sticking a key in the outside kitchen door. We haven't figured out how to show that something is trustable. For that matter, we haven't properly defined "trust". Currently it comes in two basic flavours. One requires you to specifically assign two values unclear and mutually confusing values to each and every key (how's that for transparency?) and any GUIs around it simply echo the already confusing messages from the underlying layers. That is, they don't FIX anything (nor should they), they just put a pretty face on the confusion (but that doesn't help). Two requires either declaring you trust yourself and getting everybody else to trust you declaring that, which causes most applications to ungracefully barf unless and until you kick them into submission again, or, and that is really a triumph of capitalism, you can pay someone else to declare trust and charge you through the nose for it. That gets even better when *cough* certain vendors *cough* effectively disallow you to not-trust some of those parties by adding them right back to the store of trusted parties after you've expliticly removed them, without telling you. Lovely icing, this cake has. The bottom line here is that these commercial parties only protect you from evildoers they aren't willing to take money from.</p><p>So, moving forward, go read the GNU privacy handbook, and if you are terminally bored, go read up on PKI, x509, the OpenPGP specs, but minimally do include Peter Gutmann's "Everything you never wanted to know about PKI but were forced to find out" on your reading list. Try and understand what both systems are really about.</p><p>Then it gets fun: Play a little game of what if? and ask yourself what you would do if you would get a signed email from your mom and it doesn't check out. Now ask yourself, how do you explain to your mom, supposing you got her to use crypto in email, what she should do if she gets a signed email from you and it doesn't check out. Do you have a clear and concise answer to this?</p><p>Compare with what you would do if you go to a website and your browser starts to complain about the certificates used. What do you do? How do you get the information you need regardless, and in such a way that you can trust that information? Could you trust it in the first place, given that it came in over an encrypted link? What does the certificate chain do to the trust you assign to the information received?</p><p>And so on, and so forth. Does the very act of casual encryption as currently done still make sense to you? Does paying a party you have never met for a certificate make sense for anything but shutting up the browser?</p><p>I for me think that we need a single system that can do both hierarchical and web-of-trust type key/cert trusting, and we need to re-think what this trust thing means, and what to do when trust fails. We certainly have not figured out the SOP of what to do with many of the innumerable ways crypto can go wrong. And until we do, using crypto remains specialist work.</p></htmltext>
<tokenext>An interesting take is the paper titled " why johnny ca n't encrypt " ( no link , only a google away ) .
That clearly shows lack of user education .
And that in turn shows a plethora of problems .
Such as there are : People have no idea why it is needed .
And then it gets worse .
We have n't figured out how to make it as easy as sticking a key in the outside kitchen door .
We have n't figured out how to show that something is trustable .
For that matter , we have n't properly defined " trust " .
Currently it comes in two basic flavours .
One requires you to specifically assign two values unclear and mutually confusing values to each and every key ( how 's that for transparency ?
) and any GUIs around it simply echo the already confusing messages from the underlying layers .
That is , they do n't FIX anything ( nor should they ) , they just put a pretty face on the confusion ( but that does n't help ) .
Two requires either declaring you trust yourself and getting everybody else to trust you declaring that , which causes most applications to ungracefully barf unless and until you kick them into submission again , or , and that is really a triumph of capitalism , you can pay someone else to declare trust and charge you through the nose for it .
That gets even better when * cough * certain vendors * cough * effectively disallow you to not-trust some of those parties by adding them right back to the store of trusted parties after you 've expliticly removed them , without telling you .
Lovely icing , this cake has .
The bottom line here is that these commercial parties only protect you from evildoers they are n't willing to take money from.So , moving forward , go read the GNU privacy handbook , and if you are terminally bored , go read up on PKI , x509 , the OpenPGP specs , but minimally do include Peter Gutmann 's " Everything you never wanted to know about PKI but were forced to find out " on your reading list .
Try and understand what both systems are really about.Then it gets fun : Play a little game of what if ?
and ask yourself what you would do if you would get a signed email from your mom and it does n't check out .
Now ask yourself , how do you explain to your mom , supposing you got her to use crypto in email , what she should do if she gets a signed email from you and it does n't check out .
Do you have a clear and concise answer to this ? Compare with what you would do if you go to a website and your browser starts to complain about the certificates used .
What do you do ?
How do you get the information you need regardless , and in such a way that you can trust that information ?
Could you trust it in the first place , given that it came in over an encrypted link ?
What does the certificate chain do to the trust you assign to the information received ? And so on , and so forth .
Does the very act of casual encryption as currently done still make sense to you ?
Does paying a party you have never met for a certificate make sense for anything but shutting up the browser ? I for me think that we need a single system that can do both hierarchical and web-of-trust type key/cert trusting , and we need to re-think what this trust thing means , and what to do when trust fails .
We certainly have not figured out the SOP of what to do with many of the innumerable ways crypto can go wrong .
And until we do , using crypto remains specialist work .</tokentext>
<sentencetext>An interesting take is the paper titled "why johnny can't encrypt" (no link, only a google away).
That clearly shows lack of user education.
And that in turn shows a plethora of problems.
Such as there are:People have no idea why it is needed.
And then it gets worse.
We haven't figured out how to make it as easy as sticking a key in the outside kitchen door.
We haven't figured out how to show that something is trustable.
For that matter, we haven't properly defined "trust".
Currently it comes in two basic flavours.
One requires you to specifically assign two values unclear and mutually confusing values to each and every key (how's that for transparency?
) and any GUIs around it simply echo the already confusing messages from the underlying layers.
That is, they don't FIX anything (nor should they), they just put a pretty face on the confusion (but that doesn't help).
Two requires either declaring you trust yourself and getting everybody else to trust you declaring that, which causes most applications to ungracefully barf unless and until you kick them into submission again, or, and that is really a triumph of capitalism, you can pay someone else to declare trust and charge you through the nose for it.
That gets even better when *cough* certain vendors *cough* effectively disallow you to not-trust some of those parties by adding them right back to the store of trusted parties after you've expliticly removed them, without telling you.
Lovely icing, this cake has.
The bottom line here is that these commercial parties only protect you from evildoers they aren't willing to take money from.So, moving forward, go read the GNU privacy handbook, and if you are terminally bored, go read up on PKI, x509, the OpenPGP specs, but minimally do include Peter Gutmann's "Everything you never wanted to know about PKI but were forced to find out" on your reading list.
Try and understand what both systems are really about.Then it gets fun: Play a little game of what if?
and ask yourself what you would do if you would get a signed email from your mom and it doesn't check out.
Now ask yourself, how do you explain to your mom, supposing you got her to use crypto in email, what she should do if she gets a signed email from you and it doesn't check out.
Do you have a clear and concise answer to this?Compare with what you would do if you go to a website and your browser starts to complain about the certificates used.
What do you do?
How do you get the information you need regardless, and in such a way that you can trust that information?
Could you trust it in the first place, given that it came in over an encrypted link?
What does the certificate chain do to the trust you assign to the information received?And so on, and so forth.
Does the very act of casual encryption as currently done still make sense to you?
Does paying a party you have never met for a certificate make sense for anything but shutting up the browser?I for me think that we need a single system that can do both hierarchical and web-of-trust type key/cert trusting, and we need to re-think what this trust thing means, and what to do when trust fails.
We certainly have not figured out the SOP of what to do with many of the innumerable ways crypto can go wrong.
And until we do, using crypto remains specialist work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812</id>
	<title>Because it's a PITA - Pain In the Ass!</title>
	<author>tomhudson</author>
	<datestamp>1263835200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><ol>
<li>
It's a pain in the ass to set up - do YOU want to have to configure everyone's email, etc. to use it?  I didn't think so.</li>
<li>
It's not needed.  If I'm sending somethig sensitive, I can just encrypt it and send it as an attachment, and give them the password over the phone.</li>
<li>
You're already leaking your sh*t all over the net - and if you use google docs, you're letting an advertising company look at all your information.</li>
</ol></htmltext>
<tokenext>It 's a pain in the ass to set up - do YOU want to have to configure everyone 's email , etc .
to use it ?
I did n't think so .
It 's not needed .
If I 'm sending somethig sensitive , I can just encrypt it and send it as an attachment , and give them the password over the phone .
You 're already leaking your sh * t all over the net - and if you use google docs , you 're letting an advertising company look at all your information .</tokentext>
<sentencetext>

It's a pain in the ass to set up - do YOU want to have to configure everyone's email, etc.
to use it?
I didn't think so.
It's not needed.
If I'm sending somethig sensitive, I can just encrypt it and send it as an attachment, and give them the password over the phone.
You're already leaking your sh*t all over the net - and if you use google docs, you're letting an advertising company look at all your information.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812564</id>
	<title>LACK OF UNDERSTANDING ASTOUNDING!</title>
	<author>gbutler69</author>
	<datestamp>1263809280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'd be pro if</p><p>1. i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etc</p></div><p>There is nothing for Verisign to pass on. They only have your public key. You keep your private key private. Look into how Public Key Cryptography works before you worry about non-existent problems</p><p><div class="quote"><p>2. i could create keys without firefox complaining like two year old about them</p></div><p>Again, your lack of understanding is astounding. Firefox complains because it has no way of verifying that your generated Public Key is actuall from who is says it is (You). Firefox must be able to get a copy of your public key from a "Trusted" source in order to verify your key. There are 3 possibilities: 1) Register your Public Key with a "Trusted" Key Service (i.e. Verisign), 2) Register your own key signing authority with a "Trusted" service (i.e. Verisign) and then register your public key (Cert) with your own key registrar, 3) Install a copy of your public key (cert) into the pre-trusted keys in Firefox (provide an installer for your end users).</p></div>
	</htmltext>
<tokenext>I 'd be pro if1 .
i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etcThere is nothing for Verisign to pass on .
They only have your public key .
You keep your private key private .
Look into how Public Key Cryptography works before you worry about non-existent problems2 .
i could create keys without firefox complaining like two year old about themAgain , your lack of understanding is astounding .
Firefox complains because it has no way of verifying that your generated Public Key is actuall from who is says it is ( You ) .
Firefox must be able to get a copy of your public key from a " Trusted " source in order to verify your key .
There are 3 possibilities : 1 ) Register your Public Key with a " Trusted " Key Service ( i.e .
Verisign ) , 2 ) Register your own key signing authority with a " Trusted " service ( i.e .
Verisign ) and then register your public key ( Cert ) with your own key registrar , 3 ) Install a copy of your public key ( cert ) into the pre-trusted keys in Firefox ( provide an installer for your end users ) .</tokentext>
<sentencetext>I'd be pro if1.
i had control over who got my key data rather than assuming its gets passed on by default to echelon by versign etcThere is nothing for Verisign to pass on.
They only have your public key.
You keep your private key private.
Look into how Public Key Cryptography works before you worry about non-existent problems2.
i could create keys without firefox complaining like two year old about themAgain, your lack of understanding is astounding.
Firefox complains because it has no way of verifying that your generated Public Key is actuall from who is says it is (You).
Firefox must be able to get a copy of your public key from a "Trusted" source in order to verify your key.
There are 3 possibilities: 1) Register your Public Key with a "Trusted" Key Service (i.e.
Verisign), 2) Register your own key signing authority with a "Trusted" service (i.e.
Verisign) and then register your public key (Cert) with your own key registrar, 3) Install a copy of your public key (cert) into the pre-trusted keys in Firefox (provide an installer for your end users).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809522</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814172</id>
	<title>Re:I can only answer for myself</title>
	<author>Anonymous</author>
	<datestamp>1263817440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>i use encryption because<br>1.  i do have things of value to encrypt (passwords to e commerce sites,<br>for starters).<br>2.  i use plan 9's factotum.  it does encryption right.  my password list is<br>encrypted and managed by the system.<br>3.  there's one password to remember.  no fear of losing it.<br>4.  ? really.  tin foil hat thinking.<br>5.  ah, there's your problem.</p></htmltext>
<tokenext>i use encryption because1 .
i do have things of value to encrypt ( passwords to e commerce sites,for starters ) .2. i use plan 9 's factotum .
it does encryption right .
my password list isencrypted and managed by the system.3 .
there 's one password to remember .
no fear of losing it.4 .
? really .
tin foil hat thinking.5 .
ah , there 's your problem .</tokentext>
<sentencetext>i use encryption because1.
i do have things of value to encrypt (passwords to e commerce sites,for starters).2.  i use plan 9's factotum.
it does encryption right.
my password list isencrypted and managed by the system.3.
there's one password to remember.
no fear of losing it.4.
? really.
tin foil hat thinking.5.
ah, there's your problem.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809542</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811764</id>
	<title>One major problem is spam.</title>
	<author>Anonymous</author>
	<datestamp>1263805500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>How is a mailbox provider going to analyze all those potential spam mails when everything is encrypted?</p></htmltext>
<tokenext>How is a mailbox provider going to analyze all those potential spam mails when everything is encrypted ?</tokentext>
<sentencetext>How is a mailbox provider going to analyze all those potential spam mails when everything is encrypted?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810212</id>
	<title>Re:Ethan Hunt</title>
	<author>Sloppy</author>
	<datestamp>1263841200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>If no one is breaking in, why would you want to slow everything down.</p></div> </blockquote><p>The problem with unencrypted communications, is that you never <em>know</em> if someone is breaking in.  You can't wait until there's a detected incident, because in the unlikely event that you ever discover someone has been listening, that was the 1000th time that someone listened.  By the time someone exploits their intel on you, many parties may already have a shitload of intel on you.</p><p>The other problem is that the question of what needs securing vs what doesn't need securing, does not usually cleanly break down along <em>application</em> lines.  Your ftp server might always be not-sensitive stuff, but what about web and email?</p><p>An email to your friend that says "Iron Maiden rulez! Up the irons!" isn't sensitive, but "We're going to the Iron Maiden show on Saturday so I hope nobody reads this and takes advantage of knowing when we won't be home, because that would be the perfect time to burgle us" is.  But if you're going to encrypt the second message, then your email client needs to be encrypting things.  And you probably want it to be trying to do that whenever it can, <strong>without the user having to think</strong>  about which which messages are sensitive and which aren't.  If they have to think, they will get it wrong, because it turns out the <em>first</em> message is sensitive too, since it lets an attacker profile who <em>might</em> have undefended homes on the night that Iron Maiden is in town.</p><blockquote><div><p>You wouldn't want real security at your front door, because you'd be trapped outside more often than an actual burgler.</p></div></blockquote><p>I think that's a bad analogy, though.  If you remember your passphrase, stuff just works.  When the day comes that someone tries to decrypt and turns out to not have the key, that person (unlike a person trying to enter a house without a key) probably really isn't you.</p></div>
	</htmltext>
<tokenext>If no one is breaking in , why would you want to slow everything down .
The problem with unencrypted communications , is that you never know if someone is breaking in .
You ca n't wait until there 's a detected incident , because in the unlikely event that you ever discover someone has been listening , that was the 1000th time that someone listened .
By the time someone exploits their intel on you , many parties may already have a shitload of intel on you.The other problem is that the question of what needs securing vs what does n't need securing , does not usually cleanly break down along application lines .
Your ftp server might always be not-sensitive stuff , but what about web and email ? An email to your friend that says " Iron Maiden rulez !
Up the irons !
" is n't sensitive , but " We 're going to the Iron Maiden show on Saturday so I hope nobody reads this and takes advantage of knowing when we wo n't be home , because that would be the perfect time to burgle us " is .
But if you 're going to encrypt the second message , then your email client needs to be encrypting things .
And you probably want it to be trying to do that whenever it can , without the user having to think about which which messages are sensitive and which are n't .
If they have to think , they will get it wrong , because it turns out the first message is sensitive too , since it lets an attacker profile who might have undefended homes on the night that Iron Maiden is in town.You would n't want real security at your front door , because you 'd be trapped outside more often than an actual burgler.I think that 's a bad analogy , though .
If you remember your passphrase , stuff just works .
When the day comes that someone tries to decrypt and turns out to not have the key , that person ( unlike a person trying to enter a house without a key ) probably really is n't you .</tokentext>
<sentencetext>If no one is breaking in, why would you want to slow everything down.
The problem with unencrypted communications, is that you never know if someone is breaking in.
You can't wait until there's a detected incident, because in the unlikely event that you ever discover someone has been listening, that was the 1000th time that someone listened.
By the time someone exploits their intel on you, many parties may already have a shitload of intel on you.The other problem is that the question of what needs securing vs what doesn't need securing, does not usually cleanly break down along application lines.
Your ftp server might always be not-sensitive stuff, but what about web and email?An email to your friend that says "Iron Maiden rulez!
Up the irons!
" isn't sensitive, but "We're going to the Iron Maiden show on Saturday so I hope nobody reads this and takes advantage of knowing when we won't be home, because that would be the perfect time to burgle us" is.
But if you're going to encrypt the second message, then your email client needs to be encrypting things.
And you probably want it to be trying to do that whenever it can, without the user having to think  about which which messages are sensitive and which aren't.
If they have to think, they will get it wrong, because it turns out the first message is sensitive too, since it lets an attacker profile who might have undefended homes on the night that Iron Maiden is in town.You wouldn't want real security at your front door, because you'd be trapped outside more often than an actual burgler.I think that's a bad analogy, though.
If you remember your passphrase, stuff just works.
When the day comes that someone tries to decrypt and turns out to not have the key, that person (unlike a person trying to enter a house without a key) probably really isn't you.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809014</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811340</id>
	<title>Re:I'll tell you what it is...</title>
	<author>GWBasic</author>
	<datestamp>1263846720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode. Maybe even with a "relax the crypto" configuration flag we can throw during debug</p></div><p>It's called SSL, and you can bolt it on to any TCP-based application by setting up STunnel.  The problem is that the "man in the middle attack" means that you need to jump through a bunch of hoops in order to prevent your ISP from decrypting and then re-crypting your traffic.</p></div>
	</htmltext>
<tokenext>Maybe we need to come up with a standard way of encrypting things , that our packet sniffers somehow know how to decode .
Maybe even with a " relax the crypto " configuration flag we can throw during debugIt 's called SSL , and you can bolt it on to any TCP-based application by setting up STunnel .
The problem is that the " man in the middle attack " means that you need to jump through a bunch of hoops in order to prevent your ISP from decrypting and then re-crypting your traffic .</tokentext>
<sentencetext>Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode.
Maybe even with a "relax the crypto" configuration flag we can throw during debugIt's called SSL, and you can bolt it on to any TCP-based application by setting up STunnel.
The problem is that the "man in the middle attack" means that you need to jump through a bunch of hoops in order to prevent your ISP from decrypting and then re-crypting your traffic.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810076</id>
	<title>Re:Apathy</title>
	<author>cstdenis</author>
	<datestamp>1263840540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Even in IT the learning curve can be an issue for some items.</p><p>Ever read the man page for openSSL? If you don't already know the parameters to get what you want, good luck figuring them out.<br><tt>openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout example.com.key -out example.com.crt</tt><br>and<br><tt>openssl req -new -nodes -keyout example.com.key -out example.com.csr</tt><br>Isn't exactly obvious from the documentation.</p><p>And ever try to implement DNSSEC? That is a pretty complicated system too so it's no surprise few are bothering to go to the considerable effort to set it up.</p><p>Encryption needs to be simple to implement if we expect people to bother doing it.</p></htmltext>
<tokenext>Even in IT the learning curve can be an issue for some items.Ever read the man page for openSSL ?
If you do n't already know the parameters to get what you want , good luck figuring them out.openssl req -new -newkey rsa : 1024 -days 365 -nodes -x509 -keyout example.com.key -out example.com.crtandopenssl req -new -nodes -keyout example.com.key -out example.com.csrIs n't exactly obvious from the documentation.And ever try to implement DNSSEC ?
That is a pretty complicated system too so it 's no surprise few are bothering to go to the considerable effort to set it up.Encryption needs to be simple to implement if we expect people to bother doing it .</tokentext>
<sentencetext>Even in IT the learning curve can be an issue for some items.Ever read the man page for openSSL?
If you don't already know the parameters to get what you want, good luck figuring them out.openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout example.com.key -out example.com.crtandopenssl req -new -nodes -keyout example.com.key -out example.com.csrIsn't exactly obvious from the documentation.And ever try to implement DNSSEC?
That is a pretty complicated system too so it's no surprise few are bothering to go to the considerable effort to set it up.Encryption needs to be simple to implement if we expect people to bother doing it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809062</id>
	<title>Re:Apathy</title>
	<author>Anonymous</author>
	<datestamp>1263836220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Canadians don't want guns in their houses. We learned from our previous primer minister that the only weapon* we need is a plastic spork from KFC.</p><p>* In case of missing spork, simply try to strangle the assailant.</p></htmltext>
<tokenext>Canadians do n't want guns in their houses .
We learned from our previous primer minister that the only weapon * we need is a plastic spork from KFC .
* In case of missing spork , simply try to strangle the assailant .</tokentext>
<sentencetext>Canadians don't want guns in their houses.
We learned from our previous primer minister that the only weapon* we need is a plastic spork from KFC.
* In case of missing spork, simply try to strangle the assailant.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817190</id>
	<title>Re:Costs?</title>
	<author>Anonymous</author>
	<datestamp>1263894660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That's funny, my ipod touch does imaps and smtps connections.</p></htmltext>
<tokenext>That 's funny , my ipod touch does imaps and smtps connections .</tokentext>
<sentencetext>That's funny, my ipod touch does imaps and smtps connections.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809788</id>
	<title>It's the users...mostly</title>
	<author>Mr. Freeman</author>
	<datestamp>1263839280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Most businesses don't offer encryption because their customers don't demand it.  Most users don't demand it because there is no penalty for not using it.<br><br>Sure, not using encryption can result in identity theft, someone sniffing your password, someone getting into your financial info, etc.  But how often does this really happen?  Most users perceive the benefit to be non-existent.  "I haven't had a problem before, why should I change now?".  Having your financial information ruined is something that always happens to "other people".<br><br>Companies have a financial incentive to discourage encryption because it costs them money (regardless of how little) to implement it.  They also have financial incentives to poorly protect and secure their customers' data and to lie to customers when their data is leaked.<br><br>Oh, all of our customer's credit card numbers, names, addresses, and other personal information is now available on the internet because someone lost a laptop that should never have been taken outside of the building?  Let's just cover it up.<br>Someone leaked to the press that we had a security breach?  Let's lie and say that there's no risk to customers.<br>People are now having their identity stolen because of the leak?  let's sue to keep people quiet and offer tiny settlements with NDAs.<br><br>We're not going to see encryption become widespread until:<br>1. Customers demand it. (Which won't happen anytime soon, see above)<br>2. A bunch of congressmen have their personal info leaked because of a fuckup and they pass some laws about securing personal info.</htmltext>
<tokenext>Most businesses do n't offer encryption because their customers do n't demand it .
Most users do n't demand it because there is no penalty for not using it.Sure , not using encryption can result in identity theft , someone sniffing your password , someone getting into your financial info , etc .
But how often does this really happen ?
Most users perceive the benefit to be non-existent .
" I have n't had a problem before , why should I change now ? " .
Having your financial information ruined is something that always happens to " other people " .Companies have a financial incentive to discourage encryption because it costs them money ( regardless of how little ) to implement it .
They also have financial incentives to poorly protect and secure their customers ' data and to lie to customers when their data is leaked.Oh , all of our customer 's credit card numbers , names , addresses , and other personal information is now available on the internet because someone lost a laptop that should never have been taken outside of the building ?
Let 's just cover it up.Someone leaked to the press that we had a security breach ?
Let 's lie and say that there 's no risk to customers.People are now having their identity stolen because of the leak ?
let 's sue to keep people quiet and offer tiny settlements with NDAs.We 're not going to see encryption become widespread until : 1 .
Customers demand it .
( Which wo n't happen anytime soon , see above ) 2 .
A bunch of congressmen have their personal info leaked because of a fuckup and they pass some laws about securing personal info .</tokentext>
<sentencetext>Most businesses don't offer encryption because their customers don't demand it.
Most users don't demand it because there is no penalty for not using it.Sure, not using encryption can result in identity theft, someone sniffing your password, someone getting into your financial info, etc.
But how often does this really happen?
Most users perceive the benefit to be non-existent.
"I haven't had a problem before, why should I change now?".
Having your financial information ruined is something that always happens to "other people".Companies have a financial incentive to discourage encryption because it costs them money (regardless of how little) to implement it.
They also have financial incentives to poorly protect and secure their customers' data and to lie to customers when their data is leaked.Oh, all of our customer's credit card numbers, names, addresses, and other personal information is now available on the internet because someone lost a laptop that should never have been taken outside of the building?
Let's just cover it up.Someone leaked to the press that we had a security breach?
Let's lie and say that there's no risk to customers.People are now having their identity stolen because of the leak?
let's sue to keep people quiet and offer tiny settlements with NDAs.We're not going to see encryption become widespread until:1.
Customers demand it.
(Which won't happen anytime soon, see above)2.
A bunch of congressmen have their personal info leaked because of a fuckup and they pass some laws about securing personal info.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810922</id>
	<title>This surprises you?</title>
	<author>sirgoran</author>
	<datestamp>1263844740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Please. I use to work for a mid-sized company that dealt with Fortune 500 companies. Companies that required us to use specific programs for FTP and accessing their systems. Despite several warnings, several long talks, we still had one account manager in our company that refused to follow the guidelines set out by our clients and used IE for all of his FTP traffic. We were dealing with companies paying us millions and we couldn't get one jackass to follow the rules. Even under the pressure of the IT department and the possible loss of a client couldn't get him to change his ways. Rather then fire the idiot, they moved him to a different client. Just goes to show that even when you beat someone over the head with rules, guidelines, and facts, they're still going to do what they want to do.
<br> <br>
- Goran</htmltext>
<tokenext>Please .
I use to work for a mid-sized company that dealt with Fortune 500 companies .
Companies that required us to use specific programs for FTP and accessing their systems .
Despite several warnings , several long talks , we still had one account manager in our company that refused to follow the guidelines set out by our clients and used IE for all of his FTP traffic .
We were dealing with companies paying us millions and we could n't get one jackass to follow the rules .
Even under the pressure of the IT department and the possible loss of a client could n't get him to change his ways .
Rather then fire the idiot , they moved him to a different client .
Just goes to show that even when you beat someone over the head with rules , guidelines , and facts , they 're still going to do what they want to do .
- Goran</tokentext>
<sentencetext>Please.
I use to work for a mid-sized company that dealt with Fortune 500 companies.
Companies that required us to use specific programs for FTP and accessing their systems.
Despite several warnings, several long talks, we still had one account manager in our company that refused to follow the guidelines set out by our clients and used IE for all of his FTP traffic.
We were dealing with companies paying us millions and we couldn't get one jackass to follow the rules.
Even under the pressure of the IT department and the possible loss of a client couldn't get him to change his ways.
Rather then fire the idiot, they moved him to a different client.
Just goes to show that even when you beat someone over the head with rules, guidelines, and facts, they're still going to do what they want to do.
- Goran</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810398</id>
	<title>ssh tunnels / port forwarding / sshfs</title>
	<author>cenc</author>
	<datestamp>1263842160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I keep hearing everyone bitch about how hard it is to do wide scale encryption with so many user computers to configure, but I have found things like ssh port forwarding between offices to be an incredibly easy and secure solution to much of my encryption needs. Yea, it does not solve all the problems, but it is sure makes life as a systems admin much easier than trying to keep track of all the various possible protocols and their potential faults. It is possible to just about encrypt anything with a high level of transparency to the end user.</p></htmltext>
<tokenext>I keep hearing everyone bitch about how hard it is to do wide scale encryption with so many user computers to configure , but I have found things like ssh port forwarding between offices to be an incredibly easy and secure solution to much of my encryption needs .
Yea , it does not solve all the problems , but it is sure makes life as a systems admin much easier than trying to keep track of all the various possible protocols and their potential faults .
It is possible to just about encrypt anything with a high level of transparency to the end user .</tokentext>
<sentencetext>I keep hearing everyone bitch about how hard it is to do wide scale encryption with so many user computers to configure, but I have found things like ssh port forwarding between offices to be an incredibly easy and secure solution to much of my encryption needs.
Yea, it does not solve all the problems, but it is sure makes life as a systems admin much easier than trying to keep track of all the various possible protocols and their potential faults.
It is possible to just about encrypt anything with a high level of transparency to the end user.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</id>
	<title>More direct costs.</title>
	<author>Anonymous</author>
	<datestamp>1263836340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>It costs a nonzero amount to get a certificate at all, and a self-signed certificate is barely better than raw http.</p><p>It also costs a nonzero amount in server CPU usage and/or dedicated hardware to do the crypto itself, especially the https sessions. For example, Google App Engine will handle the SSL for you for free, using a wildcard cert for *.appspot.com, but the crypto does count towards your CPU quotas.</p><p>These two factors suggest that it makes sense for crypto to be used only where needed, rather than using it everywhere we can. Combine that with corporate sluggishness to approve <i>any</i> spending, and you can imagine why even where it is needed, it can be an uphill battle to get it actually adopted.</p></htmltext>
<tokenext>It costs a nonzero amount to get a certificate at all , and a self-signed certificate is barely better than raw http.It also costs a nonzero amount in server CPU usage and/or dedicated hardware to do the crypto itself , especially the https sessions .
For example , Google App Engine will handle the SSL for you for free , using a wildcard cert for * .appspot.com , but the crypto does count towards your CPU quotas.These two factors suggest that it makes sense for crypto to be used only where needed , rather than using it everywhere we can .
Combine that with corporate sluggishness to approve any spending , and you can imagine why even where it is needed , it can be an uphill battle to get it actually adopted .</tokentext>
<sentencetext>It costs a nonzero amount to get a certificate at all, and a self-signed certificate is barely better than raw http.It also costs a nonzero amount in server CPU usage and/or dedicated hardware to do the crypto itself, especially the https sessions.
For example, Google App Engine will handle the SSL for you for free, using a wildcard cert for *.appspot.com, but the crypto does count towards your CPU quotas.These two factors suggest that it makes sense for crypto to be used only where needed, rather than using it everywhere we can.
Combine that with corporate sluggishness to approve any spending, and you can imagine why even where it is needed, it can be an uphill battle to get it actually adopted.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810552</id>
	<title>Re:People don't see the value</title>
	<author>TheRaven64</author>
	<datestamp>1263842880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.</p></div><p>It's not a mistaken attitude, and it's becoming an increasingly less-mistaken one.  Think of all of those free WiFi access points.  Your employee sits down in a cafe and connects with its access point.  Well, he thinks it's their access point.  Actually it's run by the guy renting the flat above the cafe.  He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate.  </p><p>
Your employee connect to your corporate Intranet with it and, unless you distributed the certificate out of band and your employees know not to allow connecting when the certificate verification fails, he's just handed his login details to a stranger.  This guy harvests as much as he can from the Intranet before you notice, then sells it to one of your less scrupulous competitors.  </p><p>
When a potential threat needs about $50 of off-the-shelf kit and a tiny bit of patience, it's not the sort of thing that you should be discounting.</p></div>
	</htmltext>
<tokenext>To answer the original question , the thing holding back encryption is the above mistaken attitude , that using a self-signed cert is barely better than using plaintext.It 's not a mistaken attitude , and it 's becoming an increasingly less-mistaken one .
Think of all of those free WiFi access points .
Your employee sits down in a cafe and connects with its access point .
Well , he thinks it 's their access point .
Actually it 's run by the guy renting the flat above the cafe .
He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate .
Your employee connect to your corporate Intranet with it and , unless you distributed the certificate out of band and your employees know not to allow connecting when the certificate verification fails , he 's just handed his login details to a stranger .
This guy harvests as much as he can from the Intranet before you notice , then sells it to one of your less scrupulous competitors .
When a potential threat needs about $ 50 of off-the-shelf kit and a tiny bit of patience , it 's not the sort of thing that you should be discounting .</tokentext>
<sentencetext>To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.It's not a mistaken attitude, and it's becoming an increasingly less-mistaken one.
Think of all of those free WiFi access points.
Your employee sits down in a cafe and connects with its access point.
Well, he thinks it's their access point.
Actually it's run by the guy renting the flat above the cafe.
He redirects all HTTP through his proxy and will do a MITM attack on anything that uses a self-signed certificate.
Your employee connect to your corporate Intranet with it and, unless you distributed the certificate out of band and your employees know not to allow connecting when the certificate verification fails, he's just handed his login details to a stranger.
This guy harvests as much as he can from the Intranet before you notice, then sells it to one of your less scrupulous competitors.
When a potential threat needs about $50 of off-the-shelf kit and a tiny bit of patience, it's not the sort of thing that you should be discounting.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816656</id>
	<title>The Actual Problem</title>
	<author>Dan541</author>
	<datestamp>1263844080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Only Terrorists use encryption, if your not a terrorist you've got nothing to hide.</p></htmltext>
<tokenext>Only Terrorists use encryption , if your not a terrorist you 've got nothing to hide .</tokentext>
<sentencetext>Only Terrorists use encryption, if your not a terrorist you've got nothing to hide.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809270</id>
	<title>Crying wolf in the past</title>
	<author>starglider29a</author>
	<datestamp>1263837060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In 1994, I wrote a rant to my friends telling to "get encrypted or get pwned*". Paranoia of that day (new prez, newer congress, Blue laws, Waco, Ruby Ridge, OK city yet to happen) We went through a bit of wrangling to get PGP keys and such. We were not n00bs, but it still seemed more difficult than it should have been. We encrypted our emails, and even our chats... for a while. When we realized that nothing we were saying mattered to anyone interesting (pick a 3 letter acronym), we stopped bothering.<br> <br>
But now, it seems like delusional paranoia to think we need to encrypt our every day stuff. I still have that rant on file, and it seems pretty kooky in retrospect. Having to explain the wisdom of encryption to someone who can't open a<nobr> <wbr></nobr>.DOT file comes off as wacko.<br> <br> <br>
*no, I didn't use that word.</htmltext>
<tokenext>In 1994 , I wrote a rant to my friends telling to " get encrypted or get pwned * " .
Paranoia of that day ( new prez , newer congress , Blue laws , Waco , Ruby Ridge , OK city yet to happen ) We went through a bit of wrangling to get PGP keys and such .
We were not n00bs , but it still seemed more difficult than it should have been .
We encrypted our emails , and even our chats... for a while .
When we realized that nothing we were saying mattered to anyone interesting ( pick a 3 letter acronym ) , we stopped bothering .
But now , it seems like delusional paranoia to think we need to encrypt our every day stuff .
I still have that rant on file , and it seems pretty kooky in retrospect .
Having to explain the wisdom of encryption to someone who ca n't open a .DOT file comes off as wacko .
* no , I did n't use that word .</tokentext>
<sentencetext>In 1994, I wrote a rant to my friends telling to "get encrypted or get pwned*".
Paranoia of that day (new prez, newer congress, Blue laws, Waco, Ruby Ridge, OK city yet to happen) We went through a bit of wrangling to get PGP keys and such.
We were not n00bs, but it still seemed more difficult than it should have been.
We encrypted our emails, and even our chats... for a while.
When we realized that nothing we were saying mattered to anyone interesting (pick a 3 letter acronym), we stopped bothering.
But now, it seems like delusional paranoia to think we need to encrypt our every day stuff.
I still have that rant on file, and it seems pretty kooky in retrospect.
Having to explain the wisdom of encryption to someone who can't open a .DOT file comes off as wacko.
*no, I didn't use that word.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809106</id>
	<title>Re:I have encrypted this post</title>
	<author>140Mandak262Jamuna</author>
	<datestamp>1263836400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I have encrypted this post as my contribution to making encryption more widespread.</p><p>Here you go:

kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu{ywe9f8iunsiochjaijkcs</p><p>The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....</p></div><p>But what if that post contains the secret formula that would set the pants on fire <b>successfully</b>? You know what kind of danger that would pose to general aviation? So get ready to greet a couple of tall gentlemen in dark suit, dark glasses who speak into the lapels of their coat.</p></div>
	</htmltext>
<tokenext>I have encrypted this post as my contribution to making encryption more widespread.Here you go : kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu { ywe9f8iunsiochjaijkcsThe fun part is that the ( UK ) cops can demand a decryption key for that , and lock me up when I inevitably fail to provide one....But what if that post contains the secret formula that would set the pants on fire successfully ?
You know what kind of danger that would pose to general aviation ?
So get ready to greet a couple of tall gentlemen in dark suit , dark glasses who speak into the lapels of their coat .</tokentext>
<sentencetext>I have encrypted this post as my contribution to making encryption more widespread.Here you go:

kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu{ywe9f8iunsiochjaijkcsThe fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....But what if that post contains the secret formula that would set the pants on fire successfully?
You know what kind of danger that would pose to general aviation?
So get ready to greet a couple of tall gentlemen in dark suit, dark glasses who speak into the lapels of their coat.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808922</id>
	<title>It's simple.</title>
	<author>Low Ranked Craig</author>
	<datestamp>1263835620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>It won't happen until the pain of not doing it exceeds the cost of implementing it.</htmltext>
<tokenext>It wo n't happen until the pain of not doing it exceeds the cost of implementing it .</tokentext>
<sentencetext>It won't happen until the pain of not doing it exceeds the cost of implementing it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810338</id>
	<title>What about..</title>
	<author>Anonymous</author>
	<datestamp>1263841800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>ease of use?</p><p>For example e-mail: it is hard for the majority of people to generate a key, select the appropriate strenght/algorithm, know the difference between public and private keys, notify their friends about their keys (and key changes). It is just too much of a hassle, so even if you want to use it yourself, the majority of the people you communicate won't.</p><p>Take skype for example (though closed source), they claim to encrypt your calls and video chats using 1024bit public/private RSA keys. The end user doesn't even realize it happens. The same goes for SSL, from the perspective of the end-user it 'just works'.</p><p>Unless there is a real necessity, people won't make an effort and just go for the easy way. Therefore it should be easy.</p></htmltext>
<tokenext>ease of use ? For example e-mail : it is hard for the majority of people to generate a key , select the appropriate strenght/algorithm , know the difference between public and private keys , notify their friends about their keys ( and key changes ) .
It is just too much of a hassle , so even if you want to use it yourself , the majority of the people you communicate wo n't.Take skype for example ( though closed source ) , they claim to encrypt your calls and video chats using 1024bit public/private RSA keys .
The end user does n't even realize it happens .
The same goes for SSL , from the perspective of the end-user it 'just works'.Unless there is a real necessity , people wo n't make an effort and just go for the easy way .
Therefore it should be easy .</tokentext>
<sentencetext>ease of use?For example e-mail: it is hard for the majority of people to generate a key, select the appropriate strenght/algorithm, know the difference between public and private keys, notify their friends about their keys (and key changes).
It is just too much of a hassle, so even if you want to use it yourself, the majority of the people you communicate won't.Take skype for example (though closed source), they claim to encrypt your calls and video chats using 1024bit public/private RSA keys.
The end user doesn't even realize it happens.
The same goes for SSL, from the perspective of the end-user it 'just works'.Unless there is a real necessity, people won't make an effort and just go for the easy way.
Therefore it should be easy.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810246</id>
	<title>Encryption is brittle</title>
	<author>Anonymous</author>
	<datestamp>1263841320000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>When systems fail they often fail gracefully and often provide you a hint of what's failing. Your image server is broken? Ok, no images but you still get the text and it's plainly obvious there is a problem with the image server.<br>When encryption fails, you are usually dead in the water with no inkling of what went wrong or how to fix it. Letting you know what is wrong and how to fix it is often considered a security flaw (for example, the classic approach of being vague about which part of your username/password combo is wrong).</p><p>Encryption is either all working or all not working by its nature. It is brittle by design and a pain to use as a result.</p></htmltext>
<tokenext>When systems fail they often fail gracefully and often provide you a hint of what 's failing .
Your image server is broken ?
Ok , no images but you still get the text and it 's plainly obvious there is a problem with the image server.When encryption fails , you are usually dead in the water with no inkling of what went wrong or how to fix it .
Letting you know what is wrong and how to fix it is often considered a security flaw ( for example , the classic approach of being vague about which part of your username/password combo is wrong ) .Encryption is either all working or all not working by its nature .
It is brittle by design and a pain to use as a result .</tokentext>
<sentencetext>When systems fail they often fail gracefully and often provide you a hint of what's failing.
Your image server is broken?
Ok, no images but you still get the text and it's plainly obvious there is a problem with the image server.When encryption fails, you are usually dead in the water with no inkling of what went wrong or how to fix it.
Letting you know what is wrong and how to fix it is often considered a security flaw (for example, the classic approach of being vague about which part of your username/password combo is wrong).Encryption is either all working or all not working by its nature.
It is brittle by design and a pain to use as a result.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809488</id>
	<title>Re:too much effort</title>
	<author>Anonymous</author>
	<datestamp>1263838020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Got the OpenPGP (Enigmail) add-on for Thunderbird.</p><p>For the replies in encrypted:<br>Menu Bar -&gt; OpenPGP -&gt; Preferences -&gt; Advanced -&gt; Encrypt Replies to Encrypted Message</p><p>Option to auto-attach your key however when doing PGP.<br>Account Settings -&gt; OpenPGP Security, Advanced Button, Attach my public key to messages.<br>For me it wasn't working with the Auto-select email for key to use method, but that could be because I don't have any keys set up.</p><p>Now for S/MIME method, I see less options, and as far as I can tell the only way to set them are in the Account Settings Dialog for the account. Those options appear to be which cert to use to sign and encrypt the messages.<br>Hmm, looking at some old random messages I sent to myself signed with S/MIME(random tests), it seems as it auto-attaches the public key. View Source shows an attachment of 'Content-Type: application/x-pkcs7-signature; name="smime.p7s"'<br>But I don't remember if it asked me to reply encrypted when the message itself was encrypted.</p></htmltext>
<tokenext>Got the OpenPGP ( Enigmail ) add-on for Thunderbird.For the replies in encrypted : Menu Bar - &gt; OpenPGP - &gt; Preferences - &gt; Advanced - &gt; Encrypt Replies to Encrypted MessageOption to auto-attach your key however when doing PGP.Account Settings - &gt; OpenPGP Security , Advanced Button , Attach my public key to messages.For me it was n't working with the Auto-select email for key to use method , but that could be because I do n't have any keys set up.Now for S/MIME method , I see less options , and as far as I can tell the only way to set them are in the Account Settings Dialog for the account .
Those options appear to be which cert to use to sign and encrypt the messages.Hmm , looking at some old random messages I sent to myself signed with S/MIME ( random tests ) , it seems as it auto-attaches the public key .
View Source shows an attachment of 'Content-Type : application/x-pkcs7-signature ; name = " smime.p7s " 'But I do n't remember if it asked me to reply encrypted when the message itself was encrypted .</tokentext>
<sentencetext>Got the OpenPGP (Enigmail) add-on for Thunderbird.For the replies in encrypted:Menu Bar -&gt; OpenPGP -&gt; Preferences -&gt; Advanced -&gt; Encrypt Replies to Encrypted MessageOption to auto-attach your key however when doing PGP.Account Settings -&gt; OpenPGP Security, Advanced Button, Attach my public key to messages.For me it wasn't working with the Auto-select email for key to use method, but that could be because I don't have any keys set up.Now for S/MIME method, I see less options, and as far as I can tell the only way to set them are in the Account Settings Dialog for the account.
Those options appear to be which cert to use to sign and encrypt the messages.Hmm, looking at some old random messages I sent to myself signed with S/MIME(random tests), it seems as it auto-attaches the public key.
View Source shows an attachment of 'Content-Type: application/x-pkcs7-signature; name="smime.p7s"'But I don't remember if it asked me to reply encrypted when the message itself was encrypted.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809738</id>
	<title>Critical threshold</title>
	<author>macemoneta</author>
	<datestamp>1263839100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's like what's holding back Google Wave; there's no one to talk to.  I've had encryption setup for about a decade.  I've tried convincing people to set it up.  In the end, I'm talking to myself.</p><p>If encryption is going to go mainstream, then setting it up and using it has to be the default configuration.  Pretend it's a new version of Microsoft Word, defaulting to a new file format.  There you go, everyone has upgraded (kicking and screaming).</p><p>Apple, Microsoft and Linux distributions need to establish (and export) new keys (or import existing keys) as part of the first boot processes, and use encryption if the destination user has a key by default.  It's the only way it will happen.</p></htmltext>
<tokenext>It 's like what 's holding back Google Wave ; there 's no one to talk to .
I 've had encryption setup for about a decade .
I 've tried convincing people to set it up .
In the end , I 'm talking to myself.If encryption is going to go mainstream , then setting it up and using it has to be the default configuration .
Pretend it 's a new version of Microsoft Word , defaulting to a new file format .
There you go , everyone has upgraded ( kicking and screaming ) .Apple , Microsoft and Linux distributions need to establish ( and export ) new keys ( or import existing keys ) as part of the first boot processes , and use encryption if the destination user has a key by default .
It 's the only way it will happen .</tokentext>
<sentencetext>It's like what's holding back Google Wave; there's no one to talk to.
I've had encryption setup for about a decade.
I've tried convincing people to set it up.
In the end, I'm talking to myself.If encryption is going to go mainstream, then setting it up and using it has to be the default configuration.
Pretend it's a new version of Microsoft Word, defaulting to a new file format.
There you go, everyone has upgraded (kicking and screaming).Apple, Microsoft and Linux distributions need to establish (and export) new keys (or import existing keys) as part of the first boot processes, and use encryption if the destination user has a key by default.
It's the only way it will happen.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808946</id>
	<title>Re:There's no reason to encrypt HTTP</title>
	<author>grub</author>
	<datestamp>1263835740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><br> <i>There's no reason to encrypt HTTP requests that don't contain personal information.</i> <br> <br>
<br>No?  Think about someone in China searching for Falun Gong information then having their door kicked in by the state police.</htmltext>
<tokenext>There 's no reason to encrypt HTTP requests that do n't contain personal information .
No ? Think about someone in China searching for Falun Gong information then having their door kicked in by the state police .</tokentext>
<sentencetext> There's no reason to encrypt HTTP requests that don't contain personal information.
No?  Think about someone in China searching for Falun Gong information then having their door kicked in by the state police.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810638</id>
	<title>IDS/IPS is ineffective with everything encrypted</title>
	<author>haus</author>
	<datestamp>1263843240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Corporate / Government security operations centers do not want everything to be encrypted, because it makes it much harder to determine when someone/something is doing something that you do not want them to do.</p></htmltext>
<tokenext>Corporate / Government security operations centers do not want everything to be encrypted , because it makes it much harder to determine when someone/something is doing something that you do not want them to do .</tokentext>
<sentencetext>Corporate / Government security operations centers do not want everything to be encrypted, because it makes it much harder to determine when someone/something is doing something that you do not want them to do.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809406</id>
	<title>Re:Encryption isn't free</title>
	<author>OrangeCatholic</author>
	<datestamp>1263837660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Then don't use envelopes.  Just send all your mail as postcards.
<br> <br>
After all, it takes easily twice as long to open an envelope as it does to flip over a postcard and read it.  And it costs more.
<br> <br>
Funny that 99\% of personal mail is in an envelope. I feel like we've tackled this problem before.  Does an envelope serve a purpose other than security?
<br> <br>
Meanwhile, we've lowered the cost of sending a letter from 42 cents to 0.01 cents by using email, and you're saying that cpu cycles <i>cost too much?</i>  Dude, how did you ever afford stamps?</htmltext>
<tokenext>Then do n't use envelopes .
Just send all your mail as postcards .
After all , it takes easily twice as long to open an envelope as it does to flip over a postcard and read it .
And it costs more .
Funny that 99 \ % of personal mail is in an envelope .
I feel like we 've tackled this problem before .
Does an envelope serve a purpose other than security ?
Meanwhile , we 've lowered the cost of sending a letter from 42 cents to 0.01 cents by using email , and you 're saying that cpu cycles cost too much ?
Dude , how did you ever afford stamps ?</tokentext>
<sentencetext>Then don't use envelopes.
Just send all your mail as postcards.
After all, it takes easily twice as long to open an envelope as it does to flip over a postcard and read it.
And it costs more.
Funny that 99\% of personal mail is in an envelope.
I feel like we've tackled this problem before.
Does an envelope serve a purpose other than security?
Meanwhile, we've lowered the cost of sending a letter from 42 cents to 0.01 cents by using email, and you're saying that cpu cycles cost too much?
Dude, how did you ever afford stamps?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808856</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809238</id>
	<title>Re:Seriously?</title>
	<author>SanityInAnarchy</author>
	<datestamp>1263836880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I was with you up till here:</p><p><div class="quote"><p>the current spam-friendly email protocols we've been living with for decades haven't been replaced with authenticated sender-based protocols,</p></div><p>Are you telling me there's a spam-hostile email protocol possible? How does it do with The Form?</p><p><div class="quote"><p>blacklist-based antivirus hasn't been replaced by a less "lossy" model of security.</p></div><p>Actually, the simple replacement for all antivirus is a savvy user. I don't think that's inertia, though, I think that's a weird social block we have -- we want to make this an IT problem instead of an end-user problem, because if it was an end-user problem, we'd have to educate all the end-users, and quite possibly lose a lot of otherwise-productive people who refuse to learn tech.</p></div>
	</htmltext>
<tokenext>I was with you up till here : the current spam-friendly email protocols we 've been living with for decades have n't been replaced with authenticated sender-based protocols,Are you telling me there 's a spam-hostile email protocol possible ?
How does it do with The Form ? blacklist-based antivirus has n't been replaced by a less " lossy " model of security.Actually , the simple replacement for all antivirus is a savvy user .
I do n't think that 's inertia , though , I think that 's a weird social block we have -- we want to make this an IT problem instead of an end-user problem , because if it was an end-user problem , we 'd have to educate all the end-users , and quite possibly lose a lot of otherwise-productive people who refuse to learn tech .</tokentext>
<sentencetext>I was with you up till here:the current spam-friendly email protocols we've been living with for decades haven't been replaced with authenticated sender-based protocols,Are you telling me there's a spam-hostile email protocol possible?
How does it do with The Form?blacklist-based antivirus hasn't been replaced by a less "lossy" model of security.Actually, the simple replacement for all antivirus is a savvy user.
I don't think that's inertia, though, I think that's a weird social block we have -- we want to make this an IT problem instead of an end-user problem, because if it was an end-user problem, we'd have to educate all the end-users, and quite possibly lose a lot of otherwise-productive people who refuse to learn tech.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809578</id>
	<title>Re:There's no reason to encrypt HTTP</title>
	<author>eightball</author>
	<datestamp>1263838440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That search seems to me to contain personal information: an interest in Falun Gong.</p></htmltext>
<tokenext>That search seems to me to contain personal information : an interest in Falun Gong .</tokentext>
<sentencetext>That search seems to me to contain personal information: an interest in Falun Gong.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808946</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812366</id>
	<title>Cost and complexity are the problems</title>
	<author>Anonymous</author>
	<datestamp>1263808080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Cost of recognized certificates, ones which come from the client software's preloaded default certificate authorities is a major problem.  Server to server can be self signed, but ones that are customer/user facing have to be ones most browsers and applications will recognize without prompting with a security warning.</p><p>And managing those certificates which expire every year or every couple years can be a hassle, or worse they will cause people problems when they expire.</p><p>Of the two problems though, if cost was less then you would see wider adoption.   For server to server communications, self signed certs make a lot of sense.</p></htmltext>
<tokenext>Cost of recognized certificates , ones which come from the client software 's preloaded default certificate authorities is a major problem .
Server to server can be self signed , but ones that are customer/user facing have to be ones most browsers and applications will recognize without prompting with a security warning.And managing those certificates which expire every year or every couple years can be a hassle , or worse they will cause people problems when they expire.Of the two problems though , if cost was less then you would see wider adoption .
For server to server communications , self signed certs make a lot of sense .</tokentext>
<sentencetext>Cost of recognized certificates, ones which come from the client software's preloaded default certificate authorities is a major problem.
Server to server can be self signed, but ones that are customer/user facing have to be ones most browsers and applications will recognize without prompting with a security warning.And managing those certificates which expire every year or every couple years can be a hassle, or worse they will cause people problems when they expire.Of the two problems though, if cost was less then you would see wider adoption.
For server to server communications, self signed certs make a lot of sense.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816256</id>
	<title>Re:Costs?</title>
	<author>Anonymous</author>
	<datestamp>1263838200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>even companies working in the security market don't use encrypted email and often don't even understand how to use it...</p></div><p> <a href="http://www.comodo.com/" title="comodo.com" rel="nofollow">Comodo</a> [comodo.com] is one of them. They want you to send various ID documents via unencrypted email and don't offer alternatives. I asked for a more secure method but they literally had no idea what I was talking about despite selling the product I was inquiring to use as a secure means of sending the documents. Fucking morons.</p></div>
	</htmltext>
<tokenext>even companies working in the security market do n't use encrypted email and often do n't even understand how to use it... Comodo [ comodo.com ] is one of them .
They want you to send various ID documents via unencrypted email and do n't offer alternatives .
I asked for a more secure method but they literally had no idea what I was talking about despite selling the product I was inquiring to use as a secure means of sending the documents .
Fucking morons .</tokentext>
<sentencetext>even companies working in the security market don't use encrypted email and often don't even understand how to use it... Comodo [comodo.com] is one of them.
They want you to send various ID documents via unencrypted email and don't offer alternatives.
I asked for a more secure method but they literally had no idea what I was talking about despite selling the product I was inquiring to use as a secure means of sending the documents.
Fucking morons.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814144</id>
	<title>Too hard to use ...</title>
	<author>gordguide</author>
	<datestamp>1263817260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I had a secure certificate for eMail encryption. Took about a day to figure out how to use it, get it implemented in my mail program, how to inform other eMail users the procedure to decrypt my messages, get the certificate signed by Thawte, etc. As it turned out, only one other person I corresponded with had implemented eMail encryption.</p><p>Then one day, the certificate expired. Do you think I could wade my way through the obscure techno-babble of the Thawte website to renew my certificate? If you answered "yes", you'd be wrong. I couldn't even figure out what kind of certificate I had when wading through the obtuse language at Thawte.</p><p>Someone has to make this easier than getting 24 bit video at something bigger than 640x480 to work on obscure hardware with a new Linux distro. That was a piece of cake in comparison.</p><p>To this day I have no idea what Thawte wanted me to do to renew the certificate.</p></htmltext>
<tokenext>I had a secure certificate for eMail encryption .
Took about a day to figure out how to use it , get it implemented in my mail program , how to inform other eMail users the procedure to decrypt my messages , get the certificate signed by Thawte , etc .
As it turned out , only one other person I corresponded with had implemented eMail encryption.Then one day , the certificate expired .
Do you think I could wade my way through the obscure techno-babble of the Thawte website to renew my certificate ?
If you answered " yes " , you 'd be wrong .
I could n't even figure out what kind of certificate I had when wading through the obtuse language at Thawte.Someone has to make this easier than getting 24 bit video at something bigger than 640x480 to work on obscure hardware with a new Linux distro .
That was a piece of cake in comparison.To this day I have no idea what Thawte wanted me to do to renew the certificate .</tokentext>
<sentencetext>I had a secure certificate for eMail encryption.
Took about a day to figure out how to use it, get it implemented in my mail program, how to inform other eMail users the procedure to decrypt my messages, get the certificate signed by Thawte, etc.
As it turned out, only one other person I corresponded with had implemented eMail encryption.Then one day, the certificate expired.
Do you think I could wade my way through the obscure techno-babble of the Thawte website to renew my certificate?
If you answered "yes", you'd be wrong.
I couldn't even figure out what kind of certificate I had when wading through the obtuse language at Thawte.Someone has to make this easier than getting 24 bit video at something bigger than 640x480 to work on obscure hardware with a new Linux distro.
That was a piece of cake in comparison.To this day I have no idea what Thawte wanted me to do to renew the certificate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810254</id>
	<title>DNSSEC has nothing to do with encryption</title>
	<author>Anonymous</author>
	<datestamp>1263841380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>DNSSEC has absolutely nothing to do with encryption. Nothing is hidden and the resource records are still in clear text. DNSSEC is about integrity of the resource records.</p><p>But DNSSEC can be a catalyst for encryption technologies. DNSSEC allow you to put certificates, ssh-keys, etc in the DNS in a secure way.</p><p>JB</p></htmltext>
<tokenext>DNSSEC has absolutely nothing to do with encryption .
Nothing is hidden and the resource records are still in clear text .
DNSSEC is about integrity of the resource records.But DNSSEC can be a catalyst for encryption technologies .
DNSSEC allow you to put certificates , ssh-keys , etc in the DNS in a secure way.JB</tokentext>
<sentencetext>DNSSEC has absolutely nothing to do with encryption.
Nothing is hidden and the resource records are still in clear text.
DNSSEC is about integrity of the resource records.But DNSSEC can be a catalyst for encryption technologies.
DNSSEC allow you to put certificates, ssh-keys, etc in the DNS in a secure way.JB</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809244</id>
	<title>Re:Because it's a PITA - Pain In the Ass!</title>
	<author>Stepnsteph</author>
	<datestamp>1263836940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>^ This.  Perhaps some people here are lucky enough to know people who are willing to use encryption tools.  They don't live in the same world as the rest of us.  "It ain't happening" isn't a strong enough way of expressing the situation.  I was just barely able to convince someone to install an OTR plugin, and even then they grumble about it.  That's just a plugin ffs.  Imagine trying to convince people to use shared key encryption for their email.  I've tried (I maintain a PGP key for some absurd reason) and the responses were "No" and "Hell no" and derivatives there of.</p><p>The closest I was able to get with email encryption was Ciphire Mail.  That was a beautiful tool, and it was the easiest thing to ever happen to email encryption.  It's a darn shame that they folded.</p><p>That is, of course, in regards to every day users.  I can't speak for the enterprise level.</p></htmltext>
<tokenext>^ This .
Perhaps some people here are lucky enough to know people who are willing to use encryption tools .
They do n't live in the same world as the rest of us .
" It ai n't happening " is n't a strong enough way of expressing the situation .
I was just barely able to convince someone to install an OTR plugin , and even then they grumble about it .
That 's just a plugin ffs .
Imagine trying to convince people to use shared key encryption for their email .
I 've tried ( I maintain a PGP key for some absurd reason ) and the responses were " No " and " Hell no " and derivatives there of.The closest I was able to get with email encryption was Ciphire Mail .
That was a beautiful tool , and it was the easiest thing to ever happen to email encryption .
It 's a darn shame that they folded.That is , of course , in regards to every day users .
I ca n't speak for the enterprise level .</tokentext>
<sentencetext>^ This.
Perhaps some people here are lucky enough to know people who are willing to use encryption tools.
They don't live in the same world as the rest of us.
"It ain't happening" isn't a strong enough way of expressing the situation.
I was just barely able to convince someone to install an OTR plugin, and even then they grumble about it.
That's just a plugin ffs.
Imagine trying to convince people to use shared key encryption for their email.
I've tried (I maintain a PGP key for some absurd reason) and the responses were "No" and "Hell no" and derivatives there of.The closest I was able to get with email encryption was Ciphire Mail.
That was a beautiful tool, and it was the easiest thing to ever happen to email encryption.
It's a darn shame that they folded.That is, of course, in regards to every day users.
I can't speak for the enterprise level.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810024</id>
	<title>Re:encryption alone</title>
	<author>OldSoldier</author>
	<datestamp>1263840300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>One thing and an observation.<br>Thing) a good SSL Cert (and accompanying support code) that allows for encryption w/o necessarily ensuring authenticity. We use self-signed certs for https: connections to a web-available database in our office and it's disconcerting to most first-time users to see all the warnings against "confirming that exception".</p><p>Observation) I'm still STUNNED that password encryption policies are not part of "privacy statements" on the web. I tend to use "secure" and "insecure" passwords. I was stunned recently when I went into a Sprint office to update my cell phone account and<nobr> <wbr></nobr>... long story short... the clerk asked me if I knew my account password (I didn't). He then asked for my name and looked it up and... get this... told me what my password was!!! un-fucking-believable. Turns out I did set it (I recognized the pw as being one if mine).</p></htmltext>
<tokenext>One thing and an observation.Thing ) a good SSL Cert ( and accompanying support code ) that allows for encryption w/o necessarily ensuring authenticity .
We use self-signed certs for https : connections to a web-available database in our office and it 's disconcerting to most first-time users to see all the warnings against " confirming that exception " .Observation ) I 'm still STUNNED that password encryption policies are not part of " privacy statements " on the web .
I tend to use " secure " and " insecure " passwords .
I was stunned recently when I went into a Sprint office to update my cell phone account and ... long story short... the clerk asked me if I knew my account password ( I did n't ) .
He then asked for my name and looked it up and... get this... told me what my password was ! ! !
un-fucking-believable. Turns out I did set it ( I recognized the pw as being one if mine ) .</tokentext>
<sentencetext>One thing and an observation.Thing) a good SSL Cert (and accompanying support code) that allows for encryption w/o necessarily ensuring authenticity.
We use self-signed certs for https: connections to a web-available database in our office and it's disconcerting to most first-time users to see all the warnings against "confirming that exception".Observation) I'm still STUNNED that password encryption policies are not part of "privacy statements" on the web.
I tend to use "secure" and "insecure" passwords.
I was stunned recently when I went into a Sprint office to update my cell phone account and ... long story short... the clerk asked me if I knew my account password (I didn't).
He then asked for my name and looked it up and... get this... told me what my password was!!!
un-fucking-believable. Turns out I did set it (I recognized the pw as being one if mine).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808840</id>
	<title>Same old Same old</title>
	<author>killmenow</author>
	<datestamp>1263835320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's the same thing holding back lots of things: greed. Microsoft would standardized on e-mail encryption support in Exchange/Outlook if it were THEIR "standard" that either locked users in or locked other providers out. So would Apple and damn near every other company out there.</p><p>Lots of encryption is in place where companies stand to lose money (eg., DRM, banking, etc.) But where they stand to lose money DUE to encryption, it's not widespread...imagine that. If the security of your data isn't going to lose (or make) a company money, the people running that company don't care a whole lot about the security of your data.</p></htmltext>
<tokenext>It 's the same thing holding back lots of things : greed .
Microsoft would standardized on e-mail encryption support in Exchange/Outlook if it were THEIR " standard " that either locked users in or locked other providers out .
So would Apple and damn near every other company out there.Lots of encryption is in place where companies stand to lose money ( eg. , DRM , banking , etc .
) But where they stand to lose money DUE to encryption , it 's not widespread...imagine that .
If the security of your data is n't going to lose ( or make ) a company money , the people running that company do n't care a whole lot about the security of your data .</tokentext>
<sentencetext>It's the same thing holding back lots of things: greed.
Microsoft would standardized on e-mail encryption support in Exchange/Outlook if it were THEIR "standard" that either locked users in or locked other providers out.
So would Apple and damn near every other company out there.Lots of encryption is in place where companies stand to lose money (eg., DRM, banking, etc.
) But where they stand to lose money DUE to encryption, it's not widespread...imagine that.
If the security of your data isn't going to lose (or make) a company money, the people running that company don't care a whole lot about the security of your data.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812284</id>
	<title>Re:I'll tell you what it is...</title>
	<author>Anonymous</author>
	<datestamp>1263807720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>if you can't prove that you're delivering packets reliably without knowing what's in them, then i recommend you look up the word "packet" again</p></htmltext>
<tokenext>if you ca n't prove that you 're delivering packets reliably without knowing what 's in them , then i recommend you look up the word " packet " again</tokentext>
<sentencetext>if you can't prove that you're delivering packets reliably without knowing what's in them, then i recommend you look up the word "packet" again</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813238</id>
	<title>Re:People don't see the value</title>
	<author>zippthorne</author>
	<datestamp>1263812460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.</p></div><p>Indeed.  It would be more accurate to say that a self-signed cert is <b>no</b> better than using plaintext, unless you distribute the cert via a separate channel.</p></div>
	</htmltext>
<tokenext>To answer the original question , the thing holding back encryption is the above mistaken attitude , that using a self-signed cert is barely better than using plaintext.Indeed .
It would be more accurate to say that a self-signed cert is no better than using plaintext , unless you distribute the cert via a separate channel .</tokentext>
<sentencetext>To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.Indeed.
It would be more accurate to say that a self-signed cert is no better than using plaintext, unless you distribute the cert via a separate channel.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310</id>
	<title>Re:encryption alone</title>
	<author>Anonymous</author>
	<datestamp>1263837240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>is not the whole solution.</p></div><p>This.</p><p>I'm fairly certain Blizzard uses some kind of encryption on their database.  Probably doesn't send passwords in cleartext.  But accounts still get compromised left and right.  Not because the encryption is failing, but because people set stupid passwords and share them with friends.</p><p>The same thing is true of banking websites, and PINs, and logins to the corporate network, and whatever else.  The weakest link isn't whether your data/authentication/network/connection/whatever is encrypted...  The weakest link is the person sitting in front of the terminal.  And as long as you've got users who'll click on random executables and use their kid's name as a password and share their credentials with someone else, encryption isn't really going to get you very far.</p><p>Sure, it'd help...  It'd be another layer of protection.  Another bit of security.  I'm not saying that people <i>shouldn't</i> use encryption...  But when you're looking at where to spend money, and what effort is going to get you the most impact, encryption isn't necessarily it.</p></div>
	</htmltext>
<tokenext>is not the whole solution.This.I 'm fairly certain Blizzard uses some kind of encryption on their database .
Probably does n't send passwords in cleartext .
But accounts still get compromised left and right .
Not because the encryption is failing , but because people set stupid passwords and share them with friends.The same thing is true of banking websites , and PINs , and logins to the corporate network , and whatever else .
The weakest link is n't whether your data/authentication/network/connection/whatever is encrypted... The weakest link is the person sitting in front of the terminal .
And as long as you 've got users who 'll click on random executables and use their kid 's name as a password and share their credentials with someone else , encryption is n't really going to get you very far.Sure , it 'd help... It 'd be another layer of protection .
Another bit of security .
I 'm not saying that people should n't use encryption... But when you 're looking at where to spend money , and what effort is going to get you the most impact , encryption is n't necessarily it .</tokentext>
<sentencetext>is not the whole solution.This.I'm fairly certain Blizzard uses some kind of encryption on their database.
Probably doesn't send passwords in cleartext.
But accounts still get compromised left and right.
Not because the encryption is failing, but because people set stupid passwords and share them with friends.The same thing is true of banking websites, and PINs, and logins to the corporate network, and whatever else.
The weakest link isn't whether your data/authentication/network/connection/whatever is encrypted...  The weakest link is the person sitting in front of the terminal.
And as long as you've got users who'll click on random executables and use their kid's name as a password and share their credentials with someone else, encryption isn't really going to get you very far.Sure, it'd help...  It'd be another layer of protection.
Another bit of security.
I'm not saying that people shouldn't use encryption...  But when you're looking at where to spend money, and what effort is going to get you the most impact, encryption isn't necessarily it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815960</id>
	<title>Macs</title>
	<author>Anonymous</author>
	<datestamp>1263833880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>A not so computer-literate user just pleaded me to allow unencrypted FTP because in order to use SFTP on a Mac:</p><blockquote><div><p>For Mac OS X, you'll need to take an extra step and install the "putty" package.  Honestly, it's a huge install (1 GB+) which will take about half an hour to do (or more if you need to download Xcode).  Unfortunately, there isn't an easier way to do this on a Mac.  Anyway, here are the steps to follow:</p><p>
&nbsp; 1. Install the Xcode 3.0 Developer Tools found on your Apple's Install Disc in the "Optional Installs" folder (Optional Installs-&gt;Xcode Tools-&gt;XcodeTools.mpkg) or at https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=19897  (beware: it's a 1 GB download)<br>
&nbsp; 2. Then you need to install MacPorts: http://www.macports.org/install.php<br>
&nbsp; 3. Open up a Terminal (Applications-&gt;Utilities-&gt;Terminal)<br>
&nbsp; 4. At the prompt type: sudo port install putty<br>
&nbsp; 5. (you may be asked for a password)<br>
&nbsp; 6. Voila!</p></div> </blockquote><p>I can't fucking believe it. How can an FTP program come without SFTP support? How can PuTTY be 1 gig? The PuTTY that came with my WinSCP is 1.4 megs big.</p></div>
	</htmltext>
<tokenext>A not so computer-literate user just pleaded me to allow unencrypted FTP because in order to use SFTP on a Mac : For Mac OS X , you 'll need to take an extra step and install the " putty " package .
Honestly , it 's a huge install ( 1 GB + ) which will take about half an hour to do ( or more if you need to download Xcode ) .
Unfortunately , there is n't an easier way to do this on a Mac .
Anyway , here are the steps to follow :   1 .
Install the Xcode 3.0 Developer Tools found on your Apple 's Install Disc in the " Optional Installs " folder ( Optional Installs- &gt; Xcode Tools- &gt; XcodeTools.mpkg ) or at https : //connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware ? bundleID = 19897 ( beware : it 's a 1 GB download )   2 .
Then you need to install MacPorts : http : //www.macports.org/install.php   3 .
Open up a Terminal ( Applications- &gt; Utilities- &gt; Terminal )   4 .
At the prompt type : sudo port install putty   5 .
( you may be asked for a password )   6 .
Voila ! I ca n't fucking believe it .
How can an FTP program come without SFTP support ?
How can PuTTY be 1 gig ?
The PuTTY that came with my WinSCP is 1.4 megs big .</tokentext>
<sentencetext>A not so computer-literate user just pleaded me to allow unencrypted FTP because in order to use SFTP on a Mac:For Mac OS X, you'll need to take an extra step and install the "putty" package.
Honestly, it's a huge install (1 GB+) which will take about half an hour to do (or more if you need to download Xcode).
Unfortunately, there isn't an easier way to do this on a Mac.
Anyway, here are the steps to follow:
  1.
Install the Xcode 3.0 Developer Tools found on your Apple's Install Disc in the "Optional Installs" folder (Optional Installs-&gt;Xcode Tools-&gt;XcodeTools.mpkg) or at https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=19897  (beware: it's a 1 GB download)
  2.
Then you need to install MacPorts: http://www.macports.org/install.php
  3.
Open up a Terminal (Applications-&gt;Utilities-&gt;Terminal)
  4.
At the prompt type: sudo port install putty
  5.
(you may be asked for a password)
  6.
Voila! I can't fucking believe it.
How can an FTP program come without SFTP support?
How can PuTTY be 1 gig?
The PuTTY that came with my WinSCP is 1.4 megs big.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813690</id>
	<title>Training, Where to get trained on using PKI?</title>
	<author>Anonymous</author>
	<datestamp>1263814680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Where can an IT professional get training for using encryption tools?  We need to have more training for the realities we face on the Internet. I've been writing interface scripts for banking interactions for a long time, and have only recently seen banks offer some level of encryption. Ideally, we should leverage IP restrictions as well. There should be both in place for any secure transaction.  IP restrictions and some level of object encryption and/or session encryption.  How can data be safe otherwise? -JW</p></htmltext>
<tokenext>Where can an IT professional get training for using encryption tools ?
We need to have more training for the realities we face on the Internet .
I 've been writing interface scripts for banking interactions for a long time , and have only recently seen banks offer some level of encryption .
Ideally , we should leverage IP restrictions as well .
There should be both in place for any secure transaction .
IP restrictions and some level of object encryption and/or session encryption .
How can data be safe otherwise ?
-JW</tokentext>
<sentencetext>Where can an IT professional get training for using encryption tools?
We need to have more training for the realities we face on the Internet.
I've been writing interface scripts for banking interactions for a long time, and have only recently seen banks offer some level of encryption.
Ideally, we should leverage IP restrictions as well.
There should be both in place for any secure transaction.
IP restrictions and some level of object encryption and/or session encryption.
How can data be safe otherwise?
-JW</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808798</id>
	<title>Lack of time.</title>
	<author>Smoky D. Bear</author>
	<datestamp>1263835080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A lack of time to implement it/management changing priorities... again.

I would love to and I had thought that I had convinced management why we needed to (Nothing fancy, just ssl on parts of our web page). Then something blew up. Then something else blew up... and it just wasn't that important to management any more.</htmltext>
<tokenext>A lack of time to implement it/management changing priorities... again . I would love to and I had thought that I had convinced management why we needed to ( Nothing fancy , just ssl on parts of our web page ) .
Then something blew up .
Then something else blew up... and it just was n't that important to management any more .</tokentext>
<sentencetext>A lack of time to implement it/management changing priorities... again.

I would love to and I had thought that I had convinced management why we needed to (Nothing fancy, just ssl on parts of our web page).
Then something blew up.
Then something else blew up... and it just wasn't that important to management any more.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810278</id>
	<title>Encryption export rules</title>
	<author>Antique Geekmeister</author>
	<datestamp>1263841500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In the USA, there are nasty regulations on the export of encryption, which been included under the Arms Export Control Act (http://en.wikipedia.org/wiki/Arms\_Export\_Control\_Act). This law has been extended and manipulated in unconstitutional ways: this used to be done as regulations under the Customs department, but were found to be unconstitutional there, and were transferred to the Commerce department, where they've been made somewhat more sane in the last decade but remain burdensome to software authors.</p><p>These regulations are not directly controlled by Congress, they're authorized by the Arms Export Control Act, so what is actually in them is confusing and serves the goals of the current administration, not Congress. It seems clear that whether the regulations are designed only to preserve the ability to eavesdrop on foreign communications, their direct effect is to protect the ability to eavesdrop on almost all civilian communications.</p><p>The case of Phil. Zimmerman, the author of PGP, being convicted of exporting weapons under this act simply illustrates the point. PGP could have been released for general use 10 years earlier, and incorporated in every email client in the world as a matter of course, if it were not for this regulation. DES suffered similar regulatory problems in the 1980's, and SSL suffered them in the 1990's and still suffers them.</p></htmltext>
<tokenext>In the USA , there are nasty regulations on the export of encryption , which been included under the Arms Export Control Act ( http : //en.wikipedia.org/wiki/Arms \ _Export \ _Control \ _Act ) .
This law has been extended and manipulated in unconstitutional ways : this used to be done as regulations under the Customs department , but were found to be unconstitutional there , and were transferred to the Commerce department , where they 've been made somewhat more sane in the last decade but remain burdensome to software authors.These regulations are not directly controlled by Congress , they 're authorized by the Arms Export Control Act , so what is actually in them is confusing and serves the goals of the current administration , not Congress .
It seems clear that whether the regulations are designed only to preserve the ability to eavesdrop on foreign communications , their direct effect is to protect the ability to eavesdrop on almost all civilian communications.The case of Phil .
Zimmerman , the author of PGP , being convicted of exporting weapons under this act simply illustrates the point .
PGP could have been released for general use 10 years earlier , and incorporated in every email client in the world as a matter of course , if it were not for this regulation .
DES suffered similar regulatory problems in the 1980 's , and SSL suffered them in the 1990 's and still suffers them .</tokentext>
<sentencetext>In the USA, there are nasty regulations on the export of encryption, which been included under the Arms Export Control Act (http://en.wikipedia.org/wiki/Arms\_Export\_Control\_Act).
This law has been extended and manipulated in unconstitutional ways: this used to be done as regulations under the Customs department, but were found to be unconstitutional there, and were transferred to the Commerce department, where they've been made somewhat more sane in the last decade but remain burdensome to software authors.These regulations are not directly controlled by Congress, they're authorized by the Arms Export Control Act, so what is actually in them is confusing and serves the goals of the current administration, not Congress.
It seems clear that whether the regulations are designed only to preserve the ability to eavesdrop on foreign communications, their direct effect is to protect the ability to eavesdrop on almost all civilian communications.The case of Phil.
Zimmerman, the author of PGP, being convicted of exporting weapons under this act simply illustrates the point.
PGP could have been released for general use 10 years earlier, and incorporated in every email client in the world as a matter of course, if it were not for this regulation.
DES suffered similar regulatory problems in the 1980's, and SSL suffered them in the 1990's and still suffers them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813190</id>
	<title>It looks like app UIs may be biggest barrier</title>
	<author>Sloppy</author>
	<datestamp>1263812220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>After various arguments where I propose that unauthenticated encryption is superior to plaintext, I'm left with the sense that some users (whether it's a lot of them or just a few, I don't know) conflate encryption with the nebulous word "secure."  There are applications still in use today, which confuse users into thinking that if the communications are encrypted, then no one can listen in.  (Either that, or there are people out there mis-training users into thinking that's what the apps are telling them.)</p><p>And if that indeed is the case, then some well-meaning people don't want to deploy encryption without authentication, because they feel that it could trick the user.  So those defective apps are making your question <em>become</em> "what is holding back authentication?"  And that's a whole other problem.</p><p>If we don't want to accept that encryption must come <em>after</em> authentication on everyone's todo list, then we need to repair those user interfaces (e.g. get rid of the padlock icon that is displayed when encryption is used).</p></htmltext>
<tokenext>After various arguments where I propose that unauthenticated encryption is superior to plaintext , I 'm left with the sense that some users ( whether it 's a lot of them or just a few , I do n't know ) conflate encryption with the nebulous word " secure .
" There are applications still in use today , which confuse users into thinking that if the communications are encrypted , then no one can listen in .
( Either that , or there are people out there mis-training users into thinking that 's what the apps are telling them .
) And if that indeed is the case , then some well-meaning people do n't want to deploy encryption without authentication , because they feel that it could trick the user .
So those defective apps are making your question become " what is holding back authentication ?
" And that 's a whole other problem.If we do n't want to accept that encryption must come after authentication on everyone 's todo list , then we need to repair those user interfaces ( e.g .
get rid of the padlock icon that is displayed when encryption is used ) .</tokentext>
<sentencetext>After various arguments where I propose that unauthenticated encryption is superior to plaintext, I'm left with the sense that some users (whether it's a lot of them or just a few, I don't know) conflate encryption with the nebulous word "secure.
"  There are applications still in use today, which confuse users into thinking that if the communications are encrypted, then no one can listen in.
(Either that, or there are people out there mis-training users into thinking that's what the apps are telling them.
)And if that indeed is the case, then some well-meaning people don't want to deploy encryption without authentication, because they feel that it could trick the user.
So those defective apps are making your question become "what is holding back authentication?
"  And that's a whole other problem.If we don't want to accept that encryption must come after authentication on everyone's todo list, then we need to repair those user interfaces (e.g.
get rid of the padlock icon that is displayed when encryption is used).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30819026</id>
	<title>DNSSEC does *not* do encryption.</title>
	<author>hardaker</author>
	<datestamp>1263915720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>DNSSEC does data authentication and has never strived to do encryption.  Ok, NSEC3 added hashes of names to the negative answers so you couldn't walk the domains, but that still isn't encryption.  The only thing DNSSEC adds to the DNS data is signatures and hashes on existing data.
<p>
Now, having said that, DNSSEC does let you securely look up SSH fingerprints, X509 keys, etc from DNS data so that you can do key bootstapping.  There is even a patch to openssh to automatically accept a key if it matches a fingerprint that was securely retrieved using DNSSEC.</p></htmltext>
<tokenext>DNSSEC does data authentication and has never strived to do encryption .
Ok , NSEC3 added hashes of names to the negative answers so you could n't walk the domains , but that still is n't encryption .
The only thing DNSSEC adds to the DNS data is signatures and hashes on existing data .
Now , having said that , DNSSEC does let you securely look up SSH fingerprints , X509 keys , etc from DNS data so that you can do key bootstapping .
There is even a patch to openssh to automatically accept a key if it matches a fingerprint that was securely retrieved using DNSSEC .</tokentext>
<sentencetext>DNSSEC does data authentication and has never strived to do encryption.
Ok, NSEC3 added hashes of names to the negative answers so you couldn't walk the domains, but that still isn't encryption.
The only thing DNSSEC adds to the DNS data is signatures and hashes on existing data.
Now, having said that, DNSSEC does let you securely look up SSH fingerprints, X509 keys, etc from DNS data so that you can do key bootstapping.
There is even a patch to openssh to automatically accept a key if it matches a fingerprint that was securely retrieved using DNSSEC.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809044</id>
	<title>Re:Apathy</title>
	<author>tsalmark</author>
	<datestamp>1263836220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Telnet and Rsh are effectively dead.
FTP is used primarily on cheap hosting and drop boxes.
HTTP is encrypted where it is taken to count - Banking and such.
POP IMAP are being encrypted by more and more Large ISP's.
Some issues that are solable by encryption are solved otherways (routing and firewalls)
Everything can be encrypted but most does not need to be.</htmltext>
<tokenext>Telnet and Rsh are effectively dead .
FTP is used primarily on cheap hosting and drop boxes .
HTTP is encrypted where it is taken to count - Banking and such .
POP IMAP are being encrypted by more and more Large ISP 's .
Some issues that are solable by encryption are solved otherways ( routing and firewalls ) Everything can be encrypted but most does not need to be .</tokentext>
<sentencetext>Telnet and Rsh are effectively dead.
FTP is used primarily on cheap hosting and drop boxes.
HTTP is encrypted where it is taken to count - Banking and such.
POP IMAP are being encrypted by more and more Large ISP's.
Some issues that are solable by encryption are solved otherways (routing and firewalls)
Everything can be encrypted but most does not need to be.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813290</id>
	<title>Re:I can only answer for myself</title>
	<author>diitante</author>
	<datestamp>1263812760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>1. Your right to privace needd to be exercised or it will atrophe. Use it our loose it regardless of your need to hide something.

2. That piece of paper WILL be found with the proper effort exerted. Strongly encrypted files will NOT be read, no matter the effort. Learn yourself how to use some encryption tools.

3. It could happen if your not careful. Be careful and keep a copy of your keys in an alternate safe place.

4. Very. Backup, you should be doing it anyway.

5. You mentioned 2 of the most respected tools. Start there. Start anywhere, just start. Its important.

Cheers and good luck.

M</htmltext>
<tokenext>1 .
Your right to privace needd to be exercised or it will atrophe .
Use it our loose it regardless of your need to hide something .
2. That piece of paper WILL be found with the proper effort exerted .
Strongly encrypted files will NOT be read , no matter the effort .
Learn yourself how to use some encryption tools .
3. It could happen if your not careful .
Be careful and keep a copy of your keys in an alternate safe place .
4. Very .
Backup , you should be doing it anyway .
5. You mentioned 2 of the most respected tools .
Start there .
Start anywhere , just start .
Its important .
Cheers and good luck .
M</tokentext>
<sentencetext>1.
Your right to privace needd to be exercised or it will atrophe.
Use it our loose it regardless of your need to hide something.
2. That piece of paper WILL be found with the proper effort exerted.
Strongly encrypted files will NOT be read, no matter the effort.
Learn yourself how to use some encryption tools.
3. It could happen if your not careful.
Be careful and keep a copy of your keys in an alternate safe place.
4. Very.
Backup, you should be doing it anyway.
5. You mentioned 2 of the most respected tools.
Start there.
Start anywhere, just start.
Its important.
Cheers and good luck.
M</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809542</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810218</id>
	<title>managers</title>
	<author>Tom</author>
	<datestamp>1263841200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>You asked a simple question, you deserve a simple answer: Managers.</p><p>Over my years in IT, I have seen too many decisions being made by people who haven't updated their IT knowledge for 10 years or so. People who think that "FTP" doesn't stand for "Fuck This Protocol" and to whom SSH is "this new encrypted remote login tool". In addition, crypto is inherently difficult to understand, and a <b>lot</b> (I can't emphasize that enough) managers simply don't support anything they don't understand.</p><p>Cisco had the right idea of VPNs and making the whole encryption "thingy" become invisible. Unfortunately, that too required some managers to make decisions.</p><p>The only places I've ever seen where encryption is used a) consistently and b) well is where someone very high up understood at least enough about the issue to roll out a general policy or put a security officer in place and gave him authority over such decisions. And then proceeded to fire at least one high-ranking middle-management idiot for violating the policy.</p></htmltext>
<tokenext>You asked a simple question , you deserve a simple answer : Managers.Over my years in IT , I have seen too many decisions being made by people who have n't updated their IT knowledge for 10 years or so .
People who think that " FTP " does n't stand for " Fuck This Protocol " and to whom SSH is " this new encrypted remote login tool " .
In addition , crypto is inherently difficult to understand , and a lot ( I ca n't emphasize that enough ) managers simply do n't support anything they do n't understand.Cisco had the right idea of VPNs and making the whole encryption " thingy " become invisible .
Unfortunately , that too required some managers to make decisions.The only places I 've ever seen where encryption is used a ) consistently and b ) well is where someone very high up understood at least enough about the issue to roll out a general policy or put a security officer in place and gave him authority over such decisions .
And then proceeded to fire at least one high-ranking middle-management idiot for violating the policy .</tokentext>
<sentencetext>You asked a simple question, you deserve a simple answer: Managers.Over my years in IT, I have seen too many decisions being made by people who haven't updated their IT knowledge for 10 years or so.
People who think that "FTP" doesn't stand for "Fuck This Protocol" and to whom SSH is "this new encrypted remote login tool".
In addition, crypto is inherently difficult to understand, and a lot (I can't emphasize that enough) managers simply don't support anything they don't understand.Cisco had the right idea of VPNs and making the whole encryption "thingy" become invisible.
Unfortunately, that too required some managers to make decisions.The only places I've ever seen where encryption is used a) consistently and b) well is where someone very high up understood at least enough about the issue to roll out a general policy or put a security officer in place and gave him authority over such decisions.
And then proceeded to fire at least one high-ranking middle-management idiot for violating the policy.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809358</id>
	<title>Re:More direct costs.</title>
	<author>Anonymous</author>
	<datestamp>1263837420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Not to mention a self signed certificate brings out some pretty frightening prompts (I'm looking at you Firefox)</p></htmltext>
<tokenext>Not to mention a self signed certificate brings out some pretty frightening prompts ( I 'm looking at you Firefox )</tokentext>
<sentencetext>Not to mention a self signed certificate brings out some pretty frightening prompts (I'm looking at you Firefox)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811730</id>
	<title>Re:Apathy</title>
	<author>westlake</author>
	<datestamp>1263805320000</datestamp>
	<modclass>Troll</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>It's like personal home protection for many people - they don't want a gun in the house until after they've been robbed the first time</i> </p><p>Understanding the problem correctly is the first step to a solution.</p><p>You don't want a gun in the house.</p><p> You want to ward off an intruder without a confrontation.</p><p>The armed encounter is damned unpredictable. You don't know when it will happen or who will have to face it.</p><p>Maybe your ten year old kid <b>can</b> pull it off.</p><p> But you might come home to find her dead.</p></htmltext>
<tokenext>It 's like personal home protection for many people - they do n't want a gun in the house until after they 've been robbed the first time Understanding the problem correctly is the first step to a solution.You do n't want a gun in the house .
You want to ward off an intruder without a confrontation.The armed encounter is damned unpredictable .
You do n't know when it will happen or who will have to face it.Maybe your ten year old kid can pull it off .
But you might come home to find her dead .</tokentext>
<sentencetext>It's like personal home protection for many people - they don't want a gun in the house until after they've been robbed the first time Understanding the problem correctly is the first step to a solution.You don't want a gun in the house.
You want to ward off an intruder without a confrontation.The armed encounter is damned unpredictable.
You don't know when it will happen or who will have to face it.Maybe your ten year old kid can pull it off.
But you might come home to find her dead.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808908</id>
	<title>The same reason router passwords are Admin.</title>
	<author>GiveBenADollar</author>
	<datestamp>1263835560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>People are lazy. I know I am! If It doesn't need encryption, why encrypt it?

Then again I have the root password on my linux box set to a single character, so maybe I'm too lazy.</htmltext>
<tokenext>People are lazy .
I know I am !
If It does n't need encryption , why encrypt it ?
Then again I have the root password on my linux box set to a single character , so maybe I 'm too lazy .</tokentext>
<sentencetext>People are lazy.
I know I am!
If It doesn't need encryption, why encrypt it?
Then again I have the root password on my linux box set to a single character, so maybe I'm too lazy.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809410</id>
	<title>What about cost?</title>
	<author>opus\_magnum</author>
	<datestamp>1263837660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I don't have figures handy, but I assume encryption would "waste" a sizable amount of computing power, for no apparent benefit.</htmltext>
<tokenext>I do n't have figures handy , but I assume encryption would " waste " a sizable amount of computing power , for no apparent benefit .</tokentext>
<sentencetext>I don't have figures handy, but I assume encryption would "waste" a sizable amount of computing power, for no apparent benefit.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812236</id>
	<title>Complexity Interferes with Work</title>
	<author>stewbacca</author>
	<datestamp>1263807540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The reason this stuff isn't taking off is because the complexity of a certificate gets in the way of work for most non-technical people. My VeriSign digital signature, for example, took a lot of futzing around with to get working (not to mention costing $100+ to my company) with little to no perceivable value to the end-user.</p><p>Self-important people (like my boss) don't have time to be goofing around with their computers to make their security certificates and digital signatures work correctly.</p><p>When a boss can't access a certain site or submit a particular proposal because The Computer won't let him, then the boss insists that all these security features just go away.</p></htmltext>
<tokenext>The reason this stuff is n't taking off is because the complexity of a certificate gets in the way of work for most non-technical people .
My VeriSign digital signature , for example , took a lot of futzing around with to get working ( not to mention costing $ 100 + to my company ) with little to no perceivable value to the end-user.Self-important people ( like my boss ) do n't have time to be goofing around with their computers to make their security certificates and digital signatures work correctly.When a boss ca n't access a certain site or submit a particular proposal because The Computer wo n't let him , then the boss insists that all these security features just go away .</tokentext>
<sentencetext>The reason this stuff isn't taking off is because the complexity of a certificate gets in the way of work for most non-technical people.
My VeriSign digital signature, for example, took a lot of futzing around with to get working (not to mention costing $100+ to my company) with little to no perceivable value to the end-user.Self-important people (like my boss) don't have time to be goofing around with their computers to make their security certificates and digital signatures work correctly.When a boss can't access a certain site or submit a particular proposal because The Computer won't let him, then the boss insists that all these security features just go away.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811084</id>
	<title>I don't see the value either</title>
	<author>Anonymous</author>
	<datestamp>1263845580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What real attacks does HTTPS with a self-signed cert protect against?</p><p>The first time I visit your website, it provides no protection at all against a MITM (Man In The Middle) attack.<br>If the browser caches the cert, then it provides protection the second time I visit your site.  However, if you then change your cert for any reason I'll get a bogus security warning.  And that's the exact same security warning I'd get if there was a MITM attack, so how do I tell the difference?</p><p>Now I suspect you're thinking of passive evesdropping... that's such an old-fashioned attack.  Modern networks are switched.  So almost any scenario where I can evesdrop, I can also MITM.  Even if you're using an unencrypted WiFi access, I can just set up my own base station and arrange for you to connect to it.</p></htmltext>
<tokenext>What real attacks does HTTPS with a self-signed cert protect against ? The first time I visit your website , it provides no protection at all against a MITM ( Man In The Middle ) attack.If the browser caches the cert , then it provides protection the second time I visit your site .
However , if you then change your cert for any reason I 'll get a bogus security warning .
And that 's the exact same security warning I 'd get if there was a MITM attack , so how do I tell the difference ? Now I suspect you 're thinking of passive evesdropping... that 's such an old-fashioned attack .
Modern networks are switched .
So almost any scenario where I can evesdrop , I can also MITM .
Even if you 're using an unencrypted WiFi access , I can just set up my own base station and arrange for you to connect to it .</tokentext>
<sentencetext>What real attacks does HTTPS with a self-signed cert protect against?The first time I visit your website, it provides no protection at all against a MITM (Man In The Middle) attack.If the browser caches the cert, then it provides protection the second time I visit your site.
However, if you then change your cert for any reason I'll get a bogus security warning.
And that's the exact same security warning I'd get if there was a MITM attack, so how do I tell the difference?Now I suspect you're thinking of passive evesdropping... that's such an old-fashioned attack.
Modern networks are switched.
So almost any scenario where I can evesdrop, I can also MITM.
Even if you're using an unencrypted WiFi access, I can just set up my own base station and arrange for you to connect to it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808974</id>
	<title>What's the problem?</title>
	<author>spaceyhackerlady</author>
	<datestamp>1263835860000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>What problem do we need to solve here? If it ain't broke...

</p><p>Just for the hell of it I've toyed with hooking my geiger counter up to my computer, generating a couple of DVDs full of random numbers
(<em>really</em> random) and using them for one-time pad
encryption to send email to my Mom. Which cannot be cracked, by anybody.

</p><p>There is also the issue that if you lock things down too tight you risk locking yourself
out and can't get back in.

</p><p>...laura</p></htmltext>
<tokenext>What problem do we need to solve here ?
If it ai n't broke.. . Just for the hell of it I 've toyed with hooking my geiger counter up to my computer , generating a couple of DVDs full of random numbers ( really random ) and using them for one-time pad encryption to send email to my Mom .
Which can not be cracked , by anybody .
There is also the issue that if you lock things down too tight you risk locking yourself out and ca n't get back in .
...laura</tokentext>
<sentencetext>What problem do we need to solve here?
If it ain't broke...

Just for the hell of it I've toyed with hooking my geiger counter up to my computer, generating a couple of DVDs full of random numbers
(really random) and using them for one-time pad
encryption to send email to my Mom.
Which cannot be cracked, by anybody.
There is also the issue that if you lock things down too tight you risk locking yourself
out and can't get back in.
...laura</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812302</id>
	<title>Re:Costs?</title>
	<author>stewbacca</author>
	<datestamp>1263807780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The iPhone doesn't do secure email because not enough people want that feature, not because Apple can't do it, or because Apple thinks they know better than you or I (which is the expected response to this post).</p></htmltext>
<tokenext>The iPhone does n't do secure email because not enough people want that feature , not because Apple ca n't do it , or because Apple thinks they know better than you or I ( which is the expected response to this post ) .</tokentext>
<sentencetext>The iPhone doesn't do secure email because not enough people want that feature, not because Apple can't do it, or because Apple thinks they know better than you or I (which is the expected response to this post).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810376</id>
	<title>Re:Because it's a PITA - Pain In the Ass!</title>
	<author>Anonymous</author>
	<datestamp>1263842040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>I didn't think so.</i> </p><p>When will you pompous sons of bitches quit assuming you know the answer to be given by anyone who reads your sanctimonious bullshit? That whole trope has gotten to be trite enough to make sensible people puke when they see it.</p><p>Fucking arrogant assholes.</p></htmltext>
<tokenext>I did n't think so .
When will you pompous sons of bitches quit assuming you know the answer to be given by anyone who reads your sanctimonious bullshit ?
That whole trope has gotten to be trite enough to make sensible people puke when they see it.Fucking arrogant assholes .</tokentext>
<sentencetext>I didn't think so.
When will you pompous sons of bitches quit assuming you know the answer to be given by anyone who reads your sanctimonious bullshit?
That whole trope has gotten to be trite enough to make sensible people puke when they see it.Fucking arrogant assholes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808928</id>
	<title>What good is encryption?</title>
	<author>Anonymous</author>
	<datestamp>1263835620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If Chloe can break it at CTU in a couple of keystrokes? DAMN IT!!</p></htmltext>
<tokenext>If Chloe can break it at CTU in a couple of keystrokes ?
DAMN IT !
!</tokentext>
<sentencetext>If Chloe can break it at CTU in a couple of keystrokes?
DAMN IT!
!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809178</id>
	<title>Most Data Isn't Worth Encrypting</title>
	<author>InitZero</author>
	<datestamp>1263836640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Most data traveling in the clear has little value. What value it has may be momentary. A week from now, it is worthless.</p><p>Heck, most encrypted data has little value. The fact of the matter is most data is worthless junk.</p><p>I was the backup administrator for a Fortune 500 company's branch office of 1,500 users. I have a pretty good idea of what data existed because I was responsible for keeping it safe. Of the terabytes upon terabytes of data sitting in the archive, I could have put the worth-encrypting sensitive company information on a USB thumb-drive. There was really that little of it floating around.</p><p>So, the reason most data isn't encrypted is that there really is no reason for its encryption.</p><p>Cheers,<br>Matt</p></htmltext>
<tokenext>Most data traveling in the clear has little value .
What value it has may be momentary .
A week from now , it is worthless.Heck , most encrypted data has little value .
The fact of the matter is most data is worthless junk.I was the backup administrator for a Fortune 500 company 's branch office of 1,500 users .
I have a pretty good idea of what data existed because I was responsible for keeping it safe .
Of the terabytes upon terabytes of data sitting in the archive , I could have put the worth-encrypting sensitive company information on a USB thumb-drive .
There was really that little of it floating around.So , the reason most data is n't encrypted is that there really is no reason for its encryption.Cheers,Matt</tokentext>
<sentencetext>Most data traveling in the clear has little value.
What value it has may be momentary.
A week from now, it is worthless.Heck, most encrypted data has little value.
The fact of the matter is most data is worthless junk.I was the backup administrator for a Fortune 500 company's branch office of 1,500 users.
I have a pretty good idea of what data existed because I was responsible for keeping it safe.
Of the terabytes upon terabytes of data sitting in the archive, I could have put the worth-encrypting sensitive company information on a USB thumb-drive.
There was really that little of it floating around.So, the reason most data isn't encrypted is that there really is no reason for its encryption.Cheers,Matt</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810676</id>
	<title>Re:encryption alone</title>
	<author>interploy</author>
	<datestamp>1263843420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Too bad you can't fix stupid.</htmltext>
<tokenext>Too bad you ca n't fix stupid .</tokentext>
<sentencetext>Too bad you can't fix stupid.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813502</id>
	<title>Re:encryption alone</title>
	<author>shmlco</author>
	<datestamp>1263813780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"If you make the age requirement too short, then nobody can remember their passwords. So they start working around it...."</p><p>One company I know of had an employee send around a "helpful" email saying pick a password, then just add the month/year to it. As in "password 01/10". Solves the special character and number requirements too. Next month when it expires use the same password and just bump the month.</p><p>Got back a ton of "great idea" responses. So now everyone is using xxxx mm/yy formatted passwords... and everyone there knows it.</p></htmltext>
<tokenext>" If you make the age requirement too short , then nobody can remember their passwords .
So they start working around it.... " One company I know of had an employee send around a " helpful " email saying pick a password , then just add the month/year to it .
As in " password 01/10 " .
Solves the special character and number requirements too .
Next month when it expires use the same password and just bump the month.Got back a ton of " great idea " responses .
So now everyone is using xxxx mm/yy formatted passwords... and everyone there knows it .</tokentext>
<sentencetext>"If you make the age requirement too short, then nobody can remember their passwords.
So they start working around it...."One company I know of had an employee send around a "helpful" email saying pick a password, then just add the month/year to it.
As in "password 01/10".
Solves the special character and number requirements too.
Next month when it expires use the same password and just bump the month.Got back a ton of "great idea" responses.
So now everyone is using xxxx mm/yy formatted passwords... and everyone there knows it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808900</id>
	<title>Potential problems</title>
	<author>Xamusk</author>
	<datestamp>1263835500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Because if anything goes wrong, like forgetting the password or corruption on a single byte, can make your whole data unusable</htmltext>
<tokenext>Because if anything goes wrong , like forgetting the password or corruption on a single byte , can make your whole data unusable</tokentext>
<sentencetext>Because if anything goes wrong, like forgetting the password or corruption on a single byte, can make your whole data unusable</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30823790</id>
	<title>Re:Because encryption is a bigger problem</title>
	<author>Abcd1234</author>
	<datestamp>1263892260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>You are more likely to lose your keys than your privacy</i></p><p>Yes, because it's so very tough to throw your<nobr> <wbr></nobr>.gnupg directory onto a CD and squirrel it away in your closet.</p><p>Please.</p></htmltext>
<tokenext>You are more likely to lose your keys than your privacyYes , because it 's so very tough to throw your .gnupg directory onto a CD and squirrel it away in your closet.Please .</tokentext>
<sentencetext>You are more likely to lose your keys than your privacyYes, because it's so very tough to throw your .gnupg directory onto a CD and squirrel it away in your closet.Please.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809422</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811194</id>
	<title>Because the help to get there is lacking</title>
	<author>Anonymous</author>
	<datestamp>1263846120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>As I see it, the problem is less with the technology, and more with providers' lack of steering users there:</p><p>1. While this is definitely better these days, in the past, it was common for POP3 tutorials from e-mail services, or FTP tutorials from hosting providers, to describe the unencrypted way of getting in - no doubt because it was the easiest way to get the customer what he wants, and least prone to errors. Many people who learned how to do what they're doing are probably not even aware their connection is unencrypted, or that they could, in fact encrypt it. And even if - they'd probably argue "What for? Why would anyone want to steal the password to <i>my</i> e-mail account?".<br>2. Redirects. It's a very simple thing: Automatically redirect users to the HTTPS version of websites. No user thinking involved - just set it up and let them enjoy the shiny padlock. Yes, the very large players do this automatically for logins, but the vast majority of small websites, e.g. mom and pop running an osCommerce installation, do not. The user enters through unencrypted HTTP, and proceeds to do what he wants unencryptedly. Had the server just redirected him to the secure site as he entered, he would do the exact same stuff, not having to waste a thought about security, and would still be secure.<br>3. Lastly, setup. I have a small VPS, and I, in fact, recently tried to set up SSL security for the sites I host. I can't. At least not within a reasonable threshold of effort. Why? Because SSL <i>sucks</i> to set up for virtual hosts. The only thing I could easily do is set up one certificate per IP, and I only have one shared IP for all accounts. Add to that Mozilla's oh-so-brilliant decision to auto-block self-signed certificates, and you end up in a situation where many smaller and non-corporate admins would <i>like</i> to employ secure connections, but they <i>can't</i>, because the setup is needlessly complicated, the easy ways to do it are being blocked, and basically the only way to actually get there is shell out more money.</p><p>The Mozilla team justified its decision to auto-block self-signed certificates with the fact that one can get "real" certificates for free from <a href="https://www.startssl.com/" title="startssl.com" rel="nofollow">StartSSL</a> [startssl.com]. Well, I went there. I tried. I utterly failed. Because having a free certificate for every domain doesn't mean jack shit if you can only deploy a single one - or would have to dig deep into the config for hours to get it working for all of them.<br>I mean, we're talking about a situation where it's easier to tell all users to whitelist an "invalid" (self-signed) certificate than to get real certificates working properly.<nobr> <wbr></nobr>...and that's all not taking into account that certificates expire, and once you committed to going "real", getting new certificates for all sites becomes a periodic task.</p><p>Summary: On principle, the technology works fine, but The Powers That Be are not using their powers to quietly encourage its adoption (e.g. by just not offering unencrypted FTP anymore, period), and those responsible for the technical side have created a system where it just <i>sucks</i> to offer encryption.</p><p>If the users are not encouraged to use encryption, and the admins are discouraged from offering it - how prevalent can it get, really?</p></htmltext>
<tokenext>As I see it , the problem is less with the technology , and more with providers ' lack of steering users there : 1 .
While this is definitely better these days , in the past , it was common for POP3 tutorials from e-mail services , or FTP tutorials from hosting providers , to describe the unencrypted way of getting in - no doubt because it was the easiest way to get the customer what he wants , and least prone to errors .
Many people who learned how to do what they 're doing are probably not even aware their connection is unencrypted , or that they could , in fact encrypt it .
And even if - they 'd probably argue " What for ?
Why would anyone want to steal the password to my e-mail account ? " .2 .
Redirects. It 's a very simple thing : Automatically redirect users to the HTTPS version of websites .
No user thinking involved - just set it up and let them enjoy the shiny padlock .
Yes , the very large players do this automatically for logins , but the vast majority of small websites , e.g .
mom and pop running an osCommerce installation , do not .
The user enters through unencrypted HTTP , and proceeds to do what he wants unencryptedly .
Had the server just redirected him to the secure site as he entered , he would do the exact same stuff , not having to waste a thought about security , and would still be secure.3 .
Lastly , setup .
I have a small VPS , and I , in fact , recently tried to set up SSL security for the sites I host .
I ca n't .
At least not within a reasonable threshold of effort .
Why ? Because SSL sucks to set up for virtual hosts .
The only thing I could easily do is set up one certificate per IP , and I only have one shared IP for all accounts .
Add to that Mozilla 's oh-so-brilliant decision to auto-block self-signed certificates , and you end up in a situation where many smaller and non-corporate admins would like to employ secure connections , but they ca n't , because the setup is needlessly complicated , the easy ways to do it are being blocked , and basically the only way to actually get there is shell out more money.The Mozilla team justified its decision to auto-block self-signed certificates with the fact that one can get " real " certificates for free from StartSSL [ startssl.com ] .
Well , I went there .
I tried .
I utterly failed .
Because having a free certificate for every domain does n't mean jack shit if you can only deploy a single one - or would have to dig deep into the config for hours to get it working for all of them.I mean , we 're talking about a situation where it 's easier to tell all users to whitelist an " invalid " ( self-signed ) certificate than to get real certificates working properly .
...and that 's all not taking into account that certificates expire , and once you committed to going " real " , getting new certificates for all sites becomes a periodic task.Summary : On principle , the technology works fine , but The Powers That Be are not using their powers to quietly encourage its adoption ( e.g .
by just not offering unencrypted FTP anymore , period ) , and those responsible for the technical side have created a system where it just sucks to offer encryption.If the users are not encouraged to use encryption , and the admins are discouraged from offering it - how prevalent can it get , really ?</tokentext>
<sentencetext>As I see it, the problem is less with the technology, and more with providers' lack of steering users there:1.
While this is definitely better these days, in the past, it was common for POP3 tutorials from e-mail services, or FTP tutorials from hosting providers, to describe the unencrypted way of getting in - no doubt because it was the easiest way to get the customer what he wants, and least prone to errors.
Many people who learned how to do what they're doing are probably not even aware their connection is unencrypted, or that they could, in fact encrypt it.
And even if - they'd probably argue "What for?
Why would anyone want to steal the password to my e-mail account?".2.
Redirects. It's a very simple thing: Automatically redirect users to the HTTPS version of websites.
No user thinking involved - just set it up and let them enjoy the shiny padlock.
Yes, the very large players do this automatically for logins, but the vast majority of small websites, e.g.
mom and pop running an osCommerce installation, do not.
The user enters through unencrypted HTTP, and proceeds to do what he wants unencryptedly.
Had the server just redirected him to the secure site as he entered, he would do the exact same stuff, not having to waste a thought about security, and would still be secure.3.
Lastly, setup.
I have a small VPS, and I, in fact, recently tried to set up SSL security for the sites I host.
I can't.
At least not within a reasonable threshold of effort.
Why? Because SSL sucks to set up for virtual hosts.
The only thing I could easily do is set up one certificate per IP, and I only have one shared IP for all accounts.
Add to that Mozilla's oh-so-brilliant decision to auto-block self-signed certificates, and you end up in a situation where many smaller and non-corporate admins would like to employ secure connections, but they can't, because the setup is needlessly complicated, the easy ways to do it are being blocked, and basically the only way to actually get there is shell out more money.The Mozilla team justified its decision to auto-block self-signed certificates with the fact that one can get "real" certificates for free from StartSSL [startssl.com].
Well, I went there.
I tried.
I utterly failed.
Because having a free certificate for every domain doesn't mean jack shit if you can only deploy a single one - or would have to dig deep into the config for hours to get it working for all of them.I mean, we're talking about a situation where it's easier to tell all users to whitelist an "invalid" (self-signed) certificate than to get real certificates working properly.
...and that's all not taking into account that certificates expire, and once you committed to going "real", getting new certificates for all sites becomes a periodic task.Summary: On principle, the technology works fine, but The Powers That Be are not using their powers to quietly encourage its adoption (e.g.
by just not offering unencrypted FTP anymore, period), and those responsible for the technical side have created a system where it just sucks to offer encryption.If the users are not encouraged to use encryption, and the admins are discouraged from offering it - how prevalent can it get, really?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808880</id>
	<title>Lack of Open, Accessible Standards</title>
	<author>Kr1ll1n</author>
	<datestamp>1263835440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Whole end-to-end environment encryption is currently a PITA to implement, use, and support. Fix these problems, and it will grow. And before anyone responds with, use X or Y product, think about this; the larger the environment, the less homogeneous it is. Think about product X and or Y in that scenario, and you will see the problem. Does Cisco use PGP or its open equiv? Nope. It uses its own stuff. So that means what is on X server is different than what is on X firewall and/or router. The absence of a strong open standard across platforms is what makes encryption the PITA it is for administrators.</htmltext>
<tokenext>Whole end-to-end environment encryption is currently a PITA to implement , use , and support .
Fix these problems , and it will grow .
And before anyone responds with , use X or Y product , think about this ; the larger the environment , the less homogeneous it is .
Think about product X and or Y in that scenario , and you will see the problem .
Does Cisco use PGP or its open equiv ?
Nope. It uses its own stuff .
So that means what is on X server is different than what is on X firewall and/or router .
The absence of a strong open standard across platforms is what makes encryption the PITA it is for administrators .</tokentext>
<sentencetext>Whole end-to-end environment encryption is currently a PITA to implement, use, and support.
Fix these problems, and it will grow.
And before anyone responds with, use X or Y product, think about this; the larger the environment, the less homogeneous it is.
Think about product X and or Y in that scenario, and you will see the problem.
Does Cisco use PGP or its open equiv?
Nope. It uses its own stuff.
So that means what is on X server is different than what is on X firewall and/or router.
The absence of a strong open standard across platforms is what makes encryption the PITA it is for administrators.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30819146</id>
	<title>Re:encryption alone</title>
	<author>Anonymous</author>
	<datestamp>1263916380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>FTP is a very efficient file transfer mechanism. It has a few common scenarios, such as distribution via anonymous FTP. This results in performance benefits over HTTP for low numbers of bulk file transfers. If you are using a username and password, the information is probably non-sensitive and the username is mainly for some kind of tracking metrics on the server. Another possibility is that the device is an embedded device and is never meant to be on the Internet at large (e.g. on a protected control network). Only recent technology advances have provided embedded devices a viable include encryption capability, and it is slowly rolling out.<br>As to HTTP, the bulk of that information is non-sensitive. Most of the business Internet HTTP access can be described as marketing and sales. You do not want to exclude people from that information. When something needs to be more secure, then HTTPS is used. Note that HTTPS does not inherently solve the security problem. It merely makes eavesdropping harder. Security at the end points themselves is still important. If it is not self-signed, then a third party needs to be compromised to go undetected. On the other hand, it assumes an attentive and security-aware user to know what is going on there.<br>For DNSSEC, it is really a horrible idea. To work, you need to get everyone who runs DNS to communicate to trade keys with the upper level server. This assumes that you are doing zone signing. This is work on two different organizations. This must be repeated pair-wise across the globe up to the root servers. Every update means a new signing and there should be a periodic change to the key, also. If you want to have individual records signed and verified, then you need every client on the Internet to cooperate. The amount of logistics required to do this quickly becomes fairly heavy considering that the information itself (the host name or IP address) is still not encrypted.<br>For encrypted Email to work, you will need to exchange keys with the recipient of your Email. The key exchange should not occur via Email. In a corporate environment, it is possible to assign all the required keys from a server. However, leaving that corporate network means that the keys must be exchanged. As to doing this with ease, WinZIP (for example) allows you to right click on any file or directory and select "Zip and Email Plus..." which allows a user to encrypt the ZIP file. There are dozens of similar tools. Today, such tools are more commonly used maliciously to bypass virus scanners. As such, many corporate Email servers strip such attachments. Signing Email would offer less security while being far easier to handle in most cases, but that requires the sender to register with a "well-known" certificate authority (for fee) or for the recipient to explicitly trust the certificate authority used. Both of these options require additional effort and cost and offer no significant security enhancement for non-sensitive Emails. The digital signing could be made obsolete by placing a phone call and asking talking about the Email contents. There is, however, significant movement on VoIP. Beyond the idea of simply creating an encrypted tunnel for the data, there is work being done to encrypt the calls being made.<br>The reality is that encryption is as complicated as it needs to be to get the job done. With the new two-factor authentication requirements from the payment card industry (PCI) starting to appear, things may improve. Perhaps we will see PKI certificates tied to your ATM or credit card for those transactions. We are already seeing laptops with card readers and/or fingerprint scanners built-in. We are also seeing whole hard drive encryption in software and also offered on hard drives themselves. Ultimately, however, security must strike a balance. If I laden technology with too much encryption, it is hard to configure and use and will cost more. Your microwave (I presume non-networked) really does not need to encrypt its database of power settings for the button presets with a user provided key.</p></htmltext>
<tokenext>FTP is a very efficient file transfer mechanism .
It has a few common scenarios , such as distribution via anonymous FTP .
This results in performance benefits over HTTP for low numbers of bulk file transfers .
If you are using a username and password , the information is probably non-sensitive and the username is mainly for some kind of tracking metrics on the server .
Another possibility is that the device is an embedded device and is never meant to be on the Internet at large ( e.g .
on a protected control network ) .
Only recent technology advances have provided embedded devices a viable include encryption capability , and it is slowly rolling out.As to HTTP , the bulk of that information is non-sensitive .
Most of the business Internet HTTP access can be described as marketing and sales .
You do not want to exclude people from that information .
When something needs to be more secure , then HTTPS is used .
Note that HTTPS does not inherently solve the security problem .
It merely makes eavesdropping harder .
Security at the end points themselves is still important .
If it is not self-signed , then a third party needs to be compromised to go undetected .
On the other hand , it assumes an attentive and security-aware user to know what is going on there.For DNSSEC , it is really a horrible idea .
To work , you need to get everyone who runs DNS to communicate to trade keys with the upper level server .
This assumes that you are doing zone signing .
This is work on two different organizations .
This must be repeated pair-wise across the globe up to the root servers .
Every update means a new signing and there should be a periodic change to the key , also .
If you want to have individual records signed and verified , then you need every client on the Internet to cooperate .
The amount of logistics required to do this quickly becomes fairly heavy considering that the information itself ( the host name or IP address ) is still not encrypted.For encrypted Email to work , you will need to exchange keys with the recipient of your Email .
The key exchange should not occur via Email .
In a corporate environment , it is possible to assign all the required keys from a server .
However , leaving that corporate network means that the keys must be exchanged .
As to doing this with ease , WinZIP ( for example ) allows you to right click on any file or directory and select " Zip and Email Plus... " which allows a user to encrypt the ZIP file .
There are dozens of similar tools .
Today , such tools are more commonly used maliciously to bypass virus scanners .
As such , many corporate Email servers strip such attachments .
Signing Email would offer less security while being far easier to handle in most cases , but that requires the sender to register with a " well-known " certificate authority ( for fee ) or for the recipient to explicitly trust the certificate authority used .
Both of these options require additional effort and cost and offer no significant security enhancement for non-sensitive Emails .
The digital signing could be made obsolete by placing a phone call and asking talking about the Email contents .
There is , however , significant movement on VoIP .
Beyond the idea of simply creating an encrypted tunnel for the data , there is work being done to encrypt the calls being made.The reality is that encryption is as complicated as it needs to be to get the job done .
With the new two-factor authentication requirements from the payment card industry ( PCI ) starting to appear , things may improve .
Perhaps we will see PKI certificates tied to your ATM or credit card for those transactions .
We are already seeing laptops with card readers and/or fingerprint scanners built-in .
We are also seeing whole hard drive encryption in software and also offered on hard drives themselves .
Ultimately , however , security must strike a balance .
If I laden technology with too much encryption , it is hard to configure and use and will cost more .
Your microwave ( I presume non-networked ) really does not need to encrypt its database of power settings for the button presets with a user provided key .</tokentext>
<sentencetext>FTP is a very efficient file transfer mechanism.
It has a few common scenarios, such as distribution via anonymous FTP.
This results in performance benefits over HTTP for low numbers of bulk file transfers.
If you are using a username and password, the information is probably non-sensitive and the username is mainly for some kind of tracking metrics on the server.
Another possibility is that the device is an embedded device and is never meant to be on the Internet at large (e.g.
on a protected control network).
Only recent technology advances have provided embedded devices a viable include encryption capability, and it is slowly rolling out.As to HTTP, the bulk of that information is non-sensitive.
Most of the business Internet HTTP access can be described as marketing and sales.
You do not want to exclude people from that information.
When something needs to be more secure, then HTTPS is used.
Note that HTTPS does not inherently solve the security problem.
It merely makes eavesdropping harder.
Security at the end points themselves is still important.
If it is not self-signed, then a third party needs to be compromised to go undetected.
On the other hand, it assumes an attentive and security-aware user to know what is going on there.For DNSSEC, it is really a horrible idea.
To work, you need to get everyone who runs DNS to communicate to trade keys with the upper level server.
This assumes that you are doing zone signing.
This is work on two different organizations.
This must be repeated pair-wise across the globe up to the root servers.
Every update means a new signing and there should be a periodic change to the key, also.
If you want to have individual records signed and verified, then you need every client on the Internet to cooperate.
The amount of logistics required to do this quickly becomes fairly heavy considering that the information itself (the host name or IP address) is still not encrypted.For encrypted Email to work, you will need to exchange keys with the recipient of your Email.
The key exchange should not occur via Email.
In a corporate environment, it is possible to assign all the required keys from a server.
However, leaving that corporate network means that the keys must be exchanged.
As to doing this with ease, WinZIP (for example) allows you to right click on any file or directory and select "Zip and Email Plus..." which allows a user to encrypt the ZIP file.
There are dozens of similar tools.
Today, such tools are more commonly used maliciously to bypass virus scanners.
As such, many corporate Email servers strip such attachments.
Signing Email would offer less security while being far easier to handle in most cases, but that requires the sender to register with a "well-known" certificate authority (for fee) or for the recipient to explicitly trust the certificate authority used.
Both of these options require additional effort and cost and offer no significant security enhancement for non-sensitive Emails.
The digital signing could be made obsolete by placing a phone call and asking talking about the Email contents.
There is, however, significant movement on VoIP.
Beyond the idea of simply creating an encrypted tunnel for the data, there is work being done to encrypt the calls being made.The reality is that encryption is as complicated as it needs to be to get the job done.
With the new two-factor authentication requirements from the payment card industry (PCI) starting to appear, things may improve.
Perhaps we will see PKI certificates tied to your ATM or credit card for those transactions.
We are already seeing laptops with card readers and/or fingerprint scanners built-in.
We are also seeing whole hard drive encryption in software and also offered on hard drives themselves.
Ultimately, however, security must strike a balance.
If I laden technology with too much encryption, it is hard to configure and use and will cost more.
Your microwave (I presume non-networked) really does not need to encrypt its database of power settings for the button presets with a user provided key.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812390</id>
	<title>Its not needed as badly as people thing</title>
	<author>gravis777</author>
	<datestamp>1263808200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What is the point of implementing something that is really not needed? When you are running secure stuff, SSH, SCP, VPN are used. Encrypting harddrives is overkill for the average person. What e-mails are we sending back and forth that is so sensitive it needs to be encrypted? If it is sensitive, most organizations have the approproate framework in place. I mean, why do I need to encrypt an e-mail to my fellow co-workers of the redneck joke of the day, or encrypt my browsing of Slashdot?</p></htmltext>
<tokenext>What is the point of implementing something that is really not needed ?
When you are running secure stuff , SSH , SCP , VPN are used .
Encrypting harddrives is overkill for the average person .
What e-mails are we sending back and forth that is so sensitive it needs to be encrypted ?
If it is sensitive , most organizations have the approproate framework in place .
I mean , why do I need to encrypt an e-mail to my fellow co-workers of the redneck joke of the day , or encrypt my browsing of Slashdot ?</tokentext>
<sentencetext>What is the point of implementing something that is really not needed?
When you are running secure stuff, SSH, SCP, VPN are used.
Encrypting harddrives is overkill for the average person.
What e-mails are we sending back and forth that is so sensitive it needs to be encrypted?
If it is sensitive, most organizations have the approproate framework in place.
I mean, why do I need to encrypt an e-mail to my fellow co-workers of the redneck joke of the day, or encrypt my browsing of Slashdot?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808822</id>
	<title>Nothing's "broken"</title>
	<author>prescor</author>
	<datestamp>1263835260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Because the people who pay for everything don't "see" a problem.  From the uneducated user's perspective, everything works "the same" whether or not it's encrypted.  They don't see how anything is "broken" so why should they pay $$$ in the form of certs and staff time to upgrade (i.e., "fix") things?</p><p>(That's a possible explanation, not an excuse.)</p></htmltext>
<tokenext>Because the people who pay for everything do n't " see " a problem .
From the uneducated user 's perspective , everything works " the same " whether or not it 's encrypted .
They do n't see how anything is " broken " so why should they pay $ $ $ in the form of certs and staff time to upgrade ( i.e. , " fix " ) things ?
( That 's a possible explanation , not an excuse .
)</tokentext>
<sentencetext>Because the people who pay for everything don't "see" a problem.
From the uneducated user's perspective, everything works "the same" whether or not it's encrypted.
They don't see how anything is "broken" so why should they pay $$$ in the form of certs and staff time to upgrade (i.e., "fix") things?
(That's a possible explanation, not an excuse.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809544</id>
	<title>Encryption is too hard</title>
	<author>DrXym</author>
	<datestamp>1263838260000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Email has traditionally been ignored because obtaining a S/MIME key cost money, the keys expired too quickly, encryption was slow and bloated the message, and the crypto experience in most email clients was positively user hostile. PGP / GPG solves some of the issues (hooray we don't have to pay $$$ to a CA for worthless trust and an expiring cert) but integration in email apps relies on plugins (e.g. Enigmail).
<p>
Put simply encrypting content is just too much effort for most people. I've only ever had dealings with one company that preferred to use crypto. No one else cares.
</p><p>
The only way crypto is going to see wider adoption is if its turned on by default and virtually a no-brainer to use. It has to be virtually transparent. I think it's well past the point of ever happening, although it might gain some traction if a major mail provider such as Google issued all users with a keypair, made it the default to sign outgoing messages.
</p><p>
The question is why Google or any other provider would bother to do that.</p></htmltext>
<tokenext>Email has traditionally been ignored because obtaining a S/MIME key cost money , the keys expired too quickly , encryption was slow and bloated the message , and the crypto experience in most email clients was positively user hostile .
PGP / GPG solves some of the issues ( hooray we do n't have to pay $ $ $ to a CA for worthless trust and an expiring cert ) but integration in email apps relies on plugins ( e.g .
Enigmail ) . Put simply encrypting content is just too much effort for most people .
I 've only ever had dealings with one company that preferred to use crypto .
No one else cares .
The only way crypto is going to see wider adoption is if its turned on by default and virtually a no-brainer to use .
It has to be virtually transparent .
I think it 's well past the point of ever happening , although it might gain some traction if a major mail provider such as Google issued all users with a keypair , made it the default to sign outgoing messages .
The question is why Google or any other provider would bother to do that .</tokentext>
<sentencetext>Email has traditionally been ignored because obtaining a S/MIME key cost money, the keys expired too quickly, encryption was slow and bloated the message, and the crypto experience in most email clients was positively user hostile.
PGP / GPG solves some of the issues (hooray we don't have to pay $$$ to a CA for worthless trust and an expiring cert) but integration in email apps relies on plugins (e.g.
Enigmail).

Put simply encrypting content is just too much effort for most people.
I've only ever had dealings with one company that preferred to use crypto.
No one else cares.
The only way crypto is going to see wider adoption is if its turned on by default and virtually a no-brainer to use.
It has to be virtually transparent.
I think it's well past the point of ever happening, although it might gain some traction if a major mail provider such as Google issued all users with a keypair, made it the default to sign outgoing messages.
The question is why Google or any other provider would bother to do that.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813742</id>
	<title>Options</title>
	<author>benjic</author>
	<datestamp>1263814980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It may not be feasible to employ encryption in everything we do. But we should focus on making it an option to all users to elect to use. A right to privacy shouldn't be nulled because it's to hard to protect.

Additionally employing encryption farther from the application level makes it easier to implement it more transparently.</htmltext>
<tokenext>It may not be feasible to employ encryption in everything we do .
But we should focus on making it an option to all users to elect to use .
A right to privacy should n't be nulled because it 's to hard to protect .
Additionally employing encryption farther from the application level makes it easier to implement it more transparently .</tokentext>
<sentencetext>It may not be feasible to employ encryption in everything we do.
But we should focus on making it an option to all users to elect to use.
A right to privacy shouldn't be nulled because it's to hard to protect.
Additionally employing encryption farther from the application level makes it easier to implement it more transparently.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810384</id>
	<title>It's not just the Police...</title>
	<author>MrSteveSD</author>
	<datestamp>1263842040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....</p></div><p>
In the UK, local councils can view your phone and email records, unbelievable as that is. It is a power granted to them under the RIPA Act and it's not just a theoretical power either. They have used it to spy on people for all manner of reasons. Due to these intrusive powers, public usage of encryption etc should be much more common than it is.</p></div>
	</htmltext>
<tokenext>The fun part is that the ( UK ) cops can demand a decryption key for that , and lock me up when I inevitably fail to provide one... . In the UK , local councils can view your phone and email records , unbelievable as that is .
It is a power granted to them under the RIPA Act and it 's not just a theoretical power either .
They have used it to spy on people for all manner of reasons .
Due to these intrusive powers , public usage of encryption etc should be much more common than it is .</tokentext>
<sentencetext>The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....
In the UK, local councils can view your phone and email records, unbelievable as that is.
It is a power granted to them under the RIPA Act and it's not just a theoretical power either.
They have used it to spy on people for all manner of reasons.
Due to these intrusive powers, public usage of encryption etc should be much more common than it is.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813618</id>
	<title>Re:encryption alone</title>
	<author>Hognoxious</author>
	<datestamp>1263814320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><blockquote><div><p>the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc..</p></div></blockquote><p>There is also a point after which you get diminishing returns, and in fact may make your security worse.<br>[...]<br>Complexity requirements are good up to a point</p></div></blockquote><p>Some part of "appropriate" giving you trouble?</p></div>
	</htmltext>
<tokenext>the weakest link is actually the sysadmin , who is n't enforcing appropriate password complexity , length , age , etc..There is also a point after which you get diminishing returns , and in fact may make your security worse. [ .. .
] Complexity requirements are good up to a pointSome part of " appropriate " giving you trouble ?</tokentext>
<sentencetext>the weakest link is actually the sysadmin, who isn't enforcing appropriate password complexity, length, age, etc..There is also a point after which you get diminishing returns, and in fact may make your security worse.[...
]Complexity requirements are good up to a pointSome part of "appropriate" giving you trouble?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811544</id>
	<title>Use Cost and Benifit Analysis for an answer!</title>
	<author>zarthon</author>
	<datestamp>1263847620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Just like anything encryption has a cost. This cost is actually pretty low. Keeping the government loop and comply with regulations so that terrorist plots are detected early is simply part of this cost.
There is an optimal use of encryption where it's marginal costs are equal to it's marginal benefits. We may fall short of this optimum if among other things there is imperfect Information about the costs and benefits.

#1  The the benefits are hard to measure and unknown.
#2  There are social concerns because of a lack of consensus about what constitutes The Greater Good and this undermines trust. People want their communications encrypted but not the communications of others.

The costs of encryption are very low and the technical knowledge is common and equipment is ubiquitous. The problem is not primarily technical.
The largest technical problem is related to benefit estimates. Other security holes may allow breaches. Encrypted channels must be decrypted at the end points. If the end points are spyware invested sieves then encryption is irrelevant.

Encryption use is not promoted. It's better to have most channels open and encrypt only the necessary information. A start would be to create a collection of  ROI and Cost/ Benefit analysis for enterprises over type, industry and size,  and  for various individuals and households over education level, income, and wealth. Create public policy briefs about encryption.

There is a lot of communication people can't exploit and so people don't care about it. For example who cares if someone finds out I am reading web pages to try to prevent razor burn and read a web page on gentle ex-foliation. At least the office would know I am trying !
Who pays to disseminate the marginal cost and benefit information?
You don't know when encrypted conversations would have been breached or the costs that would have been incurred from the breach.  The costs of breaches are a large part of the benefits of security and must be estimated.</htmltext>
<tokenext>Just like anything encryption has a cost .
This cost is actually pretty low .
Keeping the government loop and comply with regulations so that terrorist plots are detected early is simply part of this cost .
There is an optimal use of encryption where it 's marginal costs are equal to it 's marginal benefits .
We may fall short of this optimum if among other things there is imperfect Information about the costs and benefits .
# 1 The the benefits are hard to measure and unknown .
# 2 There are social concerns because of a lack of consensus about what constitutes The Greater Good and this undermines trust .
People want their communications encrypted but not the communications of others .
The costs of encryption are very low and the technical knowledge is common and equipment is ubiquitous .
The problem is not primarily technical .
The largest technical problem is related to benefit estimates .
Other security holes may allow breaches .
Encrypted channels must be decrypted at the end points .
If the end points are spyware invested sieves then encryption is irrelevant .
Encryption use is not promoted .
It 's better to have most channels open and encrypt only the necessary information .
A start would be to create a collection of ROI and Cost/ Benefit analysis for enterprises over type , industry and size , and for various individuals and households over education level , income , and wealth .
Create public policy briefs about encryption .
There is a lot of communication people ca n't exploit and so people do n't care about it .
For example who cares if someone finds out I am reading web pages to try to prevent razor burn and read a web page on gentle ex-foliation .
At least the office would know I am trying !
Who pays to disseminate the marginal cost and benefit information ?
You do n't know when encrypted conversations would have been breached or the costs that would have been incurred from the breach .
The costs of breaches are a large part of the benefits of security and must be estimated .</tokentext>
<sentencetext>Just like anything encryption has a cost.
This cost is actually pretty low.
Keeping the government loop and comply with regulations so that terrorist plots are detected early is simply part of this cost.
There is an optimal use of encryption where it's marginal costs are equal to it's marginal benefits.
We may fall short of this optimum if among other things there is imperfect Information about the costs and benefits.
#1  The the benefits are hard to measure and unknown.
#2  There are social concerns because of a lack of consensus about what constitutes The Greater Good and this undermines trust.
People want their communications encrypted but not the communications of others.
The costs of encryption are very low and the technical knowledge is common and equipment is ubiquitous.
The problem is not primarily technical.
The largest technical problem is related to benefit estimates.
Other security holes may allow breaches.
Encrypted channels must be decrypted at the end points.
If the end points are spyware invested sieves then encryption is irrelevant.
Encryption use is not promoted.
It's better to have most channels open and encrypt only the necessary information.
A start would be to create a collection of  ROI and Cost/ Benefit analysis for enterprises over type, industry and size,  and  for various individuals and households over education level, income, and wealth.
Create public policy briefs about encryption.
There is a lot of communication people can't exploit and so people don't care about it.
For example who cares if someone finds out I am reading web pages to try to prevent razor burn and read a web page on gentle ex-foliation.
At least the office would know I am trying !
Who pays to disseminate the marginal cost and benefit information?
You don't know when encrypted conversations would have been breached or the costs that would have been incurred from the breach.
The costs of breaches are a large part of the benefits of security and must be estimated.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809072</id>
	<title>Isn't it obvious? Money</title>
	<author>Etylowy</author>
	<datestamp>1263836280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Certificates, bandwidth, cpu power - it all ain't free.<br>Encryption costs: the obvious - signed certificates aren't free, but also https has higher bandwidth cost than http, encrypting data is CPU intensive - it all sums up.</p><p>IMHO encryption will be always limited to the bare minimum - where money and/or sensitive data is involved - and that's fine: why the hell would I want to encrypt anything else?</p></htmltext>
<tokenext>Certificates , bandwidth , cpu power - it all ai n't free.Encryption costs : the obvious - signed certificates are n't free , but also https has higher bandwidth cost than http , encrypting data is CPU intensive - it all sums up.IMHO encryption will be always limited to the bare minimum - where money and/or sensitive data is involved - and that 's fine : why the hell would I want to encrypt anything else ?</tokentext>
<sentencetext>Certificates, bandwidth, cpu power - it all ain't free.Encryption costs: the obvious - signed certificates aren't free, but also https has higher bandwidth cost than http, encrypting data is CPU intensive - it all sums up.IMHO encryption will be always limited to the bare minimum - where money and/or sensitive data is involved - and that's fine: why the hell would I want to encrypt anything else?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810164</id>
	<title>VS Electronic-Arts</title>
	<author>phorm</author>
	<datestamp>1263840960000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>I wish *EA* would use hashes or something of the sort on their databases. Last time I tried to reset my password the damn thing mailed me that actual PW in plaintext, which indicates to me that they're too stupid to realize that:</p><p>a) Storing non-hashed passwords in a DB is a good way to get hacked and expose all your customers accounts. It's really quite dumb<br>b) Email is an insecure medium for sending somebody's password down the wire</p></htmltext>
<tokenext>I wish * EA * would use hashes or something of the sort on their databases .
Last time I tried to reset my password the damn thing mailed me that actual PW in plaintext , which indicates to me that they 're too stupid to realize that : a ) Storing non-hashed passwords in a DB is a good way to get hacked and expose all your customers accounts .
It 's really quite dumbb ) Email is an insecure medium for sending somebody 's password down the wire</tokentext>
<sentencetext>I wish *EA* would use hashes or something of the sort on their databases.
Last time I tried to reset my password the damn thing mailed me that actual PW in plaintext, which indicates to me that they're too stupid to realize that:a) Storing non-hashed passwords in a DB is a good way to get hacked and expose all your customers accounts.
It's really quite dumbb) Email is an insecure medium for sending somebody's password down the wire</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30818860</id>
	<title>Re:Certificates.</title>
	<author>muckracer</author>
	<datestamp>1263914880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; Key management becomes impossible past more than a couple of keys<br>&gt; and the whole process is just incredibly tedious.</p><p>What part of it do you find difficult? (honest question...trying to understand)</p></htmltext>
<tokenext>&gt; Key management becomes impossible past more than a couple of keys &gt; and the whole process is just incredibly tedious.What part of it do you find difficult ?
( honest question...trying to understand )</tokentext>
<sentencetext>&gt; Key management becomes impossible past more than a couple of keys&gt; and the whole process is just incredibly tedious.What part of it do you find difficult?
(honest question...trying to understand)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809300</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812706</id>
	<title>HTTPS can't be cached by proxy</title>
	<author>Baloo Uriza</author>
	<datestamp>1263809880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>HTTP proxy caching is a best practice for ISPs and businesses, and going to HTTPS thus adds overhead since this traffic can't be cached.</htmltext>
<tokenext>HTTP proxy caching is a best practice for ISPs and businesses , and going to HTTPS thus adds overhead since this traffic ca n't be cached .</tokentext>
<sentencetext>HTTP proxy caching is a best practice for ISPs and businesses, and going to HTTPS thus adds overhead since this traffic can't be cached.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766</id>
	<title>Costs?</title>
	<author>Anonymous</author>
	<datestamp>1263834960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>Isn't it the case in enterprises where they would rather keep things status quo instead of adding additional layers of (potential) problems?
I believe they won't convert unless there's sufficient financial (dis)incentive to do so.</htmltext>
<tokenext>Is n't it the case in enterprises where they would rather keep things status quo instead of adding additional layers of ( potential ) problems ?
I believe they wo n't convert unless there 's sufficient financial ( dis ) incentive to do so .</tokentext>
<sentencetext>Isn't it the case in enterprises where they would rather keep things status quo instead of adding additional layers of (potential) problems?
I believe they won't convert unless there's sufficient financial (dis)incentive to do so.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808846</id>
	<title>Key Management is hard</title>
	<author>Anonymous</author>
	<datestamp>1263835320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Both technically and administratively. I've lost count of the number of 'Public Key Certificate Expired' warnings I've had over the years. Also doing crypto slows down servers - the cpu hit on web servers by using https is significant so many only use https for the bits of transactions that really need it. I just wonder what hit Google took by encrypting by default all Gmail sessions.</p></htmltext>
<tokenext>Both technically and administratively .
I 've lost count of the number of 'Public Key Certificate Expired ' warnings I 've had over the years .
Also doing crypto slows down servers - the cpu hit on web servers by using https is significant so many only use https for the bits of transactions that really need it .
I just wonder what hit Google took by encrypting by default all Gmail sessions .</tokentext>
<sentencetext>Both technically and administratively.
I've lost count of the number of 'Public Key Certificate Expired' warnings I've had over the years.
Also doing crypto slows down servers - the cpu hit on web servers by using https is significant so many only use https for the bits of transactions that really need it.
I just wonder what hit Google took by encrypting by default all Gmail sessions.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810150</id>
	<title>Re:Encryption isn't free</title>
	<author>Anonymous</author>
	<datestamp>1263840900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>web encryption doesn't really slow down anything that is actually deployed on the client side these days. Unless you count proxies but the true client side would be better off without proxies anyway.</p></htmltext>
<tokenext>web encryption does n't really slow down anything that is actually deployed on the client side these days .
Unless you count proxies but the true client side would be better off without proxies anyway .</tokentext>
<sentencetext>web encryption doesn't really slow down anything that is actually deployed on the client side these days.
Unless you count proxies but the true client side would be better off without proxies anyway.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808856</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811798</id>
	<title>Re:People don't see the value</title>
	<author>bitslinger\_42</author>
	<datestamp>1263805620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Two thoughts.  First, there are times where it is better to be using a system that you know without a doubt is insecure than to use a system that appears secure, but isn't.  At least with the known unsecure system, there's a chance that the user will stop and think "hmm, this is pretty sensitive, maybe I shouldn't be doing this over the unprotected link".  If the user has that magic gold lock icon, they'll think they're secure even when they're not, which not only increases the chance of compromise, it also increases the chance that high-value data is compromised.</p><p>Second, key-signing parties are not a panacea.  When it comes to trust and identity, how well do you really know people?  There are exactly two people in the world that I can say with confidence that I'm 100\% sure that I know who they are.  I am the first (self-evident).  My son is the other.  I know that because I was in the room when he was born, he was handed to me, I carried him to another room, and he never left that room unless he was accompanied by either my wife or myself.  Since then, he's been in our possession and we've maintained documentation of him (i.e. pictures, medical records, hand prints in clay, etc.)</p><p>For everyone else I know, there is no way for me to establish their identity with that level of certainty.  I know that the people I call my parents today are the same people that I've called my parents for as long as I've had the concept of parent, but when it comes down to it, there's no way I can be sure that my father really is Bob Bitslinger and not, for example, D. B. Cooper, or Alice Cooper, or James Fennimore Cooper, and that's with someone that I've supposedly known my whole life.</p><p>Read Cory Doctorow's book <a href="http://craphound.com/littlebrother/download/" title="craphound.com">Little Brother</a> [craphound.com].  It isn't particularly well written, and the story's a bit overblown, but it does a great job of explaining why key-signing parties don't solve the trust and identity problems in security.</p></htmltext>
<tokenext>Two thoughts .
First , there are times where it is better to be using a system that you know without a doubt is insecure than to use a system that appears secure , but is n't .
At least with the known unsecure system , there 's a chance that the user will stop and think " hmm , this is pretty sensitive , maybe I should n't be doing this over the unprotected link " .
If the user has that magic gold lock icon , they 'll think they 're secure even when they 're not , which not only increases the chance of compromise , it also increases the chance that high-value data is compromised.Second , key-signing parties are not a panacea .
When it comes to trust and identity , how well do you really know people ?
There are exactly two people in the world that I can say with confidence that I 'm 100 \ % sure that I know who they are .
I am the first ( self-evident ) .
My son is the other .
I know that because I was in the room when he was born , he was handed to me , I carried him to another room , and he never left that room unless he was accompanied by either my wife or myself .
Since then , he 's been in our possession and we 've maintained documentation of him ( i.e .
pictures , medical records , hand prints in clay , etc .
) For everyone else I know , there is no way for me to establish their identity with that level of certainty .
I know that the people I call my parents today are the same people that I 've called my parents for as long as I 've had the concept of parent , but when it comes down to it , there 's no way I can be sure that my father really is Bob Bitslinger and not , for example , D. B. Cooper , or Alice Cooper , or James Fennimore Cooper , and that 's with someone that I 've supposedly known my whole life.Read Cory Doctorow 's book Little Brother [ craphound.com ] .
It is n't particularly well written , and the story 's a bit overblown , but it does a great job of explaining why key-signing parties do n't solve the trust and identity problems in security .</tokentext>
<sentencetext>Two thoughts.
First, there are times where it is better to be using a system that you know without a doubt is insecure than to use a system that appears secure, but isn't.
At least with the known unsecure system, there's a chance that the user will stop and think "hmm, this is pretty sensitive, maybe I shouldn't be doing this over the unprotected link".
If the user has that magic gold lock icon, they'll think they're secure even when they're not, which not only increases the chance of compromise, it also increases the chance that high-value data is compromised.Second, key-signing parties are not a panacea.
When it comes to trust and identity, how well do you really know people?
There are exactly two people in the world that I can say with confidence that I'm 100\% sure that I know who they are.
I am the first (self-evident).
My son is the other.
I know that because I was in the room when he was born, he was handed to me, I carried him to another room, and he never left that room unless he was accompanied by either my wife or myself.
Since then, he's been in our possession and we've maintained documentation of him (i.e.
pictures, medical records, hand prints in clay, etc.
)For everyone else I know, there is no way for me to establish their identity with that level of certainty.
I know that the people I call my parents today are the same people that I've called my parents for as long as I've had the concept of parent, but when it comes down to it, there's no way I can be sure that my father really is Bob Bitslinger and not, for example, D. B. Cooper, or Alice Cooper, or James Fennimore Cooper, and that's with someone that I've supposedly known my whole life.Read Cory Doctorow's book Little Brother [craphound.com].
It isn't particularly well written, and the story's a bit overblown, but it does a great job of explaining why key-signing parties don't solve the trust and identity problems in security.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809316</id>
	<title>Re:Apathy</title>
	<author>OrangeCatholic</author>
	<datestamp>1263837240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&gt;Probably not the best attitude
<br> <br>
It would be fine if your FTP server wasn't connected to every user in China and Russia.  It's kind of like hanging your underwear to dry on a clothesline in the backyard thinking, "I only have one neighbor, what's the chance he's going to see my underwear?"
<br> <br>
Meanwhile, there's 6 BILLION people living at your neighbor's house.  I mean, it's not a sure thing that you'll get robbed, it just goes to show that your FTP server is in a ghetto.
<br> <br>
That's what people don't get about the internet.  It's the ultimate shitty party. Everyone's invited.  There's no way to keep anyone out.
<br> <br>
Oh wait, there is!</htmltext>
<tokenext>&gt; Probably not the best attitude It would be fine if your FTP server was n't connected to every user in China and Russia .
It 's kind of like hanging your underwear to dry on a clothesline in the backyard thinking , " I only have one neighbor , what 's the chance he 's going to see my underwear ?
" Meanwhile , there 's 6 BILLION people living at your neighbor 's house .
I mean , it 's not a sure thing that you 'll get robbed , it just goes to show that your FTP server is in a ghetto .
That 's what people do n't get about the internet .
It 's the ultimate shitty party .
Everyone 's invited .
There 's no way to keep anyone out .
Oh wait , there is !</tokentext>
<sentencetext>&gt;Probably not the best attitude
 
It would be fine if your FTP server wasn't connected to every user in China and Russia.
It's kind of like hanging your underwear to dry on a clothesline in the backyard thinking, "I only have one neighbor, what's the chance he's going to see my underwear?
"
 
Meanwhile, there's 6 BILLION people living at your neighbor's house.
I mean, it's not a sure thing that you'll get robbed, it just goes to show that your FTP server is in a ghetto.
That's what people don't get about the internet.
It's the ultimate shitty party.
Everyone's invited.
There's no way to keep anyone out.
Oh wait, there is!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808844</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809026</id>
	<title>Since when is no-encryption a problem?</title>
	<author>AbbeyRoad</author>
	<datestamp>1263836040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Simply put, the bulk of security problems are not solved by encryption.</p><p>In fact encryption and authentication often create more problems than they solve. Corporations are asking for many passwords where they aren't needed, certificates create admin overhead, and encryption is more difficult to set up and get working in-time-to-market than if there were no encryption.</p><p>One doesn't invest in something "because it sounds like -- real cool, man". Rather, one must begin with a problem and think creatively to solve that problem.<nobr> <wbr></nobr>...and encryption is just one of the available tools.</p><p>Also, you can't take the protocols SSL, DNSSEC, SFTP, IPSEC and pool them into one bucket and call it "encryption". Each are separate solutions to separate problems, and indeed will usually be only one component within the solution.</p><p>-paul</p></htmltext>
<tokenext>Simply put , the bulk of security problems are not solved by encryption.In fact encryption and authentication often create more problems than they solve .
Corporations are asking for many passwords where they are n't needed , certificates create admin overhead , and encryption is more difficult to set up and get working in-time-to-market than if there were no encryption.One does n't invest in something " because it sounds like -- real cool , man " .
Rather , one must begin with a problem and think creatively to solve that problem .
...and encryption is just one of the available tools.Also , you ca n't take the protocols SSL , DNSSEC , SFTP , IPSEC and pool them into one bucket and call it " encryption " .
Each are separate solutions to separate problems , and indeed will usually be only one component within the solution.-paul</tokentext>
<sentencetext>Simply put, the bulk of security problems are not solved by encryption.In fact encryption and authentication often create more problems than they solve.
Corporations are asking for many passwords where they aren't needed, certificates create admin overhead, and encryption is more difficult to set up and get working in-time-to-market than if there were no encryption.One doesn't invest in something "because it sounds like -- real cool, man".
Rather, one must begin with a problem and think creatively to solve that problem.
...and encryption is just one of the available tools.Also, you can't take the protocols SSL, DNSSEC, SFTP, IPSEC and pool them into one bucket and call it "encryption".
Each are separate solutions to separate problems, and indeed will usually be only one component within the solution.-paul</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809700</id>
	<title>HTTPS</title>
	<author>Bert64</author>
	<datestamp>1263838980000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>What's holding back HTTPS is the lack of IP addresses combined with the lack of support for modern versions of TLS...<br>As it stands, you need 1 IP address per HTTPS site.</p><p>What's holding back SSH and causing people to continue using telnet is a number of factors:<br>1, windows doesn't have an ssh client by default, only telnet<br>2, some networking vendors (eg cisco) charge extra for ssh support on their devices<br>3, lots of lower end networking devices only support telnet</p><p>What's holding back FTPS and the like is much the same, lack of client support and lack of user knowledge, FTP as a protocol pretty much needs to die anyway, it doesn't work well with NAT... Encrypted FTP is even more broken on NAT because the nat device cannot watch for the ftp commands and open up the appropriate data ports.<br>When you offer hosting, customers demand to use FTP and often refuse to even consider more secure alternatives.</p><p>Also, most email being sent is still completely unencrypted.</p></htmltext>
<tokenext>What 's holding back HTTPS is the lack of IP addresses combined with the lack of support for modern versions of TLS...As it stands , you need 1 IP address per HTTPS site.What 's holding back SSH and causing people to continue using telnet is a number of factors : 1 , windows does n't have an ssh client by default , only telnet2 , some networking vendors ( eg cisco ) charge extra for ssh support on their devices3 , lots of lower end networking devices only support telnetWhat 's holding back FTPS and the like is much the same , lack of client support and lack of user knowledge , FTP as a protocol pretty much needs to die anyway , it does n't work well with NAT... Encrypted FTP is even more broken on NAT because the nat device can not watch for the ftp commands and open up the appropriate data ports.When you offer hosting , customers demand to use FTP and often refuse to even consider more secure alternatives.Also , most email being sent is still completely unencrypted .</tokentext>
<sentencetext>What's holding back HTTPS is the lack of IP addresses combined with the lack of support for modern versions of TLS...As it stands, you need 1 IP address per HTTPS site.What's holding back SSH and causing people to continue using telnet is a number of factors:1, windows doesn't have an ssh client by default, only telnet2, some networking vendors (eg cisco) charge extra for ssh support on their devices3, lots of lower end networking devices only support telnetWhat's holding back FTPS and the like is much the same, lack of client support and lack of user knowledge, FTP as a protocol pretty much needs to die anyway, it doesn't work well with NAT... Encrypted FTP is even more broken on NAT because the nat device cannot watch for the ftp commands and open up the appropriate data ports.When you offer hosting, customers demand to use FTP and often refuse to even consider more secure alternatives.Also, most email being sent is still completely unencrypted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808990</id>
	<title>too much effort</title>
	<author>mrphoton</author>
	<datestamp>1263835860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I wish Thunderbird of evolution had some type of automated system for encryption, where you tagged your public key to the bottom of every e-mail.  When an in coming e-mail was detected with a key at the bottom all replys were automatically encrypted. I think the problem with encryption at the moment is that people have to think about it so it does not happen.</htmltext>
<tokenext>I wish Thunderbird of evolution had some type of automated system for encryption , where you tagged your public key to the bottom of every e-mail .
When an in coming e-mail was detected with a key at the bottom all replys were automatically encrypted .
I think the problem with encryption at the moment is that people have to think about it so it does not happen .</tokentext>
<sentencetext>I wish Thunderbird of evolution had some type of automated system for encryption, where you tagged your public key to the bottom of every e-mail.
When an in coming e-mail was detected with a key at the bottom all replys were automatically encrypted.
I think the problem with encryption at the moment is that people have to think about it so it does not happen.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082</id>
	<title>Re:Costs?</title>
	<author>Lord Ender</author>
	<datestamp>1263836340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>It's key management and distribution, not cost. The costs are very low. Training everyone to exchange S/MIME keys, for example, is just too damn hard.</p><p>When email clients can automatically look up other peoples' certificates using DNS, then encryption will hit the main-stream.</p><p>(Oh, and bass-ackward companies like Apple are also holding back encryption. The iPhone can't do Secure Email after all this time? Really, Apple? Really?)</p></htmltext>
<tokenext>It 's key management and distribution , not cost .
The costs are very low .
Training everyone to exchange S/MIME keys , for example , is just too damn hard.When email clients can automatically look up other peoples ' certificates using DNS , then encryption will hit the main-stream .
( Oh , and bass-ackward companies like Apple are also holding back encryption .
The iPhone ca n't do Secure Email after all this time ?
Really , Apple ?
Really ? )</tokentext>
<sentencetext>It's key management and distribution, not cost.
The costs are very low.
Training everyone to exchange S/MIME keys, for example, is just too damn hard.When email clients can automatically look up other peoples' certificates using DNS, then encryption will hit the main-stream.
(Oh, and bass-ackward companies like Apple are also holding back encryption.
The iPhone can't do Secure Email after all this time?
Really, Apple?
Really?)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808856</id>
	<title>Encryption isn't free</title>
	<author>raju1kabir</author>
	<datestamp>1263835380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> Most websites are still using unencrypted HTTP</p></div></blockquote><p>Without dedicated hardware, https is an incredible performance drain on web servers. And even the dedicated hardware at the data centre won't help the client side. Not to mention the caching rules which mean much more data traffic.</p><p>For most web sites, I see no reason to use encryption.</p></div>
	</htmltext>
<tokenext>Most websites are still using unencrypted HTTPWithout dedicated hardware , https is an incredible performance drain on web servers .
And even the dedicated hardware at the data centre wo n't help the client side .
Not to mention the caching rules which mean much more data traffic.For most web sites , I see no reason to use encryption .</tokentext>
<sentencetext> Most websites are still using unencrypted HTTPWithout dedicated hardware, https is an incredible performance drain on web servers.
And even the dedicated hardware at the data centre won't help the client side.
Not to mention the caching rules which mean much more data traffic.For most web sites, I see no reason to use encryption.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810942</id>
	<title>Re:It's simple.</title>
	<author>Anonymous</author>
	<datestamp>1263844800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>If it's a win/lose competitive race, then any way to lose is is bad as any other.  If encryption slows you down a little, then even if getting hacked slows you down severely, people will chance getting hacked even the expected value in speed of encryption + not getting hacked is higher than the expected value in speed of not encrypting with a small chance of gettnig hacked.  If it is only possible to win by not encrypting and being lucky enough not to get hacked, then that strategy will be chosen by all, even if it leads to the downfall of most who partake of it.</htmltext>
<tokenext>If it 's a win/lose competitive race , then any way to lose is is bad as any other .
If encryption slows you down a little , then even if getting hacked slows you down severely , people will chance getting hacked even the expected value in speed of encryption + not getting hacked is higher than the expected value in speed of not encrypting with a small chance of gettnig hacked .
If it is only possible to win by not encrypting and being lucky enough not to get hacked , then that strategy will be chosen by all , even if it leads to the downfall of most who partake of it .</tokentext>
<sentencetext>If it's a win/lose competitive race, then any way to lose is is bad as any other.
If encryption slows you down a little, then even if getting hacked slows you down severely, people will chance getting hacked even the expected value in speed of encryption + not getting hacked is higher than the expected value in speed of not encrypting with a small chance of gettnig hacked.
If it is only possible to win by not encrypting and being lucky enough not to get hacked, then that strategy will be chosen by all, even if it leads to the downfall of most who partake of it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808922</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808932</id>
	<title>Seriously?</title>
	<author>Anonymous</author>
	<datestamp>1263835620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Weeks after Google, a technology leader gets hacked by having ancient versions of IE 6 on their desktops, and you're asking why encryption isn't everywhere?

Same reason IPv6 isn't everywhere, VOIP isn't everywhere, the current spam-friendly email protocols we've been living with for decades haven't been replaced with authenticated sender-based protocols, and why blacklist-based antivirus hasn't been replaced by a less "lossy" model of security.

Why? Because doing nothing costs nothing. Doing something costs something - and if you can't explicitly explain why doing something more than the current "bare minimum" MUST be done, quantify the costs of doing vs. not doing it (and have the latter exceed the former) and/or end-of-life the current methodologies, then things just don't happen in the low-cost/low-budget world of IT.</htmltext>
<tokenext>Weeks after Google , a technology leader gets hacked by having ancient versions of IE 6 on their desktops , and you 're asking why encryption is n't everywhere ?
Same reason IPv6 is n't everywhere , VOIP is n't everywhere , the current spam-friendly email protocols we 've been living with for decades have n't been replaced with authenticated sender-based protocols , and why blacklist-based antivirus has n't been replaced by a less " lossy " model of security .
Why ? Because doing nothing costs nothing .
Doing something costs something - and if you ca n't explicitly explain why doing something more than the current " bare minimum " MUST be done , quantify the costs of doing vs. not doing it ( and have the latter exceed the former ) and/or end-of-life the current methodologies , then things just do n't happen in the low-cost/low-budget world of IT .</tokentext>
<sentencetext>Weeks after Google, a technology leader gets hacked by having ancient versions of IE 6 on their desktops, and you're asking why encryption isn't everywhere?
Same reason IPv6 isn't everywhere, VOIP isn't everywhere, the current spam-friendly email protocols we've been living with for decades haven't been replaced with authenticated sender-based protocols, and why blacklist-based antivirus hasn't been replaced by a less "lossy" model of security.
Why? Because doing nothing costs nothing.
Doing something costs something - and if you can't explicitly explain why doing something more than the current "bare minimum" MUST be done, quantify the costs of doing vs. not doing it (and have the latter exceed the former) and/or end-of-life the current methodologies, then things just don't happen in the low-cost/low-budget world of IT.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809724</id>
	<title>Re:I have encrypted this post</title>
	<author>mellon85</author>
	<datestamp>1263839040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That's what steganography is for (check truecrypt). Encryption ensures that nobody else can read the message, if you want to hide, then you need steganography, which hides the message. or as true crypt does: the data can be decrypted with 2 passwords. one for the cop, one for you and they can't know if there is something else</htmltext>
<tokenext>That 's what steganography is for ( check truecrypt ) .
Encryption ensures that nobody else can read the message , if you want to hide , then you need steganography , which hides the message .
or as true crypt does : the data can be decrypted with 2 passwords .
one for the cop , one for you and they ca n't know if there is something else</tokentext>
<sentencetext>That's what steganography is for (check truecrypt).
Encryption ensures that nobody else can read the message, if you want to hide, then you need steganography, which hides the message.
or as true crypt does: the data can be decrypted with 2 passwords.
one for the cop, one for you and they can't know if there is something else</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809300</id>
	<title>Certificates.</title>
	<author>Eskarel</author>
	<datestamp>1263837180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The basic reality is that most information really isn't all that private, and that managing certificates is rather tedious and expensive.</p><p>People don't generally whisper when they're talking to their friends in public, or talk in code, or anything much else. They don't care too much who overhears. If something is supposed to be secret they take the appropriate steps.</p><p>The same is true for web traffic. Most of it just doesn't need to be all that secure. Sure bank details need to be private, and a few other things, but my google search doesn't really need to be. Google is already storing it, and why would anyone bother to spy on it, or care if they did?</p><p>The exception to this of course is e-mail which is more of a systematic failure than https or ftps. Most people would indeed like their e-mails to be private, but while webmail providers are starting to provide https interfaces, real, honest to goodness, e-mail encryption is just too damned hard. Key management becomes impossible past more than a couple of keys and the whole process is just incredibly tedious. The person who comes up with a way to get e-mail encryption in a way that isn't too much hassle and doesn't involve storing all your keys with some "trusted" third party will have a license to print money.</p></htmltext>
<tokenext>The basic reality is that most information really is n't all that private , and that managing certificates is rather tedious and expensive.People do n't generally whisper when they 're talking to their friends in public , or talk in code , or anything much else .
They do n't care too much who overhears .
If something is supposed to be secret they take the appropriate steps.The same is true for web traffic .
Most of it just does n't need to be all that secure .
Sure bank details need to be private , and a few other things , but my google search does n't really need to be .
Google is already storing it , and why would anyone bother to spy on it , or care if they did ? The exception to this of course is e-mail which is more of a systematic failure than https or ftps .
Most people would indeed like their e-mails to be private , but while webmail providers are starting to provide https interfaces , real , honest to goodness , e-mail encryption is just too damned hard .
Key management becomes impossible past more than a couple of keys and the whole process is just incredibly tedious .
The person who comes up with a way to get e-mail encryption in a way that is n't too much hassle and does n't involve storing all your keys with some " trusted " third party will have a license to print money .</tokentext>
<sentencetext>The basic reality is that most information really isn't all that private, and that managing certificates is rather tedious and expensive.People don't generally whisper when they're talking to their friends in public, or talk in code, or anything much else.
They don't care too much who overhears.
If something is supposed to be secret they take the appropriate steps.The same is true for web traffic.
Most of it just doesn't need to be all that secure.
Sure bank details need to be private, and a few other things, but my google search doesn't really need to be.
Google is already storing it, and why would anyone bother to spy on it, or care if they did?The exception to this of course is e-mail which is more of a systematic failure than https or ftps.
Most people would indeed like their e-mails to be private, but while webmail providers are starting to provide https interfaces, real, honest to goodness, e-mail encryption is just too damned hard.
Key management becomes impossible past more than a couple of keys and the whole process is just incredibly tedious.
The person who comes up with a way to get e-mail encryption in a way that isn't too much hassle and doesn't involve storing all your keys with some "trusted" third party will have a license to print money.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809802</id>
	<title>It's not worth it.</title>
	<author>tjstork</author>
	<datestamp>1263839340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>People don't think it is actually worth it.  Besides, HTTPS alone doesn't halt man in the middle attacks, when user's browsers can accept bogus certificates.</p></htmltext>
<tokenext>People do n't think it is actually worth it .
Besides , HTTPS alone does n't halt man in the middle attacks , when user 's browsers can accept bogus certificates .</tokentext>
<sentencetext>People don't think it is actually worth it.
Besides, HTTPS alone doesn't halt man in the middle attacks, when user's browsers can accept bogus certificates.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811136</id>
	<title>Re:Apathy</title>
	<author>Anonymous</author>
	<datestamp>1263845880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>It's like personal home protection for many people - they don't want a gun in the house until after they've been robbed the first time. I'd wager that many people using encryption are doing so because they've been bitten by a lack of encryption in the past.</p></div></blockquote><p>I'd imagine encryption to be locks and safe window joints; a gun would be something like a ping flooding daemon.</p></div>
	</htmltext>
<tokenext>It 's like personal home protection for many people - they do n't want a gun in the house until after they 've been robbed the first time .
I 'd wager that many people using encryption are doing so because they 've been bitten by a lack of encryption in the past.I 'd imagine encryption to be locks and safe window joints ; a gun would be something like a ping flooding daemon .</tokentext>
<sentencetext>It's like personal home protection for many people - they don't want a gun in the house until after they've been robbed the first time.
I'd wager that many people using encryption are doing so because they've been bitten by a lack of encryption in the past.I'd imagine encryption to be locks and safe window joints; a gun would be something like a ping flooding daemon.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809872</id>
	<title>What's wrong with FTP?</title>
	<author>Anonymous</author>
	<datestamp>1263839640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If what you are distributing is Open Source or Public Domain, then FTP is just fine. I don't see a problem with half of your communication being unencrypted, provided that same half is not confidential in nature. Encryption should only be used for messages that you would object to seeing on the front page of the newspaper the next day -- but if that is the case, perhaps you shouldn't be sending those messages over the 'net at all!</p></htmltext>
<tokenext>If what you are distributing is Open Source or Public Domain , then FTP is just fine .
I do n't see a problem with half of your communication being unencrypted , provided that same half is not confidential in nature .
Encryption should only be used for messages that you would object to seeing on the front page of the newspaper the next day -- but if that is the case , perhaps you should n't be sending those messages over the 'net at all !</tokentext>
<sentencetext>If what you are distributing is Open Source or Public Domain, then FTP is just fine.
I don't see a problem with half of your communication being unencrypted, provided that same half is not confidential in nature.
Encryption should only be used for messages that you would object to seeing on the front page of the newspaper the next day -- but if that is the case, perhaps you shouldn't be sending those messages over the 'net at all!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816768</id>
	<title>Re:encryption alone</title>
	<author>phtpht</author>
	<datestamp>1263932040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>is not the whole solution.</p></div><p>How true. In transport crypto is almost futile nowadays (original SSH was deployed on coax ethernet networks where anybody could see your pw, today it's another story).</p><p>Authentication crypto has the burden of certificate management (do you verify fingerprints of each https site you visit?)</p><p>In the light of botnet compromises, crypto achieves precisely nothing (bot controlled agent can do/see exactly the same stuff as local user).</p><p>Consumer crypto has mixed success stories (see GSM and satellite TV smartcards).</p><p>Static data crypto (on-disk) brings key management hassle (crypt the daily backup, but backup the keys to a different place) and opens a field for legislative battles (i give my disk key to my lawyer).</p><p>Finally, crypto of any kind itself is hard to get done right and bad crypto is worse than no crypto (Debian openssl epic fail). It requires powerful hardware. And of course, some enlightenment of the staff, tighter procedures, etc.</p><p>So crypto deployment is always to be weighed against these (and other) downsides.</p></div>
	</htmltext>
<tokenext>is not the whole solution.How true .
In transport crypto is almost futile nowadays ( original SSH was deployed on coax ethernet networks where anybody could see your pw , today it 's another story ) .Authentication crypto has the burden of certificate management ( do you verify fingerprints of each https site you visit ?
) In the light of botnet compromises , crypto achieves precisely nothing ( bot controlled agent can do/see exactly the same stuff as local user ) .Consumer crypto has mixed success stories ( see GSM and satellite TV smartcards ) .Static data crypto ( on-disk ) brings key management hassle ( crypt the daily backup , but backup the keys to a different place ) and opens a field for legislative battles ( i give my disk key to my lawyer ) .Finally , crypto of any kind itself is hard to get done right and bad crypto is worse than no crypto ( Debian openssl epic fail ) .
It requires powerful hardware .
And of course , some enlightenment of the staff , tighter procedures , etc.So crypto deployment is always to be weighed against these ( and other ) downsides .</tokentext>
<sentencetext>is not the whole solution.How true.
In transport crypto is almost futile nowadays (original SSH was deployed on coax ethernet networks where anybody could see your pw, today it's another story).Authentication crypto has the burden of certificate management (do you verify fingerprints of each https site you visit?
)In the light of botnet compromises, crypto achieves precisely nothing (bot controlled agent can do/see exactly the same stuff as local user).Consumer crypto has mixed success stories (see GSM and satellite TV smartcards).Static data crypto (on-disk) brings key management hassle (crypt the daily backup, but backup the keys to a different place) and opens a field for legislative battles (i give my disk key to my lawyer).Finally, crypto of any kind itself is hard to get done right and bad crypto is worse than no crypto (Debian openssl epic fail).
It requires powerful hardware.
And of course, some enlightenment of the staff, tighter procedures, etc.So crypto deployment is always to be weighed against these (and other) downsides.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810966</id>
	<title>SSL/TLS is solving the wrong problem for most uses</title>
	<author>Lazy Jones</author>
	<datestamp>1263844920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>SSL and predecessory try to prevent forged messages in addition to providing encrypted communication, adding the unacceptable overhead of handling a key infrastructure, purchasing certificates etc. where for most uses encrypted communication alone would be sufficient and could be achieved in a much simpler, cheaper way (especially when authentication is achieved with passwords anyway). So we're not encrypting traffic and not preventing eavesdropping because preventing forged messages is too hard/costly - congratulations! On the other hand, one should consider the implications of the false sense of security for the layman with only encrypted traffic - which is similar to what we have now with SSL being broken (MD5 etc.)</htmltext>
<tokenext>SSL and predecessory try to prevent forged messages in addition to providing encrypted communication , adding the unacceptable overhead of handling a key infrastructure , purchasing certificates etc .
where for most uses encrypted communication alone would be sufficient and could be achieved in a much simpler , cheaper way ( especially when authentication is achieved with passwords anyway ) .
So we 're not encrypting traffic and not preventing eavesdropping because preventing forged messages is too hard/costly - congratulations !
On the other hand , one should consider the implications of the false sense of security for the layman with only encrypted traffic - which is similar to what we have now with SSL being broken ( MD5 etc .
)</tokentext>
<sentencetext>SSL and predecessory try to prevent forged messages in addition to providing encrypted communication, adding the unacceptable overhead of handling a key infrastructure, purchasing certificates etc.
where for most uses encrypted communication alone would be sufficient and could be achieved in a much simpler, cheaper way (especially when authentication is achieved with passwords anyway).
So we're not encrypting traffic and not preventing eavesdropping because preventing forged messages is too hard/costly - congratulations!
On the other hand, one should consider the implications of the false sense of security for the layman with only encrypted traffic - which is similar to what we have now with SSL being broken (MD5 etc.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811066</id>
	<title>Re:More direct costs.</title>
	<author>Bengie</author>
	<datestamp>1263845460000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>What is the CPU overhead for Encryption? My brother just installed Truecrypt on his 3.5ghz i7 and it says he can do ~510MB/sec of AES-256.</p><p>Assuming a 100mbit network connection, 12.5MB/sec would be about 2.5\% cpu. If it was a dual socket server, it would be about 1.25\% overhead. If the 100mbit connection was shared by 10 machines, it would be 0.125\% overhead per machine.</p><p>My statement makes the assumptions of similar CPU performance to my brothers 3.5ghz i7, ignore decrypting incoming data which would be less than outgoing, and uses encryption on the filesystem compared to HTTPS, which would be quite different depending on how it's implemented.</p><p>AMD/Intel both will have HW accel'd AES in the next chips which both claims about 40\% improvement, so typically sub 1\% overhead I would guess.</p></htmltext>
<tokenext>What is the CPU overhead for Encryption ?
My brother just installed Truecrypt on his 3.5ghz i7 and it says he can do ~ 510MB/sec of AES-256.Assuming a 100mbit network connection , 12.5MB/sec would be about 2.5 \ % cpu .
If it was a dual socket server , it would be about 1.25 \ % overhead .
If the 100mbit connection was shared by 10 machines , it would be 0.125 \ % overhead per machine.My statement makes the assumptions of similar CPU performance to my brothers 3.5ghz i7 , ignore decrypting incoming data which would be less than outgoing , and uses encryption on the filesystem compared to HTTPS , which would be quite different depending on how it 's implemented.AMD/Intel both will have HW accel 'd AES in the next chips which both claims about 40 \ % improvement , so typically sub 1 \ % overhead I would guess .</tokentext>
<sentencetext>What is the CPU overhead for Encryption?
My brother just installed Truecrypt on his 3.5ghz i7 and it says he can do ~510MB/sec of AES-256.Assuming a 100mbit network connection, 12.5MB/sec would be about 2.5\% cpu.
If it was a dual socket server, it would be about 1.25\% overhead.
If the 100mbit connection was shared by 10 machines, it would be 0.125\% overhead per machine.My statement makes the assumptions of similar CPU performance to my brothers 3.5ghz i7, ignore decrypting incoming data which would be less than outgoing, and uses encryption on the filesystem compared to HTTPS, which would be quite different depending on how it's implemented.AMD/Intel both will have HW accel'd AES in the next chips which both claims about 40\% improvement, so typically sub 1\% overhead I would guess.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815014</id>
	<title>Many people don't know about encryption...</title>
	<author>Froggels</author>
	<datestamp>1263823680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>and many more could care less. Attempting to explain the benefits of encryption to the most people is at best a waste of time and at worst makes you come across as a babbling paranoid geek with something to hide.

For years I have had GPG setup so that I can send and receive encrypted email; however I can count on no more than one finger the number of times that I have ever sent a "real" encrypted email and that was to verify an oder with thinkgeek.com. I have yet to receive "real" encrypted email from anyone whether it by my bank, or any of the several companies I deal with even though my public key is readily available. I find that most people are simply confused the whole topic.

What I would like to see is for the windows Thunderbird installation routine to include a security setup option that automatically downloads, installs and configures GPG for the user. More people might then start using "secure email/signing" if the option were available by default in their email interface.  Self signed certificates are good enough for most people's purposes and could be dealt with by dumbed down security warnings, eg. "Do you really trust this sender...?. Once trust is properly established the only "flags" of real concern would be when a self signed certificate doesn't match the one that has been previously trusted.</htmltext>
<tokenext>and many more could care less .
Attempting to explain the benefits of encryption to the most people is at best a waste of time and at worst makes you come across as a babbling paranoid geek with something to hide .
For years I have had GPG setup so that I can send and receive encrypted email ; however I can count on no more than one finger the number of times that I have ever sent a " real " encrypted email and that was to verify an oder with thinkgeek.com .
I have yet to receive " real " encrypted email from anyone whether it by my bank , or any of the several companies I deal with even though my public key is readily available .
I find that most people are simply confused the whole topic .
What I would like to see is for the windows Thunderbird installation routine to include a security setup option that automatically downloads , installs and configures GPG for the user .
More people might then start using " secure email/signing " if the option were available by default in their email interface .
Self signed certificates are good enough for most people 's purposes and could be dealt with by dumbed down security warnings , eg .
" Do you really trust this sender... ? .
Once trust is properly established the only " flags " of real concern would be when a self signed certificate does n't match the one that has been previously trusted .</tokentext>
<sentencetext>and many more could care less.
Attempting to explain the benefits of encryption to the most people is at best a waste of time and at worst makes you come across as a babbling paranoid geek with something to hide.
For years I have had GPG setup so that I can send and receive encrypted email; however I can count on no more than one finger the number of times that I have ever sent a "real" encrypted email and that was to verify an oder with thinkgeek.com.
I have yet to receive "real" encrypted email from anyone whether it by my bank, or any of the several companies I deal with even though my public key is readily available.
I find that most people are simply confused the whole topic.
What I would like to see is for the windows Thunderbird installation routine to include a security setup option that automatically downloads, installs and configures GPG for the user.
More people might then start using "secure email/signing" if the option were available by default in their email interface.
Self signed certificates are good enough for most people's purposes and could be dealt with by dumbed down security warnings, eg.
"Do you really trust this sender...?.
Once trust is properly established the only "flags" of real concern would be when a self signed certificate doesn't match the one that has been previously trusted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809734</id>
	<title>From a storage point of view....</title>
	<author>HockeyPuck</author>
	<datestamp>1263839100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There's a large, but slow, movement in the storage area and that is encrypting data at rest.  Either in the disk array or on the tape.  Both require dedicated hardware either in the array or on the tape drive to be practical and not impact performance.  While you can buy current generation tape drives that encrypt data on the fly the pain becomes managing the keys.  Now there's plenty of solutions to do Key Management, however many customers I've worked with on this are always afraid of <i>losing the key.</i>  We tell them to create a hard copy of the encryption key (or put it on a USB thumb drive) and put it in a safe.  You have to be a lot smarter when it comes to dealing with encrypted tapes as it's nolonger in the event of a disaster, "ship the tape from NY to LA" and restore the data. It's also about making sure the correct key is present in the LA datacenter when that tape arrives.</p><p>Dealing with encrypted disk based data can be even tougher, especially when you're dealing with replication (SRDF/timefinder/PPRC/Snapshots etc..)  Because now you're encrypting a volume/lun and replicating that between datacenters.  So either the lun is de-encrypted when it leaves the array or you've got the problem of making sure that the lun/volume stays with it's associated encryption key.</p><p>What's wrong with data at rest from a security standpoint?  It's not walking away with a tape/HD full of encrypted data, it's a compromised hosts that mounts the filesystem or restores the tape. Hosts always have access to unencrypted data. I don't see encryption being used within the application itself until everyone is willing to purchase encryption offload engines for all their servers as it's too taxing on the primary CPU to encrypt everything.</p></htmltext>
<tokenext>There 's a large , but slow , movement in the storage area and that is encrypting data at rest .
Either in the disk array or on the tape .
Both require dedicated hardware either in the array or on the tape drive to be practical and not impact performance .
While you can buy current generation tape drives that encrypt data on the fly the pain becomes managing the keys .
Now there 's plenty of solutions to do Key Management , however many customers I 've worked with on this are always afraid of losing the key .
We tell them to create a hard copy of the encryption key ( or put it on a USB thumb drive ) and put it in a safe .
You have to be a lot smarter when it comes to dealing with encrypted tapes as it 's nolonger in the event of a disaster , " ship the tape from NY to LA " and restore the data .
It 's also about making sure the correct key is present in the LA datacenter when that tape arrives.Dealing with encrypted disk based data can be even tougher , especially when you 're dealing with replication ( SRDF/timefinder/PPRC/Snapshots etc.. ) Because now you 're encrypting a volume/lun and replicating that between datacenters .
So either the lun is de-encrypted when it leaves the array or you 've got the problem of making sure that the lun/volume stays with it 's associated encryption key.What 's wrong with data at rest from a security standpoint ?
It 's not walking away with a tape/HD full of encrypted data , it 's a compromised hosts that mounts the filesystem or restores the tape .
Hosts always have access to unencrypted data .
I do n't see encryption being used within the application itself until everyone is willing to purchase encryption offload engines for all their servers as it 's too taxing on the primary CPU to encrypt everything .</tokentext>
<sentencetext>There's a large, but slow, movement in the storage area and that is encrypting data at rest.
Either in the disk array or on the tape.
Both require dedicated hardware either in the array or on the tape drive to be practical and not impact performance.
While you can buy current generation tape drives that encrypt data on the fly the pain becomes managing the keys.
Now there's plenty of solutions to do Key Management, however many customers I've worked with on this are always afraid of losing the key.
We tell them to create a hard copy of the encryption key (or put it on a USB thumb drive) and put it in a safe.
You have to be a lot smarter when it comes to dealing with encrypted tapes as it's nolonger in the event of a disaster, "ship the tape from NY to LA" and restore the data.
It's also about making sure the correct key is present in the LA datacenter when that tape arrives.Dealing with encrypted disk based data can be even tougher, especially when you're dealing with replication (SRDF/timefinder/PPRC/Snapshots etc..)  Because now you're encrypting a volume/lun and replicating that between datacenters.
So either the lun is de-encrypted when it leaves the array or you've got the problem of making sure that the lun/volume stays with it's associated encryption key.What's wrong with data at rest from a security standpoint?
It's not walking away with a tape/HD full of encrypted data, it's a compromised hosts that mounts the filesystem or restores the tape.
Hosts always have access to unencrypted data.
I don't see encryption being used within the application itself until everyone is willing to purchase encryption offload engines for all their servers as it's too taxing on the primary CPU to encrypt everything.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816572</id>
	<title>Top 2 reasons</title>
	<author>quarkscat</author>
	<datestamp>1263843060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>(1)  The USA government, or more specifically the USA's intelligence agencies, have for decades opposed any meaningful strong encryption that they might have some difficulty breaking, let alone exporting or re-exporting such encryption.  President Clinton's Clipper Chip initiative included the requirement that the keys be sequestered by the government, which destroyed any credibility with businesses or individuals.  These requirements, although relaxed somewhat, still exist to this day.

(2)  USA and foreign computer manufacturers (hardware and software) are compelled to provide either degraded encryption, or else key sequestration to the USA government if they wish to do business with the USA government -- money talks, and big money talks loudly.  Without the ability to easily integrate strong encryption into either the Operating System or the Hardware, the use of encryption is problematic for the generally lazy end-user.  The entire USA IT industry has been subverted and corrupted by the USA intelligence agencies.  Until such time as strong encryption can be shared across national boundaries without fear of any government's intrusion, this situation will persist.</htmltext>
<tokenext>( 1 ) The USA government , or more specifically the USA 's intelligence agencies , have for decades opposed any meaningful strong encryption that they might have some difficulty breaking , let alone exporting or re-exporting such encryption .
President Clinton 's Clipper Chip initiative included the requirement that the keys be sequestered by the government , which destroyed any credibility with businesses or individuals .
These requirements , although relaxed somewhat , still exist to this day .
( 2 ) USA and foreign computer manufacturers ( hardware and software ) are compelled to provide either degraded encryption , or else key sequestration to the USA government if they wish to do business with the USA government -- money talks , and big money talks loudly .
Without the ability to easily integrate strong encryption into either the Operating System or the Hardware , the use of encryption is problematic for the generally lazy end-user .
The entire USA IT industry has been subverted and corrupted by the USA intelligence agencies .
Until such time as strong encryption can be shared across national boundaries without fear of any government 's intrusion , this situation will persist .</tokentext>
<sentencetext>(1)  The USA government, or more specifically the USA's intelligence agencies, have for decades opposed any meaningful strong encryption that they might have some difficulty breaking, let alone exporting or re-exporting such encryption.
President Clinton's Clipper Chip initiative included the requirement that the keys be sequestered by the government, which destroyed any credibility with businesses or individuals.
These requirements, although relaxed somewhat, still exist to this day.
(2)  USA and foreign computer manufacturers (hardware and software) are compelled to provide either degraded encryption, or else key sequestration to the USA government if they wish to do business with the USA government -- money talks, and big money talks loudly.
Without the ability to easily integrate strong encryption into either the Operating System or the Hardware, the use of encryption is problematic for the generally lazy end-user.
The entire USA IT industry has been subverted and corrupted by the USA intelligence agencies.
Until such time as strong encryption can be shared across national boundaries without fear of any government's intrusion, this situation will persist.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816858</id>
	<title>Re:Because it's a PITA - Pain In the Ass!</title>
	<author>Dan541</author>
	<datestamp>1263933600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>It's not needed.  If I'm sending somethig sensitive, I can just encrypt it and send it as an attachment, and give them the password over the phone.</p></div><p>Over the phone? When the key is something like "HjnH6AooMyKzE9HOki6Au2d51wb" screw that, I just include the key in the body of the email. Such an email would actually be compliant with many corporate security policies.</p></div>
	</htmltext>
<tokenext>It 's not needed .
If I 'm sending somethig sensitive , I can just encrypt it and send it as an attachment , and give them the password over the phone.Over the phone ?
When the key is something like " HjnH6AooMyKzE9HOki6Au2d51wb " screw that , I just include the key in the body of the email .
Such an email would actually be compliant with many corporate security policies .</tokentext>
<sentencetext>It's not needed.
If I'm sending somethig sensitive, I can just encrypt it and send it as an attachment, and give them the password over the phone.Over the phone?
When the key is something like "HjnH6AooMyKzE9HOki6Au2d51wb" screw that, I just include the key in the body of the email.
Such an email would actually be compliant with many corporate security policies.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809574</id>
	<title>VoIP and encryption</title>
	<author>JSBiff</author>
	<datestamp>1263838380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>One of the most disturbing trends to me has been the rise of a lot of SIP based VoIP services (and client software) that offers no encryption. The thing is, there's been a couple IETF RFCs which specify how to secure SIP traffic for a few years, I believe (I'm not exactly sure how it all fits together, but I've read about SIPS, ZRTP, and SRTP).</p><p>Skype, of course, does use Encryption, so the most popular VoIP service is using encryption, *but* I'd like to see more VoIP providers offering it as part of their service.</p></htmltext>
<tokenext>One of the most disturbing trends to me has been the rise of a lot of SIP based VoIP services ( and client software ) that offers no encryption .
The thing is , there 's been a couple IETF RFCs which specify how to secure SIP traffic for a few years , I believe ( I 'm not exactly sure how it all fits together , but I 've read about SIPS , ZRTP , and SRTP ) .Skype , of course , does use Encryption , so the most popular VoIP service is using encryption , * but * I 'd like to see more VoIP providers offering it as part of their service .</tokentext>
<sentencetext>One of the most disturbing trends to me has been the rise of a lot of SIP based VoIP services (and client software) that offers no encryption.
The thing is, there's been a couple IETF RFCs which specify how to secure SIP traffic for a few years, I believe (I'm not exactly sure how it all fits together, but I've read about SIPS, ZRTP, and SRTP).Skype, of course, does use Encryption, so the most popular VoIP service is using encryption, *but* I'd like to see more VoIP providers offering it as part of their service.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809584</id>
	<title>Re:Apathy</title>
	<author>theCoder</author>
	<datestamp>1263838440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's not just apathy -- most people don't see a need for encrypting stuff.  Either it's "I'm not important enough" or a belief that it's not really possible to eavesdrop on Internet communications.</p><p>I had this conversation with my father over Christmas.  I was trying to encourage him to digitally sign (PGP) his emails and how that would enable other people to send him encrypted emails.  He wanted to know why, if eavesdropping on the Internet was so common, can't you go Google for people willing to sell you sniffed data.  I couldn't come up with a good answer, because I don't think I've ever even heard of a rogue admin at a Tier 1/2 ISP doing that sort of thing.  The closest I've heard of is the government slurping all data and doing who knows what with it, but probably not selling it.</p><p>So, if I was a nefarious businessperson who wanted to find out the confidential dealings of my competitors just by listening to their Internet traffic, is that even realistic?  Are there people/groups out there that do that?  Is it necessarily even illegal for an ISP to packet dump and then sell the data?  If not, why don't they do that -- or maybe they do?</p><p>I know it's a theoretical possibility, but for many people it's way too theoretical to bother worrying about it.  Some hard information would be helpful.</p></htmltext>
<tokenext>It 's not just apathy -- most people do n't see a need for encrypting stuff .
Either it 's " I 'm not important enough " or a belief that it 's not really possible to eavesdrop on Internet communications.I had this conversation with my father over Christmas .
I was trying to encourage him to digitally sign ( PGP ) his emails and how that would enable other people to send him encrypted emails .
He wanted to know why , if eavesdropping on the Internet was so common , ca n't you go Google for people willing to sell you sniffed data .
I could n't come up with a good answer , because I do n't think I 've ever even heard of a rogue admin at a Tier 1/2 ISP doing that sort of thing .
The closest I 've heard of is the government slurping all data and doing who knows what with it , but probably not selling it.So , if I was a nefarious businessperson who wanted to find out the confidential dealings of my competitors just by listening to their Internet traffic , is that even realistic ?
Are there people/groups out there that do that ?
Is it necessarily even illegal for an ISP to packet dump and then sell the data ?
If not , why do n't they do that -- or maybe they do ? I know it 's a theoretical possibility , but for many people it 's way too theoretical to bother worrying about it .
Some hard information would be helpful .</tokentext>
<sentencetext>It's not just apathy -- most people don't see a need for encrypting stuff.
Either it's "I'm not important enough" or a belief that it's not really possible to eavesdrop on Internet communications.I had this conversation with my father over Christmas.
I was trying to encourage him to digitally sign (PGP) his emails and how that would enable other people to send him encrypted emails.
He wanted to know why, if eavesdropping on the Internet was so common, can't you go Google for people willing to sell you sniffed data.
I couldn't come up with a good answer, because I don't think I've ever even heard of a rogue admin at a Tier 1/2 ISP doing that sort of thing.
The closest I've heard of is the government slurping all data and doing who knows what with it, but probably not selling it.So, if I was a nefarious businessperson who wanted to find out the confidential dealings of my competitors just by listening to their Internet traffic, is that even realistic?
Are there people/groups out there that do that?
Is it necessarily even illegal for an ISP to packet dump and then sell the data?
If not, why don't they do that -- or maybe they do?I know it's a theoretical possibility, but for many people it's way too theoretical to bother worrying about it.
Some hard information would be helpful.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811746</id>
	<title>Re:Encryption is too hard</title>
	<author>cpghost</author>
	<datestamp>1263805440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>The question is why Google or any other provider would bother to do that.</p></div></blockquote><p>

Why would Google do that? They need to be able to peek inside the mails to display their context-sensitive ads, so end-to-end encryption is undesirable for them. And if they have your private key so that everything is transparent -- and usable as ad platform for Google --, what's the point of encrypting mails at all? Even though we can use FireGPG with Gmail today (or GnuPG or whatnot) as end-to-end encryption, as soon as more people start to do it, you bet that Google will react and block it.</p></div>
	</htmltext>
<tokenext>The question is why Google or any other provider would bother to do that .
Why would Google do that ?
They need to be able to peek inside the mails to display their context-sensitive ads , so end-to-end encryption is undesirable for them .
And if they have your private key so that everything is transparent -- and usable as ad platform for Google -- , what 's the point of encrypting mails at all ?
Even though we can use FireGPG with Gmail today ( or GnuPG or whatnot ) as end-to-end encryption , as soon as more people start to do it , you bet that Google will react and block it .</tokentext>
<sentencetext>The question is why Google or any other provider would bother to do that.
Why would Google do that?
They need to be able to peek inside the mails to display their context-sensitive ads, so end-to-end encryption is undesirable for them.
And if they have your private key so that everything is transparent -- and usable as ad platform for Google --, what's the point of encrypting mails at all?
Even though we can use FireGPG with Gmail today (or GnuPG or whatnot) as end-to-end encryption, as soon as more people start to do it, you bet that Google will react and block it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809544</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810658</id>
	<title>Re:I have encrypted this post</title>
	<author>93 Escort Wagon</author>
	<datestamp>1263843360000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu{ywe9f8iunsiochjaijkcs</p><p>The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....</p></div><p>Like many others, you made the mistake of choosing a weak key. Here ya go:</p><p>"Be sure to drink your Ovaltine"</p></div>
	</htmltext>
<tokenext>kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu { ywe9f8iunsiochjaijkcsThe fun part is that the ( UK ) cops can demand a decryption key for that , and lock me up when I inevitably fail to provide one....Like many others , you made the mistake of choosing a weak key .
Here ya go : " Be sure to drink your Ovaltine "</tokentext>
<sentencetext>kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu{ywe9f8iunsiochjaijkcsThe fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....Like many others, you made the mistake of choosing a weak key.
Here ya go:"Be sure to drink your Ovaltine"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810444</id>
	<title>Re:Costs?</title>
	<author>glebovitz</author>
	<datestamp>1263842280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>All of my phones handle ssl or tls security for imap. Otherwise I couldn't use Google imap or my companies email.</p></htmltext>
<tokenext>All of my phones handle ssl or tls security for imap .
Otherwise I could n't use Google imap or my companies email .</tokentext>
<sentencetext>All of my phones handle ssl or tls security for imap.
Otherwise I couldn't use Google imap or my companies email.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816368</id>
	<title>Easy answer</title>
	<author>abulafia</author>
	<datestamp>1263840300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It is orthogonal.</p><p>FTP is unencrypted because what people want to do is get files from point A to point B. Something as simple as scp causes them to see a warning message that the can't quite make sense of, that looks scary, that is not on the critical path between getting files from point A to point B. So, they do what all humans do, which is go back to the lowest common denominator that is not directly related to their chosen career.</p><p>Email? Encryption? Are you fucking kidding me? I knew that was a failure when X509 was pushed. People do now want is-a-person identity verification for themselves, just for everyone else. And it turns out that PGP web of trust sort of key management only works for geeks that like concerning themselves with security. The single best thing that happened to email over the last 12 or so years is admins accepting that opportunistic transport encryption is, yes, basically free and self-signed certs work just as well as that one from Verisign. But, still, this is transport, not storage, so (in the U.S., at least) the legal system intersects, and transport encryption is necessary, but not sufficient, for personal control over one's email. And this is putting aside that a rather large part of the population has migrated to web mail, where they don't even control the storage in the first place, and the service providers have obligations to state actors that are substantially less robust than storing your own damn email on your own damn disk.</p><p>I don't think I've seen an ecommerce shop running on port 80 in 5 or 6 years, but I'm sure there are some out there still. But this ignores that we're really not that worried about people compromising routers and whatnot (I'm not saying it hasn't happened, but that is by no stretch the most common security breach mode for Joe User). Transport encryption doesn't help you when the Chinese government targets you with a zeroday, or even when you're not paying attention on a more generic phishing attack. </p><p>I was on the Cypherpunks list back in the early 90s, and there is a reason why most of the predictions of the use of crypto did not pan out to create a cyber-anarcho-capitalist-utpoia (dystopia?). And that reason is that a lack of crypto is not the weak link, and, as always, the problem exists between chair and keyboard, if you're prone to considering that the problem.</p><p>My view is that people want to get things done, not worry about getting things done securely. And so any time "securely" means even slightly more work, fuck it, it won't happen. And that means even really minor points of friction, because people don't even understand why they're doing these things in the first place. ("Why did my login have to time out? I still want to put things there.")</p><p>Ultimately, the right posture for someone who wishes to promote security is to make it transparent. That's not possible, of course. But we, as a culture, are used to accounting safeguards, CPAs imposing annoying multiparty checks and balances and whatnot, so it isn't impossible that this sort of thing could be pushed to consumers. I'm personally skeptical, because the non-geek consumer has an interest in not caring and the people selling stuff have an interest in catering to that.</p></htmltext>
<tokenext>It is orthogonal.FTP is unencrypted because what people want to do is get files from point A to point B. Something as simple as scp causes them to see a warning message that the ca n't quite make sense of , that looks scary , that is not on the critical path between getting files from point A to point B. So , they do what all humans do , which is go back to the lowest common denominator that is not directly related to their chosen career.Email ?
Encryption ? Are you fucking kidding me ?
I knew that was a failure when X509 was pushed .
People do now want is-a-person identity verification for themselves , just for everyone else .
And it turns out that PGP web of trust sort of key management only works for geeks that like concerning themselves with security .
The single best thing that happened to email over the last 12 or so years is admins accepting that opportunistic transport encryption is , yes , basically free and self-signed certs work just as well as that one from Verisign .
But , still , this is transport , not storage , so ( in the U.S. , at least ) the legal system intersects , and transport encryption is necessary , but not sufficient , for personal control over one 's email .
And this is putting aside that a rather large part of the population has migrated to web mail , where they do n't even control the storage in the first place , and the service providers have obligations to state actors that are substantially less robust than storing your own damn email on your own damn disk.I do n't think I 've seen an ecommerce shop running on port 80 in 5 or 6 years , but I 'm sure there are some out there still .
But this ignores that we 're really not that worried about people compromising routers and whatnot ( I 'm not saying it has n't happened , but that is by no stretch the most common security breach mode for Joe User ) .
Transport encryption does n't help you when the Chinese government targets you with a zeroday , or even when you 're not paying attention on a more generic phishing attack .
I was on the Cypherpunks list back in the early 90s , and there is a reason why most of the predictions of the use of crypto did not pan out to create a cyber-anarcho-capitalist-utpoia ( dystopia ? ) .
And that reason is that a lack of crypto is not the weak link , and , as always , the problem exists between chair and keyboard , if you 're prone to considering that the problem.My view is that people want to get things done , not worry about getting things done securely .
And so any time " securely " means even slightly more work , fuck it , it wo n't happen .
And that means even really minor points of friction , because people do n't even understand why they 're doing these things in the first place .
( " Why did my login have to time out ?
I still want to put things there .
" ) Ultimately , the right posture for someone who wishes to promote security is to make it transparent .
That 's not possible , of course .
But we , as a culture , are used to accounting safeguards , CPAs imposing annoying multiparty checks and balances and whatnot , so it is n't impossible that this sort of thing could be pushed to consumers .
I 'm personally skeptical , because the non-geek consumer has an interest in not caring and the people selling stuff have an interest in catering to that .</tokentext>
<sentencetext>It is orthogonal.FTP is unencrypted because what people want to do is get files from point A to point B. Something as simple as scp causes them to see a warning message that the can't quite make sense of, that looks scary, that is not on the critical path between getting files from point A to point B. So, they do what all humans do, which is go back to the lowest common denominator that is not directly related to their chosen career.Email?
Encryption? Are you fucking kidding me?
I knew that was a failure when X509 was pushed.
People do now want is-a-person identity verification for themselves, just for everyone else.
And it turns out that PGP web of trust sort of key management only works for geeks that like concerning themselves with security.
The single best thing that happened to email over the last 12 or so years is admins accepting that opportunistic transport encryption is, yes, basically free and self-signed certs work just as well as that one from Verisign.
But, still, this is transport, not storage, so (in the U.S., at least) the legal system intersects, and transport encryption is necessary, but not sufficient, for personal control over one's email.
And this is putting aside that a rather large part of the population has migrated to web mail, where they don't even control the storage in the first place, and the service providers have obligations to state actors that are substantially less robust than storing your own damn email on your own damn disk.I don't think I've seen an ecommerce shop running on port 80 in 5 or 6 years, but I'm sure there are some out there still.
But this ignores that we're really not that worried about people compromising routers and whatnot (I'm not saying it hasn't happened, but that is by no stretch the most common security breach mode for Joe User).
Transport encryption doesn't help you when the Chinese government targets you with a zeroday, or even when you're not paying attention on a more generic phishing attack.
I was on the Cypherpunks list back in the early 90s, and there is a reason why most of the predictions of the use of crypto did not pan out to create a cyber-anarcho-capitalist-utpoia (dystopia?).
And that reason is that a lack of crypto is not the weak link, and, as always, the problem exists between chair and keyboard, if you're prone to considering that the problem.My view is that people want to get things done, not worry about getting things done securely.
And so any time "securely" means even slightly more work, fuck it, it won't happen.
And that means even really minor points of friction, because people don't even understand why they're doing these things in the first place.
("Why did my login have to time out?
I still want to put things there.
")Ultimately, the right posture for someone who wishes to promote security is to make it transparent.
That's not possible, of course.
But we, as a culture, are used to accounting safeguards, CPAs imposing annoying multiparty checks and balances and whatnot, so it isn't impossible that this sort of thing could be pushed to consumers.
I'm personally skeptical, because the non-geek consumer has an interest in not caring and the people selling stuff have an interest in catering to that.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809320</id>
	<title>Talking out loud ...</title>
	<author>daveywest</author>
	<datestamp>1263837240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>How often do you speak out loud in a public place?</p><p>None of that is encrypted.  Someone might overhear you.  Break out the tin foil hats!!!!</p></htmltext>
<tokenext>How often do you speak out loud in a public place ? None of that is encrypted .
Someone might overhear you .
Break out the tin foil hats ! ! !
!</tokentext>
<sentencetext>How often do you speak out loud in a public place?None of that is encrypted.
Someone might overhear you.
Break out the tin foil hats!!!
!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30842142</id>
	<title>Encryption doesn't have to be complicated...</title>
	<author>Anonymous</author>
	<datestamp>1264008120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Encryption made easy for the average user.  Try https://www.threadthat.com.  Effective and simple.</p></htmltext>
<tokenext>Encryption made easy for the average user .
Try https : //www.threadthat.com .
Effective and simple .</tokentext>
<sentencetext>Encryption made easy for the average user.
Try https://www.threadthat.com.
Effective and simple.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810030</id>
	<title>Re:People don't see the value</title>
	<author>Anonymous</author>
	<datestamp>1263840360000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>'To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.'</p><p>That will never happen and it doesn't need to. What needs to happen is a non-profit browser recognized CA that issues domain wildcard certs to the technical contact e-mail address. Then people will use encryption for the web.</p><p>There is no point in establishing identity beyond this standard. This demonstrates control of the domain, and if you have control of the domain you can compromise the experience for the user anyway.</p></htmltext>
<tokenext>'To answer the original question , the thing holding back encryption is the above mistaken attitude , that using a self-signed cert is barely better than using plaintext .
'That will never happen and it does n't need to .
What needs to happen is a non-profit browser recognized CA that issues domain wildcard certs to the technical contact e-mail address .
Then people will use encryption for the web.There is no point in establishing identity beyond this standard .
This demonstrates control of the domain , and if you have control of the domain you can compromise the experience for the user anyway .</tokentext>
<sentencetext>'To answer the original question, the thing holding back encryption is the above mistaken attitude, that using a self-signed cert is barely better than using plaintext.
'That will never happen and it doesn't need to.
What needs to happen is a non-profit browser recognized CA that issues domain wildcard certs to the technical contact e-mail address.
Then people will use encryption for the web.There is no point in establishing identity beyond this standard.
This demonstrates control of the domain, and if you have control of the domain you can compromise the experience for the user anyway.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814240</id>
	<title>Re:Costs?</title>
	<author>ArsenneLupin</author>
	<datestamp>1263817800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The Nokia E61i that I bought 2 years ago does SSL Imap out of the box. Probably nowadays <em>all</em> non-Microsoft and non-Apple smartphones can do it too.</htmltext>
<tokenext>The Nokia E61i that I bought 2 years ago does SSL Imap out of the box .
Probably nowadays all non-Microsoft and non-Apple smartphones can do it too .</tokentext>
<sentencetext>The Nokia E61i that I bought 2 years ago does SSL Imap out of the box.
Probably nowadays all non-Microsoft and non-Apple smartphones can do it too.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804</id>
	<title>Signed certificates</title>
	<author>Spazmania</author>
	<datestamp>1263835140000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Signed certificates are holding up encryption. Opportunistic encryption doesn't happen if it has to be carefully pre-planned.</p><p>Yes, unsigned encryption is vulnerable to MITM. So what? It protects against the far more common traffic sniffing and a plethora of other attacks.</p></htmltext>
<tokenext>Signed certificates are holding up encryption .
Opportunistic encryption does n't happen if it has to be carefully pre-planned.Yes , unsigned encryption is vulnerable to MITM .
So what ?
It protects against the far more common traffic sniffing and a plethora of other attacks .</tokentext>
<sentencetext>Signed certificates are holding up encryption.
Opportunistic encryption doesn't happen if it has to be carefully pre-planned.Yes, unsigned encryption is vulnerable to MITM.
So what?
It protects against the far more common traffic sniffing and a plethora of other attacks.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</id>
	<title>I have encrypted this post</title>
	<author>fridaynightsmoke</author>
	<datestamp>1263835080000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>I have encrypted this post as my contribution to making encryption more widespread.</p><p>Here you go:<br>
kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu{ywe9f8iunsiochjaijkcs</p><p>The fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....</p></htmltext>
<tokenext>I have encrypted this post as my contribution to making encryption more widespread.Here you go : kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu { ywe9f8iunsiochjaijkcsThe fun part is that the ( UK ) cops can demand a decryption key for that , and lock me up when I inevitably fail to provide one... .</tokentext>
<sentencetext>I have encrypted this post as my contribution to making encryption more widespread.Here you go:
kkjkjGHIUgibilhjGHLiubhjbiu78HVji67gfUKGHVuygjh VljhbvolygILJKbIyugIJbikhjbKJBkbvkjnfJ.a,mx jchkdjqJiufhpi9fu{ywe9f8iunsiochjaijkcsThe fun part is that the (UK) cops can demand a decryption key for that, and lock me up when I inevitably fail to provide one....</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811434</id>
	<title>There's an obvious answer - most people don't need</title>
	<author>Johan Welin</author>
	<datestamp>1263847140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Seriously, what data do you absolutely require to be encrypted?
I would speculate that most data that one transfer across the net will impose no harm to yourself or your peers. Sure some data will eventually be picked up by some services and may, or may not, be used for commercial uses (ad's maybe). If you don't want that you can often opt for other services or use encrypted protocols.</htmltext>
<tokenext>Seriously , what data do you absolutely require to be encrypted ?
I would speculate that most data that one transfer across the net will impose no harm to yourself or your peers .
Sure some data will eventually be picked up by some services and may , or may not , be used for commercial uses ( ad 's maybe ) .
If you do n't want that you can often opt for other services or use encrypted protocols .</tokentext>
<sentencetext>Seriously, what data do you absolutely require to be encrypted?
I would speculate that most data that one transfer across the net will impose no harm to yourself or your peers.
Sure some data will eventually be picked up by some services and may, or may not, be used for commercial uses (ad's maybe).
If you don't want that you can often opt for other services or use encrypted protocols.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809344</id>
	<title>Dan Kaminsky got it right</title>
	<author>Anonymous</author>
	<datestamp>1263837360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I think the reason is the utter failure that current PKI infrastructure is. Dan Kaminsky's talk at 26C3 opened my eyes:<br>http://www.youtube.com/watch?v=RE\_Z-HKzRW0</p></htmltext>
<tokenext>I think the reason is the utter failure that current PKI infrastructure is .
Dan Kaminsky 's talk at 26C3 opened my eyes : http : //www.youtube.com/watch ? v = RE \ _Z-HKzRW0</tokentext>
<sentencetext>I think the reason is the utter failure that current PKI infrastructure is.
Dan Kaminsky's talk at 26C3 opened my eyes:http://www.youtube.com/watch?v=RE\_Z-HKzRW0</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808872</id>
	<title>Inertia</title>
	<author>Anonymous</author>
	<datestamp>1263835380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><br> <i>What's Holding Back Encryption?</i> <br> <br>Simple: INERTIA.<br> <br>
Remember back in the day when the OpenBSD guys said Enough Already and
pretty much dropped telnet, rsh, rcp, rlogin, etc.  for the SSH suite of
tools?  Yeah, a bit of growing pains at the time but no one would want to go
back.  It took some time but finally other open source projects followed
suit.<br> <br>People are lazy, if there's no push to change most won't no
matter what benefit the change offers.</htmltext>
<tokenext>What 's Holding Back Encryption ?
Simple : INERTIA .
Remember back in the day when the OpenBSD guys said Enough Already and pretty much dropped telnet , rsh , rcp , rlogin , etc .
for the SSH suite of tools ?
Yeah , a bit of growing pains at the time but no one would want to go back .
It took some time but finally other open source projects followed suit .
People are lazy , if there 's no push to change most wo n't no matter what benefit the change offers .</tokentext>
<sentencetext> What's Holding Back Encryption?
Simple: INERTIA.
Remember back in the day when the OpenBSD guys said Enough Already and
pretty much dropped telnet, rsh, rcp, rlogin, etc.
for the SSH suite of
tools?
Yeah, a bit of growing pains at the time but no one would want to go
back.
It took some time but finally other open source projects followed
suit.
People are lazy, if there's no push to change most won't no
matter what benefit the change offers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813710</id>
	<title>Re:VS Electronic-Arts</title>
	<author>julesh</author>
	<datestamp>1263814800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>I wish *EA* would use hashes or something of the sort on their databases. Last time I tried to reset my password the damn thing mailed me that actual PW in plaintext, which indicates to me that they're too stupid to realize that:</p><p>a) Storing non-hashed passwords in a DB is a good way to get hacked and expose all your customers accounts. It's really quite dumb<br>b) Email is an insecure medium for sending somebody's password down the wire</p></div></blockquote><p>You can guarantee there's a dev team and a DBA who sat over there in EA's offices, tearing their hear out en masse over this decision.  Fact is, it happens all the time, and the cause is very simple: management writing functional specifications of software.  Somebody, somewhere, put on the functional spec that there must be a password recovery function that sends your original password back to you.  That person didn't understand encryption, and was too sure of himself and his ideas about how the system's supposed to work to listen to lowly <i>developers</i> about whether or not it's a good idea.  Of course it's a good idea.  He's the boss for a reason, you know?</p></div>
	</htmltext>
<tokenext>I wish * EA * would use hashes or something of the sort on their databases .
Last time I tried to reset my password the damn thing mailed me that actual PW in plaintext , which indicates to me that they 're too stupid to realize that : a ) Storing non-hashed passwords in a DB is a good way to get hacked and expose all your customers accounts .
It 's really quite dumbb ) Email is an insecure medium for sending somebody 's password down the wireYou can guarantee there 's a dev team and a DBA who sat over there in EA 's offices , tearing their hear out en masse over this decision .
Fact is , it happens all the time , and the cause is very simple : management writing functional specifications of software .
Somebody , somewhere , put on the functional spec that there must be a password recovery function that sends your original password back to you .
That person did n't understand encryption , and was too sure of himself and his ideas about how the system 's supposed to work to listen to lowly developers about whether or not it 's a good idea .
Of course it 's a good idea .
He 's the boss for a reason , you know ?</tokentext>
<sentencetext>I wish *EA* would use hashes or something of the sort on their databases.
Last time I tried to reset my password the damn thing mailed me that actual PW in plaintext, which indicates to me that they're too stupid to realize that:a) Storing non-hashed passwords in a DB is a good way to get hacked and expose all your customers accounts.
It's really quite dumbb) Email is an insecure medium for sending somebody's password down the wireYou can guarantee there's a dev team and a DBA who sat over there in EA's offices, tearing their hear out en masse over this decision.
Fact is, it happens all the time, and the cause is very simple: management writing functional specifications of software.
Somebody, somewhere, put on the functional spec that there must be a password recovery function that sends your original password back to you.
That person didn't understand encryption, and was too sure of himself and his ideas about how the system's supposed to work to listen to lowly developers about whether or not it's a good idea.
Of course it's a good idea.
He's the boss for a reason, you know?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810164</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808828</id>
	<title>Nothing</title>
	<author>Anonymous</author>
	<datestamp>1263835260000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>Most websites are using unencrypted http for sending non-secure public pages and most people don't use email for secure transmissions and consider it almost public.</p><p>The fact that everything is not encrypted does not indicate that anything is being held back.</p><p>Encryption has transmission and management costs. It is not "free" so it will never be ubiquitous.</p></htmltext>
<tokenext>Most websites are using unencrypted http for sending non-secure public pages and most people do n't use email for secure transmissions and consider it almost public.The fact that everything is not encrypted does not indicate that anything is being held back.Encryption has transmission and management costs .
It is not " free " so it will never be ubiquitous .</tokentext>
<sentencetext>Most websites are using unencrypted http for sending non-secure public pages and most people don't use email for secure transmissions and consider it almost public.The fact that everything is not encrypted does not indicate that anything is being held back.Encryption has transmission and management costs.
It is not "free" so it will never be ubiquitous.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811356</id>
	<title>Webmail killed email encryption</title>
	<author>dokebi</author>
	<datestamp>1263846780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Back in the late 90's I was hopeful that easy to use encryption plug-ins for mail clients would finally bring encryption to the masses. But when gmail came along, with a Gig of space and full text search through your past, end-to-end encryption was finished.</p><p>Currently I'm hoping for crypto id tokens to catch on to stop all the id theft issues, but I'm not exactly holding my breath.</p><p>I think the only feasible thing for that is for the Government to hand out crypto tokens with a central auth server, and severe penalties for abuse (much like mail fraud), so that at least there is one *good* way to be identified as who you say you are.</p><p>Say what you will about Big Brother, but at least voters can do something about government abuse of personal information. Corporate abuse is absolutely unregulated.</p></htmltext>
<tokenext>Back in the late 90 's I was hopeful that easy to use encryption plug-ins for mail clients would finally bring encryption to the masses .
But when gmail came along , with a Gig of space and full text search through your past , end-to-end encryption was finished.Currently I 'm hoping for crypto id tokens to catch on to stop all the id theft issues , but I 'm not exactly holding my breath.I think the only feasible thing for that is for the Government to hand out crypto tokens with a central auth server , and severe penalties for abuse ( much like mail fraud ) , so that at least there is one * good * way to be identified as who you say you are.Say what you will about Big Brother , but at least voters can do something about government abuse of personal information .
Corporate abuse is absolutely unregulated .</tokentext>
<sentencetext>Back in the late 90's I was hopeful that easy to use encryption plug-ins for mail clients would finally bring encryption to the masses.
But when gmail came along, with a Gig of space and full text search through your past, end-to-end encryption was finished.Currently I'm hoping for crypto id tokens to catch on to stop all the id theft issues, but I'm not exactly holding my breath.I think the only feasible thing for that is for the Government to hand out crypto tokens with a central auth server, and severe penalties for abuse (much like mail fraud), so that at least there is one *good* way to be identified as who you say you are.Say what you will about Big Brother, but at least voters can do something about government abuse of personal information.
Corporate abuse is absolutely unregulated.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816182</id>
	<title>Re:Thoughts on Email and DNSSEC</title>
	<author>Anonymous</author>
	<datestamp>1263837060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Oh yes. Most people are using webmail now anyway. I don't understand why they find it easier to learn several web interfaces than one email client and why they trust some server over their harddisk, but that's how it is. I don't know of any webmail interface with PGP support. GMail does verify sigs now, but for encryption you still need a browser plugin such as FirePG.</p><p>And the frontends suck. To use OTR in instant messaging, you don't have to do anything. It will switch encryption on automatically when both parties support it. To use PGP in Thunderbird with Enigmail, you have to read through long manuals, generate keys, find a safe place for your private key, and do all the en/decrypting/signing/verifying by hand. Why can't it just look up every new recipient's email address in the background and encrypt by default without me having to click on anything?</p><p>It's almost as if developers didn't want normal people to use encryption. Which makes it more dangerous for the geeks that do use it, because it singles out their traffic.</p></htmltext>
<tokenext>Oh yes .
Most people are using webmail now anyway .
I do n't understand why they find it easier to learn several web interfaces than one email client and why they trust some server over their harddisk , but that 's how it is .
I do n't know of any webmail interface with PGP support .
GMail does verify sigs now , but for encryption you still need a browser plugin such as FirePG.And the frontends suck .
To use OTR in instant messaging , you do n't have to do anything .
It will switch encryption on automatically when both parties support it .
To use PGP in Thunderbird with Enigmail , you have to read through long manuals , generate keys , find a safe place for your private key , and do all the en/decrypting/signing/verifying by hand .
Why ca n't it just look up every new recipient 's email address in the background and encrypt by default without me having to click on anything ? It 's almost as if developers did n't want normal people to use encryption .
Which makes it more dangerous for the geeks that do use it , because it singles out their traffic .</tokentext>
<sentencetext>Oh yes.
Most people are using webmail now anyway.
I don't understand why they find it easier to learn several web interfaces than one email client and why they trust some server over their harddisk, but that's how it is.
I don't know of any webmail interface with PGP support.
GMail does verify sigs now, but for encryption you still need a browser plugin such as FirePG.And the frontends suck.
To use OTR in instant messaging, you don't have to do anything.
It will switch encryption on automatically when both parties support it.
To use PGP in Thunderbird with Enigmail, you have to read through long manuals, generate keys, find a safe place for your private key, and do all the en/decrypting/signing/verifying by hand.
Why can't it just look up every new recipient's email address in the background and encrypt by default without me having to click on anything?It's almost as if developers didn't want normal people to use encryption.
Which makes it more dangerous for the geeks that do use it, because it singles out their traffic.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810454</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809606</id>
	<title>The Stone Cutters at work again</title>
	<author>ZuluZero</author>
	<datestamp>1263838560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Who reads your plain text mail?
We do, we do!</htmltext>
<tokenext>Who reads your plain text mail ?
We do , we do !</tokentext>
<sentencetext>Who reads your plain text mail?
We do, we do!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814</id>
	<title>Apathy</title>
	<author>quangdog</author>
	<datestamp>1263835200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>I think that much more often than not most folks just use the default settings on their stuff, and at this point nearly all encryption is not something that is set up by default.
<br> <br>
While the learning curve for using encryption in email, http, ftp, etc is not all that high, there is enough of one there for most people to just say "meh", even if they understand why they should be using encryption in the first place.
<br> <br>
It's like personal home protection for many people - they don't want a gun in the house until after they've been robbed the first time.  I'd wager that many people using encryption are doing so because they've been bitten by a lack of encryption in the past.</htmltext>
<tokenext>I think that much more often than not most folks just use the default settings on their stuff , and at this point nearly all encryption is not something that is set up by default .
While the learning curve for using encryption in email , http , ftp , etc is not all that high , there is enough of one there for most people to just say " meh " , even if they understand why they should be using encryption in the first place .
It 's like personal home protection for many people - they do n't want a gun in the house until after they 've been robbed the first time .
I 'd wager that many people using encryption are doing so because they 've been bitten by a lack of encryption in the past .</tokentext>
<sentencetext>I think that much more often than not most folks just use the default settings on their stuff, and at this point nearly all encryption is not something that is set up by default.
While the learning curve for using encryption in email, http, ftp, etc is not all that high, there is enough of one there for most people to just say "meh", even if they understand why they should be using encryption in the first place.
It's like personal home protection for many people - they don't want a gun in the house until after they've been robbed the first time.
I'd wager that many people using encryption are doing so because they've been bitten by a lack of encryption in the past.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812744</id>
	<title>Re:I have encrypted this post</title>
	<author>Anonymous</author>
	<datestamp>1263810060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You're right...damn those pesky brits.</p><p>On a related note--I tried decoding your message, but I get two different plaintexts depending upon which one time pad I use to decode it.  Can you please clarify whether or not the message decodes to:</p><p>"please pick up some milk and eggs at the supermarket on the way back home, and your half of the rent check is due in a week.  TTYL."</p><p>OR</p><p>"comrade, we have placed the incendiary device at dropsite 2. Execute plan blue native next tuesday. Praise be to Allah.  -- jackel."</p></htmltext>
<tokenext>You 're right...damn those pesky brits.On a related note--I tried decoding your message , but I get two different plaintexts depending upon which one time pad I use to decode it .
Can you please clarify whether or not the message decodes to : " please pick up some milk and eggs at the supermarket on the way back home , and your half of the rent check is due in a week .
TTYL. " OR " comrade , we have placed the incendiary device at dropsite 2 .
Execute plan blue native next tuesday .
Praise be to Allah .
-- jackel .
"</tokentext>
<sentencetext>You're right...damn those pesky brits.On a related note--I tried decoding your message, but I get two different plaintexts depending upon which one time pad I use to decode it.
Can you please clarify whether or not the message decodes to:"please pick up some milk and eggs at the supermarket on the way back home, and your half of the rent check is due in a week.
TTYL."OR"comrade, we have placed the incendiary device at dropsite 2.
Execute plan blue native next tuesday.
Praise be to Allah.
-- jackel.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809368</id>
	<title>Re:too much effort</title>
	<author>Cormacus</author>
	<datestamp>1263837480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've actually had trouble with Thunderbird doing automatic (encryption-like) things with email.  And the trouble didn't stem from Thunderbird, but rather from my recipients.  They noticed that emails coming from me suddenly had an extra icon by them (Thunderbird was signing all my outgoing messages) and they flipped out.  "Why is that icon there?"  "OMGWTFBBQ?!"

So unfortunately even doing automated stuff like that will still run into the under-informed user problem.</htmltext>
<tokenext>I 've actually had trouble with Thunderbird doing automatic ( encryption-like ) things with email .
And the trouble did n't stem from Thunderbird , but rather from my recipients .
They noticed that emails coming from me suddenly had an extra icon by them ( Thunderbird was signing all my outgoing messages ) and they flipped out .
" Why is that icon there ?
" " OMGWTFBBQ ? !
" So unfortunately even doing automated stuff like that will still run into the under-informed user problem .</tokentext>
<sentencetext>I've actually had trouble with Thunderbird doing automatic (encryption-like) things with email.
And the trouble didn't stem from Thunderbird, but rather from my recipients.
They noticed that emails coming from me suddenly had an extra icon by them (Thunderbird was signing all my outgoing messages) and they flipped out.
"Why is that icon there?
"  "OMGWTFBBQ?!
"

So unfortunately even doing automated stuff like that will still run into the under-informed user problem.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808990</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_85</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810030
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811066
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_99</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810658
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810024
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_76</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809544
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810226
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_81</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809366
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817308
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_100</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816656
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811798
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809062
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809306
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30826230
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809306
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812180
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_71</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30818508
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812302
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_73</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816782
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810042
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813592
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_94</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811340
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809544
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812726
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809610
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_97</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810676
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810444
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813804
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_91</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811670
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30828922
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_74</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808990
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809488
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812654
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808910
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30823894
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815548
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808974
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813062
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811730
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808856
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810386
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_89</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810454
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816182
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809620
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_92</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816256
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810312
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810164
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817212
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812972
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809724
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810454
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813844
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816768
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808844
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809316
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_84</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809160
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30819146
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810164
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813710
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809404
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808856
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809406
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_77</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809244
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_80</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809522
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812564
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812492
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810876
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812832
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810362
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809544
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811746
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814240
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_95</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810282
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809300
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30818860
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_78</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808816
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808946
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809578
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810704
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817190
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808974
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814480
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810076
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811154
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809940
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_75</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809676
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809584
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813238
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812284
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_98</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810958
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814172
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_88</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811136
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809830
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_93</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811084
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810176
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809238
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_70</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813290
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_72</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812322
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809134
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810900
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811412
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810556
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811642
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808990
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809368
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_96</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809190
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_87</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810376
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809044
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810086
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_90</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810170
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810556
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_86</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809014
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810212
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809366
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810484
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810472
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809566
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_83</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809358
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_102</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809232
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808922
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810942
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_79</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810556
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813502
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_82</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809106
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_101</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809422
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30823790
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816858
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810384
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_103</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809104
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809320
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813032
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809134
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809780
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812520
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_18_1535222_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815460
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808974
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814480
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813062
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810406
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808922
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810942
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808872
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809566
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809012
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809300
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30818860
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808814
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809044
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811730
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809062
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809404
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809584
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811136
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810076
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810454
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813844
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816182
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808856
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809406
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810150
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809544
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810226
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811746
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812726
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808816
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808946
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809578
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808932
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809238
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809610
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809422
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30823790
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809080
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809320
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813032
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809542
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813290
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814172
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810042
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813592
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809700
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808844
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809316
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810966
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808794
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809106
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809620
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812832
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810386
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809104
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810384
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810658
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812744
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810876
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809724
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809366
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817308
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810484
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808996
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808908
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808804
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810086
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809522
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812564
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809134
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810900
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814266
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808910
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30823894
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808880
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809270
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808800
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808812
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810376
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816858
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809244
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811412
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810176
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809232
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809160
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809410
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809788
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808842
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809190
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811670
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30828922
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811340
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812284
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809892
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808990
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809368
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809488
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808766
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809082
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809786
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816256
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30814240
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810312
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810444
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810362
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810282
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812302
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815460
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817190
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810170
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809830
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816782
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30818508
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812972
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809086
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810704
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812492
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811066
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812654
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813804
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809438
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813238
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810030
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809780
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811084
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810552
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811154
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811798
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810958
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809940
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30815548
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809358
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810472
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808764
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816768
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30816656
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810024
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30819146
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809310
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809676
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810164
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813710
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30817212
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812322
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810556
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811642
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30811762
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813502
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30813618
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810676
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812520
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809014
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810212
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808826
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30809306
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30826230
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30812180
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30808980
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_18_1535222.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_18_1535222.30810922
</commentlist>
</conversation>
