The issue is that an MITM attacker can modify the traffic between client and server if it's not protected by HTTPS.

They could include a script tag and then run JS in the context of the widget which may have undesirable effects.

If the traffic is traveling over a connection you aren't 100% sure you control entirely, wrap it in HTTPS.

I can confirm this 100% with Charter / Spectrum. They use MITM to alter HTTP content to display their TOS you have to agree to in order to stop redirecting the content.

The only workaround is to use a VPN since so many servers still have not moved from HTTP to HTTPS.

Tech support states unless I accept the agreement this will not stop and may connection will be disconnected which is complete BS since HTTPS prevents this from working properly!

So yes, even ISPs are bad actors when it comes to HTTP.

I use Spectrum at home, as do my grandparents, and in neither case have I ever seen that happen (and I do access at least a couple non-HTTPS sites every once in awhile). Was that recent?

That's not a concern for a REST API where you are just grabbing and parsing json data. Even if someone injects some code into the result, it just gets parsed as a string and the worst thing that happens is the widget displays the wrong thing.

Fine so they modify the a field in the object, the point made was that you don't want to ingest anything other than what which is provided by the expected and hopefully trusted author.

Yours was a facetious point to make. Potential worst case scenario in this example may be that someone thinks its the wrong temperature, but normalising and arguing against the use of secure protocols is stupid and dangerous.

I'm not arguing against security. I literally said that using https is a good idea.

The point I'm making is that security always comes at a cost, and sometimes it just isn't worth it. In the OP's example, using https literally breaks the application. Whereas switching to http has very little downsides. So while https should be seen as the default, it makes sense to use http sometimes.

Do you use full disk encryption on every machine you use, with a separate TFA key for every device? Do you have bullet proof windows and a reinforced steel door? Have you purchased and set up a commercial firewall for your home network?

You can always increase security. Where you draw the line depends on you and your application. Throwing out all nuance because "you must always use $SecureThing at all costs" is just not helpful.

> the point made was that you don't want to ingest anything other than what which is provided by the expected and hopefully trusted author

What you actually said went quite a bit further than that. You outlined a scenario that involved arbitrary code execution.

> Yours was a facetious point to make.

"Facile", maybe? Even with that correction, the point was not facile—after all, it forced to you walk back from the original picture you painted of an RCE to a place where someone may get told there's going to be a mid-summer blizzard.

https://rationalwiki.org/wiki/Motte_and_bailey

Until somebody finds a vulnerability in your JSON parser or other layers of your stack. :)

There are inherent, unfixable vulnerabilities to a weather app, such as divulging location information and possibly travel patterns.

If you request weather info for a large range of locations at once - the k-Anonymity that HAVE I BEEN PWNED uses - you could prevent this at the cost of increasing response size dramatically

https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

I don't think that would help much. If my phone tries to get weather data for the prefix "66" and then "a9" and later "8d" and you correlate the cities together, you can be pretty sure I was driving around the Bay Area if the first list contains "Cupertino", the second "San Jose", and the third "Palo Alto".

I was thinking less around prefix matching and more around requesting enough data to where an observer couldn't tell what I was really interested in. If I requested 100 distinct locations in every state - 5000 total - you would know I was interested in the United States, but you would have a hard time determining where specifically.

But if the list from California always contained cities in the Bay Area that would be a bit suspicious.

It might be for this app but say the app displayed an image of the cloud cover. That image, from a MITM could be designed to exploit a know decoder bug (project zero just had a post about bunch they found in Apple's OSes). Browsers (or at least Chrome) run the image decompressors in the sandbox. Does Dashboard?

If the threat model is random exploits, they can still do that. Heartbleed etc have shorn that even the TLS stack itself can contain catastrophic vulnerabilities, so it's likely there will show up more in the future.

Or, maybe, just treat untrusted inputs as untrusted inputs and act accordingly. Wrapping it in encryption does nothing if the API provider gets hacked.

The other issue is that a certificate-based model of trust can be wielded by governments to censor the internet.

Unsecure http is essential to the free flow of information.

Let's get the right solution before we force everyone to use it.

Don't force anyone to use it. Both HTTP and HTTPS can be used, in addition to other protocols such as SMTP, NNTP, Gopher, Telnet, SSH, etc. To ensure to have free internet, to allow all protocols including if someone invents a new one, and including if someone uses non-standard port numbers for whatever reason, and including in both directions (anyone can act as a server or as a client or both).

If governments want to censor the internet, insecure protocols only make it easier for them.

It would be great if people could correct the record instead of just cowardly downvoting me. If I am presenting something that is untrue, please let me know.

Am I being paranoid for not trusting Google, Facebook or the federal government?