Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Encryption Google Privacy Chrome The Internet

Google Warns Webmasters About Insecure HTTP Web Forms (searchengineland.com) 94

In April Chrome began marking HTTP pages as "not secure" in its address bar if the pages had password or credit card fields. They're about to take the next step. An anonymous reader quotes SearchEngineLand: Last night, Google sent email notifications via Google Search Console to site owners that have forms on web pages over HTTP... Google said, "Beginning in October 2017, Chrome will show the 'Not secure' warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode."
Google warned in April that "Our plan to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the change in Chrome 56, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we're ready to take the next steps..."

"Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the 'Not secure' warning when users type data into HTTP sites."
This discussion has been archived. No new comments can be posted.

Google Warns Webmasters About Insecure HTTP Web Forms

Comments Filter:
  • by Anonymous Coward

    Let's separate authentication of websites from encryption for privacy. Then there's no reason not to encrypt everything.

  • by narcc ( 412956 ) on Saturday August 19, 2017 @06:14PM (#55049859) Journal

    Firefox added a warning a while ago. It's no surprise Google would follow suit.

    Chrome is really turning in to a slow, bloated, spyware-ridden Firefox clone.

  • by toonces33 ( 841696 ) on Saturday August 19, 2017 @06:37PM (#55049933)
    This seems like overkill to me.
    • This isn't requiring encryption, so I don't see what the problem is.
    • by rklrkl ( 554527 )

      I think the problem here is that while you can easily identify a password field in a form (type=password), it's not so easy to identify other form fields that might contain personal information (you don't have to call the e-mail field "email" for example). Google is probably right at blanket-covering http forms with a warning that that they aren't https.

      The warning in Incognito Mode is on a bit less of a justifiable footing though, but it's the next logical step to warning about all http sites regardless of

      • by tlhIngan ( 30335 )

        It's an annoying pain the butt.

        I mean, internal web applications don't need HTTPS, and yes, we can self-sign and force CA root to be distributed, but it's really just a pain in what is perfectly functioning software.

        The only way to hit them requires you to either be on the the local network, or VPN in.

        Firefox's warning is less than useful - the only way to disable it disables it for all sites, not just intranet ones. Chrome is probably going to be the same - disable it for all, or none, with no option to de

      • The real danger here is that people are going to be so used to seeing "not secure" in their browser and being told "oh just go ahead and use it, this isn't important" that soon enough they'll start typing their credit cards into insecure forms again.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      This seems like overkill to me.

      Are you unaware that some ISPs and "public" wireless hotspots tamper with packets in-transit in order to inject ads?

      I want zero percent of my packets to be tampered with in-transit. We prevent that with encryption.

    • Who decides if someone needs encryption or not? Do you know what all your visitors are being persecuted for? You're privileged enough to not need encryption for your specific data in your specific geo-political area. The same can not be applied universally.

    • This seems like overkill to me.

      I'd say it's insufficient. Everything should be encrypted and authenticated end to end, not just forms and form responses. Actually, it's really more important that data coming to your browser be authenticated than that data you send be encrypted. Why? Because unless your browser and OS are perfectly secure (they're not) then you have to trust every network hop between the server and you not to inject malware. With authentication, you only have to trust the server.

      And as long as you're authenticating all

  • My site has a contact page. I'm not going to spend the extra money to get a certificate just so Chrome won't kvetch about my site. I'll put verbage on the site explaining the error message in Chrome and if people don't want to contact me, I can live with that. Worst comes to worst, I can code the site to complain that Chrome isn't supported. I already do that with Internet Exploder.

    • Actually, it's free to set up HTTPS if you use letsencrypt.org. It takes roughly an hour of research to get it working, give or take depending on your current server setup. There are only a couple of gotchas: one, you have to make a certificate signing request file, .csr, which is easier on Linux than Windows. IIRC you can do it with Docker on a Windows machine. The second catch is, there are actually two files you have to put on your webserver, one is the private key, but the other is some "security key hi

    • by Anonymous Coward

      You can get a free certificate from letsencrypt [letsencrypt.org].

  • They flagged my public wiki as falling under the new policy. So someone who posts something on this wiki runs the risk of having their contribution changed by a man-in-the middle. (besides running the risk of someone just going to the wiki and changing their contribution the proper way).

  • I got this warning from Google about my site. A couple years ago, I got https working using Let's Encrypt. So, you'd think I could switch over 100% to https as Google is pushing me to do. But, what I've found is that there are a few odd browser/devices that don't work. A notable one is the PS3/4 web browser (my site is video-game related, so this is not entirely rare). Sony hasn't updated their root certs to include the one used by Let's Encrypt. So, my https does not work on a PS3 or PS4. Thus, I'd

  • A page which was served by unencrypted HTTP but which posts its form data to an https url is secure.

    It just doesn't look secure to non-technical users.

    Of course if the site then sends the form data back up unencrypted (e.g. after server side value validation fails) that is then insecure, but no one with a brain sends the password value back up anyway.

Trap full -- please empty.

Working...