Guid attribute proposal

[Ryan Doherty]

So from what I can tell there's two possibilities here:

1) Use a guid (format tbd)
Engineering complexity: low, requires new web API and browser vendors to use the guid if available
Maintenance complexity: low, requires adding guids to database
Ecosystem complexity: high, requires communicating with as many plugin vendors as possible and communicating benefit of adding a guid

2) Use md5 
Engineering complexity: high, requires computing hash from installed plugin for database and via browser
Maintenance complexity: medium, requires uploading installers to webapp or computing manually for every release, dealing with changes to install locations, new code written for each plugin
Ecosystem complexity: low-high, requires some communication to plugin vendors on how this system works, if crowdsourced requires methods of gathering and verifying data


Open questions:
* GUID format - I'm fine with a human readable format
* If guids were added, what's the best method of accessing/storing the guid? Sounds like resource data and plists?


I'm not convinced a md5 method would be worth the effort. imo I'd rather take on initially communicating with plugin vendors to get things rolling than deal with designing, building and maintaining a system to compute md5 sums. Sounds brittle to me. 




Ryan Doherty
rdoherty at mozilla.com

On Jul 29, 2010, at 8:58 AM, Lloyd Hilaiel wrote:

> On Thu, Jul 29, 2010 at 07:41:02AM -0700, l.m.orchard wrote:
>> I still want to see a GUID, but it seems like there could be
>> benefits to having an MD5 of the plugin binary.
> 
> Fair enough.  
> 
>> One case where this would fail is in a new version of a known plugin
>> we hadn't cataloged yet. We'd probably still be stuck with fuzzy
>> sniffing there. We've been hoping to use that case as a way to clue
>> us in on plugin updates we hadn't heard of from other channels.
> 
> Agreed.  Another weakness is the local compilation case (as mentioned
> by Kevin).  Another weakness would be plugins that dynamically change
> themselves.  In the case of plugin check, however, the cost of failure
> for abnormal cases seems low ("We couldn't recognize this plugin!
> would you like to submit it to mozilla for identification?").
> 
> And one case where fuzzy sniffing would fail is in the gnash case when
> a plugin is doing its darndest to look like someone else.  For the
> purposes of updates, gnash and flash are different products with
> different updates and vulnerabilties at different times.  A signature
> solves this.
> 
>> It would also take some tooling to produce an MD5 from a plugin,
>> though maybe that same tool could extract the current name / version
>> / mimetype set for the plugin directory. It might be nice to have an
>> upload form in the directory web UI that chews on a binary and
>> produces an auto-filled release record.
> 
> Great idea, a little panda that eats plugin binaries/directories and
> poops well structured metadata.  Crafting such a thing seems a fun
> experiment ("submit to the plugin eating panda for identification?").
> 
>> It would still require browser vendor coordination to expose plugin
>> MD5s / use an update service. I'm not sure whether or not that would
>> be a change to NPAPI.
> 
> How about crowd sourcing this?  If you could get the binary plugins
> installed on a random selection of 10k end users machines, wouldn't
> you be able to algorithmically build a pretty solid database (I expect
> this problem will require the development of heuristics much less
> sophisticated that what's already been thunk here:
> https://wiki.mozilla.org/PFS2#General_Algorithm)
> 
>> I guess the difference isn't in whether participation is desired -
>> it's to what degree and how onerous. Less coordination is good.
> 
> Agree.  Vendor coordination becomes encouraged, but is not required
> for the system to function well.
> 
> lloyd
> 
>> 
>> -- 
>> lorchard at mozilla.com
>> {web,mad,computer} scientist