- From: Nathan <nathan@webr3.org>
- Date: Thu, 16 Dec 2010 22:00:24 +0000
- To: Jonathan Rees <jar@creativecommons.org>
- CC: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>, www-tag@w3.org
Is this a case of, anybody can make any link they please (embedded or not), but they can/should be able to be held accountable if they make one inappropriately? (inappropriately as in illegal in some way), resource owner vs resource owner? Best, Nathan Jonathan Rees wrote: > http://www.chillingeffects.org/derivative/faq.cgi#QID380 reports on a > case where frames were used to place ads around content picked up > elsewhere. This seems very similar to your example #1 of image > inclusion. If so a court may very well one day find <img> links to > unlicensed material to be infringing. > > Best > Jonathan > > (tracker: ISSUE-25) > > On Fri, Oct 16, 2009 at 8:56 AM, Rotan Hanrahan > <rotan.hanrahan@mobileaware.com> wrote: >> 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 Thursday, 16 December 2010 22:01:36 UTC