4 ms·

The good news is that Daniel has not stopped experimenting with hardened android. https://github.com/AndroidHardening/ https://github.com/AndroidHardening/

folkrav 8y ago
I'm not familiar with what happened from beginning to end, but regardless of the actual chain of events or if the CEO was right or wrong to kick him out, I'm not sure how users can still trust Daniel after destroying signing keys.
- LukeShu 8y ago
  He didn't destroy them out of malice. He destroyed them because (from his point of view) they were about to be compromised. If users trust the key because they trust updates coming from Daniel and if Daniel is about to lose control of the key to someone else, then destroying the key before it becomes compromised is the responsible and right thing to do.
  - huahe 8y ago
    > If users trust the key because they trust updates coming from Daniel and if Daniel is about to lose control of the key to someone else, then destroying the key before it becomes compromised is the responsible and right thing to do. how can you possibly state that when the users have no control or say over this decision?
    - LukeShu 8y ago
      I state that by clearly stating the premise and assumptions in an if/then format: > If users trust the key because they trust updates coming from Daniel ..., then That's a big-ish "if"; I didn't weigh in on whether I think it's true. A reasonable person could go either-way on that. If it is true, then Daniel was justified, if it's not, then he wasn't. > ... when the users have no control or say over this decision? If we assume that people trusted Copperhead-the-organization because they trusted Daniel and that Daniel's removal is a change-of-hands, then the decisions is: - Do nothing (and stop receiving updates) - Start trusting the new engineering leadership of Copperhead-the-organization From that perspective, it makes sense that Daniel should destroy the key: Making the active decision to start trusting the new Copperhead requires the active technical step of installing the new key; making the inactive decision doesn't require action. If on the other hand we assume that Daniel was an implementation detail and that people trust Copperhead-the-organization as an institution, then the decision is: - Stop trusting Copperhead-the-organization (and stop receiving updates) - Do nothing From that perspective, it makes sense that Daniel should not destroy the key: Making the active decision of ceasing trust requires the active technical step of disabling updates.
  - burk96 8y ago
    Exactly, a pretty clever move on his part.
  - folkrav 8y ago
    Makes sense. Thanks for the explanation.
- eleitl 8y ago
  He did it to prevent their misuse. The project is dead. Stop poking it with a stick. It won't rise up again.
  - folkrav 8y ago
    I didn't even know about CopperheadOS before this post. I'm not poking at it with a stick, I'm asking questions as an outsider just learning about it.

folkrav 8y ago

I'm not familiar with what happened from beginning to end, but regardless of the actual chain of events or if the CEO was right or wrong to kick him out, I'm not sure how users can still trust Daniel after destroying signing keys.

LukeShu 8y ago
He didn't destroy them out of malice. He destroyed them because (from his point of view) they were about to be compromised. If users trust the key because they trust updates coming from Daniel and if Daniel is about to lose control of the key to someone else, then destroying the key before it becomes compromised is the responsible and right thing to do.
- huahe 8y ago
  > If users trust the key because they trust updates coming from Daniel and if Daniel is about to lose control of the key to someone else, then destroying the key before it becomes compromised is the responsible and right thing to do. how can you possibly state that when the users have no control or say over this decision?
  - LukeShu 8y ago
    I state that by clearly stating the premise and assumptions in an if/then format: > If users trust the key because they trust updates coming from Daniel ..., then That's a big-ish "if"; I didn't weigh in on whether I think it's true. A reasonable person could go either-way on that. If it is true, then Daniel was justified, if it's not, then he wasn't. > ... when the users have no control or say over this decision? If we assume that people trusted Copperhead-the-organization because they trusted Daniel and that Daniel's removal is a change-of-hands, then the decisions is: - Do nothing (and stop receiving updates) - Start trusting the new engineering leadership of Copperhead-the-organization From that perspective, it makes sense that Daniel should destroy the key: Making the active decision to start trusting the new Copperhead requires the active technical step of installing the new key; making the inactive decision doesn't require action. If on the other hand we assume that Daniel was an implementation detail and that people trust Copperhead-the-organization as an institution, then the decision is: - Stop trusting Copperhead-the-organization (and stop receiving updates) - Do nothing From that perspective, it makes sense that Daniel should not destroy the key: Making the active decision of ceasing trust requires the active technical step of disabling updates.
- burk96 8y ago
  Exactly, a pretty clever move on his part.
- folkrav 8y ago
  Makes sense. Thanks for the explanation.
eleitl 8y ago
He did it to prevent their misuse. The project is dead. Stop poking it with a stick. It won't rise up again.
- folkrav 8y ago
  I didn't even know about CopperheadOS before this post. I'm not poking at it with a stick, I'm asking questions as an outsider just learning about it.