I'm not convinced about verifying extension authors and suing if they do something they shouldn't. Firstly it'll put off lots of extension authors. More importantly, determined criminals with get a bogus verification, or disappear when someone comes to sue. The law merely discourages people from doing bad things, doesn't stop them happening.
At stake here is access to potentially millions of user's internet banking - that's got to be worth a pop for a fraudster. I'd rather that nefarious extensions were stopped from manipulate those pages, rather than having to find and sue the fraudster. I believe technical methods are the best way to protect users, and they're more within our control. Laurence On Jan 4, 1:42 am, Adam Barth <aba...@chromium.org> wrote: > 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_... > > Adam > > > > On Sun, Jan 3, 2010 at 5:28 PM, Ernest Delgado <erne...@google.com> 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 <aba...@chromium.org> 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 <melin...@gmail.com> 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 <l.d.ander...@gmail.com> 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 <aba...@chromium.org> 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 <l.d.ander...@gmail.com> > >>>> > 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 <phist...@gmail.com> 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 <l.d.ander...@gmail.com> > >>>> > >> 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 <m...@chromium.org> > >>>> > >> > 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 > >>>> > >> > > <aba...@chromium.org> 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 > >>>> > >> > > > <l.d.ander...@gmail.com> > >>>> > >> > 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 > >>>> > >> > > > chromium-extensi...@googlegroups.com. > >>>> > >> > > > > To unsubscribe from this group, send email to > >>>> > >> > > > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2Bunsu > >>>> > >> > > > bscr...@googlegroups.com><chromium-extensions%2Bunsu > >>>> > >> > bscr...@googlegroups.com> > >>>> > >> > > > . > >>>> > >> > > > > 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 > >>>> > >> > chromium-extensi...@googlegroups.com. > >>>> > >> > > > To unsubscribe from this group, send email to > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to chromium-extensi...@googlegroups.com. To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
