Oh, the issue is about traceability. EV certificates are designed to ensure there's an entity to sue if something goes wrong. I don't think the gallery has any such process.
http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Issuing_criteria Adam On Sun, Jan 3, 2010 at 5:28 PM, Ernest Delgado <[email protected]> wrote: > Isn't there anything on the "Google Chrome Gallery Developer > Agreement" about that already? > > On Sun, Jan 3, 2010 at 2:32 PM, Adam Barth <[email protected]> wrote: >> That's an interesting idea. There might be some way to leverage the >> extended validation certificate system to do that easily. >> >> Adam >> >> >> On Fri, Jan 1, 2010 at 2:22 PM, Erek Speed <[email protected]> wrote: >>> One policy is to have a higher level of verification for extension >>> authors. Some method where they're name and address are verified >>> which at least insures that they'll be identified if they do anything >>> evil. >>> >>> On Jan 2, 5:36 am, Laurence <[email protected]> wrote: >>>> Completely agree on 3, for too long everyone is expected to be an IT >>>> expert, and it's their fault if their not. >>>> >>>> As I see it, there is a problem that an innocent looking extension can >>>> turn into a malicious extension via autoupdate, or eval/innerHTML, >>>> potentially compromising many users. An obvious thing for the >>>> malicious extension to do is to log all form data, and post it to a >>>> hostile site using XHR. I don't have any good ideas for preventing >>>> this directly... >>>> >>>> One idea is to use fine grained security to prevent the malicious >>>> behaviour. My first though was to require an extra capability to allow >>>> passwords to go from content script to XHR, however as pointed out >>>> above this is not as simple as it seems. My second though: an >>>> additional capability is required to pass any data from a content >>>> script to XHR. I'm not sure how many extensions would require this >>>> capability, password managers would, but hopefully it would be few, >>>> and come with a suitably strongly worded warning. >>>> >>>> I'm sure there are many issues to work through, but lets discuss! >>>> >>>> On Jan 1, 7:44 pm, Adam Barth <[email protected]> wrote: >>>> >>>> >>>> >>>> > Some high-level points: >>>> >>>> > 1) In thinking about security, I find it helpful to separate policy >>>> > from mechanism. A bunch of messages in this thread are about various >>>> > mechanisms (taint tracking, DOM reference monitors, etc), but we don't >>>> > have a clear idea what policy we'd like these mechanisms to enforce. >>>> >>>> > 2) Several messages are interested in protecting passwords (e.g., >>>> > noticing if an extension mis-uses passwords in various ways). Before >>>> > we think about what sorts of policies we ought to apply to passwords, >>>> > we should think about how we're going to recognize what's a password >>>> > and what's not a password. Just using <input type="password"> isn't >>>> > sufficient if the extension can draw things on the web page (which is >>>> > a more or less a requirement for the extension system) because the >>>> > extension can draw a box that looks exactly like a password field. >>>> >>>> > 3) Some folks are tempted to punt security questions to the user >>>> > (e.g., extension XYZ wants to communicate with host ABC, allow/deny?). >>>> > Although it might make us feel better to be able to blame the user >>>> > when something goes wrong, many users won't have enough context to >>>> > make reasonable security decisions when faced with these kinds of >>>> > questions (e.g., should the Happy Fun Ball extension be allowed to >>>> > communicate with happyfunball.com?). >>>> >>>> > Adam >>>> >>>> > On Fri, Jan 1, 2010 at 6:48 AM, Laurence <[email protected]> wrote: >>>> > > Agreed, it'll be hard to detect if an extension is maliciously using >>>> > > passwords. However if passing of passwords can be detected between the >>>> > > content script and the background page/XHR for example, it can have a >>>> > > security capability associated with it, which hopefully people would >>>> > > only grant to a password saver. Well that's my theory... >>>> >>>> > > Laurence >>>> >>>> > > On Jan 1, 2:10 pm, PhistucK <[email protected]> wrote: >>>> > >> But, think of the counter case, how can you detect that an extension >>>> > >> is >>>> > >> maliciously using your passwords as malicious, and an extension that >>>> > >> is >>>> > >> rightfully using your passwords (a password saver) as not malicious? >>>> >>>> > >> Both of them can act the same way, so, what, will you block both of >>>> > >> them due >>>> > >> to the security risks? >>>> >>>> > >> ☆PhistucK >>>> >>>> > >> On Fri, Jan 1, 2010 at 16:04, Laurence <[email protected]> wrote: >>>> > >> > Could there be some more fine grained security around forms, >>>> > >> > especially password fields? (Including document.onkeypress when a >>>> > >> > password field has focus, and possibly other vectors - am I being >>>> > >> > too >>>> > >> > simplistic here - does the content script merge and become >>>> > >> > indistinguishable from the web page itself?). It should be very rare >>>> > >> > for extensions to need these (only password managers, which you >>>> > >> > implicitly trust with everything anyway), and if people give an >>>> > >> > extension access to their passwords, then they do it with their eyes >>>> > >> > open. >>>> >>>> > >> > Is fine grained security around eval/innerHTML from XHR possible? I >>>> > >> > assume that would be difficult too, would need to 'taint' every >>>> > >> > variable derived from an XHR. >>>> >>>> > >> > What do you think? Or other ideas? >>>> >>>> > >> > Laurence >>>> >>>> > >> > On Dec 31 2009, 10:14 pm, Mohamed Mansour <[email protected]> wrote: >>>> > >> > > Maybe having some kind of statistical usage of xhr calls that each >>>> > >> > extension >>>> > >> > > will keep track permanently. That way, we could do some sort of >>>> > >> > > smart >>>> > >> > > algorithm that will point out some uncommon, untrustworthy >>>> > >> > > requests. I am >>>> > >> > > just dreaming, but I think its possible to eliminate some threat. >>>> >>>> > >> > > Cause currently, if some developer's extension's account got >>>> > >> > > hijacked or >>>> > >> > > stolen, the user could modify his extension and add some privacy >>>> > >> > concerning >>>> > >> > > risks. To (try to) stop that, we could do what we did before, and >>>> > >> > > let the >>>> > >> > > developer supply the certification file (pem) everytime he >>>> > >> > > updates his >>>> > >> > > extension, that will eliminate that kind of threat, when the >>>> > >> > > account has >>>> > >> > > been compromised. >>>> >>>> > >> > > PS: I am not a security person, just some ideas that came out of >>>> > >> > > my head. >>>> > >> > So >>>> > >> > > I might be just dreaming. Nevertheless, its an interesting topic. >>>> >>>> > >> > > -Mohamed Mansour >>>> >>>> > >> > > On Thu, Dec 31, 2009 at 3:44 PM, Adam Barth <[email protected]> >>>> > >> > > wrote: >>>> > >> > > > Yes, that's a scary scenario and a real threat. If you have >>>> > >> > > > ideas for >>>> > >> > > > what we could do to protect against that threat, I'd be >>>> > >> > > > interested in >>>> > >> > > > discussing them. >>>> >>>> > >> > > > Keep in mind that a nefarious extension doesn't need the >>>> > >> > > > auto-update >>>> > >> > > > system at all to change its behavior over time. For example, >>>> > >> > > > the >>>> > >> > > > extension can load code from it's own web site into the >>>> > >> > > > extension >>>> > >> > > > process (e.g., via eval or innerHTML). >>>> >>>> > >> > > > Adam >>>> >>>> > >> > > > On Sun, Dec 27, 2009 at 4:16 AM, Laurence >>>> > >> > > > <[email protected]> >>>> > >> > wrote: >>>> > >> > > > > Hi, >>>> >>>> > >> > > > > I've been playing about with the extension framework - really >>>> > >> > > > > is a >>>> > >> > joy >>>> > >> > > > > to use. >>>> >>>> > >> > > > > However I have a slight concern about the threat model. It's >>>> > >> > > > > fairly >>>> > >> > > > > trivial to write an extension to log all form data (from both >>>> > >> > > > > http >>>> > >> > and >>>> > >> > > > > https sites) and send it off to a foreign host, given content >>>> > >> > > > > script >>>> > >> > > > > and Cross-Origin XHR permissions. The threat model assumes >>>> > >> > > > > that such >>>> > >> > > > > an extension will get bad reviews, so not affect many users, >>>> > >> > > > > but does >>>> > >> > > > > it factor in the autoupdate mechanism? >>>> >>>> > >> > > > > As a nefarious developer, I could create a perfectly innocent >>>> > >> > > > > and >>>> > >> > > > > useful extension (with content script and Cross-Origin XHR >>>> > >> > > > > permissions), and wait until a large number of users have >>>> > >> > > > > installed >>>> > >> > > > > it. Then I release a new version, automatically pushed out to >>>> > >> > existing >>>> > >> > > > > users, that introduces form logging. Whilst it may only take >>>> > >> > > > > a day or >>>> > >> > > > > so for someone to notice and the extension killed, large >>>> > >> > > > > numbers of >>>> > >> > > > > users will have their details (usernames, passwords, credit >>>> > >> > > > > card >>>> > >> > > > > numbers) stolen. >>>> >>>> > >> > > > > Any thoughts? >>>> >>>> > >> > > > > Laurence >>>> >>>> > >> > > > > -- >>>> >>>> > >> > > > > You received this message because you are subscribed to the >>>> > >> > > > > Google >>>> > >> > Groups >>>> > >> > > > "Chromium-extensions" group. >>>> > >> > > > > To post to this group, send email to >>>> > >> > > > [email protected]. >>>> > >> > > > > To unsubscribe from this group, send email to >>>> > >> > > > [email protected]<chromium-extensions%2Bunsu >>>> > >> > > > [email protected]><chromium-extensions%2Bunsu >>>> > >> > [email protected]> >>>> > >> > > > . >>>> > >> > > > > For more options, visit this group at >>>> > >> > > >http://groups.google.com/group/chromium-extensions?hl=en. >>>> >>>> > >> > > > -- >>>> >>>> > >> > > > You received this message because you are subscribed to the >>>> > >> > > > Google >>>> > >> > Groups >>>> > >> > > > "Chromium-extensions" group. >>>> > >> > > > To post to this group, send email to >>>> > >> > [email protected]. >>>> > >> > > > To unsubscribe from this group, send email to >>>> > >> > > > [email protected]<chromium-extensions%2Bunsu >>>> > >> > > > [email protected]><chromium-extensions%2Bunsu >>>> > >> > [email protected]> >>>> > >> > > > . >>>> > >> > > > For more options, visit this group at >>>> > >> > > >http://groups.google.com/group/chromium-extensions?hl=en. >>>> >>>> > >> > -- >>>> >>>> > >> > You received this message because you are subscribed to the Google >>>> > >> > Groups >>>> > >> > "Chromium-extensions" group. >>>> > >> > To post to this group, send email to >>>> > >> > [email protected]. >>>> > >> > To unsubscribe from this group, send email to >>>> > >> > [email protected]<chromium-extensions%2Bunsu >>>> > >> > [email protected]> >>>> > >> > . >>>> > >> > For more options, visit this group at >>>> > >> >http://groups.google.com/group/chromium-extensions?hl=en. >>>> >>>> > > -- >>>> >>>> > > You received this message because you are subscribed to the Google >>>> > > Groups "Chromium-extensions" group. >>>> > > To post to this group, send email to >>>> > > [email protected]. >>>> > > To unsubscribe from this group, send email to >>>> > > [email protected]. >>>> > > For more options, visit this group >>>> > > athttp://groups.google.com/group/chromium-extensions?hl=en. >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "Chromium-extensions" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/chromium-extensions?hl=en. >>> >>> >>> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Chromium-extensions" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/chromium-extensions?hl=en. >> >> >> > -- You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
