Recently I noticed that original del.icio.us is providing "Del.icio.us Recommendation Engine", so I changed the name of this module to "My Del.icio.us Recommendation Snippet".
This confliction is because I named it so easy way, but anyway these two are totally different. The former (original) is an internal functionality in del.icio.us service itself, and the latter (I created) is a script snippet using del.icio.us JSON call interface, which can be embedded in arbitrary web site.
Wednesday, March 01, 2006
Wednesday, February 22, 2006
Why del.icio.us recommendation engine is not personalized 2.0 ?
First, you have to tell your del.icio.us ID to your visiting site. In principle, it's not necessary. Because what we need is your recent tagging information, not your id. Unfortunately, to get your bookmark information, the site owner have to know your del.icio.us id. This is derived from del.icio.us's feed interface. But, in general, forcing to tell someone's unique id is not preferable from the aspect of privacy.
Second, this module doesn't consider the case where identity information is originally access controlled. Del.icio.us bookmarks are apparently identity information, but it's not restricted, always published for general public. In order to deal with every identity-aware web services, we have to consider the case where services are access controlled.
These are not only the issues in personalized 2.0 services. If I have a time I can pick up many other issues to be solved.
Second, this module doesn't consider the case where identity information is originally access controlled. Del.icio.us bookmarks are apparently identity information, but it's not restricted, always published for general public. In order to deal with every identity-aware web services, we have to consider the case where services are access controlled.
These are not only the issues in personalized 2.0 services. If I have a time I can pick up many other issues to be solved.
Del.icio.us Recommendation Engine
While researching recent del.icio.us's native support of JSONP, an interesting idea hit me and fired up my imagination. Devoting recent days to this development, and finally I created an attractive script moudule. "Del.icio.us Recommendation Engine", I call it.
"Del.icio.us Recommendation Engine" is a recommendation link list generator extracted from site owner's bookmarks archived in del.icio.us. If you tell your del.icio.us ID to the site, you can get the site owner's bookmarks as a recommendation. While creating your recommendation list, your recent del.icio.us posts and associated tags automatically used as your preference information.
It is cool because we don't need any server infrastructure for generating recommendation list. Entire generation process is done in client side Javascript. JSON (or JSONP) and On-Demand JavaScript techniques are used to get del.icio.us posts.
Seeing is believing. Please look and see it.
I think it is a kind of interesting module, but I don't think it is the final achivement of my personalized 2.0 project. Yes, this module does some kind of personalization for the visitors, but techniques used in this module cannot be used in many cases. I think there're many issues to be solved there in order to be a generic personalized web 2.0 service solution.
Anyway, I created some "personalized 2.0 like " service module. It's totally fun. Enjoy yourself.
"Del.icio.us Recommendation Engine" is a recommendation link list generator extracted from site owner's bookmarks archived in del.icio.us. If you tell your del.icio.us ID to the site, you can get the site owner's bookmarks as a recommendation. While creating your recommendation list, your recent del.icio.us posts and associated tags automatically used as your preference information.
It is cool because we don't need any server infrastructure for generating recommendation list. Entire generation process is done in client side Javascript. JSON (or JSONP) and On-Demand JavaScript techniques are used to get del.icio.us posts.
Seeing is believing. Please look and see it.
I think it is a kind of interesting module, but I don't think it is the final achivement of my personalized 2.0 project. Yes, this module does some kind of personalization for the visitors, but techniques used in this module cannot be used in many cases. I think there're many issues to be solved there in order to be a generic personalized web 2.0 service solution.
Anyway, I created some "personalized 2.0 like " service module. It's totally fun. Enjoy yourself.
Thursday, February 16, 2006
Del.icio.us is Now Doing JSONP, or Callback Support
I don't know when del.icio.us began the JSON service, but the JSON interface for their bookmark information was only kind of static one. Through static 'Delicious' javascript object we can get posts. So it is not apparently supporting parallel queries (will destroy each other's results), and does not consider name confliction.
But while doing test of JSON with Padding Tester (JSONP Tester), I found that they are implementing callback function parameter like Yahoo.
Check out this.
http://del.icio.us/feeds/json/stomita?callback=JsonUtil.responseCallbacks%5B0%5D
It is not mentioned official web help page and couldn't find any articles about this new feature. I'm not sure when they implemented it (maybe old).
Anyway I included del.icio.us call in JSONP Tester page.
But while doing test of JSON with Padding Tester (JSONP Tester), I found that they are implementing callback function parameter like Yahoo.
Check out this.
http://del.icio.us/feeds/json/stomita?callback=JsonUtil.responseCallbacks%5B0%5D
It is not mentioned official web help page and couldn't find any articles about this new feature. I'm not sure when they implemented it (maybe old).
Anyway I included del.icio.us call in JSONP Tester page.
JSONP Service and Security
Before talking about shared services, I have to clarify what issues (or concerns) are now discussed about JSONP services (maybe not so discussed, because there're less services than usual REST XML or SOAP Web Services). Especially, I'm going to focus security concerns. Because XMLHttpRequest itself doesn't allow the request other than the original html source site (same-origin policy), there might be same or similar concerns in JSONP service.
Let's consider Site Y is a JSONP service site (like Yahoo), and Site M is your JSONP mashup site, and User u is a visitor to Site M. Site O is a simple web service provider nothing related to these services, but might be an atacker's target.
(Note that these are only my guesses)
M cannot steal it without cooperation of Y. If Y have a unrestricted JSONP interface to access u's identity information, M can. If there's no consent of u, Y should be responsible for unintended usage of u's identity information.
Absolutely Y can. The loaded JSONP service does not always have to provide JSON object, it's nothing other than JavaScript and the code format itself is all under the control of Y. Loaded code is automatically executed without any validation (this is a key point of JSONP) and the excecution priviledge become that of Site M. So M have to do trust Y as long as M is using Y's service.
Of course Y is responsible basically. If the information theft is u's identity information in M, M also should be responsible (about unintended usage of u's identity information).
Yes, for example, requesting huge amout of requests to O. And - similar to DDoS - the attacking context become that of User u. But it's not so special case in JSONP service because any malicious site can do that. The main concern here is trust. If User u trusted Site M, and not knowing M is using Y's service (and u might be not trusting Y), M was responsible for prior explanation about using Y's services, because, if notified, u might not have used the M's service. And M should also be responsible for Site O
Basically no. If there were vulnerabilities in O it might be yes. If u accepted the usage of cross domain XMLHttpRequest in some way (browser setting?), it might also be yes, but it's under u's responsibility.
Basically no. If there were vulnerabilities in O it might be yes. CSRF might be one of them. O should be responsible with its own vulnerability.
Let's consider Site Y is a JSONP service site (like Yahoo), and Site M is your JSONP mashup site, and User u is a visitor to Site M. Site O is a simple web service provider nothing related to these services, but might be an atacker's target.
(Note that these are only my guesses)
If M is malicious, can M steal the identity information of u in Y ?
M cannot steal it without cooperation of Y. If Y have a unrestricted JSONP interface to access u's identity information, M can. If there's no consent of u, Y should be responsible for unintended usage of u's identity information.
If Y is malicious, can Y effect bad thing (information theft, session hijack) to M ?
Absolutely Y can. The loaded JSONP service does not always have to provide JSON object, it's nothing other than JavaScript and the code format itself is all under the control of Y. Loaded code is automatically executed without any validation (this is a key point of JSONP) and the excecution priviledge become that of Site M. So M have to do trust Y as long as M is using Y's service.
If Y become suddenly malicious, and the loaded code effected bad to M, who is responsible ?
Of course Y is responsible basically. If the information theft is u's identity information in M, M also should be responsible (about unintended usage of u's identity information).
If Y is malicious, Can Y attack O ?
Yes, for example, requesting huge amout of requests to O. And - similar to DDoS - the attacking context become that of User u. But it's not so special case in JSONP service because any malicious site can do that. The main concern here is trust. If User u trusted Site M, and not knowing M is using Y's service (and u might be not trusting Y), M was responsible for prior explanation about using Y's services, because, if notified, u might not have used the M's service. And M should also be responsible for Site O
Can Y steal the identity information of u in Site O ?
Basically no. If there were vulnerabilities in O it might be yes. If u accepted the usage of cross domain XMLHttpRequest in some way (browser setting?), it might also be yes, but it's under u's responsibility.
Can Y affect the transaction between u and O ?
Basically no. If there were vulnerabilities in O it might be yes. CSRF might be one of them. O should be responsible with its own vulnerability.
Subscribe to:
Posts (Atom)