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.
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
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.
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.
