4 ms·

This article should be read as ranty research, not practical advice. It'd be fine to fix these issues, but not at the website developer level. "If you have to

This article should be read as ranty research, not practical advice. It'd be fine to fix these issues, but not at the website developer level. "If you have to use externally hosted resources such as javascript libraries then at a minimum you should verify regularly that the code has not changed " No, you shouldn't. You should focus on stuff that matters to users, not existential internet security holes. Let someone else fix this problem for you, when it stops being existential. By far the safest approach for website owners that care about their users and their users privacy is to simply not include anything at all from other people’s servers. FTFY "A safe, but impractical and productivity-destroying aproach..."

rubiquity 11y ago
Your view on this screams "Tragedy of the Commons."
larrys 11y ago
Agree the advice is well intentioned and is correct (in theory according to what I read) but not entirely practical. For example: "then at a minimum you should verify regularly that the code has not changed (you have to hope that you are looking at the same code that your users see)" Who exactly is the "you" in the above statement and who pays the "you" money to fix this and keep on top of it on an ongoing basis? And for how long? In the physical world the different between ideal and practical can be described by my experience with production machinery. The machinery came with guards to protect the operators from getting their hands caught or cut off. The guards also came with switches to prevent the machines from running when the covers were taken off. But what would happen is the operators would want to oil or tweak the machines so they would take the covers off and disable the sensors so that the machine would run bare. Of course you would tell them not to do this, but they would still forget to put the covers back on or be lazy quite often and there was little you could do about it. You had production to get done under deadline and weren't likely to fire someone even though you knew there was a small safety risk in doing this type of thing (older machines of course came with no safety guards at all, operators just had to be careful at their own peril. (And good operators were impossible to find anyway so once you had someone they became a primadonna ..
- jacquesm 11y ago
  Regularly pulling a hash for the libraries you include and alerting you when a hash changes unexpectedly is no work at all. And if you need to be paid money to fix it then you have a problem anyway so one would assume that you'd be paid just as much to fix it when you're being alerted to it by a cron job as you would be paid to when you're alerted by a horde of users. As for machines without guards: I've worked (extensively) in the metal working industry and the number of people missing digits and limbs has decreased steadily ever since tampering with guards, safety-interlocks and lock-outs became a firing offense so I don't think that's a very good example.
  - larrys 11y ago
    Machines: Yes this was the 80's (sorry I didn't point that out my mistake) and things have changed. However to that point if you have your golden machine operator turning out good work (and he is only 1 of 2 on a particular line) and it's not easy to hire a replacement, let alone a good replacement, you tend to get a bit lax. Security: I am primarily a business guy (who does some light programming and knows Unix since the 80's) so I hire others to do work for me. I am just thinking that for the people that I have hired in the past how would anyone know if any of this is happening (other than code audits) and what is the mechanism to make sure the right thing happens even if you know what the right thing is? It's kind of a version of the advice "make backups but make sure that you test your backups as well".
    - jacquesm 11y ago
      The motto is 'trust but verify', and indeed that goes for your backups as well. And incidentally that's one of the most failed items during the dd's I've done and after verification several companies turned out to have lived without backups at all. It usually takes two things to go wrong for a disaster to happen: some $0.05 part that fails and a procedural error. And the consequences can be just about anything.
      - larrys 11y ago
jacquesm 11y ago
> This article should be read as ranty research, not practical advice. It'd be fine to fix these issues, but not at the website developer level. That's fine, it's only your users after all. > No, you shouldn't. You should focus on stuff that matters to users, not existential internet security holes. If you can fix a hole until that hole is plugged in a more permanent fashion then I think that you should. > FTFY "A safe, but impractical and productivity-destroying aproach..." Entirely practical and with minimal impact on your productivity. If you can find the time and expend the effort to build a product to begin with then you can certainly find the time and expend the effort to make a conscious decision about things like this. It matters enough to me that it affects my choices with respect to which parties I deal with on the internet and I sure hope I'm not the only person that thinks like that. And every time some user gets their day ruined by some formerly javascript widget hosting domain that got transfered to a new and malicious owner there is a bit more evidence to support that that approach is the right one. From the end users point of view as long as it works the two solutions are identical and if you're serving up megabytes of content anyway what's the big deal about serving up some scripts directly as well?
- andrewljohnson 11y ago
  No, the solutions are far from identical to the user. In Jacques' universe, websites are more buttoned up, and less feature-ful. Every non-banking, non-critical website is taking worthless security steps in secur-e-verse, and hurting their product. In the real universe, developers of new fluff websites focus on features and user experience, grow successful, and attract many users. Developers who takes Jacques approach build websites that fail and never get used by anyone. And also no, no, no.... no one is like you. No one cares if developers do what you propose, no one avoids websites that don't.
  - jacquesm 11y ago
    Explain to me like I'm five what features a website that hosts it's own javascript can't have versus one that loads those same javascripts from remote source?
    - 11y ago
lifeisstillgood 11y ago
Users assume the sites are safe and not malicious or open to attack. There are an enormous number of implicit contracts between us as developers and our users that are not written down but are still "stuff that matters to users". Ask a bank auditor if they think security holes does not count as "stuff that matters". Then try selling your services to said banks. It matters
Glyptodon 11y ago
I hope you don't develop any websites I use.

rubiquity 11y ago

Your view on this screams "Tragedy of the Commons."

larrys 11y ago

Agree the advice is well intentioned and is correct (in theory according to what I read) but not entirely practical. For example: "then at a minimum you should verify regularly that the code has not changed (you have to hope that you are looking at the same code that your users see)" Who exactly is the "you" in the above statement and who pays the "you" money to fix this and keep on top of it on an ongoing basis? And for how long? In the physical world the different between ideal and practical can be described by my experience with production machinery. The machinery came with guards to protect the operators from getting their hands caught or cut off. The guards also came with switches to prevent the machines from running when the covers were taken off. But what would happen is the operators would want to oil or tweak the machines so they would take the covers off and disable the sensors so that the machine would run bare. Of course you would tell them not to do this, but they would still forget to put the covers back on or be lazy quite often and there was little you could do about it. You had production to get done under deadline and weren't likely to fire someone even though you knew there was a small safety risk in doing this type of thing (older machines of course came with no safety guards at all, operators just had to be careful at their own peril. (And good operators were impossible to find anyway so once you had someone they became a primadonna ..

jacquesm 11y ago
Regularly pulling a hash for the libraries you include and alerting you when a hash changes unexpectedly is no work at all. And if you need to be paid money to fix it then you have a problem anyway so one would assume that you'd be paid just as much to fix it when you're being alerted to it by a cron job as you would be paid to when you're alerted by a horde of users. As for machines without guards: I've worked (extensively) in the metal working industry and the number of people missing digits and limbs has decreased steadily ever since tampering with guards, safety-interlocks and lock-outs became a firing offense so I don't think that's a very good example.
- larrys 11y ago
  Machines: Yes this was the 80's (sorry I didn't point that out my mistake) and things have changed. However to that point if you have your golden machine operator turning out good work (and he is only 1 of 2 on a particular line) and it's not easy to hire a replacement, let alone a good replacement, you tend to get a bit lax. Security: I am primarily a business guy (who does some light programming and knows Unix since the 80's) so I hire others to do work for me. I am just thinking that for the people that I have hired in the past how would anyone know if any of this is happening (other than code audits) and what is the mechanism to make sure the right thing happens even if you know what the right thing is? It's kind of a version of the advice "make backups but make sure that you test your backups as well".
  - jacquesm 11y ago
    The motto is 'trust but verify', and indeed that goes for your backups as well. And incidentally that's one of the most failed items during the dd's I've done and after verification several companies turned out to have lived without backups at all. It usually takes two things to go wrong for a disaster to happen: some $0.05 part that fails and a procedural error. And the consequences can be just about anything.
    - larrys 11y ago

jacquesm 11y ago

> This article should be read as ranty research, not practical advice. It'd be fine to fix these issues, but not at the website developer level. That's fine, it's only your users after all. > No, you shouldn't. You should focus on stuff that matters to users, not existential internet security holes. If you can fix a hole until that hole is plugged in a more permanent fashion then I think that you should. > FTFY "A safe, but impractical and productivity-destroying aproach..." Entirely practical and with minimal impact on your productivity. If you can find the time and expend the effort to build a product to begin with then you can certainly find the time and expend the effort to make a conscious decision about things like this. It matters enough to me that it affects my choices with respect to which parties I deal with on the internet and I sure hope I'm not the only person that thinks like that. And every time some user gets their day ruined by some formerly javascript widget hosting domain that got transfered to a new and malicious owner there is a bit more evidence to support that that approach is the right one. From the end users point of view as long as it works the two solutions are identical and if you're serving up megabytes of content anyway what's the big deal about serving up some scripts directly as well?

andrewljohnson 11y ago
No, the solutions are far from identical to the user. In Jacques' universe, websites are more buttoned up, and less feature-ful. Every non-banking, non-critical website is taking worthless security steps in secur-e-verse, and hurting their product. In the real universe, developers of new fluff websites focus on features and user experience, grow successful, and attract many users. Developers who takes Jacques approach build websites that fail and never get used by anyone. And also no, no, no.... no one is like you. No one cares if developers do what you propose, no one avoids websites that don't.
- jacquesm 11y ago
  Explain to me like I'm five what features a website that hosts it's own javascript can't have versus one that loads those same javascripts from remote source?
  - 11y ago

lifeisstillgood 11y ago

Users assume the sites are safe and not malicious or open to attack. There are an enormous number of implicit contracts between us as developers and our users that are not written down but are still "stuff that matters to users". Ask a bank auditor if they think security holes does not count as "stuff that matters". Then try selling your services to said banks. It matters

Glyptodon 11y ago

I hope you don't develop any websites I use.