Re: no-user-js - New CSP directive to mitigate Self-XSS

On 4/12/12 2:42 PM, Tanvi Vyas wrote: To mitigate this potential attack, we are considering adding a new CSP directive 'no-user-js' that can be set by websites being targeted by this attack (http://incompleteness.me/mozblog/2011/12/14/combating-self-xss/): X-Content-Security-Policy: no-user-js

Re: no-user-js - New CSP directive to mitigate Self-XSS

How about "no-user" as a source expression in script-src, instead? On 12 April 2012 14:42, Tanvi Vyas wrote: > Given recent social-engineering attacks, firefox no longer allows > javascript in the address bar (https://bugzilla.mozilla.org/** > show_bug.cgi?id=656433

Re: no-user-js - New CSP directive to mitigate Self-XSS

I assume this protection would be extended to all facilities which allow user's to execute script (scratchpad, error console, are there others?) And things like firebug would be out of scope, although they could choose to respect this header or not. On 4/13/12 7:42 AM, Tanvi Vyas wrote: Given

Re: stealing saved passwords

On Wed, 11 Apr 2012 11:20:17 -0700 Eric Chen wrote: > We are also interested in a defense for this. The defense that we came up > with is actually very similar to proposal 1) and 3) If you can work it without STS, do so as anything that turns users away will not get widespread adoption especially

no-user-js - New CSP directive to mitigate Self-XSS

Given recent social-engineering attacks, firefox no longer allows javascript in the address bar (https://bugzilla.mozilla.org/show_bug.cgi?id=656433). The same issue could exist with the Web Console. An attacker could ask a user to use the keyboard shortcut to open the web console and copy an

Re: WebAPI Security Discussion: Camera API

I think there's a huge misunderstanding here: We're not advocating getting rid of the preview screen. What we're advocating is that apps cannot receive camera data until the user has pressed the button (which is owned by the OS). In the current state of the world, some apps do not show preview s

Re: WebAPI Security Discussion: Camera API

> I'm not opposed to a trusted UI approach, but I don't think it is possible > to provide adequate functionality using a "take picture" button. The > preview point is spot on. Think about the camera apps people use - preview > is a universal feature among them. Apps can still have a preview win

Re: WebAPI Security Discussion: Camera API

I'm not opposed to a trusted UI approach, but I don't think it is possible to provide adequate functionality using a "take picture" button. The preview point is spot on. Think about the camera apps people use - preview is a universal feature among them. One solution might be to bundle the previe

Re: [b2g] WebAPI Security Discussion: Camera API

You want the application to be able to overlay things on top of the picture. Think a barcode scanner, an OCR system, an AR app and so on. OS imposed previews might be a problem. --Dev On 11 April 2012 01:39, Adrienne Porter Felt wrote: > No, in our proposal, it's up to the app to provide a prev

Re: WebAPI Security Discussion: Camera API

Just as a case in point, we've now performed no less than four studies on the types of information that users care about (i.e., the data types that permissions purport to protect). We've found that users have *significantly* greater levels of concern for things like taking photos than they do for

Re: WebAPI Security Discussion: Camera API

On Thu, Apr 12, 2012 at 8:57 AM, Jason Miller wrote: > > What would be wrong with using the same UI from Geolocation access for > something like camera access? An API method requests that the user grant > camera permissions, which shows them the appropriate dialog to confirm. > Events are fired

Re: WebAPI Security Discussion: Camera API

> > > This is a good point. Clickjacking could be addressed by designing a way > to ensure an element is "on top" (a master z-index?) and also ensuring that > the button is visible for at least {the time it takes for a human to > recognize a button}+1 before it can be pressed. > > No, this does no