I am a public services librarian who wishes to learn enough programming/scripting to use Web 2.0 APIs in my library's Website. Could this jeopardize user privacy? I am interested to hear others chime in on this topic.

Views: 84

Reply to This

Replies to This Discussion

Rory Litwin wrote an interesting post on this last year in library juice in which he felt:_
Web 2.0 websites are, with some exceptions, based primarily on sharing information, but sharing information in a particular way: essentially, they are about seeing and being seen.

He had some interesting points.
Interesting idea, sadly our website doesn't have anything remotely like an API. Our OPAC can't even generate clean HTML.... but that's another story.

To my mind it depends on what information you'd want to make available. For example as a patron being able to see that another patron has borrowed a specific book is a break of that other patrons privacy. But, being able to see that a book has been borrowed 25 times in the past 6 months is a good thing. It may be an indication that the book is a good one.

Allowing comments could also be interesting and could be considered a step down the "Library2.0" path. It wouldn't necessarily be a privacy problem because you wouldn't need people to login, just as you don't need people to login to post comments on a blog. Granted the idea of patrons posting comments in your OPAC scares many people, but I think it could be valuable.

Essentially I think it comes down to what information you'd want to make available, and how you did it. Is investigating, and possibly implementing, some of these thing a colossal waste of time? No. My suggestion would be start small and see where it leads you. The librarians you know may even come on board after a while after they see it is less scary.
Sounds like miscommunication. The Facebook API is just as secure as Facebook so your users wouldn't get anything more than what they are authorized to get.
Most likely it is a miscommunication. I don't really know what an API is or does or how I'd use it. I just know it stands for Application Programming Interface.
I am not sure that this question can be answered in abstract. It depends a lot on what you are trying to achieve, the relationship of your Web 2.0 frontend to backend systems, network and box architecture, etc.

It sounds like you are just getting into programming. I would consider it a really bad idea as a beginner to write anything that runs server-side on a public net accessible box. You should work on the assumption that any machine that runs your code might be taken over by any bad people who can network to that machine.

Client-side code is generally less risky in that regard in that if you are making AJAX requests to a XML file (or professionally written XML emitter [hopefully]) on the server, the bad guy can make the same request or the same request with different parameters, but shouldn't be able to compromise the webserver.

Does that help?
Yes, thank you.

This helps in that I better understand that most of my hypothetical questions cannot be well articulated or easily answered in the abstract, and it helps me understand the frequent miscommunications noob techs (ME) have with experienced IT systems professionals. I think I have much more to learn before I can discuss thiese issues with clarity.
Certainly not trying to discourage you. We all start someplace and I started out on the reference desk myself. People laugh when I describe myself as a non-technical resource and then pull out a wall sized semantic data model to backend audience-specific faceted navigation experiences. It comes with time and experience. Learning to code helps--just, if you are concerned about privacy, be careful about where you do it.

Actually, a lot of the difficulty that Library Professionals have talking to IT Professional comes from using different vocabulary for similar concepts. Indeed, often the concept that the IT Professional has behind the fancy word is rather simplistic from our point of view.



Follow #Library20

The Learning Revolution

© 2020   Created by Steve Hargadon.   Powered by

Badges  |  Report an Issue  |  Terms of Service