Nabble - w3.org - www-talk

HTTP-MPLEX

2009-08-03T00:29:32Z

Dear Firefox, Squid, Apache and W3 communities,

Apologies for cross-posting, hopefully at the end of this email it will
be understood that it is not my intention to annoy people.

My recent PhD research focused on improving page and object retrieval
performance in the context of a congested network and a significant part
of this research was the development of HTTP-MPLEX. I would like to let
the word out about this protocol. The protocol is designed to improve
page and object retrieval time in bandwidth asymmetric (ADSL) network
environments, which are common in Australia. HTTP-MPLEX is based on HTTP
and is designed to be both transparent and backwards compatible.

At this time, all of my work on HTTP-MPLEX is in the public domain and
links to the individual publications are listed on my homepage [1]. Of
the documents available, the most current/up-to-date work is my PhD
thesis.

As my candidature is now over, I'm hoping that some value can be found
in this work by the Internet community.

Sincerely,
Rob Mattson

[1] - http://www.mattson.com.au/robert/index.php?Menu=Research

Please consider the environment - do you really need to print this
email?

Re: [VE][xmlwf] Can't understand this error-report

2009-07-17T00:24:14Z

what is the doctype, anyway?

are all these " the character quote? (word replace the quote by other
characters)

On Fri, Jul 17, 2009 at 12:51 AM, Erhard Baltrusch<erhard@...> wrote:

> Hi,
> when validating my travel report pages, the validator came up with the
> following errors:
>
> 1. XML Parsing Error: attributs construct error
> 2. XML Parsing Error: Couldn't find end of Start Tag img line...
>
> This maeeage appears for two data records that are aboslutely identically
> constrcuted. Following is the source code:
>
> -------------------------------------------------------------------
> <a href="../../fotos/10042006/USA/Newark2.JPG" target="_blank" title="New
> Jersey" > <img class="bildlinks"
> src="../../fotos/USA/10042006/thumbs/0006_RJ.jpg" border="0" alt="Newark2"
> /></a>
> ------------------------------------------------------------------
>

--
--
ℱin del ℳensaje.

[VE][xmlwf] Can't understand this error-report

2009-07-16T15:51:20Z

Hi,
when validating my travel report pages, the validator came up with the following errors:

1. XML Parsing Error: attributs construct error
2. XML Parsing Error: Couldn't find end of Start Tag img line...

This maeeage appears for two data records that are aboslutely identically constrcuted. Following is the source code:

-------------------------------------------------------------------
<a href="../../fotos/10042006/USA/Newark2.JPG" target="_blank" title="New Jersey" > <img class="bildlinks" src="../../fotos/USA/10042006/thumbs/0006_RJ.jpg" border="0" alt="Newark2" /></a>
------------------------------------------------------------------

Can anybody help me out, please?

THX,
Erhard

Error Response Code Question (Signaling required If-Match)

2009-06-21T14:05:07Z

Hi,

does anyone know the appropriate response code when a server wants the
client to use an If-Match header on a PUT request but the client did
not send one?

Thanks,
Jan

Re: Http 403 Error for W3 DTDs

2009-06-11T09:41:09Z

Mark Baker <mark@...> writes:

> On Thu, Jun 11, 2009 at 10:37 AM, Sumit Shah<Sumit.Shah@...> wrote:

>> Thank you for your response. Can you please suggest some alternative
>> approaches in the short term until we or the responsible application
>> mitigates this?
>>
>> These issues will impact our customers in production since we rely on
>> 3rd party open source applications that are causing this traffic.
>
> Since they're open source, fix them yourselves; the simplest, most
> generic approach would be to hard code the document that would
> normally be retrieved from w3.org. If you could submit that change as
> a patch back to the project too, that would be double-plus good.

Sumit,

Yes, as I mentioned earlier many software libraries and utilities have
catalog options which you should explore. If not you can put up a
caching proxy up in front of your application. There really is no need
to have it repeatedly request the same resource across the internet.
You should also find doing this the right way (wrt HTTP caching
directives or catalog) should dramatically improve performance.

>>> Many libraries have catalog or caching options and lacking that one can
>>> get a caching proxy in front of their application making repeated DTD
>>> requests.

Regards,

--
Ted Guild <ted@...>
W3C Systems Team
http://www.w3.org

Re: Http 403 Error for W3 DTDs

2009-06-11T08:19:22Z

On Thu, Jun 11, 2009 at 10:37 AM, Sumit Shah<Sumit.Shah@...> wrote:
> Hi Ted,
>
> Thank you for your response. Can you please suggest some alternative
> approaches in the short term until we or the responsible application
> mitigates this?
>
> These issues will impact our customers in production since we rely on
> 3rd party open source applications that are causing this traffic.

Since they're open source, fix them yourselves; the simplest, most
generic approach would be to hard code the document that would
normally be retrieved from w3.org. If you could submit that change as
a patch back to the project too, that would be double-plus good.

Mark.

RE: Http 403 Error for W3 DTDs

2009-06-11T07:37:02Z

Hi Ted,

Thank you for your response. Can you please suggest some alternative
approaches in the short term until we or the responsible application
mitigates this?

These issues will impact our customers in production since we rely on
3rd party open source applications that are causing this traffic.

Thanks
Sumit

-----Original Message-----
From: ted@... [mailto:ted@...]
Sent: Wednesday, June 10, 2009 6:31 PM
To: Sumit Shah
Cc: www-talk@...
Subject: Re: Http 403 Error for W3 DTDs

Sumit,

We are sending HTTP 503 and the content of the response also includes a
link which expands to an article giving more background on this issue.

http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic

In the last 16 months since writing that article we have only seen
this traffic increase and recently we are seeing surges in traffic
that we cannot keep up with, neither our automated defenses nor manual
intervention. Increasing server capacity sees the increased capacity
just getting consumed as well. This is rendering our site overwhelmed
and unresponsive for our working groups and the rest of the web
community.

> I was wondering if this is an isolated issue or something across the
> board. Is this something intentional that W3 has done to block DTD
> requests and is there a suggested fix for it?

About 1/4th of our DTD traffic (in the hundreds of millions/day) is from
Java so when trying to keep our site available yesterday responding 503
to this traffic was low hanging fruit. We will be monitoring this
traffic and see when we can be less dramatic in our defenses.

We have also identified another widely distributed application
responsible for a substantial portion of this traffic, the vendor has
acknowledged the issue and is working on a resolution which we hope
will be released soon.

Many libraries have catalog or caching options and lacking that one can
get a caching proxy in front of their application making repeated DTD
requests.

--
Ted Guild <ted@...>
W3C Systems Team
http://www.w3.org

Re: Http 403 Error for W3 DTDs

2009-06-10T15:30:30Z

Sumit,

We are sending HTTP 503 and the content of the response also includes a
link which expands to an article giving more background on this issue.

http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic

In the last 16 months since writing that article we have only seen
this traffic increase and recently we are seeing surges in traffic
that we cannot keep up with, neither our automated defenses nor manual
intervention. Increasing server capacity sees the increased capacity
just getting consumed as well. This is rendering our site overwhelmed
and unresponsive for our working groups and the rest of the web
community.

> I was wondering if this is an isolated issue or something across the
> board. Is this something intentional that W3 has done to block DTD
> requests and is there a suggested fix for it?

About 1/4th of our DTD traffic (in the hundreds of millions/day) is from
Java so when trying to keep our site available yesterday responding 503
to this traffic was low hanging fruit. We will be monitoring this
traffic and see when we can be less dramatic in our defenses.

We have also identified another widely distributed application
responsible for a substantial portion of this traffic, the vendor has
acknowledged the issue and is working on a resolution which we hope
will be released soon.

Many libraries have catalog or caching options and lacking that one can
get a caching proxy in front of their application making repeated DTD
requests.

--
Ted Guild <ted@...>
W3C Systems Team
http://www.w3.org

Http 403 Error for W3 DTDs

2009-06-10T10:32:42Z

Hello,

I am receiving a HTTP 403 error for some of the DTD files if invoked from a JAVA application trying to parse/resolve the WSDLs that reference the W3 DTDs.

DTD in question: http://www.w3.org/2001/datatypes.dtd

I was wondering if this is an isolated issue or something across the board. Is this something intentional that W3 has done to block DTD requests and is there a suggested fix for it?

Thanks

Sumit

NWeSP 2009 - AWIC 2009 Call for papers (final call, Prague)

2009-06-02T04:40:29Z

Dear Colleague,

The NWeSP/AWIC 2009 program committees invite you to contribute a
paper for the following conferences. If you need a special extension
for few days, please let Professor Dusan Husek (dusan@...) know
as soon as possible:

5th International Conference on Next Generation Web Services Practices
September 9-11, 2009
Prague, Czech Republic
http://arg.vsb.cz/NWeSP09/Default.aspx

6th Atlantic Web Intelligence Conference
September 9-11, 2009
Prague, Czech Republic
http://arg.vsb.cz/awic2009/Default.aspx

Important dates:
Paper Submission (Extended Deadline): June 5, 2009
Notification of acceptance: June 20, 2009
Camera-ready of accepted papers: June 30, 2009
Registration: June 30, 2009

Extended versions of papers will be considered for several
international journals. Please see conference web site for more
details.

Conference contact:
Dusan Husek
Institute of Computer Science
Academy of Sciences of the Czech Republic
Pod Vodarenskou vezi 2
182 07 Prague 8
Czech Republic
http://www.cs.cas.cz/dusan/
http://www.nnw.cz
Phone: (+420 ) 26605 3230
Mob: (+420 ) 603 4444 71
Fax: (+420 ) 28658 5789

Wrong list (was: UTF-8 vs CDATA)

2009-06-01T08:06:57Z

Oops, I didn't mean to send that to www-talk...

Magnus

UTF-8 vs CDATA

2009-06-01T07:47:05Z

Xingdong and I just had an interesting battle with Erlang Web that
deserves to be documented... :)

We have a record, one of whose fields uses a custom wtype that outputs a
piece of Javascript to render its control. It worked as long as we only
used ASCII text; with Unicode text it would fail, passing UTF-32 to
erlang:iolist_size inside e_mod_inets:controller_exec. Obviously
something was failing to convert Xmerl's UTF-32 representation to the
UTF-8 that the external world uses.

After an hour of debugging, we realized that the problem was caused by
the <script> tag contents being wrapped in a CDATA section:

<script>
//<![CDATA[
...lots of javascript
//]]>
</script>

Because of this, Xmerl's parser would return an xmlText record with
type = cdata, and this triggers Erlang Web's special (non)treatment of
the text - and it was not translated. Removing the CDATA marker fixed
the problem.

(Incidentally, this is OK since Erlang Web serves XHTML files as HTML,
where the contents of <script> tags are implicitly CDATA.)

So consider this a vote to change 'type = cdata' to 'type =
erlang_web_passthrough' for the special meaning. That way it stands
less chance of interfering with proper usage of XML. :)

--
Magnus Henoch, magnus@...
Erlang Training and Consulting
http://www.erlang-consulting.com/

Last call on papers - Shangai10''0'Noo

2009-05-25T02:35:53Z

HTML "CLOCKER" - concept of a new web control

Part I

I've been thinking about a new HTML feature that clould bring all sorts of new features to the web.
Imagine clock, a watch, that has just the seconds-handle.
A very simple clock, isn't it? How would you say such an object in terms of its structure?
Well, will try to answer that.
But for now, and for that matter, let's try to understand what could be meant by saying that
something 'has a progression of 1-2-5' ?
Or even, 'with a progression 1-2-5-7', instead?
Can you start to see the difference between these two such "clocker" web controls?

I am introducing you to a new concept or feature, for the W3 consideration - using a sequence of natural numbers (I suppose
you could have negative numbers and all others featured in such of a progression, using a proper validator for that matter)
as a seed for a process within a stocastics. For that matter, being followed or not by a zero-0 would be important integrating
part of such stocastics at sake.

Here, our seed, of integers followed by the zero would mean that that "clock" or "clocker", if you will, would never stop, that is, it would be that seed sequence in loop,
repeating itself 'ad infinitum'.

Proprieties of such "clocker" control would be concerned with how and in what form it would then be displayed or be showing there.

Attaching an image to it, for instance, an animated gif I suppose, of a one minute round of a seconds-handle of one such watch. See?

To have it displayed we would have then, such of a code:

OK. Now, let's want to have more than just a loop out of a set of seeds, and so we might have an integers sequence before the last zero, above.
Remember that such zero is indicating important stochastics information, the repetition or not, if or not in a loop, of my sequence.

The interesting thin here is that this clock can be out of time, that is, it may not even be time-related.

And so, one would have to indicate with what would the seed be concerned or not with, that is, it's values, right?
Would it relate to seconds, minutes, days, units of processing power at sake, or some other data from which the machine or platform might be
being feed and provided to take into its consideration.
Like, let's say, the actual temperature (in centigrade) in Athens.
I suppose having it in Fahrenheit units into our considerations would not be that of a problem by then, would it? Isn't it the same temperature, after all?!

So basically, you could have your clocker in charge of three other ones to control if the temperature in Athens was either, say, 3, 5 or 34 degrees Celsius.

And so, there you could have it as a clock that is showing the seconds-handle of a watch if the temperature is 3, the minutes-handle if the temperature was 5 and, right,
the hours-handle for when the temperature in Athens was above that.

There it goes this time, then:

3
5
34
</CLOCKER>

I suppose, you have by now, realised the potential of such of a feature as to revolutionise the web.

Still, I have one open question : what would it be to have one or more clockers ones into the others?
Would in any sense to nest clockers such a way make any sense?

Basically the clocker would be running and checking all the time in the sequence given when has there been change from the previous state.
But what previous state? You may ask: what are we talking about?

We have indeed this tendency to think that the difference between each two in a pair, for instance, between, 2 and 7, 5 and 8, followed by 10 and 20, is,
10 and 20, is accordingly and for that matter: 5, 3, 10.

But are them, is it?
Yes, if by their difference I mean the sortest distance each two, or the quantity expressing the shortest way to order them in sequence,
but what if I mean, for instance, how many prime numbers are there between the two. You see, then that difference would not hold 5 for the first pair given, and 3 and 10 for the other two pairs.

Between 2 and 7 there are two primes; between 5 and 8, just one; and between 10 and 20 there are less than ten primes, you can be pretty sure.

So the mentioned difference between each two would hold on something like, 2 5 and ... something else I am now not knowing but that must be less than 10 as I am saying.
Four primes, to be more precise.
11, 13, 17 and 19: right?!

And so instead of our initial 5,3,10 sequence the one meant would have been 2-1-4, right?
So the difference from the "before" is one quantity to consider; the other one to consider is that one of the "next".

And interestingly we can then have an unborn difference out of these two that results to be either from the "old" or from the "new":
the so called 'third state', with which we can have a difference meant between these two quantities.
That latter one being the result of clockers itself.

              Done!

Part II

Let's suppose the way the interact with the quantities within a sequence - the one of the "before" and the one of the "after" is with mouse clicks so that clicking after the first click may express two integer quantites.
For instance, a cartesian coordinate system or a vectorial representation.
And herein we could have a clocker have us within a very long integer sequence checking for instance that the first and second quantities expressed by any two clicks are or not within that sequence and so being within or if out of the sequence.

While any two mouse clicks were expressing two designated differences within its sequence.

I definitely can see a lot of potential in whole this area of study and development.

As an exercise we could think for instance how we would refresh the body of one of our HTML pages after one minute followed by being refreshed after one hour time using this "clockers" that have now been introduced with an HTML code example of mine,
And so, making then the current use of metatag for that a bit deprecated or old-fashioned.
Another one, use it to structure layouts in new and revolutionary manners, as positioning elements, as such structures would then be allowing you to control other elements in real-time and accordingly whatever taken into consideration by that computer or platform things like changing percentages of any two elements positions to each others in terms of percentages.

Or, even maybe, how to use the web to maximize meaning, if there is any out there!!!

Regards,
Daniel Alexandre
BEng Student@...

"To be more or less" - The Great M.C

to make any formal comments on

Shangai 2010 submit paper request before January, the 10th of 2010.

You may have then your place at an exhibition.

Submit to: bicomplex@...
--
When you sow a thought you reap an action, when you sow an action you reap a habit, when you sow a habit you reap a character and when you sow a character you reap a destiny. Thoughts are like seeds. You cannot sow the seed of one plant and get another: thistles will never produce daffodils! When your thoughts are positive, powerful and constructive, your life will reflect this.

Online Training Course: An Introduction to W3C's Mobile Web Best Practices 1 June – 31 July 2009

2009-05-15T07:04:41Z

Online Training Course: An Introduction to W3C's Mobile Web Best
Practices 1 June – 31 July 2009

W3C is running an extended and improved version of its online course to
introduce Web developers and designers to its Mobile Web Best Practices.

In this course you will:
* learn about the specific promises and challenges of the mobile
platform;
* learn how to use W3C's Mobile Web Best Practices to design
mobile-friendly Web content and to adapt existing content for mobile;
* discover the relevant W3C resources for mobile Web design.

As a participant, you will have access to lectures and assignments that
provide hands-on practical experience of using W3C's mobile Web Best
Practices. You will have direct access to W3C experts on this topic who
are the instructors for this course, and you'll be able to discuss and
share experiences with your peers who are faced with the challenges of
mobile Web design.

For more information including details of the course material, more
about who will benefit most from the course, the registration fee and
access to a free sample of the course itself, please visit
http://www.w3.org/2009/04/MobiWeb102/.

--

Phil Archer
W3C Mobile Web Initiative
http://www.w3.org/Mobile/
http://philarcher.org/

CSWWS'09: Call for Participation

2009-05-13T20:17:30Z

Dear All,

CSWWS 2009, The Second Canadian Semantic Web Working Symposium, will be held in Kelowna, British Columbia (May 24, 2009). This symposium is associated with the 22nd Canadian Conference on Artificial Intelligence. You can view the program at

http://isel.cs.unb.ca/~cswwc09/cswwc09/public/conferences/3/schedConfs/2/program.pdf

We will have a full day program on Sunday, May 24th, with 14 technical papers and 2
keynote/invited talks.

Thanks again.

Best regards,

Faezeh Ensan
CSWWS09 Program Organizer
University of New Brunswick, Canada

HTML "CLOCKER" - concept of a new web control

2009-05-11T15:17:40Z

HTML "CLOCKER" - concept of a new web control

Part I

Proprieties of such "clocker" control would be concerned with how and in what form it would then be displayed or be showing there.

Attaching an image to it, for instance, an animated gif I suppose, of a one minute round of a seconds-handle of one such watch. See?

To have it displayed we would have then, such of a code:

The interesting thin here is that this clock can be out of time, that is, it may not even be time-related.

So basically, you could have your clocker in charge of three other ones to control if the temperature in Athens was either, say, 3, 5 or 34 degrees Celsius.

There it goes this time, then:

3
5
34
</CLOCKER>

I suppose, you have by now, realised the potential of such of a feature as to revolutionise the web.

Still, I have one open question : what would it be to have one or more clockers ones into the others?
Would in any sense to nest clockers such a way make any sense?

Between 2 and 7 there are two primes; between 5 and 8, just one; and between 10 and 20 there are less than ten primes, you can be pretty sure.

While any two mouse clicks were expressing two designated differences within its sequence.

I definitely can see a lot of potential in whole this area of study and development.

Or, even maybe, how to use the web to maximize meaning, if there is any out there!!!

Regards,
Daniel Alexandre
BEng Student@...

"To be more or less" - The Great M.C

Fwd: Questions on the Origin of BLOCKQUOTE

2009-05-02T09:09:48Z

Whoops, meant to send this to www-talk for fun too:

---------- Forwarded message ----------
From: Sean B. Palmer <sean@...>
Date: Sat, May 2, 2009 at 5:06 PM
Subject: Questions on the Origin of BLOCKQUOTE
To: Dan Connolly <connolly@...>
Cc: www-html <www-html@...>

Hi Dan,

I'm investigating why BLOCKQUOTE was introduced to HTML. The two
earliest mentions of the element occur in a message and a document by
you:

(1)

“I'm trying to keep up with all sorts of HTML ideas. Some things can be
added to html.dtd without significant changes to W3 code (like adding a
BLOCKQUOTE tag for a new paragraph style). But for things that will
require changes to the architecture, I'm developing a separate DTD from
the descriptive html.dtd.”

— http://lists.w3.org/Archives/Public/www-talk/1992NovDec/0159
Re: The spec evolves...
Dan Connolly (connolly@...)
Fri, 04 Dec 92 18:07:49 CST

(2)

<!ENTITY % bodyelement
"P | A | %heading |
%list | DL | HEADERS | ADDRESS | PRE | BLOCKQUOTE
| %literal">

— http://suika.fam.cx/gate/cvs/*checkout*/test/html.dtd?rev=1.3
Document Type Definition for the HyperText Markup Language
as used by the World Wide Web application (HTML DTD).
$Id: html.dtd,v 1.3 1993/01/07 00:38:36 connolly Exp $

Revision 1.2 of html.dtd dates to 1.2 1992/12/03, the day before the
message just quoted at (1), where it seems that you were trying to
keep up with suggestions for changes to HTML, and that BLOCKQUOTE was
one of those suggestions. On 7th January 1993, you checked in the new
html.dtd with BLOCKQUOTE included (2).

Neither of these mentions, however, reveal who suggested BLOCKQUOTE
and why. Was there any discussion surrounding its inclusion? What did
TimBL and others think of it? And how fast was W3 code updated? Why
was BLOCKQUOTE included whereas, perhaps, other suggestions fell by
the wayside?

What I'm trying to understand is how BLOCKQUOTE came to be included,
partially in order to better understand why and how it should be used
now. For example, one could easily have eschewed BLOCKQUOTE in favour
of usual typographical conventions:

<p>“First quoted paragraph.</p>
<p>“Second quoted paragraph.”</p>

An argument against this now is that BLOCKQUOTE gives you independence
of styling. Independence of styling was, however, not an option in
late 1992 when CSS was yet to be invented. Indeed, there are even
potential signs that BLOCKQUOTE did not win favour with users very
early on. In May 1993, Dave Raggett was asking whether people were
actually using the element:

“I am drafting an extended verion of the HTML standard and would
like to know if anyone is using the <BLOCKQUOTE> element for quoted
paragraphs. This element has a name greater than 8 characters
which could cause problems with some SGML parsers.”

— http://1997.webhistory.org/www.lists/www-talk.1993q2/0269.html

He suggested renaming it to QUOTE, and after apparently receiving no
reply on www-talk he actually called it BQ in HTML 3:

http://www.w3.org/MarkUp/html3/blockquotes.html

But then in HTML 3.2 it was back to BLOCKQUOTE, perhaps because by
this point there was an established user base and the SGML 8 character
problem had either been fixed, a workaround found, or was deemed
irrelevent:

http://www.w3.org/TR/REC-html32#bq

My suspicion is that BLOCKQUOTE follows the pattern of other early
elements, which try to introduce some level of independence from
style, giving a few suggestions as to how user agents may render it,
whilst still trying to provide a kind of reasonably well understood
meaning. Consider, for example, what HTML 2 says about BLOCKQUOTE:

“A typical rendering might be a slight extra left and right indent,
and/or italic font. The BLOCKQUOTE typically provides space above and
below the quote.

“Single-font rendition may reflect the quotation style of Internet
mail by putting a vertical line of graphic characters, such as the
greater than symbol (>), in the left margin.”

— http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.5.4

Indentation was perhaps not available using any other element, but <I>
and <EM> were added to html.dtd v.1.2 along with BLOCKQUOTE, so those
at least could have been used instead for one of the suggested
renderings. The meaning of the element and the diversity of possible
stylings seems quite likely to have been important at that stage.

This original prominent approach to element design seems to have
fallen by the wayside due to consensus of styling amongst user agents
narrowing the diversity with which an element is styled. So with
BLOCKQUOTE, it came to be associated in authors' minds with
indentation rather than its meaning as an extended quotation: by HTML
4.01, there is a warning in the specification that people are using it
merely for indentational formatting with non-quotation semantics.

At any rate, much of this research is speculation, filling in the dots
between a few scant references in the record. Even if the dots are
filled in correctly, there may be extra rationale that I've missed. I
was hoping therefore that you might be able to piece together some
more information given your clearly very central involvement in the
subject.

Kindest regards,

--
Sean B. Palmer, http://inamidst.com/sbp/

Re: HTTP proxy vs client identity

2009-03-20T19:01:15Z

Yes, it can, but many/most proxies do not do this in practice, because
of pipelining bugs in servers (if they get responses out of order,
it's a bad security problem) and because you don't know how long the
first response will take before the second will start coming back.

It's more common IME for proxies to reuse idle connections left over
from other clients.

Hope this helps,

P.S., Questions like this are appropriate for the HTTPbis list;
http://lists.w3.org/Archives/Public/ietf-http-wg/

On 19/03/2009, at 8:45 AM, Magnus Henoch wrote:

> Hi,
>
> I'm writing an HTTP proxy. Thus I'm thinking about an interesting
> protocol question: if two clients each send a request through the same
> proxy to the same origin server, is the proxy allowed to open a single
> connection to the origin server, and forward the two requests by
> pipelining? I imagine that a server might consider the two requests
> to
> come from the same client, as they arrived by the same connection.
>
> As far as I can tell from the HTTP 1.1 spec, a server may not make
> such
> an assumption. Is that correct? Are there examples of servers that
> do
> that anyway?
>
> --
> Magnus Henoch, magnus@...
> Erlang Training and Consulting
> http://www.erlang-consulting.com/
>
>
>

--
Mark Nottingham http://www.mnot.net/

HTTP proxy vs client identity

2009-03-19T08:45:27Z

Hi,

I'm writing an HTTP proxy. Thus I'm thinking about an interesting
protocol question: if two clients each send a request through the same
proxy to the same origin server, is the proxy allowed to open a single
connection to the origin server, and forward the two requests by
pipelining? I imagine that a server might consider the two requests to
come from the same client, as they arrived by the same connection.

As far as I can tell from the HTTP 1.1 spec, a server may not make such
an assumption. Is that correct? Are there examples of servers that do
that anyway?

--
Magnus Henoch, magnus@...
Erlang Training and Consulting
http://www.erlang-consulting.com/

Re: FW: I-D Action:draft-hammer-discovery-02.txt

2009-03-05T09:01:31Z

Minor nit: the Link-Pattern examples throughout the spec don't have semicolons before link parameters, while the syntax definition in Section 6 requires them. To be consistent with the syntax of Link:s I would think that the syntax definition is right, and the examples are wrong.

Dirk.

On Thu, Feb 12, 2009 at 11:18 PM, Eran Hammer-Lahav <eran@...> wrote:

Please discuss on the www-talk@... list.

For those who have read previous revisions (thanks!), please note that except for Appendix B, the rest of the spec was significantly changed and a fresh read is recommended.

Thanks,

EHL

------ Forwarded Message

From: <Internet-Drafts@...>
Reply-To: <internet-drafts@...>
Date: Fri, 13 Feb 2009 00:15:02 -0700
To: <i-d-announce@...>
Subject: I-D Action:draft-hammer-discovery-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Link-based Resource Descriptor Discovery
        Author(s)       : E. Hammer-Lahav
        Filename        : draft-hammer-discovery-02.txt
        Pages           : 25
        Date            : 2009-02-12

This memo describes a process for obtaining information about a
resource identified by a URI. The 'information about a resource', a
resource descriptor, provides machine-readable information that aims
to increase interoperability and enhance the interaction with the
resource. This memo only defines the process for locating and
obtaining the descriptor, but leaves the descriptor format and its
interpretation out of scope.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hammer-discovery-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------ End of Forwarded Message

RE: I-D Action:draft-hammer-discovery-02.txt

2009-03-04T23:03:57Z

This is addressed in section 3:

---
To promote interoperability, applications referencing this memo
SHOULD clearly define the application-specific criteria used to
select between "describedby" links. This MAY be done by:

o Supporting a single descriptor format, or defining an order of
precedence for multiple descriptor formats. Applications MAY
require the presence of the link "type" attribute with the mime-
type of the required format.

o Using the "describedby" relation type together with another
application-specific relation type in the same link. The
application-specific relation type can be registered or an
extension.

o Specifying additional link attributes using link-extensions.
---

EHL

> -----Original Message-----
> From: Jonathan Rees [mailto:jar@...]
> Sent: Wednesday, March 04, 2009 10:40 PM
> To: Eran Hammer-Lahav
> Cc: www-talk@...; www-tag@... WG
> Subject: Re: I-D Action:draft-hammer-discovery-02.txt
>
> What if a single resource needs description resources that are
> consumed by different applications, but there is no way to combine the
> two DRs into one document, and they cannot be distinguished by media
> type?
>
> Not a problem if the DRs use RDF, but you are not limiting DRs to RDF.
>
> Registering a new media type for each application is not practical.
>
> Perhaps you could parameterize DRD by the link relation - that is,
> where you now say "describedby", put a variable that takes on a
> different value for each application. Then you could use one link
> relation for A (POWDER) and another for B (XRD).
>
> The link-extension feature of Link: (and link-pattern?) might also
> help here, although I'm not sure how that would work with <link>.
>
> Jonathan
>
> (TAG ISSUE-62)
>
>
> On Feb 12, 2009, at 11:18 PM, Eran Hammer-Lahav wrote:
>
> > Please discuss on the www-talk@... list.
> >
> > For those who have read previous revisions (thanks!), please note
> > that except for Appendix B, the rest of the spec was significantly
> > changed and a fresh read is recommended.
> >
> > Thanks,
> >
> > EHL
> >
> >
> > ------ Forwarded Message
> > From: <Internet-Drafts@...>
> > Reply-To: <internet-drafts@...>
> > Date: Fri, 13 Feb 2009 00:15:02 -0700
> > To: <i-d-announce@...>
> > Subject: I-D Action:draft-hammer-discovery-02.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> > Title : Link-based Resource Descriptor Discovery
> > Author(s) : E. Hammer-Lahav
> > Filename : draft-hammer-discovery-02.txt
> > Pages : 25
> > Date : 2009-02-12
> >
> > This memo describes a process for obtaining information about a
> > resource identified by a URI. The 'information about a resource', a
> > resource descriptor, provides machine-readable information that aims
> > to increase interoperability and enhance the interaction with the
> > resource. This memo only defines the process for locating and
> > obtaining the descriptor, but leaves the descriptor format and its
> > interpretation out of scope.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-hammer-discovery-02.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
> > ------ End of Forwarded Message
> > <ATT00001.txt>

Re: I-D Action:draft-hammer-discovery-02.txt

2009-03-04T22:39:47Z

What if a single resource needs description resources that are
consumed by different applications, but there is no way to combine the
two DRs into one document, and they cannot be distinguished by media
type?

Not a problem if the DRs use RDF, but you are not limiting DRs to RDF.

Registering a new media type for each application is not practical.

Perhaps you could parameterize DRD by the link relation - that is,
where you now say "describedby", put a variable that takes on a
different value for each application. Then you could use one link
relation for A (POWDER) and another for B (XRD).

The link-extension feature of Link: (and link-pattern?) might also
help here, although I'm not sure how that would work with <link>.

Jonathan

(TAG ISSUE-62)

On Feb 12, 2009, at 11:18 PM, Eran Hammer-Lahav wrote:

> Please discuss on the www-talk@... list.
>
> For those who have read previous revisions (thanks!), please note
> that except for Appendix B, the rest of the spec was significantly
> changed and a fresh read is recommended.
>
> Thanks,
>
> EHL
>
>
> ------ Forwarded Message
> From: <Internet-Drafts@...>
> Reply-To: <internet-drafts@...>
> Date: Fri, 13 Feb 2009 00:15:02 -0700
> To: <i-d-announce@...>
> Subject: I-D Action:draft-hammer-discovery-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : Link-based Resource Descriptor Discovery
> Author(s) : E. Hammer-Lahav
> Filename : draft-hammer-discovery-02.txt
> Pages : 25
> Date : 2009-02-12
>
> This memo describes a process for obtaining information about a
> resource identified by a URI. The 'information about a resource', a
> resource descriptor, provides machine-readable information that aims
> to increase interoperability and enhance the interaction with the
> resource. This memo only defines the process for locating and
> obtaining the descriptor, but leaves the descriptor format and its
> interpretation out of scope.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hammer-discovery-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> ------ End of Forwarded Message
> <ATT00001.txt>

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-24T09:07:02Z

Since XRD is maybe the first security-sensitive application to depend on this proposed spec, I think it is appropriate that it work as a laboratory for the signature-based approach.

On Tue, Feb 24, 2009 at 8:23 AM, Eran Hammer-Lahav <eran@...> wrote:

It will, if extended to host-meta (it is currently discussed for XRD documents), but either way will not be part of the host-meta spec.

EHL

> -----Original Message-----
> From: Ben Laurie [mailto:benl@...]
> Sent: Tuesday, February 24, 2009 1:55 AM
> To: Adam Barth
> Cc: Mark Nottingham; Eran Hammer-Lahav; www-talk@...
> Subject: Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-
> meta-01)
>

> On Mon, Feb 23, 2009 at 5:32 PM, Adam Barth <w3c@...> wrote:
> > On Mon, Feb 23, 2009 at 5:38 AM, Ben Laurie <benl@...> wrote:
> >> I don't see why - if www.us.example.com chooses to delegate to
> >> www.hq.example.com, that that is its affair, not ours, surely?
> >
> > Following redirects is insecure for sites that let users configure
> redirects.
> >
> > Every time you trade away security like this, you make it more likely
> > that host-meta will be unusable for secure metadata. If host-meta is
> > unsuitable for secure metadata, folks that require security will just
> > work around host-meta by creating a "secure-meta." I can't tell you
> > which of the security compromises will cause this to happen.
> Security
> > is often a "death of a thousand paper cuts" that eventually add up to
> > you being owned.
>
> I thought signing was supposed to deal with the issues around
> redirects?

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

RE: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-24T08:23:03Z

It will, if extended to host-meta (it is currently discussed for XRD documents), but either way will not be part of the host-meta spec.

EHL

> -----Original Message-----
> From: Ben Laurie [mailto:benl@...]
> Sent: Tuesday, February 24, 2009 1:55 AM
> To: Adam Barth
> Cc: Mark Nottingham; Eran Hammer-Lahav; www-talk@...
> Subject: Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-
> meta-01)
>
> On Mon, Feb 23, 2009 at 5:32 PM, Adam Barth <w3c@...> wrote:
> > On Mon, Feb 23, 2009 at 5:38 AM, Ben Laurie <benl@...> wrote:
> >> I don't see why - if www.us.example.com chooses to delegate to
> >> www.hq.example.com, that that is its affair, not ours, surely?
> >
> > Following redirects is insecure for sites that let users configure
> redirects.
> >
> > Every time you trade away security like this, you make it more likely
> > that host-meta will be unusable for secure metadata. If host-meta is
> > unsuitable for secure metadata, folks that require security will just
> > work around host-meta by creating a "secure-meta." I can't tell you
> > which of the security compromises will cause this to happen.
> Security
> > is often a "death of a thousand paper cuts" that eventually add up to
> > you being owned.
>
> I thought signing was supposed to deal with the issues around
> redirects?

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-24T01:54:34Z

On Mon, Feb 23, 2009 at 5:32 PM, Adam Barth <w3c@...> wrote:

> On Mon, Feb 23, 2009 at 5:38 AM, Ben Laurie <benl@...> wrote:
>> I don't see why - if www.us.example.com chooses to delegate to
>> www.hq.example.com, that that is its affair, not ours, surely?
>
> Following redirects is insecure for sites that let users configure redirects.
>
> Every time you trade away security like this, you make it more likely
> that host-meta will be unusable for secure metadata. If host-meta is
> unsuitable for secure metadata, folks that require security will just
> work around host-meta by creating a "secure-meta." I can't tell you
> which of the security compromises will cause this to happen. Security
> is often a "death of a thousand paper cuts" that eventually add up to
> you being owned.

I thought signing was supposed to deal with the issues around redirects?

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T16:40:05Z

On Mon, Feb 23, 2009 at 3:48 PM, Adam Barth <w3c@...> wrote:

On Mon, Feb 23, 2009 at 3:05 PM, Breno de Medeiros <breno@...> wrote:
> crossdomain.xml was introduce to support a few specific applications
> (notably flash), and it did not take into account the security requirements
> of the application context. Tough.

I'm suggesting we learn from their mistakes instead of making the same
mistakes ourselves.

I am saying that we do not have the application context here because this spec is generic.

> Because at this point there is no consensus what a general delegation
> mechanism would look like. Quite possibly, this might be
> application-specific.

Why not handle delegation at the application layer instead of using
HTTP redirects for delegation?

I am not saying that HTTP redirects are the same as delegation. I think to treat them on the same level is a mistake. An application can decide whether to follow a redirect or not based on its security model. For applications that expect signed content, the only delegation happens via signatures, and following HTTP redirects is a transport event that has nothing to do with delegation.

> The alternative is to write a spec that
> introduces complexity to solve problems that we conjecture might exist in
> yet-to-be-developed applications. The risk then is that the spec will not
> see adoption, or that implementors will deploy partial spec compliance in
> ad-hoc fashion, which is also a danger to interoperability.

Great. Let's remove the complexity of following redirects.

Or, from another point-of-view: Let's introduce restrictions on the spec based on anticipated threats against non-existing applications.

However, I am tired of this argument. You haven't produced anything that convinces me there is a need to be addressed here, and I have not managed to convince you that this should be left to be specified when applications are developed that show clear usage patterns to justify what is and what is not, an acceptable restriction to be placed on the spec at a generic level.

My vote is that I think the spec is better left as is. Your vote is also understood. See you in a future thread ...

Adam

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T15:48:17Z

On Mon, Feb 23, 2009 at 3:05 PM, Breno de Medeiros <breno@...> wrote:
> crossdomain.xml was introduce to support a few specific applications
> (notably flash), and it did not take into account the security requirements
> of the application context. Tough.

I'm suggesting we learn from their mistakes instead of making the same
mistakes ourselves.

> Because at this point there is no consensus what a general delegation
> mechanism would look like. Quite possibly, this might be
> application-specific.

Why not handle delegation at the application layer instead of using
HTTP redirects for delegation?

> The alternative is to write a spec that
> introduces complexity to solve problems that we conjecture might exist in
> yet-to-be-developed applications. The risk then is that the spec will not
> see adoption, or that implementors will deploy partial spec compliance in
> ad-hoc fashion, which is also a danger to interoperability.

Great. Let's remove the complexity of following redirects.

Adam

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T15:05:01Z

On Mon, Feb 23, 2009 at 2:23 PM, Adam Barth <w3c@...> wrote:

On Mon, Feb 23, 2009 at 2:07 PM, Mark Nottingham <mnot@...> wrote:
> To me, what's interesting here is that the problems you're illustrating have
> never been an issue AFAIK with robots.txt,

I recently reviewed a security paper that measured whether consumers
of robots.txt follow redirects. I'm not sure if their results are
public yet, but some consumers followed redirects but others don't,
causing interoperability problems.

> and they didn't even come up as a
> concern during the discussions of P3P. I wasn't there for sitemaps, but
> AFAICT they've been deployed without the risk of unauthorised control of
> URIs being mentioned.

That just means they aren't interesting enough targets for attackers.
For high-stakes metadata repositories, like crossdomain.xml, you find
that people don't follow redirects. If I recall correctly,
crossdomain.xml started off allowing redirects but had to break
backwards compatibility to stop sites from getting hacked.

crossdomain.xml was introduce to support a few specific applications (notably flash), and it did not take into account the security requirements of the application context. Tough.

> I think the reason for this is that once the mechanism gets deployment, site
> operators are aware of the import of allowing control of this URL, and take
> steps to assure that it isn't allowed if it's going to cause a problem.

This is a terrible approach to security. We shouldn't make it even
harder to deploy a secure Web server by introducing more landmines
that you have to avoid stepping on.

> They haven't done that yet in this case (and thus you were able to get
> /host-meta) because this isn't deployed -- or even useful -- yet.

TinyURL doesn't appear to let me create a redirect with a "." in the
name, stopping me from creating a fake robots.txt or crossdomain.xml
metadata store. Similar to how MySpace and Twitter didn't let me make
a profile with a "-" in the name, I wouldn't hang my hat on this for
security.

> I would agree that this is not a perfectly secure solution, but I do think
> it's good enough.

The net result is that most people aren't going to use host-meta for
security-sensitive metadata. The interoperability cost will be too
high.

Why not introduce a proper delegation mechanism instead of re-using
HTTP redirects? That would let you address the delegation use case
without the security issue.

Because at this point there is no consensus what a general delegation mechanism would look like. Quite possibly, this might be application-specific. It is probably a better idea to see how this plays out, how useful people find it to be, and if there are generic concerns that can be addressed in a spec. The alternative is to write a spec that introduces complexity to solve problems that we conjecture might exist in yet-to-be-developed applications. The risk then is that the spec will not see adoption, or that implementors will deploy partial spec compliance in ad-hoc fashion, which is also a danger to interoperability.

> Of course, a mention in security considerations is worthwhile.

Indeed.

Adam

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T14:23:55Z

On Mon, Feb 23, 2009 at 2:07 PM, Mark Nottingham <mnot@...> wrote:
> To me, what's interesting here is that the problems you're illustrating have
> never been an issue AFAIK with robots.txt,

I recently reviewed a security paper that measured whether consumers
of robots.txt follow redirects. I'm not sure if their results are
public yet, but some consumers followed redirects but others don't,
causing interoperability problems.

> and they didn't even come up as a
> concern during the discussions of P3P. I wasn't there for sitemaps, but
> AFAICT they've been deployed without the risk of unauthorised control of
> URIs being mentioned.

That just means they aren't interesting enough targets for attackers.
For high-stakes metadata repositories, like crossdomain.xml, you find
that people don't follow redirects. If I recall correctly,
crossdomain.xml started off allowing redirects but had to break
backwards compatibility to stop sites from getting hacked.

> I think the reason for this is that once the mechanism gets deployment, site
> operators are aware of the import of allowing control of this URL, and take
> steps to assure that it isn't allowed if it's going to cause a problem.

This is a terrible approach to security. We shouldn't make it even
harder to deploy a secure Web server by introducing more landmines
that you have to avoid stepping on.

> They haven't done that yet in this case (and thus you were able to get
> /host-meta) because this isn't deployed -- or even useful -- yet.

TinyURL doesn't appear to let me create a redirect with a "." in the
name, stopping me from creating a fake robots.txt or crossdomain.xml
metadata store. Similar to how MySpace and Twitter didn't let me make
a profile with a "-" in the name, I wouldn't hang my hat on this for
security.

> I would agree that this is not a perfectly secure solution, but I do think
> it's good enough.

The net result is that most people aren't going to use host-meta for
security-sensitive metadata. The interoperability cost will be too
high.

Why not introduce a proper delegation mechanism instead of re-using
HTTP redirects? That would let you address the delegation use case
without the security issue.

> Of course, a mention in security considerations is worthwhile.

Indeed.

Adam

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T14:07:27Z

Adam,

To me, what's interesting here is that the problems you're
illustrating have never been an issue AFAIK with robots.txt, and they
didn't even come up as a concern during the discussions of P3P. I
wasn't there for sitemaps, but AFAICT they've been deployed without
the risk of unauthorised control of URIs being mentioned.

I think the reason for this is that once the mechanism gets
deployment, site operators are aware of the import of allowing control
of this URL, and take steps to assure that it isn't allowed if it's
going to cause a problem. They haven't done that yet in this case (and
thus you were able to get /host-meta) because this isn't deployed --
or even useful -- yet.

I would agree that this is not a perfectly secure solution, but I do
think it's good enough.

Of course, a mention in security considerations is worthwhile.

Cheers,

On 24/02/2009, at 8:21 AM, Adam Barth wrote:

> On Mon, Feb 23, 2009 at 1:04 PM, Breno de Medeiros
> <breno@...> wrote:
>> No, it does not. It does introduce vulnerabilities to clients that
>> visit
>> tinyurl.com with the expectation that they will interpret some
>> metadata at
>> tinyurl.com to achieve specific aims.
>
> You're right: someone has to use host-meta for something for this
> attack to work.
>
>> Simply substituting tinyurl.com's
>> host-meta affects no one until tinyurl.com starts exposing some
>> type of
>> service or application that client apps might want to configure/
>> discover
>> using host-meta.
>
> By owning their host-meta, I can opt them into whatever services use
> host-meta for discovery.
>
> Are you really saying that you don't care that I own their host-meta
> file?
>
>> As for your example of default charsets, where you are using a
>> browser to
>> define a generic interpretation of how to use host-meta to discover
>> default
>> charsets, it sounds like such API would need to be designed as:
>>
>> getHostMetaValue(URL resource_url, String host_meta_key, boolean
>> isAllowedToFollowRedirects)
>>
>> which hardly sounds to me like a burden.
>
> Don't forget mime types!
>
> String getHostMetaValue(URL resource_url, String host_meta_key,
> Boolean is_allowed_to_follow_redirects, Boolean
> require_strict_mime_type_processing)
>
> What about paper cut #37?
>
> String getHostMetaValue(URL resource_url, String host_meta_key,
> Boolean is_allowed_to_follow_redirects, Boolean
> require_strict_mime_type_processing, Boolean opt_out_of_paper_cut_37)
>
> That's the path to madness.
>
> Adam

--
Mark Nottingham http://www.mnot.net/

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T14:03:48Z

On Mon, Feb 23, 2009 at 1:48 PM, Breno de Medeiros <breno@...> wrote:
> An application would have to use host-meta for a particular aim (e.g., a
> browser discovering default charsets) and implement the spec blindly without
> regard to security considerations.

Just because we can pass the buck to application-land doesn't mean we
should write a spec full of security land mines.

Adam

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T13:48:49Z

On Mon, Feb 23, 2009 at 1:21 PM, Adam Barth <w3c@...> wrote:

On Mon, Feb 23, 2009 at 1:04 PM, Breno de Medeiros <breno@...> wrote:
> No, it does not. It does introduce vulnerabilities to clients that visit
> tinyurl.com with the expectation that they will interpret some metadata at
> tinyurl.com to achieve specific aims.

You're right: someone has to use host-meta for something for this
attack to work.

An application would have to use host-meta for a particular aim (e.g., a browser discovering default charsets) and implement the spec blindly without regard to security considerations.

> Simply substituting tinyurl.com's
> host-meta affects no one until tinyurl.com starts exposing some type of
> service or application that client apps might want to configure/discover
> using host-meta.

By owning their host-meta, I can opt them into whatever services use
host-meta for discovery.

Are you really saying that you don't care that I own their host-meta file?

> As for your example of default charsets, where you are using a browser to
> define a generic interpretation of how to use host-meta to discover default
> charsets, it sounds like such API would need to be designed as:
>
> getHostMetaValue(URL resource_url, String host_meta_key, boolean
> isAllowedToFollowRedirects)
>
> which hardly sounds to me like a burden.

Don't forget mime types!

String getHostMetaValue(URL resource_url, String host_meta_key,
Boolean is_allowed_to_follow_redirects, Boolean
require_strict_mime_type_processing)

What about paper cut #37?

String getHostMetaValue(URL resource_url, String host_meta_key,
Boolean is_allowed_to_follow_redirects, Boolean
require_strict_mime_type_processing, Boolean opt_out_of_paper_cut_37)

That's the path to madness.

Adam

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T13:27:05Z

On Mon, Feb 23, 2009 at 1:21 PM, Adam Barth <w3c@...> wrote:

On Mon, Feb 23, 2009 at 1:04 PM, Breno de Medeiros <breno@...> wrote:
> No, it does not. It does introduce vulnerabilities to clients that visit
> tinyurl.com with the expectation that they will interpret some metadata at
> tinyurl.com to achieve specific aims.

You're right: someone has to use host-meta for something for this
attack to work.

> Simply substituting tinyurl.com's
> host-meta affects no one until tinyurl.com starts exposing some type of
> service or application that client apps might want to configure/discover
> using host-meta.

By owning their host-meta, I can opt them into whatever services use
host-meta for discovery.

Are you really saying that you don't care that I own their host-meta file?

> As for your example of default charsets, where you are using a browser to
> define a generic interpretation of how to use host-meta to discover default
> charsets, it sounds like such API would need to be designed as:
>
> getHostMetaValue(URL resource_url, String host_meta_key, boolean
> isAllowedToFollowRedirects)
>
> which hardly sounds to me like a burden.

Don't forget mime types!

String getHostMetaValue(URL resource_url, String host_meta_key,
Boolean is_allowed_to_follow_redirects, Boolean
require_strict_mime_type_processing)

What about paper cut #37?

String getHostMetaValue(URL resource_url, String host_meta_key,
Boolean is_allowed_to_follow_redirects, Boolean
require_strict_mime_type_processing, Boolean opt_out_of_paper_cut_37)

That's the path to madness.

Another path to madness is to write opt_out_of_paper_cut_37 as part of a generic spec when the vulnerability affects a special class of applications. Unless it is thought out and written directly into the spec or (as others including myself prefer) enforced by the application, it certainly cannot just go away.

Adam

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T13:21:32Z

On Mon, Feb 23, 2009 at 1:04 PM, Breno de Medeiros <breno@...> wrote:
> No, it does not. It does introduce vulnerabilities to clients that visit
> tinyurl.com with the expectation that they will interpret some metadata at
> tinyurl.com to achieve specific aims.

You're right: someone has to use host-meta for something for this
attack to work.

> Simply substituting tinyurl.com's
> host-meta affects no one until tinyurl.com starts exposing some type of
> service or application that client apps might want to configure/discover
> using host-meta.

By owning their host-meta, I can opt them into whatever services use
host-meta for discovery.

Are you really saying that you don't care that I own their host-meta file?

> As for your example of default charsets, where you are using a browser to
> define a generic interpretation of how to use host-meta to discover default
> charsets, it sounds like such API would need to be designed as:
>
> getHostMetaValue(URL resource_url, String host_meta_key, boolean
> isAllowedToFollowRedirects)
>
> which hardly sounds to me like a burden.

Don't forget mime types!

String getHostMetaValue(URL resource_url, String host_meta_key,
Boolean is_allowed_to_follow_redirects, Boolean
require_strict_mime_type_processing)

What about paper cut #37?

String getHostMetaValue(URL resource_url, String host_meta_key,
Boolean is_allowed_to_follow_redirects, Boolean
require_strict_mime_type_processing, Boolean opt_out_of_paper_cut_37)

That's the path to madness.

Adam

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

2009-02-23T13:04:38Z

On Mon, Feb 23, 2009 at 12:16 PM, Adam Barth <w3c@...> wrote:

On Mon, Feb 23, 2009 at 11:47 AM, Breno de Medeiros <breno@...> wrote:
> Or they may have to do it because host-meta does not allow redirects and
> they need it. I wonder what is more likely.

One solution is to add content to a host-meta file that says where to
find the host-meta file:

My-Host-Meta-Is-Located-At: http://www.example.com/my-favorite-host-meta

This has the advantage of not introducing vulnerabilities into existing servers.

> Because tinyurl.com allows you to do this.

Yes. Precisely. Following redirects introduces a vulnerability into
tinyurl.com. That is why I recommend not following redirects.

No, it does not. It does introduce vulnerabilities to clients that visit tinyurl.com with the expectation that they will interpret some metadata at tinyurl.com to achieve specific aims. Simply substituting tinyurl.com's host-meta affects no one until tinyurl.com starts exposing some type of service or application that client apps might want to configure/discover using host-meta.

As for your example of default charsets, where you are using a browser to define a generic interpretation of how to use host-meta to discover default charsets, it sounds like such API would need to be designed as:

getHostMetaValue(URL resource_url, String host_meta_key, boolean isAllowedToFollowRedirects)

which hardly sounds to me like a burden.

I don't know how to make a more compelling case for security than
supplying a working proof-of-concept exploit that required all of five
seconds to create on one of the world's most popular sites.

> I am more imaginative: I could do DNS spoofing,

DNS spoofing requires a lot more work (i.e., a more powerful attacker)
than abusing redirects.

> or I could choose another
> site to hack that is actually more interesting that tinyurl.

So we shouldn't care about introducing vulnerabilities into tinyurl
because we don't think they are important enough?

Adam

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)