The Chromium project has announced this change to adapt to the new W3C standard which mandates that any powerful feature has its limited use through secure authentication environments.

The W3C itself admits that simply requiring HTTPS for such features is not enough to guarantee end-user security, however it establishes such a standard as a prerequisite for building a safer Internet. The determination is that any application that has access to sensitive data is offered with the minimum of authenticated security (HTTPS).

While the policy does not prevent malicious developers from delivering harmful content to end users, it at least tries to prevent more often that Man-In-Kind attacks inject malicious scripts onto their web page to acquire sensitive data from their users.

Before such a change could happen, one needed to discuss what characterizes powerful features in the Web context. In short, it has been defined as a powerful resource any and all code offers access to: >

• Sensitive Information (Personal Information, Credentials, Payments, etc.)
• Access to sensors (geolocation, webcam, camera, etc.)
• Information from other devices (Bluetooth, Wireless, etc.)
• Stored Sessions
• Appeal that can request user permission
• Among others.

Note: I think it's worth adding that Chrome offers a flag that allows you to treat unsafe sites as safe for testing purposes. Just run Chrome using the --unsafely-treat-insecure-origin-as-secure="example.com" flag (replacing example.com with your domain of interest).

References:

• Defining HTTP as Unsecured
• Defining Powerful Features in Unsafe As Obsolete Sources
• Security Context for WEB Applications - W3C