[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] psa: battery api: just use all battery
I bet a determined web designer could intuit the battery level through
other means. My Nexus 7's "battery saver" mode says that it "Reduces
device performance, limits vibration, location services and most
background data". Email, messaging and other apps that rely on syncing
may not update unless you open them."...I'd bet good money that if you
collected the right performance data from someone's phone over a dozen
visits to your website - you could figure out if it was in battery saver
For Uber, probably most users install their App anyway - and it'll carry
on being evil if that's the kind of company Uber wants to be.
What I think would be a better solution would be to have a menu item for
the entire phone to allow the user to choose: "Hide my battery status from
apps and web sites" - which would allow you to pretend that your battery
is fully charged when it's not so you could still get a cheaper Uber rate.
When sites become well-known for this evil practice - people could
prevent it from working as needed.
For the "evil tracking" use-cases, instead of returning a trackable exact
number - the battery API could simply have been a boolean: "Battery is
below the threshold for high activity applications"...with backwards
compatibility for the API to show either 100% or 0%. That would be
sufficient to allow "good natured" applications to throttle video rates
and such - but not enough to help out evil tracking applications.
There are all manner of other ways that this could have been handled short
of shutting it off.
The real concern here is the precedent this might set for future Web
API's. If "cannot be used for evil" becomes a critical requirement for a
new feature - we're probably doomed because so much of what makes the web
useful is also exploitable.
Maksims Mihejevs wrote:
> I can clearly see very good usages of Battery API, for example in web
> clients of social networks, and in native apps as well (although
> conversation here about web).
> Social network can filter content based on its nature of being heavy on
> battery, for example it can show less video content and minify video
> thumbnails to make it less likely clicked so to keep users preserving
> battery for longer.
> Same applies to many other content on the web, video autoplay - can be
> disabled if battery is below lets say 30%.
> In WebGL big usage would be to go down to 30fps from 60fps, to preserve
> battery by reducing pressure on GPU. And even more, changing DPI on page,
> that slices fill rate 4 times. That way users can engage with content for
> much longer and without too much harm. And Battery API allows a developer
> to do so.
> On many platforms going Fullscreen, games can show battery status, as
> header is hidden in fullscreen - this is good way to keep user aware of
> And there is many more use cases.
> I very agree with Florian on this.
> On 2 November 2016 at 11:09, Florian BÃ¶sch <email@example.com> wrote:
>> - https://news.slashdot.org/story/16/11/01/1833254/
>> - https://lists.w3.org/Archives/Public/public-device-apis/
>> - https://www.theguardian.com/technology/2016/nov/01/
>> - https://bugs.webkit.org/show_bug.cgi?id=164213
>> - https://blog.lukaszolejnik.com/browsers-remove-
>> The opponents of this functionality argue (among other things) that it's
>> used in a bad fashion by Uber (surge pricing more to users with low
>> battery) and should therefore be removed.
>> I believe this to be a spurious argument. Is Uber misbehaving? Yes. But
>> what does it actually say about the value of a battery API? What it says
>> that clearly users are intimately cognizant of their battery status, and
>> that they're willing to spend actual money to preserve it, indicating
>> they value their battery, and in the case of Uber, they value it so much
>> that they're sometimes statistically significantly more willing to pay a
>> This clearly demonstrates that the battery API has value to users, even
>> when Uber is misusing it.
>> This value will be vacuumed up when the API is removed. At present this
>> might seem small (it's true, it's rarely used so far), but there's no
>> telling if the future value would be so small. Would we know the value
>> losing a feature that takes a long while to adopt if it was revoked
>> after a
>> short period of time?
>> If say WebGL or CSS media queries or flexbox was removed after a short
>> period before anybody had a substantial grip on the technology on the
>> grounds that they're flawed features, what would the value be that was
>> lost? Well clearly we can argue with hindsight that it would be pretty
>> large now, because the hardware accelerated web and the responsive web
>> would barely exist. But could you make that assessment from your
>> before those points where proven?
>> A short while (mere months) after WebGL was introduced, Microsoft argued
>> that "WebGL is considered harmful" and made allegations of unsuitability
>> it for the web, and that they would never support it [source:
>> harmful/]. Should WebGL just have given up and be removed then?
>> Who can tell the exact value of a feature to be removed for the future
>> the Web if you don't give it appropriate time to be explored? Well
>> in this case, the opponents of this feature make that determination for
>> entire web. I admire the crystal ball they seem to possess that allows
>> to accurately predict the future value of a feature.
>> On Wed, Nov 2, 2016 at 11:07 AM, Cameron Yule <firstname.lastname@example.org>
>>> Florian, do you have a link to an announcement?
>>> I'd potentially be okay with losing the battery API if the browser had
>>> way to tell my application it's throttling resources for a reason.
>>> On Wednesday, 2 November 2016, Maksims Mihejevs <email@example.com>
>>>> Apple always needs to be different and just worse.
>>>> Tons of bugs and issues because of their GPU specifics and now they
>>>> removing API's..
>>>> On 2 November 2016 at 01:56, Florian BÃ¶sch <firstname.lastname@example.org> wrote:
>>>>> this just in. for the first time mobile (battery driven) browsing
>>>>> overtook power outlet driven browsing. so lets give those meddlesome
>>>>> mobiles a run for their battery life as the most emerging device
>>>>> category... because reasons.
>>>>> On Wednesday, 2 November 2016, Florian BÃ¶sch <email@example.com>
>>>>>> mozilla and apple are removing the battery api that would let
>>>>>> performance intensive apps, such as webgl ones, choose a less or
>>>>>> battery intensive mode of operation automatically. they reason
>>>>>> "os'es are
>>>>>> now good at that stuff."
>>>>>> so just crank your rendering code to max and kill that battery. who
>>>>>> needs battery life anyway. its no longer like you could tell you
>>>>>> killing the battery, so dont worry.
>>> +44(0)774 760 8776
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: