NPAPI Clear plugin site data

Josh Aas josh at
Wed Jan 5 19:12:54 PST 2011

Moving the proposal to accepted status, thanks for all of the input on this! I'll make the changes to our standard headers this week.

Josh Aas
Software Engineer
Mozilla Corporation

----- Original Message -----
From: "Jethro Villegas" <jvillega at>
To: jeffreyc at, "Kevin Decker" <kdecker at>
Cc: "Maciej Stachowiak" <mjs at>, plugin-futures at, josh at
Sent: Wednesday, January 5, 2011 9:43:22 PM
Subject: Re: NPAPI Clear plugin site data

Adobe Flash Player approves the proposal and we look forward to seeing this in the Mozilla source trunk. Who gets to make the code check-in? 



-----Original message----- 

From: Jeff Chang <jeffreyc at> 
To: Kevin Decker <kdecker at> 
Cc: Maciej Stachowiak <mjs at>, "plugin-futures at" <plugin-futures at>, Josh Aas <josh at> 
Sent: Thu, Jan 6, 2011 02:21:50 GMT+00:00 
Subject: Re: NPAPI Clear plugin site data 


Kevin, can you clarify exactly whom (or what organizations) you mean when you say "everyone else"? In other words, who do you need to hear from before we can officially move this to accepted status? 


On Tue, Jan 4, 2011 at 3:38 PM, Kevin Decker < kdecker at > wrote: 

Josh and Dan -- 

This looks great. If everyone else is on board, hopefully soon we can move this to accepted status! 


On Dec 25, 2010, at 2:55 PM, Josh Aas wrote: 

Thanks Maciej. Dan and I think the paired API option is a good idea. We had considered it before but thought it would be more complex than it turned out to be. I updated the current proposal: 


Josh Aas 
Software Engineer 
Mozilla Corporation 

----- Original Message ----- 
From: "Maciej Stachowiak" < mjs at > 
To: "Josh Aas" < josh at > 
Cc: plugin-futures at 
Sent: Friday, December 24, 2010 4:12:33 AM 
Subject: Re: NPAPI Clear plugin site data 

On Dec 23, 2010, at 8:13 PM, Josh Aas wrote: 

Dan and I updated the spec with a new definition for the site argument. The goal was to remove ambiguity, simplify parsing, and clarify the handling of sub-domains. 

* If NULL, all site-specific data and more generic data on browsing history (for instance, number of sites visited) should be cleared. 

* If !NULL, argument is a domain per the domain portion of the URI specification but with a requirement for NFKC-normalized UTF-8 encoding. No other encoding is allowed. All sub-domains of the specified domain are to be cleared as well. If a sub-domain is specified only it and its sub-domains are to be cleared. For example, if a browser specifies " " then data for " " and " " is to be cleared but data for " " is not to be cleared. 

Any objections or concerns? 

I think this approach is unfortunate, because it locks in a very loose notion of the scope of data (domain plus subdomains), and forces any plugin that implements the mapping 

I would prefer an approach where there is a getter that returns a list of tokens (preferably origins, but perhaps domains are acceptable), and a clear function that is defined to only work on items returned from the getter. This puts the responsibility for subdomain folding on the browser, not plugins, which seems more reliable. Having every plugin implement subdomain folding creates the risk of subtle mismatches and therefore privacy loopholes. It also allows browsers to decide on the level of granularity they'd like to show in their UI, instead of forcing course granularity on all browsers. 

One thing I'd like to understand is the use case for using NPP_ClearSiteData with a domain argument in the absence of GetSitesWithSiteData. All the uses I can imagine seem broken: 

A) Have the user type in a domain name - clearly unacceptably geeky HI. 
B) Show a list of sites based on data the browser knows about (cookies, local storage, etc), and only let the user clear plugin data for a specific site by picking from that list. This seems gravely misleading, since a site that *only* stores plugin data will never show up, leading the user to erroneously conclude that said site does not hold any privacy-sensitive data. 

If I'm missing some sensible UI that can be built with NPP_ClearSiteData + domain argument, but without NPP_GetSitesWithSiteData, please let me know. 

I can, of course, imagine valid use cases for NPP_ClearSiteData with no domain, such as buttons that let the user delete site data from all sites, or for a specific time range. 

Given this, I propose one of the following: 

Option 1) For now, we define only NPP_ClearAllSiteData, which has no domain argument, but has all the other current arguments of NPP_ClearSiteData. Later, we add both NPP_GetSitesWithSiteData and NPP_ClearSiteDataForSite, which takes a domain or origin argument (must be one of the ones returned from GetSitesWithSiteData to have any effect). 

Option 2) We define both NPP_ClearSiteData and NPP_GetSitesWithSiteData now, packaged as a single proposal; if the origin/domain argument is non-NULL, it must be one of the ones returned from NPP_GetSitesWithSiteData. 

With either of those, it becomes somewhat less important what the site identifier is, but I would propose origin. 


plugin-futures mailing list 
plugin-futures at 

plugin-futures mailing list 
plugin-futures at 

More information about the plugin-futures mailing list