Delivery-Date: Thu, 03 Jul 2014 17:27:16 -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 3B7251E0C1B
	for <archiver@seul.org>; Thu,  3 Jul 2014 17:27:14 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4D8332C439;
	Thu,  3 Jul 2014 21:27:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 9D6C02E80B
 for <tor-talk@lists.torproject.org>; Thu,  3 Jul 2014 21:19:38 +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 iEyp8uN8mAcT for <tor-talk@lists.torproject.org>;
 Thu,  3 Jul 2014 21:19:38 +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 7B29A2B4FF
 for <tor-talk@lists.torproject.org>; Thu,  3 Jul 2014 21:19:38 +0000 (UTC)
Received: by mail-ie0-f181.google.com with SMTP id y20so859038ier.26
 for <tor-talk@lists.torproject.org>; Thu, 03 Jul 2014 14:19:36 -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=Am9N3HZHE3r15hC74cByC9/l6V7ig+NpOrp/dYYdyIw=;
 b=GOwOAO/i0nyKAbhzkwvsKfofeMvTSf/YCdmRoTrHyDCbovJ5Y/l2lSGR1JK3fdqKz2
 /PMZaIIXuCI+HxpnSgs7AbgsV3eZ2iBUlQuwAMIg/Gbu3oM1jfz/olIfLjQJTJ6J96IN
 hf0xKBLcmaoLWLLDeteNIAlnZBoezaxQk+UZfopIPKAtE3VYIm/vHIYg4W4HYNFDFup8
 KkmvpPbaBPaE6Jp69fTGYL1BJI/l+d4PTphCoUz4KhU9uF6SaJZRYnvJrWKlg5XKLhge
 ORFFvBqL4bwkwNA0kAqTZYZgdwNV3HXUMbCOYMW+jOoqzSn4n0Th3srbuK2WPIk52Bae
 k4Rw==
MIME-Version: 1.0
X-Received: by 10.50.117.2 with SMTP id ka2mr14563843igb.33.1404422376140;
 Thu, 03 Jul 2014 14:19:36 -0700 (PDT)
Received: by 10.64.30.194 with HTTP; Thu, 3 Jul 2014 14:19:36 -0700 (PDT)
In-Reply-To: <53b4d10c.32658c0a.3341.783eSMTPIN_ADDED_BROKEN@mx.google.com>
References: <CAP-DOiTPMHavRep1c6mEjM8ykoeMXjYq-ddyD3ewSyLywS4aYQ@mail.gmail.com>
 <53b4d10c.32658c0a.3341.783eSMTPIN_ADDED_BROKEN@mx.google.com>
Date: Thu, 3 Jul 2014 21:19:36 +0000
Message-ID: <CAP-DOiQGg7C8soyDGTe9R7E85mB8Soxhr4VuaAOifXtp5cdwVg@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>

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

