Thanks for bringing this up, @valeth. I don’t think this is at all shady. So I want to go a lot deeper into the topic than you intended, to explain why. This is partly because it has also been a topic that’s been on my mind.
The brief answer is that I feel I have everyone’s best interests at heart. I’ve written a web site that uses your api key because it makes lots of scripts possible that wouldn’t otherwise be feasible. Because of this there are a number of places an api key ends up by having a script I’ve written active. So here’s the full list:
- In a browser cookie associated with wanikanitools-golang.curiousattemptbunny.com. You can clear cookies for that site to get rid of it, or use the sign out button on the site.
- In an analytics tool that I use, called New Relic. Data is discarded there after two weeks (or possible one week, I forget). This is not essential, it’s just easier for me to support people when someone says the script is broken for them but it’s working for me.
- As the index into caches of assignments, review_statistics, study_materials from the WK site. This is what makes the site so fast at computing leeches etc. This data is currently never deleted (because disk space isn’t a problem). I could either put the effort in to making them expire, or into converting the api key a one-way hash.
- In my web server logs. This is pretty ephemeral although I’m not sure how quickly the logs are deleted.
- Specifically for the App Store script: I’m using the api key to track which scripts the user has installed. Again, I could put the work in to use a one-way hash here.
- Specifically for the Leech Trainer script: I’m using the api key to track which leeches have already been trained. Again, I could put the work in to use a one-way hash here.
I’d like to frame things this way:
- Installing any user script relies heavily on trusting the author of that script. It’s essentially running arbitrary code which could do anything that JavaScript running on a web site can do.
- All the code I write is publicly visible - either on greasyfork, or in GitHub.
- I’m motivated to make my own experience of learning Japanese on WaniKani the best that it can be, and it delights me that others get to benefit from my efforts too. A post like this really makes my day, and affirms that I’m on the right track.
- I easily volunteer 5 (often more) hours of my own coding time a week on the collection of scripts that I’m writing and maintaining. I have a busy life as a parent, spouse, and employee, so these hours come from a small and precious supply. All that is to say that I’m very deliberate about which features I add. I’m always looking for what gets the best making-the-most-peoples-learning-better to my-time ratio.
So to summarize, I think it boils down to:
- Ideally, everything is good as-is, or
- If there are one or two requests to delete api key information, I’ll do them by hand., or
- If there are multiple requests, I’ll be motivated to either provide an iTunes-like “Agree to Terms” warning (which I personally dislike), or more likely implement a delete-all-my-data button.
Again, thanks for bringing up the topic. I hope this doesn’t come across as me picking on you, because my intention is just to be transparent about how I’m using your api key and what my motivations are.
Cheers,
hitechbunny