A possible solution:
There's a "Login with Amazon" service that may be what the developer needs to be using: http://login.amazon.com/
Because it seemed out of place, it felt like it was an obvious tactic to bootstrap trust where there wasn't any. A better icon (for me) would have been a badge from your SSL provider, or even just some well designed lock icon.
It seems like they need to do a better job of education users about that. I don't think they have a pure "Symantec SSL" batch anymore.
<form id="add_products_form" name="add_products_form" onsubmit="connect_amazon2(); return false;" method="post" enctype="multipart/form-data" _lpchecked="1">
This is from chrome developer tools, network tab
Also, would you say chrome developer tools is the lightest/most accessible way for the general public to inspect for such a thing?
EDIT: TY, schrodinger. That turned out to be a tab in Dev Tools that I just hadn't dug into before. No need to install anything!
It's actually using GET to their server and something unknown to Amazon (that would most likely be server to server and not accessible over Javascript).
Although the method on the form is POST, it has an onsubmit handler which calls the connect_amazon2() JS function (which makes a GET AJAX request on line 311) and then returns false, preventing the form from being submitted.
Yes, the Chrome Dev Tools are probably the easiest way to take a look at this type of information. I actually used Safari, but Chrome's tools are much easier to use.
The connect_amazon2() must be making the GET request.
disc: not implying you would disagree with any of the above.
As well as on Amazon's logs, which aren't meant to hold customers' passwords. This is bad, bad, bad (interesting idea though).
For some reason, the "Norton Secured" badge makes me less likely to trust the site and looking at the inline, not very well written Javascript gives me even less confident that the guys behind this site have the technical chops to keep my data secure.