Re: Device Memory header and JS API

[Enrico Weigelt, metux IT consult]

On 07.09.2017 23:30, Daniel Veditz wrote:

​Without some kind of signal everyone gets the least-common-denominator 
version of a site 


Exactly. That was the idea behind the web. Unfortunately, so many
things have been added in recent years that browsers became more
complex than operating systems and web coders take lots of dubious
assumptions (gladly, they meanwhile learned not to dictate screen
resolutions anymore :o), and the code of major sites becomes worse
day per day.

Just compare Facebook vs. VK: same functionality - FB is extremly
slow and fat, VK is very slim and fast. Ergo: folks like FB should
just do their homework (or become optimized-away someday).

(and even then older equipment or phones may result in 
a poor experience) or sites will try to guess based on user-agent.


Well, it's been a while since I was actively building web apps,
(when PCs were slower than today's cheap smartphones). I can't
recall any case where I had wished such an feature. My applications
also worked well even on the early smartphones (eg good old Nokia
communicator).

For images and things maybe CSS could specify some media queries that 
loads different resources based on local factors like amount of memory 
or network speed, but then that's leaking the same information just in a 
different way.


Not necessarily, and not in the same granularity. Of course it would be
better, if requests to css+co wouldn't send cookies.
(IMHO, cookies are a very bad invention to begin with)


--mtx
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Martin Thomson]

On Fri, Sep 8, 2017 at 5:32 AM, Tom Ritter  wrote:
> On Thu, Sep 7, 2017 at 1:09 PM, Shubhie Panicker via dev-platform
>  wrote:
>> Curious - are there concerns with implementing Client Hints in general?
>
> Yes. But the fingerprinting team (specifically, I'm not sure what
> other teams have done) haven't investigated Client Hints yet to see
> what we may wish to obscure. =)

I reviewed some changes to the spec, and am of the opinion that there
are problems with Client Hints in this area:  see
https://github.com/httpwg/http-extensions/pull/373#pullrequestreview-54009185

That's not a proper review of the sort that Tom is talking about, but
the issues are suggestive of problems.  As with here, the biggest
concern I have is over the amount of control a UA has when it comes to
how this is used.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Daniel Veditz]

On Thu, Sep 7, 2017 at 11:28 AM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> Optimally, the browser should tell nothing about the client - web
> content should written in a way that it works independent from the
> actual client. At least that's how the web originally was designed.
>

​Without some kind of signal everyone gets the least-common-denominator
version of a site (and even then older equipment or phones may result in a
poor experience) or sites will try to guess based on user-agent. Privacy
minded folks can spoof their user agent, sure, but nothing says we can't
create ways to spoof the client-hint responses (allow them to be turned
off).

For images and things maybe CSS could specify some media queries that loads
different resources based on local factors like amount of memory or network
speed, but then that's leaking the same information just in a different way.

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Fabrice Desre]

On 09/07/2017 11:09 AM, Shubhie Panicker via dev-platform wrote:

Thanks for the comments.

<< The low end is extremely small buckets, and the high end isn't even
fleshed out but I'm certain that's becomes small buckets too >16GB too.
<< (Obviously this doesn't take into account mobile, and I couldn't find
any reports on distribution of android devices by RAM.)
Mobile and Android devices are key use-cases here and low end bucket is
expected to grow significantly, especially due to efforts like Android Go



For very low memory devices, the total memory is not the best signal 
unfortunately. I'm not gonna give precise numbers or names for obvious 
reaons (Shubbie, you can get them from your colleagues) but for instance 
the memory used by modems varies greatly from one SoC vendor to the 
other. The variation may not me so significant to user space when your 
total memory is a few GB, but it really is on devices like those 
targeted by Android Go.
So you will report something that doesn't help a JS lib to build an 
opinionated signal - you should rather report the available memory 
available to web sites, which is a wonderful fingerprinting signal...


Fabrice
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Tom Ritter]

On Thu, Sep 7, 2017 at 1:09 PM, Shubhie Panicker via dev-platform
 wrote:
> Curious - are there concerns with implementing Client Hints in general?

Yes. But the fingerprinting team (specifically, I'm not sure what
other teams have done) haven't investigated Client Hints yet to see
what we may wish to obscure. =)

-tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Shubhie Panicker via dev-platform]

Thanks for the comments.

<< The low end is extremely small buckets, and the high end isn't even
fleshed out but I'm certain that's becomes small buckets too >16GB too.
<< (Obviously this doesn't take into account mobile, and I couldn't find
any reports on distribution of android devices by RAM.)
Mobile and Android devices are key use-cases here and low end bucket is
expected to grow significantly, especially due to efforts like Android Go

.

<< Is there any reason it can't just report that: 'Low Memory' or 'Not Low
Memory'.
In an ideal world we would surface Device Class as "low, medium, high"
etc. However
the browser is not in the best position to make an accurate call that works
for everyone and is future proof, see this section

for why we don't want to provide an opinionated signal and instead choose
to provide a low-level un-opinionated signal.
JS libraries or frameworks will build opinionated signal on top of this, we
don't think the web platform is the right place for this.
That said, the tradeoff is that is that total memory is a fingerprinting
vector.

<< Of course if we implemented client hints we could simply send less
information, like 0.5, 1, and 2. Maybe 4 if some sites really would send
resources large enough to where that is an issue. And I guess Firefox for
Android claims to be able to run on a 384Mb device so maybe 0.25 is a
useful value as well.
We could consider updating to closest, single most significant bit, to
reduce the buckets.
Of course FF could surface a subset (or overlapping set), but being able to
standardize on a common set would be great.

Curious - are there concerns with implementing Client Hints in general?


On Wed, Sep 6, 2017 at 12:58 PM, Andrew Overholt 
wrote:

> On Wed, Sep 6, 2017 at 2:53 PM, Daniel Veditz  wrote:
>
>> I do not know what are plans are about Client Hints in general, whether we
>> intend to or when, and obviously that's a prerequisite.
>>
>
> Client Hints is https://bugzilla.mozilla.org/show_bug.cgi?id=935216, FWIW.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Enrico Weigelt, metux IT consult]

On 05.09.2017 19:13, Shubhie Panicker via dev-platform wrote:

Hi,

Boris expressed privacy concern with the API and suggested starting a > thread here to get some concrete feedback. We would love to get this> 
feedback and are open to updating the header and API as it would be 
great> to get FF behind this API.

I fully agree. There're already too many similar security problems.
(maybe it's different between countries/cultures, but over here in
Germany we *do* care about privacy.)

Optimally, the browser should tell nothing about the client - web
content should written in a way that it works independent from the
actual client. At least that's how the web originally was designed.

I'd also question the practical usecase. For example, video hosters
already have settings for video quality - which, btw has only small
relation to available memory (bottlenecks are bandwidth and cpu or
vpu power). Adding such an Header/API here just risks web coders
taking even more silly assumptions and adding even more bad code.

Also serving a "light version" of sites like Facebook or Google
Analytics (like mentioned in the google maillist) doesn't seem to be an
good use case to me, too:

#1: Facebook delivers really, really bad code. No idea how they do it,
but typing something sometimes takes several seconds per char. Scrolling
sometimes takes minutes, etc, etc (w/ multiple tabs that even goes up
exponentially) - in Chrome as well as FB. It's just beyond repair.

In contrast, VK just flashes. Quick and simple (like Google once was)
Ergo: when VK provides quite the same functionality w/o any performance
problems (and actually, that isn't such a big deal at all), then FB
is just doing it terribly wrong. I really wonder why such a big company
doesn't get their tech in order.

Well, if FB would honor such an header and serve a really light version
(I have my doubts), then I'd vote for hard-coding 128MB

#2: Google Analytics shouldn't be supported at all - they already far
too invasive (if it wouldn't open pandorra's box, I'd even vote for a
law for blocking them on ISP core routers) - I've blocked them on
my routers.

OTOH, I do see a valid case for *users* (not the computer on its own)
deciding on certain content preferences - on a per-site basis.

But that wouldn't be memory (*ideally*, normal user processes shouldn't
even care how much memory is in a box - let the kernel handle that),
instead things like max. video resolution, sound quality (I'm personally
fine w/ mono, as I only have one operating ear ;-)), etc. Such a setting
should be easily switchable any time (eg. I'm often listening to radio
shows @yt and switch to lowest resolution to save cpu cycles).

BTW: video playback can be much more efficient when using VPUs
(hw-codecs) - especially for embedded/mobile devices. But the 
hw-configuration, and therefore optimal pipeline is pretty device

specific, so it has to be configurable. The best option IMHO would
be using gst and let the user/operator specify the actual pipeline.


--mtx

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Martin Thomson]

Why do the numbers need to be standardized?  Could we give browsers
the ability to change the value in response to their understanding of
the current situation.

Surely an Android device is easily identifiable as such, so we could
choose values that reflect our Android population at the current
moment and we could choose numbers so that no bucket is too small.  We
could say that the number is decimal, that it needs to be at least the
identified value, and have a  wrote:
> On 2017-09-06 11:48 AM, Tom Ritter wrote:
>>
>> Steam's hardware survey shows the following distribution percentages.
>>
>> Less than 512 MB 0.00%
>> 512 Mb to 999 MB 0.03%
>> 1 GB 0.52%
>> 2 GB 3.30%
>> 3 GB  6.27%
>> 4 GB  14.96%
>> 5 GB  0.66%
>> 6 GB  3.23%
>> 7 GB  2.33%
>> 8 GB  42.77%
>> 9 GB  0.04%
>> 10 GB  0.29%
>> 11 GB  0.18%
>> 12 GB and higher  25.39%
>
>
> The memory distribution of Firefox desktop users is shared on the Firefox
> Hardware Report dashboard. Unsurprisingly, Firefox users have less memory
> than Steam users.
>
> https://hardware.metrics.mozilla.com/#goto-cpu-and-memory
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Andrew Overholt]

On Wed, Sep 6, 2017 at 2:53 PM, Daniel Veditz  wrote:

> I do not know what are plans are about Client Hints in general, whether we
> intend to or when, and obviously that's a prerequisite.
>

Client Hints is https://bugzilla.mozilla.org/show_bug.cgi?id=935216, FWIW.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Chris Peterson]

On 2017-09-06 11:48 AM, Tom Ritter wrote:

Steam's hardware survey shows the following distribution percentages.

Less than 512 MB 0.00%
512 Mb to 999 MB 0.03%
1 GB 0.52%
2 GB 3.30%
3 GB  6.27%
4 GB  14.96%
5 GB  0.66%
6 GB  3.23%
7 GB  2.33%
8 GB  42.77%
9 GB  0.04%
10 GB  0.29%
11 GB  0.18%
12 GB and higher  25.39%


The memory distribution of Firefox desktop users is shared on the 
Firefox Hardware Report dashboard. Unsurprisingly, Firefox users have 
less memory than Steam users.


https://hardware.metrics.mozilla.com/#goto-cpu-and-memory
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Daniel Veditz]

On Tue, Sep 5, 2017 at 10:13 AM, Shubhie Panicker via dev-platform <
dev-platform@lists.mozilla.org> wrote:

> Boris expressed privacy concern with the API and suggested starting a
> thread here to get some concrete feedback.


​It's great that you agreed to send this (and other client hints?) only
for​ secure connections.

I share Boris's concern that the buckets are too fine-grained. Are those
fine distinctions likely to matter to content producers compared to the
additional fingerprintability?  Of course if we implemented client hints we
could simply send less information, like 0.5, 1, and 2. Maybe 4 if some
sites really would send resources large enough to where that is an issue.
And I guess Firefox for Android claims to be able to run on a 384Mb device
so maybe 0.25 is a useful value as well.

Sending the info to 3rd party resources increases tracking risk, though I
suppose if we didn't sites could still pass the info along through URL
parameters.

I do not know what are plans are about Client Hints in general, whether we
intend to or when, and obviously that's a prerequisite.

-
​Dan Veditz​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Tom Ritter]

This is pretty concerning to me from a fingerprinting POV. The spec
currently rounds up to one of the following values:

0.25, 0.5, 0.75, 1, 1.5, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128

Steam's hardware survey shows the following distribution percentages.

Less than 512 MB 0.00%
512 Mb to 999 MB 0.03%
1 GB 0.52%
2 GB 3.30%
3 GB  6.27%
4 GB  14.96%
5 GB  0.66%
6 GB  3.23%
7 GB  2.33%
8 GB  42.77%
9 GB  0.04%
10 GB  0.29%
11 GB  0.18%
12 GB and higher  25.39%

The low end is extremely small buckets, and the high end isn't even
fleshed out but I'm certain that's becomes small buckets too >16GB
too. (Obviously this doesn't take into account mobile, and I couldn't
find any reports on distribution of android devices by RAM.)

I'm not thrilled about including this at all, but if we did I would
strongly recommend significantly reducing the number of buckets
reported. Ideally to 2.

I haven't seen anything in this that indicates people want to use such
nuanced data; they just want to know whether to serve the 'light' or
the 'normal' mode. This is reminiscent of NetworkInformaiton API where
it was designed to expose a ton of information but really people just
wanted to know "Will this cost the user money or not".

Is there any reason it can't just report that: 'Low Memory' or 'Not Low Memory'.

-tom

On Tue, Sep 5, 2017 at 12:13 PM, Shubhie Panicker via dev-platform
 wrote:
> Hi,
> I work on Chrome Web Platform and we just shipped an API for detecting
> Device Memory:
> header
> 
> and JS API
> 
> .
> Boris expressed privacy concern with the API and suggested starting a
> thread here to get some concrete feedback. We would love to get this
> feedback and are open to updating the header and API as it would be great
> to get FF behind this API.
> (It's not too late to update this, larger adoption is gated on
> Accept-CH-Lifetime
> header
> 
> which would enable sending the CH header on the first request)
>
> Sincerely,
> Shubhie
>
> PS: As an aside, we discussed the API in the Web Perf WG but unfortunately
> Mozilla is not currently participating in the WG and we'd love to address
> that going forward.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Device Memory header and JS API

[Shubhie Panicker via dev-platform]

Hi,
I work on Chrome Web Platform and we just shipped an API for detecting
Device Memory:
header

and JS API

.
Boris expressed privacy concern with the API and suggested starting a
thread here to get some concrete feedback. We would love to get this
feedback and are open to updating the header and API as it would be great
to get FF behind this API.
(It's not too late to update this, larger adoption is gated on
Accept-CH-Lifetime
header

which would enable sending the CH header on the first request)

Sincerely,
Shubhie

PS: As an aside, we discussed the API in the Web Perf WG but unfortunately
Mozilla is not currently participating in the WG and we'd love to address
that going forward.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform