Now there is a more or less sophisticated permission system which users then bypass by still accepting any prompt if you promise them anything shiny...
I actually am less against these ideas on the phone. Quite the contrary, I think I'm largely agreed that more efforts need to be done to let people control those.
I am also sadly skeptical that this works, there. I've seen my family that is all too eager to just click "ok" on whatever an app says it needs. :(
I've actually seen this in the wild this year. It was placed at a train station in a small town in southern Germany, which presumably did not have a physical bank branch. It was exactly as you said: basically a chair, keyboard and screen in a tiny building (not much larger than a phone booth).
I really enjoyed Storytelling with Data: A Data Visualization Guide for Business Professionals
by Cole Nussbaumer Knaflic. The author really breaks down the individual elements of good/bad visualizations using case studies with lots of actionable advice. Highly recommended.
The point that the others are trying to make is that these questions are not relevant in the context of the backend technology choices. The REST or GraphQL endpoints could be handled by monkeys writing bits via typewriters and it wouldn't affect the CPU usage in your browser.
For me the central benefit is that you can create them in a distributed manner and are not reliant on a central system as a single source of truth for creating your identifiers.
I can therefore easily generate a new UUID in a trusted backend service which just accepts the command received from the untrusted client and then forwards the request for asynchronous processing while returning the UUID to the client. This is a typical architecture and the only change is that I can now create UUIDs which may have performance benefits, depending on the data storage technology of my read models.
If you need to create the UUIDs on the client side to support specific requirements such as offline-first, then I would indeed consider adding some reconciliation which replaces the IDs provided by the client-side by new ones generated by a trusted component as soon as synchronizing takes place.
In any case regardless of UUIDv4, v7 or any other format you should not allow the untrusted client to determine the real ID - as long as there is at least one trusted component in the architecture which would take over this role. This should help eliminate a whole set of possible security issues.
I can't remember any specifics I'm afraid, it was probably 10+ years ago. I remember being prompted to change it (either by mail or in the client), I never did and I never logged in either. The account is gone. Since it was that long ago I can't rule out simply misremembering.
As the author of arc42 writes in the article, the order of the chapters does not imply the order in which they should be decided upon and written.
In addition he writes that you might have already documented the most important decisions as part of the solution strategy chapter.
Most importantly, pick and choose based on your own judgement and experience those parts that you need and make it your own - in my experience arc42 has always been a good starting point when starting fresh or as a reference when evaluating existing documentation.
Just as a heads up: to my knowledge that's not correct in Germany. It's only highly unlikely to get "abgemahnt" in addition to the difficulty of obtaining IP addresses of users in comparison to alternatives such as Torrents. But not getting caught != legal.
Streaming from a „offensichtlich rechtswidrige Vorlage“ (§ 53 UrhG.) is not legal. That has been clarified by a decision from the EuGH in 2017.
I'm not a lawyer though and this isn't legal advice. Let me know if there have been verdicts and legal proceedings stating the contrary.
As a random example, see this one ( https://www.welivesecurity.com/2017/04/19/turn-light-give-pa... ) which is a banking trojan cosplaying as a flashlight widget.
Now there is a more or less sophisticated permission system which users then bypass by still accepting any prompt if you promise them anything shiny...