Den 19 aug 2014 16:17 skrev "Tom Ritter" <<a href="mailto:tom@ritter.vg">tom@ritter.vg</a>>: > > On 19 August 2014 03:18, Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote: > > Yet I'd ALSO claim the provider is one of the most > > important entities for end-to-end crypto to protect us from. > > Conundrum. > > When you don't trust your provider, I think that can be roughly > analogized to trying to solve the present-day CA system while > acknowledging they're not going away. The best we've seen come up > with is CT. It's a 'Trust but Verify' model, except those who verify > are very few. The extension of this, I mentioned a few months ago: > > On 26 March 2014 08:17, Tom Ritter <<a href="mailto:tom@ritter.vg">tom@ritter.vg</a>> wrote: > > A design I keep circling back to, despite not liking it all that much, > > is a 98% Trust, 2% Verify model. It needs a new name, but the idea is > > open specifications, and open ability to write outside clients that > > interop that you trust more. The outside client may be browser > > extensions silently verifying the code, extensions providing the whole > > experience, mobile apps, native apps, whatever. The 2% run these > > outside clients and don't 'trust' the service to do the encryption, > > the 98% use provider-bootstrapped code that can be tampered with. > > Delicately designed, on an individual request, the service shouldn't > > know who is the 2% vs the 98% until it's too late to undetectably > > tamper. On repeated observations, the service may know, but I think > > this can be mitigated a little bit. I recognize this approach from reading about cryptographic voting methods, the general method is called "cut and choose" where a random subset of inputs is revealed/unsealed, selected to make malice hard to hide. So "cut and choose verification"?