- From: Ben Edelman <edelman@law.harvard.edu>
- Date: Wed, 5 May 2004 22:59:08 -0400
- To: <www-p3p-policy@w3.org>
Greetings, I'm currently looking into the possibility that certain client-side software (some might call it spyware) violates its own P3P statements. The software I'm looking at is delivered via a drive-by download. See e.g. <http://www.benedelman.org/spyware/cdt-driveby.png>, the sort of thing described at <http://news.com.com/2100-1023-877568.html>. As to the specifics: Software delivery is by HTTP, and P3P tags (HTTP header variety) are included for the JavaScript-laden HTML files that ultimately invoke the CAB that contains the actual installer stub (binary executable). These P3P tags contain a compact P3P policy and a reference to a full P3P policy that also happens to be at a well-known location on the same web host. The P3P policies may be (largely, though not completely) truthful as to users' ordinary accesses to the program's company's ordinary web server using an ordinary browser. However, they are demonstrably false as to the activities and effects of the client-side software that the drive-by seeks to install. My question, then, is whether a web site's P3P policy applies to the software provided by the site via the drive-by download, or only to accesses directly to the web site using an ordinary web browser. I've read section 2.3.3 of <http://www.w3.org/TR/P3P/#active_content> ("Applying a Policy to a URI"), which seems to be the relevant section as to the question of whether or not P3P in fact applies to the software being installed in this way. On one hand, the drive-by procedure installs software with a single confirmation ("Yes") from the user. This starts the installation of executable code returned when the URI is requested, which seems to trigger the second sentence of the third paragraph of 2.3.3 ("If executable code is returned..."). On the other hand, the resulting code does cause the installation of what might be claimed to be a separate program, triggering the Example 3 (an executable for an electronic mail program). Of course, the software at issue here is importantly different from the electronic mail program in the Example: This software lacks a full installer (just a trickler that does the whole job once users press Yes in the drive-by prompt, without further confirmation, on-screen display of a license, etc.); This software starts automatically, not at users' specific request; This software is integrated with the web browser, not a separate app. For all these reasons, the email client example in Example 3 seems somewhat inapt. Nonetheless, the argument can be made... Anyone have thoughts on this? Other text, within the P3P specification or elsewhere, that is relevant here? Discussions in the course of the drafting process? Benjamin Edelman Harvard University http://www.benedelman.org
Received on Wednesday, 5 May 2004 23:13:05 UTC