Clarifying magnatune support in amarok

[Pascal Bleser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nikolaj Hald Nielsen wrote:
> 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.

Ok, great :)
Thanks for all the information.
Good we sorted that one out ^^

> On 11/11/06, Pascal Bleser <guru at unixtech.be <mailto:guru at unixtech.be>>
> wrote:
> 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/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=
>> <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 ?

- --
  -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)

iD8DBQFFVaPrr3NMWliFcXcRArkJAJ9nTW0KtlKjUBa8ipUxpwrjj311iwCgjryu
wziLlza5ofqUfZQCqsRPmZU=
=eP6v
-----END PGP SIGNATURE-----