FAQ
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

Search Discussions

  • Shlomi Fish at Jul 29, 2011 at 11:24 am
    Hi Gabor,

    On Fri, 29 Jul 2011 12:58:52 +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!
    One reason I have not converted wholesale to metacpan is because it redirects
    all http:// requests to https:// . Very annoying.

    Regards,

    Shlomi Fish


    --
    -----------------------------------------------------------------
    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 .
  • Sawyer x at Jul 29, 2011 at 11:58 am

    On Fri, Jul 29, 2011 at 2:24 PM, Shlomi Fish wrote:

    Hi Gabor,

    On Fri, 29 Jul 2011 12:58:52 +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!
    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.
  • David Morel at Jul 29, 2011 at 12:05 pm

    Le 29 juil. 2011 à 13:58, sawyer x a écrit :

    On Fri, Jul 29, 2011 at 2:24 PM, Shlomi Fish wrote:
    Hi Gabor,

    On Fri, 29 Jul 2011 12:58:52 +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!
    One reason I have not converted wholesale to metacpan is because it redirects
    all http:// requests to https:// . Very annoying.
    Annoying in what sense (I'm not as radical as SawyerX :)?
    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.
    David Morel
  • Shawn H Corey at Jul 29, 2011 at 12:17 pm

    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.00000002 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
  • Sawyer x at Jul 29, 2011 at 1:16 pm

    On Fri, Jul 29, 2011 at 3:17 PM, Shawn H Corey wrote:
    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.
  • David Golden at Jul 29, 2011 at 1:17 pm

    On Fri, Jul 29, 2011 at 7:58 AM, 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, 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
  • Sawyer x at Jul 29, 2011 at 1:40 pm

    On Fri, Jul 29, 2011 at 4:17 PM, David Golden wrote:
    On Fri, Jul 29, 2011 at 7:58 AM, 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, 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.
  • Eric Wilhelm at Aug 15, 2011 at 7:17 pm
    # from sawyer x
    # on Friday 29 July 2011 06:39:
    I also personally see a case for "security by default".
    OK, please set your client accordingly. It's bad design to force this
    at the server for all traffic.

    Of course, it looks like the reasoning is "encourage users to be logged
    in at all times" -- a flawed goal IMO.

    https://github.com/CPAN-API/metacpan-web/issues/157

    --Eric
    --
    "Everything goes wrong all at once."
    --Quantized Revision of Murphy's Law
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • David Nicol at Jul 29, 2011 at 2:18 pm

    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?
  • Gabor Szabo at Jul 29, 2011 at 1:19 pm

    On Fri, Jul 29, 2011 at 2:58 PM, sawyer x wrote:
    On Fri, Jul 29, 2011 at 2:24 PM, Shlomi Fish wrote:

    Hi Gabor,

    On Fri, 29 Jul 2011 12:58:52 +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!
    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.
  • Aldo Calpini at Jul 29, 2011 at 2:30 pm

    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
  • David Cantrell at Jul 29, 2011 at 3:39 pm

    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!
  • Aldo Calpini at Jul 29, 2011 at 6:41 pm

    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
  • Sawyer x at Jul 29, 2011 at 6:45 pm

    On Fri, Jul 29, 2011 at 9:43 PM, Aldo Calpini 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.
  • Aristotle Pagaltzis at Aug 28, 2011 at 12:38 pm

    * Shlomi Fish [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!
  • Arthur Corliss at Aug 28, 2011 at 5:54 pm

    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
  • Aristotle Pagaltzis at Aug 28, 2011 at 6:30 pm

    * Arthur Corliss [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/>
  • Lyle at Aug 28, 2011 at 6:41 pm

    On 28/08/2011 19:30, Aristotle Pagaltzis wrote:
    * Arthur Corliss[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


    Lyle
  • Sawyer x at Aug 28, 2011 at 7:04 pm

    On Sun, Aug 28, 2011 at 9:41 PM, Lyle wrote:
    On 28/08/2011 19:30, Aristotle Pagaltzis wrote:

    * Arthur Corliss<corliss@digitalmages.**com <corliss@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!" :)
  • Eric Wilhelm at Aug 28, 2011 at 7:34 pm
    # 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
    ---------------------------------------------------
  • Arthur Corliss at Aug 28, 2011 at 7:59 pm

    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
  • Arthur Corliss at Aug 28, 2011 at 8:12 pm
    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
  • David Cantrell at Aug 30, 2011 at 5:21 pm

    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!
  • Arthur Corliss at Aug 28, 2011 at 7:38 pm

    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
  • David Nicol at Aug 29, 2011 at 4:44 pm

    On Sun, Aug 28, 2011 at 2:38 PM, Arthur Corliss 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.
  • Arthur Corliss at Aug 29, 2011 at 9:47 pm

    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
  • Sawyer x at Aug 30, 2011 at 6:16 am

    On Tue, Aug 30, 2011 at 12:47 AM, Arthur Corliss wrote:

    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.
  • Arthur Corliss at Aug 30, 2011 at 2:50 pm

    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
  • Aristotle Pagaltzis at Sep 9, 2011 at 2:58 pm

    * Arthur Corliss [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/>
  • Arthur Corliss at Sep 9, 2011 at 5:52 pm

    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
  • Peter Pentchev at Sep 11, 2011 at 12:47 am

    On Fri, Sep 09, 2011 at 04:57:55PM +0200, Aristotle Pagaltzis wrote:
    * Arthur Corliss [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 roam@ringlet.net roam@FreeBSD.org peter@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.
  • Aristotle Pagaltzis at Sep 11, 2011 at 2:52 am

    * Peter Pentchev [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/>
  • Lyle at Sep 13, 2011 at 12:01 am

    On 28/08/2011 20:03, sawyer x wrote:
    On Sun, Aug 28, 2011 at 9:41 PM, Lyle wrote:

    On 28/08/2011 19:30, Aristotle Pagaltzis wrote:

    * Arthur Corliss[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
  • Aristotle Pagaltzis at Sep 13, 2011 at 8:34 pm

    * Lyle [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/>
  • Lyle at Sep 13, 2011 at 11:53 pm

    On 13/09/2011 21:34, Aristotle Pagaltzis wrote:
    * Lyle[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
  • Thomas Klausner at Sep 14, 2011 at 6:47 am
    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-:+-$"-g&&print$_.$/}
  • Arthur Corliss at Aug 28, 2011 at 7:16 pm

    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
  • Lincoln A Baxter at Jul 31, 2011 at 3:41 am

    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 <heaven@kingST.sforeverxx.com>: Sender address rejected: Domain not found; from=<heaven@kingST.sforeverxx.com> to=<lab@lincolnbaxter.com> proto=ESMTP helo=<mail-33-ewr.dyndns.com>

Related Discussions

People

Translate

site design / logo © 2021 Grokbase