[Cryptography] eliminating manufacturer's ability to backdoor users

[Ray Dillinger]

On 02/22/2016 10:51 AM, RB wrote:
> On Mon, Feb 22, 2016 at 5:52 AM, Allen <allenpmd at gmail.com> wrote:
>> As long as manufacturers like Apple insist on controlling the 
>> keys to the phone, they will be required open it when subject to a 
>> warrant.

> I'm genuinely curious what solution you might suggest that would be
> secure and immune to compulsion while remaining sufficiently
> profitable that companies would engage in it.  While interesting, your
> suggestion of perfectly anonymous updates that are incapable of
> uniquely identifying a device eliminates the majority of the
> environment's profitability and therefore manufacturers' incentive to
> participate.

I can think of a few things.  As far as I understand it, the
uniqueness-for-profitability argument argues for uniqueness of
content provided to the user and personal data snooped from the
user, but not for the uniqueness of the software that runs to
deliver the content and snoop the data.

Apple's profitability doesn't depend on providing different
versions of the operating system to different users.  Nor do
the app makers create individually tailored executables.  And
if they did they wouldn't be able to sell them in apple's
walled garden without getting Apple to sign off on every
release for every user.

Apple's profitability (and that of app makers) depends on
serving unique *content* to each device, and on snooping
identifiable individual data from each device, but how on
earth would that require unique per-user versions of OS
updates?

> Ancillary services and integration are where the profits are,
> and if a company is unable to determine if a user is even a paying
> customer, they're not going to provide a service.  

You're describing mutual blinded authentication.  Chaum worked
out a protocol for this decades ago.  Nothing argues against
using it for software distribution (as opposed to data snooped
from user devices or content delivery to them).

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160222/6785c805/attachment.sig>