<div dir="ltr">Hi Brady,<div><br></div><div>The battery status API has been used by EFL port so far. As far as I know the feature was added to support</div><div>web application. But I&#39;m not sure how many web applications have used it so far.(Personally I guess it might be</div><div>used by few applications.) Besides ¬†unfortunately nobody maintains it now. If there is concern to keep the feature</div><div>and other ports don&#39;t want to use it anymore, It looks I can&#39;t object to remove it.</div><div><br></div><div>Gyuyoung.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 9:54 AM, Simon Fraser <span dir="ltr">&lt;<a href="mailto:simon.fraser@apple.com" target="_blank">simon.fraser@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I support the proposal to remove.<br>
<br>
Simon<br>
<span class=""><br>
&gt; On Oct 30, 2016, at 5:14 PM, Brady Eidson &lt;<a href="mailto:beidson@apple.com">beidson@apple.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; There&#39;s code in the tree to support the W3C Battery Status API.<br>
&gt;<br>
</span>&gt; A recent study showed the extent of the risk (discussion and link to study <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.lukaszolejnik.com_battery-2Dstatus-2Dreadout-2Das-2Da-2Dprivacy-2Drisk_&amp;d=CwICAg&amp;c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&amp;r=gEUmSR3VtC-5Q3Im6T2Js1aXwjJK4RExonGEvDq2twI&amp;m=ZKSbJXtXvUd44zKls9LfZwY1fsH0NRSg8KxOY7clZdI&amp;s=8c9qMq7SAf9mAh8t9oHbJE45_tXRsbZBMid46hd9UXs&amp;e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__blog.<wbr>lukaszolejnik.com_battery-<wbr>2Dstatus-2Dreadout-2Das-2Da-<wbr>2Dprivacy-2Drisk_&amp;d=CwICAg&amp;c=<wbr>Hw-EJUFt2_<wbr>D9PK5csBJ29kRV40HqSDXWTLPyZ6W8<wbr>u84&amp;r=gEUmSR3VtC-<wbr>5Q3Im6T2Js1aXwjJK4RExonGEvDq2t<wbr>wI&amp;m=<wbr>ZKSbJXtXvUd44zKls9LfZwY1fsH0NR<wbr>Sg8KxOY7clZdI&amp;s=<wbr>8c9qMq7SAf9mAh8t9oHbJE45_<wbr>tXRsbZBMid46hd9UXs&amp;e=</a> ) which led to Mozilla first making the API less precise (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1124127" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1124127</a>) but then eventually removing it altogether (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1313580" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1313580</a>)<br>
<div class="HOEnZb"><div class="h5">&gt;<br>
&gt; Apple has never enabled this on their ports, one reason being concern for abuse in fingerprinting/tracking.<br>
&gt; The study seems to be a strong second opinion backing this concern.<br>
&gt; Mozilla&#39;s actions demonstrate another vendor not seeing the API being useful enough to outweigh the user concern.<br>
&gt;<br>
&gt; As one of the voices for Apple&#39;s ports I think the above episode further cements our concern in ever enabling the API.<br>
&gt;<br>
&gt; As one of the voices for WebKit as a whole I think above episode suggests we should just remove the code from the tree altogether.<br>
&gt;<br>
&gt; What to other Apple folks think? What do port maintainers who enable the API think?<br>
&gt;<br>
&gt; Thanks,<br>
&gt; ~Brady<br>
<br>
______________________________<wbr>_________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-dev</a><br>
</div></div></blockquote></div><br></div>