Clarifying magnatune support in amarok

Sat Nov 11 10:01:29 UTC 2006

I think John pretty much nailed it (Do we have a "honorary Amarok developer"
title? :-)

The only case in which any personal information is stored is if amarok is
configured and buildt with Debug=full in wich 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.

Pascal, I will look at your patch and merge it into svn. We are also
preparing a patchset for the released 1.4.4 version and I will make sure to
include it there as well.

- Nikolaj

On 11/11/06, Pascal Bleser <guru at unixtech.be> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John Buckman wrote:
> >> The reason is that it 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.
> >>
> >> http://lists.opensuse.org/opensuse/2006-11/msg00224.html
> >> http://lists.opensuse.org/opensuse/2006-11/msg00228.html
> >> http://lists.opensuse.org/opensuse/2006-11/msg00234.html
> >> http://lists.opensuse.org/opensuse/2006-11/msg00244.html
> >
> > The beauty of open source is that you can just look at the source and
> > find out. :D
>
> Sure, I was about to check the source code anyway.
> I was actually asking about what happens on magnatune's side of things
> (transaction history if it was made through an amarok developer's
> account at magnatune).
> This was fixed in the stable version, so that's fine ;)
>
> > in the function:
> > void MagnatunePurchaseHandler::processPayment
> > in
> > src/magnatunebrowser/magnatunepurchasehandler.cpp
> >
> > Is where things happen.  The purchase info is submitted via https with:
> >
> >   QString purchaseURL = "https://magnatune.com/buy/buy_dl_cc_xml?cc="
> > + ccNumber + "&mm=" + expMonth + "&yy="+ expYear + "&sku=" + albumCode
> > + "&name=" + name + "&email=" + email + "&id=amarok&amount=" +
> > amountString;
> >
> > the only logging I see is if debug logging is on, in which case the
> > purchase url is stored in the debug log.
> >    debug() << "purchase url : " << purchaseURL << endl;
>
> Ewwww... Ok. That one must be removed (ccNumber, expMonth and expYear).
>
> See patch in attachment.
>
> > The communication is direct between the client machine and magnatune,
> > and does not touch anyone else.  The call to Magnatune's HTTPS side is
> > via the KDE storedGet() call:
> >
> > m_resultDownloadJob = KIO::storedGet( KURL(purchaseURL), false, false );
>
> Hmm.. ok. To be really sure that stuff isn't logged anywhere, one would
> need to check whether KURL() and KIO::storedGet() don't log.
>
> > I'm CCking Nikolaj (the Amarok developer who did the Magnatune
> > integration work) in case there is other logging going on that I don't
see.
>
> I didn't see anything else in src/magnatunebrowser/*
> The only place left could be KURL() or KIO::storedGet()
>
> >> It's not that I'm paranoid nor that I'm implying any bad intentions
> >> but.. well.. IMO it must be as transparent as possible ;)
> >> I couldn't find any detailed information about the transaction process
> >> and how the personal data of the users is secured.
> >> Could you please take a few minutes to enlighten us about it ? (or
point
> >> me to a link if I didn't look hard enough)
> >
> > Nikolaj, can you help? I don't see any saving of personal data myself,
> > it looks more like you implemented a form that submits via HTTPS GET,
> > and the security and issues are the same as when using a web browser.
>
> The HTTPS GET is fine of course.
> Amarok does the SSL handshake and then sends the GET line that includes
> the sensitive data through the SSL tunnel.
>
> The logging must be removed though.
> It's not *that* critical as the CVV/CVV2/CVC2 number is not submitted
> (that's the credit card verification number) and if someone gets the
> credit card data submitted by amarok through gaining remote access and
> seeking in the logs, the card holder could still refuse the transaction
> (and then magnatune would have to prove it's actually that person who
> did the transaction).
>
> But still, not logging the CC data in the first place would be.. um..
> better ;)
>
> > As to this comment:
> >> Like the implementation how your credit card information is submitted
> >> and that
> >> it is posted under the personal account of one Amarok developer at
> >> Magnatune?
> >
> > I assume they're referring to the "id=nikola" in the purchase url that
> > was in the beta versions of Amarok, which has now been changed to
> > "id=amarok".  This is simply used to track the source of the purchase
> > and has no nefarious intent.
>
> Ok. So there is an "amarok" account at magnatunes.
> Is there any option for anyone (except you guys at magnatunes, of
> course) to log in to that account and see transaction history that
> includes credit card information ?
>
> CC data is a really sensitive thing (I happen to work in the payment
> business ;)).
>
> Thanks for clarifying John.
>
> Nikolaj: I'll patch out the CC data logging in my amarok builds - could
> it be merged upstream ?
>
> cheers
> - --
>   -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
>   /\\ <pascal.bleser at skynet.be>       <guru at unixtech.be>
>  _\_v The more things change, the more they stay insane.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFFVZ4Kr3NMWliFcXcRAnfcAJ4gA475gJaHYegjxCT2eUxvH8kMPQCfYguZ
> L7qDU9EGm5/G4Wjn+TQH9ow=
> =R6Mg
> -----END PGP SIGNATURE-----
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20061111/d137edc2/attachment.html>