W3C home > Mailing lists > Public > www-tag@w3.org > February 2010

Re: ACTION-278 Hiding metadata for security reasons

From: Jonathan Rees <jar@creativecommons.org>
Date: Wed, 10 Feb 2010 22:04:56 -0500
Message-ID: <760bcb2a1002101904k3398f962kc70da87c5c2c0988@mail.gmail.com>
To: Larry Masinter <masinter@adobe.com>
Cc: Tyler Close <tyler.close@gmail.com>, Dan Connolly <connolly@w3.org>, Tim Berners-Lee <timbl@w3.org>, John Kemp <john@jkemp.net>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, "www-tag@w3.org" <www-tag@w3.org>, "Mark S. Miller" <erights@google.com>
Can you apply your method to the https unsubscription use case that I
gave? Suppose that being unsubscribed would do me harm, and that an
attacker was trying to unsubscribe me. What would they do?

Personally I would rather not deal in generalities at this point. We
should either come up with some way of saying that the unsubscribe
case is OK, or else come up with a real threat (either to the user, or
to the architecture) that would make the multitudes pay attention and
change their evil ways. Figuring out the general case can be done in
parallel or later.


On Wed, Feb 10, 2010 at 6:05 PM, Larry Masinter <masinter@adobe.com> wrote:
>>   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.
> While I'm sympathetic to the intent, this leaves undefined
>  the scope of "user agent" here, referent of "the user",
> and the meanings of "disclose", "legitimately", "confidential",
> "assume" and "third-parties".  Does "user agent" apply to,
> say, archive.org (which might pick up a mailing list archive
> of an email and scan what is supposed to be a 'private'
> URL)? Does it apply to, say, news.google.com, which seems
> to aggregate news from newspapers that have a "news reader"
> registration and login requirements?
> I don't think this is an effective path to pursue. There are
> agents that use URIs, including browsers, crawlers, scanners,
> aggregators, portals, bookmark sharing tools, translation
> gateways, Internet Archive services. These agents, for better
> or worse, have widely varying properties where information
> retrieved by them is distributed further, including using
> Referer, publishing access logs, peer sharing of cached
> retrieved results, etc.  Many of those deployed web agents
> make the presumption that any material they access without
> going through any particular access control mechanism may
> be shared further without particular restriction, although
> in practice the distribution that happens is not widespread,
> there are no guarantees.
> While "secret URLs" provide the appearance of adding some
> amount of confidentiality to the results, in fact, there
> are many circumstances where such URLs are disclosed,
> by agents that are not browsers and whose update to follow
> recommendations in _this_ document is unlikely.
> A false sense of security is worse than no security,
> in many circumstances.
> If users wish to make material available to "anyone who
> has the URL", that's fine, but don't make any promises
> that this is a "security" mechanism, because it's not.
> There is a kind of "security" I've heard called "yellow
> ribbon security", which functions like the "yellow ribbon"
> banner sometimes put up:
> Now, the yellow ribbon doesn't actually prevent anyone
> from crossing it, it just puts the crosser on notice
> that they are actually crossing a line someone (perhaps
> even the police) do not want them to cross.
> It *might* be possible to make secret URLs into a
> "yellow ribbon" security mechanism, if, for example,
> the "unguessable" part of the URL were clearly
> unguessable.  (Random jumble of letters rather than,
> say, random quotes from literature, which might not
> look random.)
> Larry
> --
> http://larry.masinter.net
Received on Thursday, 11 February 2010 03:05:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:32 UTC