
I received a worried email from the
OpenSUSE folks, who had de-activated the Magnatune support in Amarok for their next revision of their Linux distribution, because they had privacy and security concerns.
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.
The OpenSUSE people seemed satisfied by these answers, and I'm hoping that means they'll re-enable Magnatune in Amarok, as the vast majority of Amarok users are going to be getting their version from their Linux distribution, not downloading and compiling their own copies.
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.