- From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
- Date: Fri, 16 Oct 2009 13:56:52 +0100
- To: <www-tag@w3.org>
- Message-ID: <D5306DC72D165F488F56A9E43F2045D30210C492@FTO.mobileaware.com>
To the TAG members, Recent discussions with other W3C members once again highlight the general mis-understanding of the role of the URI (or URL, to use the term more familiar to the wider community). The publication of a URL that identifies a third party resource cannot (in any sensible manner) be prevented by that third party because the URL is merely the address of a single resource within a huge public space. By virtue of placing the resource into the public space, the owner of the resource (or the associated intellectual property) has effectively agreed to reveal the address and make it "common knowledge". Some owners of these resources seem to believe that they can legally prevent people from uttering Web addresses in public. This would be counter to the architecture of the Web, which depends on being able to make such references. This probably seems correct to anyone familiar with the Web. A statement from the TAG to this effect reinforcing the open nature of URLs may help dispel the misunderstandings about what can and cannot be done with URLs. However, there are still some concerns about how such links might be used, and there seems to be no obvious means of addressing these shortcomings. Example 1: It is possible to create a Web page that contains image elements that use deep links into a third party site. The creator of the page has not accessed or modified the referenced images. The images are only presented to the end user because the user's Web client has retrieved the images directly, albeit because of the markup. Such out-of-context retrieval is naturally a concern to the owners of the referenced images but still seems legitimate in terms of the Web architecture. This is a particular problem in phishing scams where the referenced resources are employed as part of a deception to convince the end user that the page being viewed is legitimately from the bank, society, club or whatever. Framing entire pages is another example where the Web architecture seems to facilitate plagiarism. Example 2: We have observed the increasing practice of introducing a proxy between the client and the origin server. The proxy may manipulate the interaction with the end user, either to inject/remove material or otherwise adapt the interaction to match the environmental constraints. Accessing the Web via mobile devices is a particular example. (The work of W3C in offering guidelines for such scenarios is welcome.) Does the fact of providing a resource for access via a public URL also grant the consumers of the digital representations of that resource the right to manipulate those representations? One might argue that the Web browser itself is manipulating the data stream in order to provide a rendering for the user, and this is itself a form of adaptation. If the Web architecture permits (and encourages) this, then it seems fair for anyone to assume that any Web traffic may be manipulated. However, if the origin server takes steps to ensure that the resources are NOT publically available by requiring the user to enter into a session via some form of credentials, then does the continued adaptation by the proxy not constitute a breach of the terms of access? Example 3: A site that adapts its response to the delivery context (as does my company's mobile Web technology) may emit an entirely different site map to the end user, depending on how that user is interacting with the site. Pagination of long pages, for example, will lead to intermediate pages (sub-pages, if you like) that have URLs of their own. These URLs are ephemeral. Deep linking to these URLs, because of their temporary and context-dependent nature, would be meaningless. Is there a recommended way for the adapting server to respond to a client that is referencing such deep links from outside of the delivery context in which such URLs might make sense? The current options are to redirect to a base representation, return a HTTP error code or to return a representation of the URL (if possible) that is suitable for the new delivery context. Some guidance from the TAG on these concerns would be welcome. Regards, ---Rotan. ____________________________ Dr Rotan Hanrahan Chief Innovations Architect and CTO Mobileaware Ltd 4 St Catherines Lane West The Digital Hub Dublin 8, Ireland E: rotan.hanrahan@mobileaware.com W: www.MobileAware.com CONFIDENTIALITY NOTICE This e-mail message and all documents that accompany it are intended only for the use of the individual or entity to which addressed and may contain privileged or confidential information. Any unauthorised disclosure or distribution of this e-mail message is prohibited. If you have received this e-mail message in error, please notify us immediately so that we may correct our internal records. Thank you.
Received on Friday, 16 October 2009 12:57:45 UTC