zlacker

While it's a much lesser offense, many APIs are only available in "Secure Contexts", so it's not entirely a new concept https://webidl.spec.whatwg.org/#SecureContext

>>wbobei+(OP)
Getting a secure context costs $0 and takes no effort in many common webservers at this point.

I do remember the controversy at the time of everybody shifting to HTTPS only, though, and how it might exclude small/hobbyist sites. Fortunately, we've found ways to mitigate that friction in the end. I'm much less optimistic here.

>>lxgr+u
The thing is, yes it was controversial at the time to enforce HTTPS, but on the other side I 'member pwning people with ARP spoof attacks (both to steal cookies and credentials as well as simply redirecting all images to porn) at my school already way over a decade ago, and all I had was a laptop, Wireshark, Metasploit and some other piece of open source software whose name I forgot. No ARP sponge and the internet uplink was 10/10 mbit anyway so it was easy to do that shit for the entire school. A year later someone packaged all that stuff into a single software even a complete dunderhead could use to prank and steal facebook sessions at will.

Basic reality and the easiness of attacks made it impossible to stick with HTTP for much longer. And hell if I watch Scammer Payback on Youtube, I'm beginning to think it might be a good idea to disable developer tools on browsers and to only unlock them if you can prove physical, un-remoteable access to a machine, similar to Apple's SIP.

>>mschus+oc
Whatever proof you require, scammers will still convince Grandma to enable it.

>>mschus+oc
> "I'm beginning to think it might be a good idea to disable developer tools on browsers and to only unlock them if you can prove..."

Strongest possible disagreement here.

>>chrisw+Fj
How so? I don't see how a secure attention sequence (i.e. what Windows used to do with requiring ctrl + alt + esc to be pressed to log in) could be a bad thing.

On the other hand, you can bet that that's absolutely something scammers will be able to convince people to do while they're on the phone with them...

>>lxgr+u
> Fortunately, we've found ways to mitigate that friction in the end.

Some of it, yes, but there are a nontrivial number of small/hobbyist sites that never overcame that friction.

>>lxgr+Sj
That, or a reboot with pressing F8 with a clear prompt "Enabling developer mode, do not do so if required by a phone support". Easy enough for actual developers and tinkerers, but disruptive for someone getting scammed.

> On the other hand, you can bet that that's absolutely something scammers will be able to convince people to do while they're on the phone with them...

Indeed but it will slow them down significantly and reduce the amount of marks by a significant amount as well.

>>lxgr+u
It's still annoying while coding on a local server.

>>wbobei+(OP)
The crucial difference between the two is that I get to decide which contexts I consider insecure. For convenience I may choose to let an agent decide on my behalf.

This is fundamentally different from a world where Google gets to decide if I am a risk to them.