<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: And maybe librarians can start pasting ads in books?</title>
	<atom:link href="http://unhinderedbytalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/feed/" rel="self" type="application/rss+xml" />
	<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/</link>
	<description>Not all battles are fought with a sword</description>
	<pubDate>Sat, 11 Oct 2008 15:31:26 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Phi</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28981</link>
		<dc:creator>Phi</dc:creator>
		<pubDate>Wed, 27 Jun 2007 15:16:16 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28981</guid>
		<description>Good point on compressing the HTML - if you're going to encrypt it, compressing it along the way makes a lot of sense.  That won't help much on pre-compressed material like images, however, which often are the bulk of the size of a web page.

I also agree with your thoughts on the speed issues.  A decade back, you could really tell the difference in load times between visiting a secure page and one that wasn't.  Current hardware plus broadband has really washed that out.

I'd have to think more about the PGP solution.  Are you suggesting &lt;em&gt;only&lt;/em&gt; doing public key encryption, or using public key to encrypt a private key?  The former is pretty slow and does tend to bloat messages, and the second seems to just be a different kind of key exchange.  Maybe I'm just missing something?</description>
		<content:encoded><![CDATA[<p>Good point on compressing the HTML - if you&#8217;re going to encrypt it, compressing it along the way makes a lot of sense.  That won&#8217;t help much on pre-compressed material like images, however, which often are the bulk of the size of a web page.</p>
<p>I also agree with your thoughts on the speed issues.  A decade back, you could really tell the difference in load times between visiting a secure page and one that wasn&#8217;t.  Current hardware plus broadband has really washed that out.</p>
<p>I&#8217;d have to think more about the PGP solution.  Are you suggesting <em>only</em> doing public key encryption, or using public key to encrypt a private key?  The former is pretty slow and does tend to bloat messages, and the second seems to just be a different kind of key exchange.  Maybe I&#8217;m just missing something?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: travc</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28956</link>
		<dc:creator>travc</dc:creator>
		<pubDate>Wed, 27 Jun 2007 08:15:28 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28956</guid>
		<description>Um, just a quibble, but encryption doesn't necisarially mean larger in size.  One big benefit of having encrypted html would be that the same mechanism could easily compress / decompress the page at the same time.

Slowness wise, it shouldn't make any sort of difference unless you have a very very slow (processor wise) machine.  On the server side, you can just pregen and/or cache the encrypted pages, so no problem there.

SSL is overkill.  A public key / private key encryption scheme (like PGP) would be fine.  No need for per-session key exchange and such which really does add latency.  And PGPish encryption would have the significant benefit of ensuring the page is actually written by who it says it is (assuming the normal constraints that public key is from a trusted server and the private key is private of course).

Anyway, I have thought about this quite a bit since the early days of the web, and never found a real reason "why not"... especially now that the decryption is basically nothing compared with the power of the average computer (in the olden days, it would have actually slowed things down).</description>
		<content:encoded><![CDATA[<p>Um, just a quibble, but encryption doesn&#8217;t necisarially mean larger in size.  One big benefit of having encrypted html would be that the same mechanism could easily compress / decompress the page at the same time.</p>
<p>Slowness wise, it shouldn&#8217;t make any sort of difference unless you have a very very slow (processor wise) machine.  On the server side, you can just pregen and/or cache the encrypted pages, so no problem there.</p>
<p>SSL is overkill.  A public key / private key encryption scheme (like PGP) would be fine.  No need for per-session key exchange and such which really does add latency.  And PGPish encryption would have the significant benefit of ensuring the page is actually written by who it says it is (assuming the normal constraints that public key is from a trusted server and the private key is private of course).</p>
<p>Anyway, I have thought about this quite a bit since the early days of the web, and never found a real reason &#8220;why not&#8221;&#8230; especially now that the decryption is basically nothing compared with the power of the average computer (in the olden days, it would have actually slowed things down).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phi</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28921</link>
		<dc:creator>Phi</dc:creator>
		<pubDate>Tue, 26 Jun 2007 22:53:08 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28921</guid>
		<description>It was the red dotted line in that diagram that I was assuming was the weak spot.  Is it reasonable to assume that all sorts of random individuals are going to install Tor servers on their computers and then route all their traffic through that?

All that said, it does appear that Tor does provide a reasonable option for people that both care about the issues and are comfortable with a technical solution that will obviously take at least some care and feeding.</description>
		<content:encoded><![CDATA[<p>It was the red dotted line in that diagram that I was assuming was the weak spot.  Is it reasonable to assume that all sorts of random individuals are going to install Tor servers on their computers and then route all their traffic through that?</p>
<p>All that said, it does appear that Tor does provide a reasonable option for people that both care about the issues and are comfortable with a technical solution that will obviously take at least some care and feeding.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: grendelkhan</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28915</link>
		<dc:creator>grendelkhan</dc:creator>
		<pubDate>Tue, 26 Jun 2007 21:24:37 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28915</guid>
		<description>The tor server generally runs on your own machine. The unencrypted communications take place (a) between your browser and your tor instance, running on the same machine, and (b) between the tor endpoint, which is somewhere random on the internet, and the site which you connect to. &lt;a href="http://tor.eff.org/overview.html.en" rel="nofollow"&gt;There's a good diagram here&lt;/a&gt;.

It's clearly not a fix for the problem as a whole, but it &lt;i&gt;is&lt;/i&gt; something end users can do to protect themselves from their ISPs.</description>
		<content:encoded><![CDATA[<p>The tor server generally runs on your own machine. The unencrypted communications take place (a) between your browser and your tor instance, running on the same machine, and (b) between the tor endpoint, which is somewhere random on the internet, and the site which you connect to. <a href="http://tor.eff.org/overview.html.en" rel="nofollow">There&#8217;s a good diagram here</a>.</p>
<p>It&#8217;s clearly not a fix for the problem as a whole, but it <i>is</i> something end users can do to protect themselves from their ISPs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phi</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28914</link>
		<dc:creator>Phi</dc:creator>
		<pubDate>Tue, 26 Jun 2007 21:07:35 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28914</guid>
		<description>I'm not up on the details of &lt;a href="http://tor.eff.org/" rel="nofollow"&gt;Tor&lt;/a&gt;, but I guess I'm not clear on how this would solve the problem for most users.  If you're not running a Tor server, then wouldn't that last hop (which would presumably be visible to your ISP) not be encrypted?  If that's correct, then Tor would protect you from everyone along the route &lt;em&gt;except&lt;/em&gt; the people at the end (including your ISP).

We can presumably work around this by having everyone set up a Tor server, but that's clearly not going to be an option for most users for a whole variety of reasons.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not up on the details of <a href="http://tor.eff.org/" rel="nofollow">Tor</a>, but I guess I&#8217;m not clear on how this would solve the problem for most users.  If you&#8217;re not running a Tor server, then wouldn&#8217;t that last hop (which would presumably be visible to your ISP) not be encrypted?  If that&#8217;s correct, then Tor would protect you from everyone along the route <em>except</em> the people at the end (including your ISP).</p>
<p>We can presumably work around this by having everyone set up a Tor server, but that&#8217;s clearly not going to be an option for most users for a whole variety of reasons.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: grendelkhan</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28909</link>
		<dc:creator>grendelkhan</dc:creator>
		<pubDate>Tue, 26 Jun 2007 19:31:27 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28909</guid>
		<description>There's always tor. If the problem is the ISP on your end, that'll fix the problem, as they'll only see an encrypted stream of mishmosh flowing into your browser. (Of course, actually logging into anything is problematic.) If it's the ISP on their end, well, the site administrator will definitely know about it.</description>
		<content:encoded><![CDATA[<p>There&#8217;s always tor. If the problem is the ISP on your end, that&#8217;ll fix the problem, as they&#8217;ll only see an encrypted stream of mishmosh flowing into your browser. (Of course, actually logging into anything is problematic.) If it&#8217;s the ISP on their end, well, the site administrator will definitely know about it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phi</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28906</link>
		<dc:creator>Phi</dc:creator>
		<pubDate>Tue, 26 Jun 2007 19:07:18 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28906</guid>
		<description>Qalmlea:  I'm aware of such plugins, but have never bothered installing them.  Part of this is raw laziness (which I possess in abundance), but part of it is a weird inclination to see pages for what they are, both good and bad.  That little lump of coal banner ad on ScienceBlogs.com is &lt;em&gt;remarkaby&lt;/em&gt; annoying, but at some level I'm glad I see it because it informs my broader vision of ScienceBlogs.

Barry:  You're right about the times, especially the whole negotiation phase at the beginning.  And I hadn't even thought about the issues of encrypting images, and pages with content from multiple sites.  Ugh.  It definitely would be better if we can simply thwack the stupid ISPs into behaving than end up with great oceans of SSL just because of a few bad apples.  I'd be a little anxious for people who don't have (or don't realize that they have) ISP options.  The set of those without options is probably shrinking daily, but the set of people who aren't aware of their options is probably large, and the kind of people who'd use this sort of software are probably above a little FUD to keep the less confident/knowledgeable users in line.

CoryQ:  Agreed.  It really scks that the whole intarweb has been a brilliantly frustrating series of case studies in the tragedy of the commons.</description>
		<content:encoded><![CDATA[<p>Qalmlea:  I&#8217;m aware of such plugins, but have never bothered installing them.  Part of this is raw laziness (which I possess in abundance), but part of it is a weird inclination to see pages for what they are, both good and bad.  That little lump of coal banner ad on ScienceBlogs.com is <em>remarkaby</em> annoying, but at some level I&#8217;m glad I see it because it informs my broader vision of ScienceBlogs.</p>
<p>Barry:  You&#8217;re right about the times, especially the whole negotiation phase at the beginning.  And I hadn&#8217;t even thought about the issues of encrypting images, and pages with content from multiple sites.  Ugh.  It definitely would be better if we can simply thwack the stupid ISPs into behaving than end up with great oceans of SSL just because of a few bad apples.  I&#8217;d be a little anxious for people who don&#8217;t have (or don&#8217;t realize that they have) ISP options.  The set of those without options is probably shrinking daily, but the set of people who aren&#8217;t aware of their options is probably large, and the kind of people who&#8217;d use this sort of software are probably above a little FUD to keep the less confident/knowledgeable users in line.</p>
<p>CoryQ:  Agreed.  It really scks that the whole intarweb has been a brilliantly frustrating series of case studies in the tragedy of the commons.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: CoryQ</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28895</link>
		<dc:creator>CoryQ</dc:creator>
		<pubDate>Tue, 26 Jun 2007 15:52:26 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28895</guid>
		<description>I am contiually frightened by the human capacity to ruin things for others.  Thanks for bringing this interesting thing to my attention.</description>
		<content:encoded><![CDATA[<p>I am contiually frightened by the human capacity to ruin things for others.  Thanks for bringing this interesting thing to my attention.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barry Leiba</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28856</link>
		<dc:creator>Barry Leiba</dc:creator>
		<pubDate>Tue, 26 Jun 2007 03:20:43 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28856</guid>
		<description>Using SSL is a generally good idea &#8212; but it'll slow things down more than the "tiny fraction of a second" that the larger payload takes.  The bulk of the overhead of using encrypted pages is the SSL negotiation that happens when the HTTPS session starts, and that's significant.  It also means that all content on the page (all the images that are loaded) have to use SSL also, or else the browser will give a popup warning about mixed secure and non-secure content.  If some of the images come from multiple sites, the SSL negotiation has to be performed with each site, slowing it down more.

So it's a good idea, but I'd hate to have to use it.  Better to shun the ISPs that do things like this.  And there'll definitely be a market for ones that don't, because those that do will be hurting their own customers with it.</description>
		<content:encoded><![CDATA[<p>Using SSL is a generally good idea &mdash; but it&#8217;ll slow things down more than the &#8220;tiny fraction of a second&#8221; that the larger payload takes.  The bulk of the overhead of using encrypted pages is the SSL negotiation that happens when the HTTPS session starts, and that&#8217;s significant.  It also means that all content on the page (all the images that are loaded) have to use SSL also, or else the browser will give a popup warning about mixed secure and non-secure content.  If some of the images come from multiple sites, the SSL negotiation has to be performed with each site, slowing it down more.</p>
<p>So it&#8217;s a good idea, but I&#8217;d hate to have to use it.  Better to shun the ISPs that do things like this.  And there&#8217;ll definitely be a market for ones that don&#8217;t, because those that do will be hurting their own customers with it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Qalmlea</title>
		<link>http://UnhinderedByTalent.com/Phi/archives/2007/06/25/and-maybe-librarians-can-start-pasting-ads-in-books/#comment-28851</link>
		<dc:creator>Qalmlea</dc:creator>
		<pubDate>Tue, 26 Jun 2007 02:38:07 +0000</pubDate>
		<guid isPermaLink="false">http://UnhinderedByTalent.com/Phi/?p=591#comment-28851</guid>
		<description>If you use Mozilla, there are wonderful add-ons like ad-block and flash blocker.  I don't actually see any ads on Science blogs.  The most I see are the little "f"s telling me that there's flash content, if I wish to look at it.  I don't know how well (or if) adblocker would work against this latest...debacle.</description>
		<content:encoded><![CDATA[<p>If you use Mozilla, there are wonderful add-ons like ad-block and flash blocker.  I don&#8217;t actually see any ads on Science blogs.  The most I see are the little &#8220;f&#8221;s telling me that there&#8217;s flash content, if I wish to look at it.  I don&#8217;t know how well (or if) adblocker would work against this latest&#8230;debacle.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
