It has been well over a year since the TI-84 Plus CE came out. On the subject of an app SDK, we've heard about as much from TI as apologies from Donald Trump. The current guess in the community is that the decision to continue to require app signatures is a matter of internal politics; the same person(s) that wanted apps to continue to require signatures also don't want to release the app signing key. It would seem that currently, there is an internal stalemate of sorts, in which the people in TI that are in favor of 3rd-party software convince the people who are not to continue to tolerate our assembly-language antics.

To be clear, there are no sound technical reasons to require app signatures in the first place. The only useful function they fulfill is as an integrity check, which could be done easier and faster with a simple CRC. Otherwise, programs can do anything apps can do, including:

• install hooks;
  
• using a hook, display a custom Apps menu, and display our own programs on the Apps menu as though they were proper apps;
  
• persist after RAM resets;
  
• be larger than 64 K, by loading additional segments;
  
• be relocatable, by using our own relocation engine; and
  
• execute from the archive by applying relocations based on an algorithm that computes, before calling _ArchUnarch, where the program will end up in the archive.

In the past year, the community has made good progress producing our own SDK. We are capable of producing apps ourselves, notwithstanding our lack of a signing key. To the end of supporting app development, I have been working on our own linker that will support both RAM programs---specifically, LibLoad relocatable libraries, in C---, and flash apps. However, on the point of flash apps, the community is not unified. How should we implement them?

There are two ways to do flash apps without a signing key: Fake them using programs in the archive, and patch out the OS's app signature check.

Fake apps would be implemented as special appvars. A special shell would predict where in the archive the appvar would appear when archived, process the app's relocations list while the appvar is in RAM, and archive it. A menu hook can hook into the apps list to make the fake apps appear in the Apps menu.
Pros of fake apps:

• No need for any exploits

Cons of fake apps:

• A special shell is needed to install the Apps menu hook after every RAM reset
  
• The relocations list needs to be reprocessed after every garbage collect
  
• The app needs to be split into < 64 K segments. This can probably be handled by the PC-side linker and calc-side relocator, though it will still require programmers to take special steps with read-only data structures that need to be kept together (e.g. bitmaps).
  
• The shell for fake apps will need to verify that the file still exists in the correct location before running. This is easy: just write the expected location into the file, and compare.
  
• Archive hooks are unsafe; there is always a small chance (on the order of 0.5 %) of crashing after a garbage collect. That said, whether or not to use flash hooks is up to developers, and for stability, a RAM hook could be used to verify and chain to a flash hook.
  
• It will be an awful hack that will be annoying to program for, and annoying for end-users

Alternatively, we could patch the OS, a process popularly called jailbreaking on other platforms. Personally, I suspect TI would not take steps to prevent our patcher from working as long as the patcher cannot adversely affect the functioning of TestGuard. To that end, the patcher would need to be highly obfuscated so that inexperienced people could not adapt it to perform other patches which TI would find objectionable. And I must say, in my experience, people with the skills to develop OS patches do not need to cheat on STEM tests. However, patched OSes will fail TestGuard validation. (Certainly, TestGuard validation can be hacked, but developing such functionality also provides great potential for such to be adapted to cheating.) Therefore, we should also provide an unpatcher.

Pros of an OS patch:

• It is easier for us to develop a highly-obfuscated patcher and linker than a hacky shell and toolchain to support fake apps.
  
• It is probably easier and more convenient for end users. First, the jailbroken apps do not need to be relocated after every garbage collect. And second, the jailbreaker patch can be uninstalled after the user has installed the desired apps; apps are not revalidated after installation.
  
• It could showcase what we can do with proper flash apps.

Cons of an OS patch:

• It is an OS patch nonetheless, and some community members feel that any kind of OS patch will jeopardize our chances of ever getting a signing key, nevermind their SDK. (Yes, TI, we know you have an SDK. You used it to create the apps that already exist. They didn't just materialize out of thin air.)
  
• The end-user has to remember to unpatch their calculator before any time the calculator might be subject to TestGuard validation.
  
• Robust encrypting obfuscation depends on obscure hardware quirks to generate the decryption key, making it impossible to deobfuscate without either a very good emulator, or intimate knowledge of the hardware. However, that means that a new ASIC revision could break the decryption routine. Unfortunately, robust obfuscation requires that you allow crashing if decryption fails, since that makes it harder for an analyst to determine if the code has been properly deobfuscated.

Before continuing with work on either option, I think the community should have a discussion on which approach to take. I am in favor of the OS patch option, but feel free to discuss your own opinion in detail. Furthermore, this is an open forum thread. I know that some of TI's employees occasionally look at the Cemetech forums. If anybody would like to bring this to their attention so they can see our thoughts and intentions, please do so. And if TI would like to add their opinion, please join Cemetech and talk with the community! We are not happy with this lack of communication. If we are really lucky, this thread will serve to change that.

Regardless of what TI may or may do, the community is not a monolithic entity. Those of us who would like to be on friendlier terms with TI do refrain from releasing any tools that promote cheating, but we cannot guarantee that others will not. Yet programming the OS to enforce app signatures and withholding the key does not change that. There is no shortage of ways to bypass the flash write lock and patch the OS in arbitrary ways. I know that those of us who can write OS patches are not waiting for TI to release the key, and then publish an evil TestGuard breaker. It has been a year. If we wanted to publish such a thing, we would just do it, without waiting. The reason such a thing is not currently available on ticalc.org is that the people who can make tools to defeat TestGuard have no need to do so, because math skills and programming skills go hand-in-hand.

Finally, I am also aware that TI Education is engaged with a cat-and-mouse game with some members of the Nspire series community. However, there is a lot of non-overlap between them and the rest of us. Please do not begrudge us their actions.

Discuss this matter. I hope for a community consensus in about two weeks.

Addendum for TI: Since writing this, I have remembered that Push-to-Test and TestGuard treat apps with certain names differently. I understand the desire to treat certain apps specially. However, I believe the proper way to do that is with a special header field, and to restrict recognition of that field to apps with a special signing key.

On the TI-84 Plus CE, that signing key could simply be the normal one, because that is still secret to TI. TI could release a new OS version that allows the app key field to be absent or have only a dummy value, and for such apps to lack a signature. When Push-to-Test and TestGuard look for apps to treat specially, they can also do a quick check for the signing key ID. This would allow 3rd-party apps without there being a chance of tricking testing tools into thinking they're TI-endorsed in some way.

For the lulz, some IRC quotes during the initial IRC discussion on this:

Code:



Code:



Code:



Code:



Code:

Something to note is that the opinions that will be posted in this topic might not necessarily represent the opinions of the TI community as a whole about the matter. The 4 active TI calculator sites userbases (Cemetech, Omnimaga, CodeWalrus and TI-Planet) share different views overall about TI's stance, Ndless, OS patches and circumventing TI's restrictions (which sometimes caused a bit of friction between some users), although overall there are concerns that circumventing application restrictions could lead to TI retaliating by releasing a TI-84 Advanced CE calculator with no ASM/C support or another cat and mouse game between TI and the community. But it would definitively be interesting to see most people's views about the matter.


I myself have mixed feelings about such hack: I think that waiting for the RSA key has been a lost cause since the very day the TI-84 Plus CE was released, because of TI's past actions, so it doesn't matter if such hack comes out or not, because we were not gonna get the key either way. But my worry is if TI starts patching the exploits then there are risks that community apps get blocked permanently or for months until a new exploit is found, just like with Ndless. I think that it's possible that TI won't retaliate as long as we don't tamper with PTT, TestGuard and exam LED features, though.

Hmm, perhaps I should cross-post this. Although, at least on this side of the Atlantic, Cemetech's members have the most contact with TI. To patch or not to patch; that is the question. Whether 'tis nobler in the mind to suffer the hacks of fake apps, or to take patches against an opaque corporation. Which you prefer depends on how you think TI will respond, and Cemetech has some community members that have been active a long time and know TI as well as you could know them. And yes, DJ_O, Omnimaga has some technically proficient members, too, but the senior members I really want to hear from also visit Cemetech. Sadly, this is a decision that rests not on technical merits, but politics, and proficiency with playing politics does not come easily to the young.

I feel similarly.

There is an exploit that we believe would costs TI thousands of dollars to fix. Suffice it say, even if they very much oppose us, they will not spend that much money unless we give them a very good reason to. Of course, this also raises the stakes on the quality of the obfuscation, because it only takes one person to force them to spend that money, and then I'll understand if they hold a grudge. So I recommend we start with a simple exploit, something that they can fix if our version 1.0 gets deobfuscated.

[Edit: removed some vague but unnecessary technical information]

That's basically what I believe, but instead of "possible," "almost certainly." Oh, and I don't think they think of it as retaliation. I think they think of it as protecting their business interests.

Because no one around here actually seems to know the format of an app, how to execute one, and many other useful things that you should probably be aware of, I documented the structure of flash applications over on WikiTI and also wrote an example program that demonstrates finding application, getting the size, version information, copyright string, and even executing them. You can find the demo code on WikiTI; 2nd is used to execute, any other key continues in the search.

http://wikiti.brandonw.net/index.php?title=84PCE:OS:Applications

Here's a screenshot for your enjoyment:



In my opinion, I really see this as an opportunity to see just how good of programmers we can be. I will still continue to not be like some, and openly share any knowledge I have. It's best to be collaborative in these situations, and I wish everyone the best of luck.

The format of an app is close to that used by, er, the TI-68k series

That's a really tough question. I couldn't choose an option to vote on. To "jailbreak" the CE would generate a lot more admiration for the calc hacking community than the other option, but I don't think that matters in the face of TI responding by locking the calc down more. I'd probably lean more towards the safe side.

I've added an addendum suggesting that TI allow unsigned apps in the next OS update. (Just release it in a timely manner. Like, sometime this year.) It would allow them---and everybody else---to distinguish between TI apps and 3rd-party apps for testing purposes. Maybe they could also have Push-to-Test only permit TI-signed apps on tests. This seems to me to be an option that the community would accept, and I hope TI would find it acceptable, too. Just, seriously . . . release it in a timely manner, and tell us whether or not to expect such a thing.

I have a few ides to contribute.. Although apps to provide good things .. They're not really that much better. I think we should look into an app that acts as a registered ti app that runs third party apps from within. This would be so,thing to think about , but I'm new to applications . I have been working on getting apps on the TI 84 CE and actually got one to transfer, but it reset the ENTIRE memory.. So it didn't work.. Anyways good luck on whatever you guys try and I'm happy to help .

Yup, as outlined by DrDnar.

On the TI-68k series, FlashApps enjoy several features that ASM programs do not enjoy (as much, or at all):
* the lifecycle management part of the event system, from system startup, while ASM programs mostly enjoy the subset of events they can hook, after having been installed as TSRs;
* namespaced TI-Basic extensions: <flashapp name>.<entry point>, e.g. sstart.sstart(...) and sstart.about(), rather than a flat naming space, <program/function name> or <folder name>\<program/function name> - the latter form provides most user-level benefits, just scattered across multiple files instead of a single FlashApp file;
* a more direct access to the built-in, heavyweight OO infrastructure for overriding various system aspects in an application, such as the font used by the system. ASM programs have access to the setters and getters of that infrastructure, but again, not in an integrated fashion.

But the TI-eZ80 series, despite taking several cues from the TI-68k series, provides none of that, not even folders. And there are no restrictions on direct Flash execution in archive memory, either. All of those technical reasons make FlashApps a much weaker requirement / a much harder sell on the TI-eZ80 series.


FTR again: some things which have been posted in this topic about community FlashApps were already suggested to the relevant persons at TI, multiple times even...
Unless TI provides an automated Web service, ala Let's Encrypt, don't underestimate the negative impact on popularity of the signing process, even with TI making a hard, long-lasting commitment to reacting to signing requests and developer key creations in a matter of hours, at least five days a week (24/7 is not very realistic without full automation ^^).
AFAIK, the popularity of FlashApps on the TI-Z80 series came mainly from the combination of egregious limitations on the size of ASM programs and TI releasing the 0104 key; on the TI-68k series, signing FlashApps was one of the two leading reasons (the other one being the horrible official toolchain) making FlashApps an unpopular development option. Even on the TI-68k series, the aforementioned extra functionality not available in the TI-eZ80 series was not sufficiently compelling, and the narrower functionality in other areas was annoying.

One advantage of apps is that they can be larger than 64 KB. TI-Boy CE in program form would result into Pokémon being split into 16 appvars or sub-programs.

I'm all for more open-ness, though I've seen how TI "likes" it when things are being made available by force by enthusiasts - and however good the motivations are initially, Ndless and this jailbreaker here achieve the same thing: make (more) native development possible in an way that TI didn't want it possible.
So far, nothing good came out of it as TI keeps blocking Ndless in each update - They are going to like it even less if the exploit(s) used on the CE are more "permanent", i.e. relying on something they themselves can't even fix with a software update.

The problem, really, isn't that it's all nice and good towards PTT (that should obviously be there, otherwise you might as well call the jailbreaker "F*ckTI"), it's that TI has to keep a certain relation of trust with both teachers and exam boards. And neither are really willing to put the effort into understanding technicalities behind why something could/should be trusted, since TI didn't allow it in the first place. And well, TI didn't allow apps on the CE probably because they don't see (yet?) see any useful purposes from them as they can already know we're doing quite fine with programs.

Anyway, we've seen awesome things made with Ndless, and I'm sure even TI saw that (but they probably won't admit it) - it'd be nice if instead of having to force our way in, there'd be a conversation open with devs and execs from TI, at least so that everybody can get on the same page and express wills and concerns. There has pretty much always be an extreme lack of communication from TI with the community - I'd hope it gets better at some point, for the benefit of all, but I don't really hold my breath. Simply because if a dialogue happens, some people will always say that "this isn't enough, we want less restrictions, etc."
I also hope a situation where an even more "powerful" (read, unrestricted) jailbreaker doesn't get reached, because it would have not only destroyed all efforts that would have been made, but clearly destroy for good any kind of trust TI could have put in the community.

So, think of the outcomes:

• Somehow, TI manages to agree to open up the CE a bit, with keys and whatnot -> what if someone wants more? Will people here suddenly be "defending TI" saying "Nope, you're going to stay confined to these restrictions, and you better not try anything"
  
• TI agree to discuss, but no agreement comes out of it. Because each side now sees the other as the close-minded foe, it's going to be an open war? Exploits after exploits? That's even worse than Ndless.
  
• TI refuses dialogue, and a jailbreaker is going to be made anyway, apparently.

Please weigh in all possible + and - before doing anything.
I'm all for more open-ness, but it's pretty d*mn hard to make everybody happy.

So, my choice in the poll (even though my opinion doesn't weigh in much as I'm not really an ez80 coder) is the first (jailbreaker), because if TI (and exam boards etc.) is open-minded enough, they could see it's not "dangerous", and if they're not, well surely people here are going to bypass security anyway... so what's the point of taking a harder route?

(BTW DrDnar, it's not nice to reduce communities to a single sentence made from opinions of vocal minorities - the goal is to achieve some sort of common agreement between communities so that we can stand united when talking with TI if that ever happens ; and it's not with your phrasing (despite your edit, which only makes it a bit less unacceptable) that this can be achieved easily)

I went out for a walk this evening, considering writing my own letter asking about an SDK. But on my walk, I realized some things:

• (1a) TI is most likely not making any public statements to us about app development because their lawyer is advising them not to tell us anything. This is standard for lawyers. Specifically, (1b) their lawyer is treating us like a legal adversary seeking to render to TI some kind of legal harm, and you never want to help your enemy by telling them how you think.
• (2) By refusing to communicate with us in any way, TI may have lost some of their legal rights. What rights, you ask? Why, you ask? Given (1a), I am going to do the same, and not tell you.

Why is this important? Well, no matter how long we continue to respect their business interests, their lawyer's advice will stay the same: say nothing, because to a lawyer, any statement you make may potentially be used against you in court, and TI doesn't need to take that risk. While some of us have been told off-the-record that some employees would like to speak with us candidly and honestly, it would appear that TI's lawyer has told them attempting candid and honest discussion may cause them serious harm.

So on the one hand, the powers that be have some employees telling them not to trust us. And on the other hand, they have a lawyer telling them not to trust us. And so, the powers that be understandably decide that TI should not do anything for us.

Furthermore, I believe that as long as (1b) continues to be true, we should not feel obliged to respect their business interests. Certainly, I believe that's what a lawyer would tell us: that we get nothing by being nice, and will continue to get nothing. On other hand, given (2), they likely cannot stop us from publishing the OS patcher I have proposed. And note that they have never actually made any public statement to the community-at-large that they wish us to respect their business interests. We should stop behaving as though they have, if for no other reason than to encourage them to actually say what their intensions toward us are, and what they would like from us.

Additionally, I have gone out of my way to make it clear I was willing to respect their business interests. This is because I thought that doing so might help the community (not just a few select individuals) form friendly relations with TI. Given that they are likely being so opaque on their counsel's advice, it would seem that doing so is a waste of time, for you cannot endear yourself to a lawyer while there are billable hours at stake!

Therefore, I suspect that if we hired our own lawyer, our lawyer would tells us to go ahead with the patcher if TI continues to refuse to have any dialog with the community (and not just a few select individuals). I now believe the best option to get TI to talk with us at all is to try to convince them that their lawyer is doing them a disservice by advising them to refuse to speak to us. If that doesn't work, the only way to get them to say anything to us will be to literally file a lawsuit. It's not because any of their employees want to be rude to us, but because they've been advised by their counsel to be silent.

So, in a few weeks, I would like to proceed with the OS patcher option I proposed. I suspect they will continue to refuse to talk to us, no matter what we do. And I suspect that releasing the OS patcher will not hurt any of the personal relationships our community members have, because some of TI's own employees also do not like this situation.

This crisis was inevitable. Did you think that the iPhone jailbreakers were happy when they decided to state their intentions to release their hacks to the public? Of course not. But it's the lifecycle of hardware, and part of an international movement called freedom.

When a company refuses to open talks and give proper representation to its customers, this is the hammer. It is a deadly weapon. Look at TI's ticker (NASDAQ: TXN) and realize that it is a public company with investors. And when you show that all of TI's security features that its engineers promised to its investors and teachers and school board members were all for naught, oh yeah, you're raising hell.

When after all those T^3 conferences and those "talks" between TI and Kerm it just so turns out Kerm's community has decided to turn on TI and hard press them to release their SDK, oh yeah, you're raising hell. And then when the TI communities decide that yeah it was time we ought to jailbreak and collectively point the middle finger at TI (because this is really what this is, you're getting absolutely unrestricted access to some touchy parts of the calculator just to call your program an app), oh yeah, TI's gonna get mad. But you know what? It's just business. They'll lose money and they'll sue, you'll pray every night for an EFF lawyer, and there will be a ruling, because you wanted to write apps for the calculator you bought with your hard earned money and the company that made the calculator and sold it to you didn't want you to. Technically we've all already broken the EULA one way or another.

And why does the poll say "heavily obfuscated patcher"? You want to keep this closed source? No. Nobody gets to play god. This is Cemetech here, a place to share your creations not to tout around some patcher you refuse to talk about because you think it might suddenly cause a calculator to explode or TI to suddenly sue you or some script kiddie to suddenly start cheating. You report it privately to TI and you give TI time to negotiate, you make a public full disclosure with source, videos, screenshots, the whole shebang, or you don't do anything at all (which isn't really a choice given the amount of information you've already provided).

In fact, you don't seem to have a choice anymore. All the stars of the internet point to "information wants to be free." Anything else is just a chilling effect. The hardware is in our hands and we must not be bound by TI's "games."

Maybe my post might seem too radical. Personally, I am a very vocal antibusiness sort of person, although I do not take an according political alignment. But by nature we are hackers. We already know how to cheat on tests but we know we're too smart to depend on cheating. And teachers must not depend on some flimsy TestGuard software to prevent program usage, in fact none of my teachers at all use TestGuard.

We need to be realistic. TI's software isn't perfect; after all, security is always a matter of when, not if. We need to show TI that their software isn't perfect and never was. Let this be a lesson to them. I took a risk to post this because many people disagree with me. Are you - we - ready to take a risk?

Personally, I feel that TI has already given as more than we could ever want with this platform. There's memory mapped io, a decent enough LCD, a ton, ton of ram to play with, and a nice large archive space. And an actual eZ80 processor, which is something that is such a nice step up from the z80 into the releam of flat addressing. Programs, appears, and any variable really can be 64kb in size; on the older calcs this wa s limited to only about 8kb. In addition, while the prospect of apps seems pretty neat, keep in mind that they are absolutely huge, and contain much wasted relocation information. (If it had been me I would have set aside more RAM as a temporary execution buffer, but meh). In addition, the heavy presence of flash wait states will make most programs unbearably slow.

The main issue here that I see is that TI is just holding out. Who knows, with the release of OS 5.2 and the TI Inovator, there may be some sort of SDK for it, and while it may be very limited, it will still point us in a lot of the right directions. They may not have given us an SDK, but boy, most all of the routines in both the OS and bootcode have been named and given a place in ti84pce.Inc. It's up to us to keep the community alive, to keep discovering the new things and entry points. That's the joy I find in this

As I see it, the platform is very similar to that of the 68k series, where programs turned out to be the way to go. Sure, hooks are a little bit safer in the archive, but hooks get reset on a ram clear anyway so it is kind of a moot point.

TL:DR -- programs are better than apps for the eZ80 series

Actually his edit kinda brings up a good point. A lot of the younger users in the community tend to be enthusiastically open towards jailbreaks, but tend to not think of the consequences, and they often reply without providing enough arguments and counter arguments (eg a topic flooded with answers such as "Suck it TI! Ndless rulez!" might make it hard to follow the topic if it gets large), so if you are looking for well-thought and valid arguments in favor of or against a third-party OS hack or something, then perhaps it's better to ask an older audience. Of course DrDnar can miss out certain of the most prominent TI community members who don't check Cemetech regularly, though (eg Sorunome, Critor, aeTIos, Streetwalrus, Eiyeron), but I guess he can always PM or e-mail them if he wants more opinions.

You overstate the significance of a few people who want to write programs to their bottom line. Doubly so for TI as a whole compared to TI Education.

False dichotomy. The point is to create a tool that meets the stated goal. As long as such a thing exists, success has been had. This is not a security situation in which the goal is to put pressure on a vendor to fix an issue affecting their users but not the vendor themselves.

---

I'm of the opinion that there is no approach which can be expected to change the (unstated) position of TI on this issue (see my first point above). As such, the choice of action here should be guided by balancing utility to individuals seeking programmability and probability of reaction. Given my premise, any such reaction can be assumed to be technical in nature, fixing any bugs allowing circumvention of their protections.

Given the two proposed solutions, I'd favor taking the patch route at least initially. I also do not believe any obfuscation in use need be particularly strong; strong obfuscation may even inspire more skilled individuals to document elsewhere the method of operation. By comparison, an exploit with workings which are relatively plain to a skilled reader is still plenty opaque to an unskilled reader and does not invite puzzle-solving to undermine the original purpose of omitting detailed information on its working.

A patch offers notably superior usability, but has higher probability of reaction. This sets the bar high bar for a good initial implementation, because any response following the release of such a tool sets the pattern for any further events. If there is a fix to any used exploits we may assume the same reaction will follow for all future exploits, an arms race I don't think anybody is really interested in. If the arms-race wall is breached, the exploit-free approach remains open (barring the complete removal of user-programmability in an update, which I find extremely unlikely).

If they continue to refuse to talk, and also push OS updates that prevent our humble patch from working, then switching to the non-patching route might be a good idea, just for end-users' sake, so they don't have to keep track of which hacks work on what OSes. As I pointed out above, they haven't made any public statements that I know of saying that they oppose OS patches, so they can't reasonably tell us that we've done something they oppose. At the moment, all we really have is speculation and a few private, off-the-record comments.

Personally, to expand on Mateo's reflection, I'd be totally fine with programs only if they didn't have to be limited to 65k
I mean sure, it's not everyday you have such a big thing, but I have attempted ports that just don't fit in a single program, and would be a PITA to split and things. The best example I suppose would be Lua, which I manage to build for the eZ80, but in the end it was like 120 KB...

I know of use cases where apps are still better (regarding hooks, for instance), but I'm no (e)z80 coder myself, I rather merely make tools for for programmers themselves, rarely end-users.

I'd like to summarize my new position on these issues:

• Any statements community members have gotten privately from TI employees represent unofficial, off-the-record personal opinions, and should not be considered to represent TI Education's formal stance.
• We have a reasonable expectation for TI to make clear publicly their stance on these issues, if for no other reason than that's what you expect a reasonable person to do.
• In the absence of any public statement against OS patches (and for that matter, Ndless), we have reasonable plausible deniability to claim that we had no idea TI finds such things objectionable. Therefore, such things cannot be cited as a reason to withhold access for 3rd parties to write applications that can be run on unmodified calculators.
• TI cannot reasonably deny us access to programming tools and information because we might violate the wishes of teachers and exam boards if neither the exam boards nor TI tell us what those wishes are.
• In the event that TI does make a public statement against publishing a patcher, we should oblige and not publish a patcher.
• If TI does not make a public statement opposing a patcher in a timely manner, we should interpret that as acquiescence and proceed.
• While these issues have been brought up to some of our personal contacts, somebody should write an email to TI saying these things. We should make sure they cannot say that we didn't ask. Does anybody have an email address for somebody like Dale Philbrick or Peter Balyta? (I suppose I'll be the one writing this email.)