Re: Some Feature requests.

That will do nothing to affect identifying the GPU through compute and
offscreen renders, indeed those two are the best way to figure out what is
the GPU.

-Kevin

On Thu, Aug 8, 2019 at 9:12 AM Markus Schütz <mschuetz@potree.org> wrote:

>
> I admit I don't know too much about fingerprinting but I'd like to see it
> prevented without taking away too much performance potential from the
> developers.
>
> Something that I was thinking of, wouldn't it be possible to tie any
> functionality with the potential to fingerprint to an opaque canvas that
> covers at least 66% of the page, with those 66% being actually visible? And
> that canvas can be resized but not be resized to anything smaller than that
> 66% for, let's say, 5 seconds. This would make it way too obnoxious for
> sites that want to exploit WebGPU for fingerprinting without doing anything
> useful with it.
>
> On 07/08/2019 23:30, James Darpinian wrote:
>
> Kevin makes an interesting point that I hadn't considered. Explicitly
> providing GPU info by default can give the browser and user more control.
>
> If we don't provide GPU info, sites will be forced to implement GPU
> fingerprinting methods that are infeasible for us to block. Such methods
> will be widespread and included in popular libraries. If we do provide GPU
> info by default, sites will likely rely on it instead of implementing
> unblockable GPU fingerprinting. Then we will have the option to modify the
> GPU info we provide in some situations, such as a private browsing mode. In
> practice, the privacy of private browsing mode could be higher in the
> latter scenario than the former.
>
> On Wed, Aug 7, 2019 at 1:30 PM Kevin Rogovin <kevinrogovin@invisionapp.com>
> wrote:
>
>> Hi,
>>
>> I am sorry, this is very counter-productive to the success of WebGPU
>> whose goal is to close the performance gap for hardware accelerated
>> graphics between native and web.
>>
>> The previous posts prove that that it is quite possible and feasible to
>> identify (roughly) the GPU at the cost of slower start-up performance and
>> batter life on mobile. GPU-intensive apps will NEED to do this (because the
>> performance profile for different GPU's is literally all over the map
>> across architectures for various specific loads), thus it will be done.
>> Rather than making the developer's life more difficult along with making
>> the user's experience worse, there is a pretty clear way forward: provide
>> the GPU info directly. If hiding this is important to a user, just as many
>> browsers allow for changing the browser ID, perhaps a browser can also
>> provide an option to NOT provide the GPU (i.e. a WebGPU implementation
>> would report "Generic GPU"). This would then give customers the control of
>> identifying the hardware, and for those users which take that option who
>> use a highly GPU intensive app, the downside that it the app will run
>> perf-test-probing along with other probing on the device. In all honesty,
>> compared to all the other shenanigans going on with browser tracking, this
>> is by far the smallest potato.
>>
>> If we were in a world where the GPU architectures were quite similar,
>> this would not be needed, but that is not the world we live in (in all
>> honestly thankfully too, since variety in hardware is a good thing in my
>> eyes).
>>
>> My 2 cents.
>>
>>  -Kevin
>>
>> On Wed, Aug 7, 2019 at 11:04 PM Dean Jackson <dino@apple.com> wrote:
>>
>>>
>>>
>>> > On 7 Aug 2019, at 14:05, Doug Moen <doug@moens.org> wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Aug 6, 2019, at 10:35 PM, Myles C. Maxfield wrote:
>>> >> We’ve heard this defeatist argument before and entirely disagree with
>>> it.
>>> >
>>> > My point is that security designs by non-experts have a poor track
>>> record.
>>> > I think fingerprinting security for WebGPU should be designed by a web
>>> browser fingerprinting security expert
>>>
>>> We agree. This *is* advice from our Web Browser fingerprinting security
>>> experts.
>>>
>>> It's not a secret that there are low-level techniques to identify
>>> hardware, and thus users. Their existence does not mean it is acceptable to
>>> provide high-level ways to identify hardware/users.
>>>
>>> To give an analogy (that will probably cause more distraction than help,
>>> but whatever).... just because someone can throw a brick through your
>>> window doesn't mean you should leave your front door unlocked. Maybe some
>>> day you'll get brick-proof windows.
>>>
>>> Dean
>>>
>>>
>>> > , and I also think that you are trying to fix the problem at the wrong
>>> level of abstraction. The security should be provided at a level above the
>>> WebGPU API.
>>>
>>>
>>>
>