Note: this blog is a mirror of my HP Labs Blog, on the same topic, accessible at: http://h30507.www3.hp.com/t5/Research-on-Security-and/bg-p/163

Monday, July 30, 2007

Web 2.0/Ajax “Submission Throttling” and Privacy Concerns

“Submission Throttling” (e.g. see here) is an “Ajax Pattern” commonly used in state-of-the-art web applications: in a nutshell, data is buffered at the user/client side (web browser) and then sent to the server (e.g. remote web site) at predetermined times.

Interesting “side-effects” might occur when “personal data” is involved and the user is not really aware of what is going on … Let’s consider a simple example.

In the context of an “HTML form”, shown in a web page within a web browser, “Submission Throttling” techniques consist in sending part of the information already typed in this form - *** BEFORE any “Submit” button has been clicked by the user …*** - to the remote server (for a variety of reasons, e.g. field content validation, getting suggestions, etc.) and getting back some “feedback” (e.g. word correction, complete word, etc.). This Ajax pattern is simple to implement as it requires “java script-enabled” web browsers and some client-server coordination (see a full working example here):

  1. A web form is displayed to the user in a web page, via a web browser;
  2. Java script code, running in the web browser (associated to the current web page), listens for events related to the form, such as typing characters or changes of focus (e.g. related to form fields);
  3. When such event occurs, the current content of one or more fields is collected by a java script function and sent to the remote web server, for example via XMLHttpRequest (i.e. a programmatic HTTP request to the remote site made by java script code);
  4. The remote web server gets this data, does some processing and returns back an answer (e.g. a corrected version of the typed word/sequence of characters, a complete version of word, an indication that that word cannot be used in that context, etc.) to the java script code, running in the user’s web browser;
  5. This java script code uses this “answer” to provide some “feedback” to the user (e.g. suggesting that the typed “userId” cannot be used, as somebody else has already used it or that the currently typed e-mail address is incorrect).


Please notice that the current data in the form is disclosed in advance to the remote web server - prior to any explicit “Submit” decision made by the user and/or without necessarily the end-user understanding that this is happening and giving his/her consent …

On one hand, I see the usefulness of this mechanism (when properly used) and the value it brings in making web services more usable and interactive. On the other hand, from an identity and privacy management perspective, I see the possible risks this pattern could bring – both in malicious and non-malicious situations – for example when the involved user’s data is personal data.

I believe there are some implications in terms of privacy laws and data protection. Is it legal to disclose in advance user’s data, prior to his/her “consent” to submit this data? Of course javascripts could be disabled in web browsers and the problem neutralised – but in doing this most of the current “web 2.0” functionalities are disabled as well.

I think that users should be made aware when these techniques are used (and perhaps their consent asked in advance) … and “web browser tools” deployed to achieve this (e.g. web browser plug-ins detecting outgoing XMLHttpRequests or other attempts to connect to web servers during a session and transfer data).

What do you think? What is your view?

No comments: