Good idea.
Good idea.
"This app would like to send data over the internet insecurely."
There would be a nice stampede to get SSL coverage for API endpoints if we called it what it really is.
http://www.cnet.com/news/how-web-mail-providers-leave-door-o... "A survey of top mail providers shows that Google is alone in using strong encryption, known as SMTP-TLS... Facebook, Hotmail, Yahoo Mail, and AOL Mail do not accept incoming e-mail in SMTP-TLS encrypted form..."
I hope things have improved since. (Some enterprising journalist might want to do a followup.)
This app would like to use HTTPS
This app would like to use HTTP
This app would like full internet access
From a security point of the view the app realistically should also pin it's certificate as well - the app developer knows the certificates that the app should expect to prevent Charles proxy working.- This app would like to transmit secured data over the internet.
- This app would like to transmit unsecured data over the internet. Transmitting unsecured data could result in it being intercepted by unauthorized third parties for unintended purposes such as monitoring or tracking of your communications or identity theft. This information could also be used to gain unauthorized access to your devices or accounts.
Of course, even if it is secured... it could still be used for such by anyone who can acquire the private key of the server, then you're pretty much hooped.
I guess ultimately, it just needs to warn the user that data is being communicated with the internet. It's probably being tracked and monitored by someone and probably not for the purpose the user intended. Use with caution.