I can take a stab at more formal heuristics for bookmarks, at least. We
will have a better idea of actual limiting parameters for bookmarks (as in
how many operations in a certain time frame is reasonable) once the
ExtensionsActivityMonitor I just landed percolates and we can aggregate
across representative sample data it produces.
I guess the docs were too long for more folks to read through :)
For those who have read, what are thoughts on the proposal to maintain a
counter per-function, and per-item-id in some cases? So for detecting the
situation
bookmarks.update(123, "title:Foo")
bookmarks.update(123, "title:Foo")
bookmarks.update(123, "title:Foo")
... 17 times for example
we would have a map somewhere with one entry for each bookmarks function,
and the 'update' entry would look like
( "bookmarks.update", { (123, hash<title:"Foo">, 20), ...} )
maintaining a history of length *at most* 1 for at most every bookmark. If
an 'update' comes in for '123' that tries to update it in some *other* way,
the hash would be different so we'd reset the count and allow the operation.
We could also either store a timestamp or use a timer task to
discard records that were 'old enough'.
For bookmarks.create, store (hash<last input>, count), and limit quota to a
count of 10 per hour (mostly arbitrary numbers right now).
Same for bookmarks.remove. For starters, out of simplicity I wouldn't try
and associate removals with adds or do any cross-referencing to detect
things like 'you just added and removed the same item 100 times in a
minute', but hope that 'you just added the same item 100 times in a minute'
+ 'you just removed the same item 100 times in a minute' signals will help a
little on their own, independently from each other.
Do these seem like they would eat up too much memory?
As for requesting such a quota limitation be turned on, what are thoughts on
my proposal to request it in the manifest/permissions block? Is that doable?
We would need a way for browser/sync to toggle it too, but that's likely
just an implementation detail.
On Wed, Oct 21, 2009 at 5:55 PM, Aaron Boodman <[email protected]> wrote:
> Have not read all of it yet, but am in favor in general of having some
> sort of quota for extension api calls to protect from meltdown.
>
> We have a very convenient chokepoint to implement this in our system,
> so it would just be a matter of a more detailed design of the
> heuristics to use for each API type.
>
> - a
>
> On Wed, Oct 21, 2009 at 5:08 PM, Tim Steele <[email protected]> wrote:
> > [re-sending from correct email account]
> > Hi,
> > I wrote up a document that discusses some interesting unintentional
> > relationships that can exist between independent extensions, and how this
> > general problem also currently affects the browser sync engine. This
> issue
> > was discovered from trying to explain the primary symptom of unusually
> high
> > syncing traffic generated by Chrome clients. Please find it here:
> > A Tale of Two (or more) Sync Engines
> > You should read that before continuing!
> > This led to me thinking about what we do long term, short term, or
> basically
> > before Chrome Sync and extensions are running in parallel in a beta
> channel
> > environment. You'll see a bit of this at the end of the first document,
> but
> > after posing the problem as an extensions problem I ended up at a random
> > idea that I think makes at least a little sense, though I admit I was
> having
> > fun thinking and writing about it so maybe I missed some major roadblocks
> > along the way. There are downsides, mainly revolving around the added
> > hand-holding we would impose on extensions. Please read! Hoping for
> > comments and feedback. Extensions API "quotaserver"
> > In addition to that, Colin and Todd (cc'ed) brought up some sync specific
> > ideas they have (I mention it a bit at the end of the first doc). We'll
> try
> > to get a separate thread going about this soon!
> > Thanks!
> > Tim
> > > >
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
