These past few days, there has been a lot of discussion on the recent removal of certain cherished features from our favorite eZ80-based calculators. In response, I've sent the following the letter directly to Dr. Peter Balyta, with endorsement from Adriweb and Critor. Please, Cemetech, feel free to show your support in this thread.
Quote:
Dear Peter Balyta,
I must admit I found the recent decision to remove third-party native code (i.e. C and assembly) support from the TI-84 Plus CE line baffling. It is true that Texas Instruments Education Technology and our programming community have somewhat different interests, but I believe that our community can offer Texas Instruments something very useful.
Without any direct contacts in Texas Instruments, I have long believed that Texas Instruments merely tolerates us. Yet, Christopher Mitchell and Adrien Bertrand have both told me that they have good relationships with you, and that you support our desire to write programs. Some of us, like Christopher, also enjoy teaching programming skills; others, like Matt Waltz, remain only interested in programming.
I recognize that your interest lies in teaching mathematics. Our passion, however, is in programming. We enjoy the challenge of writing games for hardware poorly suited to gaming; it is not the games themselves we enjoy, but rather the challenge of making them. And surely all your employees in your Education Technology division can understand that.
Removing support for third-party native code does not remove this challenge. Indeed, it adds a new, interesting challenge for us. But it is not a challenge we want to have.
From what I gather, the main argument for removing support for native code is that doing so will improve exam security. I find this argument odd because we, the senior members of the programming community, do agree that tools that defeat exam security are bad. We have already proven ourselves to be experts at finding security holes, and in the past, when we have noticed exploits that directly impact exam security, we have notified you. Conversely, even when we have resorted to hacks, we have tried to respect Test Mode, such as with Matt Waltz working with Adrien and Xavier to add code to Cesium so that even if people modify it to run in Test Mode, it will refuse to launch restricted apps and programs.
When Texas Instruments received complaints about a method for bypassing Test Mode, why did you not ask us if we had ideas on how to address the problem? I suspect the reason is that we have not made it clear that our interest is not specifically in games, but in the challenge. Identifying and fixing Test Mode bugs is also a challenge most of us could enjoy. Rather than try to thwart us, you should employ us.
True, some of us, like Brandon Wilson, have already started preparing pitchforks and torches. In fact, people I have never known to have any negative sentiment toward Texas Instruments or interest in vulnerability analysis have started already finding exploits. Others, like Christopher and me, are more inclined to stop working on any projects we had planned. And this is dangerous for Texas Instruments, because without cooler heads active in the community, people like Brandon Wilson will feel free to release tools specifically designed for cheating. After all, it is now much more difficult to say that holding back is good for the community’s relationship with Texas Instruments.
Conversely, actively inviting community feedback on exam security will encourage everyone – including the naysayers! – to work to improve exam security. Major technology giants like Microsoft and Google have found that inviting the public to hunt for security flaws makes their products better. Many even run a bug bounty program that rewards people who report problems with cash. We are not asking for money. Something as simple as a public Web page acknowledging our help fixing issues would help us feel appreciated and show people opposed to our programming community that we are actually helpful. But without support for native code, doing so would be asking us to work against our own interests.
Furthermore, to use the parlance of security experts, removing native code support actually makes your attack surface for exploits far, far larger. Previously, you only had to worry about weaknesses in specific parts of the OS and boot code that could bypass your security model. Now, every single line of code in the OS, boot code, and every application is a potential weak point that could be used to run native code. You still need to fix the old exploits, because they may allow downgrading; but now, in addition, you also need to identify and fix every other possible bug in every single line of code written for the TI-84 Plus CE series. If you do not, your claim that you have improved exam security will seem hollow.
Personally, in the past I have complained about seemingly solvable performance issues. I do not know if your engineers saw those complaints and responded to them, but I was heartened to see that Texas Instruments seems to have taken those complaints seriously, for calculators produced in 2019 now have a new architecture featuring a cache. Nonetheless, I still see serious performance bottlenecks that could be resolved. I would love to have the opportunity to talk with your engineers directly and help address such issues, and hear why some engineering decisions were made. I find such discussions fascinating, and I can think of no business reason why information such as the addition of a cache should be kept secret by a non-disclosure agreement.
And indeed, I have already identified a way to implement downgrade protection in a manner that no native code we write can bypass. Surely supporting native code and allowing your engineers to discuss freely with us the challenges they face implementing Test Mode security will benefit everyone. As the Nspire community has shown with Ndless, an adversarial relationship will frustrate everyone and benefit no one.
I hope you can explain to institutions that the downgrade tool was written by the same loose group of enthusiasts that also notified you of the Test Mode bug that Yvan Monka demonstrated, and that we followed the industry-standard (for computer security) responsible disclosure practice of not publishing our finding until you had a chance to fix it. You might also point out that the downgrade tool was written not to allow students to bypass Test Mode, but because some of us were afraid that the disabling of the Asm84CEPrgm token was a prelude to broader restrictions.
Please, tell educators that we are not motivated by a desire to promote cheating, we are motivated by creativity and a desire to confront challenges. Tell educators that you believe the best way to address their concerns about exam security is to embrace us as partners, not shun us as adversaries. Tell educators we are competent engineers, and it benefits everyone for Texas Instruments to accept us as powerful allies instead of scorning us as potent enemies.
Give us the opportunity to help. Make a public statement so we can convince people to put their pitchforks away. Let this be an opportunity for cooperation.
I must admit I found the recent decision to remove third-party native code (i.e. C and assembly) support from the TI-84 Plus CE line baffling. It is true that Texas Instruments Education Technology and our programming community have somewhat different interests, but I believe that our community can offer Texas Instruments something very useful.
Without any direct contacts in Texas Instruments, I have long believed that Texas Instruments merely tolerates us. Yet, Christopher Mitchell and Adrien Bertrand have both told me that they have good relationships with you, and that you support our desire to write programs. Some of us, like Christopher, also enjoy teaching programming skills; others, like Matt Waltz, remain only interested in programming.
I recognize that your interest lies in teaching mathematics. Our passion, however, is in programming. We enjoy the challenge of writing games for hardware poorly suited to gaming; it is not the games themselves we enjoy, but rather the challenge of making them. And surely all your employees in your Education Technology division can understand that.
Removing support for third-party native code does not remove this challenge. Indeed, it adds a new, interesting challenge for us. But it is not a challenge we want to have.
From what I gather, the main argument for removing support for native code is that doing so will improve exam security. I find this argument odd because we, the senior members of the programming community, do agree that tools that defeat exam security are bad. We have already proven ourselves to be experts at finding security holes, and in the past, when we have noticed exploits that directly impact exam security, we have notified you. Conversely, even when we have resorted to hacks, we have tried to respect Test Mode, such as with Matt Waltz working with Adrien and Xavier to add code to Cesium so that even if people modify it to run in Test Mode, it will refuse to launch restricted apps and programs.
When Texas Instruments received complaints about a method for bypassing Test Mode, why did you not ask us if we had ideas on how to address the problem? I suspect the reason is that we have not made it clear that our interest is not specifically in games, but in the challenge. Identifying and fixing Test Mode bugs is also a challenge most of us could enjoy. Rather than try to thwart us, you should employ us.
True, some of us, like Brandon Wilson, have already started preparing pitchforks and torches. In fact, people I have never known to have any negative sentiment toward Texas Instruments or interest in vulnerability analysis have started already finding exploits. Others, like Christopher and me, are more inclined to stop working on any projects we had planned. And this is dangerous for Texas Instruments, because without cooler heads active in the community, people like Brandon Wilson will feel free to release tools specifically designed for cheating. After all, it is now much more difficult to say that holding back is good for the community’s relationship with Texas Instruments.
Conversely, actively inviting community feedback on exam security will encourage everyone – including the naysayers! – to work to improve exam security. Major technology giants like Microsoft and Google have found that inviting the public to hunt for security flaws makes their products better. Many even run a bug bounty program that rewards people who report problems with cash. We are not asking for money. Something as simple as a public Web page acknowledging our help fixing issues would help us feel appreciated and show people opposed to our programming community that we are actually helpful. But without support for native code, doing so would be asking us to work against our own interests.
Furthermore, to use the parlance of security experts, removing native code support actually makes your attack surface for exploits far, far larger. Previously, you only had to worry about weaknesses in specific parts of the OS and boot code that could bypass your security model. Now, every single line of code in the OS, boot code, and every application is a potential weak point that could be used to run native code. You still need to fix the old exploits, because they may allow downgrading; but now, in addition, you also need to identify and fix every other possible bug in every single line of code written for the TI-84 Plus CE series. If you do not, your claim that you have improved exam security will seem hollow.
Personally, in the past I have complained about seemingly solvable performance issues. I do not know if your engineers saw those complaints and responded to them, but I was heartened to see that Texas Instruments seems to have taken those complaints seriously, for calculators produced in 2019 now have a new architecture featuring a cache. Nonetheless, I still see serious performance bottlenecks that could be resolved. I would love to have the opportunity to talk with your engineers directly and help address such issues, and hear why some engineering decisions were made. I find such discussions fascinating, and I can think of no business reason why information such as the addition of a cache should be kept secret by a non-disclosure agreement.
And indeed, I have already identified a way to implement downgrade protection in a manner that no native code we write can bypass. Surely supporting native code and allowing your engineers to discuss freely with us the challenges they face implementing Test Mode security will benefit everyone. As the Nspire community has shown with Ndless, an adversarial relationship will frustrate everyone and benefit no one.
I hope you can explain to institutions that the downgrade tool was written by the same loose group of enthusiasts that also notified you of the Test Mode bug that Yvan Monka demonstrated, and that we followed the industry-standard (for computer security) responsible disclosure practice of not publishing our finding until you had a chance to fix it. You might also point out that the downgrade tool was written not to allow students to bypass Test Mode, but because some of us were afraid that the disabling of the Asm84CEPrgm token was a prelude to broader restrictions.
Please, tell educators that we are not motivated by a desire to promote cheating, we are motivated by creativity and a desire to confront challenges. Tell educators that you believe the best way to address their concerns about exam security is to embrace us as partners, not shun us as adversaries. Tell educators we are competent engineers, and it benefits everyone for Texas Instruments to accept us as powerful allies instead of scorning us as potent enemies.
Give us the opportunity to help. Make a public statement so we can convince people to put their pitchforks away. Let this be an opportunity for cooperation.
