Safety of extensions (DefCon presentation)
Kálmán „KAMI” Szalai
Today, one of leading IT portal published an article about FIrefox with
this title: "Firefox is not safety because of its extensions". The
article concludes the findings of this published article:
https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-roberto_liverani-nick_freeman-abusing_firefox.pdf
that was released at DefCon (https://www.defcon.org/)
What do you think about this presentation? Do we have official answer?
Do you have opinions about risks, best practices, advices?
If this is not a good list for this question, I am really sorry, and
please forward my letter to the right lis and notify me.
Thank you in advance!
--
Best regards,
KAMI
Hungarian Mozilla Community member
Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com
My projects: http://ooop.sf.net/ | http://hun.sf.net/
Blog (Hun): http://bit.ly/10ucTR | Donate: http://bit.ly/eYZO6
Follow me: http://bit.ly/gJuJZ | http://bit.ly/kDocB
Ian G
> On 25/11/09 18:47, Kálmán „KAMI” Szalai wrote:
>> Today, one of leading IT portal published an article about FIrefox with
>> this title: "Firefox is not safety because of its extensions".
>
Or, "SSL has been breached because of phishing" ;)
It is true that to the technical mind that can unravel these things,
these are different things, but to the general public these can often
become the same one thing. So when they blame the big brand, they might
be wrong or innacurate or just plain confused. Or they might have been
deceived, and now the deception is coming back to bite.
But the problem still exists. At a minimum, those protecting the big
brand will need to think about how to distance their brand from the
various not-so-clear things or utter slanders thrown at them.
And those who are concerned about security will know what happens next:
because each side now has a convenient excuse to blame someone else
for the problem, nothing will be done, and slowly the brand will acquire
a well-deserved reputation for being insecure. Seen it all before...
In thinking about extensions, one would think that providing a portal
for "friendly extensions" and dealing with only signed or otherwise
checked sources would be sufficient. Is there a sense that these
techniques aren't working?
Or is the problem out in the wild wild west where users are just
downloading any old shlock?
> Installing an extension is like installing an application on your
> machine - it's just as trusted as any other application.
Right. Having said that, how does one give the users the tools to
figure that out? Or is it the users' responsibility to figure it out by
themselves?
To some extent this is the same dilemma the banks find themselves in.
They were forced to use the platform, against good advice, and now find
the platform is biting them. What to do? They can't go back. And
there is no easy forward.
iang
Adam Barth
Ideally, an extension platform would make it easier for developers to
write secure extensions. I'm happy to discuss ideas with folks
off-list.
Adam
On Thu, Nov 26, 2009 at 10:01 AM, Ian G <ia...@iang.org> wrote:
> On 26/11/2009 15:35, Gervase Markham wrote:
>>
>> On 25/11/09 18:47, Kálmán „KAMI” Szalai wrote:
>>>
>>> Today, one of leading IT portal published an article about FIrefox with
>>> this title: "Firefox is not safety because of its extensions".
>>
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Gervase Markham
> Jetpack is an opportunity to rethink the extension security model.
> Ideally, an extension platform would make it easier for developers to
> write secure extensions. I'm happy to discuss ideas with folks
> off-list.
Why off-list? This is mozilla.dev.security :-)
Every sandbox/restricted permissions system, from Java to Android apps,
ends up having to have a way for apps to ask permission to have certain
capabilities. And you get the inevitable problem that users just say
"yes", because they want the app to work. Your video player needs access
to your phonebook? What are you going to do if that seems odd - not
watch videos?
Similarly, there will be Jetpacks which work with your password store
and those which don't. How do you deal with that? Just let all Jetpacks
read the password store? Or have a permissions model? If you have one,
what's to stop users just clicking "Yes"?
The only solution to this problem, IMO, is to authenticate authors, not
code. If you know who the author is, to a sufficient level that there's
some chance of a policeman feeling his collar if he turns out to have
written code which steals all your passwords, then there's an incentive
for good behaviour. (This is how EV SSL certs work.) Of course, this
works against "anyone can author an add-on and put it on the web and
have people use it"...
Gerv
Adam Barth
> On 26/11/09 20:32, Adam Barth wrote:
>>
>> Jetpack is an opportunity to rethink the extension security model.
>> Ideally, an extension platform would make it easier for developers to
>> write secure extensions. I'm happy to discuss ideas with folks
>> off-list.
>
> Why off-list? This is mozilla.dev.security :-)
I have a bunch of data in a not-yet-published paper that I'm not ready
to release publicly, but we can talk in general first and I can follow
up with the data in a bit after I polish up the paper.
> Every sandbox/restricted permissions system, from Java to Android apps, ends
> up having to have a way for apps to ask permission to have certain
> capabilities. And you get the inevitable problem that users just say "yes",
> because they want the app to work. Your video player needs access to your
> phonebook? What are you going to do if that seems odd - not watch videos?
>
> Similarly, there will be Jetpacks which work with your password store and
> those which don't. How do you deal with that? Just let all Jetpacks read the
> password store? Or have a permissions model? If you have one, what's to stop
> users just clicking "Yes"?
It's important to separate two concerns:
1) Malicious extensions
2) Honest extensions that have vulnerabilities (benign-but-buggy)
I agree that the malicious extension problem is somewhat intractable
because of the above concerns. However, than news article is
complaining about vulnerabilities in honest extensions.
In the current extension system, any vulnerability in an extension is
disaster because every extension runs with the user's full authority.
That means if I XSS an extension, I can run arbitrary code on your
machine. In the DefCon talk, the presenters make this clear by
installing VNC and remotely moving the user's mouse.
A fortunate fact of the world is that the vast majority of Firefox
extensions do not require the user's full authority. (That is the
statement I have a bunch of data to back up.) If the extension
ecosystem let authors restrict the privileges of their extensions (and
encouraged them to do so), then vulnerabilities in extensions would be
less severe because the attacker would obtain less that the user's
full authority by compromising an extension.
> The only solution to this problem, IMO, is to authenticate authors, not
> code. If you know who the author is, to a sufficient level that there's some
> chance of a policeman feeling his collar if he turns out to have written
> code which steals all your passwords, then there's an incentive for good
> behaviour. (This is how EV SSL certs work.) Of course, this works against
> "anyone can author an add-on and put it on the web and have people use
> it"...
For the benign-but-buggy threat, the authors are perfectly nice
people. No amount of authenticating them is going to reduce the
severity of vulnerabilities in their extensions.
Adam
Eddy Nigg
> Similarly, there will be Jetpacks which work with your password store
> and those which don't. How do you deal with that? Just let all
> Jetpacks read the password store? Or have a permissions model? If you
> have one, what's to stop users just clicking "Yes"?
Regarding the above specific example I believe it IS about code and not
author. Access to the password store must happen in the same manner as
Firefox implements it, e.g. poke for the master password every time this
happens.
>
> The only solution to this problem, IMO, is to authenticate authors,
> not code. If you know who the author is, to a sufficient level that
> there's some chance of a policeman feeling his collar if he turns out
> to have written code which steals all your passwords, then there's an
> incentive for good behaviour. (This is how EV SSL certs work.) Of
> course, this works against "anyone can author an add-on and put it on
> the web and have people use it"...
>
As such, this is what code signing certificates really provide and
obviously I'd support that ;-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kálmán „KAMI” Szalai
Ian G írta:
>
> In thinking about extensions, one would think that providing a portal
> for "friendly extensions" and dealing with only signed or otherwise
> checked sources would be sufficient. Is there a sense that these
> techniques aren't working?
>
> Or is the problem out in the wild wild west where users are just
> downloading any old shlock?
Do we have friendly extension, or signed extension? Could you describe
the validation process. Is it a go not go test or a detailed code
review? Are there possibility that author create a good extension and
change it for the 4th release to bad extension? Will we have a
bugtracker to follow the possible (security) bugs in the extensions. Can
we introduce "it is safe" tag for the really tested extensions?
>
>
>> Installing an extension is like installing an application on your
>> machine - it's just as trusted as any other application.
>
>
> Right. Having said that, how does one give the users the tools to
> figure that out? Or is it the users' responsibility to figure it out
> by themselves?
>
> To some extent this is the same dilemma the banks find themselves in.
> They were forced to use the platform, against good advice, and now
> find the platform is biting them. What to do? They can't go back.
> And there is no easy forward.
>
Yes, for example the extension can steal the keystrokes? Should I
netbanking only in safe mode of Firefox?
>
>
> iang
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
--
Best regards,
KAMI
Kálmán „KAMI” Szalai
Adam Barth írta:
>
> It's important to separate two concerns:
>
> 1) Malicious extensions
> 2) Honest extensions that have vulnerabilities (benign-but-buggy)
>
> I agree that the malicious extension problem is somewhat intractable
> because of the above concerns. However, than news article is
> complaining about vulnerabilities in honest extensions.
>
And How can we avoid the Malicious extensions problems'. I think the
general user not able to select the right extension. Many users install
spy programs because the read a webpage, or get a false antivirus
notification. How can we protect users if they want to install
extensions mainly one Malicious extension.
--
Best regards,
KAMI
amir.herzberg
> It's important to separate two concerns:
>
> 1) Malicious extensions
> 2) Honest extensions that have vulnerabilities (benign-but-buggy)
Absolutely. And I also completely agree with the rest of Adam's post
(below). Just let me add my 2cents - two more advantages to introduce
a `real` protection mechanism for extensions:
1. It would allow Mozilla and the community to inspect more carefully
sensitive extensions (these requiring strong capabilities), for
vulnerabilities (and intentional abuse / trapdoors).
2. It would allow users or user agents to decide whether to install a
specific extension based on its `capabilities profile`. Yes, naive
users may not be able to do this, but sysadmins may define defaults
for an organization, and anti-virus programs etc. can set up such
values.
So, I think this is a good idea. It may require significant work to do
this well, though... but this can be fun!
Best, Amir Herzberg
Michael Lefevre
> Do we have friendly extension, or signed extension? Could you describe
> the validation process. Is it a go not go test or a detailed code
> review? Are there possibility that author create a good extension and
> change it for the 4th release to bad extension? Will we have a
> bugtracker to follow the possible (security) bugs in the extensions. Can
> we introduce "it is safe" tag for the really tested extensions?
I'm not part of the add-ons team, but I can try and answer anyway.
Firefox, by default, will only install extensions from
https://addons.mozilla.org - users can install addons from anywhere, but
they have to go through a security warning and a few mouse clicks before
Firefox will install addons from other sites.
The addons on the official site are reviewed, according to the process
at https://addons.mozilla.org/en-US/developers/docs/policies/reviews
>>> Installing an extension is like installing an application on your
>>> machine - it's just as trusted as any other application.
>>
>> Right. Having said that, how does one give the users the tools to
>> figure that out? Or is it the users' responsibility to figure it out
>> by themselves?
>>
> Yes, for example the extension can steal the keystrokes? Should I
> netbanking only in safe mode of Firefox?
As said above, extensions/addons are like installing an application.
Extensions can steal keystrokes, but also get passwords from your
computer, read your files, re-format you hard disk, or anything else.
Addons have the same privileges on your computer as Firefox itself, so
users need to have the same level of trust of addons as they do in
Firefox, or other applications they install on their computer.
Michael
Adam Barth
<kam...@gmail.com> wrote:
> Adam Barth írta:
>> It's important to separate two concerns:
>>
>> 1) Malicious extensions
>> 2) Honest extensions that have vulnerabilities (benign-but-buggy)
>>
>> because of the above concerns. However, than news article is
>> complaining about vulnerabilities in honest extensions.
>
I'm not sure. That's a hard problem, but we can still make progress
on the benign-but-buggy case.
Adam
chris hofmann
There is some early thinking about the Jetpack security model at
https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Jetpack_Security_Model
There is still alot of work left to do in driving out details around how
the capabilities will be checked by knowledgable reviewers, and surfaced
to users that might not be as good at making the correlations between
capabilities in Jetpacks and possible risks.
Aza also put together a draft of an introductory video to explain at a
high level how this system might work.
definitely interested in feedback as the security model gets flushed out
and applied.
-chofmann
Adam Barth
> There is some early thinking about the Jetpack security model at
>
> https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Jetpack_Security_Model
This looks like a great start. A few things you might consider:
1) If the Jetpack is not signed with a CA-verified certificate, you
might consider having the developer self-sign the Jetpack. That could
help with the issues raised in
<https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Code_Updating> for
unsigned Jetpacks. (You can check that the update is self-signed with
the same key.)
2) The document doesn't explain how Jetpacks interact with web content
(e.g., web pages). Many of the vulnerabilities in existing extensions
are due to unsafe interaction with malicious web pages. You might
consider if there is a way to structure the API for interacting with
web pages to make that easier to do securely. For example, you could
isolate the the content-touching parts of the Jetpack behind a JSON
message passing interface, like you've done with third-party
libraries.
3) One of the things we found in our study (which Adrienne has made
public at <http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-139.pdf>)
is that many extensions use nsIFile to store extension-local
persistent state. You might consider providing an alternative API
(e.g., something like localStorage) that lets Jetpacks store
persistent state without the authority to read and write arbitrary
files.
Adam
Devdatta
> public at <http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-139.pdf>)
> is that many extensions use nsIFile to store extension-local
> persistent state. You might consider providing an alternative API
> (e.g., something like localStorage) that lets Jetpacks store
> persistent state without the authority to read and write arbitrary
> files.
The study says that extensions use nsIFile to 'store information that
is too complex for the preferences system'. What is 'too complex' ? If
a key value store (viz. the preferences system) isn't good enough,
would localStorage work ? Do you have a list of extensions for whom
localStorage would be good enough (but can't work with just the
preferences system) ?
thanks
devdatta
Adam Barth
That's a good question for Adrienne, but my understanding is the prefs
system can only store simple types like integers and booleans. Now
that JSON.stringify and JSON.parse are implemented in Firefox,
localStorage can store many interesting objects. I think the HTML5
spec also as support for storing things like images in localStorage,
but I'm not sure that's implemented in Firefox yet.
It's possible that we could design a persistent storage API that's
better optimized for extensions, but I think it makes sense to re-use
interfaces the web platform whenever possible. For example, if jQuery
adds an abstraction for localStorage, Jetpacks can use that for free.
Adam
Devdatta
> that JSON.stringify and JSON.parse are implemented in Firefox,
The preference system supports Strings + Integers + Booleans. As of
now, afaik, localStorage is a key value system only supporting
strings.
Regards
Devdatta
2009/11/29 Adam Barth <abarth-...@adambarth.com>:
Ian G
> On Sat, Nov 28, 2009 at 11:51 PM, K�lm�n �KAMI� Szalai
> <kam...@gmail.com> wrote:
>> Adam Barth �rta:
>>> It's important to separate two concerns:
>>>
>>> 1) Malicious extensions
>>> 2) Honest extensions that have vulnerabilities (benign-but-buggy)
>>>
>>> I agree that the malicious extension problem is somewhat intractable
>>> because of the above concerns. However, than news article is
>>> complaining about vulnerabilities in honest extensions.
>>
>> And How can we avoid the Malicious extensions problems'.
>
> I'm not sure. That's a hard problem, but we can still make progress
> on the benign-but-buggy case.
there are two popular ways to deal with this:
* beforehand - review
* afterwards - punishment
The good thind thing about "beforehand - review" is that it is
understandable. The bad thing is that it doesn't scale very well, and
when it comes to user code, there aren't that many people who want to go
trawling through looking for yet more bugs in someone else's code. "I'd
rather write it myself." Or, at the best, the work falls on some, the
benefits on others (e.g., see over on the policy group for their review
process, where the tiniest operators pay for the reviews of the largest
operators).
In contrast, the notion of "afterwards - punishment" is a lot less
understandable. There appear to be two popular ways: reputation and
the long reach of the law. Reputation can be used to damn a developer.
The law can either lock him up or charge him all his profits.
It is this part that is often wrapped up in the so-called identity or
trust business. If you know the guy's name, so the concept goes, you
can be safe, because if something goes wrong, you pass his name to the
Feds or the Mounties (they always get their man). Or, you damn him to
all time on the mailing lists.
But this is specious. For a start, he might be outside the Feds
location, and we know how they never ever break the rules and cross the
borders. Or he might be a she, and the Mounties are stumped. Or it
might be a false name. Or or or....
It does have one advantage: You can collect these names far more
efficiently than you can review code. And, the cost falls on the
developer not someone else. So we could say that the system scales very
well, as long as it rarely needs to be called upon.
So what to do? One thing that does look better than either path is a
mixture of both. A small amount of identity and a small amount of
review. That is, once you've got your small identity handle, and it
relates to a small amount of review, another vista opens up: Alice
can't get her code reviewed, it's not even allowed in the Queue ...
until she's reviewed Bob's code. Or some metric.
Beyond spreading the load of the review, it also gives the review teeth.
If the reviewee's code turns out to be bad, the reviewer's reputation
could suffer. Which also points the bone of fear at the reviewer's own
code.
This method is called the web of trust. The word trust there is a
misnomer ... we all think of trust as good, so putting it in there is a
standard marketing trick to make us think this is good. But no matter
that; the WoT allows the work of several people to relate to the work
of other people. In a way that is shared, cheap, scaleable, and
community. Developers working for developers; hey, isn't that what
it's about?
iang
Adrienne Porter Felt
On Sun, Nov 29, 2009 at 8:05 PM, Adrienne Porter Felt <a...@berkeley.edu>wrote:
> A fortunate fact of the world is that the vast majority of Firefox
>>> extensions do not require the user's full authority. (That is the
>>> statement I have a bunch of data to back up.) If the extension
>>> ecosystem let authors restrict the privileges of their extensions (and
>>> encouraged them to do so), then vulnerabilities in extensions would be
>>> less severe because the attacker would obtain less that the user's
>>> full authority by compromising an extension.
>>>
>>
>> Furthermore, this would allow the community to better scrutinize the
>> security of the smaller number of extensions that would require higher
>> privileges.
>>
>
> I generally agree with this point of view. I like the idea of combining
> community review and least privilege. If a developer asks for a lot of
> privileges (i.e., host system access), then that extension has to go through
> a review -- which may slow down getting the app listed. Fewer apps have to
> be reviewed, and more developers are willing to request a small amount of
> privileges. Only a small number of apps really need host system access, so
> that would be great.
>
> The problem that we run into here, though, is that host system access isn't
> the only thing to worry about (although it's the biggest one). Access to
> web pages can still be abused, and extensions that want web access should
> perhaps still merit review. A lot of extensions want web access, so a lot
> of extensions would still need review. I don't know what to do about that.
> We don't have the ability to do partial DOM access at the moment so we
> can't do a "web site with no password or cookie access" type of privilege.
>
> One idea might be to force a delay. Like -- if you ask for host
> privileges, your app won't even start the review process for a week. If you
> ask for arbitrary web access, your app won't start the review process for
> another 4 days. If you ask for web access to only five sites or less, your
> app starts the review process in 2 days. Etc. That might bug developers
> enough to want to use as few privileges as possible.
>
> Another point I'd like to bring up is that a least privilege system (where
> the developer clearly declares all privileges) does make it easier to
> review, even if you still have to do a lot of reviews. The reviewer knows
> exactly what the worst case scenario is; you don't need to waste time
> looking for sneaky evil system calls if you know the extension can't make
> any system calls at all.
>
Adrienne Porter Felt
On Sun, Nov 29, 2009 at 7:51 PM, Adrienne Porter Felt <a...@berkeley.edu>wrote:
> > The study says that extensions use nsIFile to 'store information that
>> > is too complex for the preferences system'. What is 'too complex' ? If
>> > a key value store (viz. the preferences system) isn't good enough,
>> > would localStorage work ? Do you have a list of extensions for whom
>> > localStorage would be good enough (but can't work with just the
>> > preferences system) ?
>>
>
> It's not that extensions "can't" use with the preferences system. That was
> not what I meant to imply -- lazy wording on my part. Rather, developers
> choose not to use prefs when their data is complex -- they write XML or
> JSON. IMO this is because (1) writing XML out to a file is simpler/more
> familiar and (2) the name "prefs" does not make it sound like a place for
> general data storage.
>
> If nsIFile were taken away, I personally think either prefs or localStorage
> would be good and usable alternatives (although I would suggest a name
> change to prefs), keeping in mind Adam's points.
>
Mook
For non-Jetpack extensions, places like #extdev have been explicitly
telling people to avoid prefs for larger scale storage, because prefs
are always completely loaded on startup (so things like a table for a
site-specific extension wouldn't make sense. localStorage would work,
but then again the extensions could already access the sqlite storage
(https://developer.mozilla.org/en/Storage) stuff anyway.
(I must be odd, since about half my extensions don't interact with the
content page being viewed, and I don't think any of them is doable with
the current Jetpack API...)
--
Mook
(I do extensions and poke xulrunner apps, as a short background.)
Devdatta
> For non-Jetpack extensions, places like #extdev have been explicitly telling
> people to avoid prefs for larger scale storage, because prefs are always
ohh! Makes sense!
> completely loaded on startup (so things like a table for a site-specific
> extension wouldn't make sense. localStorage would work, but then again the
> extensions could already access the sqlite storage
> (https://developer.mozilla.org/en/Storage) stuff anyway.
The SQLlite stuff uses nsIFile. The problem is that nsIFile allows
arbitrary access to any file, which is not good. I don't want every
extension I install to have the power to delete all my documents. You
ideally want to limit the privileges of an extension to the minimum
(Principle of Least Privilege).
To me, it looks like (and I might be wrong here), there are two
obvious/simple ways to do it :
* Limit nsIfile to only write to files in a particular directory
(say specific to each extension).
* Make extension writers use stuff like localStorage and
disallow/discourage use of nsIFile.
(is there any other option I have missed?)
(There are ofcourse extensions that might require arbitrary file
access, but for them AMO could require intensive review )
I am a fan of option 1.
Mook : As an extension developer, what problems do you see with either
of the two options ? I am really interested in your viewpoint.
Cheers
Devdatta
Mook
> To me, it looks like (and I might be wrong here), there are two
> obvious/simple ways to do it :
> * Limit nsIfile to only write to files in a particular directory
> (say specific to each extension).
This would cover quite a bit, actually; most things really just want to
stick some persistent data _somewhere_, not anywhere in particular. As
an extension developer who really just wants stuff to keep working with
the minimum effort, of course this is my preferred option - well, next
to having no restrictions of course ;)
> * Make extension writers use stuff like localStorage and
> disallow/discourage use of nsIFile.
This would cover a smaller subset of the above - it wouldn't be useful
for things like greasemonkey (multiple files), but might be for, say,
adblockplus (giant list of things). This of course assumes that each
extension gets its own localStorage space, since enumeration is used
quite often too.
> (is there any other option I have missed?)
For completeness, there's also one sqlite db per extension which can go
create as many tables as it wants). Possibly also free access to the
profile, but not outside of it, but given that the list of extensions is
there too it's uncertain how useful that is.
> (There are ofcourse extensions that might require arbitrary file
> access, but for them AMO could require intensive review )
> I am a fan of option 1.
As long as it's opt-in, yes, that should be fine. I've always
considered the extension mechanism to be successful _precisely_ because
it's totally unrestricted (the one I started poked native window handles
and made Win32 API calls!). Hopefully, with the carrot of shorter
review times, more people would be able to use the safer model, without
having to disallow the unsafe method completely.
> Mook : As an extension developer, what problems do you see with either
> of the two options ? I am really interested in your viewpoint.
Both options (and, really, anything else too) would require the platform
to suddenly know which extension your code is from; I don't know how
easy it would be for that to happen. But I'm sure there are people
smarter than I am who could do it without breaking the
needs-to-be-unsafe extensions ;)
--
Mook
Devdatta
> This would cover quite a bit, actually; most things really just want to
> stick some persistent data _somewhere_, not anywhere in particular. As an
There are two related properties we are talking about here :
1. Most extensions can survive with just nsIFile access to a (their
own) particular folder
2. Currently most extensions only use nsIFile to access things in
their own folder anyway.
From what I read, you said 1. is true. I am also interested in knowing
about the second. Do you have any idea about the second property
through your involvement in the AMO/extdev community ?
Cheers
Devdatta