<div class="gmail_quote">On Tue, Jun 8, 2010 at 7:07 AM, Peter Watkins <span dir="ltr"><<a href="mailto:peterw@tux.org">peterw@tux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Jun 07, 2010 at 09:46:35PM -0700, John Panzer wrote:<br>
> On Mon, Jun 7, 2010 at 7:35 PM, Peter Watkins <<a href="mailto:peterw@tux.org">peterw@tux.org</a>> wrote:<br>
<br>
</div><div class="im">> > Whitelists again? Ugh. Chris had that nice video explaining how XAuth could<br>
> > put a few IdPs up their in a short, relevant list of choices. Now you're<br>
> > saying to make privacy OK, IdPs have to whitelist RP sites?<br>
<br>
</div><div class="im">> What makes you think their IdP wouldn't be doing this based on the user's<br>
> preferences?<br>
<br>
</div>Because that would just move the NASCAR problem from the RP site to the IdP<br>
site. Your current draft says the IdP can specify a list of RP domains when<br>
it deposits a token. In order to give the end user control over what sites<br>
this should be used at, the IdP would need a UI for determining what to go<br>
in this "extend" list. And it would have to so so when adding each token!<br>
NASCAR all over again, and probably even worse, since my impression is that<br>
there are at least two orders of magnitude more RPs than IdPs for any user.<br>
(In reality, this means IdP sites would not bother implementing such controls.)<br></blockquote><div><br></div><div>This would certainly be a poor UI. I can imagine better ones, but more to the point, the marketplace can decide what the best UI is in this case.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
This is a great example of why this should be in-browser. With an in-browser<br>
solution, a user could be prompted each time an RP asks for XAuth tokens,<br>
and could decide at that time which IdP tokens to reveal, and whether to<br>
always reveal the same set to that RP, etc. Users would only be prompted<br>
about the tokens they actually possess, and the RP sites they actually<br>
viist -- solving the privacy/disclosure NASCAR problem efficiently.<br></blockquote><div><br></div><div>I think this would be a poor UI too -- it's well known that most users will simply end up clicking "OK" in this situation, and the experience is worse. But without getting into that argument: You could implement essentially the same UX using JS -- the RP doesn't get the data sent back via postMessage() unless the <a href="http://xauth.org">xauth.org</a> JS says it can. You could probably have a better UX with an in-browser solution, but not a qualitatively different one. In other words, this is not a strong differentiator for in-browser vs. JS solutions.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Another reason for in-browser: avoiding one-size-fits-all solutions. You<br>
could add per-request controls to the code in Auth.org, but many users<br>
wouldn't want them, as it would slow them down. And you'd spend time localizing<br>
the UI. Move it to the browser and it becomes someone else's problem. You<br>
could release minimally compliant extensions, and let "the market" handle<br>
edge cases, just as the ISV market has for years provided additional controls<br>
over things like HTTP cookies.<br></blockquote><div><br></div><div>I agree that an in-browser solution could provide a better UX; in fact that's my argument (make it work, then make it better) ;). </div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> > > I think that browser support would make some<br>
> > > things easier -- perhaps defending against "pretend" IdPs that use social<br>
> > > engineering to get themselves on your IdP list -- but (a) those attacks<br>
> > > aren't privacy issues and (b) they appear low value to me.<br>
> ><br>
> > What social engineering? Getting you to open a page with an XAuth iframe?<br>
> > That sounds like a relatively easy attack to carry out, esp. in the era<br>
> > of tinyurl and <a href="http://bit.ly" target="_blank">bit.ly</a>.<br>
<br>
> And if successful, it gets the attacker a slightly annoying link with a big<br>
> glowing verified pointer back to their web site. I hope spammers do attempt<br>
> this; it'll be much easier to combat than other things they do today.<br>
<br>
</div>Many phishers don't really care about having legitimate-looking URLs.<br>
Some would try using this to phish someone's Facebook credentials, and since<br>
XAuth code is agressively cached in the browser, this wouldn't be any easier<br>
to defend against than current phishing scams (if XAuth.org *did* see traffic<br>
for each token jar request, then you would have a point). Consider Chris' demo<br>
again -- the Receiver site using simple strings & favicons to represent<br>
XAuth-discovered IdPs. Seems a legitimate concern to me.<br></blockquote><div><br></div><div>Apparently, in order to phish Facebook credentials, one must do no more than rank #1 on the search result for "facebook login" (<a href="http://knowyourmeme.com/memes/i-want-the-old-facebook-back">http://knowyourmeme.com/memes/i-want-the-old-facebook-back</a>).</div>
<div><br></div><div>I do agree that we need more comprehensive defenses against "bad actors" on the Internet. This is a separate discussion, but the ability to have distributed, abuse-resistant reputation for both sites and users is something that is sorely needed if we really want to promote a fully decentralized architecture for just about anything of interest.</div>
<div><br></div><div>If for example <a href="http://xauth.org">xauth.org</a> had a good way to ask for the Internet's opinion of a site, it could ask the user to confirm for the small subset of sites that it thinks are hinky (or which it has no information about), with appropriate warnings. An immune system for the Internet, if you will.</div>
<div><br></div><div>On the other hand, this is also something that is not a differentiator between in-browser and JS-based implementations; either one could consult such a service and pop up (infrequent, scary) warnings.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> > > I will agree that things would be more secure if we encased every client<br>
> > > computer in concrete with no 'net connection and sank them to the bottom<br>
> > of<br>
> > > the ocean.<br>
> ><br>
> > Excuse me?<br>
<br>
> My somewhat flippant point was that eliminating all possible risks also<br>
> eliminates all possible usefulness.<br>
<br>
</div>And the implication is that you don't want to bother with threat assessment.<br>
Or that perhaps I'm not a worthy interlocutor. Please try not to be flippant;<br>
I think most of us here (save perhaps potty-mouth Santosh) are trying to be<br>
civil and respectful.<br></blockquote><div><br></div><div>Definitely not the intention. I was having trouble figuring out what specific threats people were concerned about. If you have to handle all possible threats, there is almost no adequate defense.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> > > Sure, we could host extensions at <a href="http://xauth.org" target="_blank">xauth.org</a>. And then people could<br>
> > download<br>
> > > them. From, um, a centralized site. How is that more decentralized<br>
> > > exactly?<br>
> ><br>
> > Users could vet the code and not worry about it changing on them the way it<br>
> > could from a SaaS site like <a href="http://xauth.org" target="_blank">xauth.org</a>.<br>
<br>
> Of course regular users are not going to vet the code. And <a href="http://xauth.org" target="_blank">xauth.org</a> is not<br>
> a SaaS site. It's just a stock web server.<br>
<br>
</div>Users are relying on code not under their control (whatever is served by<br>
<a href="http://auth.org" target="_blank">auth.org</a>). It might not be full-on REST/SOAP, but it's a centralized service.<br></blockquote><div><br></div><div>Yes. This begs the question of what "under their control" means exactly though (what threats are we considering?)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> But yes, it would be better for _security in the long run_ to have this code<br>
> be baked into an otherwise trusted download (like the browser). It is not<br>
> necessary to do this to start with, and indeed is a very bad idea while the<br>
> APIs are still in flux.<br>
<br>
</div>I don't buy that. It's simple to update a repository XML file to tell Chrome,<br>
Firefox, etc., that there's a new extension available. If the *API* is in flux,<br>
then all the RPs will have to adapt anyway. Having the code in browser makes<br>
it tougher to update the *implementation*, but not the API, and only very,<br>
very slightly. Make new distributable, update software XML feeds, publish.<br>
I do this for my own software, and it takes 2-3 short commands for me to<br>
publish an update. No big deal.</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> > <a href="http://xauth.org" target="_blank">xauth.org</a> would have no indication<br>
> > whatsoever that a user was interacting with XAuth-compatible Extenders or<br>
> > Receivers.<br>
<br>
> Not sure what you're saying here.<br>
<br>
</div>Spelled out in my subsequent email -- Referer data for IFRAME requests.<br>
<div class="im"><br>
> > I'll post this on the xauth group now, too, but for instance currently the<br>
> > <a href="http://xauth.org" target="_blank">xauth.org</a> site is not accessible via a https URL (at least not one that<br>
> > passes normal CN/hostname checks)<br>
<br>
</div><div class="im">> Heh. They're currently using Akamai to mitigate SPOF issues and Akamai is<br>
> responding to SSL requests as *.<a href="http://akamai.net" target="_blank">akamai.net</a> hosts. Obviously this<br>
> configuration issue will be fixed.<br>
<br>
</div>Yeah, it's been a month since Allen Tom raised the issue in the xAuth Google<br>
group, and nobody there actually replied to say they'd fix that. Glad to hear<br>
it from you.<br>
<div class="im"><br>
> (Note that exactly the same issues arise when downloading extensions. JS is<br>
> just a way of delivering always-latest-version extensions to your browser.)<br>
<br>
</div>And the solutions are similar -- code-signing and publishing extension info<br>
on https pages, as Firefox does.<br></blockquote><div><br></div><div>How does this avoid having to trust a central site (the extension site and the owner of the signing key)? Or do you see the case of retrieving JS via TLS as qualitatively different from retrieving similar code from an extension site? Or is the fact that users would need to actively download the extension (until, as some suggest, it is baked into browsers automatically)? </div>
<div><br></div><div>Thought experiment: Would you be satisfied if xauth were baked into Chromium (hosted at <a href="http://www.chromium.org">www.chromium.org</a>)? If so, would it be sufficient to CNAME <a href="http://xauth.org">xauth.org</a> to <a href="http://www.chromium.org">www.chromium.org</a> and serve up JS from there, signed with the Chromium.org private key?</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
-Peter<br>
<br>
</font></blockquote></div><br>