Re: [whatwg] Proposal for a debugging information API

Thanks Tobie, that does sound related, but not quite the same use case.
 That proposal seems to want to make the creation of memory/network/runtime
performance profiles scriptable if the user allows it.  Presumably you
wouldn't do that routinely, which raises the question of when you would do
it.  Once the app has crashed it's probably too late.  I foresee this
mainly being used by groups of users 'friendly' to the application author,
such as employees of their firm, qa testers, etc.  Their privacy issue
isn't so bad, either, as there would be nothing in those profiles which the
app author didn't in principal have access to before.  I'm also not sure my
use case falls inside the performance working group's charter.  In any
case, I'll reach out to them and see if they're interested, thanks.

Ian, I'd be interested in what you had in mind when you said 'a lot of
user opt-in'.
 Presumably you don't feel a permission dialog raised at the time of the
API call enough, were you thinking of a browser configuration setting, off
by default?  That's very limiting, you'd be down to 'friendly users' again.
 Your other objections I think could mostly be dealt with.  I've specified
that user agents supporting the screenshot have to provide a blackout tool.
 Also, in some ways the more annoying this dialog is the better, as it's
supposed to be something devs only use if they really need to.  You could
focus the 'no' button by default, or make it unresponsive until a timeout,
stuff like that.

I'll raise this with some of the browser vendors directly as Ian suggested.

Thanks,

-Dave


On Thu, Nov 15, 2012 at 1:46 AM, Tobie Langel <tobie.langel@gmail.com>wrote:

> On Thu, Nov 15, 2012 at 6:07 AM, David Barrett-Kahn <dbk@google.com>
> wrote:
> > Hi whatwg.  I have a proposal for a new web standard, and would value
> your
> > feedback.  This is based on my experiences working on Google Docs, which
> > has a well developed ability to send crash reports back to the server for
> > analysis.  We often find these crash reports to be lacking in crucial
> > information though, because that information is not available on the JS
> > APIs.
> >
> > My proposal is to have a class of information which can be made available
> > to an app only after the display of a generic 'this application has
> > crashed' dialog, which could be drilled into to show what is being
> > disclosed, and which of course can be denied.
> >
> > Good examples of the information in question are the system's precise
> > hardware and network configuration, what Chrome extensions it has
> > installed, and perhaps a screenshot of the failed application.
>
> There is directly related work[1] being included in the WebPerf
> WG[2]'s upcoming charter. Given the privacy and fingerprinting
> constraints are the same, you should probably bring your suggestions
> there.
>
> --tobie
> ---
> [1]:
> https://docs.google.com/document/d/1Yw_qNMCnGsWQRsdcrifzh_kzFey-ThQ3yp-DmxuJxvg/edit
> [2]: http://www.w3.org/2010/webperf/
>



-- 
-Dave

Received on Friday, 16 November 2012 01:28:55 UTC