W3C home > Mailing lists > Public > www-tag@w3.org > October 2009

URIs, deep linking, framing, adapting and related concerns

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Fri, 16 Oct 2009 13:56:52 +0100
Message-ID: <D5306DC72D165F488F56A9E43F2045D30210C492@FTO.mobileaware.com>
To: <www-tag@w3.org>
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


However, there are still some concerns about how such links might be
used, and there seems to be no obvious means of addressing these


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.








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



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


Received on Friday, 16 October 2009 12:57:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:04 UTC