First, "threat modelling" is a very broad, I'd even say "umbrella" term. It ranges, basically, from creating a simple google sheet document "what could go wrong" to a complicated graph-based quantitative modelling.
And I would say, you get more value from the simple spreadsheet. The rest is complicated voodoo which takes a lot of resources and still gives you quite ambiguous results. But it is fun to do as well.
STRIDE is nice, and it is kind of de facto standard, but when it comes to classifying actual threats you would notice that everything is interconnected. You cannnot separate one letter in STRIDE from another in most threat scenarios you encounter! Spoofing leads you to tampering, elevation of privilege to information disclosure and finally you try to arrange the whole mess in a minimally comprehencible way. So I would say, what you are actually interested in is not classifying everything in STRIDE or making complicated attack graphs, but trying to identify threat "building blocks" like a software bug or a workstation compromise and build a few typical "worst-case" scenarios around that.
See also "Crown Jewel Analysis" and "ATT&ACK", both would help you much. Feel free to contact me if you need more assisitance :)
Stage seven: we probably need more smooth cookie consent management UX integrated into the browsers.. oh wait they had it from the day 0 and it was dropped because everyone agreed it is useless.
> > And when it matters, it's just being ignored.
> Where is that? Though you're welcome to point those out to your country regulator.
Blanket forced consent in terms "we need to track you because we have a business need, take that or leave", despite being explicitly prohibited in all GDPR-related guidelines is still something you get away with.