Comment by dogma1138 | Hacker News Reader

Comment by dogma1138 | Hacker News Reader

Parent Full thread

The only problem is see if this is “tested” in production is having features that aren’t yet fully ready either form a technical or business perspective and relying on “security through obscurity” to prevent them from being used.

Say you are adding new features those might be exposed in a API prior to have the UI components that facilitate the user interaction directly this isn’t enough to prevent the user from accessing them if there are no additional controls on the backend.

Even worse I would bet good money that for web applications many teams would add UI components and use the “hidden” attribute as a keystone and even if they don’t add any direct UI elements they quite likely to add the JavaScript functions that facilitate those before exposing their trigger in the UI.

Let’s say a user notices that submit order POST requests now have another field “rush_order=false” what happens when it’s set to true?

Sure you can say well the businesses logic would handle this but then you need to make your business logic “aware” of this type of a development which means the keystone isn’t the UI anymore.

This type of development can expose you to various business, legal and security risks if there aren’t excellent controls behind it.

Hide the API away too? You don't need to add another field to an existing API while in development, use a different endpoint altogether, to obscure the fact that it even exists. Then, part of the "keystone" can be merging it with the existing API.

This is very specific to your example, but I guess my point is it is almost always possible to design your in-progress state in a way such that new features are obscured.

For systems in which there is no meaningful way to distinguish users (or say, non-returning customers), these concerns are certainly worth addressing.

Consider, however, cases where the company has long term relationships with customers; say, industries where real customer support is in place. In these cases, an infrastructure for “feature toggles” is extremely helpful, because you can turn on the feature for specific customers (or developers for testing!), or certain segments of customers (e.g. early access customers). In such an infrastructure, there is no “security through obscurity”; you’re authorizing transactions on the backend (based on whether specific users are allowed to use the feature), and merely enabling the UI on the front end based on user whitelists.

Incidentally, once this is in place it’s just another half step to implement phased releases, or A/B testing. Makes rolling back easy too.

These are possible problems, but they are unique to this pattern. It's worth being aware of these risk of for sure, but they all have may have mitigations: - The app may be internal - The API maybe gated by as API gateway, and the new APIs exposed at a later time. - APIs should always be coded to have security in depth, it should not matter if the UI is enabled or not.

It's not about delivering changes that are not fully ready to be in production. It's about breaking down a larger change, and delivering it in chunks, as and when each one is fully ready.

Odds are that very few people would notice it (the "obscurity" part).

If it's a requirement that such features absolutely cannot be invoke by end users in advance of release, it seems like you could always use access control or feature toggles in front of the new backend API. It's important to be aware of such a requirement, but I don't think the fact that some use cases have this requirement gets in the way of "Keystone Interface" as a concept.

Reply on news.ycombinator.com