W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: UMP / CORS: Implementor Interest

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 21 Apr 2010 19:40:07 -0700
Cc: Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <3D1B728B-1645-437F-B178-1C01B175E8DE@apple.com>
To: "Mark S. Miller" <erights@google.com>

On Apr 21, 2010, at 7:09 PM, Mark S. Miller wrote:

> On Wed, Apr 21, 2010 at 6:45 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
> On Apr 21, 2010, at 6:23 PM, Mark S. Miller wrote:
>> On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak <mjs@apple.com>  
>> wrote:
>> I agree that "Anonymous" or "Anon" is more clear as to the purpose  
>> than "Uniform".
>> In the same say this email is anonymous. Sure, I say it is from  
>> MarkM, but my browser doesn't add any identifying info that you can  
>> see. Even if I included MarkM's PGP signature, by your criteria, it  
>> would still be anonymous.
> Your mail client automatically adds identifying info, as do any mail  
> relays in the delivery path. If that were not the case, I would  
> think it's fair to say the message is sent anonymously based on the  
> envelope being anynymous. That's so even if the message contents  
> include a claim or proof of your identity.
> Ok, so a request is non-anonymous if the identifying information is  
> added by at least:
> 1) a browser (cookies, etc)
> 2) a mail client
> 3) any mail relays in the delivery path.
> What other software counts? Why does PGP not count? If the mail  
> client in question is JavaScript running in a web page sending a  
> uniform message, is it still non-anonymous?

I'm not trying to draw a bright line here between categories of  
software, rather I am looking into the reason this proposed API would  
exist. The purpose is to avoid passively including any credentials  
that would identify the user, identify the requesting site, or  
otherwise convey ambient authority. Right? So what's a good word to  
express that? Maybe "Anonymous" is not the best word to capture that  
concept, but "Uniform" does not seem to capture it either. I don't  
think most people would make the leap that "Uniform" means, "please,  
browser, don't add any credentials". Whereas I think "Anonymous" does  
convey that intent. There may be an even better words, but I think  
"Anonymous" is a really good fit.

Consider Tor. Tor calls itself "a distributed, anonymous network", and  
most would agree that is a fair label. However, no one assumes that  
Tor will prevent you from typing your real name or other indentifying  
information into a Web page, or stop you from uploading a file that  
includes a PGP signature. What it does try to do is ensure that such  
information is not conveyed to anyone passively. That seems to match  
the intent of UMP (and the UMP-like subset of CORS) - no identifying  
information is passively added, but the sender is free to explicitly  
add it themselves.

>> I understand why UMP uses that term but I don't think it will be  
>> obvious to authors reading code.
>> "XML" is also a misnomer. And "Http" is confusing as well, since  
>> these requests can (and should) generally be carried over https. At  
>> least we agree on "Request" ;).
> I agree, but (a) that ship has sailed; and (b) dropping those from  
> the name only in the anonymous/uniform/whatever version would  
> probably be more confusing than helpful, at least if the API ends up  
> being roughly similar. XMLHttpRequest has brand value, and it's  
> worth building on author awareness even if the X and the H are more  
> historical than meaningful at this point.
> Funny, I don't recall anyone objecting that the proposed JSONRequest  
> should have been called JSONXmlHttpRequest. I also don't recall  
> anyone suggesting that Microsoft rename XDomainRequest to  
> XDomainXmlHttpRequest. Surely the same argument holds for these?

This Working Group also did not agree to standardize those APIs,  
though both were proposed. We have no say in what names third parties  
use in nonstandard APIs.

In addition, they both of these APIs gratuitously different from  
XMLHttpRequest in ways other than security policy. I would suggest  
that we not do that with the proposed new constructor.

Received on Thursday, 22 April 2010 02:40:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:24 UTC