Re: Proposal: Marking HTTP As Non-Secure

Hi Everyone,

I am new to posting, a former "Watcher" they put root in the corner, but I really do like the proposal so I felt compelled to write. In fact for the last couple of years, certain agencies/as well as bad actors, that I will not name have covertly been able to literally see what I see and go where I go when the pages are not secured. On one hand it helped US government agents take a ride with me to the dark side and provided them with information that they never would have been able to get or understand without me, to protect all of us from really bad actors, plots and more. I guess your a patriot if you give up your life for others, but I am not cut from their cloth so that doesn't jive well with me, it shouldn't be that way. Not anymore at least.
On the other hand bad actors would literally, see what I was seeing including my medical research, years of work used or sold by bad actors solely based on the pages I was viewing that were not secured, followed by redirecting me to terrorist websites. I ended up in jail for drugs I never bought but my credit card was used, a former agent ended up in jail, a very disturbing situation to say the least. He was from the "old school days" of law enforcement he didn't stand a chance and didn't deserve what he got because "the higher ups" didn't take the time to listen or understand that little person screaming at the top of her lungs. Very sad indeed. We have enough bad guys so when a good guy gets put away, it makes you wonder why your still a good guy.
The bad actors would create bogus letters based on the pages I would view, as a way of harassment find my location and mail me things to make me jump out of my skin, all of which a police officer would not be able to understand if you needed to go to them to fill out a report. A new brand of harassment and recruiting tool. Making a user believe law enforcement doesn't care, creating the illusion everything in the world is bad, the pop ups that redirect you to the sites they want you to see, after years of this type of surveillance and really psychological warfare, an impressionable teen or adult could easily become a victim or a recruit for them. All because the pages are not secure. In my experience bad actors don't go underground, they hide in plain site as in non-secured webpages with code in the script. 
They have found ways to listen in on calls through my mic/phone... other bad actors would constantly send denial of service attacks, and implement MITM attacks on me, my banks and much more. Everyone said it couldn't be done with Chrome, I've been told to submit bugs, xyz... So for the last 5 years, I have been trying to find ways to secure Chrome. Privacy is now a luxury and its not free, despite all of the fake freedoms they say we have we just don't that's a fact so am grateful to your team and to the other user/developers on here. With DRTbox and Stingray, plus not knowing the integrity of the agent/officer, we all need to be secure. I can promise that when it comes to cyber they are years behind. When you need help they pretend the problem doesn't exist, (as in my case, until you become an asset to them). 
Take a look at the command line below, this occurred over air with a different Chrome, without consent. While this was occurring, I noticed that I'd walk into a store, be it Best Buy, Office Max, or The Apple store for purchase while everyone is hooked up to "secure wifi", these bad actors send bad kernal code executions and more. Before you walk out the door after your purchase the damage is already done. My case is extreme, but it is being done.

/opt/google/chrome/chrome--enable-logging--gpu-sandbox-failures-fatalsys--ppapi-flash-(disable)args-enable_htv_video_decode=1--ppapi-flash-path=/opt/google/chrome/pepper/libpeplash/--ui-prioritze-in-gpu-process--use-cras--use-gl=egl--user-data-dir=/home/chronos--vmodule=screen_lockers=!webui_screen_locker=2, *ui/display/chromeos*=1,*1, *as/display*=1,*ui/ozone*=1,*zygote*=1*plugin*=2--ozone-platform=gbm--ozone-use-surfaceless-default-wallpaper-large=1usr/share/chromeos/-assets/wallpaper/oem_small.jpg --guest-assets/wallpaper/guest-small.jpg--max-tiles-for-interest-area=512--max-unused-resource-memory-usage-percentage=5--has-chromeos-keyboard --login-profile=user=bwsi--homepage-chrome://newtab/--incongnito--log-level=1 --login-user=$guest--obbe-guest-session--login-user=$guest--login-profile=f00cd7b941583--disable-sync--disable-extension--ozone-use *surfaceless

I wanted to take what I have been through to the next level and go to the Financial Times Security Summit, where the heads of most companies I have in one way or another been on the phone with, will be, this coming March. Having had in one way or another spoken to the heads of banks, healthcare providers, medical institutions, all of which have been tampered with and the credit bureaus, something needs to be done. My background is medical research, so I'd rather go to DC, to discuss other matters.....I am glad you are all on top of this, I wouldn't have survived the last 5 years if you were not. It is really hard explaining to friends and family what is really happening. Its the mindset that, if I ignore it long enough it will go away, or its just too crazy. We all have parents, so knowing what someone is possibly doing to them, is a painful site. So Thank you again!!!!!!!!! A million times. 
I love the proposal, please keep me posted.

Thanks
Forsight

On Friday, December 12, 2014 at 7:46:36 PM UTC-5, Chris Palmer wrote:
> Hi everyone,
> 
> 
> Apologies to those of you who are about to get this more than once, due to the cross-posting. I'd like to get feedback from a wide variety of people: UA developers, web developers, and users. The canonical location for this proposal is: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure.
> 
> 
> 
> Proposal
> 
> We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure. We intend to devise and begin deploying a transition plan for Chrome in 2015.
> 
> The goal of this proposal is to more clearly display to users that HTTP provides no data security.
> 
> Request
> 
> We’d like to hear everyone’s thoughts on this proposal, and to discuss with the web community about how different transition plans might serve users.
> 
> Background
> 
> We all need data communication on the web to be secure (private, authenticated, untampered). When there is no data security, the UA should explicitly display that, so users can make informed decisions about how to interact with an origin.
> 
> Roughly speaking, there are three basic transport layer security states for web origins:
> 
> Secure (valid HTTPS, other origins like (*, localhost, *));
> Dubious (valid HTTPS but with mixed passive resources, valid HTTPS with minor TLS errors); and
> Non-secure (broken HTTPS, HTTP).
> 
> For more precise definitions of secure and non-secure, see Requirements for Powerful Features and Mixed Content.
> 
> We know that active tampering and surveillance attacks, as well as passive surveillance attacks, are not theoretical but are in fact commonplace on the web.
> 
> RFC 7258: Pervasive Monitoring Is an Attack
> NSA uses Google cookies to pinpoint targets for hacking
> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
> How bad is it to replace adSense code id to ISP's adSense ID on free Internet?
> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
> Erosion of the moral authority of transparent middleboxes
> Transitioning The Web To HTTPS
> 
> We know that people do not generally perceive the absence of a warning sign. (See e.g. The Emperor's New Security Indicators.) Yet the only situation in which web browsers are guaranteed not to warn users is precisely when there is no chance of security: when the origin is transported via HTTP. Here are screenshots of the status quo for non-secure domains in Chrome, Safari, Firefox, and Internet Explorer:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Particulars
> 
> UA vendors who agree with this proposal should decide how best to phase in the UX changes given the needs of their users and their product design constraints. Generally, we suggest a phased approach to marking non-secure origins as non-secure. For example, a UA vendor might decide that in the medium term, they will represent non-secure origins in the same way that they represent Dubious origins. Then, in the long term, the vendor might decide to represent non-secure origins in the same way that they represent Bad origins.
> 
> Ultimately, we can even imagine a long term in which secure origins are so widely deployed that we can leave them unmarked (as HTTP is today), and mark only the rare non-secure origins.
> 
> There are several ways vendors might decide to transition from one phase to the next. For example, the transition plan could be time-based:
> 
> T0 (now): Non-secure origins unmarked
> T1: Non-secure origins marked as Dubious
> T2: Non-secure origins marked as Non-secure
> T3: Secure origins unmarked
> 
> Or, vendors might set thresholds based on telemetry that measures the ratios of user interaction with secure origins vs. non-secure. Consider this strawman proposal:
> 
> Secure > 65%: Non-secure origins marked as Dubious
> Secure > 75%: Non-secure origins marked as Non-secure
> Secure > 85%: Secure origins unmarked
> 
> The particular thresholds or transition dates are very much up for discussion. Additionally, how to define “ratios of user interaction” is also up for discussion; ideas include the ratio of secure to non-secure page loads, the ratio of secure to non-secure resource loads, or the ratio of total time spent interacting with secure vs. non-secure origins.
> 
> We’d love to hear what UA vendors, web developers, and users think. Thanks for reading!

-- 
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 [email protected]