Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
Hi!
On Tue, Sep 13, 2011 at 10:34:33PM +0200, Aristotle Pagaltzis wrote:
The only Google product I ever use if I can help it is their web
search, and then only because all of the competitors are next to
worthless in comparison. I wish someone were able to step up to
Google on that front.
http://duckduckgo.com/ seems quite nice. And it's written in Perl :-)
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Lyle webmas...@cosmicperl.com [2011-09-13 02:05]: I wasn't going to reply to this, but as this thread has continued... I thought Arthur's point was so relevant and clear to the greater context of this (as he has continued to outline), that such as comment as Aristotle's could only be inspired by some kind of affinity felt towards Google. Maybe it's just because I work with a guy that gets his back up when you knock Google, that I read this as similar behaviour The only Google product I ever use if I can help it is their web search, and then only because all of the competitors are next to worthless in comparison. I wish someone were able to step up to Google on that front. I don’t even like how many people I correspond with with use GMail (though if you’re going to use webmail, there really is no other competent MUA – again the same problem as above), and my Google+ profile (which I only made after a dozen people added me using my email address and the milk was already spilt – thanks, guys) only says “If you haven’t added me then please don’t”. So much for your theory, then. I’ll still rather use encrypted.google.com than www.google.com. (On a distantly related note, my feelings about Apple run along very similar lines. I admire their products and wish I could use them but I refuse to be beholden to the company. So I can merely forlornly pine for a worthy competitor, though the outlook on that front is equally bleak as in Google’s case. Sigh. (Wasn’t the unfettered free market supposed to automagically be able to solve problems of this type? – Though now I’m stepping too far afield.[^1])) [^1]: On that note, though, if you who are reading this *do* love those companies, then please consider this line of argument on how you can best help make such companies better: http://robert.ocallahan.org/2006/02/choosing-sides_27.html http://lists.canonical.org/pipermail/kragen-tol/2011-August/000938.html Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On 13/09/2011 21:34, Aristotle Pagaltzis wrote: * Lylewebmas...@cosmicperl.com [2011-09-13 02:05]: I wasn't going to reply to this, but as this thread has continued... I thought Arthur's point was so relevant and clear to the greater context of this (as he has continued to outline), that such as comment as Aristotle's could only be inspired by some kind of affinity felt towards Google. Maybe it's just because I work with a guy that gets his back up when you knock Google, that I read this as similar behaviour The only Google product I ever use if I can help it is their web search, and then only because all of the competitors are next to worthless in comparison. I wish someone were able to step up to Google on that front. Well after searching for sheds on GumTree google felt it was justified to bombard with with AdSense shed adverts. I discovered that a LOT of sites have AdSense these days. I can't remember agreeing to them doing that. I'm tempted to go into a rant about adwords and adsense but it's well off topic so I won't. Fact is though, the way it works is corrupt. I hate to say it, by Bing search actually gives rather good results these days. People don't use it because it's M$, not because of results. My M$ hate has faded a little, and started to be replaced by a some sympathy. I fear in Google we may have inadvertently created an even bigger monster. Not that my homepage is bing, it's still google. But if I use someone else's computer, or a different broswer, and bing comes up - I just use it. I don't feel the need to change to google any more. Lyle I apologise for the OT
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On 28/08/2011 20:03, sawyer x wrote: On Sun, Aug 28, 2011 at 9:41 PM, Lyle webmas...@cosmicperl.com mailto:webmas...@cosmicperl.com wrote: On 28/08/2011 19:30, Aristotle Pagaltzis wrote: * Arthur Corlisscorl...@digitalmages.com mailto:corl...@digitalmages.com [2011-08-28 19:55]: With friends like Google protecting your information, who needs encryption? ;-) --Arthur Corliss Live Free or Die Right, so just let everyone in any coffee shop or any other open network you connect to sniff all your traffic. Did you have an actual point? I always find it amusing when comments against google seem to get at people. After all, Google is just another Microsoft :P You clearly misunderstood Aristotle. He doesn't care about a comment against Google, and I'm sure he has no special affinity towards it. He simply had a good remark on a discussion of the effectiveness and CPU costs of SSL encryption and it was ignored with a completely irrelevant comment. I wasn't going to reply to this, but as this thread has continued... I thought Arthur's point was so relevant and clear to the greater context of this (as he has continued to outline), that such as comment as Aristotle's could only be inspired by some kind of affinity felt towards Google. Maybe it's just because I work with a guy that gets his back up when you knock Google, that I read this as similar behaviour Lyle
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, 9 Sep 2011, Aristotle Pagaltzis wrote: Protecting your communication with another party from third parties needs no justification whatever. It should be the assumed default that exceptions are made from, not the exception from the rule requiring proof. If I?m having a massive argument with my personal foe #1, the fact that I distrust this person on all conceivable levels does not make you welcome to eavesdrop on the conversation. It does not matter the very least bit how trustworthy the other party is: uninvited third parties have no business knowing what you do or do not say to the other party. This is about assessment of risk, and in the example of Google that's exactly what you're missing. I would agree with you if your traffic was going to a trusted party, i.e., a server under the control of entities you know and trust. But it's not. So who's the greater danger to you? The megalith cataloging and profiling all of your communications across multiple networks and devices, or the script kiddie at the next table? It should be obvious who has the greater ability to harm you. And that's what makes so much of this thread ridiculous. Some here are excessively paranoid about the most peripheral and fleeting contacts, yet don't care about the data mining operation that you're securely funneling all your information to. If that's what makes you paranoid, then I'd have to say you're not paranoid enough, not by a long shot. That?s the ?I have nothing to hide? argument. No, read above. It's the assessment of risk argument. And one that's pertinent on many, many levels. As has been pointed out by several parties on this list, SSL-everywhere is not a zero-cost proposition, so if you're going to go to that length there should be tangible benefit. It does not matter how embarrassing it is or isn?t. Irrelevant. It?s much simpler: unless they want you to know (or it affects you directly in some undue manner etc. ? insert reasonable qualifiers here), you have no business knowing. How yawn-worthy that information is makes no criterion. The one criterion that does apply is whether making the channel secure against you trying to find out is too expensive relative to its sensitivity. So far, MetaCPAN seems to be less than straining under the load, so I don?t see a justification to reconsider. We used to avoid SSL unless necessary because it was expensive. I agree with the engineers who are saying that it?s time to re-examine that as a default assumption ? whether they are employed by Google or not makes no difference to me as far as that statement is concerned. Someone else pointed out that SSL is not trivial or low cost to many embedded devices. That's true. I pointed out that it makes traffic shaping and caching strategies to relieve backbone congestion extremely more complicated. It may be cheap for servers to terminate those connections with the power inherent in the average modern server, but that's just technical narcissism. It gives no thought to the rest of us at all. You won?t see me disagreeing that the concentration of power in Google?s hands is dangerous. But that?s a different matter, even though very important in its own right. Abolishing Google would not reduce the justification to secure communications. The two issues are independent ? so the question you pose is entirely beside the point to the matter at hand. I have no wish to abolish Google, and this isn't just a Google problem, it's a social media problem, a search engine problem, it's a problem of trust with any third party that you lack contractual safeguards or control over. That said, I still think we should have an actual *benefit* before we slab a dollop of SSL on everything. I'm not opposed to metacpan having an SSL interface, but why on earth would you place barriers to use on a public resource, containing public information?! That's the operators of metacpan forcing their peculiar dogmatism and fanaticism on the rest of us. Which I don't actually have a problem with as long as they're not the *default* or *only* repositories of that information. But if they aim to become such they need to be bent on maximum accessibility. That's just common sense. Explain to me why giving people a choice of interfaces is a bad thing. SSL gives them a hard-on. Great. I share their preferences, but I don't share the inclination to force it on the rest of the world. Taken to that extreme would have us SSL'ify content distribution networks. And is that friendly to the network operators carrying that traffic? Is that what we really want to do? Might as well, I guess, since even that traffic has *some* intel value. But I would argue that the cost incurred for very little real benefit should be considered. --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Sep 09, 2011 at 04:57:55PM +0200, Aristotle Pagaltzis wrote: * Arthur Corliss corl...@digitalmages.com [2011-08-28 21:40]: My humor was perhaps too subtle, since you didn't get the relevance of my reply. Google switching to SSL by default is as pointless as metacpan. In the former case it's the protection of delivery to/from an entity that not only doesn't have your best interest at heart, but has a business built on exploiting *your* information for *its* benefit. Utterly pointless. Protecting your communication with another party from third parties needs no justification whatever. It should be the assumed default that exceptions are made from, not the exception from the rule requiring proof. If I’m having a massive argument with my personal foe #1, the fact that I distrust this person on all conceivable levels does not make you welcome to eavesdrop on the conversation. It does not matter the very least bit how trustworthy the other party is: uninvited third parties have no business knowing what you do or do not say to the other party. [snip the rest of an e-mail with more excellent arguments] I also wonder why is it that nobody has so far brought up another important consequence of using SSL, at least with a trusted certificate at the other end - protection from not just eavesdropping, but also man-in-the-middle attacks. Yes, it seems kind of... weird... to think of MITM attacks against MetaCPAN, but with just a little bit of further thinking, it's not all *that* weird - and now you've all started me wondering how difficult it would be to catch an HTTP file transfer of a previously unknown Perl module out of the air, hijack it, unpack the tarball, add a couple of lines to Build.PL (or Makefile.PL or whatever), repack it and pass it on down the line :) No, of course I'm not going to seriously sit down and write code doing that. Still... I really wonder why no one brought MITM attacks up yet :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence every third, but it still comprehensible. signature.asc Description: Digital signature
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Peter Pentchev r...@ringlet.net [2011-09-11 02:50]: I also wonder why is it that nobody has so far brought up another important consequence of using SSL, at least with a trusted certificate at the other end - protection from not just eavesdropping, but also man-in-the-middle attacks. Yes, it seems kind of... weird... to think of MITM attacks against MetaCPAN, but with just a little bit of further thinking, it's not all *that* weird - and now you've all started me wondering how difficult it would be to catch an HTTP file transfer of a previously unknown Perl module out of the air, hijack it, unpack the tarball, add a couple of lines to Build.PL (or Makefile.PL or whatever), repack it and pass it on down the line :) No, of course I'm not going to seriously sit down and write code doing that. Still... I really wonder why no one brought MITM attacks up yet :) I think in this particular scenario you mentioned, SSL is the wrong layer at which to solve the problem. CPAN clients download from the CPAN mirror network, in general. Some sort of code signing should be baked into them (in fact there is, but it has a number of problems in its current form that I don’t remember off hand, so that nobody is using it in anger). But more generally your point is a good one. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Arthur Corliss corl...@digitalmages.com [2011-08-28 21:40]: My humor was perhaps too subtle, since you didn't get the relevance of my reply. Google switching to SSL by default is as pointless as metacpan. In the former case it's the protection of delivery to/from an entity that not only doesn't have your best interest at heart, but has a business built on exploiting *your* information for *its* benefit. Utterly pointless. Protecting your communication with another party from third parties needs no justification whatever. It should be the assumed default that exceptions are made from, not the exception from the rule requiring proof. If I’m having a massive argument with my personal foe #1, the fact that I distrust this person on all conceivable levels does not make you welcome to eavesdrop on the conversation. It does not matter the very least bit how trustworthy the other party is: uninvited third parties have no business knowing what you do or do not say to the other party. In the latter case you have a search engine whose use is basically the retrieval of information based on *published* open source software, and highly published at that, given the world-wide replication of CPAN itself. What exactly is metacpan protecting? Is it that embarrasing that programmer Joe can't remember what module function foo was defined in? Can someone really derive significant benefit from witnessing Harry browse the API for WWW:Retrieval::LOLCats or what have you? That’s the “I have nothing to hide” argument. It does not matter how embarrassing it is or isn’t. Irrelevant. It’s much simpler: unless they want you to know (or it affects you directly in some undue manner etc. – insert reasonable qualifiers here), you have no business knowing. How yawn-worthy that information is makes no criterion. The one criterion that does apply is whether making the channel secure against you trying to find out is too expensive relative to its sensitivity. So far, MetaCPAN seems to be less than straining under the load, so I don’t see a justification to reconsider. We used to avoid SSL unless necessary because it was expensive. I agree with the engineers who are saying that it’s time to re-examine that as a default assumption – whether they are employed by Google or not makes no difference to me as far as that statement is concerned. So, regardless of the incremental costs of implementing SSL, *why* is the mandatory use of SSL even considered intelligent, rational, or any other way beneficial? I wasn't going to get involved in this thread, but the Google bait was too spot on to ignore. You won’t see me disagreeing that the concentration of power in Google’s hands is dangerous. But that’s a different matter, even though very important in its own right. Abolishing Google would not reduce the justification to secure communications. The two issues are independent – so the question you pose is entirely beside the point to the matter at hand. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Tue, Aug 30, 2011 at 12:47 AM, Arthur Corliss corl...@digitalmages.comwrote: I think you're still missing my point and focusing on defending a company you obviously like. All you had to do was originally write as much as I understand people's desire for encryption, I still believe that 1. SSL is only necessary in specific websites (example A, example B) and 2. when working with Google we shouldn't be worrying about encryption there, but rather Google itself. Instead you opted to butt heads with someone, belittling their whole SSL doesn't have large overhead remark with who cares? Google! You could have made an eloquent respectful comment, saying that while SSL apparently doesn't cost much, Google is really what bothers you and that you'd rather have a discussion about that. I don't think anyone (including myself) would have anything bad to say about it, and you would have been most likely successful at raising that point of issue. I've personally moved to DuckDuckGo and considering replacing Gmail. Unfortunately, I've most likely committed the same belittling, whether it was towards you, Shlomi, David, or anyone else here. So, my apologies for this and I will be clearing my desk of this thread. Apologies, and warm wishes to all, s.
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Tue, 30 Aug 2011, sawyer x wrote: All you had to do was originally write as much as I understand people's desire for encryption, I still believe that 1. SSL is only necessary in specific websites (example A, example B) and 2. when working with Google we shouldn't be worrying about encryption there, but rather Google itself. Instead you opted to butt heads with someone, belittling their whole SSL doesn't have large overhead remark with who cares? Google! You could have made an eloquent respectful comment, saying that while SSL apparently doesn't cost much, Google is really what bothers you and that you'd rather have a discussion about that. I don't think anyone (including myself) would have anything bad to say about it, and you would have been most likely successful at raising that point of issue. I've personally moved to DuckDuckGo and considering replacing Gmail. G I guess the little winky smiley face on my original post was lost on you, eh? I shall have to be far less subtle in the future, but for now I'll let my e-mails stand on their own. And I won't point out how I specifically requested that a Google-centric conversation should be held off-list... Oops. ;-) Unfortunately, I've most likely committed the same belittling, whether it was towards you, Shlomi, David, or anyone else here. So, my apologies for this and I will be clearing my desk of this thread. I thought that the whole thread was silly, as is the concept that metacpan would to dictate SSL-only for questionable gains. And I think my interjection was pretty fair, inoffensive, and good natured. But, maybe quietly lurking exposes my better side. :-) --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, Aug 28, 2011 at 12:33:54PM -0700, Eric Wilhelm wrote: I didn't think it was a question of CPU speed anytime in the past decade. It is on small mobile clients, and the notwork latency it adds is also noticeable. And on the server side, when you're running on old donated equipment, or cheap donated equipment, or a cloud thing that charges per CPU cycle, then pointless use of SSL is kinda silly. Even sillier than pointless use of SSL when none of the above applies. Sure, use SSL for authentication like what my bank does. Use it for your webmail when using chavternet in a crappy cafe which doesn't even serve delicious cake. But don't just use it all the time, and especially don't create a service that *only* uses it, unless you *have* to use it. -- David Cantrell | http://www.cantrell.org.uk/david Hail Caesar! Those about to vi ^[ you!
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, Aug 28, 2011 at 2:38 PM, Arthur Corliss corl...@digitalmages.com wrote: Google switching to SSL by default is as pointless as metacpan. In the former case it's the protection of delivery to/from an entity that not only doesn't have your best interest at heart, but has a business built on exploiting *your* information for *its* benefit. Utterly pointless. I'll take this bait, swallow it, and hopefully bite off the line: Yes, Google is going to use query data for its gain. But, Google's business model also involves *aggregation* and *respecting individual privacy*. The SSL to Google Search is supposed to protect one from eavesdropping, as has been pointed out, by the other people in Starbucks. And it does this. Say you're sitting in Starbucks, searching for clues concerning an embarrassing medical condition. Your risk is, Mallory will intercept your packets and tell his buddies and they will huddle and point. If some Google tech sees your query among the millions of other queries and points it out to /his/ buddies and they huddle and point, that doesn't affect you the same way, if at all. They won't be pointing at you, the victim of an embarrassing medical condition, they will be merely pointing at an evidence of your existence. And such attention might actually bring more attention, in general, to the problem of severe triskaidekaphobia or whatever, which would be a good thing for you -- in the aggregate. The resulting open discussion of severe triskaidekaphobia might help lift the crippling stigma that has followed the victims for so long, without any unpleasant direct confrontations.
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Mon, 29 Aug 2011, David Nicol wrote: I'll take this bait, swallow it, and hopefully bite off the line: Yes, Google is going to use query data for its gain. But, Google's business model also involves *aggregation* and *respecting individual privacy*. The SSL to Google Search is supposed to protect one from eavesdropping, as has been pointed out, by the other people in Starbucks. And it does this. Say you're sitting in Starbucks, searching for clues concerning an embarrassing medical condition. Your risk is, Mallory will intercept your packets and tell his buddies and they will huddle and point. If some Google tech sees your query among the millions of other queries and points it out to /his/ buddies and they huddle and point, that doesn't affect you the same way, if at all. They won't be pointing at you, the victim of an embarrassing medical condition, they will be merely pointing at an evidence of your existence. And such attention might actually bring more attention, in general, to the problem of severe triskaidekaphobia or whatever, which would be a good thing for you -- in the aggregate. The resulting open discussion of severe triskaidekaphobia might help lift the crippling stigma that has followed the victims for so long, without any unpleasant direct confrontations. I think you're still missing my point and focusing on defending a company you obviously like. Contact me off the list if you want to discuss/debate the actual dangers that companies like Google present. Otherwise, let's focus on the crux of my argument: trusting any third party with your personal information whose primary business is selling the use of your information is foolish, and the use of SSL as your conduit to them should not make you feel safer. That company is liable to be a greater danger to your privacy than random wifi eavesdroppers. Likewise, the use of SSL to conceal your access of highly public (and specialized) information on metacpan also provides no tangible benefit for 90% of the users. They should offer SSL as an option, but not mandate it for those of us who derive no benefit from it. Again: a resource like metacpan should aim for maximum accessibility... --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Shlomi Fish shlo...@shlomifish.org [2011-07-29 13:25]: One reason I have not converted wholesale to metacpan is because it redirects all http:// requests to https:// . Very annoying. http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy *no additional machines* and *no special hardware*. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: *SSL/TLS is not computationally expensive any more*. […] Also, don't forget that we recently deployed encrypted web search on https://encrypted.google.com. Switch your search engine!
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, Aristotle Pagaltzis wrote: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy *no additional machines* and *no special hardware*. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: *SSL/TLS is not computationally expensive any more*. [?] Also, don't forget that we recently deployed encrypted web search on https://encrypted.google.com. Switch your search engine! These comments are pretty funny once you consider that you're making a secure connection to an independent party who has a commercial and fiduciary responsibility to exploit every bit of data you give them. With friends like Google protecting your information, who needs encryption? ;-) --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Arthur Corliss corl...@digitalmages.com [2011-08-28 19:55]: On Sun, 28 Aug 2011, Aristotle Pagaltzis wrote: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy *no additional machines* and *no special hardware*. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: *SSL/TLS is not computationally expensive any more*. […] Also, don't forget that we recently deployed encrypted web search on https://encrypted.google.com. Switch your search engine! These comments are pretty funny once you consider that you're making a secure connection to an independent party who has a commercial and fiduciary responsibility to exploit every bit of data you give them. With friends like Google protecting your information, who needs encryption? ;-) --Arthur Corliss Live Free or Die Right, so just let everyone in any coffee shop or any other open network you connect to sniff all your traffic. Did you have an actual point? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, Aug 28, 2011 at 9:41 PM, Lyle webmas...@cosmicperl.com wrote: On 28/08/2011 19:30, Aristotle Pagaltzis wrote: * Arthur Corlisscorliss@digitalmages.**com corl...@digitalmages.com [2011-08-28 19:55]: With friends like Google protecting your information, who needs encryption? ;-) --Arthur Corliss Live Free or Die Right, so just let everyone in any coffee shop or any other open network you connect to sniff all your traffic. Did you have an actual point? I always find it amusing when comments against google seem to get at people. After all, Google is just another Microsoft :P You clearly misunderstood Aristotle. He doesn't care about a comment against Google, and I'm sure he has no special affinity towards it. He simply had a good remark on a discussion of the effectiveness and CPU costs of SSL encryption and it was ignored with a completely irrelevant comment. Google might be another Microsoft, it might be worse, but it is *irrelevant* to the question of SSL security and the costs of enabling it by default. Aristotle, for what it's worth, I've learned that people always want to have their say, even if in an inappropriate time. Such as the politician, who when asked what do you think about the current financial crisis? will answer: I think the weather is excellent, and golf sounds like a wonderful idea! :)
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, Aristotle Pagaltzis wrote: Right, so just let everyone in any coffee shop or any other open network you connect to sniff all your traffic. Did you have an actual point? Yep, but it appears you completely missed it. I use encryption all the time, but outside of authentication its merit is questionable when it concerns information that is a) public information (especially in the context of published open source) and b) information going to an untrustable third party like Google. Personally, I have no use for metacpan, and don't care what they do. But as a general operating principle, I like to use the appropriate tools where they're *appropriate*. I expect my bank's websites to be fully SSL, I expect my on-line brokerage's sites to be fully SSL. But what exactly is the risk with a search engine of a highly specialized and highly public information? I fail to see the benefit, and I tend towards paranoia naturally. OSS is about freedom choice. As long as users have a choice (an alternative to metacpan) feel free to force your preferences on the users. But in the unfortunate circumstance where metacpan becomes the only choice it'd be nice if the maintainers try to be a little less dogmatic about it. They should be inclined towards maximum accessibility, not maximum pedagoguery. I know I didn't get the memo but I think someone did claim that metacpan was the de facto interface these days... --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
# from sawyer x # on Sunday 28 August 2011 12:03: a discussion of the effectiveness and CPU costs of SSL encryption I didn't think it was a question of CPU speed anytime in the past decade. How does a proxy cache encrypted data? Atwood's Law of Computer Latency: Processor cycles, storage density, and network bandwidth are increasing, faster than the speed of light is getting faster. --Eric -- Insert random misquote here --- http://scratchcomputing.com ---
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, sawyer x wrote: You clearly misunderstood Aristotle. He doesn't care about a comment against Google, and I'm sure he has no special affinity towards it. He simply had a good remark on a discussion of the effectiveness and CPU costs of SSL encryption and it was ignored with a completely irrelevant comment. Google might be another Microsoft, it might be worse, but it is *irrelevant* to the question of SSL security and the costs of enabling it by default. My humor was perhaps too subtle, since you didn't get the relevance of my reply. Google switching to SSL by default is as pointless as metacpan. In the former case it's the protection of delivery to/from an entity that not only doesn't have your best interest at heart, but has a business built on exploiting *your* information for *its* benefit. Utterly pointless. In the latter case you have a search engine whose use is basically the retrieval of information based on *published* open source software, and highly published at that, given the world-wide replication of CPAN itself. What exactly is metacpan protecting? Is it that embarrasing that programmer Joe can't remember what module function foo was defined in? Can someone really derive significant benefit from witnessing Harry browse the API for WWW:Retrieval::LOLCats or what have you? So, regardless of the incremental costs of implementing SSL, *why* is the mandatory use of SSL even considered intelligent, rational, or any other way beneficial? I wasn't going to get involved in this thread, but the Google bait was too spot on to ignore. --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, Eric Wilhelm wrote: I didn't think it was a question of CPU speed anytime in the past decade. How does a proxy cache encrypted data? Bringing up proxies is an excellent point. While most proxies do support SSL tunnelling, this does make the request uncacheable since the proxy never knows anything about the connection outside of the host port it's tunnelling to. I run a proxy cluster myself, and I do force caching of search engine responses for a short window (typically on the order of a few hours), and it does tend to pay off, especially when notable events occur in the world. Obviously, SSL bypasses the cache altogether. And I can only get away with this because the businesses I support all want the same safe levels applied to all requests, so I don't have to worry about inappropriate content in some people's results. Which brings to mind yet another point: for those of us providing content filtering services via proxies SSL is a huge problem. The only good solution is to do transparent interception of SSL connections with your proxies serving up a private CA-signed certificate using wild cards, but that requires installing your private CA's root certificate on all clients, and even then there's clients that that still won't work on. Never mind that the concept of spoofing external organization certificates is insanely dangerous in its own right. --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, Arthur Corliss wrote: snip Which brings to mind yet another point: for those of us providing content filtering services via proxies SSL is a huge problem. The only good solution is to do transparent interception of SSL connections with your proxies serving up a private CA-signed certificate using wild cards, but that requires installing your private CA's root certificate on all clients, and even then there's clients that that still won't work on. Never mind that the concept of spoofing external organization certificates is insanely dangerous in its own right. I'm going to preemptively qualify this brain dump as relevant to the metacpan debate because I would consider metacpan's content, search results, etc., to be highly cacheable. Moreso than a general purpose engine like Google, metacpan's results would tend to be more applicable to multiple users' searches. And yet the whole SSL-only mindset would hamper an individual network operator's ability to control and shape its network. Hopefully no one misconstrues this as me being against SSL sites, I'm extremely in favor of them, particularly with organizations hosting my sensitive information. I only think metacpan should offer both HTTPS and HTTP interfaces. Let those ultra-paranoids among us use the HTTPS, and the rest of us HTTP. --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, 2011-07-29 at 12:58 +0300, Gabor Szabo wrote: In case you don't have time to follow the many blog post of the Perl community I think this is an item worth reading for you as a Module Author. Don't be left out from the new CPAN game! This Week in MetaCPAN by Olaf Alders http://blogs.perl.org/users/olaf_alders/2011/07/this-week-in-metacpan.html regards Gabor Well, it would be nice if the mail this sends, actually came from a real domain. I'm not going to change my mail server's policies to accept mail from unknown domains: Jul 30 23:32:42 lws postfix/smtpd[3948]: NOQUEUE: reject: RCPT from mxout-095-ewr.mailhop.org[216.146.33.95]: 450 4.1.8 hea...@kingst.sforeverxx.com: Sender address rejected: Domain not found; from=hea...@kingst.sforeverxx.com to=l...@lincolnbaxter.com proto=ESMTP helo=mail-33-ewr.dyndns.com
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
Hi Gabor, On Fri, 29 Jul 2011 12:58:52 +0300 Gabor Szabo szab...@gmail.com wrote: In case you don't have time to follow the many blog post of the Perl community I think this is an item worth reading for you as a Module Author. Don't be left out from the new CPAN game! One reason I have not converted wholesale to metacpan is because it redirects all http:// requests to https:// . Very annoying. Regards, Shlomi Fish This Week in MetaCPAN by Olaf Alders http://blogs.perl.org/users/olaf_alders/2011/07/this-week-in-metacpan.html regards Gabor -- - Shlomi Fish http://www.shlomifish.org/ Why I Love Perl - http://shlom.in/joy-of-perl Jewish Atheists are the only true Atheists. They beat the hell out of Goy Atheists. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 2:24 PM, Shlomi Fish shlo...@shlomifish.org wrote: Hi Gabor, On Fri, 29 Jul 2011 12:58:52 +0300 Gabor Szabo szab...@gmail.com wrote: In case you don't have time to follow the many blog post of the Perl community I think this is an item worth reading for you as a Module Author. Don't be left out from the new CPAN game! One reason I have not converted wholesale to metacpan is because it redirects all http:// requests to https:// . Very annoying. I'd say very correct! I like to work in HTTPS (and we should, really, in a secure world). Many websites already moved to it by default such as github.com, all google sites, workflowy.com, foursquare and more. Most of what we do online is private. Not I want to hide this because it's illegal private, but this is personal, so mind your own business private. The dangers of no privacy in the internet age are becoming more and more apparent and it's high time we realize it and exercise some personal discretion. I'm happy websites are now moving to it and I don't need to always rewrite http to https. It's time to get fucking modern. :) (and you can quote me on that!) S.
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On 11-07-29 07:58 AM, sawyer x wrote: Most of what we do online is private. Not I want to hide this because it's illegal private, but this is personal, so mind your own business private. How about? This is professional; I don't want my client's competetion knowing what I'm researching. -- Just my 0.0002 million dollars worth, Shawn Confusion is the first step of understanding. Programming is as much about organization and communication as it is about coding. The secret to great software: Fail early often. Eliminate software piracy: use only FLOSS. Make something worthwhile. -- The Dear Hunter
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 3:17 PM, Shawn H Corey shawnhco...@gmail.comwrote: On 11-07-29 07:58 AM, sawyer x wrote: Most of what we do online is private. Not I want to hide this because it's illegal private, but this is personal, so mind your own business private. How about? This is professional; I don't want my client's competetion knowing what I'm researching. Even better! I'll be sure to remember this example.
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 7:58 AM, sawyer x xsawy...@gmail.com wrote: I like to work in HTTPS (and we should, really, in a secure world). Many websites already moved to it by default such as github.com, all google sites, workflowy.com, foursquare and more. Those are all sites for which users log-in and keep lots of personal information. They are not reference sites. SSL prevents (or at least makes it difficult to do) proxy caching. Thus, every client needs to hit the origin server directly and idempotent requests (which is the vast majority of them) can't be served up by intermediate caching, which wastes server cycles and bandwidth. That is fundamentally bad design when the use case does not require protection of user information. The only time MetaCPAN should be forcing https is for author log-in and logged-in sessions. (I support offering it as an option, but it doesn't need to be the default). Most of what we do online is private. Not I want to hide this because it's illegal private, but this is personal, so mind your own business private. SSL does not hide the hostname (and port) you are connecting to; it will only hide the actual HTTP request and response. On the actual subject of whether MetaCPAN is becoming a defacto standard -- consider that search.cpan.org has a Google PageRank of 7. MetaCPAN has quite a ways to go before it will have that level of significance in search results. (Maybe if p3rl.org routed to MetaCPAN instead of search.cpan.org, that would help.) I think MetaCPAN is a great project and is evolving quickly, but hyperbole doesn't serve any real benefit. -- David
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 2:58 PM, sawyer x xsawy...@gmail.com wrote: On Fri, Jul 29, 2011 at 2:24 PM, Shlomi Fish shlo...@shlomifish.org wrote: Hi Gabor, On Fri, 29 Jul 2011 12:58:52 +0300 Gabor Szabo szab...@gmail.com wrote: In case you don't have time to follow the many blog post of the Perl community I think this is an item worth reading for you as a Module Author. Don't be left out from the new CPAN game! One reason I have not converted wholesale to metacpan is because it redirects all http:// requests to https:// . Very annoying. I'd say very correct! I think I used to[1] get alerts on metacpan that some of the content is coming via http while the main page is https. I wonder if this is not breaking the whole idea of privacy? Gabor [1] I don't get them any more as I turned them off.
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 4:17 PM, David Golden xda...@gmail.com wrote: On Fri, Jul 29, 2011 at 7:58 AM, sawyer x xsawy...@gmail.com wrote: I like to work in HTTPS (and we should, really, in a secure world). Many websites already moved to it by default such as github.com, all google sites, workflowy.com, foursquare and more. Those are all sites for which users log-in and keep lots of personal information. They are not reference sites. I think Google searches and MetaCPAN searches are equivalent in the way they both represent stuff you're looking to find. It's true that Google can contain personal stuff while MetaCPAN will likely contain professional (or rather code-related) stuff, but they both have a case for allowing the user to browse peacefully without worrying about who's looking over your shoulders (via proxies, log files), whether it be your boss or competitor. I also personally see a case for security by default. SSL prevents (or at least makes it difficult to do) proxy caching. Agreed. That is a setback indeed for SSL. However, this can be minimized by using sub-requests in reverse proxies, and netcaches. I'm not trying to have a discussion on the technical merits of SSL. My point is merely that I support a security by default paradigm. I understand you do not, or at least in some situations. That's cool. That is fundamentally bad design when the use case does not require protection of user information. I guess I have a much broader sense of when it is necessary to protect user information. I might just be too extreme on this. The only time MetaCPAN should be forcing https is for author log-in and logged-in sessions. This just seems obvious to me. Who would write an application that sends your credentials online in cleartext? (yes, I know, some might consider this to be theoretically acceptable in intranet, but I don't...) Most of what we do online is private. Not I want to hide this because it's illegal private, but this is personal, so mind your own business private. SSL does not hide the hostname (and port) you are connecting to; it will only hide the actual HTTP request and response. Oh, I know... I think MetaCPAN is a great project and is evolving quickly, but hyperbole doesn't serve any real benefit. Debatable, but I'll shut up now. :) (I just personally don't see it as hyperbole) Have a great weekend! S.
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 8:17 AM, David Golden wrote: I think MetaCPAN is a great project and is evolving quickly, but hyperbole doesn't serve any real benefit. didn't someone here used to have sure it's hyperbole, but you can never have too much hyperbole as their .sig?
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On 29.07.2011 13:58, sawyer x wrote: I like to work in HTTPS (and we should, really, in a secure world). Many websites already moved to it by default such as github.com http://github.com, all google sites, workflowy.com http://workflowy.com, foursquare and more. just out of curiosity, where exactly does google work in https? here in Austria, at least, all searching (web, maps, etc.) is done in plain http. and I *am* logged in, and automatically switched to https for google+, gmail, etc. cheers, Aldo
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 04:32:40PM +0200, Aldo Calpini wrote: just out of curiosity, where exactly does google work in https? https://encrypted.google.com/ -- David Cantrell | Bourgeois reactionary pig EINE KIRCHE! EIN KREDO! EIN PAPST!
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On 29.07.2011 17:39, David Cantrell wrote: https://encrypted.google.com/ ah, ok. but that's explicitly requesting for https, which is something different from eg. github, which really redirect http requests to https. I don't question that there's a trend here, and I don't particularly advocate using http over https. I was just wondering why my google was different from sawyer x's one :-) cheers, Aldo
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Fri, Jul 29, 2011 at 9:43 PM, Aldo Calpini d...@perl.it wrote: On 29.07.2011 17:39, David Cantrell wrote: https://encrypted.google.com/ ah, ok. but that's explicitly requesting for https, which is something different from eg. github, which really redirect http requests to https. Gmail redirects to https now for everyone, as far as I know. Though I can't be too sure since I configured it to https manually as soon as I could.
