<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_01_13_2150245</id>
	<title>Gmail Moves To HTTPS By Default</title>
	<author>timothy</author>
	<datestamp>1263378840000</datestamp>
	<htmltext>clone53421 writes <i>"Although Gmail has long supported <a href="http://gmailblog.blogspot.com/2008/07/making-security-easier.html">HTTPS as an option</a>, Gmail announced their decision yesterday to <a href="http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html">switch everyone to HTTPS by default</a>: 'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data. Over the last few months, we've been researching the security/latency tradeoff and decided that turning https on for everyone was the right thing to do.' I wonder if this has anything to do with the reports of <a href="http://googleblog.blogspot.com/2010/01/new-approach-to-china.html">Chinese users having their accounts hacked</a>? 'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update. That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers."</i></htmltext>
<tokenext>clone53421 writes " Although Gmail has long supported HTTPS as an option , Gmail announced their decision yesterday to switch everyone to HTTPS by default : 'We initially left the choice of using it up to you because there 's a downside : https can make your mail slower since encrypted data does n't travel across the web as quickly as unencrypted data .
Over the last few months , we 've been researching the security/latency tradeoff and decided that turning https on for everyone was the right thing to do .
' I wonder if this has anything to do with the reports of Chinese users having their accounts hacked ?
'Only two Gmail accounts appear to have been accessed , and that activity was limited to account information ( such as the date the account was created ) and subject line , rather than the content of emails themselves, ' said David Drummond in that blog update .
That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail 's servers .
"</tokentext>
<sentencetext>clone53421 writes "Although Gmail has long supported HTTPS as an option, Gmail announced their decision yesterday to switch everyone to HTTPS by default: 'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.
Over the last few months, we've been researching the security/latency tradeoff and decided that turning https on for everyone was the right thing to do.
' I wonder if this has anything to do with the reports of Chinese users having their accounts hacked?
'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update.
That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761604</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>mpe</author>
	<datestamp>1263500040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>I've long held that the only answer to pervasive surveillance is to encrypt everything.
<br>
It won't stop them from cracking things that attract their attention, but for most things it won't be worth the hassle.</i> <br> <br>Encrypting only some things will draw attention to them, it can also leak information. e.g. communications between alice and bob are encrypted, but not between alice and cath...<br>In the same way if you are going to shred documents it's a good idea to shred everything. Even try and ensure that shredded "confidential documents" are well mixed with shredded "junk documents".</htmltext>
<tokenext>I 've long held that the only answer to pervasive surveillance is to encrypt everything .
It wo n't stop them from cracking things that attract their attention , but for most things it wo n't be worth the hassle .
Encrypting only some things will draw attention to them , it can also leak information .
e.g. communications between alice and bob are encrypted , but not between alice and cath...In the same way if you are going to shred documents it 's a good idea to shred everything .
Even try and ensure that shredded " confidential documents " are well mixed with shredded " junk documents " .</tokentext>
<sentencetext>I've long held that the only answer to pervasive surveillance is to encrypt everything.
It won't stop them from cracking things that attract their attention, but for most things it won't be worth the hassle.
Encrypting only some things will draw attention to them, it can also leak information.
e.g. communications between alice and bob are encrypted, but not between alice and cath...In the same way if you are going to shred documents it's a good idea to shred everything.
Even try and ensure that shredded "confidential documents" are well mixed with shredded "junk documents".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757950</id>
	<title>any experiments already done ?</title>
	<author>Anonymous</author>
	<datestamp>1263385260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'd think someone would have done this analysis for all types of data. Can someone on Slashdot point us to those studies ? Mapping the delay times to user experience may be the missing link but surely some study indicating how decryption/encryption processing will delay response  times.</p></htmltext>
<tokenext>I 'd think someone would have done this analysis for all types of data .
Can someone on Slashdot point us to those studies ?
Mapping the delay times to user experience may be the missing link but surely some study indicating how decryption/encryption processing will delay response times .</tokentext>
<sentencetext>I'd think someone would have done this analysis for all types of data.
Can someone on Slashdot point us to those studies ?
Mapping the delay times to user experience may be the missing link but surely some study indicating how decryption/encryption processing will delay response  times.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758736</id>
	<title>Re:Next step: encryption at rest</title>
	<author>Anonymous</author>
	<datestamp>1263388320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If Google can't serve you ads, what incentive do they have to even provide you this magical secure email service?</p></htmltext>
<tokenext>If Google ca n't serve you ads , what incentive do they have to even provide you this magical secure email service ?</tokentext>
<sentencetext>If Google can't serve you ads, what incentive do they have to even provide you this magical secure email service?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758522</id>
	<title>Gmail gadget for iGoogle</title>
	<author>kindbud</author>
	<datestamp>1263387420000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>I removed the Gmail gadget for iGoogle from my iGoogle homepage, because despite the iGoogle being loaded via HTTPS, the Gmail gadget would use plain HTTP.</p><p>Have they changed the Gmail Gadget to also use HTTPS?  I couldn't find anything about it.</p></htmltext>
<tokenext>I removed the Gmail gadget for iGoogle from my iGoogle homepage , because despite the iGoogle being loaded via HTTPS , the Gmail gadget would use plain HTTP.Have they changed the Gmail Gadget to also use HTTPS ?
I could n't find anything about it .</tokentext>
<sentencetext>I removed the Gmail gadget for iGoogle from my iGoogle homepage, because despite the iGoogle being loaded via HTTPS, the Gmail gadget would use plain HTTP.Have they changed the Gmail Gadget to also use HTTPS?
I couldn't find anything about it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758212</id>
	<title>pochta.ru / smtp.ru</title>
	<author>xororand</author>
	<datestamp>1263386160000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Some free mail providers have been offering HTTPS for a long time, for example the Russian <a href="https://www.pochta.ru/" title="pochta.ru">https://www.pochta.ru/</a> [pochta.ru] . Their web mail interface is decent too. Unfortunately they've been bought out by or merged with "qip" and have dropped their English language option since. It's still usable though and a good option if you need a free mail account with secure authentication outside of the western countries for some reason.</p></htmltext>
<tokenext>Some free mail providers have been offering HTTPS for a long time , for example the Russian https : //www.pochta.ru/ [ pochta.ru ] .
Their web mail interface is decent too .
Unfortunately they 've been bought out by or merged with " qip " and have dropped their English language option since .
It 's still usable though and a good option if you need a free mail account with secure authentication outside of the western countries for some reason .</tokentext>
<sentencetext>Some free mail providers have been offering HTTPS for a long time, for example the Russian https://www.pochta.ru/ [pochta.ru] .
Their web mail interface is decent too.
Unfortunately they've been bought out by or merged with "qip" and have dropped their English language option since.
It's still usable though and a good option if you need a free mail account with secure authentication outside of the western countries for some reason.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757558</id>
	<title>Really?</title>
	<author>rastilin</author>
	<datestamp>1263383460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p> I wonder if this has anything to do with the reports of Chinese users having their accounts hacked?</p></div><p>Really? No, I'm sure it's just a coincidence.</p></div>
	</htmltext>
<tokenext>I wonder if this has anything to do with the reports of Chinese users having their accounts hacked ? Really ?
No , I 'm sure it 's just a coincidence .</tokentext>
<sentencetext> I wonder if this has anything to do with the reports of Chinese users having their accounts hacked?Really?
No, I'm sure it's just a coincidence.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761126</id>
	<title>Re:Yeah, that's a big WTF...</title>
	<author>bendodge</author>
	<datestamp>1263407640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My cynical side says that Google isn't kidding. If you were an ISP, wouldn't you prioritize other services over https since you can't know what it actually is?</p></htmltext>
<tokenext>My cynical side says that Google is n't kidding .
If you were an ISP , would n't you prioritize other services over https since you ca n't know what it actually is ?</tokentext>
<sentencetext>My cynical side says that Google isn't kidding.
If you were an ISP, wouldn't you prioritize other services over https since you can't know what it actually is?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760790</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758026</id>
	<title>Re:No Brainer</title>
	<author>Anonymous</author>
	<datestamp>1263385560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.</i></p><p>Multiply that overhead by millions of email accounts, and you're looking at a significant cost. I'm sure google has already calculated the additional server load &amp; power usage this change will require.</p><p><i>(POP? You're still using POP?)</i></p><p>POP over SSL has been around for a very, very long time.</p><p><i>As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues</i></p><p>Hahaha. Can you show me the option to read yahoo mail using SSL? You can't, because IT DOESN'T EXIST. Google always gave you the option to use https, it just wasn't enabled by default.</p></htmltext>
<tokenext>Encryption has some overhead , but so what ?
It 's not like modern hardware is n't up to it.Multiply that overhead by millions of email accounts , and you 're looking at a significant cost .
I 'm sure google has already calculated the additional server load &amp; power usage this change will require. ( POP ?
You 're still using POP ?
) POP over SSL has been around for a very , very long time.As usual , Google leads the pack in creating groundbreaking technology , and comes in dead last in dealing with the boring stuff , like dealing with security issuesHahaha .
Can you show me the option to read yahoo mail using SSL ?
You ca n't , because IT DOES N'T EXIST .
Google always gave you the option to use https , it just was n't enabled by default .</tokentext>
<sentencetext>Encryption has some overhead, but so what?
It's not like modern hardware isn't up to it.Multiply that overhead by millions of email accounts, and you're looking at a significant cost.
I'm sure google has already calculated the additional server load &amp; power usage this change will require.(POP?
You're still using POP?
)POP over SSL has been around for a very, very long time.As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issuesHahaha.
Can you show me the option to read yahoo mail using SSL?
You can't, because IT DOESN'T EXIST.
Google always gave you the option to use https, it just wasn't enabled by default.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757742</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</id>
	<title>Wait, what?</title>
	<author>Anonymous</author>
	<datestamp>1263383220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i> encrypted data doesn't travel across the web as quickly as unencrypted data. </i></p><p>Why on earth would that be?   Routers don't know whether your data is encrypted or not.  The one difference I can think of is that encrypted data can't be compressed.  But that wouldn't have any effect on latency, just throughput.  And that can be taken care of by compressing the data before you encrypt it anyway.</p></htmltext>
<tokenext>encrypted data does n't travel across the web as quickly as unencrypted data .
Why on earth would that be ?
Routers do n't know whether your data is encrypted or not .
The one difference I can think of is that encrypted data ca n't be compressed .
But that would n't have any effect on latency , just throughput .
And that can be taken care of by compressing the data before you encrypt it anyway .</tokentext>
<sentencetext> encrypted data doesn't travel across the web as quickly as unencrypted data.
Why on earth would that be?
Routers don't know whether your data is encrypted or not.
The one difference I can think of is that encrypted data can't be compressed.
But that wouldn't have any effect on latency, just throughput.
And that can be taken care of by compressing the data before you encrypt it anyway.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757412</id>
	<title>Encrypted data doesn't travel across web as quick</title>
	<author>Anonymous</author>
	<datestamp>1263382560000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p>We need network neutrality for encrypted packets!</p></htmltext>
<tokenext>We need network neutrality for encrypted packets !</tokentext>
<sentencetext>We need network neutrality for encrypted packets!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758716</id>
	<title>Re:Wait, what?</title>
	<author>profplump</author>
	<datestamp>1263388200000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>The article is imprecise, but HTTPS is higher latency, even when network and CPU capacity are sufficient -- setting up an SSL connection requires several more round trips than raw HTTP, so if your latency is higher than 0 it can be noticeably slower to use encrypted connections.</p><p>Encrypted connections also typically have some per-datagram overhead, though that's typically pretty small, and not strictly necessarily on streams if you're willing to give up integrity checks. And there is a CPU load. The CPU factor was mostly relevant 15 years ago, but on low-end systems (phones, for example) it can still be a problem. And on systems with high numbers of connections (servers, for example) it's not necessarily a problem bit it does require more horsepower.</p></htmltext>
<tokenext>The article is imprecise , but HTTPS is higher latency , even when network and CPU capacity are sufficient -- setting up an SSL connection requires several more round trips than raw HTTP , so if your latency is higher than 0 it can be noticeably slower to use encrypted connections.Encrypted connections also typically have some per-datagram overhead , though that 's typically pretty small , and not strictly necessarily on streams if you 're willing to give up integrity checks .
And there is a CPU load .
The CPU factor was mostly relevant 15 years ago , but on low-end systems ( phones , for example ) it can still be a problem .
And on systems with high numbers of connections ( servers , for example ) it 's not necessarily a problem bit it does require more horsepower .</tokentext>
<sentencetext>The article is imprecise, but HTTPS is higher latency, even when network and CPU capacity are sufficient -- setting up an SSL connection requires several more round trips than raw HTTP, so if your latency is higher than 0 it can be noticeably slower to use encrypted connections.Encrypted connections also typically have some per-datagram overhead, though that's typically pretty small, and not strictly necessarily on streams if you're willing to give up integrity checks.
And there is a CPU load.
The CPU factor was mostly relevant 15 years ago, but on low-end systems (phones, for example) it can still be a problem.
And on systems with high numbers of connections (servers, for example) it's not necessarily a problem bit it does require more horsepower.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757944</id>
	<title>Re:iGoogle support?</title>
	<author>amRadioHed</author>
	<datestamp>1263385200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It didn't used to, but it's working for me now. I just checked and my gmail is still set to always use HTTPS.</p></htmltext>
<tokenext>It did n't used to , but it 's working for me now .
I just checked and my gmail is still set to always use HTTPS .</tokentext>
<sentencetext>It didn't used to, but it's working for me now.
I just checked and my gmail is still set to always use HTTPS.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765742</id>
	<title>Re:Use HTTPS on the authentication only?</title>
	<author>clone53421</author>
	<datestamp>1263489960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You seem to be drawing a distinction between &ldquo;privacy&rdquo; and &ldquo;security&rdquo;... if they can&rsquo;t steal your authentication data since it&rsquo;s sent encrypted, but they can see all of the e-mails you read as they&rsquo;re transmitted in the clear, your account is &ldquo;secure&rdquo; but not &ldquo;private&rdquo;?</p></htmltext>
<tokenext>You seem to be drawing a distinction between    privacy    and    security    ... if they can    t steal your authentication data since it    s sent encrypted , but they can see all of the e-mails you read as they    re transmitted in the clear , your account is    secure    but not    private    ?</tokentext>
<sentencetext>You seem to be drawing a distinction between “privacy” and “security”... if they can’t steal your authentication data since it’s sent encrypted, but they can see all of the e-mails you read as they’re transmitted in the clear, your account is “secure” but not “private”?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758688</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757766</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>Anonymous</author>
	<datestamp>1263384300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Not much point with gmail though. If the power that be wanted access to your account they would simply look up Google's "lawful interception" pricelist and pay them the $40.</p></htmltext>
<tokenext>Not much point with gmail though .
If the power that be wanted access to your account they would simply look up Google 's " lawful interception " pricelist and pay them the $ 40 .</tokentext>
<sentencetext>Not much point with gmail though.
If the power that be wanted access to your account they would simply look up Google's "lawful interception" pricelist and pay them the $40.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758666</id>
	<title>Correction to summary</title>
	<author>metrometro</author>
	<datestamp>1263388020000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>"Only two Gmail accounts appear to have been accessed"...  <b>by attacking Google systems directly.</b> Using other methods, the attackers were highly successful.</p><p>Google disclosed that upon investigating users suspected of being attacked, they found "dozens" of Chinese human rights activists who had been compromised through phishing, malware or other systems that allowed security forces (presumably) to read their mail via a valid authentication. So, while Google itself may be mostly reliable on the backend, the security ecosystem as a whole is deeply flawed.</p><p>Google: "as part of this investigation but independent of the attack on Google, we have discovered that the accounts of dozens of U.S.-, China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties. These accounts have not been accessed through any security breach at Google, but most likely via phishing scams or malware placed on the users' computers."<br><a href="http://googleblog.blogspot.com/2010/01/new-approach-to-china.html" title="blogspot.com">http://googleblog.blogspot.com/2010/01/new-approach-to-china.html</a> [blogspot.com]</p><p>So go change your passwords.</p></htmltext>
<tokenext>" Only two Gmail accounts appear to have been accessed " ... by attacking Google systems directly .
Using other methods , the attackers were highly successful.Google disclosed that upon investigating users suspected of being attacked , they found " dozens " of Chinese human rights activists who had been compromised through phishing , malware or other systems that allowed security forces ( presumably ) to read their mail via a valid authentication .
So , while Google itself may be mostly reliable on the backend , the security ecosystem as a whole is deeply flawed.Google : " as part of this investigation but independent of the attack on Google , we have discovered that the accounts of dozens of U.S.- , China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties .
These accounts have not been accessed through any security breach at Google , but most likely via phishing scams or malware placed on the users ' computers .
" http : //googleblog.blogspot.com/2010/01/new-approach-to-china.html [ blogspot.com ] So go change your passwords .</tokentext>
<sentencetext>"Only two Gmail accounts appear to have been accessed"...  by attacking Google systems directly.
Using other methods, the attackers were highly successful.Google disclosed that upon investigating users suspected of being attacked, they found "dozens" of Chinese human rights activists who had been compromised through phishing, malware or other systems that allowed security forces (presumably) to read their mail via a valid authentication.
So, while Google itself may be mostly reliable on the backend, the security ecosystem as a whole is deeply flawed.Google: "as part of this investigation but independent of the attack on Google, we have discovered that the accounts of dozens of U.S.-, China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties.
These accounts have not been accessed through any security breach at Google, but most likely via phishing scams or malware placed on the users' computers.
"http://googleblog.blogspot.com/2010/01/new-approach-to-china.html [blogspot.com]So go change your passwords.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762264</id>
	<title>Re:Wait, what?</title>
	<author>Xest</author>
	<datestamp>1263467940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Maybe it's because GCHQ/NSA's monitoring operation have to decrypt the mail first after intercepting it before mining it if it's encrypted<nobr> <wbr></nobr>:p</p></htmltext>
<tokenext>Maybe it 's because GCHQ/NSA 's monitoring operation have to decrypt the mail first after intercepting it before mining it if it 's encrypted : p</tokentext>
<sentencetext>Maybe it's because GCHQ/NSA's monitoring operation have to decrypt the mail first after intercepting it before mining it if it's encrypted :p</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757560</id>
	<title>Keyloggers</title>
	<author>Anonymous</author>
	<datestamp>1263383460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Unless you're entering your details via a virtual keyboard, using http or https won't make a damn bit of difference if you've got a keylogger running. (via trojan? I believe that's how the Chinese accounts were hacked)</p></htmltext>
<tokenext>Unless you 're entering your details via a virtual keyboard , using http or https wo n't make a damn bit of difference if you 've got a keylogger running .
( via trojan ?
I believe that 's how the Chinese accounts were hacked )</tokentext>
<sentencetext>Unless you're entering your details via a virtual keyboard, using http or https won't make a damn bit of difference if you've got a keylogger running.
(via trojan?
I believe that's how the Chinese accounts were hacked)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760150</id>
	<title>SSL requires a ton of CPU power</title>
	<author>Myria</author>
	<datestamp>1263397500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.</p></div><p>We recently bought servers with their cryptography performance as a huge factor in our decision.  The primary math operation required for SSL, modular exponentiation, is extremely expensive in CPU use.  It is still the #1 item on CPU profiling charts for the servers.</p><p>We actually went to 64-bit just to get the 2x~3x modular exponentiation performance it provides.</p><p>Also, this CPU cost won't really go down: if you can buy faster machines, so can the crackers.  So you increase the key size.</p></div>
	</htmltext>
<tokenext>Encryption has some overhead , but so what ?
It 's not like modern hardware is n't up to it.We recently bought servers with their cryptography performance as a huge factor in our decision .
The primary math operation required for SSL , modular exponentiation , is extremely expensive in CPU use .
It is still the # 1 item on CPU profiling charts for the servers.We actually went to 64-bit just to get the 2x ~ 3x modular exponentiation performance it provides.Also , this CPU cost wo n't really go down : if you can buy faster machines , so can the crackers .
So you increase the key size .</tokentext>
<sentencetext>Encryption has some overhead, but so what?
It's not like modern hardware isn't up to it.We recently bought servers with their cryptography performance as a huge factor in our decision.
The primary math operation required for SSL, modular exponentiation, is extremely expensive in CPU use.
It is still the #1 item on CPU profiling charts for the servers.We actually went to 64-bit just to get the 2x~3x modular exponentiation performance it provides.Also, this CPU cost won't really go down: if you can buy faster machines, so can the crackers.
So you increase the key size.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757742</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757966</id>
	<title>HTTP sends more than just subject line...</title>
	<author>Omeganon</author>
	<datestamp>1263385320000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update. That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers.</p></div></blockquote><p>No, if that were the case they would have been able to see *everything* the user received as part of the data response, including message bodies.</p></div>
	</htmltext>
<tokenext>'Only two Gmail accounts appear to have been accessed , and that activity was limited to account information ( such as the date the account was created ) and subject line , rather than the content of emails themselves, ' said David Drummond in that blog update .
That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail 's servers.No , if that were the case they would have been able to see * everything * the user received as part of the data response , including message bodies .</tokentext>
<sentencetext>'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update.
That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers.No, if that were the case they would have been able to see *everything* the user received as part of the data response, including message bodies.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757742</id>
	<title>No Brainer</title>
	<author>fm6</author>
	<datestamp>1263384180000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.</p><p>Anybody who cares about security has stopped using open protocols to send sensitive data. FTP is out, SFTP is in. Goodbye Telnet, hello SSH. And anybody who sends passwords over an open HTTP, SMTP, or IMAP connection is begging to be hacked. (POP? You're still using POP?) The issue is not security versus performance, it's the usual case of people not going to the trouble of upgrading their technology until they can't ignore the problem any more.</p><p>As usual, Google  leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues, or making sure you the resources to properly support your latest product. They need to hire fewer geniuses and start hiring more ordinary drudges with the patience to make things work in the real world.</p></htmltext>
<tokenext>Encryption has some overhead , but so what ?
It 's not like modern hardware is n't up to it.Anybody who cares about security has stopped using open protocols to send sensitive data .
FTP is out , SFTP is in .
Goodbye Telnet , hello SSH .
And anybody who sends passwords over an open HTTP , SMTP , or IMAP connection is begging to be hacked .
( POP ? You 're still using POP ?
) The issue is not security versus performance , it 's the usual case of people not going to the trouble of upgrading their technology until they ca n't ignore the problem any more.As usual , Google leads the pack in creating groundbreaking technology , and comes in dead last in dealing with the boring stuff , like dealing with security issues , or making sure you the resources to properly support your latest product .
They need to hire fewer geniuses and start hiring more ordinary drudges with the patience to make things work in the real world .</tokentext>
<sentencetext>Encryption has some overhead, but so what?
It's not like modern hardware isn't up to it.Anybody who cares about security has stopped using open protocols to send sensitive data.
FTP is out, SFTP is in.
Goodbye Telnet, hello SSH.
And anybody who sends passwords over an open HTTP, SMTP, or IMAP connection is begging to be hacked.
(POP? You're still using POP?
) The issue is not security versus performance, it's the usual case of people not going to the trouble of upgrading their technology until they can't ignore the problem any more.As usual, Google  leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues, or making sure you the resources to properly support your latest product.
They need to hire fewer geniuses and start hiring more ordinary drudges with the patience to make things work in the real world.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762240</id>
	<title>Re:Ouch.</title>
	<author>jimicus</author>
	<datestamp>1263467520000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p> encrypted data doesn't travel across the web as quickly as unencrypted data</p></div><p>That just hurts my brain.</p></div><p>Actually, that is possible.  Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.</p></div>
	</htmltext>
<tokenext>encrypted data does n't travel across the web as quickly as unencrypted dataThat just hurts my brain.Actually , that is possible .
Encrypted data does n't generally compress as well as plaintext , and it 's quite common for web servers to compress data before sending it to the client .</tokentext>
<sentencetext> encrypted data doesn't travel across the web as quickly as unencrypted dataThat just hurts my brain.Actually, that is possible.
Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758778</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758688</id>
	<title>Use HTTPS on the authentication only?</title>
	<author>hrimhari</author>
	<datestamp>1263388140000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Is it obvious to everybody that encrypting everything is good only for privacy but doesn't seem to add much to security when compared to encrypting just the authentication data then using a session ID? Or rather, could the gurus please clarify where's the security increase in putting <b>everything</b> over https?</p></htmltext>
<tokenext>Is it obvious to everybody that encrypting everything is good only for privacy but does n't seem to add much to security when compared to encrypting just the authentication data then using a session ID ?
Or rather , could the gurus please clarify where 's the security increase in putting everything over https ?</tokentext>
<sentencetext>Is it obvious to everybody that encrypting everything is good only for privacy but doesn't seem to add much to security when compared to encrypting just the authentication data then using a session ID?
Or rather, could the gurus please clarify where's the security increase in putting everything over https?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760790</id>
	<title>Yeah, that's a big WTF...</title>
	<author>jonaskoelker</author>
	<datestamp>1263403500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>since encrypted data doesn't travel across the web as quickly as unencrypted data.</p></div><p>It's probably because of all the extra 1's.  They're heavier.</p><p>No, seriously, this statement is bovine excrement.</p><p>What is true is that encrypted <em>transactions</em> (from SYN to FIN) are slower than unencrypted ones because they transmit more <em>data</em> in more <em>packets</em> using more <em>roundtrips</em>.</p><p>Of course, that's not what you tell the (crypto-illiterate) public.  But wouldn't "accessing web pages with HTTPS is typically slower than with HTTP" convey exactly the same information to the public, except for the wrong part?</p></div>
	</htmltext>
<tokenext>since encrypted data does n't travel across the web as quickly as unencrypted data.It 's probably because of all the extra 1 's .
They 're heavier.No , seriously , this statement is bovine excrement.What is true is that encrypted transactions ( from SYN to FIN ) are slower than unencrypted ones because they transmit more data in more packets using more roundtrips.Of course , that 's not what you tell the ( crypto-illiterate ) public .
But would n't " accessing web pages with HTTPS is typically slower than with HTTP " convey exactly the same information to the public , except for the wrong part ?</tokentext>
<sentencetext>since encrypted data doesn't travel across the web as quickly as unencrypted data.It's probably because of all the extra 1's.
They're heavier.No, seriously, this statement is bovine excrement.What is true is that encrypted transactions (from SYN to FIN) are slower than unencrypted ones because they transmit more data in more packets using more roundtrips.Of course, that's not what you tell the (crypto-illiterate) public.
But wouldn't "accessing web pages with HTTPS is typically slower than with HTTP" convey exactly the same information to the public, except for the wrong part?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757412</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760650</id>
	<title>Re:Wait, what?</title>
	<author>kent\_eh</author>
	<datestamp>1263402180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Actually, the more different things that become encrypted the better. <br>
If encrypted traffic becomes the norm, then the act of encrypting something <i>looks</i> a lot less suspicious (whether or not you are actually doing something suspicious)</htmltext>
<tokenext>Actually , the more different things that become encrypted the better .
If encrypted traffic becomes the norm , then the act of encrypting something looks a lot less suspicious ( whether or not you are actually doing something suspicious )</tokentext>
<sentencetext>Actually, the more different things that become encrypted the better.
If encrypted traffic becomes the norm, then the act of encrypting something looks a lot less suspicious (whether or not you are actually doing something suspicious)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757734</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757408</id>
	<title>Hang on...</title>
	<author>Anonymous</author>
	<datestamp>1263382560000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p><i>That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers."</i></p><p>If someone can intercept your traffic how will this help?  They can intercept all your secret handshake bits too.</p></htmltext>
<tokenext>That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail 's servers .
" If someone can intercept your traffic how will this help ?
They can intercept all your secret handshake bits too .</tokentext>
<sentencetext>That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers.
"If someone can intercept your traffic how will this help?
They can intercept all your secret handshake bits too.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757804</id>
	<title>Re:iGoogle support?</title>
	<author>Elwood P Dowd</author>
	<datestamp>1263384480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I believe it does. I'm not sniffing, so I could be wrong here. Do you have any explanation for this statement?</p></htmltext>
<tokenext>I believe it does .
I 'm not sniffing , so I could be wrong here .
Do you have any explanation for this statement ?</tokentext>
<sentencetext>I believe it does.
I'm not sniffing, so I could be wrong here.
Do you have any explanation for this statement?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759044</id>
	<title>Re:Will Yahoo! follow suit?</title>
	<author>Anonymous</author>
	<datestamp>1263389700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Anyone care to guess if Yahoo! will so the same thing?</p><p>I really hope so. I use a Yahoo account and I know how easy it is to sniff Ethernet. I hate to read mail at cafes and other places where I'm not certain of the LAN security."</p><p>Did you really say that?!  Your worried about whether some end to end encryption will occur and think that will protect when your at an internet cafe!  Your email is NOT protected if your using some compromised machine at an internet cafe.  Come on!  Let's say it all together people, https encryption only protects it on transit and will not help me if the computer I'm using is not trustworthy.</p></htmltext>
<tokenext>" Anyone care to guess if Yahoo !
will so the same thing ? I really hope so .
I use a Yahoo account and I know how easy it is to sniff Ethernet .
I hate to read mail at cafes and other places where I 'm not certain of the LAN security .
" Did you really say that ? !
Your worried about whether some end to end encryption will occur and think that will protect when your at an internet cafe !
Your email is NOT protected if your using some compromised machine at an internet cafe .
Come on !
Let 's say it all together people , https encryption only protects it on transit and will not help me if the computer I 'm using is not trustworthy .</tokentext>
<sentencetext>"Anyone care to guess if Yahoo!
will so the same thing?I really hope so.
I use a Yahoo account and I know how easy it is to sniff Ethernet.
I hate to read mail at cafes and other places where I'm not certain of the LAN security.
"Did you really say that?!
Your worried about whether some end to end encryption will occur and think that will protect when your at an internet cafe!
Your email is NOT protected if your using some compromised machine at an internet cafe.
Come on!
Let's say it all together people, https encryption only protects it on transit and will not help me if the computer I'm using is not trustworthy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757818</id>
	<title>Re:Wait, what?</title>
	<author>Anonymous</author>
	<datestamp>1263384600000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think is a common misconception to think that encrypted data cannot be compressed.</p><p>On Compression of Data Encrypted with Block Ciphers (from DCC2009, http://dx.doi.org/10.1109/DCC.2009.71).</p><p>From the article conclusions: "Simulation results indicate that, while still far from theoretical limits, considerable compression gains are attainable and improved performance can be expected as block sizes increase in the future."</p></htmltext>
<tokenext>I think is a common misconception to think that encrypted data can not be compressed.On Compression of Data Encrypted with Block Ciphers ( from DCC2009 , http : //dx.doi.org/10.1109/DCC.2009.71 ) .From the article conclusions : " Simulation results indicate that , while still far from theoretical limits , considerable compression gains are attainable and improved performance can be expected as block sizes increase in the future .
"</tokentext>
<sentencetext>I think is a common misconception to think that encrypted data cannot be compressed.On Compression of Data Encrypted with Block Ciphers (from DCC2009, http://dx.doi.org/10.1109/DCC.2009.71).From the article conclusions: "Simulation results indicate that, while still far from theoretical limits, considerable compression gains are attainable and improved performance can be expected as block sizes increase in the future.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758510</id>
	<title>So does Wikipedia...</title>
	<author>cffrost</author>
	<datestamp>1263387300000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>...if you begin with the <a href="https://secure.wikimedia.org/wikipedia/en/wiki/Main\_Page" title="wikimedia.org" rel="nofollow">right URL.</a> [wikimedia.org]</htmltext>
<tokenext>...if you begin with the right URL .
[ wikimedia.org ]</tokentext>
<sentencetext>...if you begin with the right URL.
[wikimedia.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763962</id>
	<title>Re:Wait, what?</title>
	<author>zix619</author>
	<datestamp>1263484080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>IMO, the main issue is that ISPs throttle encrypted data and "try to" monitor it as an indication of botnet activity etc, e.g. all commands from command and control centers to bots are encrypted

that said, the main CPU challenge is on the server side and not on the client side: when google servers receive each thousands of encrypted packets the sum of decryption load on CPU is the problem. On client side, I don't believe that with modern CPUs the extra load is significant,</htmltext>
<tokenext>IMO , the main issue is that ISPs throttle encrypted data and " try to " monitor it as an indication of botnet activity etc , e.g .
all commands from command and control centers to bots are encrypted that said , the main CPU challenge is on the server side and not on the client side : when google servers receive each thousands of encrypted packets the sum of decryption load on CPU is the problem .
On client side , I do n't believe that with modern CPUs the extra load is significant,</tokentext>
<sentencetext>IMO, the main issue is that ISPs throttle encrypted data and "try to" monitor it as an indication of botnet activity etc, e.g.
all commands from command and control centers to bots are encrypted

that said, the main CPU challenge is on the server side and not on the client side: when google servers receive each thousands of encrypted packets the sum of decryption load on CPU is the problem.
On client side, I don't believe that with modern CPUs the extra load is significant,</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757734</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30866374</id>
	<title>Re:encrypted data slow? WTF?</title>
	<author>petermgreen</author>
	<datestamp>1264174320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Afaict the killer is the round trip times, a ssl connection takes more round trips to set up than a plain TCP one and web browsers frequently set up new connections (yes there is keepalive but thats still a far cry from a system that uses a single persistant connection).</p><p>No problem if you are on a fast low latency connection but if you aren't those extra round trips can really add up.</p></htmltext>
<tokenext>Afaict the killer is the round trip times , a ssl connection takes more round trips to set up than a plain TCP one and web browsers frequently set up new connections ( yes there is keepalive but thats still a far cry from a system that uses a single persistant connection ) .No problem if you are on a fast low latency connection but if you are n't those extra round trips can really add up .</tokentext>
<sentencetext>Afaict the killer is the round trip times, a ssl connection takes more round trips to set up than a plain TCP one and web browsers frequently set up new connections (yes there is keepalive but thats still a far cry from a system that uses a single persistant connection).No problem if you are on a fast low latency connection but if you aren't those extra round trips can really add up.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757960</id>
	<title>Slightly off-topic...</title>
	<author>mustafap</author>
	<datestamp>1263385260000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>why is it that if I have an account like</p><p>bob.alice@gmail.com</p><p>That mail addressed to</p><p>bobalice@gmail.com</p><p>gets delivered to bob.alice@gmail.com</p></htmltext>
<tokenext>why is it that if I have an account likebob.alice @ gmail.comThat mail addressed tobobalice @ gmail.comgets delivered to bob.alice @ gmail.com</tokentext>
<sentencetext>why is it that if I have an account likebob.alice@gmail.comThat mail addressed tobobalice@gmail.comgets delivered to bob.alice@gmail.com</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30772382</id>
	<title>Re:Was it really about that?</title>
	<author>Simetrical</author>
	<datestamp>1263470580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Bullshit.</p><p>Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster. That would be why it's taken until now for them to take this step.</p></div><p>SSL requires extra round-trips to negotiate keys.  If you have significant latency to the nearest Google cluster, that could be a noticeable delay on every HTTP request, since connections aren't recycled.  If Gmail switches to Web Sockets or such, of course, that would become a nonissue.</p></div>
	</htmltext>
<tokenext>Bullshit.Ok , maybe it 's true , but it seems much more likely that this was about them conserving CPU , not about you getting your email faster .
That would be why it 's taken until now for them to take this step.SSL requires extra round-trips to negotiate keys .
If you have significant latency to the nearest Google cluster , that could be a noticeable delay on every HTTP request , since connections are n't recycled .
If Gmail switches to Web Sockets or such , of course , that would become a nonissue .</tokentext>
<sentencetext>Bullshit.Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster.
That would be why it's taken until now for them to take this step.SSL requires extra round-trips to negotiate keys.
If you have significant latency to the nearest Google cluster, that could be a noticeable delay on every HTTP request, since connections aren't recycled.
If Gmail switches to Web Sockets or such, of course, that would become a nonissue.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759262</id>
	<title>Was it really about that?</title>
	<author>SanityInAnarchy</author>
	<datestamp>1263390900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.</p></div><p>Bullshit.</p><p>Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster. That would be why it's taken until now for them to take this step.</p><p>Of course, it's still fairly useless if I stay logged in -- then my session could still be hijacked from vanilla Google searches...</p></div>
	</htmltext>
<tokenext>We initially left the choice of using it up to you because there 's a downside : https can make your mail slower since encrypted data does n't travel across the web as quickly as unencrypted data.Bullshit.Ok , maybe it 's true , but it seems much more likely that this was about them conserving CPU , not about you getting your email faster .
That would be why it 's taken until now for them to take this step.Of course , it 's still fairly useless if I stay logged in -- then my session could still be hijacked from vanilla Google searches.. .</tokentext>
<sentencetext>We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.Bullshit.Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster.
That would be why it's taken until now for them to take this step.Of course, it's still fairly useless if I stay logged in -- then my session could still be hijacked from vanilla Google searches...
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762322</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>BlackHawk-666</author>
	<datestamp>1263469020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Of course, you can immediately discard any useful thing being in traffic from Youtube - unless the hacker is desperately short of crummy user provided content and comments that make the raptor jesus cry.

They can discard anything from news sites too - particularly since you can just read the comments on each news article you look at via the url.

Really, it's only sites that provide private information that can't be filtered from their 'look at' list. Sites like your email, forums (assuming they care what you write in semi-public places), your banking (which is already heavily encrypted).

Actually, if it's really important and needs encrypting it probably is already.</htmltext>
<tokenext>Of course , you can immediately discard any useful thing being in traffic from Youtube - unless the hacker is desperately short of crummy user provided content and comments that make the raptor jesus cry .
They can discard anything from news sites too - particularly since you can just read the comments on each news article you look at via the url .
Really , it 's only sites that provide private information that ca n't be filtered from their 'look at ' list .
Sites like your email , forums ( assuming they care what you write in semi-public places ) , your banking ( which is already heavily encrypted ) .
Actually , if it 's really important and needs encrypting it probably is already .</tokentext>
<sentencetext>Of course, you can immediately discard any useful thing being in traffic from Youtube - unless the hacker is desperately short of crummy user provided content and comments that make the raptor jesus cry.
They can discard anything from news sites too - particularly since you can just read the comments on each news article you look at via the url.
Really, it's only sites that provide private information that can't be filtered from their 'look at' list.
Sites like your email, forums (assuming they care what you write in semi-public places), your banking (which is already heavily encrypted).
Actually, if it's really important and needs encrypting it probably is already.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912</id>
	<title>encrypted data slow?  WTF?</title>
	<author>r7</author>
	<datestamp>1263395340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data</p></div><p>Reference please?  How would encrypted data travel any different than unencrypted date?  Routers don't look at content and the difference in payload sizes is negligible.</p><p>Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we're talking about milliseconds, nothing that rises to the level of human perception.</p><p>Honestly have to wonder whether the OP is a Yahoo!, Compuserv, or AOL employee, given how out-of-date those companies' email and webmail offerings have become.  Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago.</p></div>
	</htmltext>
<tokenext>https can make your mail slower since encrypted data does n't travel across the web as quickly as unencrypted dataReference please ?
How would encrypted data travel any different than unencrypted date ?
Routers do n't look at content and the difference in payload sizes is negligible.Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we 're talking about milliseconds , nothing that rises to the level of human perception.Honestly have to wonder whether the OP is a Yahoo ! , Compuserv , or AOL employee , given how out-of-date those companies ' email and webmail offerings have become .
Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago .</tokentext>
<sentencetext>https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted dataReference please?
How would encrypted data travel any different than unencrypted date?
Routers don't look at content and the difference in payload sizes is negligible.Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we're talking about milliseconds, nothing that rises to the level of human perception.Honestly have to wonder whether the OP is a Yahoo!, Compuserv, or AOL employee, given how out-of-date those companies' email and webmail offerings have become.
Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764282</id>
	<title>Re:Next step: encryption at rest</title>
	<author>Anonymous</author>
	<datestamp>1263485460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google's data center. That way even Google employees cannot read our mail. Not for serving up ads. Not for any reason whatsoever.</p></div> </blockquote><p>That feature has been available for a couple decades.  Get PGP, GnuPG, or something like that, and get the people you converse with to use it too.</p></div>
	</htmltext>
<tokenext>Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google 's data center .
That way even Google employees can not read our mail .
Not for serving up ads .
Not for any reason whatsoever .
That feature has been available for a couple decades .
Get PGP , GnuPG , or something like that , and get the people you converse with to use it too .</tokentext>
<sentencetext>Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google's data center.
That way even Google employees cannot read our mail.
Not for serving up ads.
Not for any reason whatsoever.
That feature has been available for a couple decades.
Get PGP, GnuPG, or something like that, and get the people you converse with to use it too.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758052</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>phantomfive</author>
	<datestamp>1263385620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I don't know, I think there are some things that don't need encryption.  I don't think I will ever need encryption to read google news, for example, or to watch youtube movies.</htmltext>
<tokenext>I do n't know , I think there are some things that do n't need encryption .
I do n't think I will ever need encryption to read google news , for example , or to watch youtube movies .</tokentext>
<sentencetext>I don't know, I think there are some things that don't need encryption.
I don't think I will ever need encryption to read google news, for example, or to watch youtube movies.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757740</id>
	<title>Will Yahoo! follow suit?</title>
	<author>vinn01</author>
	<datestamp>1263384180000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Anyone care to guess if Yahoo! will so the same thing?</p><p>I really hope so.  I use a Yahoo account and I know how easy it is to sniff Ethernet.  I hate to read mail at cafes and other places where I'm not certain of the LAN security.</p></htmltext>
<tokenext>Anyone care to guess if Yahoo !
will so the same thing ? I really hope so .
I use a Yahoo account and I know how easy it is to sniff Ethernet .
I hate to read mail at cafes and other places where I 'm not certain of the LAN security .</tokentext>
<sentencetext>Anyone care to guess if Yahoo!
will so the same thing?I really hope so.
I use a Yahoo account and I know how easy it is to sniff Ethernet.
I hate to read mail at cafes and other places where I'm not certain of the LAN security.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757844</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>Anonymous</author>
	<datestamp>1263384660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The spooks in government and private industry (hi IT dept, snoop anything juicy recently?) don't want encrypted traffic to become the norm. They have the ear of their respective leaders, so I wouldn't expect the status quo to be changing anytime soon. The plebs don't even realize what they've given up.</p><p>(Posted using my work computer via unencrypted HTTP piped through an SSH tunnel)</p></htmltext>
<tokenext>The spooks in government and private industry ( hi IT dept , snoop anything juicy recently ?
) do n't want encrypted traffic to become the norm .
They have the ear of their respective leaders , so I would n't expect the status quo to be changing anytime soon .
The plebs do n't even realize what they 've given up .
( Posted using my work computer via unencrypted HTTP piped through an SSH tunnel )</tokentext>
<sentencetext>The spooks in government and private industry (hi IT dept, snoop anything juicy recently?
) don't want encrypted traffic to become the norm.
They have the ear of their respective leaders, so I wouldn't expect the status quo to be changing anytime soon.
The plebs don't even realize what they've given up.
(Posted using my work computer via unencrypted HTTP piped through an SSH tunnel)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760864</id>
	<title>Re:Intercepting emails</title>
	<author>Anonymous</author>
	<datestamp>1263404220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This was an EXTREMELY great fear in the early to mid 90s, when the government was trying to get everyone to standardize encryption on all devices using the Clipper chip (and key escrow in general).  The chip had good throughput... but it allowed for people to pull out any keys if they had access to the LEAF (law enforcement access field).  The algorithm was classified secret, and the chips were made in one factory, then moved to another factory where the algorithm was slapped on, before being shipped out</p><p>Funny thing, the cypherpunks were right.  As soon as the algorithm was declassified, it was ripped apart in several days, and laid to rest months later.  Had this been in every computer and communications device on the Web (and other cryptographic algorithms forbidden by law which was the other shoe that was feared to drop), the security of the Internet would have depended on the fact that the algorithm was unknown, and the second a blackhat figured it out who knew differential cryptanalysis, people would have had to permanently disconnect their businesses from the Internet for weeks to years until something was able to replace this, like another hardware device.  As a twist of irony, blackhats could zero out the LEAF making their communications and keys un-escrowable.</p><p>So, leaving a back door for law enforcement seems like a good idea.  However, it would completely ruin any trust customers give a product should blackhats find it present, and start using it.  Obligatory car analogy:  Nobody wants every car thief on the streets to have a master remote that unlocks their car and starts it up just at a button press, with no way of disabling this.</p></htmltext>
<tokenext>This was an EXTREMELY great fear in the early to mid 90s , when the government was trying to get everyone to standardize encryption on all devices using the Clipper chip ( and key escrow in general ) .
The chip had good throughput... but it allowed for people to pull out any keys if they had access to the LEAF ( law enforcement access field ) .
The algorithm was classified secret , and the chips were made in one factory , then moved to another factory where the algorithm was slapped on , before being shipped outFunny thing , the cypherpunks were right .
As soon as the algorithm was declassified , it was ripped apart in several days , and laid to rest months later .
Had this been in every computer and communications device on the Web ( and other cryptographic algorithms forbidden by law which was the other shoe that was feared to drop ) , the security of the Internet would have depended on the fact that the algorithm was unknown , and the second a blackhat figured it out who knew differential cryptanalysis , people would have had to permanently disconnect their businesses from the Internet for weeks to years until something was able to replace this , like another hardware device .
As a twist of irony , blackhats could zero out the LEAF making their communications and keys un-escrowable.So , leaving a back door for law enforcement seems like a good idea .
However , it would completely ruin any trust customers give a product should blackhats find it present , and start using it .
Obligatory car analogy : Nobody wants every car thief on the streets to have a master remote that unlocks their car and starts it up just at a button press , with no way of disabling this .</tokentext>
<sentencetext>This was an EXTREMELY great fear in the early to mid 90s, when the government was trying to get everyone to standardize encryption on all devices using the Clipper chip (and key escrow in general).
The chip had good throughput... but it allowed for people to pull out any keys if they had access to the LEAF (law enforcement access field).
The algorithm was classified secret, and the chips were made in one factory, then moved to another factory where the algorithm was slapped on, before being shipped outFunny thing, the cypherpunks were right.
As soon as the algorithm was declassified, it was ripped apart in several days, and laid to rest months later.
Had this been in every computer and communications device on the Web (and other cryptographic algorithms forbidden by law which was the other shoe that was feared to drop), the security of the Internet would have depended on the fact that the algorithm was unknown, and the second a blackhat figured it out who knew differential cryptanalysis, people would have had to permanently disconnect their businesses from the Internet for weeks to years until something was able to replace this, like another hardware device.
As a twist of irony, blackhats could zero out the LEAF making their communications and keys un-escrowable.So, leaving a back door for law enforcement seems like a good idea.
However, it would completely ruin any trust customers give a product should blackhats find it present, and start using it.
Obligatory car analogy:  Nobody wants every car thief on the streets to have a master remote that unlocks their car and starts it up just at a button press, with no way of disabling this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757542</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762506</id>
	<title>Re:Semantics</title>
	<author>asdf7890</author>
	<datestamp>1263471420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Actually, the CPU overhead of encrypting any given request+response is pretty trivial on modern hardware. For small objects there is very little to do (the encryption stage, while not taking zero time, will be dwarfed by network latency and file/database access timings and so on) and for large objects (chunky attachments for instance) bandwidth is the bottleneck.</p><p>The initial SSL negotiation probably adds more to the user experience, though this is mitigated somewhat by enabling HTTP keep-alives (if the client supports this, which any modern browser does and most not-so-modern ones too, and the web servers have the extra resource it will require, which I'm guessing Google's web farm has).</p><p>The real kicker for a dynamic web app like gmail is that fact that nothing should ever be cached if it comes in through a HTTPS connection, so even static content such as script files, css files, and images have to be re-requested much more regularly than when using HTTP. This means more bandwidth and latency seen by the user, and of course a chunk more bandwidth use seen by the servers.</p></htmltext>
<tokenext>Actually , the CPU overhead of encrypting any given request + response is pretty trivial on modern hardware .
For small objects there is very little to do ( the encryption stage , while not taking zero time , will be dwarfed by network latency and file/database access timings and so on ) and for large objects ( chunky attachments for instance ) bandwidth is the bottleneck.The initial SSL negotiation probably adds more to the user experience , though this is mitigated somewhat by enabling HTTP keep-alives ( if the client supports this , which any modern browser does and most not-so-modern ones too , and the web servers have the extra resource it will require , which I 'm guessing Google 's web farm has ) .The real kicker for a dynamic web app like gmail is that fact that nothing should ever be cached if it comes in through a HTTPS connection , so even static content such as script files , css files , and images have to be re-requested much more regularly than when using HTTP .
This means more bandwidth and latency seen by the user , and of course a chunk more bandwidth use seen by the servers .</tokentext>
<sentencetext>Actually, the CPU overhead of encrypting any given request+response is pretty trivial on modern hardware.
For small objects there is very little to do (the encryption stage, while not taking zero time, will be dwarfed by network latency and file/database access timings and so on) and for large objects (chunky attachments for instance) bandwidth is the bottleneck.The initial SSL negotiation probably adds more to the user experience, though this is mitigated somewhat by enabling HTTP keep-alives (if the client supports this, which any modern browser does and most not-so-modern ones too, and the web servers have the extra resource it will require, which I'm guessing Google's web farm has).The real kicker for a dynamic web app like gmail is that fact that nothing should ever be cached if it comes in through a HTTPS connection, so even static content such as script files, css files, and images have to be re-requested much more regularly than when using HTTP.
This means more bandwidth and latency seen by the user, and of course a chunk more bandwidth use seen by the servers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761792</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757488</id>
	<title>Google just doesn want...</title>
	<author>Anonymous</author>
	<datestamp>1263382980000</datestamp>
	<modclass>Troll</modclass>
	<modscore>0</modscore>
	<htmltext><p>others sniffing the traffic they want to store for you on their end as to keep it all to themselves.</p></htmltext>
<tokenext>others sniffing the traffic they want to store for you on their end as to keep it all to themselves .</tokentext>
<sentencetext>others sniffing the traffic they want to store for you on their end as to keep it all to themselves.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761236</id>
	<title>Re:I hope they keep Google Apps in the clear!</title>
	<author>Anonymous</author>
	<datestamp>1263408720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>iDont beLeave You.</p></htmltext>
<tokenext>iDont beLeave You .</tokentext>
<sentencetext>iDont beLeave You.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759118</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760878</id>
	<title>Re:encrypted data slow? WTF?</title>
	<author>jonaskoelker</author>
	<datestamp>1263404340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>How would encrypted data travel any different than unencrypted date?</p></div><p>You would have more roundtrips during the key exchange phase of SSL.  It's not that the data travels slower, it's that there is more of it, and you have to wait for more ping-pong iterations.</p></div>
	</htmltext>
<tokenext>How would encrypted data travel any different than unencrypted date ? You would have more roundtrips during the key exchange phase of SSL .
It 's not that the data travels slower , it 's that there is more of it , and you have to wait for more ping-pong iterations .</tokentext>
<sentencetext>How would encrypted data travel any different than unencrypted date?You would have more roundtrips during the key exchange phase of SSL.
It's not that the data travels slower, it's that there is more of it, and you have to wait for more ping-pong iterations.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757456</id>
	<title>Great!</title>
	<author>Anonymous</author>
	<datestamp>1263382800000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Great move by Google, although TFA points out that there are some problems with offline gmail and HTTPS, kudos to them for coming straight out and saying it may be a problem, while posting a link for some workarounds: <a href="http://mail.google.com/support/bin/answer.py?hl=en&amp;answer=172697" title="google.com" rel="nofollow">http://mail.google.com/support/bin/answer.py?hl=en&amp;answer=172697</a> [google.com]</htmltext>
<tokenext>Great move by Google , although TFA points out that there are some problems with offline gmail and HTTPS , kudos to them for coming straight out and saying it may be a problem , while posting a link for some workarounds : http : //mail.google.com/support/bin/answer.py ? hl = en&amp;answer = 172697 [ google.com ]</tokentext>
<sentencetext>Great move by Google, although TFA points out that there are some problems with offline gmail and HTTPS, kudos to them for coming straight out and saying it may be a problem, while posting a link for some workarounds: http://mail.google.com/support/bin/answer.py?hl=en&amp;answer=172697 [google.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759056</id>
	<title>Google Groups</title>
	<author>destiney</author>
	<datestamp>1263389760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How about some love for Google Groups?  They're currently overrun with spammers who are bypassing all available moderation measures.</p></htmltext>
<tokenext>How about some love for Google Groups ?
They 're currently overrun with spammers who are bypassing all available moderation measures .</tokentext>
<sentencetext>How about some love for Google Groups?
They're currently overrun with spammers who are bypassing all available moderation measures.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757628</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>Anonymous</author>
	<datestamp>1263383700000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I've often wondered why email clients don't make it easier to set up encryption, and use it as the default if your recipient and you have exchanged keys (preferrably automatically if both have the capacity.) Sure, if you're semi-clued up it's not that hard to set this up manually, but to the average user it's way out of their comfort zone.</p></htmltext>
<tokenext>I 've often wondered why email clients do n't make it easier to set up encryption , and use it as the default if your recipient and you have exchanged keys ( preferrably automatically if both have the capacity .
) Sure , if you 're semi-clued up it 's not that hard to set this up manually , but to the average user it 's way out of their comfort zone .</tokentext>
<sentencetext>I've often wondered why email clients don't make it easier to set up encryption, and use it as the default if your recipient and you have exchanged keys (preferrably automatically if both have the capacity.
) Sure, if you're semi-clued up it's not that hard to set this up manually, but to the average user it's way out of their comfort zone.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757824</id>
	<title>Re:Keyloggers</title>
	<author>Anonymous</author>
	<datestamp>1263384600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Keyloggers will be modified to take a screenshot as you click (if they haven't already).</p></htmltext>
<tokenext>Keyloggers will be modified to take a screenshot as you click ( if they have n't already ) .</tokentext>
<sentencetext>Keyloggers will be modified to take a screenshot as you click (if they haven't already).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757560</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432</id>
	<title>iGoogle support?</title>
	<author>l2718</author>
	<datestamp>1263382680000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext>For the moment Google's own gadget for for iGoogle doesn't support HTTPS access to gmail.</htmltext>
<tokenext>For the moment Google 's own gadget for for iGoogle does n't support HTTPS access to gmail .</tokentext>
<sentencetext>For the moment Google's own gadget for for iGoogle doesn't support HTTPS access to gmail.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760346</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>cortesoft</author>
	<datestamp>1263399360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>You are exactly right.  This is for the very same reason that we need to start making encryption standard for everyone; if your scenario was to take place under current circumstances, you would already be under suspicion and under greater focus since most people don't encrypt everything... when everyone encrypts everything, it will finally be the case that no pattern can be deduced from the presence of encrypted data</p></htmltext>
<tokenext>You are exactly right .
This is for the very same reason that we need to start making encryption standard for everyone ; if your scenario was to take place under current circumstances , you would already be under suspicion and under greater focus since most people do n't encrypt everything... when everyone encrypts everything , it will finally be the case that no pattern can be deduced from the presence of encrypted data</tokentext>
<sentencetext>You are exactly right.
This is for the very same reason that we need to start making encryption standard for everyone; if your scenario was to take place under current circumstances, you would already be under suspicion and under greater focus since most people don't encrypt everything... when everyone encrypts everything, it will finally be the case that no pattern can be deduced from the presence of encrypted data</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757618</id>
	<title>Re:Wait, what?</title>
	<author>Ant P.</author>
	<datestamp>1263383640000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>Routers don't know whether your data is encrypted or not.</p></div><p>Neither does your browser, or the server. HTTP is a stateless protocol. Every encrypted request requires setting up the encryption all over again.</p></div>
	</htmltext>
<tokenext>Routers do n't know whether your data is encrypted or not.Neither does your browser , or the server .
HTTP is a stateless protocol .
Every encrypted request requires setting up the encryption all over again .</tokentext>
<sentencetext>Routers don't know whether your data is encrypted or not.Neither does your browser, or the server.
HTTP is a stateless protocol.
Every encrypted request requires setting up the encryption all over again.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760798</id>
	<title>Re:HTTP sends more than just subject line...</title>
	<author>Anonymous</author>
	<datestamp>1263403620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Not only is this wrong, see the comment somewhere near the top (how would google know about someone elses' lan being snooped?), but also what if the user only opened his account but didn't do much else? Then you would see exactly the subject lines and no message content.<br>When you read about something, try to think about how it's possible instead of just saying NO BITCH, NOT THAT.<br>The number of times I've had to deal with stupid issues because of that...</p></htmltext>
<tokenext>Not only is this wrong , see the comment somewhere near the top ( how would google know about someone elses ' lan being snooped ?
) , but also what if the user only opened his account but did n't do much else ?
Then you would see exactly the subject lines and no message content.When you read about something , try to think about how it 's possible instead of just saying NO BITCH , NOT THAT.The number of times I 've had to deal with stupid issues because of that.. .</tokentext>
<sentencetext>Not only is this wrong, see the comment somewhere near the top (how would google know about someone elses' lan being snooped?
), but also what if the user only opened his account but didn't do much else?
Then you would see exactly the subject lines and no message content.When you read about something, try to think about how it's possible instead of just saying NO BITCH, NOT THAT.The number of times I've had to deal with stupid issues because of that...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757966</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765838</id>
	<title>Re:Was it really about that?</title>
	<author>clone53421</author>
	<datestamp>1263490260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster. That would be why it's taken until now for them to take this step.</p></div><p>Well, it&rsquo;s more of a half-truth. If it slows <em>you</em> down, it also slows down Gmail&rsquo;s server. They&rsquo;re obviously worried about both.</p></div>
	</htmltext>
<tokenext>Ok , maybe it 's true , but it seems much more likely that this was about them conserving CPU , not about you getting your email faster .
That would be why it 's taken until now for them to take this step.Well , it    s more of a half-truth .
If it slows you down , it also slows down Gmail    s server .
They    re obviously worried about both .</tokentext>
<sentencetext>Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster.
That would be why it's taken until now for them to take this step.Well, it’s more of a half-truth.
If it slows you down, it also slows down Gmail’s server.
They’re obviously worried about both.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763950</id>
	<title>Re:Yeah, that's a big WTF...</title>
	<author>clone53421</author>
	<datestamp>1263484020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The encryption/decryption process is what slows it down.</p></htmltext>
<tokenext>The encryption/decryption process is what slows it down .</tokentext>
<sentencetext>The encryption/decryption process is what slows it down.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760790</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759588</id>
	<title>Re:Wait, what?</title>
	<author>Chuck Chunder</author>
	<datestamp>1263392640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There's additional overhead in doing the encryption/decryption at each end.<br>
There's additional overhead in <a href="http://en.wikipedia.org/wiki/Transport\_Layer\_Security#Simple\_TLS\_handshake" title="wikipedia.org">establishing</a> [wikipedia.org] (and re-establishing) a connection.
<br> <br>
There could also be implications in regards to caching, ie a browser may not cache SSL served data on disk so you end up downloading more stuff (images, javascript, css) the first time mail is used after a browser is launched that may otherwise be cached on a non-ssl connection. The precise details here would depend on the browser, browser version, browser configuration and what the server does (what cache directives it sends etc).</htmltext>
<tokenext>There 's additional overhead in doing the encryption/decryption at each end .
There 's additional overhead in establishing [ wikipedia.org ] ( and re-establishing ) a connection .
There could also be implications in regards to caching , ie a browser may not cache SSL served data on disk so you end up downloading more stuff ( images , javascript , css ) the first time mail is used after a browser is launched that may otherwise be cached on a non-ssl connection .
The precise details here would depend on the browser , browser version , browser configuration and what the server does ( what cache directives it sends etc ) .</tokentext>
<sentencetext>There's additional overhead in doing the encryption/decryption at each end.
There's additional overhead in establishing [wikipedia.org] (and re-establishing) a connection.
There could also be implications in regards to caching, ie a browser may not cache SSL served data on disk so you end up downloading more stuff (images, javascript, css) the first time mail is used after a browser is launched that may otherwise be cached on a non-ssl connection.
The precise details here would depend on the browser, browser version, browser configuration and what the server does (what cache directives it sends etc).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759288</id>
	<title>What about slashdot?</title>
	<author>Anonymous</author>
	<datestamp>1263391020000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>I really want EVERY site I visit to use https. Why doesn't slashdot?</p></htmltext>
<tokenext>I really want EVERY site I visit to use https .
Why does n't slashdot ?</tokentext>
<sentencetext>I really want EVERY site I visit to use https.
Why doesn't slashdot?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757716</id>
	<title>Re:Wait, what?</title>
	<author>Anonymous</author>
	<datestamp>1263384000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I also wondered what they meant by that. Many people don't understand that encrypted data is the SAME SIZE as unencrypted data. That said, there is additional work on each end of the communications to negotiate the session and actually encrypt and decrypt the data. Also, existing proxies and caches may provide fewer performance benefits under HTTPS.</p></htmltext>
<tokenext>I also wondered what they meant by that .
Many people do n't understand that encrypted data is the SAME SIZE as unencrypted data .
That said , there is additional work on each end of the communications to negotiate the session and actually encrypt and decrypt the data .
Also , existing proxies and caches may provide fewer performance benefits under HTTPS .</tokentext>
<sentencetext>I also wondered what they meant by that.
Many people don't understand that encrypted data is the SAME SIZE as unencrypted data.
That said, there is additional work on each end of the communications to negotiate the session and actually encrypt and decrypt the data.
Also, existing proxies and caches may provide fewer performance benefits under HTTPS.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757698</id>
	<title>Re:Hang on...</title>
	<author>Brian Gordon</author>
	<datestamp>1263383940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>Might as well scoop up the mod points if someone's going to get them. <a href="http://en.wikipedia.org/wiki/D-H" title="wikipedia.org">This, moron</a> [wikipedia.org].</p></htmltext>
<tokenext>Might as well scoop up the mod points if someone 's going to get them .
This , moron [ wikipedia.org ] .</tokentext>
<sentencetext>Might as well scoop up the mod points if someone's going to get them.
This, moron [wikipedia.org].</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757408</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759554</id>
	<title>Re:No Brainer</title>
	<author>asserted</author>
	<datestamp>1263392460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>&gt; As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues</p><p>and now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default).<br>if google is dead last, the internet must be swarming with secure mail services, right?<nobr> <wbr></nobr>...right?</p></htmltext>
<tokenext>&gt; As usual , Google leads the pack in creating groundbreaking technology , and comes in dead last in dealing with the boring stuff , like dealing with security issuesand now you show me another free mail service of any significance that has IMAPS , POP3S , SMTPS and now HTTPS ( yes , all with * S , because Gmail requires you to use SSL for SMTP , POP3 and IMAP , and has been doing so since the very beginning , HTTPS was available for use for a while , though not required or offered by default ) .if google is dead last , the internet must be swarming with secure mail services , right ?
...right ?</tokentext>
<sentencetext>&gt; As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issuesand now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default).if google is dead last, the internet must be swarming with secure mail services, right?
...right?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757742</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760610</id>
	<title>S/MIME support?</title>
	<author>KenMcM</author>
	<datestamp>1263401880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When will Google provide S/MIME support natively?</htmltext>
<tokenext>When will Google provide S/MIME support natively ?</tokentext>
<sentencetext>When will Google provide S/MIME support natively?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760918</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>Anonymous</author>
	<datestamp>1263404880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Don't forget that active ad injection "services" that drop in ads (or merely add cross site traking stuff) are going to be more and more common as ISPs try to keep their quarterly numbers up, but not lay fiber.</p><p>Even just a way to have packets signed in a way that an active MITM attack would be noticed (because of SSL's overhead) would help to keep this form of intrusion from becoming a common issue.</p></htmltext>
<tokenext>Do n't forget that active ad injection " services " that drop in ads ( or merely add cross site traking stuff ) are going to be more and more common as ISPs try to keep their quarterly numbers up , but not lay fiber.Even just a way to have packets signed in a way that an active MITM attack would be noticed ( because of SSL 's overhead ) would help to keep this form of intrusion from becoming a common issue .</tokentext>
<sentencetext>Don't forget that active ad injection "services" that drop in ads (or merely add cross site traking stuff) are going to be more and more common as ISPs try to keep their quarterly numbers up, but not lay fiber.Even just a way to have packets signed in a way that an active MITM attack would be noticed (because of SSL's overhead) would help to keep this form of intrusion from becoming a common issue.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762536</id>
	<title>In other news</title>
	<author>tokul</author>
	<datestamp>1263471960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Chinese government requires installation of special CA bundle on all computers in China.<nobr> <wbr></nobr>:)</htmltext>
<tokenext>Chinese government requires installation of special CA bundle on all computers in China .
: )</tokentext>
<sentencetext>Chinese government requires installation of special CA bundle on all computers in China.
:)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758778</id>
	<title>Ouch.</title>
	<author>machine321</author>
	<datestamp>1263388500000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p> encrypted data doesn't travel across the web as quickly as unencrypted data</p></div><p>That just hurts my brain.</p></div>
	</htmltext>
<tokenext>encrypted data does n't travel across the web as quickly as unencrypted dataThat just hurts my brain .</tokentext>
<sentencetext> encrypted data doesn't travel across the web as quickly as unencrypted dataThat just hurts my brain.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759064</id>
	<title>Re:Will Yahoo! follow suit?</title>
	<author>ForestHill</author>
	<datestamp>1263389760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In that respect, there's no such thing as "LAN security." THe cafe is really no less secure than anything else WRT your email's readability. Even if you're at work behind a corporate firewall, you should be similarly nervous. That email was in the clear across the internet. Even if it came form another coworker, a 3rd party at work could be snooping. Treat unencrypted email as if anyone could read it. 'cuz they can.</htmltext>
<tokenext>In that respect , there 's no such thing as " LAN security .
" THe cafe is really no less secure than anything else WRT your email 's readability .
Even if you 're at work behind a corporate firewall , you should be similarly nervous .
That email was in the clear across the internet .
Even if it came form another coworker , a 3rd party at work could be snooping .
Treat unencrypted email as if anyone could read it .
'cuz they can .</tokentext>
<sentencetext>In that respect, there's no such thing as "LAN security.
" THe cafe is really no less secure than anything else WRT your email's readability.
Even if you're at work behind a corporate firewall, you should be similarly nervous.
That email was in the clear across the internet.
Even if it came form another coworker, a 3rd party at work could be snooping.
Treat unencrypted email as if anyone could read it.
'cuz they can.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758504</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>Anonymous</author>
	<datestamp>1263387300000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>The day someone implements DNSSEC based server key delivery in a popular browser, there will be a grass-roots effort to make your dream come true.</p></htmltext>
<tokenext>The day someone implements DNSSEC based server key delivery in a popular browser , there will be a grass-roots effort to make your dream come true .</tokentext>
<sentencetext>The day someone implements DNSSEC based server key delivery in a popular browser, there will be a grass-roots effort to make your dream come true.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757440</id>
	<title>Sniffing? I disagree.</title>
	<author>FooAtWFU</author>
	<datestamp>1263382680000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Google couldn't really tell if there was sniffing going on in their users' connections. They could, however, figure out exactly what sort of activities someone using POP or IMAP or the web UI (or some compromised internal Google tool) ended up doing, based on logs.</htmltext>
<tokenext>Google could n't really tell if there was sniffing going on in their users ' connections .
They could , however , figure out exactly what sort of activities someone using POP or IMAP or the web UI ( or some compromised internal Google tool ) ended up doing , based on logs .</tokentext>
<sentencetext>Google couldn't really tell if there was sniffing going on in their users' connections.
They could, however, figure out exactly what sort of activities someone using POP or IMAP or the web UI (or some compromised internal Google tool) ended up doing, based on logs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760830</id>
	<title>Re:encrypted data slow? WTF?</title>
	<author>davet2001</author>
	<datestamp>1263403860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Reference please?  How would encrypted data travel any different than unencrypted date?  Routers don't look at content and the difference in payload sizes is negligible.</p></div><p>
This might have to do with compression as well as the key exchange/processing overhead.
</p><p>
I remember my university lecturer explaining that written English text could be compressed down to about 1 bit per character, and this was to do with the fact that patterns of written text are quite common.  I would imagine that the same principle holds reasonably true for HTML as well.
</p><p>
Encrypted traffic essentially looks like a sequence of random bytes, so probably requires 7 or 8 bits per character.
</p><p>
I expect that multiple links along the route will try to compress your data to save bandwidth where they can (the first modem being a prime example), and in the case of https, no compression can be done.
</p><p>
Yeah, so if I'm right (sorry, no references), Reading an email could easily be 7-8 times slower over https.</p></div>
	</htmltext>
<tokenext>Reference please ?
How would encrypted data travel any different than unencrypted date ?
Routers do n't look at content and the difference in payload sizes is negligible .
This might have to do with compression as well as the key exchange/processing overhead .
I remember my university lecturer explaining that written English text could be compressed down to about 1 bit per character , and this was to do with the fact that patterns of written text are quite common .
I would imagine that the same principle holds reasonably true for HTML as well .
Encrypted traffic essentially looks like a sequence of random bytes , so probably requires 7 or 8 bits per character .
I expect that multiple links along the route will try to compress your data to save bandwidth where they can ( the first modem being a prime example ) , and in the case of https , no compression can be done .
Yeah , so if I 'm right ( sorry , no references ) , Reading an email could easily be 7-8 times slower over https .</tokentext>
<sentencetext>Reference please?
How would encrypted data travel any different than unencrypted date?
Routers don't look at content and the difference in payload sizes is negligible.
This might have to do with compression as well as the key exchange/processing overhead.
I remember my university lecturer explaining that written English text could be compressed down to about 1 bit per character, and this was to do with the fact that patterns of written text are quite common.
I would imagine that the same principle holds reasonably true for HTML as well.
Encrypted traffic essentially looks like a sequence of random bytes, so probably requires 7 or 8 bits per character.
I expect that multiple links along the route will try to compress your data to save bandwidth where they can (the first modem being a prime example), and in the case of https, no compression can be done.
Yeah, so if I'm right (sorry, no references), Reading an email could easily be 7-8 times slower over https.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757936</id>
	<title>Re:Intercepting emails</title>
	<author>Monkeedude1212</author>
	<datestamp>1263385200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>While true that it wasn't interception - I am sure the recent involvement with the Chinese security issues has simply brought into focus how much Google is being attacked, also knowing that they are dealing with some relatively skilled hackers. Whether the attacks were designed to sniff out people not using HTTPS or not - better to just remove that option altogether.</p></htmltext>
<tokenext>While true that it was n't interception - I am sure the recent involvement with the Chinese security issues has simply brought into focus how much Google is being attacked , also knowing that they are dealing with some relatively skilled hackers .
Whether the attacks were designed to sniff out people not using HTTPS or not - better to just remove that option altogether .</tokentext>
<sentencetext>While true that it wasn't interception - I am sure the recent involvement with the Chinese security issues has simply brought into focus how much Google is being attacked, also knowing that they are dealing with some relatively skilled hackers.
Whether the attacks were designed to sniff out people not using HTTPS or not - better to just remove that option altogether.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757542</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759080</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>roju</author>
	<datestamp>1263389820000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>How do you effectively search your email history if it's all encrypted? Are there algorithms for indexing encrypted data without giving too much away?</p></htmltext>
<tokenext>How do you effectively search your email history if it 's all encrypted ?
Are there algorithms for indexing encrypted data without giving too much away ?</tokentext>
<sentencetext>How do you effectively search your email history if it's all encrypted?
Are there algorithms for indexing encrypted data without giving too much away?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</id>
	<title>The beginning of HTTPS for everything by default?</title>
	<author>Anonymous</author>
	<datestamp>1263383340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>I've long held that the only answer to pervasive surveillance is to encrypt everything.</p><p>It won't stop them from cracking things that attract their attention, but for most things it won't be worth the hassle.</p><p>Encrypt everything.</p></htmltext>
<tokenext>I 've long held that the only answer to pervasive surveillance is to encrypt everything.It wo n't stop them from cracking things that attract their attention , but for most things it wo n't be worth the hassle.Encrypt everything .</tokentext>
<sentencetext>I've long held that the only answer to pervasive surveillance is to encrypt everything.It won't stop them from cracking things that attract their attention, but for most things it won't be worth the hassle.Encrypt everything.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757566</id>
	<title>Re:iGoogle support?</title>
	<author>FlyingBishop</author>
	<datestamp>1263383460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Google has a lot of rough edges on their peripheral apps. The Android plugin for Eclipse is unsigned. (And this is the plugin that most developers will be signing their apps with.)</p></htmltext>
<tokenext>Google has a lot of rough edges on their peripheral apps .
The Android plugin for Eclipse is unsigned .
( And this is the plugin that most developers will be signing their apps with .
)</tokentext>
<sentencetext>Google has a lot of rough edges on their peripheral apps.
The Android plugin for Eclipse is unsigned.
(And this is the plugin that most developers will be signing their apps with.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757734</id>
	<title>Re:Wait, what?</title>
	<author>Anonymous</author>
	<datestamp>1263384180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>The reason why encrypted data tends not to travel as quickly (other than the fact that it is incompressible) is that a lot of DPI filters in a number of links throttle anything encrypted, assuming if it is encrypted, then its P2P traffic.</p></htmltext>
<tokenext>The reason why encrypted data tends not to travel as quickly ( other than the fact that it is incompressible ) is that a lot of DPI filters in a number of links throttle anything encrypted , assuming if it is encrypted , then its P2P traffic .</tokentext>
<sentencetext>The reason why encrypted data tends not to travel as quickly (other than the fact that it is incompressible) is that a lot of DPI filters in a number of links throttle anything encrypted, assuming if it is encrypted, then its P2P traffic.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765792</id>
	<title>Re:I hope they keep Google Apps in the clear!</title>
	<author>clone53421</author>
	<datestamp>1263490200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://www.google.com/support/a/bin/answer.py?hl=en&amp;answer=100181" title="google.com">http://www.google.com/support/a/bin/answer.py?hl=en&amp;answer=100181</a> [google.com]:</p><blockquote><div><p>Note: If you force HTTPS for your domain, your users won't be able to disable HTTPS on an individual basis. However, if you don't force HTTPS for your domain, your users can enable HTTPS when necessary but only if you also have enabled the 'Enable pre-release features' checkbox in your Admin Control Panel.</p></div></blockquote><p>So yes, it appears that you can still disable HTTPS if necessary.</p></div>
	</htmltext>
<tokenext>http : //www.google.com/support/a/bin/answer.py ? hl = en&amp;answer = 100181 [ google.com ] : Note : If you force HTTPS for your domain , your users wo n't be able to disable HTTPS on an individual basis .
However , if you do n't force HTTPS for your domain , your users can enable HTTPS when necessary but only if you also have enabled the 'Enable pre-release features ' checkbox in your Admin Control Panel.So yes , it appears that you can still disable HTTPS if necessary .</tokentext>
<sentencetext>http://www.google.com/support/a/bin/answer.py?hl=en&amp;answer=100181 [google.com]:Note: If you force HTTPS for your domain, your users won't be able to disable HTTPS on an individual basis.
However, if you don't force HTTPS for your domain, your users can enable HTTPS when necessary but only if you also have enabled the 'Enable pre-release features' checkbox in your Admin Control Panel.So yes, it appears that you can still disable HTTPS if necessary.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759118</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757542</id>
	<title>Intercepting emails</title>
	<author>Anonymous</author>
	<datestamp>1263383220000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><blockquote><div><p>'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update. That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers.</p></div></blockquote><p>Actually, I read somewhere that hackers gained access to a system designed to give law enforcement access to people's emails, presumably under warrant. [sarcasm]Who could have ever imagined the same loopholes intended for use by law enforcement could possibly be exploited by hackers as well?[/sarcasm]</p></div>
	</htmltext>
<tokenext>'Only two Gmail accounts appear to have been accessed , and that activity was limited to account information ( such as the date the account was created ) and subject line , rather than the content of emails themselves, ' said David Drummond in that blog update .
That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail 's servers.Actually , I read somewhere that hackers gained access to a system designed to give law enforcement access to people 's emails , presumably under warrant .
[ sarcasm ] Who could have ever imagined the same loopholes intended for use by law enforcement could possibly be exploited by hackers as well ?
[ /sarcasm ]</tokentext>
<sentencetext>'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update.
That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers.Actually, I read somewhere that hackers gained access to a system designed to give law enforcement access to people's emails, presumably under warrant.
[sarcasm]Who could have ever imagined the same loopholes intended for use by law enforcement could possibly be exploited by hackers as well?
[/sarcasm]
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30772356</id>
	<title>Re:Ouch.</title>
	<author>Simetrical</author>
	<datestamp>1263470520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Actually, that is possible.  Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.</p></div><p>Can you point me to a single HTTPS implementation in wide use that applies SSL <em>before</em> compression?  It's the same software doing both, you know.  But SSL requires extra round-trips to set up connections, so it is indeed slower.</p></div>
	</htmltext>
<tokenext>Actually , that is possible .
Encrypted data does n't generally compress as well as plaintext , and it 's quite common for web servers to compress data before sending it to the client.Can you point me to a single HTTPS implementation in wide use that applies SSL before compression ?
It 's the same software doing both , you know .
But SSL requires extra round-trips to set up connections , so it is indeed slower .</tokentext>
<sentencetext>Actually, that is possible.
Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.Can you point me to a single HTTPS implementation in wide use that applies SSL before compression?
It's the same software doing both, you know.
But SSL requires extra round-trips to set up connections, so it is indeed slower.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762240</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764956</id>
	<title>Re:Wait, what?</title>
	<author>clone53421</author>
	<datestamp>1263487440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There are actually a number of reasons why HTTPS is slower:</p><p>Setting up the HTTPS connection takes extra time;<br>Encrypting/decrypting the data takes extra time, as you said;<br>Don&rsquo;t tell anyone, but ISPs might tend to prioritize HTTPS traffic lower than HTTP;<br>...if not just outright throttle it, which some undoubtedly do...</p><p><div class="quote"><p>Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower?</p></div><p>Yes.</p><p>Calculations? It&rsquo;s an e-mail, not a spreadsheet. You can&rsquo;t calculate words!</p></div>
	</htmltext>
<tokenext>There are actually a number of reasons why HTTPS is slower : Setting up the HTTPS connection takes extra time ; Encrypting/decrypting the data takes extra time , as you said ; Don    t tell anyone , but ISPs might tend to prioritize HTTPS traffic lower than HTTP ; ...if not just outright throttle it , which some undoubtedly do...Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower ? Yes.Calculations ?
It    s an e-mail , not a spreadsheet .
You can    t calculate words !</tokentext>
<sentencetext>There are actually a number of reasons why HTTPS is slower:Setting up the HTTPS connection takes extra time;Encrypting/decrypting the data takes extra time, as you said;Don’t tell anyone, but ISPs might tend to prioritize HTTPS traffic lower than HTTP;...if not just outright throttle it, which some undoubtedly do...Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower?Yes.Calculations?
It’s an e-mail, not a spreadsheet.
You can’t calculate words!
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757862</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764144</id>
	<title>Re:pochta.ru / smtp.ru</title>
	<author>Anonymous</author>
	<datestamp>1263484920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yup, it is secure but the cert seems invalid. My firefox browser gives me the "This Connection is Untrusted" message.</p><p>Stop promoting these amateurs as alternatives to google.</p></htmltext>
<tokenext>Yup , it is secure but the cert seems invalid .
My firefox browser gives me the " This Connection is Untrusted " message.Stop promoting these amateurs as alternatives to google .</tokentext>
<sentencetext>Yup, it is secure but the cert seems invalid.
My firefox browser gives me the "This Connection is Untrusted" message.Stop promoting these amateurs as alternatives to google.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758212</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761628</id>
	<title>Re:Wait, what?</title>
	<author>Anonymous</author>
	<datestamp>1263500460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Since this hasn't been mentioned yet:</p><p>Transparent proxies (yes, some ISPs use them) also can't deal with encrypted data, since for encryption to work they have to not know what you got.</p></htmltext>
<tokenext>Since this has n't been mentioned yet : Transparent proxies ( yes , some ISPs use them ) also ca n't deal with encrypted data , since for encryption to work they have to not know what you got .</tokentext>
<sentencetext>Since this hasn't been mentioned yet:Transparent proxies (yes, some ISPs use them) also can't deal with encrypted data, since for encryption to work they have to not know what you got.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757714</id>
	<title>Re:Intercepting emails</title>
	<author>AHuxley</author>
	<datestamp>1263384000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Its all in plain text until sent, thats how LOE gets to read, google is a good company.<br>The end users feels safe as they are using the "s" and no more plain text in the wild.<br>
Google would have never offered "s" unless they have a backdoor.</htmltext>
<tokenext>Its all in plain text until sent , thats how LOE gets to read , google is a good company.The end users feels safe as they are using the " s " and no more plain text in the wild .
Google would have never offered " s " unless they have a backdoor .</tokentext>
<sentencetext>Its all in plain text until sent, thats how LOE gets to read, google is a good company.The end users feels safe as they are using the "s" and no more plain text in the wild.
Google would have never offered "s" unless they have a backdoor.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757542</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757760</id>
	<title>Re:Wait, what?</title>
	<author>Hairy1</author>
	<datestamp>1263384300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Apart from the CPU of encrypting there is the issue of compression. Perhaps some physical network links use compression, and encrypted traffic can't be compressed?</p></htmltext>
<tokenext>Apart from the CPU of encrypting there is the issue of compression .
Perhaps some physical network links use compression , and encrypted traffic ca n't be compressed ?</tokentext>
<sentencetext>Apart from the CPU of encrypting there is the issue of compression.
Perhaps some physical network links use compression, and encrypted traffic can't be compressed?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761618</id>
	<title>Temporary fix</title>
	<author>WinstonWolfIT</author>
	<datestamp>1263500340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Someday Google will be larger than even China, and then nobody will dare mess with their servers.</htmltext>
<tokenext>Someday Google will be larger than even China , and then nobody will dare mess with their servers .</tokentext>
<sentencetext>Someday Google will be larger than even China, and then nobody will dare mess with their servers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759100</id>
	<title>Re:Wait, what?</title>
	<author>shish</author>
	<datestamp>1263390000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Is it too technical now to say that encrypting data requires extra calculations</p></div><p>Speaking as someone who has recently been providing tech support for his mother -- yes, that is *far* too technical for the average non-IT person<nobr> <wbr></nobr>:-(</p></div>
	</htmltext>
<tokenext>Is it too technical now to say that encrypting data requires extra calculationsSpeaking as someone who has recently been providing tech support for his mother -- yes , that is * far * too technical for the average non-IT person : - (</tokentext>
<sentencetext>Is it too technical now to say that encrypting data requires extra calculationsSpeaking as someone who has recently been providing tech support for his mother -- yes, that is *far* too technical for the average non-IT person :-(
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757862</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759418</id>
	<title>Re:Next step: encryption at rest</title>
	<author>ratboy666</author>
	<datestamp>1263391620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Dreaming? Nah.</p><p>I use "Dropbox" to move/synchronize files. Of course, I leave the silly default files alone.</p><p>But my own stuff? How about that lovely file "DrMm9Vs1udHmzdZG41chJ5,K"?<br>That one's only 77 bytes long -- I guess they could figure out which files I update most often, and, given enough compute power, figure out that THAT file is an idea I jotted down last week...</p><p>Just encrypt the stinking data BEFORE you send it to them. It's cloud survival 101.</p></htmltext>
<tokenext>Dreaming ?
Nah.I use " Dropbox " to move/synchronize files .
Of course , I leave the silly default files alone.But my own stuff ?
How about that lovely file " DrMm9Vs1udHmzdZG41chJ5,K " ? That one 's only 77 bytes long -- I guess they could figure out which files I update most often , and , given enough compute power , figure out that THAT file is an idea I jotted down last week...Just encrypt the stinking data BEFORE you send it to them .
It 's cloud survival 101 .</tokentext>
<sentencetext>Dreaming?
Nah.I use "Dropbox" to move/synchronize files.
Of course, I leave the silly default files alone.But my own stuff?
How about that lovely file "DrMm9Vs1udHmzdZG41chJ5,K"?That one's only 77 bytes long -- I guess they could figure out which files I update most often, and, given enough compute power, figure out that THAT file is an idea I jotted down last week...Just encrypt the stinking data BEFORE you send it to them.
It's cloud survival 101.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762048</id>
	<title>Re:What about slashdot?</title>
	<author>z-j-y</author>
	<datestamp>1263464580000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>I really want EVERY site I visit to use https. Why doesn't slashdot?</p></div></blockquote><p>because there's a downside: https can make your browsing slower since encrypted data doesn't travel across the web as quickly as unencrypted data.</p></div>
	</htmltext>
<tokenext>I really want EVERY site I visit to use https .
Why does n't slashdot ? because there 's a downside : https can make your browsing slower since encrypted data does n't travel across the web as quickly as unencrypted data .</tokentext>
<sentencetext>I really want EVERY site I visit to use https.
Why doesn't slashdot?because there's a downside: https can make your browsing slower since encrypted data doesn't travel across the web as quickly as unencrypted data.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>Anonymous</author>
	<datestamp>1263388740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>I don't know, I think there are some things that don't need encryption. I don't think I will ever need encryption to read google news, for example, or to watch youtube movies.</p></div><p>Actually yes you need to encrypt that too.</p><p>If you are selective about what you encrypt, then the best assumption to make is that the things you don't want/need to hide are plain text, and the things you want/need to hide are encrypted.</p><p>Now when I am watching your data stream and see some google news, a youtube video, and finally an encrypted block of data, it is almost certain that whatever is in that encrypted block of data is worth my while to try and crack, as it is clearly data you want hidden.</p><p>If you encrypt everything all the time, then I would always wonder what you are hiding (if anything!)<br>I could take some of your encrypted data and try to crack it.  Say it works once or twice, and all I see are you reading your daily news, and some video of a kitten falling over on youtube.   Well hell, suddenly not only did I waste a lot of time cracking that encryption for nothing, but I would assume (possibly mistakenly) that you very well might not have anything to hide, and there is no reason to specifically look into anything you are doing.<br>Even if I don't assume that, and either assume or just know that you DO have something to hide...  Well as a hacker, where would I start?  I don't have all the time and processing power in the world to brute force everything you do.  I would always be very behind your 'now' traffic.  By the time I eventually did get to decrypting the part you really wanted hidden, it could be years or decades later.  How much use would that data be so long after the fact?  More often than not, the older the data, the less useful it is.</p><p>Encrypt everything.  Nothing looks suspicious and out of the norm, so if/when you do something that you do want/need hidden from hackers, a hacker wouldn't even know it happened let alone know where to start looking for it.</p><p>Not encrypting everything just paints a huge target on the exact data you are wanting to hide in the first place.</p></div>
	</htmltext>
<tokenext>I do n't know , I think there are some things that do n't need encryption .
I do n't think I will ever need encryption to read google news , for example , or to watch youtube movies.Actually yes you need to encrypt that too.If you are selective about what you encrypt , then the best assumption to make is that the things you do n't want/need to hide are plain text , and the things you want/need to hide are encrypted.Now when I am watching your data stream and see some google news , a youtube video , and finally an encrypted block of data , it is almost certain that whatever is in that encrypted block of data is worth my while to try and crack , as it is clearly data you want hidden.If you encrypt everything all the time , then I would always wonder what you are hiding ( if anything !
) I could take some of your encrypted data and try to crack it .
Say it works once or twice , and all I see are you reading your daily news , and some video of a kitten falling over on youtube .
Well hell , suddenly not only did I waste a lot of time cracking that encryption for nothing , but I would assume ( possibly mistakenly ) that you very well might not have anything to hide , and there is no reason to specifically look into anything you are doing.Even if I do n't assume that , and either assume or just know that you DO have something to hide... Well as a hacker , where would I start ?
I do n't have all the time and processing power in the world to brute force everything you do .
I would always be very behind your 'now ' traffic .
By the time I eventually did get to decrypting the part you really wanted hidden , it could be years or decades later .
How much use would that data be so long after the fact ?
More often than not , the older the data , the less useful it is.Encrypt everything .
Nothing looks suspicious and out of the norm , so if/when you do something that you do want/need hidden from hackers , a hacker would n't even know it happened let alone know where to start looking for it.Not encrypting everything just paints a huge target on the exact data you are wanting to hide in the first place .</tokentext>
<sentencetext>I don't know, I think there are some things that don't need encryption.
I don't think I will ever need encryption to read google news, for example, or to watch youtube movies.Actually yes you need to encrypt that too.If you are selective about what you encrypt, then the best assumption to make is that the things you don't want/need to hide are plain text, and the things you want/need to hide are encrypted.Now when I am watching your data stream and see some google news, a youtube video, and finally an encrypted block of data, it is almost certain that whatever is in that encrypted block of data is worth my while to try and crack, as it is clearly data you want hidden.If you encrypt everything all the time, then I would always wonder what you are hiding (if anything!
)I could take some of your encrypted data and try to crack it.
Say it works once or twice, and all I see are you reading your daily news, and some video of a kitten falling over on youtube.
Well hell, suddenly not only did I waste a lot of time cracking that encryption for nothing, but I would assume (possibly mistakenly) that you very well might not have anything to hide, and there is no reason to specifically look into anything you are doing.Even if I don't assume that, and either assume or just know that you DO have something to hide...  Well as a hacker, where would I start?
I don't have all the time and processing power in the world to brute force everything you do.
I would always be very behind your 'now' traffic.
By the time I eventually did get to decrypting the part you really wanted hidden, it could be years or decades later.
How much use would that data be so long after the fact?
More often than not, the older the data, the less useful it is.Encrypt everything.
Nothing looks suspicious and out of the norm, so if/when you do something that you do want/need hidden from hackers, a hacker wouldn't even know it happened let alone know where to start looking for it.Not encrypting everything just paints a huge target on the exact data you are wanting to hide in the first place.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758052</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760062</id>
	<title>Re:What about slashdot?</title>
	<author>icebraining</author>
	<datestamp>1263396600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Because there's no reason to. What are you trying to protect, valuable mod points?</p><p>Oh, and don't say "I want to encrypt everything, so the hackers don't know what's important". HTTPS doesn't hide the IP you're accessing. If you want that kind of protecting, you should get a secure VPN or Tor.</p></htmltext>
<tokenext>Because there 's no reason to .
What are you trying to protect , valuable mod points ? Oh , and do n't say " I want to encrypt everything , so the hackers do n't know what 's important " .
HTTPS does n't hide the IP you 're accessing .
If you want that kind of protecting , you should get a secure VPN or Tor .</tokentext>
<sentencetext>Because there's no reason to.
What are you trying to protect, valuable mod points?Oh, and don't say "I want to encrypt everything, so the hackers don't know what's important".
HTTPS doesn't hide the IP you're accessing.
If you want that kind of protecting, you should get a secure VPN or Tor.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761256</id>
	<title>Re:Next step: encryption at rest</title>
	<author>mlts</author>
	<datestamp>1263408900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>With TrueCrypt, what I used to do when moving files between college and home was to create a TC volume, stuff the goodies in it at one destination, using a keyfile off a smart card, then upload that.  Then when I arrived at the other destination, I'd pull the TC volume from the cloud storage site, get to work, then re-upload it when done.  Because I'm using a keyfile on a smart card, the cloud provider isn't going to have the relatively [1] easy attack surface that just a passphrase offers.  This also helps mitigate "dumb" keyloggers.  A keylogger might be able to grab my smart card's PIN, but without the card, it won't do the remote blackhat much good.  However a "smart" keylogger that can snarf the PIN, then forge an access session to the smart card, yanking out the keyfile, then sending that to the attacker's site is feasible, especially if a target is a high value.</p><p>[1]:  Relative is the word here, because a 20+ character password is extremely hard to guess, while a randomly generated keyfile that only exists on a smart card pretty much forces an attacker to have to brute force the whole 256 bit keyspace.</p></htmltext>
<tokenext>With TrueCrypt , what I used to do when moving files between college and home was to create a TC volume , stuff the goodies in it at one destination , using a keyfile off a smart card , then upload that .
Then when I arrived at the other destination , I 'd pull the TC volume from the cloud storage site , get to work , then re-upload it when done .
Because I 'm using a keyfile on a smart card , the cloud provider is n't going to have the relatively [ 1 ] easy attack surface that just a passphrase offers .
This also helps mitigate " dumb " keyloggers .
A keylogger might be able to grab my smart card 's PIN , but without the card , it wo n't do the remote blackhat much good .
However a " smart " keylogger that can snarf the PIN , then forge an access session to the smart card , yanking out the keyfile , then sending that to the attacker 's site is feasible , especially if a target is a high value .
[ 1 ] : Relative is the word here , because a 20 + character password is extremely hard to guess , while a randomly generated keyfile that only exists on a smart card pretty much forces an attacker to have to brute force the whole 256 bit keyspace .</tokentext>
<sentencetext>With TrueCrypt, what I used to do when moving files between college and home was to create a TC volume, stuff the goodies in it at one destination, using a keyfile off a smart card, then upload that.
Then when I arrived at the other destination, I'd pull the TC volume from the cloud storage site, get to work, then re-upload it when done.
Because I'm using a keyfile on a smart card, the cloud provider isn't going to have the relatively [1] easy attack surface that just a passphrase offers.
This also helps mitigate "dumb" keyloggers.
A keylogger might be able to grab my smart card's PIN, but without the card, it won't do the remote blackhat much good.
However a "smart" keylogger that can snarf the PIN, then forge an access session to the smart card, yanking out the keyfile, then sending that to the attacker's site is feasible, especially if a target is a high value.
[1]:  Relative is the word here, because a 20+ character password is extremely hard to guess, while a randomly generated keyfile that only exists on a smart card pretty much forces an attacker to have to brute force the whole 256 bit keyspace.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760898</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>whovian</author>
	<datestamp>1263404640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I've long held that the only answer to pervasive surveillance is to encrypt everything.</p></div><p>Law enforcement and broadband providers aren't going to like that.  Ubiquitous encryption shoots down their "argument" that only criminals would encrypt their traffic.</p></div>
	</htmltext>
<tokenext>I 've long held that the only answer to pervasive surveillance is to encrypt everything.Law enforcement and broadband providers are n't going to like that .
Ubiquitous encryption shoots down their " argument " that only criminals would encrypt their traffic .</tokentext>
<sentencetext>I've long held that the only answer to pervasive surveillance is to encrypt everything.Law enforcement and broadband providers aren't going to like that.
Ubiquitous encryption shoots down their "argument" that only criminals would encrypt their traffic.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760412</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>John Hasler</author>
	<datestamp>1263400080000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>&gt; Not encrypting everything just paints a huge target on the exact data you<br>&gt; are wanting to hide in the first place.</p><p>Right.  So just encrypt the kitten videos and send lots of tantalizing stuff in the clear.  That'll fix 'em.</p></htmltext>
<tokenext>&gt; Not encrypting everything just paints a huge target on the exact data you &gt; are wanting to hide in the first place.Right .
So just encrypt the kitten videos and send lots of tantalizing stuff in the clear .
That 'll fix 'em .</tokentext>
<sentencetext>&gt; Not encrypting everything just paints a huge target on the exact data you&gt; are wanting to hide in the first place.Right.
So just encrypt the kitten videos and send lots of tantalizing stuff in the clear.
That'll fix 'em.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759252</id>
	<title>NIKE JORDAN SHOES,COACH,GUCCI,HANDBAG,POLO,TSHIRTS</title>
	<author>Lawrence1986</author>
	<datestamp>1263390780000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><a href="http://www.allbyer.com/" title="allbyer.com" rel="nofollow">http://www.allbyer.com/</a> [allbyer.com]
Hi,Dear Ladies and Gentlemen,Here are the most popular, most stylish and avant-garde shoes,handbags,Tshirts, jacket,Tracksuit w ect...NIKE SHOX,JORDAN SHOES 1-24,AF,DUNK,SB,PUMA<nobr> <wbr></nobr>,R4,NZ,OZ,T1-TL3) $35HANDBGAS(COACH,L V, DG, ED HARDY) $35TSHIRTS (POLO<nobr> <wbr></nobr>,ED HARDY, LACOSTE) $16
thanks... For details, please consult <a href="http://www.allbyer.com/" title="allbyer.com" rel="nofollow">http://www.allbyer.com/</a> [allbyer.com]</htmltext>
<tokenext>http : //www.allbyer.com/ [ allbyer.com ] Hi,Dear Ladies and Gentlemen,Here are the most popular , most stylish and avant-garde shoes,handbags,Tshirts , jacket,Tracksuit w ect...NIKE SHOX,JORDAN SHOES 1-24,AF,DUNK,SB,PUMA ,R4,NZ,OZ,T1-TL3 ) $ 35HANDBGAS ( COACH,L V , DG , ED HARDY ) $ 35TSHIRTS ( POLO ,ED HARDY , LACOSTE ) $ 16 thanks... For details , please consult http : //www.allbyer.com/ [ allbyer.com ]</tokentext>
<sentencetext>http://www.allbyer.com/ [allbyer.com]
Hi,Dear Ladies and Gentlemen,Here are the most popular, most stylish and avant-garde shoes,handbags,Tshirts, jacket,Tracksuit w ect...NIKE SHOX,JORDAN SHOES 1-24,AF,DUNK,SB,PUMA ,R4,NZ,OZ,T1-TL3) $35HANDBGAS(COACH,L V, DG, ED HARDY) $35TSHIRTS (POLO ,ED HARDY, LACOSTE) $16
thanks... For details, please consult http://www.allbyer.com/ [allbyer.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30795050</id>
	<title>Re:So does Wikipedia...</title>
	<author>harmonise</author>
	<datestamp>1263651360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>...if you begin with the right URL.</p></div></blockquote><p>It doesn't work for me. It makes a HTTPS connection but then Firefox says that the connection is not using encryption.</p></div>
	</htmltext>
<tokenext>...if you begin with the right URL.It does n't work for me .
It makes a HTTPS connection but then Firefox says that the connection is not using encryption .</tokentext>
<sentencetext>...if you begin with the right URL.It doesn't work for me.
It makes a HTTPS connection but then Firefox says that the connection is not using encryption.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758510</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757610</id>
	<title>Re:Wait, what?</title>
	<author>The End Of Days</author>
	<datestamp>1263383640000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I suspect they were just dumbing down all the overheads of using encryption into one catchall sentence.</p></htmltext>
<tokenext>I suspect they were just dumbing down all the overheads of using encryption into one catchall sentence .</tokentext>
<sentencetext>I suspect they were just dumbing down all the overheads of using encryption into one catchall sentence.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758914</id>
	<title>Blackberry</title>
	<author>tgetzoya</author>
	<datestamp>1263389100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>GMail items still shows up on my Blackberry, and that's all I care about.  If I need to write a long email then I'll log onto the computer.  <br> <br>I don't notice the speed difference at all.</htmltext>
<tokenext>GMail items still shows up on my Blackberry , and that 's all I care about .
If I need to write a long email then I 'll log onto the computer .
I do n't notice the speed difference at all .</tokentext>
<sentencetext>GMail items still shows up on my Blackberry, and that's all I care about.
If I need to write a long email then I'll log onto the computer.
I don't notice the speed difference at all.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758678</id>
	<title>Re:iGoogle support?</title>
	<author>espamo</author>
	<datestamp>1263388080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yes, it didn't used to, but It's been working for me for awhile also, maybe a month. The gadget's iframe address uses https.</htmltext>
<tokenext>Yes , it did n't used to , but It 's been working for me for awhile also , maybe a month .
The gadget 's iframe address uses https .</tokentext>
<sentencetext>Yes, it didn't used to, but It's been working for me for awhile also, maybe a month.
The gadget's iframe address uses https.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765320</id>
	<title>Re:Next step: encryption at rest</title>
	<author>Sloppy</author>
	<datestamp>1263488460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Attacker with physical access to the file (stored at Google) can only read the plaintext if he also happens to have physical access to the key (stored on your personal computer).  Most Google employees don't have physical access to the users' houses.</p></htmltext>
<tokenext>Attacker with physical access to the file ( stored at Google ) can only read the plaintext if he also happens to have physical access to the key ( stored on your personal computer ) .
Most Google employees do n't have physical access to the users ' houses .</tokentext>
<sentencetext>Attacker with physical access to the file (stored at Google) can only read the plaintext if he also happens to have physical access to the key (stored on your personal computer).
Most Google employees don't have physical access to the users' houses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763124</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760080</id>
	<title>Re:pochta.ru / smtp.ru</title>
	<author>vbraga</author>
	<datestamp>1263396780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There's also <a href="http://mail.ru/" title="mail.ru">mail.ru</a> [mail.ru]. English language sign up is gone, it's possible to get an account using Google Translate.</p></htmltext>
<tokenext>There 's also mail.ru [ mail.ru ] .
English language sign up is gone , it 's possible to get an account using Google Translate .</tokentext>
<sentencetext>There's also mail.ru [mail.ru].
English language sign up is gone, it's possible to get an account using Google Translate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758212</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759226</id>
	<title>Re:Will Yahoo! follow suit?</title>
	<author>shish</author>
	<datestamp>1263390720000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>I hate to read mail at cafes and other places where I'm not certain of the LAN security.</p></div><p>Weird, I <i>love</i> reading mail at insecure cafes... you can sit in the corner and play games like "match the email to the person" and "convince the businessman that you're a replacement representative for his meeting"<nobr> <wbr></nobr>:-)</p></div>
	</htmltext>
<tokenext>I hate to read mail at cafes and other places where I 'm not certain of the LAN security.Weird , I love reading mail at insecure cafes... you can sit in the corner and play games like " match the email to the person " and " convince the businessman that you 're a replacement representative for his meeting " : - )</tokentext>
<sentencetext>I hate to read mail at cafes and other places where I'm not certain of the LAN security.Weird, I love reading mail at insecure cafes... you can sit in the corner and play games like "match the email to the person" and "convince the businessman that you're a replacement representative for his meeting" :-)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764068</id>
	<title>Re:Sniffing? I disagree.</title>
	<author>clone53421</author>
	<datestamp>1263484560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I did wonder how they&rsquo;d know if a man-in-the-middle attack occurred, and what information was taken. However, accessing an account directly via POP, IMAP, or the web UI would give you full access to the account if it gave you any at all, I would think.</p><p>I&rsquo;m still trying to remember where you&rsquo;d be able to find out when a Gmail account was registered, though. That does sound like it might be some sort of internal Google tool that was compromised.</p></htmltext>
<tokenext>I did wonder how they    d know if a man-in-the-middle attack occurred , and what information was taken .
However , accessing an account directly via POP , IMAP , or the web UI would give you full access to the account if it gave you any at all , I would think.I    m still trying to remember where you    d be able to find out when a Gmail account was registered , though .
That does sound like it might be some sort of internal Google tool that was compromised .</tokentext>
<sentencetext>I did wonder how they’d know if a man-in-the-middle attack occurred, and what information was taken.
However, accessing an account directly via POP, IMAP, or the web UI would give you full access to the account if it gave you any at all, I would think.I’m still trying to remember where you’d be able to find out when a Gmail account was registered, though.
That does sound like it might be some sort of internal Google tool that was compromised.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757440</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30781120</id>
	<title>Re:No Brainer</title>
	<author>alexo</author>
	<datestamp>1263581340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>and now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default).</p></div></blockquote><p>Gmail is not free, it just uses a different currency.  You pay for it with (some of) your privacy and the actual price can be between zero and infinity, depending on how much you value it.</p><p>If you are willing to consider paid services, fastmail.fm has been doing *S for quite a while.</p></div>
	</htmltext>
<tokenext>and now you show me another free mail service of any significance that has IMAPS , POP3S , SMTPS and now HTTPS ( yes , all with * S , because Gmail requires you to use SSL for SMTP , POP3 and IMAP , and has been doing so since the very beginning , HTTPS was available for use for a while , though not required or offered by default ) .Gmail is not free , it just uses a different currency .
You pay for it with ( some of ) your privacy and the actual price can be between zero and infinity , depending on how much you value it.If you are willing to consider paid services , fastmail.fm has been doing * S for quite a while .</tokentext>
<sentencetext>and now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default).Gmail is not free, it just uses a different currency.
You pay for it with (some of) your privacy and the actual price can be between zero and infinity, depending on how much you value it.If you are willing to consider paid services, fastmail.fm has been doing *S for quite a while.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759554</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763124</id>
	<title>Re:Next step: encryption at rest</title>
	<author>tokul</author>
	<datestamp>1263479340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google's data center. That way even Google employees cannot read our mail. Not for serving up ads. Not for any reason whatsoever.
</p><p>Nah, I'm dreaming.</p></div>
</blockquote><p>
You are not dreaming. You are delusional or missed your security classes. Encryption won't save you from physical access. If service can read file, attacker with physical access can read it too.</p></div>
	</htmltext>
<tokenext>Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google 's data center .
That way even Google employees can not read our mail .
Not for serving up ads .
Not for any reason whatsoever .
Nah , I 'm dreaming .
You are not dreaming .
You are delusional or missed your security classes .
Encryption wo n't save you from physical access .
If service can read file , attacker with physical access can read it too .</tokentext>
<sentencetext>Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google's data center.
That way even Google employees cannot read our mail.
Not for serving up ads.
Not for any reason whatsoever.
Nah, I'm dreaming.
You are not dreaming.
You are delusional or missed your security classes.
Encryption won't save you from physical access.
If service can read file, attacker with physical access can read it too.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757712</id>
	<title>Not through sniffing</title>
	<author>Charles Dodgeson</author>
	<datestamp>1263384000000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Apparently the two compromised accounts were because of "access a system used to help Google comply with search warrants by providing data on Google users."  I've <a href="http://jpgoldberg.blogspot.com/2010/01/google-attack-vectors.html" title="blogspot.com">blogged</a> [blogspot.com] about this.  And my source for all of that is from <a href="http://www.computerworld.com/s/article/9144221/Google\_attack\_part\_of\_widespread\_spying\_effort" title="computerworld.com">an article</a> [computerworld.com] in Computer World.</htmltext>
<tokenext>Apparently the two compromised accounts were because of " access a system used to help Google comply with search warrants by providing data on Google users .
" I 've blogged [ blogspot.com ] about this .
And my source for all of that is from an article [ computerworld.com ] in Computer World .</tokentext>
<sentencetext>Apparently the two compromised accounts were because of "access a system used to help Google comply with search warrants by providing data on Google users.
"  I've blogged [blogspot.com] about this.
And my source for all of that is from an article [computerworld.com] in Computer World.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757862</id>
	<title>Wait, what?</title>
	<author>ScriptedReplay</author>
	<datestamp>1263384780000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since <b>encrypted data doesn't travel across the web as quickly as unencrypted data</b>.'</p></div><p>Huh? Encrypted bits are asthmatic and can't run as fast as unencrypted ones? Coming from someone at Google this statement is quite the WTF. Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower?</p></div>
	</htmltext>
<tokenext>'We initially left the choice of using it up to you because there 's a downside : https can make your mail slower since encrypted data does n't travel across the web as quickly as unencrypted data.'Huh ?
Encrypted bits are asthmatic and ca n't run as fast as unencrypted ones ?
Coming from someone at Google this statement is quite the WTF .
Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower ?</tokentext>
<sentencetext>'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.'Huh?
Encrypted bits are asthmatic and can't run as fast as unencrypted ones?
Coming from someone at Google this statement is quite the WTF.
Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758092</id>
	<title>Re:Slightly off-topic...</title>
	<author>Anonymous</author>
	<datestamp>1263385860000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Becuase you arn't meant to use "." in the user part of an email address.</p></htmltext>
<tokenext>Becuase you ar n't meant to use " .
" in the user part of an email address .</tokentext>
<sentencetext>Becuase you arn't meant to use ".
" in the user part of an email address.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757960</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670</id>
	<title>Next step: encryption at rest</title>
	<author>giladpn</author>
	<datestamp>1263383820000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>OK, better late then never. Good that Google has finally introduced HTTPS as a default.
<br> <br>
Now the next feature we all need is encryption of the content of our data when it is <i>at rest on disks</i> in Google's data center. That way even Google employees cannot read our mail. Not for serving up ads. Not for any reason whatsoever.
<br> <br>
And after that, Facebook and Twitter...
<br> <br>
Nah, I'm dreaming.</htmltext>
<tokenext>OK , better late then never .
Good that Google has finally introduced HTTPS as a default .
Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google 's data center .
That way even Google employees can not read our mail .
Not for serving up ads .
Not for any reason whatsoever .
And after that , Facebook and Twitter.. . Nah , I 'm dreaming .</tokentext>
<sentencetext>OK, better late then never.
Good that Google has finally introduced HTTPS as a default.
Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google's data center.
That way even Google employees cannot read our mail.
Not for serving up ads.
Not for any reason whatsoever.
And after that, Facebook and Twitter...
 
Nah, I'm dreaming.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761792</id>
	<title>Semantics</title>
	<author>xenobyte</author>
	<datestamp>1263460020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>... https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.<nobr> <wbr></nobr>...</p></div></blockquote><p>That is complete bull... Data is data (1's and 0's) and it travels with the same speed regardless of what those bit represent.</p><p>The correct way of saying what the author intended to say is something like this: "https can make your mail slower compared to unencrypted http since encrypted data requires some additional overhead and some additional processing power to encrypt and decrypt at each end".</p></div>
	</htmltext>
<tokenext>... https can make your mail slower since encrypted data does n't travel across the web as quickly as unencrypted data .
...That is complete bull... Data is data ( 1 's and 0 's ) and it travels with the same speed regardless of what those bit represent.The correct way of saying what the author intended to say is something like this : " https can make your mail slower compared to unencrypted http since encrypted data requires some additional overhead and some additional processing power to encrypt and decrypt at each end " .</tokentext>
<sentencetext>... https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.
...That is complete bull... Data is data (1's and 0's) and it travels with the same speed regardless of what those bit represent.The correct way of saying what the author intended to say is something like this: "https can make your mail slower compared to unencrypted http since encrypted data requires some additional overhead and some additional processing power to encrypt and decrypt at each end".
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758546</id>
	<title>Huh? HTTPs?</title>
	<author>Hurricane78</author>
	<datestamp>1263387480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Dont&rsquo; you mean IMAPS and SSMTP?</p></htmltext>
<tokenext>Dont    you mean IMAPS and SSMTP ?</tokentext>
<sentencetext>Dont’ you mean IMAPS and SSMTP?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761992</id>
	<title>Re:iGoogle support?</title>
	<author>Inda</author>
	<datestamp>1263463620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I use HTTPS on iGoogle and the Gmail gadget works fine.<br><br>OK, that's a lie, but it works 99\% of the time. Sometime it asks me to re-enter my password, sometime it tells me it can't use HTTPS but a refresh sorts that out.<br><br>'Re-install' your gadget.<br><br>Actually, thinking about it some more, I do add something to the query string to force the google.com site to use British english, can't remember what from this PC. I seem to remember this helped with HTTPS early when Google let us use it... It may have been my unwillingness to use that nav-menu on the left... Um, I use HTTPS on iGoogle's Gmail gadget.</htmltext>
<tokenext>I use HTTPS on iGoogle and the Gmail gadget works fine.OK , that 's a lie , but it works 99 \ % of the time .
Sometime it asks me to re-enter my password , sometime it tells me it ca n't use HTTPS but a refresh sorts that out .
'Re-install ' your gadget.Actually , thinking about it some more , I do add something to the query string to force the google.com site to use British english , ca n't remember what from this PC .
I seem to remember this helped with HTTPS early when Google let us use it... It may have been my unwillingness to use that nav-menu on the left... Um , I use HTTPS on iGoogle 's Gmail gadget .</tokentext>
<sentencetext>I use HTTPS on iGoogle and the Gmail gadget works fine.OK, that's a lie, but it works 99\% of the time.
Sometime it asks me to re-enter my password, sometime it tells me it can't use HTTPS but a refresh sorts that out.
'Re-install' your gadget.Actually, thinking about it some more, I do add something to the query string to force the google.com site to use British english, can't remember what from this PC.
I seem to remember this helped with HTTPS early when Google let us use it... It may have been my unwillingness to use that nav-menu on the left... Um, I use HTTPS on iGoogle's Gmail gadget.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30771146</id>
	<title>Good for US</title>
	<author>Anonymous</author>
	<datestamp>1263465000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>stopping the rest of world from lawful interception</htmltext>
<tokenext>stopping the rest of world from lawful interception</tokentext>
<sentencetext>stopping the rest of world from lawful interception</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758382</id>
	<title>Re:Slightly off-topic...</title>
	<author>maxume</author>
	<datestamp>1263386820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Because the system disregards the periods. The upshot is that no one can use the bobalice account to try to impersonate bob.alice.</p></htmltext>
<tokenext>Because the system disregards the periods .
The upshot is that no one can use the bobalice account to try to impersonate bob.alice .</tokentext>
<sentencetext>Because the system disregards the periods.
The upshot is that no one can use the bobalice account to try to impersonate bob.alice.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757960</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761208</id>
	<title>Re:Wait, what?</title>
	<author>bendodge</author>
	<datestamp>1263408540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not so fast. I bet a nickel your ISP prioritizes HTTPS lower than HTTP on their network.</p></htmltext>
<tokenext>Not so fast .
I bet a nickel your ISP prioritizes HTTPS lower than HTTP on their network .</tokentext>
<sentencetext>Not so fast.
I bet a nickel your ISP prioritizes HTTPS lower than HTTP on their network.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757862</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759118</id>
	<title>I hope they keep Google Apps in the clear!</title>
	<author>Anonymous</author>
	<datestamp>1263390120000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>If they make Google Apps HTTPS only, I'll be screwed, because my little embedded devices can't handle HTTPS stack.</p></htmltext>
<tokenext>If they make Google Apps HTTPS only , I 'll be screwed , because my little embedded devices ca n't handle HTTPS stack .</tokentext>
<sentencetext>If they make Google Apps HTTPS only, I'll be screwed, because my little embedded devices can't handle HTTPS stack.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759644</id>
	<title>Secure HTTPS is not nearly enough</title>
	<author>Anonymous</author>
	<datestamp>1263393120000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>Purge logs within a reasonable time since making the last octet of IP is not really making the log anonymous.</p><p>Do not store IPs in any of the search logs. I still have not figured out why Google does it. Aside from geographical information and abuse detection you can't really use IP anything, unless you want to provide information to authorities.</p><p>Expire Google cookie each week.</p><p>Provide an anonymous proxy with limited search capabilities.  That way people who really care can get their top 10-20 results while the rest of us can enjoy more garbage and ads<nobr> <wbr></nobr>:)</p><p>Stop any self-sensoring.  Information is out there to be free.</p><p>Put up information on how to make searches anonymous, e.g. how to use TOR, privoxy and other secure tools.</p></htmltext>
<tokenext>Purge logs within a reasonable time since making the last octet of IP is not really making the log anonymous.Do not store IPs in any of the search logs .
I still have not figured out why Google does it .
Aside from geographical information and abuse detection you ca n't really use IP anything , unless you want to provide information to authorities.Expire Google cookie each week.Provide an anonymous proxy with limited search capabilities .
That way people who really care can get their top 10-20 results while the rest of us can enjoy more garbage and ads : ) Stop any self-sensoring .
Information is out there to be free.Put up information on how to make searches anonymous , e.g .
how to use TOR , privoxy and other secure tools .</tokentext>
<sentencetext>Purge logs within a reasonable time since making the last octet of IP is not really making the log anonymous.Do not store IPs in any of the search logs.
I still have not figured out why Google does it.
Aside from geographical information and abuse detection you can't really use IP anything, unless you want to provide information to authorities.Expire Google cookie each week.Provide an anonymous proxy with limited search capabilities.
That way people who really care can get their top 10-20 results while the rest of us can enjoy more garbage and ads :)Stop any self-sensoring.
Information is out there to be free.Put up information on how to make searches anonymous, e.g.
how to use TOR, privoxy and other secure tools.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757730</id>
	<title>Worth it</title>
	<author>Anonymous</author>
	<datestamp>1263384180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The initial slow down because of the encryption overhead will eventually be compensated for with faster networking hardware and technology so it isn't such a burden.</p><p>In the long run it will be better.</p></htmltext>
<tokenext>The initial slow down because of the encryption overhead will eventually be compensated for with faster networking hardware and technology so it is n't such a burden.In the long run it will be better .</tokentext>
<sentencetext>The initial slow down because of the encryption overhead will eventually be compensated for with faster networking hardware and technology so it isn't such a burden.In the long run it will be better.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758676</id>
	<title>Re:The beginning of HTTPS for everything by defaul</title>
	<author>Hurricane78</author>
	<datestamp>1263388020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Since when is HTTP(S) &ldquo;everything&rdquo;? Maybe for those who have never seen something else than HTML and webapps.</p><p>Just set up VPN-like connections. Or think it to the end, and use a Darknet by default.<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>Since when is HTTP ( S )    everything    ?
Maybe for those who have never seen something else than HTML and webapps.Just set up VPN-like connections .
Or think it to the end , and use a Darknet by default .
; )</tokentext>
<sentencetext>Since when is HTTP(S) “everything”?
Maybe for those who have never seen something else than HTML and webapps.Just set up VPN-like connections.
Or think it to the end, and use a Darknet by default.
;)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757666</id>
	<title>Re:Wait, what?</title>
	<author>phizi0n</author>
	<datestamp>1263383820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>1) Encryption/decryption take time. While time for packets to travel across is unchanged, the overhead of (en|de)cryption does add to the overall latency from layer 7 http server to layer 7 client app and vice versa.<br>2) It's possible that some ISP's may have lower QoS priorities for specific encrypted traffic, traffic they can't identify, or port 443.</p></htmltext>
<tokenext>1 ) Encryption/decryption take time .
While time for packets to travel across is unchanged , the overhead of ( en | de ) cryption does add to the overall latency from layer 7 http server to layer 7 client app and vice versa.2 ) It 's possible that some ISP 's may have lower QoS priorities for specific encrypted traffic , traffic they ca n't identify , or port 443 .</tokentext>
<sentencetext>1) Encryption/decryption take time.
While time for packets to travel across is unchanged, the overhead of (en|de)cryption does add to the overall latency from layer 7 http server to layer 7 client app and vice versa.2) It's possible that some ISP's may have lower QoS priorities for specific encrypted traffic, traffic they can't identify, or port 443.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765546</id>
	<title>Re:Huh? HTTPs?</title>
	<author>clone53421</author>
	<datestamp>1263489300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>No, I mean HTTPS. Gmail also has a web interface, you know.</p><p>Initially, only the login page was encrypted, and once you were in, everything was transmitted in the clear. (Just about every other free e-mail service does this, too.) Anyone on your LAN (including on the same wireless signal) could sniff your traffic and see everything that you received.</p><p>Then they enabled full-session HTTPS so that all of the traffic, from login to logout, is encrypted, but it was only available as an option, or if you went to https://mail.google.com/ instead of <a href="http" title="slashdot.org">http</a> [slashdot.org]:. It also wasn&rsquo;t available on Google Apps hosted accounts, but you could still get an encrypted session by using https: in the URL. (They eventually rolled out the optional full-session encryption to the Google Apps accounts.)</p><p>Then it was discovered that a hacker could access your account by requesting your session cookie with a standard HTTP request. (Normally, the cookie is sent during the encrypted login process.) Once they got your session cookie, it would think they were logged in and they could get full access to your account until the session timed out (but still couldn&rsquo;t do anything that would require knowing your password &ndash; e.g. changing your password). This was fixed by marking the cookie as secure-connection-only so that it wouldn&rsquo;t be transmitted except by HTTPS.</p><p>Now they&rsquo;re taking out the option of using an insecure (HTTP) connection altogether. Your entire session, from login to logout, is over an encrypted connection. Most other free e-mail services still don&rsquo;t even give this as an option for their web-based interfaces, partly because it puts a higher load on the server.</p></htmltext>
<tokenext>No , I mean HTTPS .
Gmail also has a web interface , you know.Initially , only the login page was encrypted , and once you were in , everything was transmitted in the clear .
( Just about every other free e-mail service does this , too .
) Anyone on your LAN ( including on the same wireless signal ) could sniff your traffic and see everything that you received.Then they enabled full-session HTTPS so that all of the traffic , from login to logout , is encrypted , but it was only available as an option , or if you went to https : //mail.google.com/ instead of http [ slashdot.org ] : .
It also wasn    t available on Google Apps hosted accounts , but you could still get an encrypted session by using https : in the URL .
( They eventually rolled out the optional full-session encryption to the Google Apps accounts .
) Then it was discovered that a hacker could access your account by requesting your session cookie with a standard HTTP request .
( Normally , the cookie is sent during the encrypted login process .
) Once they got your session cookie , it would think they were logged in and they could get full access to your account until the session timed out ( but still couldn    t do anything that would require knowing your password    e.g .
changing your password ) .
This was fixed by marking the cookie as secure-connection-only so that it wouldn    t be transmitted except by HTTPS.Now they    re taking out the option of using an insecure ( HTTP ) connection altogether .
Your entire session , from login to logout , is over an encrypted connection .
Most other free e-mail services still don    t even give this as an option for their web-based interfaces , partly because it puts a higher load on the server .</tokentext>
<sentencetext>No, I mean HTTPS.
Gmail also has a web interface, you know.Initially, only the login page was encrypted, and once you were in, everything was transmitted in the clear.
(Just about every other free e-mail service does this, too.
) Anyone on your LAN (including on the same wireless signal) could sniff your traffic and see everything that you received.Then they enabled full-session HTTPS so that all of the traffic, from login to logout, is encrypted, but it was only available as an option, or if you went to https://mail.google.com/ instead of http [slashdot.org]:.
It also wasn’t available on Google Apps hosted accounts, but you could still get an encrypted session by using https: in the URL.
(They eventually rolled out the optional full-session encryption to the Google Apps accounts.
)Then it was discovered that a hacker could access your account by requesting your session cookie with a standard HTTP request.
(Normally, the cookie is sent during the encrypted login process.
) Once they got your session cookie, it would think they were logged in and they could get full access to your account until the session timed out (but still couldn’t do anything that would require knowing your password – e.g.
changing your password).
This was fixed by marking the cookie as secure-connection-only so that it wouldn’t be transmitted except by HTTPS.Now they’re taking out the option of using an insecure (HTTP) connection altogether.
Your entire session, from login to logout, is over an encrypted connection.
Most other free e-mail services still don’t even give this as an option for their web-based interfaces, partly because it puts a higher load on the server.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30766160</id>
	<title>Re:encrypted data slow? WTF?</title>
	<author>clone53421</author>
	<datestamp>1263491340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Reference please? How would encrypted data travel any different than unencrypted date? Routers don't look at content and the difference in payload sizes is negligible.</p></div><p>It takes longer to establish an HTTPS connection than an HTTP connection. It also requires encryption on the server and decryption on the client, both of which take a little extra time. Finally, encrypted data doesn&rsquo;t compress well at all, and data is normally compressed as it is sent over the internet. With HTTPS traffic the encryption happens first and so the compression isn&rsquo;t effective.</p><p>Plus some ISPs try to get away with prioritizing HTTPS traffic lower than HTTP traffic, or they just throttle it altogether, since it&rsquo;s probably them damn file sharers encrypting their traffic so we can&rsquo;t tell what they&rsquo;re downloading.</p><p><div class="quote"><p>Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we're talking about milliseconds, nothing that rises to the level of human perception.</p></div><p>First of all, I&rsquo;m the poster, and that quotation wasn&rsquo;t mine. It was a quotation from the Gmail blog, and I had it nicely set out in its own blockquoted paragraph until Timothy moved it all into one paragraph. Now it&rsquo;s set off in single quotes, which makes it blend into what I wrote.</p><p>Yes, we&rsquo;re talking about milliseconds, and most users wouldn&rsquo;t notice. However, on the server&rsquo;s end, we&rsquo;re talking about thousands or millions of users, which adds up to thousands or millions of milliseconds, which makes their servers slower on the whole, which the users <em>may</em> be able to notice. So it may be a case where if a few users enabled it, the slowdown would be imperceptible, but if <em>all</em> their users were using it, the load on their servers would slow everyone down to a noticeable sluggishness.</p><p><div class="quote"><p>Honestly have to wonder whether the OP is a Yahoo!, Compuserv, or AOL employee, given how out-of-date those companies' email and webmail offerings have become. Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago.</p></div><p>Everyone else converted to HTTPS webmail, you say? Who exactly do you mean by &ldquo;everyone else&rdquo;? The login will always be done securely, but once you are logged in it will typically switch to an unencrypted session.</p></div>
	</htmltext>
<tokenext>Reference please ?
How would encrypted data travel any different than unencrypted date ?
Routers do n't look at content and the difference in payload sizes is negligible.It takes longer to establish an HTTPS connection than an HTTP connection .
It also requires encryption on the server and decryption on the client , both of which take a little extra time .
Finally , encrypted data doesn    t compress well at all , and data is normally compressed as it is sent over the internet .
With HTTPS traffic the encryption happens first and so the compression isn    t effective.Plus some ISPs try to get away with prioritizing HTTPS traffic lower than HTTP traffic , or they just throttle it altogether , since it    s probably them damn file sharers encrypting their traffic so we can    t tell what they    re downloading.Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we 're talking about milliseconds , nothing that rises to the level of human perception.First of all , I    m the poster , and that quotation wasn    t mine .
It was a quotation from the Gmail blog , and I had it nicely set out in its own blockquoted paragraph until Timothy moved it all into one paragraph .
Now it    s set off in single quotes , which makes it blend into what I wrote.Yes , we    re talking about milliseconds , and most users wouldn    t notice .
However , on the server    s end , we    re talking about thousands or millions of users , which adds up to thousands or millions of milliseconds , which makes their servers slower on the whole , which the users may be able to notice .
So it may be a case where if a few users enabled it , the slowdown would be imperceptible , but if all their users were using it , the load on their servers would slow everyone down to a noticeable sluggishness.Honestly have to wonder whether the OP is a Yahoo ! , Compuserv , or AOL employee , given how out-of-date those companies ' email and webmail offerings have become .
Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago.Everyone else converted to HTTPS webmail , you say ?
Who exactly do you mean by    everyone else    ?
The login will always be done securely , but once you are logged in it will typically switch to an unencrypted session .</tokentext>
<sentencetext>Reference please?
How would encrypted data travel any different than unencrypted date?
Routers don't look at content and the difference in payload sizes is negligible.It takes longer to establish an HTTPS connection than an HTTP connection.
It also requires encryption on the server and decryption on the client, both of which take a little extra time.
Finally, encrypted data doesn’t compress well at all, and data is normally compressed as it is sent over the internet.
With HTTPS traffic the encryption happens first and so the compression isn’t effective.Plus some ISPs try to get away with prioritizing HTTPS traffic lower than HTTP traffic, or they just throttle it altogether, since it’s probably them damn file sharers encrypting their traffic so we can’t tell what they’re downloading.Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we're talking about milliseconds, nothing that rises to the level of human perception.First of all, I’m the poster, and that quotation wasn’t mine.
It was a quotation from the Gmail blog, and I had it nicely set out in its own blockquoted paragraph until Timothy moved it all into one paragraph.
Now it’s set off in single quotes, which makes it blend into what I wrote.Yes, we’re talking about milliseconds, and most users wouldn’t notice.
However, on the server’s end, we’re talking about thousands or millions of users, which adds up to thousands or millions of milliseconds, which makes their servers slower on the whole, which the users may be able to notice.
So it may be a case where if a few users enabled it, the slowdown would be imperceptible, but if all their users were using it, the load on their servers would slow everyone down to a noticeable sluggishness.Honestly have to wonder whether the OP is a Yahoo!, Compuserv, or AOL employee, given how out-of-date those companies' email and webmail offerings have become.
Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago.Everyone else converted to HTTPS webmail, you say?
Who exactly do you mean by “everyone else”?
The login will always be done securely, but once you are logged in it will typically switch to an unencrypted session.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758746</id>
	<title>Re:Slightly off-topic...</title>
	<author>hrimhari</author>
	<datestamp>1263388380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>-1 Wrong. Dots have been widely used in the user part of email addresses along with some other punctuation characters. From the <a href="http://en.wikipedia.org/wiki/E-mail\_address" title="wikipedia.org" rel="nofollow">Wikipedia article:</a> [wikipedia.org]</p><p>The local-part of the e-mail address may use any of these ASCII characters:</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; * Uppercase and lowercase English letters (a-z, A-Z)<br>
&nbsp; &nbsp; &nbsp; &nbsp; * Digits 0 to 9<br>
&nbsp; &nbsp; &nbsp; &nbsp; * Characters ! # $ \% &amp; ' * + - / = ? ^ \_ ` { | } ~<br>
&nbsp; &nbsp; &nbsp; &nbsp; * Character . (dot, period, full stop) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively.</p></htmltext>
<tokenext>-1 Wrong .
Dots have been widely used in the user part of email addresses along with some other punctuation characters .
From the Wikipedia article : [ wikipedia.org ] The local-part of the e-mail address may use any of these ASCII characters :         * Uppercase and lowercase English letters ( a-z , A-Z )         * Digits 0 to 9         * Characters !
# $ \ % &amp; ' * + - / = ?
^ \ _ ` { | } ~         * Character .
( dot , period , full stop ) provided that it is not the first or last character , and provided also that it does not appear two or more times consecutively .</tokentext>
<sentencetext>-1 Wrong.
Dots have been widely used in the user part of email addresses along with some other punctuation characters.
From the Wikipedia article: [wikipedia.org]The local-part of the e-mail address may use any of these ASCII characters:
        * Uppercase and lowercase English letters (a-z, A-Z)
        * Digits 0 to 9
        * Characters !
# $ \% &amp; ' * + - / = ?
^ \_ ` { | } ~
        * Character .
(dot, period, full stop) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758092</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757408
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757698
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757628
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757740
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759226
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759118
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765792
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758676
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761604
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759080
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758510
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30795050
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762264
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762048
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760346
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757766
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760878
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758546
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765546
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757760
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757734
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760650
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761792
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762506
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759118
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761236
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757412
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760790
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763950
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760918
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763124
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765320
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757742
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757412
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760790
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761126
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760412
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757560
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757824
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30766160
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757716
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760830
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757862
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764956
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758736
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757610
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757740
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759044
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764282
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762322
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758504
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760080
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757734
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763962
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757666
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760864
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759588
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30772382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758716
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761628
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757818
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760898
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758678
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757714
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759418
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761256
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760062
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757862
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759100
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757966
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760798
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765838
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757804
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758688
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765742
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757742
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757960
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757862
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761208
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757844
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30866374
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757936
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757742
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759554
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30781120
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757740
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759064
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758778
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762240
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30772356
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757960
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758746
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764144
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761992
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757566
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_13_2150245_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757440
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764068
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757408
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757698
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759262
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30772382
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765838
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759118
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761236
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765792
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757488
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757440
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764068
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757432
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761992
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757944
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758678
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757566
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757804
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757552
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761604
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757628
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757844
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759080
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758676
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758504
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758052
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758822
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760412
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760346
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760918
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762322
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757766
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760898
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761792
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762506
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758688
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765742
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757542
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757714
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760864
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757936
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757534
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757716
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757734
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760650
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763962
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757610
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761628
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758716
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757666
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757760
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762264
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757818
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757618
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759588
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757670
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759418
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761256
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763124
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765320
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758736
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764282
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758212
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764144
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760080
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758546
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30765546
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757712
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759912
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30766160
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30866374
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760878
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760830
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759288
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762048
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760062
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758666
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758778
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30762240
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30772356
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758510
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30795050
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757740
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759044
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759064
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759226
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757960
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758092
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758746
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758382
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757456
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757742
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759554
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30781120
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758026
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760150
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30758522
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757966
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760798
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757862
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761208
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30764956
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30759100
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757412
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30760790
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30763950
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30761126
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_13_2150245.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757560
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_13_2150245.30757824
</commentlist>
</conversation>
