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

Secret URLs and TAG deliberations

From: Larry Masinter <masinter@adobe.com>
Date: Sat, 23 Jan 2010 11:19:00 -0800
To: Jonathan Rees <jar@creativecommons.org>, Tyler Close <tyler.close@gmail.com>
CC: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D5FE372@nambxv01a.corp.adobe.com>
> 1. The TAG does not dispute any of the arguments made in
> my web-key paper <http://waterken.sf.net/web-key>.

I had no opinion about Tyler's arguments because I hadn't
read the paper, and I don't think there was a reference to
it in the discussions. Looking at it now, I'm not sure what
"arguments" are applicable to the question. The paper looks
like a design for a new mechanism, and the arguments given
in it seem like they're addressed to defining the problem
the new mechanism might address and why it addresses them,
but I'm not sure which arguments read on the policy
statements of W3C.  I think I (or we, or some TAG members)
have (possibly inadvertently) disputed other arguments that
are similar to the ones in that paper, though.

> I think part of the problem is that "sharing" in web
> architecture means "sharing with everyone" rather than the
> more general web-key notion of "sharing with those who you
> want to share with". The TAG findings seem to take an
> all-or-nothing view to sharing, putting access control
> basically outside of the purview of web architecture, even
> though it has a very simple solution within it.

I'd say that the TAG findings might be more narrowly
applicable in this situation than one would like. But of
course, it is inevitable that "findings" are general, and
there may be specifics missed.

> The roots of this position are historical (the web was
> created as a global information space), political (let's
> not make it too easy to create secret things that "divide
> the web"), and technical (access control is complicated
> and if we worried about it the architecture would topple
> under its own weight). This is an awful lot of baggage to
> try to put aside all at once...

I'd say the primary issue originally and still is that
complex security issues and considerations tend to cross the
protocol layer boundaries, and involve dealing with DNS and
TCP and routers and key and password infrastructure and a
wide variety of technical topics that are outside of the
domain of W3C.

This is the main reason why I've been keen on encouraging
the establishment of a cross-organizational web security
review group, rather than trying to deal with all of them in
the TAG or in the W3C alone.

A second related issue is resources: as a TAG member,
there's barely enough time in the amount that I allocate for
TAG work to attend the meetings, stay up on the issues that
are before us participate in discussions, prepare materials
for future meetings, write analyses and so forth, and other
TAG members seem to be in a similar situation. When
resources are finite and exceeded by demand, then
prioritization is important, and establishing the
architecture for the public web first seems most useful.

Neither of these two factors are "baggage" that can be "put

Finally, I don't agree that the TAG seems, to me, to be
overly burdened with the "historical" or "political" or
"technical" burdens JAR lays on us, although they are not
unreasonable as factors to consider when prioritizing topics
for discussion.

>> 2. The TAG understands that unguessable URLs are used for
>> access-control by many of the most popular sites on the
>> Web. For example, this email contains a Google Docs URL
>> [1] for a document I have chosen to make readable by all
>> readers of this mailing list, even those who have never
>> used Google Docs. Had I not so chosen, these readers
>> would not have access and I could have shared access with
>> a smaller group of people, or no one at all.

The TAG is aware of this usage pattern; I also provided a
similar URL at the acrobat.com site, and the user interface
that allows a user to choose this method of distribution.
But I disagree that this is "Access Control" as meant in
http://en.wikipedia.org/wiki/Access_control.  If one means
something else by "access control", I'd like a reference of
a definition of the term (preferably in the computer science
published literature).

> Noah said that he didn't find popularity to be convincing,
> so this is irrelevant to him.

What I thought I heard Noah say (and I agree) is that
popularity of a mechanism doesn't, by itself, mean it is
right. I think that popularity of a mechanism should be a
motivation for looking hard at why those who use it *think*
it is right, and to consider that perhaps there are some
requirements for which the mechanism is, after all, a valid

But unguessable URLs are as useful for access control in the
same way that the ancient Egyptians used secret passages to
protect the pyramids from looters:



or that CONTROL headquarters was protected by the use of a
secret phone booth:


Secret entrances (without access control properly in place)
are very weak (laughably weak) methods of protection. Anyone
following Max and Agent 99 can see them drop in the phone
booth and know how to get into CONTROL headquarters, and
anyone following a "Referer" path from an otherwise
protected page or document can get access.

> 3. Some members of the TAG believe that an unguessable
> https URL is a "password in the clear", but that sending
> someone a URL and a separate password to type into the web
> page is not a "password in the clear".

No, someone (Noah?) said that it reminded him of the
"passwords in the clear" issue and had perhaps some related
arguments. I agreed that there might be some common factors.

And it is true that sending someone a URL and a separate
password is different than sending them a URL which contains
a password, because one of the exposure points for the
password are URL proxies and other intermediaries which
remember URLs used, and send them on using Referer; these
exposure points are not there for passwords sent back as
form-data (as long as the form is submitted with POST and
not GET).  The "password in clear" similarity didn't factor
in that agreement.

>> 4. The TAG is currently sticking to its finding that
>> prohibits use of the web-key technique because Noah
>> Mendelsohn says: "I don't like that". There are no other
>> substantive arguments that I could attempt to refute.

This is nonsense for several reasons. First, Noah actually
gave substantive reasons, and the characterization of his
actual discussion (necessarily summarized in the minutes,
since we don't have transcripts) is patently unfair.

Secondly, this message itself is chock full of substantive

Finally, this and Tyler's following outburst this
morning really are questioning the assumption of the
TAG, as chartered:

including the section "Participant Qualifications"
and the decision process involved.  Frankly, I
don't think should be left unchallenged. I have yet
to see any example of any TAG member in the history
of the TAG make any assertions that are simply
and merely based on "personal preference" without
reference to architectural principles, past experience,
a concern for the proper operational future of the
web, and followed by discussion of substantive
reasons for making a claim. Tyler, if you are willing
to stand by your insinuations, please supply some
evidence of  any contradiction of TAG member behavior
to the principles by which the TAG is chartered,
or else withdraw your insult.

> "The TAG" is just a bunch of people.

I disagree. The tag is not "just" a bunch of people. We do
seem to be undergoing a technical Cultural Revolution
http://en.wikipedia.org/wiki/Cultural_Revolution where the
imperialist intellectuals (those who profess expertise)
should be purged from their positions of power. But I am
going to hold onto my old guard position of believing that I
(and Noah and Jonathan) actually have some recognized
expertise and that we are not "just" a bunch of people,
we're special, very special.

> "Sticking" sounds like an active thing, but all we have is
> "has not yet resolved to fix a previous TAG's consensus
> statement on the matter" which doesn't imply consensus in
> the current group that UMU is OK as it stands. It's very
> difficult to get any group to make any kind of consensus
> statement, especially when the group contains views as
> different as the ones Noah and I hold on this subject.

FWIW, in a meta-disagreement, I disagree with JAR that the
TAG is as far from agreement as JAR we are, or that JAR
actually disagrees with Noah.

> 5. The TAG does not dispute my argument that the current
> finding is self-contradictory.

I'm not sure "the TAG" discussed the argument. I will
dispute it here, though (if what is meant is

where it says the finding is self-contradictory.

(Tyler msg 2009Dec/122)
>>> .... Therefore, an obvious deduction from the body text
>>> is that the URI for a confidential resource should not
>>> be guessable, and should be kept confidential. The "Good
>>> Practice" conclusion of the section then flatly
>>> contradicts the body text of the section.

This argument makes a deduction from the body text
which the body text does not state; the deduction is
labeled "obvious" but it is false.

But the assertion claimed to be contradictory is actually
not there:

>>> The last sentence of the body text correctly points out
>>> that the ability to guess the URI for a confidential
>>> resource is dangerous.

That's not what the last sentence of the body text actually
says. What it actually says is:

(TAG finding)
>>>> Furthermore, if access controls are not properly in
>>>> place, he might be able to guess the URIs for other
>>>> accounts, and to attempt to access them.

The last sentence does point out a use case of a danger, but
the root cause is not identified. The "root cause" is just
as easily "access controls are not properly in place" and
not "ability to guess the URL".

(Tyler msg 2009Dec/122)
>>> Therefore, an obvious deduction from the body text is
>>> that the URI for a confidential resource should not be
>>> guessable, and should be kept confidential.

This deduced assertion is not an "obvious deduction" and so
is not contradictory to the "Good Practice".

I have now disputed the assertion that the finding is

Does the TAG dispute this too? One could argue that "Larry
(on the TAG) disputes X" is consistent with "the TAG does
not dispute X", but I would disagree. While "the TAG says X"
is only consistent with "The TAG, using its decision policy,
has agreed to say X", the phrase "The TAG does not say X"
does not require the TAG to decide to say "not X".

"The TAG does not dispute X", being different from "The TAG
says it does not dispute X", the former can only mean that
no one on the TAG disputes X. Obviously.

So the assertion 5 "The TAG does not dispute..." is false.

> Again, better not to say "The TAG"...

I think it's fine to talk about what the TAG says, as long
as it is accurate. "The TAG" has a decision process.
Generally, though, that process wouldn't result in directly
"not disputing" someone else's argument, though.

> If I can paraphrase Noah's argument, he asserts that URIs,
> simply by virtue of being URIs, are so likely to be made
> public that they shouldn't ever hold bits that need to be
> protected. If something needs to be kept private it
> shouldn't be in a URI.

Maybe I'm projecting, but I think Noah offered that as a
strawman argument. It is a problem that the TAG findings try
to be so proscriptive about what to do or not to do (rather
than descriptive of consequences) that more nuanced advice
is difficult. If I had to give a simplistic rule of thumb
rather than a more analytical factor analysis, I would agree
with advising "If something needs to be kept private it
shouldn't be in a URI", although it should be obvious that
all design heuristics are just that.

> Somehow the password by virtue of being called a password
> is going to be protected, while the URI by virtue of being
> called a URI is going to be exposed.

I don't think this is what I heard Noah say, or what I
think.  I think URIs are exposed to more paths of disclosure
than other means of communication and thus are more likely
to be revealed broadly, and push the balance of Good
Practice away, as the finding currently recommends.

>> I don't agree with this; like you I think using URIs to
>> designate is a good idea. While creating public good and
>> "network effects" is a good thing, and the architecture
>> should strive to make it easy to create public benefit,
>> the public aspects of web architecture are not the only
>> important ones - otherwise we wouldn't have https: and
>> access control at all.

This is interesting, but I don't see the relevance. We
should acknowledge that "secret URLs" are a common usage
pattern and that there are some situations where they will
do to accomplish some goal, even though that goal is not
"effective access control".

What I think constitutes an effective access control
mechanism is one in which those using the mechanism have a
clear understanding of the risks and a means of monitoring
and correcting failures.

But designers are often unaware of the exposure risks
involved in "secret URLs", and so the requirement of
understanding of risks is not met.

Further, password-based access control mechanisms often
allow measurement of the quality of guessability of
passwords, of detecting intrusions or intrusion attempts, of
correcting for past errors or intrusions by, for example,
locking accounts or changing passwords. Using secret URLs
don't have many of those advantages, and thus it is

> I'm at a bit of a loss how to put the argument on a
> rational footing.  One attempt to follow in subsequent
> email.

Looking forward to continued discussion.

> I'm hoping there is some significant nuance I have
> missed. If so, please point out which of the above
> statements is false and exactly why, so that I can engage
> with that part of the discussion.

I think there are significant nuances issed that I have
explained. I have pointed out some of the false statements
and why (although perhaps "exactly" is too demanding.)



Received on Saturday, 23 January 2010 19:20:01 UTC

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