8 ms·

Neat article, interesting that suggestions for sane defaults in rails were more-or-less ignored until the problem was demonstrated to easily impact a wide user-

by daguava 11y ago

Neat article, interesting that suggestions for sane defaults in rails were more-or-less ignored until the problem was demonstrated to easily impact a wide user-base.

venomsnake 11y ago
That is how the world works. Proactive security is expensive and it brings no obvious value to the people that manage organization resources. "A problem is only a problem when it materializes" - that is the way some people think.
jldugger 11y ago
That was the source of lolz at the time it happened. If anything, the article demonstrates how little you need to know to break things. In a way, it's a miracle anything works around here.
- jacquesm 11y ago
  "If engineers built buildings and bridges the way programmers write software the first woodpecker that would come along would destroy civilization."
  - chrisan 11y ago
    That is kind of unfair :) Typically infrastructure engineers get to (or rather have to) over-engineer things. When you build a bridge you don't build something that is _just_ good enough to hold X cars. You design it to hold X + Y% and/or have Z redundancy Most software doesn't put peoples lives in danger and thus doesn't get the budget/resources to put in NASA like engineering in software
    - jacquesm 11y ago
      That's why our motto is 'move fast and break things' right?
      - simoncion 11y ago
        That's sure as fuck not my motto. ;)
        jacquesm 11y ago
        Thank you.
    - tonyarkles 11y ago
      A lot of engineering is about meeting requirements while keeping costs down. As the joke goes... "Anyone can build a bridge that stands; it takes an engineer to build a bridge that just barely stands"
      - enraged_camel 11y ago
        I realize it's a joke, but even then it's not a good one. The reality is actually the other way around. Anyone can build a bridge that barely stands, but it takes an engineer to build one that still stands after an earthquake.
        tonyarkles 11y ago
        Uhhhh... see https://en.wikipedia.org/wiki/List_of_Roman_bridges https://en.wikipedia.org/wiki/List_of_Roman_bridges I'm not sure if the original designers intended for these to have multi-millenia design lives, but I bet that they could have been made much cheaper...
        enraged_camel 11y ago
        If they were made much cheaper, they likely would not be standing today.
        tonyarkles 11y ago
        Precisely! Engineering usually isn't about designing the best X, it's about designing the cheapest X that meets all of its requirements. Edit: even if the requirement is for X to be the best in the world (which, as a non-quantifiable requirement, makes me uneasy), the goal would still be to do it as cost effectively as possible.
  - wglb 11y ago
    Lots of folks chuckled at this when it was first said, but then in the late 90s, the were not chuckling at y2k.
    - jacquesm 11y ago
      As late as 1986 someone reprimanded me for 'wasting two bytes' in a record.
- golergka 11y ago
  The more I learn about security, the faster I want to run away from anything related to it. Being a client-side developer in gamedev (i.e. a space that's not as sensitive to security as a lot of other industries) feels so good.
  - simoncion 11y ago
    > Being a client-side developer in gamedev (i.e. a space that's not as sensitive to security as a lot of other industries) feels so good. :( A buggy and/or vulnerable game client or server is generally just as hazardous as most any other buggy or vulnerable software.
    - golergka 11y ago
      Buggy game client can only be hazardous if the client/server architecture is built incorrectly — and at least that is not hard to avoid. (Screams "DON'T TRUST THE CLIENT" in the architecture meetings usually help.)
      - simoncion 11y ago
        > (Screams "DON'T TRUST THE CLIENT" in the architecture meetings usually help.) Yeah, except that in many (most?) modern games you can't have a fully-untrusted client... for performance reasons you have to give the client too much information. From what I understand, getting that balance just right is rather tough. :( > Buggy game client can only be hazardous... Don't forget that the vast majority of games pass data to 3D graphics card drivers which are terrible, awful, and somewhere between hardly and not at all concerned with security. A bug in a game could hard-lock your system, [0] or lead to code execution in kernelspace. (Not to mention the usual host of problems a buggy program that has read/write access to everything that the system user it's running as, and generally full network access has.) [0] Despite Windows 7's graphics card driver fault isolation system, I've had a couple of graphics-related hard-lockups in the many years I've been using my gaming PC.

by daguava 11y ago

Neat article, interesting that suggestions for sane defaults in rails were more-or-less ignored until the problem was demonstrated to easily impact a wide user-base.

venomsnake 11y ago

That is how the world works. Proactive security is expensive and it brings no obvious value to the people that manage organization resources. "A problem is only a problem when it materializes" - that is the way some people think.

jldugger 11y ago

That was the source of lolz at the time it happened. If anything, the article demonstrates how little you need to know to break things. In a way, it's a miracle anything works around here.

jacquesm 11y ago
"If engineers built buildings and bridges the way programmers write software the first woodpecker that would come along would destroy civilization."
- chrisan 11y ago
  That is kind of unfair :) Typically infrastructure engineers get to (or rather have to) over-engineer things. When you build a bridge you don't build something that is _just_ good enough to hold X cars. You design it to hold X + Y% and/or have Z redundancy Most software doesn't put peoples lives in danger and thus doesn't get the budget/resources to put in NASA like engineering in software
  - jacquesm 11y ago
    That's why our motto is 'move fast and break things' right?
    - simoncion 11y ago
      That's sure as fuck not my motto. ;)
      - jacquesm 11y ago
        Thank you.
  - tonyarkles 11y ago
    A lot of engineering is about meeting requirements while keeping costs down. As the joke goes... "Anyone can build a bridge that stands; it takes an engineer to build a bridge that just barely stands"
    - enraged_camel 11y ago
      I realize it's a joke, but even then it's not a good one. The reality is actually the other way around. Anyone can build a bridge that barely stands, but it takes an engineer to build one that still stands after an earthquake.
      - tonyarkles 11y ago
        Uhhhh... see https://en.wikipedia.org/wiki/List_of_Roman_bridges https://en.wikipedia.org/wiki/List_of_Roman_bridges I'm not sure if the original designers intended for these to have multi-millenia design lives, but I bet that they could have been made much cheaper...
        enraged_camel 11y ago
        If they were made much cheaper, they likely would not be standing today.
        tonyarkles 11y ago
        Precisely! Engineering usually isn't about designing the best X, it's about designing the cheapest X that meets all of its requirements. Edit: even if the requirement is for X to be the best in the world (which, as a non-quantifiable requirement, makes me uneasy), the goal would still be to do it as cost effectively as possible.
- wglb 11y ago
  Lots of folks chuckled at this when it was first said, but then in the late 90s, the were not chuckling at y2k.
  - jacquesm 11y ago
    As late as 1986 someone reprimanded me for 'wasting two bytes' in a record.
golergka 11y ago
The more I learn about security, the faster I want to run away from anything related to it. Being a client-side developer in gamedev (i.e. a space that's not as sensitive to security as a lot of other industries) feels so good.
- simoncion 11y ago
  > Being a client-side developer in gamedev (i.e. a space that's not as sensitive to security as a lot of other industries) feels so good. :( A buggy and/or vulnerable game client or server is generally just as hazardous as most any other buggy or vulnerable software.
  - golergka 11y ago
    Buggy game client can only be hazardous if the client/server architecture is built incorrectly — and at least that is not hard to avoid. (Screams "DON'T TRUST THE CLIENT" in the architecture meetings usually help.)
    - simoncion 11y ago
      > (Screams "DON'T TRUST THE CLIENT" in the architecture meetings usually help.) Yeah, except that in many (most?) modern games you can't have a fully-untrusted client... for performance reasons you have to give the client too much information. From what I understand, getting that balance just right is rather tough. :( > Buggy game client can only be hazardous... Don't forget that the vast majority of games pass data to 3D graphics card drivers which are terrible, awful, and somewhere between hardly and not at all concerned with security. A bug in a game could hard-lock your system, [0] or lead to code execution in kernelspace. (Not to mention the usual host of problems a buggy program that has read/write access to everything that the system user it's running as, and generally full network access has.) [0] Despite Windows 7's graphics card driver fault isolation system, I've had a couple of graphics-related hard-lockups in the many years I've been using my gaming PC.