4 ms·

Many folks prioritize preventing practical in-the-wild blue pill attacks over preventing the theoretical DRM use case.

TeMPOraL 4y ago
It's not a "theoretical DRM use case" if you stop thinking in terms of movie piracy for a moment, and consider what's happening with banking apps on mobile platforms. Thanks to remote attestation, the custom ROM scene for Android is pretty much dead now, because there's little point of customizing the OS when it automatically makes important services no longer accessible from the phone.
- jnwatson 4y ago
  That's the entire point. Your bank doesn't want you to run their software on your potentially vulnerable hardware.
  - TeMPOraL 4y ago
    That's the entire point of conflict: to me, that's an overreach by the bank, who's now dictating things out of scope of the relationship between us. The traditional boundary is one drawn by device ownership: my device, my rules; their device, their rules. I.e. my phone can do whatever, their servers can refuse working with me. Remote attestation is at best a way for simplifying their own service, at a big cost to users' freedom. In reality, it's a bit of that, plus mostly making sure the customers are locked into a bank-controlled channel that can be used to upsell more financial products.
    - acdha 4y ago
      > The traditional boundary is one drawn by device ownership: my device, my rules; their device, their rules. Your device your rules seems to cover this, too: they’re saying they don’t want to do business under other rules – the app is just showing the UI for that policy client side. It’s frustrating but that seems not unreasonable given the massive ratio of people being compromised versus intentionally customizing the OS. I miss the free-for-all of the 90s in some ways but statistically zero of the non-IT people I know wouldn’t hand root on their phone over to some guy in another country based on a prompt on a webpage.
      - TeMPOraL 4y ago
        > Your device your rules seems to cover this, too: they’re saying they don’t want to do business under other rules – the app is just showing the UI for that policy client side. I guess I see two problems here: 1) They shouldn't be allowed to make that policy in the first place. Their policy is effectively dictating what devices I can own and what can I do with them, which is unreasonable when the devices in question are general-purpose computers. 2) My device is being used against me and against my wishes here; I'm not sure who's more to blame here - the bank for taking advantage of the API, Google for providing it, or the phone vendor for implementing it and locking me out of it, or Google again for effectively forcing the phone vendor to lock me out of it. > I miss the free-for-all of the 90s in some ways but statistically zero of the non-IT people I know wouldn’t hand root on their phone over to some guy in another country based on a prompt on a webpage. There must be some other way of handling it. We wouldn't have the Fisher-Price tech of 2020s without the free-for-all 90s! The ability for technically proficient users to do whatever the hell they want with their own general-purpose computers is fundamental to developing new technologies, products and services, and better alternatives to existing ones. Between Fisher-Price consumer tech and locked down corporate tech (because security!), it looks like we're heading for an era where a general-purpose computer will be something available only to few certified employees in corporate-sponsored labs.
  - zmgsabst 4y ago
    Right — the bank is trying to control how I use their service “for my own safety”. That’s not a theoretic DRM issue, but a practical attack on the software ecosystem.
  - AshamedCaptain 4y ago
    And soon "potentially vulnerable hardware" will be anything except AT&T devices, and we'll be back to closed networks except this time the government does not have the balls to split any of the mega-corporations.
  - bakugo 4y ago
    And why should the bank's opinion be relevant here?
  - jeroenhd 4y ago
    If I grab the LineageOS sources right now and build an image for my phone, my phone will get about a year of ignored security updates and removes at least a dozen shady apps trying to talk to different Chinese cloud providers. In terms of practical security, custom ROMs are often safer than the forgotten and obsolete software left on a device when updates stop rolling out. Sandbox escapes and exploits to get root access are more realistic threats than airport security flashing a different OS through your phone recovery or some kind of conspiracy to stuff malware into an open source repository. As long as you take care to only install software from reliable sources (i.e. download.lineageos.org, F-Droid.org) I don't see the problem.
- public_defender 4y ago
  This is not limited to consumer transactions like banking apps, and deployment is never guaranteed to be the result of a rational decision-making process. I have now had more than one employer who deployed remote attestation in a bring-your-own-device ecosystem. They do this because they are told by some vendor tutorial that it is more secure, but they end up disabling user devices by accident. My current IT department told me to buy a new phone if my current one couldn't pass a SafetyNet check. The problem is that if you are inside a project developing something like this, you can clearly visualize your expected use case, but it's impossible to know what other use cases will be contrived. Of course in this case, we have predicted a few major malfeasances and I think anyone supporting a project like this needs to know the harmful use cases and be responsible for developing with them in mind.
AshamedCaptain 4y ago
I would argue the blue pill attacks _are_ theoretical for the majority of users, while DRM overreach are at least a daily occurrence. The complexity and bugs of these "protections" is likely to cause more actual security issues AND headaches to average users than the "evil maid" scenario these blog posts like to speak of.

It's not a "theoretical DRM use case" if you stop thinking in terms of movie piracy for a moment, and consider what's happening with banking apps on mobile platforms. Thanks to remote attestation, the custom ROM scene for Android is pretty much dead now, because there's little point of customizing the OS when it automatically makes important services no longer accessible from the phone.

jnwatson 4y ago
That's the entire point. Your bank doesn't want you to run their software on your potentially vulnerable hardware.
- TeMPOraL 4y ago
  That's the entire point of conflict: to me, that's an overreach by the bank, who's now dictating things out of scope of the relationship between us. The traditional boundary is one drawn by device ownership: my device, my rules; their device, their rules. I.e. my phone can do whatever, their servers can refuse working with me. Remote attestation is at best a way for simplifying their own service, at a big cost to users' freedom. In reality, it's a bit of that, plus mostly making sure the customers are locked into a bank-controlled channel that can be used to upsell more financial products.
  - acdha 4y ago
    > The traditional boundary is one drawn by device ownership: my device, my rules; their device, their rules. Your device your rules seems to cover this, too: they’re saying they don’t want to do business under other rules – the app is just showing the UI for that policy client side. It’s frustrating but that seems not unreasonable given the massive ratio of people being compromised versus intentionally customizing the OS. I miss the free-for-all of the 90s in some ways but statistically zero of the non-IT people I know wouldn’t hand root on their phone over to some guy in another country based on a prompt on a webpage.
    - TeMPOraL 4y ago
      > Your device your rules seems to cover this, too: they’re saying they don’t want to do business under other rules – the app is just showing the UI for that policy client side. I guess I see two problems here: 1) They shouldn't be allowed to make that policy in the first place. Their policy is effectively dictating what devices I can own and what can I do with them, which is unreasonable when the devices in question are general-purpose computers. 2) My device is being used against me and against my wishes here; I'm not sure who's more to blame here - the bank for taking advantage of the API, Google for providing it, or the phone vendor for implementing it and locking me out of it, or Google again for effectively forcing the phone vendor to lock me out of it. > I miss the free-for-all of the 90s in some ways but statistically zero of the non-IT people I know wouldn’t hand root on their phone over to some guy in another country based on a prompt on a webpage. There must be some other way of handling it. We wouldn't have the Fisher-Price tech of 2020s without the free-for-all 90s! The ability for technically proficient users to do whatever the hell they want with their own general-purpose computers is fundamental to developing new technologies, products and services, and better alternatives to existing ones. Between Fisher-Price consumer tech and locked down corporate tech (because security!), it looks like we're heading for an era where a general-purpose computer will be something available only to few certified employees in corporate-sponsored labs.
- zmgsabst 4y ago
  Right — the bank is trying to control how I use their service “for my own safety”. That’s not a theoretic DRM issue, but a practical attack on the software ecosystem.
- AshamedCaptain 4y ago
  And soon "potentially vulnerable hardware" will be anything except AT&T devices, and we'll be back to closed networks except this time the government does not have the balls to split any of the mega-corporations.
- bakugo 4y ago
  And why should the bank's opinion be relevant here?
- jeroenhd 4y ago
  If I grab the LineageOS sources right now and build an image for my phone, my phone will get about a year of ignored security updates and removes at least a dozen shady apps trying to talk to different Chinese cloud providers. In terms of practical security, custom ROMs are often safer than the forgotten and obsolete software left on a device when updates stop rolling out. Sandbox escapes and exploits to get root access are more realistic threats than airport security flashing a different OS through your phone recovery or some kind of conspiracy to stuff malware into an open source repository. As long as you take care to only install software from reliable sources (i.e. download.lineageos.org, F-Droid.org) I don't see the problem.
public_defender 4y ago
This is not limited to consumer transactions like banking apps, and deployment is never guaranteed to be the result of a rational decision-making process. I have now had more than one employer who deployed remote attestation in a bring-your-own-device ecosystem. They do this because they are told by some vendor tutorial that it is more secure, but they end up disabling user devices by accident. My current IT department told me to buy a new phone if my current one couldn't pass a SafetyNet check. The problem is that if you are inside a project developing something like this, you can clearly visualize your expected use case, but it's impossible to know what other use cases will be contrived. Of course in this case, we have predicted a few major malfeasances and I think anyone supporting a project like this needs to know the harmful use cases and be responsible for developing with them in mind.

AshamedCaptain 4y ago

I would argue the blue pill attacks _are_ theoretical for the majority of users, while DRM overreach are at least a daily occurrence. The complexity and bugs of these "protections" is likely to cause more actual security issues AND headaches to average users than the "evil maid" scenario these blog posts like to speak of.