Delivery-Date: Thu, 03 Jul 2014 17:42:18 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 4EF6B1E0C1B
	for <archiver@seul.org>; Thu,  3 Jul 2014 17:42:13 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 41E4D2B4FF;
	Thu,  3 Jul 2014 21:42:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id D18C42E88C
 for <tor-talk@lists.torproject.org>; Thu,  3 Jul 2014 21:27:18 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3T3D1rca3ChH for <tor-talk@lists.torproject.org>;
 Thu,  3 Jul 2014 21:27:18 +0000 (UTC)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com
 [IPv6:2607:f8b0:4001:c03::235])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id AE8572D15C
 for <tor-talk@lists.torproject.org>; Thu,  3 Jul 2014 21:27:18 +0000 (UTC)
Received: by mail-ie0-f181.google.com with SMTP id y20so865461ier.26
 for <tor-talk@lists.torproject.org>; Thu, 03 Jul 2014 14:27:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :content-type; bh=SbyhynQch9FGakkF8ky8q2gAmpYLs0qO26jzrUb6nSw=;
 b=yGBRQM4CohxTXEWCcBM0gNCd2Kema1lipaNoW7nJ6wjT8N3lYbONzMh/J507v4DjOS
 ZD0aInEf4Bbpr7yfEChfWyJraUaG6KRPYuv36kHMX3g9rkcqq8wHEeXm8yE7MP+BL8Sn
 K5b8Ufusi6kxaRV6SRJLAMR/zXYihB8kJ+8XCp4dLu1ShgwS0GI/2q8mg3OtWXGwy2M+
 NB6dp8tVtk6HXjSxix3u4zos2dLP4pG2KDbgmIh2md9x04HoOS5Xkdqy1BvcOzcUAHsF
 Wr3akdlnrvk0XhQ6wJTFSeNYTsI2NgqSW+UILQDWnlHbvXjmsNZwr5cpdp3dglzwyXPu
 YYew==
MIME-Version: 1.0
X-Received: by 10.50.117.2 with SMTP id ka2mr14600031igb.33.1404422836413;
 Thu, 03 Jul 2014 14:27:16 -0700 (PDT)
Received: by 10.64.30.194 with HTTP; Thu, 3 Jul 2014 14:27:16 -0700 (PDT)
In-Reply-To: <CAP-DOiQGg7C8soyDGTe9R7E85mB8Soxhr4VuaAOifXtp5cdwVg@mail.gmail.com>
References: <CAP-DOiTPMHavRep1c6mEjM8ykoeMXjYq-ddyD3ewSyLywS4aYQ@mail.gmail.com>
 <53b4d10c.32658c0a.3341.783eSMTPIN_ADDED_BROKEN@mx.google.com>
 <CAP-DOiQGg7C8soyDGTe9R7E85mB8Soxhr4VuaAOifXtp5cdwVg@mail.gmail.com>
Date: Thu, 3 Jul 2014 21:27:16 +0000
Message-ID: <CAP-DOiTPssFAZU3zOPZ35=bMUvmRz_+zA9XA+MyOowBdh44K8Q@mail.gmail.com>
From: ideas buenas <ideasbuenas@gmail.com>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] (no subject)
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Another example is this   s3-website-eu-west-1.amazonaws.com    OR
edge-star-shv-08-gru1.facebook.com  OR
ec2-54-225-215-244.compute-1.amazonaws.com   everyone resolving to
markmonitor.com


On Thu, Jul 3, 2014 at 9:19 PM, ideas buenas <ideasbuenas@gmail.com> wrote:

> I'm not referring to this.I'm talking of a lot of URI that appears when I
> try to link to any site. Every one of those Remote Address start with a
> couple o letters followed by numbers like this:
> server-54-230-83-145.mia50.r.cloudfront.net  .
>
>
>
>
> On Thu, Jul 3, 2014 at 2:59 AM, Seth David Schoen <schoen@eff.org> wrote:
>
>> ideas buenas writes:
>>
>> > Why is markmonitor.com and its derivates in my TBB? How can I do to
>> delete
>> > this ? Are they watching me?
>>
>> Hi,
>>
>> Are you talking about seeing a markmonitor.com rule in the HTTPS
>> Everywhere
>> Enable/Disable Rules menu?
>>
>> https://www.eff.org/https-everywhere/atlas/domains/markmonitor.com.html
>>
>> If so, this is one of thousands of HTTPS Everywhere rewrite rules that
>> are included with HTTPS Everywhere, which is included with the Tor
>> Browser Bundle.  The goal of HTTPS Everywhere and its rewrite rules
>> is to automatically access as many sites as possible with secure HTTPS
>> connections.
>>
>> HTTPS Everywhere typically does not make your browser access sites or
>> services that it would not otherwise have accessed, so it shouldn't help
>> sites monitor your web browsing if they would otherwise not have been
>> able to.  There are definitely lots of sites that can monitor some aspects
>> of your web browsing because the site operator has included content loaded
>> from those sites in their web page (so your browser automatically
>> retrieves
>> that content when you visit the page that embedded the content).  For
>> example, there are ad networks whose ads are embedded in thousands or
>> millions of different sites, and if you visit any of those sites without
>> blocking those ads, the ad network operator will get some information
>> about your visit when your browser loads the embedded content from those
>> servers.
>>
>> The "monitor" in the name of markmonitor is not a reference to monitoring
>> users' web browsing.  Instead, it's part of the name of the company
>> MarkMonitor, a subsidiary of Thomson Reuters, that provides certain
>> Internet services mostly to very large companies.
>>
>> https://www.markmonitor.com/
>>
>> Their name is supposed to suggest that they can "monitor" their clients'
>> trademarks, but not specifically by spying on Internet (or Tor) users'
>> web browsing.  It seems that one of their original lines of business was
>> letting companies know about trademark infringement on web sites, so that
>> MarkMonitor's customers could threaten to sue those web sites' operators.
>> They subsequently went into other more infrastructural lines of business.
>>
>> There was an article a few years ago criticizing the large amount of
>> power that MarkMonitor has, but most of that power seems to have arisen
>> mainly because it's an infrastructure provider that some very popular
>> sites decided to sign up with for various purposes (primarily to register
>> Internet domain names, because MarkMonitor's domain name registration
>> services make it extremely difficult for somebody else to take over
>> control of a domain name illicitly).
>>
>> The markmonitor.com HTTPS Everywhere rule is one of thousands of HTTPS
>> Everywhere rules, and its goal is solely to make sure that if you're
>> visiting a web page hosted at (or loading content from) markmonitor.com
>> itself, that your browser's connection to markmonitor.com's servers will
>> be a secure HTTPS connection instead of an insecure HTTP connection.  It
>> is not trying to give any additional information to those servers or to
>> cause your browser to connect to those servers when it would not
>> otherwise have done so.
>>
>> (You can see the rule itself in the atlas link toward the beginning of
>> my message, and see that its effect is to rewrite some http:// links into
>> corresponding https:// links, just like other HTTPS Everywhere rules do.)
>>
>> Having HTTPS Everywhere rules that relate to a site does not necessarily
>> mean that your browser has ever visited that site or will ever visit
>> that site.  We've tried to make this clear because many of the rules
>> do relate to controversial or unpopular sites, or sites that somebody
>> could disagree with or be unhappy about in some way.  Each rule just
>> tries to make your connection more secure if and when you as the end
>> user of HTTPS Everywhere decide to visit a site that loads content from
>> the servers in question.
>>
>> You can disable the markmonitor.com HTTPS Everywhere rule from within the
>> Enable/Disable Rules menu -- but that won't stop your web browser from
>> loading things from markmonitor.com's servers if and when you visit pages
>> that refer to content that's hosted on those servers.  It will just stop
>> HTTPS Eveyrwhere from rewriting that access to take place over HTTPS URLs.
>>
>> --
>> Seth Schoen  <schoen@eff.org>
>> Senior Staff Technologist                       https://www.eff.org/
>> Electronic Frontier Foundation                  https://www.eff.org/join
>> 815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107
>> --
>> tor-talk mailing list - tor-talk@lists.torproject.org
>> To unsubscribe or change other settings go to
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>
>
>
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

