Re: ACTION-278 Hiding metadata for security reasons

Tyler Close wrote:

> The bit that covers this point is:
> 
> >   A user-agent
> > MUST NOT disclose representations or URIs, unless either explicitly
> > instructed to do so by the user or as legitimately directed to by
> > presented content. Since the user may wish to keep this information
> > confidential, the user-agent must not assume it can be revealed to
> > third-parties.

I'm perhaps getting lost in this long thread, but where does that MUST NOT 
text come from?   Is it in a normative specification such as an RFC, or is 
it a proposal for a rule that might be promulgated?  A Google search on 
the text turned up nothing but your email.

Thank you.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Tyler Close <tyler.close@gmail.com>
Sent by: www-tag-request@w3.org
02/09/2010 04:21 PM
 
        To:     Dan Connolly <connolly@w3.org>
        cc:     Tim Berners-Lee <timbl@w3.org>, John Kemp 
<john@jkemp.net>, ashok.malhotra@oracle.com, Larry Masinter 
<masinter@adobe.com>, Jonathan Rees <jar@creativecommons.org>, 
"www-tag@w3.org" <www-tag@w3.org>, "Mark S. Miller" <erights@google.com>, 
(bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: ACTION-278 Hiding metadata for security 
reasons


On Tue, Feb 9, 2010 at 11:47 AM, Dan Connolly <connolly@w3.org> wrote:
> On Mon, 2010-02-08 at 18:10 -0800, Tyler Close wrote:
>> On Mon, Feb 8, 2010 at 5:29 PM, Tim Berners-Lee <timbl@w3.org> wrote:
>> >
>> > On 2010-02 -08, at 07:41, John Kemp wrote:
>> >
>> > Yes, I believe that to be true too - apart from the case where a URI 
may end
>> > up being transmitted to another site "automatically" by means of the 
Referer
>> > HTTP header.
>> >
>> >
>> > Generalizing, you could argue that client software is written so as 
to store
>> > and remember and spread URIs, unlike passwords. So passwords are 
stored
>> > hidden away in some way, but browsing history and bookmarks are not.
>>
>> That seems like an enormous logical leap to take based only on the
>> Referer header.
>
> Surely you'd agree there are more information paths than the
> Referer header. I think Noah pointed out phishing detection
> services (though my understanding of those is that it's
> not that the browser sends URIs to the service, but rather
> the service sends lists of URIs to the browser, with
> periodic updates).
>
> You can easily copy and paste the URI of any page you're
> looking at into email etc.
>
> Then there are delicious bookmarklets etc.
>
> Hmm... these are deliberate actions by the user; somewhere
> else in the thread you discounted those, didn't you?
> I'll have to look again. I suspect Tim didn't consider that
> part of your argument. I wonder if it shows up in your draft text
> (of Mon, 8 Feb 2010 17:44:16 -0800). I'll have to look again...

The bit that covers this point is:

>   A user-agent
> MUST NOT disclose representations or URIs, unless either explicitly
> instructed to do so by the user or as legitimately directed to by
> presented content. Since the user may wish to keep this information
> confidential, the user-agent must not assume it can be revealed to
> third-parties.

Sharing at the direction of the user is great and should be
encouraged. Automatically leaking data against the user's wishes is
not so nice. The Referer header is the only standard place where data
is automatically leaked even when it may be against the wishes of both
the user and the presented content. Fortunately, the web-key pattern
for using the URI fragment can plug this hole.

Anti-phishing services have many different designs that have each gone
through much evolution. AFAIK, the IE service has always stripped the
query string. The Firefox version initially sent full URLs to a
server, but then switched to sending blacklists to the client.
Internal testing found the online check of the URL to be no more
effective than the blacklisting technique. All of this is second-hand
information.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Wednesday, 10 February 2010 16:43:31 UTC