<div class="gmail_quote">On Tue, Jun 8, 2010 at 4:33 PM, SitG Admin <span dir="ltr"><<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="im">
<div>>I'm having trouble seeing how some additional once-per-year
cache revalidation requests to <a href="http://xauth.org" target="_blank">xauth.org</a>'s IP would change the amount of
information leakage in any appreciable way.</div>
<div><br></div>
</div><div>Single point of failure = NON-centralization.</div></div></blockquote><div><br></div><div>OK, so now we're back to talking about reliability rather than privacy? It's very hard to respond when the topic keeps changing.</div>
<div><br></div><div>Reliability: If Akamai's edge cache network and its second and third level backups all fail, the once-per-year revalidation requests to retrieve XAuth code will fail too. In which case, the web page should probably show a fallback UI (the one it has today, for example) and make the user explicitly choose their IdP. Or they could probably hit reload and recover from the network hiccup too.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<div><br></div>
<div>I assume the caching cannot be reset, and that your intent is to
get browser support within the year so it never has to be revalidated;
this would limit blocking/interception attacks.</div></div></blockquote><div><br></div><div>I'm picking a year as that's common practice for content that never changes. It would almost certainly start out much less than that as early adopters shake out the kinks.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<div><br></div>
<div>I don't, however, understand why you can't set up a local proxy
server, temporarily bounce the JS request through it, and set the
cache accordingly. Post the source code, let everyone review it, then
let users download it from mirrors (verifying the hash against
anywhere it is published), creating a truly decentralized setup. (For
at least another year, they wouldn't have to worry about setting up
the cache again.)</div></div></blockquote><div><br></div><div>You can. The source code is at <a href="http://github.com/xauth/xauth">http://github.com/xauth/xauth</a> and is under an Apache 2.0 license. You can set up a local proxy, or map your <a href="http://xauth.org">xauth.org</a> to 127.0.0.1 in /etc/hosts and run your own server, or probably do other things with extensions. There is absolutely nothing stopping you from doing this. In fact I hope you do, and share the results with the community!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<div>There *is* a slightly higher barrier to entry, then, but it would
do a great deal to alleviate the concerns of those of us who see a
centralized service which *may*, in some idyllic future, become what
it was promised to be.</div>
<div><br></div></div></blockquote><div><br></div><div>Anyone who wants to pay the higher barrier to entry is free to do so; XAuth will work perfectly for them once they've jumped over the barrier.</div><div><br></div>
<div>I don't think, though, that it's reasonable for us to demand that everybody be forced to jump over a pretty major barrier without a compelling reason. So far I haven't seen such a reason.</div><div><br>
</div>
<div>-John</div><div><br></div></div>