- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 21 Apr 2010 19:40:07 -0700
- To: "Mark S. Miller" <erights@google.com>
- 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>
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. Regards, Maciej
Received on Thursday, 22 April 2010 02:40:41 UTC