I see the chosen language of "certain unregistered applications" (I suppose company mandated) already hints on the goal of control aspect. I want to deploy apps on my device. They are my apps, it’s my device, and I should not be required to ask for permission to do so.
Is it a lock? I buy a building and the builder put an id verification lock on the doors and I am not allowed to remove it. And they also require a separate one time fee of 2 to 5 percent of the purchase price.
In physical world, there’s only so many people who can rob you if you do something stupid (like constantly give away copies of your keys to strangers), they will be very noticeable when they are doing so, and if you feel like something’s off you can always change the lock.
On the Internet, an you are fair game to anyone and everyone in the entire world (where in some jurisdictions even if it’s known precisely who is the figurative robber they wouldn’t face any consequences), you could get pwned as a result of an undirected mass attack, and if you do get pwned you get pwned invisibly and persistently.
Some might say in these circumstances the management company installing a (figurative) biometric lock is warranted, and the most reliable way to stop unsuspecting residents from figuratively giving access to random masked strangers (in exchange for often very minor promised convenience) is to require money to change hands. Of course, that is predicated on that figurative management company 1) constantly upping their defences against tenacious, well-funded adversaries across the globe and 2) themselves being careful about their roster of approved trusted parties, whom they make it easy to grant access to your premises to.
The trouble with your analogy is that physical reality works the same way. People have been committing mail fraud since the advent of post offices. Spies have been planting bugs on delivered goods since the invention of bugs. The thing that causes this isn't digital devices, it's long-distance delivery of goods and messages.
Meanwhile installing software on your own device is the thing that isn't that. They're preventing it even when you're the owner of the device and have physical access to it. They're not installing a lock so that only you can get in, they're locking you out of your own building so they can install a toll booth on the door.
All of your examples require, to successfully attack one target, a level of effort (hiring human spies and keeping them happy so that they don’t whistleblow or swap sides, planting physical bugs, etc.) vastly incomparable with a level of effort required to attack millions upon millions of targets; and just as incomparably higher stakes of an unsuccessful operation (actual people going to jail, versus being perfectly safe in a jurisdiction that does not extradite).
totally my point here. The actual shape of the thing starts mattering so much that at one point your metaphor is just completely useless for judging the actual tradeoffs
I haven't seen that before. But it was really hard get to the end. Not because it's bad written or so, on the contrary is a very good piece. However the feeling is unfathomable. I hate Julius'es. More so I hate the managers blinded by Julius'es.
Unfortunate result of the security theater.. "Someone who has access to run privileged application can run side channel attacks! Let's drop cpu performance 20 percent over the world"
As I understood it’s enough to have “access to run privileged application” anywhere where the packet goes through. So, not necessarily at client or server sides. Or did I misunderstand?
The point I wanted to emphasize is that even if you do overcomplicate your DOM, the component abstraction is what allows you to fix it in one place. Don't like what's in your component — add `return <input />`, bam! It's fixed across the entire app now.
And how is the surrounding JS code, like the event handlers, and the CSS of the component supposed to still work now? A radio input will need at the very least additional CSS to remove the native appearance. Unlikely that was set already --> it's not that easy.
The idea is that the component's API is not the DOM. Usually this means your data should flow in a certain way: top-down.
Application code is not supposed to use the DOM as the source of truth for some boolean state that the checkbox is an input for.
You don't usually read a component's state from outside (here: the "checked" property).
Instead you define an API where data only flows top-down.
When your checkbox component follows this paradigm, it is "controlled", and if it contains a standard HTML input, that input's "checked" DOM object property is bound to the data passed into the component ("props"). Clicking it won't check it anymore until you add an "onClick" callback and pass a function into this callback that will make the "checked" prop change.
The checkbox is now "controlled" and it's state was "lifted up" (meaning that it is determined not by the checkbox component itself).
"controlled" means you tell React to always force the "checked" DOM property to be the same as the "checked" prop you pass into the component. You do this by assigning to the reflected "checked" HTML attribute in JSX.
When your components only use this "top-down" data flow, they're "pure" in React lingo. Because they look like pure functions: props => DOM fragment. The machinery behind the scenes means they're not actually that (something has to coordinate the rendering).
But if you don't use internal state (e.g. useState hook) or global stores, these "impure" parts are React internals only, and you can have a mental model that views the component like a pure function.
This makes it easier to connect it with other components in a tree.
For example:
HTMLInputElement.checked can be true without a "checked" attribute being in the markup.
If you want to have some text next to it that says "checked / not checked" you have to wire stuff, and this stuff depends on your markup.
If you have a "controlled" checkbox, you have a tree, not only for the markup, but also for the data: the boolean "checked" state can now be declared one level above both the info text and the checkbox. Then the info text doesn't care at all about events anymore.
And the checkbox component only uses a callback that is also independent from the exact markup structure (e.g. a selector for the HTML input element).
You don't need to read from the checkbox to update the text. You feed both with a boolean and both can be "pure" components. The checkbox gets a "onClick" callback and it's checked state is no longer internal, it's "controlled".
The wiring you have to do instead of the regular DOM events (which would read the input's state) is now to use your "onClick" callback to toggle your boolean.
Internally, in the component, you do whatever you need to read and write to the DOM. But usually that just means "what markup do I return".
Input elements and reflected attributes such as "checked" are already a relatively complex case.
And, you can escape the recommended top-down data flow by many means (refs, context, accessing centralized "stores" from within the component...), but that's often where it gets ugly. But you need to do it often when your app gets bigger (centralized data stores), or when you implement things like UI libraries (refs).
reply