They were worried about how (if at all) the credit card details were stored in Amarok, how the information was transferred to Magnatune, and if the Amarok developers had any access to transaction info.
The short answers are:
- credit card details aren't stored in Amarok at all, unless the application was compiled with debugging turned on (which it normally wouldn't be), in which case a line in the debug log would have the CC details. This debug log entry has been removed now, so that possibility doesn't exist
- the Amarok developers have no access to purchase data
- purchase info is transferred via https:, just like online web shops.
- Info about how to re-download the music (and artwork) is saved in Amarok, but this has no personal information in it.
Thanks again to Nikolaj for making the plugin, responding to questions, and (now) working another revision.
I'm reprinting part of the Amarok Weekly Newsletter below, the section that deals with Magnatune:
Music store plugin discussion
Christopher Conroy was interested in Magnatune-like plugin for Amarok. Integration with web music archives would be much easier with appropriate plugin:
1) What is the status of defining a plugin structure for things *like* magnatune. If it is still in development, are there some things a newbie contributor like me could help with?
2) Has any consideration been given to making these sorts of things scriptable (via DCOP?) It seems to me (after a very cursory examination of some scripts and amarok code), that one could have a DCOP interface that would allow one to setup a parser/fetcher/dbhandler to correspond to a browser gui (a tree and some script defined buttons).
Nikolaj Hald Nielsen explained the current situation, and plans for future:
First of all, no one (to the best of my knowledge) is currently working on a plug in system / generic interface for these things. I will venture a guess that I Will be doing a substantial amount of this work when the time comes, and I doubt it will be happening for a while still. I still have quite a bit of work to do refining the Magnatune stuff and I really think that it will be a mistake to branch out before this functionality is really solid.
Secondly, (and this is just my own personal opinion) I don't believe in building frameworks from scratch. I have seen this fail too many times. Instead I would much prefer, just like you mentioned, to factor out common functionality from a number of similar, working, features.
Discussion went from realization details to user interface design. Seems like we will have to wait a bit longer until generic solution for online stores and catalogs is developed.
Magnatune store security
Pascal Bleser, maintainer of Amarok packages for SUSE Linux, expressed his concern about security involved in Magnatune store:
[...] is not really clear how the whole thing is handled. Most specifically, whether e.g. credit card information can be seen by people from the amarok developer team in some magnatune transaction history or something. [...]
I couldn't find any detailed information about the transaction process and how the personal data of the users is secured.
Greg Meyer answered his questions:
(1) It uses https to transmit information.
(2) It only used the name of an Amarok developer (Nikolaj) to identify the transaction as coming from amarok during the beta period. Once we went gold the name was changed to amarok. Again, this was to identify the transaction as coming from Amarok and it doesn't use anybody's account.
(3)No one can see any credit card information except the people at Magnatune that execute the transaction, and even then it is probably quite automatic.
(4) We did a horrible job about being clear in communicating the nature of the transaction. This will soon be fixed if it hasn't been already.
Nikolaj nailed the main concern:
The only case in which any personal information is stored is if amarok is configured and built with Debug=full in which case the purchase url is printed to the log. It does store the Amarok reply xml data to use for later redownlaoding of a purchased track, but this does not contain any personal information at all.
Developers agreed that this single bit of debug output can be removed without harming the value of debug info.