5 ms·

And because you use crap hardware, everyone else has to change his totally legitimate network setup?

lillecarl 5y ago
I don't think it's because of this one person, but rather the masses that has crap hardware and software installed everywhere. It's a global problem, not everyone is capable of securing their own network.
- bawolff 5y ago
  Although i agree with this browser change, i highly doubt it will fix all crap hardware. There's a limit to how much you can apply band aid solutions to something that seems to be trying its hardest to be insecure, and non-idempotent GET requests is a bit beyond a minor oversight.
  - rocqua 5y ago
    Note that GET requests should be side-effect free. Not just idempotent. That means a GET request that turns your lights on, or opens your garage door (which is idempotent) is still wrong.
    - bawolff 5y ago
      Isn't that what idempotent means? You can't exactly open the garage if its already open. https://developer.mozilla.org/en-US/docs/Glossary/Idempotent https://developer.mozilla.org/en-US/docs/Glossary/Idempotent
      - marmight 5y ago
        In general, an idempotent method is a method such that calling it one time is the same as calling it n times in a row for any n > 1. However, idempotency doesn't require that calling the method one time is the same as calling it zero times, although such a method isn't excluded from the definition either. So a stateless method is necessarily idempotent, but an idempotent method isn't necessarily stateless.
      - vel0city 5y ago
        From your example: > DELETE /idX/delete HTTP/1.1 is idempotent, even if the returned status code may change between requests: So requesting to open the garage door multiple times which results in an open garage door in the end is an idempotent request, even though after the second request the response is "I am already open!" Now, a request to toggle the state of the garage door would not be idempotent. The state of the system is different if you call it an odd or even amount of times.
    - inetknght 5y ago
      > Note that GET requests should be side-effect free. Not quite. If a GET request is side-effect free then it won't be logged (since that is a side effect). GET requests aren't supposed to modify state. Logging is a side-effect but it isn't usually considered to be stateful. Changing the state (on/off) of a lightbulb is definitely against the standard requirements for a GET request.
      - nybble41 5y ago
        Logging is stateful, though the state usually isn't observable via HTTP requests. Of course the same is true of the light bulb, unless another API is provided to read its status, and a similar API could be provided for the log files. Or a script could toggle a light bulb in response to the logging. Perhaps a better way to express this is that user agents are permitted to turn one GET request into N GET requests (N >= 1), and can also issue GET requests without user interaction (e.g. for preloading). When this happens the system should still meet its (customer / end-user) requirements. The requirements related to logging are that every request is logged, so it makes sense to record each GET request separately. The requirements for the light bulb are that one user interaction (not one GET request) equals one state change, so updating the state in response to each GET request doesn't meet the requirements. Even if the API were explicitly "turn on" or "turn off" rather than "toggle" you still wouldn't want the state to be affected by preloading, and you could get odd results if opposing requests were repeated (interleaved).
  - PeterisP 5y ago
    Nothing will fix all crap hardware, so we have to live with it and solutions like this prevent crap hardware from being accessed and abused even if it remains crap forever (since it will remain crap).
- tommek4077 5y ago
  Just like not everyone is capable in handling explosives or build roadsafe cars or most other stuff by themselfes. We have rulings for this, laws, needed checks and so on. Start stopping the import of crap, like one does it with illegal firecrackers or in the past with eletronic stuff that interferes to much.
  - technobabbler 5y ago
    Are you suggesting regulating IOT devices for better security? Who the heck could you trust to do that? The FCC? The Chinese government? Consumer rights in the USA is barely a thing, and there is no competent bureaucracy for this sort of auditing. Creating some standards body and coming up with evolving criteria and hoping manufacturers will buy in seems like a multi year, if not multiple decade, process... In the meantime Google can single handedly monkey patch this situation within a few months and force manufacturers to catch up with the next product cycle. While a less ideal route, this seems far likelier to produce actual results within our lifetimes.
    - Retric 5y ago
      I find it really interesting how the US government can constantly solves very tricky real world problems that impact our lives, yet people have close to zero trust in it. Which isn’t to say you’re wrong here. I think it’s because when stuff works it looks simple. There isn’t an obvious difference between a mound of dirt piled up in days and one that’s carefully compacted as it’s constructed. At least until you want to build something on top that actually lasts for 50 years. Build stuff to last takes time and nobody is around to see you succeed. Back to your point actually fixing the underlying issues with IOT security is worth it long term even if it hypothetically takes 20 years to get it correct. At the same time moving quickly and patching one of 100,000 problems can still be useful.
      - technobabbler 5y ago
        > how the US government can constantly solves very tricky real world problems that impact our lives What are some recent examples? Especially dealing with technology? I can think of a bunch of counter-examples where the government did not do a good job of regulating: * Rural broadband failed * Net neutrality failed * Healthcare.gov was a fiasco * Wireless spectrum auction never got us municipal/rural long-range wireless * NASA's duties have largely been outsourced to private actors * State DMVs are a shitshow * Election integrity failed * They can't figure out what to do about online disinformation * Warrantless wiretapping: both unconstitutional yet ineffective, as in 9/11 and the lack of data sharing between agencies * Foreign military misadventures, our traditional forte: Afghanistan, Iraq, both abysmal failures * Healthcare: a joke compared to every other developed country * Education: pathetic and getting worse * Social programs: Welfare, what welfare? inequality and homelessness getting worse every year * Infrastructure: crumbling * Clean water: only for rich white people * Immigration: heh * Covid: lol * Renewables: haha * Nuclear: let's pretend it's not there On every major policy front, the US government has been a disaster for decades. I'm no libertarian by any stretch, but our government is a complete shitshow compared to any other developed democracy. We have neither the leadership competence (decisionmakers and legislators) nor the engineering talent (career civil servants) who can tackle something as diverse as nuanced as IoT security, or arguably, digital security in general. Give them 20 years and they might be able to catch up to 1990s netsec, and by then the manufacturers will be two decades ahead and foreign intelligence services even further beyond that. Our government is doomed, and taking us down with it.
kalleboo 5y ago
I'd wager the ratio of people who have at least one item of IoT junk to the number of people who have a legit setup that requires allowing cross site access to a local resource from a remote one is probably ten million to one. Who are these "everyone else" who are controlling their LAN devices from a public website who are going to suffer an evening setting up CORS? edit: what I can see breaking is stuff like Synology QuickConnect https://global.download.synology.com/download/Document/Software/WhitePaper/Firmware/DSM/All/enu/Synology_QuickConnect_White_Paper.pdf https://global.download.synology.com/download/Document/Softw...
- johnchristopher 5y ago
  > edit: what I can see breaking is stuff like Synology QuickConnect https://global.download.synology.com/download/Document/Softw https://global.download.synology.com/download/Document/Softw... Goooooood. I hate this thing with a passion since I had to set it up for a computer illiterate friend.
- vetinari 5y ago
  Also services using split horizon DNS: i.e. it is publicly available service, but only when used from outside. When used from inside, it is not routed through public interface, but resolved directly to it's internal IP.
  - wink 5y ago
    I'm pretty sure I'm lacking experience in administering a huge network to spot the obvious? problem, but for smaller setups I've never understood why you would do this anyway and not treat it as "external first" by putting it in a sort of DMZ and treat your internal users as "quasi-external" ones by routing them into the DMZ via another means... Of course this has the downside if you have actual 'internal only' stuff, but those could be separated from the split stuff... Just too much work with years (decades) old setups?
    - vetinari 5y ago
      In DMZ, it still has an IP from private range, ergo, still treated as internal -- it doesn't matter whether it is in the same subnet as your users, only whether it falls into the range that the browser considers private. So it doesn't solve anything here.

I don't think it's because of this one person, but rather the masses that has crap hardware and software installed everywhere. It's a global problem, not everyone is capable of securing their own network.

bawolff 5y ago
Although i agree with this browser change, i highly doubt it will fix all crap hardware. There's a limit to how much you can apply band aid solutions to something that seems to be trying its hardest to be insecure, and non-idempotent GET requests is a bit beyond a minor oversight.
- rocqua 5y ago
  Note that GET requests should be side-effect free. Not just idempotent. That means a GET request that turns your lights on, or opens your garage door (which is idempotent) is still wrong.
  - bawolff 5y ago
    Isn't that what idempotent means? You can't exactly open the garage if its already open. https://developer.mozilla.org/en-US/docs/Glossary/Idempotent https://developer.mozilla.org/en-US/docs/Glossary/Idempotent
    - marmight 5y ago
      In general, an idempotent method is a method such that calling it one time is the same as calling it n times in a row for any n > 1. However, idempotency doesn't require that calling the method one time is the same as calling it zero times, although such a method isn't excluded from the definition either. So a stateless method is necessarily idempotent, but an idempotent method isn't necessarily stateless.
    - vel0city 5y ago
      From your example: > DELETE /idX/delete HTTP/1.1 is idempotent, even if the returned status code may change between requests: So requesting to open the garage door multiple times which results in an open garage door in the end is an idempotent request, even though after the second request the response is "I am already open!" Now, a request to toggle the state of the garage door would not be idempotent. The state of the system is different if you call it an odd or even amount of times.
  - inetknght 5y ago
    > Note that GET requests should be side-effect free. Not quite. If a GET request is side-effect free then it won't be logged (since that is a side effect). GET requests aren't supposed to modify state. Logging is a side-effect but it isn't usually considered to be stateful. Changing the state (on/off) of a lightbulb is definitely against the standard requirements for a GET request.
    - nybble41 5y ago
      Logging is stateful, though the state usually isn't observable via HTTP requests. Of course the same is true of the light bulb, unless another API is provided to read its status, and a similar API could be provided for the log files. Or a script could toggle a light bulb in response to the logging. Perhaps a better way to express this is that user agents are permitted to turn one GET request into N GET requests (N >= 1), and can also issue GET requests without user interaction (e.g. for preloading). When this happens the system should still meet its (customer / end-user) requirements. The requirements related to logging are that every request is logged, so it makes sense to record each GET request separately. The requirements for the light bulb are that one user interaction (not one GET request) equals one state change, so updating the state in response to each GET request doesn't meet the requirements. Even if the API were explicitly "turn on" or "turn off" rather than "toggle" you still wouldn't want the state to be affected by preloading, and you could get odd results if opposing requests were repeated (interleaved).
- PeterisP 5y ago
  Nothing will fix all crap hardware, so we have to live with it and solutions like this prevent crap hardware from being accessed and abused even if it remains crap forever (since it will remain crap).
tommek4077 5y ago
Just like not everyone is capable in handling explosives or build roadsafe cars or most other stuff by themselfes. We have rulings for this, laws, needed checks and so on. Start stopping the import of crap, like one does it with illegal firecrackers or in the past with eletronic stuff that interferes to much.
- technobabbler 5y ago
  Are you suggesting regulating IOT devices for better security? Who the heck could you trust to do that? The FCC? The Chinese government? Consumer rights in the USA is barely a thing, and there is no competent bureaucracy for this sort of auditing. Creating some standards body and coming up with evolving criteria and hoping manufacturers will buy in seems like a multi year, if not multiple decade, process... In the meantime Google can single handedly monkey patch this situation within a few months and force manufacturers to catch up with the next product cycle. While a less ideal route, this seems far likelier to produce actual results within our lifetimes.
  - Retric 5y ago
    I find it really interesting how the US government can constantly solves very tricky real world problems that impact our lives, yet people have close to zero trust in it. Which isn’t to say you’re wrong here. I think it’s because when stuff works it looks simple. There isn’t an obvious difference between a mound of dirt piled up in days and one that’s carefully compacted as it’s constructed. At least until you want to build something on top that actually lasts for 50 years. Build stuff to last takes time and nobody is around to see you succeed. Back to your point actually fixing the underlying issues with IOT security is worth it long term even if it hypothetically takes 20 years to get it correct. At the same time moving quickly and patching one of 100,000 problems can still be useful.
    - technobabbler 5y ago
      > how the US government can constantly solves very tricky real world problems that impact our lives What are some recent examples? Especially dealing with technology? I can think of a bunch of counter-examples where the government did not do a good job of regulating: * Rural broadband failed * Net neutrality failed * Healthcare.gov was a fiasco * Wireless spectrum auction never got us municipal/rural long-range wireless * NASA's duties have largely been outsourced to private actors * State DMVs are a shitshow * Election integrity failed * They can't figure out what to do about online disinformation * Warrantless wiretapping: both unconstitutional yet ineffective, as in 9/11 and the lack of data sharing between agencies * Foreign military misadventures, our traditional forte: Afghanistan, Iraq, both abysmal failures * Healthcare: a joke compared to every other developed country * Education: pathetic and getting worse * Social programs: Welfare, what welfare? inequality and homelessness getting worse every year * Infrastructure: crumbling * Clean water: only for rich white people * Immigration: heh * Covid: lol * Renewables: haha * Nuclear: let's pretend it's not there On every major policy front, the US government has been a disaster for decades. I'm no libertarian by any stretch, but our government is a complete shitshow compared to any other developed democracy. We have neither the leadership competence (decisionmakers and legislators) nor the engineering talent (career civil servants) who can tackle something as diverse as nuanced as IoT security, or arguably, digital security in general. Give them 20 years and they might be able to catch up to 1990s netsec, and by then the manufacturers will be two decades ahead and foreign intelligence services even further beyond that. Our government is doomed, and taking us down with it.

kalleboo 5y ago

I'd wager the ratio of people who have at least one item of IoT junk to the number of people who have a legit setup that requires allowing cross site access to a local resource from a remote one is probably ten million to one. Who are these "everyone else" who are controlling their LAN devices from a public website who are going to suffer an evening setting up CORS? edit: what I can see breaking is stuff like Synology QuickConnect https://global.download.synology.com/download/Document/Software/WhitePaper/Firmware/DSM/All/enu/Synology_QuickConnect_White_Paper.pdf https://global.download.synology.com/download/Document/Softw...

johnchristopher 5y ago
> edit: what I can see breaking is stuff like Synology QuickConnect https://global.download.synology.com/download/Document/Softw https://global.download.synology.com/download/Document/Softw... Goooooood. I hate this thing with a passion since I had to set it up for a computer illiterate friend.
vetinari 5y ago
Also services using split horizon DNS: i.e. it is publicly available service, but only when used from outside. When used from inside, it is not routed through public interface, but resolved directly to it's internal IP.
- wink 5y ago
  I'm pretty sure I'm lacking experience in administering a huge network to spot the obvious? problem, but for smaller setups I've never understood why you would do this anyway and not treat it as "external first" by putting it in a sort of DMZ and treat your internal users as "quasi-external" ones by routing them into the DMZ via another means... Of course this has the downside if you have actual 'internal only' stuff, but those could be separated from the split stuff... Just too much work with years (decades) old setups?
  - vetinari 5y ago
    In DMZ, it still has an IP from private range, ergo, still treated as internal -- it doesn't matter whether it is in the same subnet as your users, only whether it falls into the range that the browser considers private. So it doesn't solve anything here.