4 ms·

So what happens when your browser crashes? I experience that on a regular basis. Id' rather have my browser crash/killed instead of slowly overwriting my filesy

So what happens when your browser crashes? I experience that on a regular basis. Id' rather have my browser crash/killed instead of slowly overwriting my filesystem buffers or corrupting my stack pointer... Other than that browser are multi-thread/process applications. Usually only a single tab or a plugin crashes unless core browser process is affected. Most users would accept the trade off between crashed browser and infected/corrupted system.

jhasse 9y ago
> or corrupting my stack pointer... in that case, it will crash with a SIGSEGV sooner or later anyway
- Slavius 9y ago
  ...or is being remotely exploited and it silently succeeds. Who wants that?
  - jhasse 9y ago
    That is very unlikely. Crashing would happen 100% of the time though. Most people want that trade-off (meaning: If their browser would crash, they would switch to another one, even it was less secure).
    - Slavius 9y ago
      Corrupting SP is part of almost every exploit and I can guarantee you that it is very likely (going to cause harm on your system). Try to pull Metasploit GIT repo to get some idea about thousands of payloads that do corrupt SP without crashing the host...
      - jhasse 9y ago
        Yes, but how many of all cases of corrupted stack pointers are exploits?
        jessaustin 9y ago
        Why would that matter? We're not trying to be secure against random cosmic rays. We're trying to be secure against attackers. http://wondermark.com/406/ http://wondermark.com/406/
        jhasse 9y ago
        It matters because we're talking about letting the browser crash on all cases. > We're trying to be secure against attackers. We also want a browser that doesn't crash.
    - TickleSteve 9y ago
      Stack pointer manipulation is the entry point for an extremely large subset of security issues.
mythz 9y ago
> Most users would accept the trade off between crashed browser and infected/corrupted system. Most users are using computing devices a means of getting stuff done. They don't want to spend any energy thinking about how their software works, they want their devices to be invisible, which they use to run their Apps uninterrupted. The trade-off is whether to let Apps continue running vs hard crashing and taking down all the work they've done and all the mental energy and focus invested up to that point. If their Apps frequently crash most users aren't thinking, well I'm super glad the hours I spent on this paper I'm working on is now lost, the phone calls to my loved ones or movie I'm watching are abruptly terminated because someone's policy on hard crashing when a bug is found has been triggered. Their preferences and purchasing power are going to go towards non user-hostile devices they perceive provide the best experience for using their preferred Apps without any need for pre-requisite knowledge of OS internals. There's not a single computing device that frequently crashes as a result of security hardening that will be able to retain any meaningful marketshare. Users are never going tolerate anything that requires extraneous effort on their part into researching and manually applying what needs to be done to get their device running without crashing.
- Slavius 9y ago
  Apps are supposed to keep their state either by saving your work regularly to persistent media or keeping your data off-client. We're living in 21st century in a cloud era FFS. Keep running your app although integrity corruption within the application happened is putting user data at risk. IMHO an application that corrupts 3 days long presentation file save is to every user more frustrating than the one that crashes due to error leaving you with 5 minutes of unsaved changes lost. Microsoft have invented "Application Recovery and Restart" exactly for this purpose.
  - mythz 9y ago
    > Keep running your app although integrity corruption within the application happened is putting user data at risk. If user data is continually backed up to a remote site it's not going to be at risk from a local bug is it? Bugs exist in all software, Users are going to be be more visibly frustrated from their Apps frequently crashing then the extremely unlikely scenario where a detected bug corrupts their "3 days long presentation". They're going very unhappy if the cause of their frequent data loss was due to a user-hostile setting to hard crash on the first detectable bug. > Microsoft have invented "Application Recovery and Restart" exactly for this purpose. From Microsoft website: > An application can use Application Recovery and Restart (ARR) to save data and state information before the application exits due to an unhandled exception or when the application stops responding. - https://msdn.microsoft.com/en-us/library/windows/desktop/cc948909%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/cc9... i.e. restarting Apps due to "unhandled exception or when the application stops responding" in which case the App is in an unusable state and ARR kicks in to try auto recover it for minimal user disruption. The focus on providing a good UX, not a miserable crash-prone experience where users use their devices in fear that at anytime anything they're working on can be terminated abruptly without warning.

jhasse 9y ago

> or corrupting my stack pointer... in that case, it will crash with a SIGSEGV sooner or later anyway

Slavius 9y ago
...or is being remotely exploited and it silently succeeds. Who wants that?
- jhasse 9y ago
  That is very unlikely. Crashing would happen 100% of the time though. Most people want that trade-off (meaning: If their browser would crash, they would switch to another one, even it was less secure).
  - Slavius 9y ago
    Corrupting SP is part of almost every exploit and I can guarantee you that it is very likely (going to cause harm on your system). Try to pull Metasploit GIT repo to get some idea about thousands of payloads that do corrupt SP without crashing the host...
    - jhasse 9y ago
      Yes, but how many of all cases of corrupted stack pointers are exploits?
      - jessaustin 9y ago
        Why would that matter? We're not trying to be secure against random cosmic rays. We're trying to be secure against attackers. http://wondermark.com/406/ http://wondermark.com/406/
        jhasse 9y ago
        It matters because we're talking about letting the browser crash on all cases. > We're trying to be secure against attackers. We also want a browser that doesn't crash.
  - TickleSteve 9y ago
    Stack pointer manipulation is the entry point for an extremely large subset of security issues.

mythz 9y ago

> Most users would accept the trade off between crashed browser and infected/corrupted system. Most users are using computing devices a means of getting stuff done. They don't want to spend any energy thinking about how their software works, they want their devices to be invisible, which they use to run their Apps uninterrupted. The trade-off is whether to let Apps continue running vs hard crashing and taking down all the work they've done and all the mental energy and focus invested up to that point. If their Apps frequently crash most users aren't thinking, well I'm super glad the hours I spent on this paper I'm working on is now lost, the phone calls to my loved ones or movie I'm watching are abruptly terminated because someone's policy on hard crashing when a bug is found has been triggered. Their preferences and purchasing power are going to go towards non user-hostile devices they perceive provide the best experience for using their preferred Apps without any need for pre-requisite knowledge of OS internals. There's not a single computing device that frequently crashes as a result of security hardening that will be able to retain any meaningful marketshare. Users are never going tolerate anything that requires extraneous effort on their part into researching and manually applying what needs to be done to get their device running without crashing.

Slavius 9y ago
Apps are supposed to keep their state either by saving your work regularly to persistent media or keeping your data off-client. We're living in 21st century in a cloud era FFS. Keep running your app although integrity corruption within the application happened is putting user data at risk. IMHO an application that corrupts 3 days long presentation file save is to every user more frustrating than the one that crashes due to error leaving you with 5 minutes of unsaved changes lost. Microsoft have invented "Application Recovery and Restart" exactly for this purpose.
- mythz 9y ago
  > Keep running your app although integrity corruption within the application happened is putting user data at risk. If user data is continually backed up to a remote site it's not going to be at risk from a local bug is it? Bugs exist in all software, Users are going to be be more visibly frustrated from their Apps frequently crashing then the extremely unlikely scenario where a detected bug corrupts their "3 days long presentation". They're going very unhappy if the cause of their frequent data loss was due to a user-hostile setting to hard crash on the first detectable bug. > Microsoft have invented "Application Recovery and Restart" exactly for this purpose. From Microsoft website: > An application can use Application Recovery and Restart (ARR) to save data and state information before the application exits due to an unhandled exception or when the application stops responding. - https://msdn.microsoft.com/en-us/library/windows/desktop/cc948909%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/cc9... i.e. restarting Apps due to "unhandled exception or when the application stops responding" in which case the App is in an unusable state and ARR kicks in to try auto recover it for minimal user disruption. The focus on providing a good UX, not a miserable crash-prone experience where users use their devices in fear that at anytime anything they're working on can be terminated abruptly without warning.