Are you implying that POST data isn't going to be transmitted in cleartext beyond that point? Because that's incorrect - HTTPS doesn't selectively encrypt - the whole connection is encrypted. If you're worried about GET data being sent in cleartext, POST is no different.

The point is that GET parameters are more likely to be stored in server logs or other application logs where POST body is usually discarded from such logs.

So someone getting access to the logs will have access to a lot of possibly sensitive data, that's all depending on server and application settings, but by default GET are more likely to leave traces than POST.

It's a subtle but valid concern.

Ahhh, understood. There's someone between what you see as "ebay.com", where the GET is decrypted, and the actual ebay machine that will use the password information. I was thinking of it at the user-agent level. The GETs never leave your machine in plain text. I did not consider that the other end where you send the information could be "flakey". Bloody hell, it's a miracle anything works at all.

Not even necessarily, but the https logs are likely archived to another server, and that server will likely be secured completely differently.

Maybe ebay do the right thing and terminate on the final endpoint, and keep their logs appropriately secured. We shouldn't assume the worst without knowledge.