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.
Quoting my reply on TI-Planet:

Quote:
DrDnar: thanks for spending the time writing that message, but the other version was better Wink

The message remains mostly good, except for the two things IMO:
* the direct singling of BrandonW. I strongly resent it, and I wouldn't be surprised other people do as well;
* both you and me know that putting the pitchforks away is not going to be possible because for well-identified non-technical reasons, the prerequisites for most people dropping the pitchforks cannot be implemented... so it's no use trying to suggest to Peter Balyta that it can be done Smile
The only thing that might convince people to put the pitchforks away would be TI fully reversing its stance on both the availability of native code programs and the anti-downgrade protection. IOW, pretending, in the very near future, that OS 5.5.1 was a blunder that never should have existed. However, the history that both you and me are familiar with shows that TI is basically never backing off their bad moves... especially such importantly public moves as this one, with the exam regulators watching !
Knowledgeable / expert community members, and/or other security researchers, could definitely help TI - but only if users get something in return. There's got to be a carrot matching the stick.
In practice, the gloves are now permanently off, and the TI-eZ80 series castle will fall like a house of cards, since its design is far more insecure than e.g. the PS3, in which Sony did at least try to implement some protections.

In 2012, I did already warn top-level TI EdTech management about the pitfalls of excessive lockdown. To no avail.
Nice letter. Time for a bedtime story.

Once upon a time, NumWorks was put in a similar situation a couple of months ago with a blog post from a student who analysed the security of the NumWorks calculator (that is, none whatsoever). The post is technically sound but the issue was handled very poorly, with no responsible disclosure, which started to make the bad kind of waves in that country's ministry of education.

Once it was clear for NumWorks that things were starting to get out of control, they reached out to members of the community for advice. We identified a number of solutions and workarounds with different pros and cons. Every single one of them does not prevent running custom native apps nor custom firmwares on their hardware, since the openness of their calculators is a major selling point. The ending has yet to unfold, but I am confident that a solution that satisfies all involved parties will be reached.

Therefore, when Texas Instruments unilaterally decides to remove a major feature that people readily use from a product through a software upgrade, without reaching out to their community to find a solution that satisfies all involved parties beforehand, then says "we're keen to hear the community's input" and has the gall to ask "what would allow you to make powerful programs and games in Python as you would have done in ASM/C", fully aware that their Python implementation is a grossly underpowered squeaky toy that does not provide a migration path for any of the existing ASM/C programs people spent countless hours writing nor can act as a substitute for future developments by a very, VERY long shot, I call bullsh*t.

Peter Balyta, on the off-chance that you are reading Cemetech, a reasonable person can only reach two possible conclusions regarding the behavior of Texas Instruments:
  • Texas Instruments does not care one bit about their community, will preemptively throw them off the cliff at the first sign of remote danger and will try to shamelessly manipulate their community to get away with it ;
  • Texas Instruments actually sincerely cares, but somehow handled this in the worst possible way one could possibly have handled this. Seriously, you could not have chosen a more effective way to piss your customers off.

If Texas Instruments actually sincerely cares, then Texas Instruments better start showing it. Otherwise, any trust and credibility Texas Instruments had will be irremediably lost and people with act accordingly.

The clock is ticking.
Thanks a lot for telling that bedtime story to the public Smile
Lionel Debroux wrote:
Thanks a lot for telling that bedtime story to the public Smile

Desperate times call for desperate measures. If that does not work then nothing else will.
Lionel Debroux wrote:
DrDnar: thanks for spending the time writing that message, but the other version was better Wink
More heartfelt, perhaps, but if this has a near-zero chance of having any effect, well, the other version definitely has zero chance of having any effect.

Lionel Debroux wrote:
The message remains mostly good, except for [. . .] the direct singling of BrandonW. I strongly resent it, and I wouldn't be surprised other people do as well[.]
It's no secret that BrandonW hates restrictions simply because they are there. I believe like a decode ago he even published his own fake RAM clear tool. Rhetorically, it was useful to contrast a measured approach with his all-restrictions-are-bad attitude. (Which I don't disagree with, but I recognize the motivation for Test Mode, and I believe BrandonW does, too)

But I admit that phrasing makes him seem unduly unreasonable. He's been a valued member of the community and he's not one to try to sabotage other good-faith efforts, and I should have asked if he minded being the heel (so to speak) in this letter.

Lionel Debroux wrote:
However, the history that both you and me are familiar with shows that TI is basically never backing off their bad moves... especially such importantly public moves as this one, with the exam regulators watching !
That's definitely the trend I still expect to see continue, but we really want that to change and if we never reach out, we have only ourselves to blame. I really hope that Peter Balyta will try to argue that upsetting us will be thoroughly counter-productive. But yeah, I too am already planning my own approach to native code on the assumption that our offer will be rejected (and it's one which can't be blocked without completely rethinking their entire approach to hardware).

Lionel Debroux wrote:
Knowledgeable / expert community members, and/or other security researchers, could definitely help TI - but only if users get something in return. There's got to be a carrot matching the stick.
Well, yes, I do believe I argued that.

Lionel Debroux wrote:
In practice, the gloves are now permanently off
We need to give them a chance to change. Threatening them with weapons of mass disruption might feel empowering, but there's zero chance it could help our cause.
TI doesn't care. They will never care. You can be nice to them all day long, provide helpful examples and suggestions, and it will fall on deaf ears because all they care about is profits. So no, TI will never change their decision, nor will they decide to do anything differently.

It's time to move on and let it go.
I’d say drop naming BrandonW anywhere in the letter please
Neither critor, Adriweb, nor I have heard anything back from Peter Balyta. I really thought they'd at least be interested in hearing our thoughts about how security could be improved. But apparently even that is unacceptable? As this letter apparently does not even deserve a response (mokusatsu), it sounds like cooperation will never be an option.
DrDnar wrote:
... it sounds like cooperation will never be an option.


I'd say it never was. This is just the latest installment of TI being TI for the last decade or so.

Who knows, maybe the next update will remove TI-BASIC because it can be used to create games and therefore is an unnecessary distraction in the classroom Dry

Vote with your wallet. Because clearly they only care about money and nothing else.
Quote:
Who knows, maybe the next update will remove TI-BASIC because it can be used to create games and therefore is an unnecessary distraction in the classroom

Well, they should totally remove TI-Python as well, for the same reason Smile
Both the horribly small heap size and the horrendously slow graphics performance prevents the making of lots of games, even while leveraging TI's non-portable APIs. However, some other types of games (heck, probably even a low-featured form of "dealers"...) can be done in TI-Python.

As for cooperation: DrDnar should be commended for spending time trying to talk to TI management, so that (once again) it's not our side slamming the door shut... but the predictable outcode of nothing happening was known in advance, sadly.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement