Live data from Hacker News

Bypassing Browser Security Warnings with Pseudo Password Fields

troyhunt.com

31–40 of 127 posts

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#31

"I’ve been speaking with the owner about SSL before I invest in becoming a member, but she’s been told by the dev of the platform (it’s a franchise system called ShopCity.com) that SSL is more about Google’s monopolizing visibility of content, and less to do with security" This is an interesting observation of how Google's technical crusades often align with its profit interests. The main threat that HTTPS everywhere…

Perhaps, but it's fairly easy to un-Google your life nowadays.

Except, it shouldn't take work!.. Like - with cell phones.

Until recently, I had no idea that manufacturers actually PAY Google to have the services on Android... Talk about idiocy.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#32
post #21
post #18

Earlier quoted context omitted.

What's easier for a dev: inserting a few lines of code, or getting access to the production server, setting up letsencrypt (or getting a budget approval for the $10/year certificate)?

Code is rarely the same as "inserting a few lines of code" though. They presumably had to think about how to work around the problem, look for an appropriate font, etc. All for the purpose of hiding a symptom of an underlying problem.

Yes, exactly - there's a framework in place, which allows for the bullchit. :/

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#33
This hack is exactly what I needed 2 days ago while working on a browser-based terminal app. My site will be secured with SSL/TLS, but I needed a way to make a content-editable span mask input like a password field. I already implemented it with a password input, but it doesn't wrap inline like a span does. It will be much cleaner to just add a class that masks the font.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#34
post #15

Earlier quoted context omitted.

It's because you don't do bulk calls. Sells, support, orders, etc. They all need office phones at a certain scale. Not that they couldn't do it with mobiles. But infrastructures for those kind of systems all assume a land line.

Decent deskphones are significantly more comfortable than cellphones, nevermind the better audio hardware.

You could make special apps with a UI made to help with the specific tasks, and with a good bluetooth headset make a nice mobile experience IMO. But yeah currently solid IRL keypads + phone handles are better than mobiles'.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#35
post #10
post #9

Earlier quoted context omitted.

All landline phone connections sold by Telekom in germany are VOIP, it's just mostly hidden from the subscriber. The technology is doing perfectly fine.

VOIP and specifically SIP in its least secure form became the replacement for old tandem circuits. Sadly, rather than pushing SIP hardware out to the endpoints, most lamdline carriers chose to just provide twisted pair service. VoLTE is as close as most consumers will get to proper VOIP service.

Giving everyone SIP phones is expensive, and forcing your subscribers to purchase SIP phones will ensure a number of them flee to the competition. Putting the VOIP hardware in the modem makes much more sense, because you have to provide that to your subscribers anyway.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#37

"I’ve been speaking with the owner about SSL before I invest in becoming a member, but she’s been told by the dev of the platform (it’s a franchise system called ShopCity.com) that SSL is more about Google’s monopolizing visibility of content, and less to do with security" This is an interesting observation of how Google's technical crusades often align with its profit interests. The main threat that HTTPS everywhere…

I don't want my ISP to inject JavaScript to random pages or analyze my traffic. That should be downright illegal. They should be like water supply company: provide me damn clean water and get out of my way.

Somehow the sewage company doesn't analyze my urine (I hope) to figure out if I prefer spicy or sour food and get an extra buck from third parties, and somehow they're still in the business.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#38

If only we had these kinds of strong warnings in the VOIP industry. Nearly every provider barebacks the internet, throwing unencrypted signaling data (phone number dialed, keys pressed during the call, codec to use) and call media over the internet raw, just hoping that no one eavesdrops or alters their data. HIPPA compliance? Nah bruh, unencrypted UDP is just fine! PCI-DSS says we can't take credit cards over this w…

[deleted]

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#39
post #29

LOL, I love the guys filing that bug report with Mozilla... Had to have cost some overtime for their network admins. xD The way I see it, this - along with most of things - when you place the mechanisms there, people will use them and abuse them. 20 years ago, a browser had 3 MB and today they're 30 and 60 MB large, with much better compression of the installer. Why do we need this-and-that service integration within…

>Someone wants to watch a video: install a codec. [...] Introducing 1000&1 vulnerabilities, where there should be none

I'd rather use a codec maintained and updated by Mozilla every 6 weeks than some "community maintained" codec that I installed years ago and has to be manually updated.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#40
post #24

Earlier quoted context omitted.

"the HTTPS and IPv6 anti-vaxxer crowd " What does this mean?

Pretty sure that means people who refuse to deploy TLS & IPv6, even when their hardware & software stack fully supports it.

That makes more sense than trying to force a completely unrelated opinion into a conversation.

Also, the notion that broad use of IPv6 = security in VOIP, IoT or any area is a postulation at best.

I've personally always found this to be a good overview of security issues involved in both protocols in VOIP:

http://ieeexplore.ieee.org/abstract/document/6714161/

(Sci-Hub approved)

There are certain parts of the industry hesitant to transition for the possibility of security mis-configurations and human errors, the picture that the VOIP industry as a whole holds no interest in security is false. It could definitely improve, but that doesn't just apply to VOIP.

Post reply on HN