Re: Running "Trusted Code" on the Web?

On 2015-02-27 22:14, Manu Sporny wrote:
> On 02/27/2015 04:44 AM, Anders Rundgren wrote:
>> That is, the card is never directly exposed to potentially malicious
>>   merchant code.
>
> Except in the case of some of the more recent merchant store breaches. :)

Yes, but that is the card-not-present scenario which is not what I illustrated.


>
>> Now if you rather go to the Web, you'll find that the entire concept
>>   "Trusted Code" is missing!
>
> It is... because it's a really, really hard problem to solve, and there
> are multiple layers of what "trusted" could mean.

Essentially it means known code that has been supplied in such a way that
it has a certain level of trust like from an AppStore.


>
>> Strong authentication to specific domains (like U2F) compensate for
>> this deficiency at the expense of user experience and limited
>> flexibility when it comes to provider selection.
>
> So, what's the solution? :)

AFAIK there are two solutions:
- Signed and packaged web-code
- Calling external native code from the web


> I ask because I don't think many people will argue that there isn't a
> problem.

The demise of plugins created a big hole in the web.  The users were left without a remedy.


> Your comments above are very broad brush, so there's not much
> actionable in this email, what is the point you're trying to make and
> the action you'd like the group to take?

True this question is out of scope but it might be good knowing about it
when doing a security analysis so you don't end-up like:
https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html


Anders

Received on Friday, 27 February 2015 22:13:12 UTC