4 ms·

That old post has a heavy emphasis on the problem being "undocumented features", which is absurd, since most Microsoft products have undocumented features. Thes

That old post has a heavy emphasis on the problem being "undocumented features", which is absurd, since most Microsoft products have undocumented features. These often intended for use in automated testing, or used internally by the software, or for use only by the developers and support personnel. SQL Server's `DBCC WRITEPAGE` is a great example of the latter. There are plenty of APIs intended only for Microsoft to use. There are significant features locked away by registry settings with zero documentation. Windows itself even has entire APIs that were explicitly designed and intended for external that are effectively undocumented. The real issue is easter eggs (or any code) that a developer snuck in without approval. Sadly, the post goes on to claim that even approved easter eggs should not be shipped (with the implication that them being undocumented is the problem), but that is absurd. Better cease all development on Windows/Azure/Office for the next decade so that all the undocumented features can be properly documented.

lwansbrough 6y ago
Not a great example IMO. Any accessible API is a public API once it’s released into the ether. Inevitably people build on those undocumented features (or come to expect them to exist) and it’s not sufficient for Microsoft or whoever to day “oops too bad, you built on a private API” because ultimately they would be disrupting their customers. I’m not against easter eggs though, you just have to be okay with the prospect of breaking expectations users may have in the future.
- yellowapple 6y ago
  > and it’s not sufficient for Microsoft or whoever to day “oops too bad, you built on a private API” because ultimately they would be disrupting their customers. Uhhh, that seems perfectly sufficient to me. Play stupid games (like relying on undocumented APIs), win stupid prizes (like watching everything break when those APIs change). Private interfaces should be used as a last resort, and with the full understanding that - being private - they have no obligation to be "stable".
userbinator 6y ago
There's a difference between "undocumented undocumented", which is what Easter eggs usually are, and plain undocumented (what you're referring to.)
- cmeacham98 6y ago
  Serious question: from my perspective as the user what is the difference?
  - plasma 6y ago
    I understand the main concern is related to security, if code (a team member's secret easter egg) is shipped unbeknownst to the development lifecycle (code review, QA, etc) then a security exploit may have just (accidentally) been included with the product. I'd imagine if the easter egg was a documented feature (eg, scoped by product managers, went through security review, etc) perhaps it would be fine.
    - PeterisP 6y ago
      In many products 'easter eggs' were well planned by the developing company, they're just not documented for the end-user and left there for them to discover. However, it probably made more sense in the pre-mass-internet age.
    - Talanes 6y ago
      >The real issue is easter eggs (or any code) that a developer snuck in without approval. Sadly, the post goes on to claim that even approved easter eggs should not be shipped (with the implication that them being undocumented is the problem), but that is absurd. I think the poster you replied to originally had this covered.
unnouinceput 6y ago
Heh, this is benign. Now imagine the "Easter Eggs" that Intel/AMD/ARM has in their processors, the ones of undocumented CPU instructions that allows an attacker to elevate to kernel privilege. With Specter/Meltdown the world has only scratched the tip of the iceberg, with more to come in following decade.
skissane 6y ago
> The real issue is easter eggs (or any code) that a developer snuck in without approval. Sadly, the post goes on to claim that even approved easter eggs should not be shipped (with the implication that them being undocumented is the problem), but that is absurd. Developers still slip “undocumented features” into code all the time. I think it is ultimately a public relations and legal liability issue. If you add an undocumented feature, and you have a plausible argument as to how doing it serves the needs of the business (e.g “it dumps diagnostics useful in debugging customer issues”), it is much easier to defend yourself (and for your management to defend you) if that code later causes problems (whether security or performance or whatever) than if you embed a flight simulator. It is about the CYA of having a believable business purpose to what you did, which is helpful both in courts of law and the court of the media. A lot of places nowadays you need at least one PR review from a peer to merge code. Still you can end up with a feature that only two or three people know exist (the author and the PR reviewers) In my experience “undocumented features” often happen because the original specs don’t go into details about issues like diagnosability, etc, often because PM/design teams write the specs but only the implementing developers have a good idea of what useful diagnostics actually are. Maybe the developers should go back and update the spec but they very often don’t
vl 6y ago
> That old post has a heavy emphasis on the problem being "undocumented features", which is absurd, since most Microsoft products have undocumented features. Context is important here. As part of anti-trust deal, MS had to document all APIs and file formats, and there was a massive internal effort to do so. Basically it’s not allowed to call non-public APIs from one MS product to another. On top of that there was massive security push when entire Windows division stopped working on new version and concentrated on security of XP for many months. After these traumas there was no way Easter eggs would survive.

lwansbrough 6y ago

Not a great example IMO. Any accessible API is a public API once it’s released into the ether. Inevitably people build on those undocumented features (or come to expect them to exist) and it’s not sufficient for Microsoft or whoever to day “oops too bad, you built on a private API” because ultimately they would be disrupting their customers. I’m not against easter eggs though, you just have to be okay with the prospect of breaking expectations users may have in the future.

yellowapple 6y ago
> and it’s not sufficient for Microsoft or whoever to day “oops too bad, you built on a private API” because ultimately they would be disrupting their customers. Uhhh, that seems perfectly sufficient to me. Play stupid games (like relying on undocumented APIs), win stupid prizes (like watching everything break when those APIs change). Private interfaces should be used as a last resort, and with the full understanding that - being private - they have no obligation to be "stable".

userbinator 6y ago

There's a difference between "undocumented undocumented", which is what Easter eggs usually are, and plain undocumented (what you're referring to.)

cmeacham98 6y ago
Serious question: from my perspective as the user what is the difference?
- plasma 6y ago
  I understand the main concern is related to security, if code (a team member's secret easter egg) is shipped unbeknownst to the development lifecycle (code review, QA, etc) then a security exploit may have just (accidentally) been included with the product. I'd imagine if the easter egg was a documented feature (eg, scoped by product managers, went through security review, etc) perhaps it would be fine.
  - PeterisP 6y ago
    In many products 'easter eggs' were well planned by the developing company, they're just not documented for the end-user and left there for them to discover. However, it probably made more sense in the pre-mass-internet age.
  - Talanes 6y ago
    >The real issue is easter eggs (or any code) that a developer snuck in without approval. Sadly, the post goes on to claim that even approved easter eggs should not be shipped (with the implication that them being undocumented is the problem), but that is absurd. I think the poster you replied to originally had this covered.

unnouinceput 6y ago

Heh, this is benign. Now imagine the "Easter Eggs" that Intel/AMD/ARM has in their processors, the ones of undocumented CPU instructions that allows an attacker to elevate to kernel privilege. With Specter/Meltdown the world has only scratched the tip of the iceberg, with more to come in following decade.

skissane 6y ago

> The real issue is easter eggs (or any code) that a developer snuck in without approval. Sadly, the post goes on to claim that even approved easter eggs should not be shipped (with the implication that them being undocumented is the problem), but that is absurd. Developers still slip “undocumented features” into code all the time. I think it is ultimately a public relations and legal liability issue. If you add an undocumented feature, and you have a plausible argument as to how doing it serves the needs of the business (e.g “it dumps diagnostics useful in debugging customer issues”), it is much easier to defend yourself (and for your management to defend you) if that code later causes problems (whether security or performance or whatever) than if you embed a flight simulator. It is about the CYA of having a believable business purpose to what you did, which is helpful both in courts of law and the court of the media. A lot of places nowadays you need at least one PR review from a peer to merge code. Still you can end up with a feature that only two or three people know exist (the author and the PR reviewers) In my experience “undocumented features” often happen because the original specs don’t go into details about issues like diagnosability, etc, often because PM/design teams write the specs but only the implementing developers have a good idea of what useful diagnostics actually are. Maybe the developers should go back and update the spec but they very often don’t

vl 6y ago

> That old post has a heavy emphasis on the problem being "undocumented features", which is absurd, since most Microsoft products have undocumented features. Context is important here. As part of anti-trust deal, MS had to document all APIs and file formats, and there was a massive internal effort to do so. Basically it’s not allowed to call non-public APIs from one MS product to another. On top of that there was massive security push when entire Windows division stopped working on new version and concentrated on security of XP for many months. After these traumas there was no way Easter eggs would survive.