Re: [whatwg] Proposal for a debugging information API
I'm not sensing a lot of enthusiasm about this proposal, and am guessing it would be an uphill slog with all the privacy/security issues involved. I'm therefore thinking I won't take it any further. If you feel something important is being lost here and that you could help me move this forward do let me know though. Thanks, -Dave On Fri, Nov 16, 2012 at 6:04 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 Nov 2012, David Barrett-Kahn wrote: Thanks Ian. So here's what confuses me, why is the bar so much higher for traditional webapps than it is for browser extensions, chrome apps, native apps, mobile apps or nearly anything else? Browser extensions, chrome apps, native apps, and mobile apps aren't anywhere near as secure as Web apps. The bar shouldn't be any lower for them than for the Web, but that it is is one of the Web's biggest strengths. You can, by and large, follow any random link, and be assured that you're not going to get scammed (modulo security bugs). If you just install any random native program you come across, your machine is going to become a nest of malware. Extensions, chrome apps, and mobile apps have a consent experience, but it's hard to argue that users are making an informed decision there and that the consent experience really protects them. Native apps have no consent experience at all. Right. Compare the average amount of malware on a Windows machine to that on a Chrome OS machine. :-) I guess I'm hoping you can point me to some guidelines you've developed or which you agree with on where the limits of the web sandbox should be. I'd rather not force you to re-have a discussion I'm sure you've had far too many times :-) I don't think there's anything formally written down. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- -Dave
Re: [whatwg] Proposal for a debugging information API
On Thu, 15 Nov 2012, David Barrett-Kahn wrote: Ian, I'd be interested in what you had in mind when you said 'a lot of user opt-in'. I don't know, exactly. It has to be something where we're confident that the user understands that he is about to send sensitive information to a stranger. The concern isn't when this is used by a company like Apple or Facebook; the worst such companies are going to do with sensitive data is target ads better or make their products more streamlined. The concern is when some attacker wants to get information about your company's intranet's topology, or wants to know what potentially vulnerable plugins or extensions you have installed, or wants to know what software you are running, so that they can more precisely target you. Such an attacker can trivially provide you with a game to play, and then have the game crash, misleading you into thinking they're a perfectly honest game developer and causing you to eagerly send them all the sensitive information they want. These are not hypothetical concerns. Over the last few years, targetted attacks of this nature have become much more common and are a real threat. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for a debugging information API
Thanks Ian. So here's what confuses me, why is the bar so much higher for traditional webapps than it is for browser extensions, chrome apps, native apps, mobile apps or nearly anything else? Extensions, chrome apps, and mobile apps have a consent experience, but it's hard to argue that users are making an informed decision there and that the consent experience really protects them. Native apps have no consent experience at all. I guess I'm hoping you can point me to some guidelines you've developed or which you agree with on where the limits of the web sandbox should be. I'd rather not force you to re-have a discussion I'm sure you've had far too many times :-) Regards, -Dave On Fri, Nov 16, 2012 at 10:06 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 15 Nov 2012, David Barrett-Kahn wrote: Ian, I'd be interested in what you had in mind when you said 'a lot of user opt-in'. I don't know, exactly. It has to be something where we're confident that the user understands that he is about to send sensitive information to a stranger. The concern isn't when this is used by a company like Apple or Facebook; the worst such companies are going to do with sensitive data is target ads better or make their products more streamlined. The concern is when some attacker wants to get information about your company's intranet's topology, or wants to know what potentially vulnerable plugins or extensions you have installed, or wants to know what software you are running, so that they can more precisely target you. Such an attacker can trivially provide you with a game to play, and then have the game crash, misleading you into thinking they're a perfectly honest game developer and causing you to eagerly send them all the sensitive information they want. These are not hypothetical concerns. Over the last few years, targetted attacks of this nature have become much more common and are a real threat. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- -Dave
Re: [whatwg] Proposal for a debugging information API
On Fri, 16 Nov 2012, David Barrett-Kahn wrote: Thanks Ian. So here's what confuses me, why is the bar so much higher for traditional webapps than it is for browser extensions, chrome apps, native apps, mobile apps or nearly anything else? Browser extensions, chrome apps, native apps, and mobile apps aren't anywhere near as secure as Web apps. The bar shouldn't be any lower for them than for the Web, but that it is is one of the Web's biggest strengths. You can, by and large, follow any random link, and be assured that you're not going to get scammed (modulo security bugs). If you just install any random native program you come across, your machine is going to become a nest of malware. Extensions, chrome apps, and mobile apps have a consent experience, but it's hard to argue that users are making an informed decision there and that the consent experience really protects them. Native apps have no consent experience at all. Right. Compare the average amount of malware on a Windows machine to that on a Chrome OS machine. :-) I guess I'm hoping you can point me to some guidelines you've developed or which you agree with on where the limits of the web sandbox should be. I'd rather not force you to re-have a discussion I'm sure you've had far too many times :-) I don't think there's anything formally written down. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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.lan...@gmail.comwrote: On Thu, Nov 15, 2012 at 6:07 AM, David Barrett-Kahn d...@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
[whatwg] Proposal for a debugging information API
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. I've fleshed this out in the following document, and would value opinions on the value of a feature of this kind, and the merits of this particular approach. https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk Thanks! -Dave
Re: [whatwg] Proposal for a debugging information API
Recent blog posts that coincidentally may be useful in this discussion: http://vocamus.net/dave/?p=1532 http://www.twobraids.com/2012/11/socorro-as-service.html On Thu, Nov 15, 2012 at 12:07 AM, David Barrett-Kahn d...@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. I've fleshed this out in the following document, and would value opinions on the value of a feature of this kind, and the merits of this particular approach. https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk Thanks! -Dave -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] Proposal for a debugging information API
Yes, thanks, these are just the sorts of systems which would be used to collect this information were it available. I believe that as it becomes easier for less well resourced development teams to have crash reporting of this kind its use will become more widespread, and that it will eventually become part of the standard toolkit. -Dave On Wed, Nov 14, 2012 at 9:12 PM, Gordon P. Hemsley gphems...@gmail.comwrote: Recent blog posts that coincidentally may be useful in this discussion: http://vocamus.net/dave/?p=1532 http://www.twobraids.com/2012/11/socorro-as-service.html On Thu, Nov 15, 2012 at 12:07 AM, David Barrett-Kahn d...@google.comwrote: 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. I've fleshed this out in the following document, and would value opinions on the value of a feature of this kind, and the merits of this particular approach. https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk Thanks! -Dave -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ -- -Dave
Re: [whatwg] Proposal for a debugging information API
On Wed, 14 Nov 2012, David Barrett-Kahn wrote: 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's basically no way we could ever do this without a lot of user opt-in, because of the privacy concerns (a hostile site could embed a user's facebook page, trigger a crash to get a screenshot, and then scrape the screenshot and compare it to the hardware information to work out what device they were using, who they were, etc). Just having a dialog as you propose here: https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk ...would probably not be enough; users can easily be tricked into clicking that kind of dialog (e.g. by using misleading domain names, or by having them play a game that involves hitting enter a lot). Clearly though this kind of thing would be hugely helpful for debugging. My recommendation would be to approach browser vendors directly with the proposal and experiment with different ideas to find one that balances user concerns with practical results, somewhat as discussed here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
