XAuth critiques
SitG Admin
sysadmin at shadowsinthegarden.com
Tue Jun 8 23:33:18 UTC 2010
>I'm having trouble seeing how some additional once-per-year cache
>revalidation requests to <http://xauth.org>xauth.org's IP would
>change the amount of information leakage in any appreciable way.
Single point of failure = NON-centralization.
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.
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.)
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.
-Shade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100608/745f76cf/attachment.html>
More information about the specs
mailing list