[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Conformance OSX 10.7.x



Users aren't necessarily technical experts.  Most people can understand concepts like "Site X wants to know where you are" and "Site Y wants to take pictures of you".  Asking for advice on technical issues is more problematic because a typical user does not have the technical knowledge to be able to make a meaningful answer.  This is an issue that has been discussed in detail in numerous committees over numerous contexts.

Punting to the user on a technically driven security issue is a security anti-pattern.

If this information is _really_ necessary, then the goal should be to make the absolute minimum amount of information available.  eg. Rather than saying "can we have an api to provide a string containing all the gpu info" we could ask "exactly what information is required? How can we provide just that information?" and provide that info through a single explicit API.

--Oliver

On Feb 1, 2013, at 2:16 PM, Gregg Tavares <gman@google.com> wrote:




On Fri, Feb 1, 2013 at 11:33 AM, Oliver Hunt <oliver@apple.com> wrote:

How does the end user know which button to press in this dialog?

What do you mean?

I'm assuming it would be just like geo location permission or webcam permission.

"http://webcamtoy.com/ wants to use your camera. [ Deny ] [ Allow ]"

"http://webglsite.com/" wants to gather hardware about your system. [ Deny ] [ Allow ]"
 
Note: I'm not sure if I'm for or against this proposal. Just suggesting how I would expect it to work.



--Oliver

On Feb 1, 2013, at 11:28 AM, Kenneth Russell <kbr@google.com> wrote:

>
> Balancing the needs for privacy and precise bug reports, it's been
> suggested by Jeff Gilbert during a recent face-to-face meeting that a
> WebGL extension be proposed which prompts the user for permission to
> access information about the 3D graphics card. If the user grants it,
> then plausibly the
> http://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/
> extension would be allowed to be fetched. Additional information could
> be added to that extension as necessary. This would let the
> application construct its own bug report.
>
> If someone could propose such an extension that would be great. It
> would need to pass in some sort of completion callback indicating
> success or failure to the function which prompts the user for
> permission.
>
> -Ken
>
>
>
> On Thu, Jan 24, 2013 at 9:19 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> It's not a bad idea per-se (except that perhaps instead of an email I'd like
>> to get it as a JSON-post to my troubleshooting interface or such).
>>
>> What I'd like to see goes further than that however:
>>
>> - We don't need to know for an identical configuration that a user has run
>> into the issue, again, we already know it's a problem.
>> - We'd really like to know how many of our visitors (if they click the
>> report or not) are gonna have that configuration, so we can prioritize
>> bugfixes and workarounds.
>> - If we already know that for out application this users configuration is
>> gonna be a problem, we don't need to send him down the rabbit hole only to
>> find out it sucks. We could tell him up front "dude, I'm sorry but it won't
>> work, we're working on fixing it, meanwhile, try ..."
>>
>> So the paradox is this: In order to provide a *good* user experience we need
>> to profile our users. However we also want avoid the baddies to profile our
>> users. So meh, kinda sucks.
>>
>>
>> On Thu, Jan 24, 2013 at 6:07 PM, Brandon Jones <bajones@google.com> wrote:
>>>
>>> Here's a (somewhat unorthodox) idea:
>>>
>>> I've always understood the resistance to exposing GPU/driver specs via
>>> _javascript_ to be a countermeasure against using that information to
>>> fingerprint a user's system for tracking, combined with a reluctance to
>>> encourage developers to start writing code that targets specific hardware.
>>> As Florian points out, though, when something goes wrong that's immediately
>>> the first thing that both the app developer and the browser vendor asks for:
>>> system configuration. Unfortunately Florian is also correct that many users
>>> don't know how or won't go to the trouble of explicitly submitting this
>>> information with their complaints.
>>>
>>> What an automated system was put in place that allows user to send an
>>> email to the app developers pre-populated with relevant specs at the push of
>>> a button? For example, in Chrome we now have an infobar that triggers on
>>> certain WebGL issues. It would be  nice if the site could provide some
>>> contact info that would change the info bar from "Something went wrong,
>>> click to reload" to "Something went wrong. www.AwesomeWebGLGame.com has
>>> requested more information about the problem you are experiencing, click if
>>> you would like to contact them about this issue" (That's a bit wordy for an
>>> infobar, but you get the idea). The result of this could be as simple as
>>> launching their default email client and pre-populating some system specs
>>> and the support email for the site (Maybe even a screenshot?). That way
>>> there's complete transparency about what's being sent, and the chances of
>>> the developer getting quality information goes up dramatically. Since it's
>>> dialog/infobar driven the site can't silently scrape the info for tracking
>>> purposes without the user explicitly knowing it. Sounds like a decent
>>> compromise.
>>>
>>> The biggest issue I see is that the only cases where this could be
>>> launched automatically are crashes, context loss, or something similar.
>>> Those cases can be interesting to the application developer, but more often
>>> than not those scenarios are of more interest to the browser vendors. Things
>>> like corrupted rendering, missing textures, or other non-crashing anomalies
>>> are typically only able to be identified by the user, in which case a
>>> "report a problem" button is more appropriate. It shouldn't be a big deal to
>>> provide an API to request the infobar/dialog though, which would give app
>>> developers more control while still keeping the process in the users hands.
>>>
>>> I realize this is a pretty significant feature I'm proposing but I do
>>> strongly feel that if we want the development community to really embrace
>>> features like WebGL we need to give them all the tools we can to address the
>>> new development challenges they represent. This is my idea for that, and I'd
>>> be happy to hear other ideas on how to provide this critical information to
>>> developers in a security-conscious manner. I think to rely solely on
>>> dev/user communication to collect this critical information is probably a
>>> mistake in the long run, though.
>>>
>>> --Brandon
>>>
>>>
>>> On Thu, Jan 24, 2013 at 8:04 AM, Florian Bösch <pyalot@gmail.com> wrote:
>>>>
>>>> On Thu, Jan 24, 2013 at 4:26 PM, Mark Callow <callow.mark@artspark.co.jp>
>>>> wrote:
>>>>>
>>>>> I can't think of any other way, short of blacklisting, to prevent the
>>>>> developer spending that time re-investigating the bug.
>>>>
>>>> So this is what happens:
>>>> 1) User runs app
>>>> 2) Problem
>>>> 3) User tells developer of problem
>>>> 4) Developer scratches head
>>>> 5) Developer spends some time futily trying to reproduce bug on a machine
>>>> where it is not present
>>>> 6) Developer asks user for his GPU/OS/driver combination (because WebGL
>>>> does not expose it)
>>>> 7) Users reaction "o_O wut?"
>>>> 8) 90% of such users are never heard of again
>>>> 10) some users report their configuration, which the developer doesn't
>>>> have.
>>>> 11) Intdeterminate time later, Developer gets chance to run his app on a
>>>> problematic configuration
>>>> 12) spends days/hours actually tracing down the bug
>>>> 13) having found the bug confirms against the conformance
>>>> 14) files a bug ticket
>>>> 15) gets told it won't be fixed
>>>>
>>>> Now repeat that times developers times users times configurations and
>>>> it's a lot headscratching, tweeting, bad blog postsing, people dissing WebGL
>>>> on HN and /. and son. Wash, rhinse and repeat. And I think we'd like that
>>>> avoid somehow.
>>>>
>>>> So there's two aspects to that problem: Where to catch it and how to
>>>> catch it.
>>>>
>>>> The answer to the "where" question should be fairly simple, it should
>>>> happen as early as possible. The answer to the how question seems to be that
>>>> we have these means to deal with it:
>>>> - Blacklist
>>>> - Differentiate by the experimental prefix
>>>> - Introduce an extension to differentiate
>>>>
>>>> I don't think the blacklist is a really good measure, because conceivably
>>>> not all applications will have issues with it.
>>>> The differentiation by experimental prefix sounds ok to me, but, at the
>>>> moment it's all experimental. So it doesn't actually solve anything right
>>>> now. So the functionality of an extension seems to be pretty similar, except
>>>> that it would offer a solution to this maybe faster than we can get rid of
>>>> the experimental prefix.
>>>>
>>>> Regardless, I see a problem in baking this into the experimental prefix
>>>> or an extension. Everytime a new device or driver pops up, you'll have to
>>>> update the browser so that the list gets updated and you'll have to hope
>>>> that this propagate trough the userbase fairly quickly so you won't have to
>>>> answer hundreds of emails about issues you already know about.
>>>>
>>>> So on top of my head, if this was a native app, here's what I'd do:
>>>> 1) User runs app
>>>> 2) Problem
>>>> 3) Open a dialog prompting the user to send me a report
>>>> 4) Queries an interface on my server that compares the driver, os and gpu
>>>> to a database of issues
>>>> 5) Automatically issues the user an apology and advice in case that he
>>>> has run into a known issue
>>>> 6) If not a know issue, creates a new support case for me to investigate.
>>>>
>>>> So we can't do that in WebGL because the driver and GPU is not exposed.
>>>> I've mentioned before that this would really handy. And understand why you
>>>> wouldn't want to do that. Nevertheless, I think that would be one of the
>>>> most sensible solutions.
>>>
>>>
>>
>
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------