RE: Secure Chrome and Secure MetaData

There are certainly proposals that have a greater or lesser degree of reliance on platform security, netowrk security and so on than others.

Where I have concern though is the way the conversation keeps making a seamless transition between chrome attacks and platform attacks.

The point of distinction I would make here is that we all share the same chrome, we all use HTTP, HTML, Javascript, CSS enabled browsers that are way to permissive in the manipulations they allow content to perform.

There is no way that the most careful consumer can defend against an attack where a frameless javascript window pops up with a fake browser inside it.

There are protections that we can expect users to take at the platform level and how ever many million machines are compromised at any given time there are robust defenses against trojan compromise that are possible. My standard Windows account does not have the ability to load a device driver, change the system registry or change system files. The chance that the machine will be compromised by a Trojan is vastly reduced as a result.

The upshot of this is that while it is certainly a concern that a machine can be hijacked there is certainly value to proposals that only address the social engineering attack.

Moreover the processes by which the machines are hijacked in the first place are also the result of a social engineering attack. If nobody ever opened up executable attachments there would be remarkably few viruses.


Virtually all current Internet crime involves social engineering and in particular impersonation of a trusted party at some point in the cycle.


> -----Original Message-----
> From: public-usable-authentication-request@w3.org 
> [mailto:public-usable-authentication-request@w3.org] On 
> Behalf Of Dan Schutzer
> Sent: Tuesday, June 20, 2006 6:16 PM
> To: Hallam-Baker, Phillip; 'Drew Dean'
> Cc: 'Mary Ellen Zurko'; public-usable-authentication@w3.org
> Subject: RE: Secure Chrome and Secure MetaData
> 
> 
> I do think there is merit to focus and not to digress, but 
> regarding the out-of-scope comment
> 
> Just remember two things:
> 
> 1. There can be solutions that can both solve in-scope and 
> out-of-scope problems, and these solutions might be favored 
> just for that reason 2. If all the hard problems are put on 
> someone else's plate and no progress is ever made on these 
> hard problems, that we might be building our solution on a 
> base of sand.
> 
> -----Original Message-----
> From: public-usable-authentication-request@w3.org
> [mailto:public-usable-authentication-request@w3.org] On 
> Behalf Of Hallam-Baker, Phillip
> Sent: Tuesday, June 20, 2006 5:44 PM
> To: Drew Dean
> Cc: Mary Ellen Zurko; public-usable-authentication@w3.org
> Subject: RE: Secure Chrome and Secure MetaData
> 
> 
> 
> > From: Drew Dean [mailto:ddean@yahoo-inc.com]
> 
> > To follow up on Phil and Mary's points:
> > 
> > I find it rather interesting that there's been no discussion of the 
> > Compartmented Mode Workstations (CMW) of the 1980s-1990s.  
> While they 
> > aren't a shining example of success, unambiguously displaying the
> > security label of a window is exactly the "secure chrome" 
> problem.   
> > If we don't study history, we'll be condemned to repeat it....
> 
> I agree that this is a very attractive approach for some 
> problems. For example Civilization IV refuses to run without 
> full admin privs. I don't want to give admin privs on the 
> machine but I would allow full admin privs on a virtual 
> machine that had no ability to affect anything outside its scope.
> 
> This is simply good old compartmentalized security.
> 
> 
> > I mostly, but not entirely, agree with Phil's ruling 
> platform attacks 
> > out of scope.  I agree that solving that problem isn't our problem, 
> > but think that we can reasonably specify requirements on 
> the platform 
> > at and below us (i.e., browser & underlying OS) to support 
> a trusted 
> > path of some sort.  The details, however, should be out of scope -- 
> > and may/probably be implementation dependent, so there's 
> not much to 
> > standardize.
> 
> I think that we can have a wide ranging discussion and we 
> should discuss the requirements interfaces across the 
> entities. For example CardSpace (nee
> Infocard) is bolted into the Vista O/S and that is a large 
> part of the attraction.
> 
> What we do need to do though is to exclude all comments of 
> the form 'this is not going to work because of [out of scope 
> attack]'. The answer to that has to be 'that topic is out of 
> scope for this forum'.
> 
> On the other hand I would very much welcome someone who did a 
> security analysis of the latest Internet Crime Attack 
> 'Phuming' in which they identified six components that relate 
> to topics that are in scope and another ten that turn out to 
> be out of scope. Just don't suggest that this is the place to 
> solve those problems or that the group should do nothing 
> until the problem is solved.
> 
> The point is to deliver on a tightly focused statement of 
> work, not to solve every problem in this space. 
> 
> 			Phill
> 
> 
> 
> 
> 
>

Received on Tuesday, 20 June 2006 22:48:52 UTC