[OpenID] NyaLogin private beta invites, supporting OpenID movement
he...@nyalog.in
SitG Admin
Are these different from the standard "It's FREE!" invites already
available through the website? Or is that an advertised service users
need to offer their personal info to learn isn't *quite* open yet?
>It generates a simple 5-7 line code which you implement on your
>website and you do not need to study any of APIs.
This seems to be a public authentication *proxy*:
http://www.nyalog.in/Include/images/AuthChart.png
As security and privacy go, this is a step even *more* intrusive than
simply instructing a user to retrieve arbitrary JavaScript (code)
from another site.
I also tracked down the source of your "Super easy to implement" feature icon:
http://www.emule-project.net/home/img/cuddleemule.png
Understand, it's not that I think you violated their IPR or anything
(if anyone, *they* shouldn't have such ideals!), but I do wonder what
it says about your company philosophies that your visuals are so
close to the logo of a filesharing software that intentionally
enables IPR violations.
I have not been able to track down anything similar for the "It's
FREE" feature icon, but it seems to be a candy bar with a bite taken
out of it and the wrapper partly off. Those are the only two icons in
your feature list that seemed out of place to me.
-Shade
_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
he...@nyalog.in
SitG Admin
>Facebook, Twitter, Google etc and we are only providing channel for
>authentication.
Then, as I understand this, you're acting as an ISP; if your service
became successful, it would become a centralized point of
eavesdropping for identity correlation. I understand tunneling secure
connections over proxies; if you were concealing from users' main
ISP's what sites they were authenticating to or what sites they were
authenticating with, I could readily see what your service offers,
but by not proxying communications between the user and RP, it seems
that their ISP can still look at *those* OpenID strings to see what
OP the user has. This wouldn't matter as much if delegation was used,
but with most users accepting their OP's default, your service
doesn't seem to add much in the way of privacy (and potentially takes
away).
Think of distributed trust (i.e. the decentralized model) as a small
army of baskets, each carrying two or three eggs. It's easy to say
"We can sacrifice the weakest members of our army at no loss if we
give all their eggs to the strongest!", but even if you can find some
volunteers brave (read: stupid) enough to try it, all those eggs will
make them a prime target for so many snakes that they will be brought
down anyway! You can easily say "potential risks to privacy don't
matter", and even mean it, but the lure of such centralization will
attract attackers you *cannot* stop.
Risk management isn't just about preventing potential attacks. It's
also about damage control; limiting the effects, once a compromise
occurs. Looking at the diagram again, it looks like NyaLogin proxies
the user's connection to their *OP* (whom they have already
determined they can trust), and not to the *RP* (with whom they don't
automatically have such a relationship), while letting the ISP
determine RP but not OP (because of NyaLogin's proxy being the only
IP address connected to), and letting NyaLogin determine RP, ISP, and
OP.
If the goal is to let users keep their OP/Identity secret from their
main ISP, the tradeoff is letting NyaLogin have access to this
information instead. You might want to market more towards
disadvantaged users in countries under heavy censorship, though they
might already be trying to work around site whitelists (and NyaLogin
might not make it there any time soon).
>Regarding logo design, we have no clue of a company having similar
>logo. If there is a company with similar logo, that is a coincidence
>but please let us know the file sharing company you are talking
>about so that we can take appropriate steps to avoid any violation.
I linked to their website in the last post. It was a simple enough
description; "Why is that donkey sticking its tongue out at me?". I
think I got lucky with the software name being so close, though.
Alternatively, if there is software named after that candy bar, I
gave up before finding it :)
Andrew Arnott
Is that a fair assessment?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
SitG Admin
>with fewer features perhaps). The auth proxying model seems
>identical.
This?
https://rpxnow.com/docs
Ahh, the more-detailed technical language there gives me some idea of
what the intent may be. They are trying to be the first discovery
node in a multi-hop OpenID auth, right? Basically, the RP says "here
is their claimed URI, please let us know where the delegation loops
terminate"?