1. Sending a DBA username and password over a cleartext channel is bad. Users would do it without reading warnings if the feature is available, and their passwords would get out. -1 to requiring a DBA password via Web form.
I'm still in favor of providing a DB-rights escalation feature. Truly secure hosting services provide at least 2 DB usernames, one for web service usage without database creation (and often without table creation) privileges, and another for administration with full rights. I really don't want my Drupal website creating tables with the normal user rights it has -- which means I cannot install any modules which create tables without defeating my provider's security arrangements. Escalated privs at module install time would be the perfect solution. While some users would no doubt ignore even the most obtrusive of warnings, it *is* after all their choice to make such a mistake. We can do a number of things to mitigate the problem. If protocol is HTTPS (i.e. encrypted), we can display no warnings. We can also use some sort of Javascript-based encryption to send the username and password over the wire as ciphertext. Still, even if some mad cracker managed to sniff the DBA username and password off the wire, they would still have to find their way to the database itself. After all, I can destroy your non-SSL Drupal website by sniffing your admin username and password, without needing access to the database directly. Thus, just because some few people will foolishly ignore the warnings (and probably still be just fine because the likelihood of their packets being sniffed is exceedingly low anyway), does not mean we should avoid implementing features that many people would make good use of in a more secure fashion. ..chrisxj