Re: Improved Client Identification

Andrew Mulholland <andrew@bash.sh> Wed, 04 March 2015 19:47 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ietf.org@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB61ACE38 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 4 Mar 2015 11:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.689
X-Spam-Level:
X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvCJCYUx8H7A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 4 Mar 2015 11:47:43 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB89B1ACE37 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 4 Mar 2015 11:47:42 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YTFDN-0005gV-GE for ietf-http-wg-dist@listhub.w3.org; Wed, 04 Mar 2015 19:44:17 +0000
Resent-Date: Wed, 04 Mar 2015 19:44:17 +0000
Resent-Message-Id: <E1YTFDN-0005gV-GE@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <andrew@bash.sh>) id 1YTFDG-0005eE-Uy for ietf-http-wg@listhub.w3.org; Wed, 04 Mar 2015 19:44:10 +0000
Received: from mail-qc0-f178.google.com ([209.85.216.178]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <andrew@bash.sh>) id 1YTFDA-00027u-Ca for ietf-http-wg@w3.org; Wed, 04 Mar 2015 19:44:10 +0000
Received: by qcwb13 with SMTP id b13so1597622qcw.12 for <ietf-http-wg@w3.org>; Wed, 04 Mar 2015 11:43:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MvKS3DtSEA4MvlL4Pzruhf1Ut/i78rLMRHGRZ9W84mU=; b=bZSnstgXsMVvnFMWNViV3IN0vlhUn54s7l4NOYbO6HZe6j1nAwHOJqs9d5gl7Zi9D6 lCcTKJVlTyWanJNOsCKjV2/zJcgB/VTArHMcQAkXMSKQN7BbhOqFkHKS0lZgXWTROfr6 pwXYbnO5Gy+EwiLZ9B8W7NLjwe4KNenROkq/xCT1b6kbDzbh+SbUytqS+3ar6y+67/BK ppENfWQAABEjDlohsLFPmEMnSTp1tq6xeTCPe9l+gg71ktMEexZg6GuwSNhsxTzrjGjM sPYR8eFtYxcXtxK43i/4fzcFQ4D2Je3wYc9+MssSRmRKPwzOygg29Vc0TVJniNc8NBAW 0MkQ==
X-Gm-Message-State: ALoCoQlhhb8KI/oJZRqy6UlkkCMBknWhDdbo7lJJoV1ZAK8ZOV/R2DInZgw6C5cLP8RThdrnAywR
MIME-Version: 1.0
X-Received: by 10.55.43.17 with SMTP id r17mr10361457qkh.28.1425498217289; Wed, 04 Mar 2015 11:43:37 -0800 (PST)
Received: by 10.140.232.78 with HTTP; Wed, 4 Mar 2015 11:43:37 -0800 (PST)
In-Reply-To: <CADP4zhFON3u03kYfL2iYhhOoZ91LoLkcNamphFKniba2YdmugA@mail.gmail.com>
References: <CADP4zhFON3u03kYfL2iYhhOoZ91LoLkcNamphFKniba2YdmugA@mail.gmail.com>
Date: Wed, 04 Mar 2015 14:43:37 -0500
Message-ID: <CA+JaFPjMqcvR=G=bQwjkUO71YguH2KRC7HDacQL0u=darmBqcQ@mail.gmail.com>
From: Andrew Mulholland <andrew@bash.sh>
To: Sanel Mesinovic <sanel.mesinovic@ymc.ch>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="001a11496d50deb03605107baabf"
Received-SPF: pass client-ip=209.85.216.178; envelope-from=andrew@bash.sh; helo=mail-qc0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-0.7
X-W3C-Hub-Spam-Report: HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: lisa.w3.org 1YTFDA-00027u-Ca 2d57c79b31e0dcd97b503852d073bcc4
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Improved Client Identification
Archived-At: <http://www.w3.org/mid/CA+JaFPjMqcvR=G=bQwjkUO71YguH2KRC7HDacQL0u=darmBqcQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28887
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 20 February 2015 at 10:36, Sanel Mesinovic <sanel.mesinovic@ymc.ch>
wrote:

> Hello,
>
> I found your email address here <https://httpwg.github.io/about/policies/>.
> Have one small contribution / request to make to the new HTTP 2 protocol.
> Already wrote an email long time ago to Tim Berners Lee however no reply.
> Maybe someone already during this time already raised the issue.
>
> In my opinion the new protocol should introduce a better way to uniquely
> identify the client. Currently it is not possible to uniquely identify a
> user. IP identification is not reliable. There can be two or more users
> behind the same IP. Session identification is even worse.
>
> There are many advantages of using better identification:
>
> a.) web analytics could track unique visitors per time period much more
> accurately
> b.) tracking user activity in apps e.g. not allowing the same user to like
> the page if he has already clicked the Like / Vote button
> c.) law enforcement could much easier prove who was the culprit behind the
> criminal activity
> d.) other reasons
>
>
Whether or not these are advantages depends on your perspective.
I'm not convinced that these are sufficiently good enough reasons to expose
more data about an individual.


> In my vision the protocol should allow the server side to ask or the
> client side to send the system data to the server. There could be two
> scenarios:
>
> 1.) The server could specify that the browser must provide the UNIQUE DATA
> 2.) The client could send the UNIQUE DATA by using javascript.
>

Herein lies the flaw with such a setup.
If you are trusting a remote system for which you have no control over to
provide data that you use to define a trust relationship, or for
identification purposes, then essentially you have no control over the data
at all.

Of course perhaps people with nothing to hide are exposing more than
before, so it's not great for them from a privacy perspective.

Perhaps I've something to hide, so through the use of a browser plugin,I
ensure my browser returns random data for these, or perhaps spoofs the
identity of another...

Similarly perhaps I/you accidentally were to browse to a server hosted by
an untrustworthy entity, who then sells lists of "unique data" which could
be use by others to spoof identity.

The existing ways are for sure not perfect, but they do not rely solely on
user provided information to establish identity, and I fail to see how this
'Unique Data' can be any more accurate than a randomly generated UUID
stored in a session cookie.


best wishes


Andrew