@ruilov I see nothing in that thread that contradicts what I said.
@JockM: If they were to do that, it would be no problem. The reason I am very against removing loadstring() is because I use it in implementing class functions which create buttons which execute some line of code. The function is defined during creating the instance and loadstring() executes the code making it possible to create real interfaces using class functions.
Taking it out would kill that dead, but flagging http.get() data as non-executable would keep it so all would still be fine. My problem would be that it would require one hell of a rework and I can see easily getting around it.
@JockM, right but you see how TLL was aware of this issue.
Look we don’t even have to talk about it anymore. Just make sure your code is posted on somewhere where it’s easy to parse.
You’re spending a lot of time with codea - anything exciting coming down the pipe?
Might I make a recommendation for the next version?
For the new openURL(url) function, can we get a way to choose between opening the link in Safari or opening it in an in-app browser, much like the way Codea has a forums button?
http.get and loadstring could easily co-exist while being mutually exclusive (sort of). We could make using either function disable the other for the duration of the executed environment. I.e. using http.get turns off loadstring until the application is reset. The only thing I’m worried at this point is someone making an embedded app store and a large news site posting about it. That would probably call Apple to action, not sure exactly what they would do though.
I can’t begin to tell you guys how awesome the new text selection tools are in Codea. It has pretty much ruined everything else on the iPhone/iPad for me, because this functionality isn’t built in everywhere. I find myself swiping on the keyboard to move the cursor while doing pretty much anything else that requires typing. Really nice work guys, hopefully others (esp. Apple) take note of this and begin to implement it more broadly.
@John: While that is a good idea, it again would kill any kind of GUI/Windowing library from functioning with http.get() data.
Is there any way you could embed a required file within the projects that are needed to execute Codea code that exceeds x amount of lines or maybe place a restriction on the size of string that loadstring() can use?
@ruilov said “I’d rather not make assumptions about what apple will or will not like”
It’s not an assumption - it’s a track record. Codea had code sharing (along with a few other apps), and Apple purged them - pulled them from the store entirely until TLL had removed the feature entirely. That’s why we cut and paste now.
If you make a feature that can “compete” in some way with the App store, or threatens Apple’s primary goal (to make the ipad/iphone software ‘safe’ so that you don’t have to worry about viruses/trojans/malware) - Apple will nuke the app. Again - not assumption, fact, they’ve done it time and time again, and they’re more than willing to assert that right after-the-fact. And I don’t blame them. If they see http.get() as a threat - it’s history.
I think there is a VERY GOOD chance that Apple will continue relaxing restrictions, such as they have for interpreted languages, so long as people don’t abuse them (in Apple’s eyes). I also thing there is a very good chance that people who want to “push the envelope” (and I’ve been one of them) will screw the pooch, and make them crack down hard; they won’t wait for it to happen, they’ll pre-empt it.
You want to make an ‘app store’ using Codea? Fine - make it with the runtime, and submit it to Apple, and have fun with that (they’ll reject it, but whatever floats your boat). As for Codea proper, please don’t pee in the pool, some of us are having fun without waving it in apple’s face…
@JockM I believe a few other Lua editors explicitly allow both sockets and load() — iLuaBox even offers networking as an in-app-purchase (and in-app-purchase needs to be explicitly reviewed and approved by Apple).
It’s not about whether you can download code (otherwise you could argue reading and typing code is “downloading”, or copying and pasting is not allowed). It’s whether the application installs code by default — as part of its built-in functionality. If users construct their own solutions I think they obviously know the dangers, and what they are doing.
They are not simply tapping a link in an email and causing a change in functionality (a feature we had to remove). But they are researching, implementing, and using a system entirely on their own. I think that’s similar to someone who goes out of their way to copy and paste an example from the forums. They are in the minority and are dedicated users who know all the details.
(That said, whatever Apple decides goes. But this is a grey area right now. The last App Reviewer I spoke to claimed that typing code from the internet is “downloading” code. But obviously they are letting that one pass.)
@Simeon: Quick question. Will the Codea Runtime be updated soon to support 1.4?
@Simeon This is your app, but I would suggest the only reason that Codea and iLuaBox continue to have loadstring() is because non of the reviews know Lua that well.
But given sufficient publicity, a blog post that catches fire, and gets Apple’s attention then they are going to come down on you like a ton of bricks. And this could happen in lots and lots of ways:
- Someone writes an appstore,
- White/grey/black hat writes a app to demonstrate how a man-in-the-middle attack could get untrusted code into Codea that can send out spam, or crack passwords, or the like
- Some well meaning blogger writes post about Codea and posts @ruilov’s code
Because there is the thing, http.get() plus loadstring() is a genuine attack vector. It is a way to get around Apple’s restrictions on what code can be published, get porn apps on the iPad, run malicious code, etc. If Apple pulled Codea for this it wouldn’t be in the same class as Apple pulling AirFoil. You wouldn’t really have any defense.
But this is the deal you make when you deal with Apple. Codea needs Apple, but Apple doesn’t need Codea. There are only a handful of App developers they need. They could pull Codea forever and all the bad PR in the world would have no real effect on Apple; but you need Apple, at least until you port Codea to another platform.
It also hurts you very little to disable loadstring() (sorry @Deamos). It is harder to create an unrunnableString type, and harder still to get it right. But I think it is in your best interest to do one of them. There is no reason to tempt fate on this one…
@ruilov depends what you mean about exiting. Am I writing a competitor to Codea? Nope, I spent a fair chunk of my life writing authoring systems, and have no interest in doing it again.
If you mean stuff I am doing with Codea, then yeah I have a couple of things in the works. We will see what comes of them.
And if you mean stuff for iOS that has nothing to do with Codea then most definitely. A company I help to found is soon to go live with film production software. I am negotiating with a british publisher for rights to a early 20th century mystery series, and I have an app I wrote for a client that should go live next week.
I keep off the streets and out of gangs 
We’ll be updating the runtime to version 1.4 shortly.
I could lose loadstring(). It’d be… inconvenient. But hardly fatal.
We lose web access - sigh. I dunno.
The silly, silly part is - it’s already trivial to download and execute arbitrary code; it’s called safari and javascript. Yes, presumably apple believes it’s not a likely vector for code exploits, but then - they thought the same of .png files back in the day.
Someone trying to do so in Codea isn’t doing anything useful - it’s a stunt, pure and simple.
@JockM
Disabling loadstring wouldnt ultimately work because people could implement their own version of loadstring (or write an interpreter for a smaller DSL or something) in Lua itself. Also if http.get somehow returned unexecutable strings, you could just hide the data in an image or using some other steganography technique.
The only way to absolutely stop people downloading and running code is to remove http.get. (Not that we have plans to.)
@Dylan I don’t see people implementing their own interpreters and loadstring() as the same level of risk. The problem is one of risk to Codea not to more abstract issues of security.
Because that isn’t how Apple will perceive things. There is a big difference between “we did our best to close all security holes preemptively” and “oh yeah we knew about that one since we started, but thought we would wait for you to realize the implications”
Disabling loadstring() is an act of good faith, and removes a feature almost nobody uses (again sorry @Deamos). Apple has a track-record of being harsh. I don’t see any point in deliberately poking a badger.
Again, Why can’t we just restrict the size of code executable by loadstring() to something like 7 or so chars? While not removing the issue completely, it would prevent anyone from being able to easily do what we are trying to avoid, while still maintaining the feature for those of us who use it.
The current version of Spritely uses (and is pretty dependent on) loadString.
Granted, now that 1.4 is out I can and will rewrite to use the image tools, but I suspect there are more than a few images out there at the moment saved in a way that relies on loadString.
Mmm… But if I recall looking at the stuff Spritely uses for loadstring, It would be easy to write a parser…
Apple’s concern with downloadable code is security-based - if someone found an exploit in codea, they could presumably craft lua code in codea to exploit that. By writing our own interpreter in codea (I was considering a BASIC dialect), that level is once-removed, and likely not realistically exploitable.
In a sane world, if apple balks removing loadstring should be sufficient. But - apple isn’t always reasonable.
I think the sanest course of action is to not poke the bear. People who think downloading and executing code is a good idea need to be educated as to the long-term possible consequences.
Indeed - I’m very anti-censorship, but I suggest a forum rule that advocating or sharing code here that attempts to circumvent or bypass Apple’s policies (not just this - if someone wrote other things apple frowns on - tethering comes to mind) should cause those posts to be locked, with an explanation.
Firstly, I would like to thank you for the update. I see a lot of improvements which I, as well as others, will find to be quite fruitful. The more easily task of selecting projects is a much appreciated gift and inserting user created images, keyboard enhancements, etc., is most welcomed. Great job.
Secondly, I have noticed that quite a few user projects are now crashing Codea than before. Opening them again after restarting Codea works fine. Is this just me or is anyone else experiencing this dilemma?
A lot of these crashes are happening with copy/pasted code from forum examples but also from my own created code.
Irregardless, I am so enjoying coding away from my PC after a long hiatus.