Testing Powerful Features on Insecure Origins

[Joel Weinberger]

Hi security-dev folks. We've been moving towards preferring secure origins for powerful new features as well as deprecating old powerful features on insecure origins. Of course, this provides some barrier for testing for developers, since it requires setting up a server with a cert for testing, which can be difficult.

Thus, we created the --unsafely-treat-insecure-origin-as-secure flag for developer testing (see Testing a Deprecated Powerful Feature for more info on using this flag). Additionally, it's always possible to create a self-signed cert and to click through the warning for purposes of testing.

However, there are two issues with these approaches. The flag is not really usable on ChromeOS or Android, as using command line flags on those platforms requires rooted/dev devices, and that's a pretty high bar. The click-through solution still works, but we really don't like suggesting clicking through any interstitial as a supported solution.

Thus, we'd like to try to find a more general solution, and we'd love to get suggestions. One idea that we like is basically to provide a checkbox in Dev Tools to allow a developer to specify that this origin should be treated as secure temporarily. This would allow you to test on all platforms, albeit on Android you'd need to connect via ADB to get DevTools, but it seems that any non-trivial development on Android requires this anyway.

What are the community's thoughts? Do you have suggestions? Please don't suggest getting rid of the secure context requirement because, well, that's on the table :-)

--Joel

[Joel Weinberger]

Whoops, and of course, I meant that getting rid of the secure context requirement is *NOT* on the table. So much for double checking my emails :-/

--Joel

[Ryan Sleevi]

On Thu, Jul 28, 2016 at 10:06 AM, Joel Weinberger <j...@chromium.org> wrote:

Thus, we'd like to try to find a more general solution, and we'd love to get suggestions. One idea that we like is basically to provide a checkbox in Dev Tools to allow a developer to specify that this origin should be treated as secure temporarily. This would allow you to test on all platforms, albeit on Android you'd need to connect via ADB to get DevTools, but it seems that any non-trivial development on Android requires this anyway.

That seems non-ideal, since one of the conditions of the flags is that you specify a profile-dir to avoid things like cache polution/MITM.

What are the community's thoughts? Do you have suggestions? Please don't suggest getting rid of the secure context requirement because, well, that's on the table :-)

Have you considered a 'Developer Profile' mode, similar to Incognito Profile & normal user Profiles?

A 'Developer Profile' mode could initialize 'as if' it was a new profile dir (that is, away from the user's profile), clearly indicate it was developer mode (and thus greater security risk, perhaps as a non-dismissible security warning that appears as part of/below the omnibox/chrome), but then allow things like DevTools-specified origins to be treated as secure.

Since part of the challenge is balancing the needs of users (who we want to keep protected) and developers (who we want to allow the flexibility to do their jobs), perhaps there's other steps that could be taken or features not exposed, to make sure that end users aren't "tricked" into always running in developer mode.

For example, you wouldn't want non-developers to be coerced into 'developer mode' because a site simply wants to avoid secure origin warnings.

WDYT?

[David Benjamin]

As possibly less involved variant of that (adding a 'Developer Profile' mode would take quite a lot of UI), we could burn either URL scheme or a TLD (I believe .test is reserved?). And in DevTools, one could configure mappings like:

https://site1.my-test-site.com.test -> localhost:1234

https://site2.my-test-site.com.test -> localhost:5678

We would speak to those ports over localhost + HTTP (not HTTPS), so no need to mess with certificates and such, but we'd act as if they were secure origins. Being in a separate TLD keeps the state from colliding with real origins, and one needs to go to DevTools to configure this at all. It also means you can test your site in setups that are closer to reality than http://localhost:1234. Maybe you have some wonky JS somewhere that explodes if window.location reports HTTPS.

[Joel Weinberger]

On Thu, Jul 28, 2016 at 11:18 AM David Benjamin <davi...@chromium.org> wrote:

As possibly less involved variant of that (adding a 'Developer Profile' mode would take quite a lot of UI), we could burn either URL scheme or a TLD (I believe .test is reserved?). And in DevTools, one could configure mappings like:

https://site1.my-test-site.com.test -> localhost:1234

https://site2.my-test-site.com.test -> localhost:5678

We would speak to those ports over localhost + HTTP (not HTTPS), so no need to mess with certificates and such, but we'd act as if they were secure origins. Being in a separate TLD keeps the state from colliding with real origins, and one needs to go to DevTools to configure this at all. It also means you can test your site in setups that are closer to reality than http://localhost:1234. Maybe you have some wonky JS somewhere that explodes if window.location reports HTTPS.

That sounds interesting, although for reasons I don't fully comprehend, I think devs often want to run tests on their real domains, albeit over HTTP. Frankly, I don't understand the reasoning, so maybe we don't care.

On Thu, Jul 28, 2016 at 2:09 PM Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Jul 28, 2016 at 10:06 AM, Joel Weinberger <j...@chromium.org> wrote:

Thus, we'd like to try to find a more general solution, and we'd love to get suggestions. One idea that we like is basically to provide a checkbox in Dev Tools to allow a developer to specify that this origin should be treated as secure temporarily. This would allow you to test on all platforms, albeit on Android you'd need to connect via ADB to get DevTools, but it seems that any non-trivial development on Android requires this anyway.

That seems non-ideal, since one of the conditions of the flags is that you specify a profile-dir to avoid things like cache polution/MITM.

Agreed. My proposal would definitely risk pollution issues. Maybe when you check that box we do a full clear of origin browsing data and history? 

What are the community's thoughts? Do you have suggestions? Please don't suggest getting rid of the secure context requirement because, well, that's on the table :-)

Have you considered a 'Developer Profile' mode, similar to Incognito Profile & normal user Profiles?

A 'Developer Profile' mode could initialize 'as if' it was a new profile dir (that is, away from the user's profile), clearly indicate it was developer mode (and thus greater security risk, perhaps as a non-dismissible security warning that appears as part of/below the omnibox/chrome), but then allow things like DevTools-specified origins to be treated as secure.

Cool idea! As David mentioned, it would probably be a very big UX change. What about only allowing the Dev Tools option in Incognito mode? I don't know if we have any precedence for that, but it seems doable (and much simpler). 

[Sergey Shekyan]

Thus, we created the --unsafely-treat-insecure-origin-as-secure flag for developer testing (see Testing a Deprecated Powerful Feature for more info on using this flag). 

While using all these dangerous flags, I caught myself running the browser with some security features disabled for days without realizing it.

How sane is it to propose to time limit such flags if running with default profile? Say, forcefully disable it after X hours? 

[Ryan Sleevi]

On Thu, Jul 28, 2016 at 3:47 PM, Joel Weinberger <j...@chromium.org> wrote:

That seems non-ideal, since one of the conditions of the flags is that you specify a profile-dir to avoid things like cache polution/MITM.

Agreed. My proposal would definitely risk pollution issues. Maybe when you check that box we do a full clear of origin browsing data and history? 

Seems like a way to anger a lot of developers who accidentally do it. We'd also have to consider the integration of features like Sync or Autofill - should those entries be available in this mode? (My understanding, perhaps incorrectly, is that --user-data-dir avoids all of those concerns)

 

Have you considered a 'Developer Profile' mode, similar to Incognito Profile & normal user Profiles?

A 'Developer Profile' mode could initialize 'as if' it was a new profile dir (that is, away from the user's profile), clearly indicate it was developer mode (and thus greater security risk, perhaps as a non-dismissible security warning that appears as part of/below the omnibox/chrome), but then allow things like DevTools-specified origins to be treated as secure.

Cool idea! As David mentioned, it would probably be a very big UX change. What about only allowing the Dev Tools option in Incognito mode? I don't know if we have any precedence for that, but it seems doable (and much simpler). 

The concern with Incognito is that it'd still be different/distinct enough from normal browsing that it may or may not meet the right use cases. For example, the aforementioned Autofill (is requestAutoComplete still a thing? Maybe not?) or testing things like Service Worker (which may assume a backing disk cache to test over repeated visits, but Incognito would lack that)

I fully admit to not having fully though the idea through. My suggestion was specifically trying to reduce "big UX changes" by having the Dev profile go through all the normal profile initialization code (e.g. not Incognito), but then trigger a toast (like we already do for dangerous command-line flags). I didn't think it'd be a very big UX change, so I'm sure there's a piece I'm missing. 

[Joel Weinberger]

To Sergey's time-limited flag proposal, there's no reason we couldn't do that, although expressing what's happening in the UI seems difficult me. However, for this particular flag, your explanation is exactly why we require that you run it explicitly with a separate profile (so you don't get everything mixed up with your insecure mode). I suspect it would be more likely that we'd just start making this profile requirement for these crazy flags.

On Thu, Jul 28, 2016 at 3:58 PM Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Jul 28, 2016 at 3:47 PM, Joel Weinberger <j...@chromium.org> wrote:

That seems non-ideal, since one of the conditions of the flags is that you specify a profile-dir to avoid things like cache polution/MITM.

Agreed. My proposal would definitely risk pollution issues. Maybe when you check that box we do a full clear of origin browsing data and history? 

Seems like a way to anger a lot of developers who accidentally do it. We'd also have to consider the integration of features like Sync or Autofill - should those entries be available in this mode? (My understanding, perhaps incorrectly, is that --user-data-dir avoids all of those concerns)

Fair point. Personally, I don't think I'm as tied to the unique profile as you are. Dev Mode has plenty of foot guns as it is, so it doesn't seem crazy to me to put this in there.

 

Have you considered a 'Developer Profile' mode, similar to Incognito Profile & normal user Profiles?

A 'Developer Profile' mode could initialize 'as if' it was a new profile dir (that is, away from the user's profile), clearly indicate it was developer mode (and thus greater security risk, perhaps as a non-dismissible security warning that appears as part of/below the omnibox/chrome), but then allow things like DevTools-specified origins to be treated as secure.

Cool idea! As David mentioned, it would probably be a very big UX change. What about only allowing the Dev Tools option in Incognito mode? I don't know if we have any precedence for that, but it seems doable (and much simpler). 

The concern with Incognito is that it'd still be different/distinct enough from normal browsing that it may or may not meet the right use cases. For example, the aforementioned Autofill (is requestAutoComplete still a thing? Maybe not?) or testing things like Service Worker (which may assume a backing disk cache to test over repeated visits, but Incognito would lack that)

I fully admit to not having fully though the idea through. My suggestion was specifically trying to reduce "big UX changes" by having the Dev profile go through all the normal profile initialization code (e.g. not Incognito), but then trigger a toast (like we already do for dangerous command-line flags). I didn't think it'd be a very big UX change, so I'm sure there's a piece I'm missing. 

I think it would definitely require some UX changes so we represent the mode you're in, but it's also just creating new profile types is a very heavy weight change. I know that when we've made similar proposals for new profile types in the past, they've been shot down for that reason. I suspect that this flag alone would not be reason enough to have a new "Dev Mode Profile," but perhaps I'm wrong.

[Ryan Sleevi]

On Thu, Jul 28, 2016 at 4:09 PM, Joel Weinberger <j...@chromium.org> wrote:

Seems like a way to anger a lot of developers who accidentally do it. We'd also have to consider the integration of features like Sync or Autofill - should those entries be available in this mode? (My understanding, perhaps incorrectly, is that --user-data-dir avoids all of those concerns)

Fair point. Personally, I don't think I'm as tied to the unique profile as you are. Dev Mode has plenty of foot guns as it is, so it doesn't seem crazy to me to put this in there.

Mostly, I'm uneasy with the "clear all data" proposal, because it's much harder to enter that data on mobile.

If I wanted to test a single site on a device, it'd mean nuking all of my data and history. If we assume such developers have multiple Android/Chromebook devices (e.g. one for personal, one for development), this isn't so bad, but my gut tells me that the developers trying to test on Android are likely going to use their personal device they use for other things, and the idea of nuking all data in order to enable dev mode seems like... a very high price to pay. That's why I'm trying to find a solution that doesn't involve that sort of significant disruption.

On Desktop, modifying the --user-data-dir doesn't force me to lose any of my other data; I can always remove the --user-data-dir and get back to 'my' profile. That also seems to be the principles between Canary (aka SxS).

Just explaining the rationale, since it may not have been clear why I'm pretty uncomfortable with the idea of clearing data based on checking something in DevTools. I'm fairly certain it's clear that I feel strongly about the need to avoid corrupting 'user' state via 'insecure' mode though, so I'm not relitigating that :)

[Joel Weinberger]

On Thu, Jul 28, 2016 at 4:17 PM Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Jul 28, 2016 at 4:09 PM, Joel Weinberger <j...@chromium.org> wrote:

Seems like a way to anger a lot of developers who accidentally do it. We'd also have to consider the integration of features like Sync or Autofill - should those entries be available in this mode? (My understanding, perhaps incorrectly, is that --user-data-dir avoids all of those concerns)

Fair point. Personally, I don't think I'm as tied to the unique profile as you are. Dev Mode has plenty of foot guns as it is, so it doesn't seem crazy to me to put this in there.

Mostly, I'm uneasy with the "clear all data" proposal, because it's much harder to enter that data on mobile.

Ah, sorry, by "foot gun," I simply meant the possibility of corrupting user state via insecure mode. I agree that the "clear all data" proposal seems really scary; it was just an offhand suggestion.

If I wanted to test a single site on a device, it'd mean nuking all of my data and history. If we assume such developers have multiple Android/Chromebook devices (e.g. one for personal, one for development), this isn't so bad, but my gut tells me that the developers trying to test on Android are likely going to use their personal device they use for other things, and the idea of nuking all data in order to enable dev mode seems like... a very high price to pay. That's why I'm trying to find a solution that doesn't involve that sort of significant disruption.

On Desktop, modifying the --user-data-dir doesn't force me to lose any of my other data; I can always remove the --user-data-dir and get back to 'my' profile. That also seems to be the principles between Canary (aka SxS).

Just explaining the rationale, since it may not have been clear why I'm pretty uncomfortable with the idea of clearing data based on checking something in DevTools. I'm fairly certain it's clear that I feel strongly about the need to avoid corrupting 'user' state via 'insecure' mode though, so I'm not relitigating that :)

Maybe we can automagically pop you into a fresh profile if you click the 'insecure' option in Dev mode, but not necessarily create a new type of profile? I think the David and I were suggesting that a new profile type is part that will be hard to convince folks of. 

 

 

[Craig Francis]

On 28 Jul 2016, at 23:47, Joel Weinberger <j...@chromium.org> wrote:

... I think devs often want to run tests on their real domains, albeit over HTTP. Frankly, I don't understand the reasoning, so maybe we don't care.

I use domain names so mobile devices can easily connect to my dev machine (same with the Windows VM for IE/Edge), where all the config is done with a simple wildcard DNS entry, and a couple of Apache rewrite rules.

As I work on many websites (current machine has 80), where I'm not going to setup and remember IP addresses and port numbers for every one.

I also use the same naming convention to access the demo server, and other development machines:

http://project1.client1.dev1.domain.com

http://project2.client1.dev1.domain.com

http://project1.client1.dev2.domain.com

http://project1.client1.demo.domain.com

http://project2.client1.demo.domain.com

[Craig Francis]

Quick thoughts...

I agree flags are a pain, even getting them working on a Mac isn't ideal (usually starting by clicking on the icon in the Dock, or using QuickSilver/Spotlight).

I kind of like the idea of Ryan's Developer Profile, it keeps it simpler, but I know that when I'm developing/testing, I will almost certainly want to quickly look something up, and I'll simply open a new tab in the browser window I'm currently using.

Extending Incognito mode for dev isn't good, as I'd want these pages to stay in history, cookies to remain, etc.

The idea of using a tick box in Dev Tools, that makes it easier to developers to do (good), but the concern is that this might become too easy for non-developers.

Actually... why not make it a little bit more complicated (you need to type in every domain, in the settings somewhere, as a single list you can check), and when this is active, show a warning triangle in the address bar.

Something like the attached screenshot?

Craig

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[David Benjamin]

On Thu, Jul 28, 2016 at 6:48 PM Joel Weinberger <j...@chromium.org> wrote:

On Thu, Jul 28, 2016 at 11:18 AM David Benjamin <davi...@chromium.org> wrote:

As possibly less involved variant of that (adding a 'Developer Profile' mode would take quite a lot of UI), we could burn either URL scheme or a TLD (I believe .test is reserved?). And in DevTools, one could configure mappings like:

https://site1.my-test-site.com.test -> localhost:1234

https://site2.my-test-site.com.test -> localhost:5678

We would speak to those ports over localhost + HTTP (not HTTPS), so no need to mess with certificates and such, but we'd act as if they were secure origins. Being in a separate TLD keeps the state from colliding with real origins, and one needs to go to DevTools to configure this at all. It also means you can test your site in setups that are closer to reality than http://localhost:1234. Maybe you have some wonky JS somewhere that explodes if window.location reports HTTPS.

That sounds interesting, although for reasons I don't fully comprehend, I think devs often want to run tests on their real domains, albeit over HTTP. Frankly, I don't understand the reasoning, so maybe we don't care.

If we're to consider that a constraint (which, I agree, seems a nonsense constraint, but I do not know the reasoning), we should definitely figure out the reason first, to see what we could provide with alternate mechanisms. That is a very strong constraint and I think basically forces the separate profile to keep the statefulness from going crazy.

(I actually think having a separate profile would be by far the best option if feasible. But my recollection is the two platforms where --user-data-dir doesn't work, Android and CrOS, are also the two where multiprofile is wonky, so this might be involved. Or maybe I'm wrong and this is actually straightforward.)

My thinking with the mappings was that we could emulate as many of the behaviors of the true domain (I dunno, maybe we could even do awful things to the PSL... that sounds annoying, but at least it's a well-defined idea) as we could while still keeping a clear separation.

It's not perfect (maybe I have some code that is sensitive to whether the domain ends in .test), but it's a balance between having a separate profile but still having the required separation.

[Adrienne Porter Felt]

On Fri, Jul 29, 2016 at 5:12 AM, David Benjamin <davi...@chromium.org> wrote:

On Thu, Jul 28, 2016 at 6:48 PM Joel Weinberger <j...@chromium.org> wrote:

On Thu, Jul 28, 2016 at 11:18 AM David Benjamin <davi...@chromium.org> wrote:

As possibly less involved variant of that (adding a 'Developer Profile' mode would take quite a lot of UI), we could burn either URL scheme or a TLD (I believe .test is reserved?). And in DevTools, one could configure mappings like:

https://site1.my-test-site.com.test -> localhost:1234

https://site2.my-test-site.com.test -> localhost:5678

We would speak to those ports over localhost + HTTP (not HTTPS), so no need to mess with certificates and such, but we'd act as if they were secure origins. Being in a separate TLD keeps the state from colliding with real origins, and one needs to go to DevTools to configure this at all. It also means you can test your site in setups that are closer to reality than http://localhost:1234. Maybe you have some wonky JS somewhere that explodes if window.location reports HTTPS.

That sounds interesting, although for reasons I don't fully comprehend, I think devs often want to run tests on their real domains, albeit over HTTP. Frankly, I don't understand the reasoning, so maybe we don't care.

If we're to consider that a constraint (which, I agree, seems a nonsense constraint, but I do not know the reasoning), we should definitely figure out the reason first, to see what we could provide with alternate mechanisms. That is a very strong constraint and I think basically forces the separate profile to keep the statefulness from going crazy.

(I actually think having a separate profile would be by far the best option if feasible. But my recollection is the two platforms where --user-data-dir doesn't work, Android and CrOS, are also the two where multiprofile is wonky, so this might be involved. Or maybe I'm wrong and this is actually straightforward.)

Multiprofile in Android is quite hard. I personally don't think creating a new type of profile is a promising path forwards. It would require a large amount of engineering & UI support, not just to build but to keep it supported in the future.

[bunspa...@gmail.com]

Just ran into this problem on Android trying to get a location. Problem is, my development environment doesn't run a full webserver (it's a wsgi app which for testing runs a very basic http server) so I can't serve https with it.
Particularly for Android development this is bad news since "localhost" isn't an option for obvious reasons, nor is the parameter as that requires to root the device.

Here's a idea: how about a source that's remote debugged is considered secure? It's very easy on any desktop to run chrome/chromium and remote debug on a connected Android device. This constellation would allow to "run as secure" since it requires debugging mode and USB connection - if that's not secure you have a problem to begin with :-)

Just a thought

[Joel Weinberger]

I know very little about Android and remote debugging, but that doesn't sound like a bad idea. Any Android-y folks out there have thoughts on this?

[Ryan Sleevi]

Is there a reason "localhost" with adb || ssh port forwarding isn't an option? That's what our bots use.

[bunspa...@gmail.com]

Sure it's an option, butiIt requires configuration and adb. AFAIK regular Chrome/Chromium to Android Chrome debugging requires nothing but a USB driver (if on Windows) and in my case nothing at all - works right out of the box on Linux. Switch Phone to USB Debug mode, plug in and select "inspect devices" from chrome devtools on your desktop.
This would be a solution for someone building a website (not an app) who wants to use and test some of the secure features (i.e. geolocation) on an android device. Anyone testing a website on Android is probably using the remote debug anyways to see console messages.

[Torne (Richard Coles)]

On Fri, 14 Oct 2016 at 02:08 Joel Weinberger <j...@chromium.org> wrote:

I know very little about Android and remote debugging, but that doesn't sound like a bad idea. Any Android-y folks out there have thoughts on this?

Ignoring the restriction when remote debugging is taking place would make it extremely difficult to actually debug issues with real sites - if everything magically works while you have the debugger connected but stops working as soon as you disconnect, that's going to be really weird and surprising ;)

It'd have to be an option that you specifically enable in devtools, rather than something that happened automatically while debugging.

[Craig Francis]

On 14 Oct 2016, at 10:11, Torne (Richard Coles) <to...@chromium.org> wrote:

It'd have to be an option that you specifically enable in devtools, rather than something that happened automatically while debugging.

Could it show a warning in the console every time a "powerful feature" is being used on an insecure origin, while the debugger is enabled?

[PhistucK]

An option plus a warning while the option is enabled sounds like the safest way to go.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

[bunspa...@gmail.com]

You have a rather good point there. Right now you can't debug the features unless you set up a full secure webserver to test on and if you change the behavior to automatically allow secured features to run you can't debug the real life scenario.
One thing though: this is just the transport layer and has (hopefully) nothing to do with how a website is programmed. Anything that runs under http should run under https. It's just chrome where that isn't true anymore. Personally I don't see a lot of reason why you would debug a live website just to test how it behaves between transport protocols. The only thing worth debugging is you don't have https, don't know about this restriction and want to know why certain features of your website don't run on chrome.

[Torne (Richard Coles)]

Yes, that's exactly the case I'm concerned about: the site uses features that require https and the developer isn't aware of chrome's policy here so is trying to debug the site. If the feature magically starts working when they connect the debugger then that's going to make figuring out what's going on really difficult :)

This would have to be an optional behaviour. I'm not sure we'd want to add such an option, though; I can, unfortunately, imagine sites telling users to turn it on. :(

Developers generally should be working out how to set up actual HTTPS-enabled development environments - it's not that difficult now with Let's Encrypt and it makes development and testing much more like production.

[Craig Francis]

On 14 Oct 2016, at 15:14, Torne (Richard Coles) <to...@chromium.org> wrote:

... it's not that difficult now with Let's Encrypt and it makes development and testing much more like production.

While I agree that development should be done on HTTPS, it's not that simple for the average developer.

Remember that many develop on their local computers (behind a NAT, and often within a VM), and Let's Encrypt does not work with that setup.

The easiest (not necessarily the best) solution I've found is to create a self signed certificate, and add it as a trusted root CA.

Craig

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[bunspa...@gmail.com]

Thanks. That's just what I wanted to say. Large corporations shaping the internet to their liking (Google, Apple, MS etc. etc.) tend to forget that most developers don't have a large budget and generally develop on a fairly small setup.

PS: If websites ask to turn on debug features in your browser and you're stupid enough to do so you deserve what you get.
Not that it makes that much of a difference since the endpoints of the transport are generally compromised to begin with - i.e. running facebook via https on a verizon android device doesn't hinder Facebook or Verizon to gather and sell your information. Both have full access to the unencrypted data.

[Chris Palmer]

On Fri, Oct 14, 2016 at 8:06 AM, <bunspa...@gmail.com> wrote:

PS: If websites ask to turn on debug features in your browser and you're stupid enough to do so you deserve what you get.

Let's not blame victims or call people "stupid" when their only 'mistake' is to not know what a debugger is and what turning one on might entail. As it happens, some people do indeed get tricked by such social engineering (see e.g. https://www.facebook.com/notes/facebook-security/dont-be-a-self-xss-victim/10152054702905766/), and most people are (a) focused on completing their task and (b) trained (often, by us) to be helpless in the face of baffling cyber jibber-jabber. To make software safe for people, we need to have empathy for the people who use it.

In this case, though, I think it's unlikely that very many people would install adb and tether their phone to a desktop/laptop to get Geolocation to work.

[Torne (Richard Coles)]

I was assuming if we added this feature to devtools we would add it on desktop for local debugging as well as remote, which makes it more likely someone could be encouraged to do it ill-advisedly. If it was only for remote debugging I agree it's unlikely, but I don't see why it should be; the problem isn't really that different between desktop and mobile.