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
