CubeIDE forcing you to login to ST [...] - Follow up

CBerg · ‎2024-05-21

The original Thread "CubeIDE forcing you to login to ST ...", opened by @JDoe.2 in August 2023 with 37 Kudos for JDoe

got shut down (flagged as read-only) today with a last statement by @Amel NASRI which is marked as "Solution".

Congratulations ST, now I am really upset. Now I know you read the community postings, you just prefer to ignore them if they are annoying. Flagging a thread as read only and posting an "alibi" technical solution where the thread clearly shows that thread was not about technical issues in common, but your customers do not want to be forced to log in to use your product is an affront against all those people who spoke out against those new policies.

Please take this posting as my formal protest against your action.

Edit: shortened Title to reflect the note from Amel

CBerg · ‎2024-09-02

Long time no update! Has ST finally removed that sh***y mandatory login? Or do they still insist in annoying their users?

STOne-32 · ‎2024-11-26

Dear @CBerg , @Techn @JDoe.2 @unsigned_char_array @Pavel A.,

I wanted to share these actions that we are implementing to Try to make our STM32 Developers experience more appropriate and simple while Downloading then Installing and using STM32CubeIDE here :

https://www.st.com/en/development-tools/stm32cubeide.html

Action 1: implemented already - we limit the download options to only last 4 versions. In case of older versions requested - to contact us via Online Support .

>> This will reduce the Web page hangs in some browsers and configuration and we launch it for a testing purpose till end of the Year with full monitoring of the downloads.

Action 2 : After installation and while using the STM32CubeIDE we limit the Login and user authentification to “Only” downloading operations as follow starting for Today release V1.17.0.

I know this is not yet an optimal solution for long term that needs more engineering effort but some incremental changes to make the less frustrated customers and developers . Your voice Matters I wanted to thank all of you as we are listening and taking your feedback in actions .

Happy Thanksgiving to you and your family

Ciao

STOne-32

CBerg · ‎2024-11-26

even if it's not the optimal solution: you heard us and you did not give a f*** on your users like many other big tech corps do. There is hope ;) Thanks and take my kudo.

CBerg · ‎2024-11-27

BTW: @STOne-32 - as you mentioned a redesign of the download options on the ST website: logging in there for downloading the IDE or other software was never a problem for me. For me the main issue - as discussed in this thread and the ancestor thread - was always just the issue with the mandatory login in the IDE, not on the website.

This mandatory login in the CubeIDE gives the user the feeling ST could shut that software down - or limit its function to render it useless - if the user-account is closed/suspended (for what ever reason) which - de facto - gives ST the power to decide if someone can work with their tools or not, after the client made the decision to work with ST MCUs / tools.

For me, this would be "life threatening", I would potentially loose the work of years, including the redesign of several PCBs, if you would do this. And empowering yourself to be capable of doing that feels like someone is running behind me with a loaded gun pointing on me. I really don't like that, and therefore you got this strong form of protest, with strong words ;)

Besides that: my issue with the ST website is, that I use Firefox with several addons for privacy and javascript blocking, plus a PiHole and I barely can get to the login form, because your website is so messed up with trackers, analytics and all that stuff from external domains. I have to pull my "pants down" completely and be lucky to get it running with Firefox, or use Edge with almost no restrictions.

JDoe.2 · ‎2025-07-20

@CBerg you were right, my friend. I'm returning to the forums because I’m frustrated that ST doesn’t address the work that directly supports our needs.

@CBerg wrote:
This mandatory login in the CubeIDE gives the user the feeling ST could shut that software down - or limit its function to render it useless - if the user-account is closed/suspended (for what ever reason) which - de facto - gives ST the power to decide if someone can work with their tools or not, after the client made the decision to work with ST MCUs / tools.

CubeIDE 1.19 is out and guess what? You can't use CubeIDE 1.18.1 anymore to create new projects. I first noticed it last week at work but I thought our IT department had fudged something up as they do at least twice a month. Except now I'm seeing the same thing at home on my own machine.
Try it on your end, people: if you still have 1.18.1, try to create a new project. You shall find that you can only create a blank project. The STM32Cube option is grayed-out:

I observed this on Win10 and Win11, and for any target device. The only fix is to update to 1.19.
This means ST does indeed mess with your local installation of CubeIDE. There's definitely potential for a kill switch.
There's already a thread about this, I'm not the first one to have noticed. I posted a reply in my usual clam and measured style...

https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-stm32cube-project-creation-issue/td-p/823125

This has to stop. We have to find a way to bring ST to reason one way or another.

JDoe.2 · ‎2025-07-20

So. I tried giving ST a piece of my mind on the thread about that issue. To no one's surprise, my reply doesn't appear on the forum. Gee I wonder why.

Meanwhile, I fired-up an old virtual machine I use for experiments. It's a Win10 and has CubeIDE 1.12 on it. Before booting it, I disabled its network connectivity.

I launched Cube IDE, went to create a new project, and the first thing that happened was this dialog box:

I said no, of course, and then picked an MCU and wouldn't you know:

So yeah, ST put a kill switch in their tools. If your work depends on it, I suggest backing up your installers and setting everything up in a VM. For your information, VMWare is free and works perfectly well with tools like CubeIDE. Moreover it supports USB passthrough for your STLINK and other needs.

I think we need to start taking matters into our own hands. We should start an effort to collect all past installers for all ST tools, including Cube libraries, and put them somewhere safe where we can all access them and back them up. I started doing so as far back as CubeIDE 1.12 and will gladly contribute.

As for my VM... I'm half tempted to clone it, give the clone internet access, and see if CubeIDE gets lobotomized. But I have better things to do with my time and ST has yet again wasted too much of it. If it happens, I'll let you know. It's just safe to assume no install of CubeIDE is safe.

EDIT: I was so pissed-off I did clone my VM and give it internet access. Started CubeIDE 1.12, started a new project, and now the Cube option is grayed out. There was no message or anything about updating or downloading something. Even as far as 1.12, CubeIDE phoned home every single time you used it.

I will have words with my contacts at ST about this. I am now beyond fuming and I will give people bad days over it. The enshitification of this world has to stop.

CBerg · ‎2025-07-20

>>Started CubeIDE 1.12, started a new project, and now the Cube option is grayed out. There was no message or anything about updating or downloading something. Even as far as 1.12, CubeIDE phoned home every single time you used it.<<

This is a very bad development. And it makes me very nervous.

If ST has really implemented kill switches, what is the purpose of those? I hope this is just a misconfiguration of some updater config files or something ...

If ST would be so kind and make a statmement about this matter, and if this behaviour is by intent, please explain the intentions of their decisions and their implications!

STOne-32 · ‎2025-07-20

Dear @CBerg , @JDoe.2

Thank you very much for bringing to our attention this outstanding recent issue impacting old versions already installed. Our Technical teams just found the root-cause of this weird behavior and are working for a fix.

It seems a change on a product database naming on one production server, thus responsible of this behavior. We will be back to you with more details, once fixed.
https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-stm32cube-project-creation-issue/td-p/823125

Thanks again.

STOne-32

CBerg · ‎2025-07-20

Dear @STOne-32

thank you for reacting so quickly, and thank you for pointing out clearly that this is was a mistake and will be fixed soon. I can relax again now and i hope @JDoe.2 can relax now, too :)

best regards and have a nice evening (if you live in my timezone).

JDoe.2 · ‎2025-07-20

@CBerg is more diplomatic than I am. My own feeling is:

Oh HELL no, @STOne-32 ! Forget the cookie-cutter LLM-written corpo messaging.

I've had enough. I have ZERO INTEREST in spending the rest of my career in fear every time I start an ST tool that it will suddenly stop working or do something else to block me from working. I don’t care about whatever made-up or real technical reason. I need a solution and a guarantee. If you can't provide either, I'll make my own, after all I'm an engineer. It's what we do.

I think we'd all like to know why CubeIDE has to phone home every time we start a new project. Clearly, my experiment proves that it is not required in order to start a project. So then we'd all like to know why, if internet is available, CubeIDE feels necessary to update something without telling us.

Since ST is intent in wasting my time and everyone else's, fine, that's how it's gonna be. I'll have to try and track down with WireShark whatever tools do and which machines they talk to behind our backs. Your company has a really bad attitude towards its clients since at least 2020. Let me remind everyone, when I complained about mandatory login in CubeIDE and explained why many industries can't comply with that, I got dozens of "kudos" and then your "community manager" shut down the thread, marked it as "solved" and even edited its title to something different. It's like 1984.

Meanwhile, you manage to break features that used to work. Case in point: used to be, if you started a project for a Nucleo, all the MCU pins would be muxed to match the hardware on the board. Now you've decided this worked too well, so what did you do ? Deleted all that and replaced it with a half-assed "BSP" tab that only covers LED's, the user button and a UART. Now if I want to create a project for a NUCLEO-H745 I have to mux the pins for the Ethernet MAC, USB, etc... myself. Do you have any idea how much time this has wasted for everyone?

But instead of fixing that, you spy on us. For the 1756th time, PLEASE, DO NOT ENABLE TELEMETRY BY DEFAULT. Everytime I have to install one of your downgrades (sorry, they can't be called updates), I (and everyone else) have to navigate into settings menu to turn it off. Do we need to get the EU on your asses to make you respect the RGDP? Is this a literacy problem on your end? Can't you save my refusal in the many things you surely track on your "production servers"?

I'm seriously going to look into how to lobotomize your tools until they do what I want, when I want. You do not get to mess with my machine, my work and my schedule. I pay for those tools through component purchases. The least you could do is respect me as a customer. Or I can just recommend NXP and Infineon for all future projects I'm involved in. You were not my first MCU supplier, nobody says you have to be the last.

At this point, all trust is lost. You should make CubeMX, in fact all your tools, open source. Eclipse already is, so are your libraries. Then perhaps better people than you can make it work as it should. And least we'll be able to know what's in it, what it does, and trust there won't be any surprises.