Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be careful of the examples you use. They stick

blog.thinkst.com

Post reply on HN
Print view View original

51–60 of 129 posts

Re: Be careful of the examples you use. They stick

#51

Post by jxf »

pdw wrote: post #25
saurik wrote: post #19

Earlier quoted context omitted.

Omg, I just read the documentation for erasedups and I'm actually shocked anyone would want that feature turned on, to the point where it never even would have occurred to me to implement it in the first place and if the feature worked like that without some way to turn it off I'd have been super angry :(. Maybe we are parsing that sentence wrong and by "shouldn't be necessary to set" the idea is "it is useful in sit…

Now I'm confused. Why would you want duplicate entries in your command history? I get that on an overloaded system in the 80s it might have taken a perceptable amount of time to filter out duplicates. But on a modern system you surely want it always enabled?

I think the people who leave it on see it as "rewriting history" -- e.g., if you typed [cmd1], [cmd1], [cmd2], and you erase duplicates, your history no longer reflects what you actually typed. The people who leave it off see the history as more like "a list of interesting things I did at some point", so erasing duplicates means it's easier to find the most interesting things.

Re: Be careful of the examples you use. They stick

#52

Post by fastball »

This isn't quite the point of the article, but we allow people to apply for student discounts for our service, and provide the following example that we ask users to send to us over Intercom:

> Hello, could I please apply for the student discount?

>

> [PLEASE READ AND DELETE THIS – After sending this initial message, please attach a proof of your student status, such as a photo of your valid Student ID so we can process this quicker!]

I don't think any of the countless people that have asked for the discount have ever removed the "PLEASE REMOVE" part, and many don't bother to send the proof until we ask for it either.

Re: Be careful of the examples you use. They stick

#53

Post by Cyykratahk »

azeemba wrote: post #43
tialaramex wrote: post #40

Earlier quoted context omitted.

There is also an entire TLD, .example so that you can put multiple names in a TLD and distinguish big-corp.example from my-local-store.example and it's clear that those aren't related, they just share a registry the same way as letsencrypt.org and wikipedia.org do

example.com is officially reserved in the spec for this use case. Is the .example TLD reserved as well?

Yes, here are the reserved TLDs [0]:

    test
    example
    invalid
    localhost
    local
    localdomain
    domain
    lan
    home
    host
    corp
0. https://www.ietf.org/archive/id/draft-chapin-rfc2606bis-00.h...

Re: Be careful of the examples you use. They stick

#54

Post by lornajane »

This is such a great story and an important one. I always optimise examples for people copying and pasting, trying to make it as safe and meaningful by default as possible. It doesn't matter why you're copying and pasting - you may not have a lot of skills in this specific area, or you might be in a hurry. If you know what you're doing, you can probably improve the code, but if you use it as-is, it shouldn't come back to bite you!

Re: Be careful of the examples you use. They stick

#55

Post by happimess »

azeemba wrote: post #43
tialaramex wrote: post #40

Earlier quoted context omitted.

There is also an entire TLD, .example so that you can put multiple names in a TLD and distinguish big-corp.example from my-local-store.example and it's clear that those aren't related, they just share a registry the same way as letsencrypt.org and wikipedia.org do

example.com is officially reserved in the spec for this use case. Is the .example TLD reserved as well?

It seems true, according to [0]

      ".test" is recommended for use in testing of current or new DNS related code.
      ".example" is recommended for use in documentation or as examples.
      ".invalid" is intended for use in online construction of domain that are sure to be invalid and which it is obvious at a are invalid.
      The ".localhost" TLD has traditionally been statically defined in DNS implementations as having an A record pointing to the back IP address and is reserved for such use.  Any other use conflict with widely deployed code which assumes this use.
[0] https://datatracker.ietf.org/doc/html/rfc2606

Re: Be careful of the examples you use. They stick

#56

Post by kibwen »

azeemba wrote: post #43
tialaramex wrote: post #40

Earlier quoted context omitted.

There is also an entire TLD, .example so that you can put multiple names in a TLD and distinguish big-corp.example from my-local-store.example and it's clear that those aren't related, they just share a registry the same way as letsencrypt.org and wikipedia.org do

example.com is officially reserved in the spec for this use case. Is the .example TLD reserved as well?

.example, .invalid, .local, .localhost, .onion, and .test are all "special use" domains.

https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...

"ICANN/IANA has created some Special-Use domain names which are meant for special technical purposes. ICANN/IANA owns all of the Special-Use domain names."

Re: Be careful of the examples you use. They stick

#57

Post by RegW »

codeflo wrote: post #31
assbuttbuttass wrote: post #30

> When given an example, a significant number of users default to using that same example in their customisation. The behaviour is consistent across customers and configurations. This surprised us! This is not surprising to me at all. Maybe the authors have never used an example before?

Well, I’m also the sort of person who wouldn’t. Similarly, I also never copy&paste example code when reading documentation, instead, I immediately jump into writing my own variation. It took me a while to realize that’s not typical.

Often examples don't make it clear what is expected. As a consequence you might copy the example value temporarily until your understanding solidifies, but it never does, or doesn't before it gets a dependency on it.

So foo.bar.com or my-subdomain.example.com?

Re: Be careful of the examples you use. They stick

#58

Post by l33t7332273 »

ThalesX wrote: post #48
chasd00 wrote: post #38

I gave what my company calls a “lunch and learn” presentation once of some interesting tools. People liked it and shared my deck around which was cool. But then my quick/dirty examples started showing up in best practice (I loathe that term) decks shared to very large teams with my name at the bottom. A security guy, who I greatly respect, raised some questions and I had to go through the whole story with him and the…

I did a similar thing as part of a "lunch and learn". NodeJS + Express was super fresh and I did a small example app. When returning the user profile, I just queried the database and returned the entry displaying some properties on the frontend. The team lead was like "show us the request in the console", and I opened it up and there was the non-encrypted password, createdAt date and basically all the not-needed prop…

I don’t think that’s so bad. It’s a demo, not an end product.

Re: Be careful of the examples you use. They stick

#59

Post by recursivetech »

A few years back, I recall reading about some automotive manufacturers who had just copied an example "airbag arming authorization" code/value that appeared in a shared spec document (IIRC) for their vehicles. There was a Metasploit module created (for the Hardware Bridge) that would send CAN bus messages to just check/verify if a particular vehicle uses this insecure arming code. For vehicles using this known code, an attacker with CAN bus access could deploy airbags on an unsuspecting target during vehicle operation. https://www.rapid7.com/blog/post/2017/12/22/metasploit-wrapu...

Re: Be careful of the examples you use. They stick

#60

Post by velosol »

thaumasiotes wrote: post #22
l0b0 wrote: post #11

This is also an opportunity to think about the value of a piece of configuration. If an example configuration value works for 40% of users without modification, should that value even exist? Think Bash's `HISTCONTROL=erasedups`, which shouldn't be necessary to set in the 21st century. Or should it be auto-generated, like Docker's container names? In the very best case, the defaults are so good that an empty configura…

> This is also an opportunity to think about the value of a piece of configuration. If an example configuration value works for 40% of users without modification, should that value even exist? This sounds completely insane. If a majority of people need something different, they shouldn't be allowed to have it?

I read it slightly differently: those 60% can set one of the other values and the default value no longer exists but is simply the default so the 40% who previously had to set that value now don't.
Post reply on HN