On 2016-10-24 6:29 PM, Adam Roach wrote: > I'm hearing general agreement that we think turning this off is the > right thing to do; that maintaining compatibility with Chrome's behavior > is important (since that's what existing code will presumably be tested > against); and -- as bz points out -- we don't want to throw an exception > here for spec compliance purposes. I propose that we move forward with a > plan to immediately deny permission in non-secure contexts. Kan-Ru's > proposal that we put this behind a pref seems like a good one -- that > way, if we discover that something unexpected happens in deployment, > it's a very simple fix to go back to our current behavior. > > I would be hesitant to over-analyze additional complications, such as > https-everywhere or user education on this topic. We are, after all, > simply coming into alignment with the rest of the web ecosystem here.
FWIW, and to the extent that my opinion matters on the topic, I strongly disagree that breaking the websites that people use silently is the right thing to do. Let's ignore the HTTPS Everywhere part of the thread, and instead pay more attention to what our users will see after we roll this out. It's easy to ignore this when looking at the ratio of granted non-secure geolocation prompts per all page loads, but we _are_ talking about breaking a fifth of geolocations on the web for our users. I think the user experience that Chrome has shipped sets an extremely low bar. While it's easy for us to match that bar, we can (and I argue we should) do better. PS. Please note that I'm disappearing later today going on vacation, which may mean I may not get to continue arguing this side. I'm secretly hoping someone else will. :-) > On 10/22/16 12:05, Ehsan Akhgari wrote: >> On 2016-10-22 10:16 AM, Boris Zbarsky wrote: >>> On 10/22/16 9:38 AM, Richard Barnes wrote: >>>> I'm not picky about how exactly we turn this off, as long as the >>>> functionality goes away. Chrome and Safari both immediately call the >>>> error >>>> handler with the same error as if the user had denied permission. We >>>> could >>>> do that too, it would just be a little more code. >>> Uh... What does the spec say to do? >> It seems like the geolocation spec just says the failure callback needs >> to be called when permission is defined, with the PERMISSION_DENIED >> code, but doesn't mention anything about non-secure contexts. The >> permissions spec explicitly says that geolocation *is* allowed in >> non-secure contexts <https://w3c.github.io/permissions/#geolocation>. >> The most relevant thing I can find is >> <https://w3c.github.io/webappsec-secure-contexts/#legacy-example>, which >> is an implementation consideration. But as far as I can tell, this is >> not spec'ed. >> >>> Your intent, and the whole "sites that would break are already broken" >>> thing sounded like we were going to match Chrome and Safari behavior; if >>> that was not the plan you really needed to explicitly say so! >> Yes, indeed. It seems that making Navigator.geolocation [SecureContext] >> is incompatible with their implementation. >> >>> We certainly should not be shipping anything that will change behavior >>> here to something _different_ from what Chrome and Safari are shipping, >>> assuming they are shipping compatible things. Again, what does the spec >>> say to do? >>> >>> -Boris >>> _______________________________________________ >>> 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 > > > -- > Adam Roach > Principal Engineer, Mozilla _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
