[Bug 6774] <mark> element: restrict insertion by other servers

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6774





--- Comment #10 from Nick Levinson <Nick_Levinson@yahoo.com>  2009-06-29 02:56:49 ---
There's no risk to the website owner's server. The risk is to a server at the
user's end but that is not under the end user's control, or to the user's
terminal when the user doesn't understand system details and simply is looking
at a website.

Cache technology allows storing an incoming page for a second, long enough for
the browser or receiving server to add the markup, and a browser may support
multiple caches simultaneously (I understand some do). Proxy technology, even
if no proxy today allows writing but only reading, could have writing added,
and a proxy does not require a separate server if not meant for security but
only for modifying inbound files. While the methods can be used for any
purpose, many such purposes are illegal. This use would be legal.

Institutions could also use cache or proxy technology to render undesirable
text virtually invisible to employees and to members of the public using their
public terminals. A user could use the source command to see it in raw form but
almost no one ever will, almost none even remember such a command, and some
institutions disable some of those commands for security and support reasons.

A public library near me already removed ads from Yahoo's email inbox page. The
library staff told me they do that because users get confused. I saw the inbox
pages. I saw page-editing can be done at a receiving server without slowing the
downloading time at all noticeably. The particular method was to block page
element replacements that came from non-Yahoo domains, which is arguably a
crude way to edit, but other kinds of edits appear well within technological
reach at the page-receiving end of a download.

I'm told Firefox already offers bad-word replacement. I assume that's via an
extension  or some such addition. If that's under a user's control, fine. If
the user at least knows the page is being edited, that may be acceptable. But
if it does it, technical means already are in use.

In Yahoo's search engine, I used a view-as-HTML link to view a document to
which highlighting for my keywords were probably added in less than a second.
While the URL of the HTML-equivalent document differed from the original doc's
URL, that's probably for business and legal reasons, not because the technology
made it impossible to claim the URL was the same, as retrieving a file through
a cache or a proxy doesn't show the URL of the cache or the proxy but of the
remote origin.

MS's SmartTags, as far as I know, were not much criticized for slowing page
display, if at all. They had the technology and were fast enough.

The receiving server or terminal is where this can happen, and for that the
techniques are feasible. And the subtlety is easy enough, too, so that most
users don't know the difference between original and received by looking at it.

Thanks.

-- 
Nick


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 29 June 2009 02:56:59 UTC