voludu2 wrote:The person who provided that link said it showed how a this type of vulnerability could compromise a cell phone.

I am not an expert. I am hoping to hear from an expert.

In extreme cases, yes.
Most vulnerabilities take place on public/not their wifi. People can spoof pages.. and many browsers have vulnerabilities. Even making the browser unstable is an accomplishment

Passwords can also be transmitted in a way that can easily be read. Depending on the situation.

For links, you can use //Google.ca or //Wikipedia.org doing so should avoid the blue lock icon (frowned upon!). and automatically select http or https. Not all sites have https. Do NOT use https for every link!

kentsmith9 wrote:

CoolCanuck wrote:For links, you can use //Google.ca or //Wikipedia.org doing so should avoid the blue lock icon (frowned upon!). and automatically select http or https. Not all sites have https. Do NOT use https for every link!

I am pretty confident using //Wikipedia.org and http://Wikipedia.org are the same. In both cases the browser starts a standard http link with the host server. If the server redirects to the https secure link, then you automatically get transferred to the secure page.

Therefore using //Wikipedia.org is no different and is still exposed in the same way.

As mentioned previously, we can create a template (maybe we already did) to display secure links without the lock symbol. Or we can ignore it if we believe no one is confused by the meaning of the lock.

Hi kentsmith9,

Please see this wikipedia article, as our style guide is very similar. https://en.wikipedia.org/wiki/Help:URL# ... and_https:

using // also helps prevent "unsafe resource" browser warnings when an image/script over http:// is loaded from the secure wiki. There is a difference.

Here is a small article I created to try to help others understand. It is not complete.
https://wiki.waze.com/wiki/User:CoolCan ... HTTPStests

voludu2 wrote:You said there is a flaw to using //

Is that meant to be an argument against using it?

Or are you saying that // is, on the whole, a good choice?

Just being honest . The flaw is that links are not automatically formatted. (you have to use [//example.com]. Not a huge disadvantage, since we name our links eg [//wikipedia.org Wikipedia]

You can name links. I'm saying if you simply type //site.com , it will not be a clickable link.

writing http://site.com or https://site.com automatically is a clickable link

We should always aim for the best experience possible for our fellow users. If we can prevent an attack/interception - we should. While it is not directly our concern, nor goal, it would be foolish to allow an attack happen that we know could easily be prevented. Some people are not tech-savy. By not implementing this, it's almost like you're wishing for it to happen. You are well aware of the problems we could prevent, the outcome, and how the person could feel if an attack happened. Let's prevent any bad experience - both using the wiki, and clicking outside links.

I think you took the comment top_gun_de wrote the wrong way. As you know, it is difficult to express tone on the Internet. As such, things are often taken in the worst way possible. I strongly believe top_gun_de was NOT trying to say you lacked knowledge about IP and DNS. He simply stated a fact.. possibly not directed at you.

Here's what I consider an "insult".
"Unlike you, ___________"
"Do some research"
"It's just common sense"
etc.

I'm not seeing any of that language being used.

Just to be clear: We're talking strictly about https in the Waze Wiki.

"You'll also note that Google does not encourage https in its place links." Can you please cite an official source proving this?
"Google is well aware of the security concerns, and it does not rise high enough to override the difficulty/awkwardness it would place on its in-house and community authors, nor the negative user experience that https can sometimes cause (e.g., certificate errors)."

What's worse? A certificate error, or having your data/system compromised?

Have a great day, and thanks for all your hard work!

The attack vector:
1. User types http://www.waze.com
2. Attacker intercepts this and displays some other page that is identical to the waze login page. It may even have a green lock in the url with a different but similar-looking domain name.
3. User doesn't notice this, and enters their credentials into the attackers site. The attacker now has their password, and no traffic has even gone to waze servers, so they can't prevent it.

That's why you always use https, and be wary of entering credentials from a link.

If using http to go to an https site puts any Waze user at risk, shouldn't the entire wiki be changes?

Maybe this is how?