Proposals for Gathering Consumer Demographics
`
`Page 1 of 4
`
`Proposals for Gathering Consumer Demographics
`
`See also:
`
`• Dave Kristols' ideas in this area
`I. The Request-ID: header field:
`
`As originally proposed in 3 Proposals: session ID, business-card auth, customer auth.
`
`Each HTTP request should include a header field of the form:
`Request-ID: $session $request++
`
`e.g.
`
`Request-ID: 342%33a4d443 12
`
`that is, at the beginning of each session, the HTTP client chooses a random number, and each request in that session is identified by a number that increases
`monotincally with time. A "session" is not formally defined (other than "a set of requests with the same $session id"), though I suggest that browsers begin a
`session when they are invoked and when they have been idle for 30 mintues or more, and allow some user interface to say "start a new session" (i.e. "choose a
`new random session ID").
`
`Each user agent must provide a mechanism to turn this feature off, especially for site security administrators that prohibit its use.
`
`Some details: the $request is incremented for each HTTP request, including inline images; it is not reset when requests go to a different server or anything
`like that. On the other hand, HTTP clients which are not traditional user agents (e.g. multi-threaded robots) may in fact use several sessions in parallel.
`
`A proxy must pass the Request-ID: header through unmodified. One might consider some sort of Proxy-Request-ID, though I doubt it would be valuable.
`
`The response to an HTTP request must _not_ vary as a funciton of the Request-ID. That is, an HTTP proxy need not include the Request-ID in its "cache
`key." The request ID must _not_ be used to tailer the content of pages on a per-user basis. Use the anon athentication mechanism below.
`II. Automated HTML forms through Profiles
`
`In stead of business card auth
`
`An HTML user agent should maintain a profile on behalf of a user. A profile is a set of name-value fields. It should be long-lived. For example, the user agent
`may allow editing of the profile in a dialog box, and store the profile in the local filesystem. The name of each profile field begins with "profile-". Profile
`fields should include:
`profile-full-name
`profile-first-name
`profile-last-name
`profile-email-address
`profile-home-url
`profile-affiliation
`profile-affiliation-url
`profile-postal-street
`profile-postal-street-2
`profile-postal-city
`profile-postal-state
`profile-postal-zip
`profile-business-phone
`
`what else do information providers routinely ask for?
`
`In processing a form, if a form field name matches a profile field name, the initial value of the field should be taken from the value of the profile field.
`
`For example:
`<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
`title>Welcome to Guitar-Pick Land!</title>
`<h1>Welcome to Guitar-Pick Land!</h1>
`<p>Howdy partner! Welcome to Guitar-Pick land, the home
`of everthing there is to know about guitar picks.
`<p>We like to get to know the folks that use our service.
`But we keep this just between you and us.
`<a href="policy.html">We promise!</a>
`http://www.w3.org/Privacy/Proposals.html
`
`1/14/2015
`
`Google Inc.
`GOOG 1025
`IPR of U.S. Patent No. 6,014,698
`
`
`
`Page 1 of 4
`
`Proposals for Gathering Consumer Demographics
`
`See also:
`
`• Dave Kristols' ideas in this area
`I. The Request-ID: header field:
`
`As originally proposed in 3 Proposals: session ID, business-card auth, customer auth.
`
`Each HTTP request should include a header field of the form:
`Request-ID: $session $request++
`
`e.g.
`
`Request-ID: 342%33a4d443 12
`
`that is, at the beginning of each session, the HTTP client chooses a random number, and each request in that session is identified by a number that increases
`monotincally with time. A "session" is not formally defined (other than "a set of requests with the same $session id"), though I suggest that browsers begin a
`session when they are invoked and when they have been idle for 30 mintues or more, and allow some user interface to say "start a new session" (i.e. "choose a
`new random session ID").
`
`Each user agent must provide a mechanism to turn this feature off, especially for site security administrators that prohibit its use.
`
`Some details: the $request is incremented for each HTTP request, including inline images; it is not reset when requests go to a different server or anything
`like that. On the other hand, HTTP clients which are not traditional user agents (e.g. multi-threaded robots) may in fact use several sessions in parallel.
`
`A proxy must pass the Request-ID: header through unmodified. One might consider some sort of Proxy-Request-ID, though I doubt it would be valuable.
`
`The response to an HTTP request must _not_ vary as a funciton of the Request-ID. That is, an HTTP proxy need not include the Request-ID in its "cache
`key." The request ID must _not_ be used to tailer the content of pages on a per-user basis. Use the anon athentication mechanism below.
`II. Automated HTML forms through Profiles
`
`In stead of business card auth
`
`An HTML user agent should maintain a profile on behalf of a user. A profile is a set of name-value fields. It should be long-lived. For example, the user agent
`may allow editing of the profile in a dialog box, and store the profile in the local filesystem. The name of each profile field begins with "profile-". Profile
`fields should include:
`profile-full-name
`profile-first-name
`profile-last-name
`profile-email-address
`profile-home-url
`profile-affiliation
`profile-affiliation-url
`profile-postal-street
`profile-postal-street-2
`profile-postal-city
`profile-postal-state
`profile-postal-zip
`profile-business-phone
`
`what else do information providers routinely ask for?
`
`In processing a form, if a form field name matches a profile field name, the initial value of the field should be taken from the value of the profile field.
`
`For example:
`<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
`title>Welcome to Guitar-Pick Land!</title>
`<h1>Welcome to Guitar-Pick Land!</h1>
`<p>Howdy partner! Welcome to Guitar-Pick land, the home
`of everthing there is to know about guitar picks.
`<p>We like to get to know the folks that use our service.
`But we keep this just between you and us.
`<a href="policy.html">We promise!</a>
`http://www.w3.org/Privacy/Proposals.html
`
`1/14/2015
`
`Google Inc.
`GOOG 1025
`IPR of U.S. Patent No. 6,014,698
`
`
`
`Proposals for Gathering Consumer Demographics
`<form method=POST action="/cgi-bin/new-user.pl">
`<p>Name: <input name=profile-full-name>
`<p>E-mail: <input name=profile-email-address>
`<p>Would you like to be added to our mailing list? <input type=checkbox name=subscribe>
`<p>Would you like to get our catalog? <input type=checkbox name=catalog>
`<p>If so, please give us your shipping address:
`<pre>
`Street:<input name=profile-postal-street>
` <input name=profile-postal-street-2>
`City: <input name=profile-postal-city> State: <input name=profile-postal-state> Zip: <input name=profile-postal-zip>
`</pre>
`<input type=submit> <input type=reset>
`</form>
`
`Page 2 of 4
`
`Security considerations
`
`If an information provider collects data via HTML forms and keeps it for longer than the lifetime of the HTTP transaction, they should make their policy for
`treatment of the data available.
`
`User agents must _not_ use profile field values in HIDDEN fields. Any data taken from the profile _must_ be visible to the user at the time of submission.
`III. Anonymous Authentication
`
`This is much like the Netscape cookie mechanism, except that we remove the need for clients to maintain a database by weakening it such that the server does
`not specify the cookie.
`
`To facilitate applications involving per-user state, a new authentication scheme is defined: 'anon'.
`
`To support this authentication scheme, a user agent chooses a 128 bit true-random number, called the client identity, on behalf of the user.
`
`A user agent may support multiple identities per user. On the other hand, a user may want to use the same identity from a desktop and a laptop computer, so
`there should be some facility to, for example, copy and paste, or perhaps manually transcribe, user identities.
`
`Each participating information provider chooses suitably unique a realm name.
`
`To authenticate a client, an HTTP server responds to a request with, for example:
`HTTP/1.0 401 Unauthorized
`WWW-Authenticate: anon www.guitar-picks.com
`
`To authenticate itself, the client sends an Authentication: header in the request; for example:
`Authorization: anon <credentials>
`
`where <credentials> = base64(MD5(realm . ":" . client-identity))
`
`The server can then use the credentials, for example, as a key to its per-user database.
`Discussion
`
`Issue I: The desire to model the behaviour of an information provider's consumers, balanced with the privacy rights of those
`consumers
`
`I believe the Request-ID mechanism addresses this issue. It does assume certain "norms" of behaviour in the public, global information space:
`
`• that service providers have a right to collect information about who is using their service, in order to be able to do security audits, debugging, etc.
`• that service providers have an obligation to keep information about individuals using their service confidential. They may release aggregate information,
`e.g. "12000 folks hit our site today" or "40% of our consumers are using Netscape."
`• that consumers have the right to know what information is being gathered about them, especially if this information is kept longer than the lifetime of
`the transation.
`
`Consumers should be aware that each request they make is associated with their IP address, and hence possibly the domain they're affiliated with.
`
`• that consumers have the right to refuse to give out identifying information (i.e. enter a bogus email address as an anon-ftp password, or using a firewall
`to aggregate individual IP addresses into one site proxy)
`• that information providers have the right to refuse service to folks that won't identify themselves (e.g. ftp servers that do reverse name lookups on your
`IP address and check it against your email address, or require the use of IDENT, or ...)
`• that producers and consumers should use as little public resources (e.g. internet bandwidth) as possible to achieve their goals. (i.e. don't do stuff that
`breaks caching unless you have to)
`
`Note that these are norms of behaviour, quite distinct from both the technical and legal limits. Service providers should be aware, for example, that their log
`files may be subject to subpoena (sp?), and so just keeping them around at all is a privacy risk to their consumers.
`http://www.w3.org/Privacy/Proposals.html
`
`1/14/2015
`
`
`
`Proposals for Gathering Consumer Demographics
`Perhaps these norms should be written up as an RFC in the user services area of the IETF?
`
`Issue II: The desire to build applications with persistent state
`
`Page 3 of 4
`
`A number of interesting applications can be delivered via the web using HTTP and HTMl forms, but they require state that persists between HTTP
`transactions, associated with a certain user, or associated with a short dialog with a certain user.
`
`Popular implementation techniques include:
`
`• Hidden form fields. This works well if all navigation is done with form submit buttons. But as soon as the user crosses a normal hypertext link, the state
`may be lost
`• Munging URLs. A per-user identifer can be inserted in the URLs. This works correctly with caching proxies, but it has the unfortunate side effect that if
`the URL is placed in a hotlist or passed between users, it becomes invalid.
`• The Netscape Cookie mechanism. This has the unfortunate requirement that the client maintain a database of realm->cookie mappings. The consumer
`must have access to this database whenever they use the service. It's also not clear how this mechanism interacts with caching proxies.
`
`The anonymous authentication mechanism addresses this need without any of the unfortunate side-effects above. The credentials can be used as an
`anonymous user ID, or as a dialog ID.
`
`It's possible that the anon authentication scheme is a special case of the simple-MD5 mechanism. For exmaple, the client can use the identity as both the
`username and password. The server need never know either the username nor password: they just use the credentials as the dialog ID.
`
`Issue III: The desire to unobtrusively gather demographical information about consumers and to build user profiles, balanced
`with the privacy rights of consumers
`
`The automated forms should reduce the burden of consumers to fill out basic name and address forms. Yet no information is given out without explicit
`approval of the user (clicking the "submit" button with the information being given away visible.)
`
`The anon authentication should provide an "identity" in any requests that need it. This identity is not transferrable between realms (i.e. Wired and Pathfinder
`can't collude), and it is anonymous: the server never learns the client identity, let alone name, address, etc., unless the user explictly submits this information.
`
`Issue IV: The effect of caching proxies on the demograhpics gathered at a site
`
`To complete the picture, we really need some way for caching proxies to relay these demographics to origin servers. One possible mechanism is for original
`servers to include in their response:
`Log-To: mailto:logs@here.com
`
`A caching proxy would keep track of cach hits on that resource, and report them in buld via email in this case, though HTTP posting is another possible
`mechanism.
`
`The privacy considerations are tricky. A considerable amount of sensitive data could be gathered very quicly by a malicious third party.
`
`Another compilcating factor is that a simple proxy may not even log the data that the original service provider is interested in.
`
`Ideally, we could agree on some aggregate statistics that all proxies could gather and relay in batch. Unfortunately, I expect that the set of data that's
`"interesting" varies widely between providers.
`Related Work
`
`Net tracking standards slow to emerge
`from c|net:
`
`Net tracking standards slow to emerge, experts say SAN FRANCISCO--At the Internet Tracking Roundtable discussion sponsored by c|net:
`the computer network here Friday, an industry group composed of Internet content providers, media planners, advertising agency
`representatives, and researchers agreed on one point: no one Internet tracking standard is likely to emerge in the near future.
`
`The discussion centered on which tracking criteria are needed to make the Net more hospitable to advertisers. Panel members included
`representatives from Neilsen, I/Pro, J. Walter Thompson, HotWired, NetCount, and c|net.
`
`In general, content providers argued that the uniqueness of the Web demands custom tracking standards that take into consideration current
`technology constraints.
`
`One hurdle to accurate tracking is the lack of a common vernacular to describe Web tracking criteria, said c|net CEO Halsey Minor. For
`example, "hits," "visits," and "pages accessed" all mean different things to different people, he said.
`
`Some representatives from the advertising side of the fence said the key is to use the same kinds of tracking devices already used in broadcast
`and print.
`
`...
`
`http://www.w3.org/Privacy/Proposals.html
`
`1/14/2015
`
`
`
`Proposals for Gathering Consumer Demographics
`Daniel W. Connolly
`$Id: Proposals.html,v 1.1 1998/10/22 20:05:00 renaudb Exp $
`Webmaster
`Created October 1995
`Last updated 06 Nov 1995
`
`Page 4 of 4
`
`http://www.w3.org/Privacy/Proposals.html
`
`1/14/2015
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
