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
>>> > >> > > > 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
>>> > >> > chromium-extensions+unsubscr...@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 
>>> > > chromium-extensions+unsubscr...@googlegroups.com.
>>> > > 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 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.
>>
>>
>>
>
> --
>
> 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.
>
>
>

--

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.


Reply via email to