Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome hides www and https:// in the address bar again

bleepingcomputer.com

Post reply on HN
Print view View original

121–130 of 194 posts

Re: Chrome hides www and https:// in the address bar again

#121

Post by EpicEng »

RobertRoberts wrote: post #119
EpicEng wrote: post #37

Earlier quoted context omitted.

Have they though? How many of their users understand what "www" or "https" mean? For those that have a vague idea, how many ever look? I don't like the change either, for a variety of reasons, but I don't think I'm their average user either. For the average user, seeing the domain and nothing else likely improves security.

This isn't about users, it's about a scam to trick people into thinking that something is being served from their site, but it's not, it will be from Google. (ie, AMP)

Like I said, I'm against it for several reasons, but I replied to this:

>there seems to be a disconnect between the chrome devs and users

Re: Chrome hides www and https:// in the address bar again

#122

Post by dwild »

EpicEng wrote: post #37
mr_puzzled wrote: post #7

Off topic : there seems to be a disconnect between the chrome devs and users. Another instance was the automatic signing in to chrome incident. I've lost trust in the chrome team and have switched to Firefox full time and honestly there's nothing that I miss. The firefox devs seem to better understand their users, frequently blog about changes that positively impact users. I have a lot more faith in firefox even thou…

Have they though? How many of their users understand what "www" or "https" mean? For those that have a vague idea, how many ever look? I don't like the change either, for a variety of reasons, but I don't think I'm their average user either. For the average user, seeing the domain and nothing else likely improves security.

> seeing the domain and nothing else likely improves security

By hiding between 1 to 3 letters?

It seems much more secure to do it like Firefox using grey for the unimportant part and black for the important part.

If anything, if "m" is hijacked (by a feature actually to use subdomains), it's less secure because now he thinks he is somewhere that he isn't.

Re: Chrome hides www and https:// in the address bar again

#123

Post by dwild »

privateSFacct wrote: post #22
Rebelgecko wrote: post #5

Google must really hate URLs. My search results recently stopped showing the full path of the URL, just the domain name. It was a huge pain because I was looking for an item at Ikea and couldn't tell if a result went to their American site or to their UK, Saudi Arabian, Qatari, etc. site (apparently the same item can have small differences in different countries— I almost bought the wrong lightbulbs because the UK ve…

Google sees folks falling for google-secure-payments.google.via.net type URLS. They see all the gaming people do with URLs in search results (including abusing the names of other brands like Amazon). There are lots of developers who like distinguishing these subtle topics. I can tell you in a larger enterprise deployment most of these changes will be welcomed (yes, people do still click on bogus URLs believe it or no…

Can you tell me what's more secure and why?

    Before the change: www.google.com
    After the change: google.com

    Before the change: google-secure-payments.google.via.net
    After the change: google-secure-payments.google.via.net
Seems to me like the same trick is available.

Now do it like Firefox:

    Grey: www
    Black google.com

    Grey: google-secure-payments.google
    Black: via.net
Warning: Check the black portion of the URL and make sure it's the right one!

Re: Chrome hides www and https:// in the address bar again

#124

Post by dreamcompiler »

ken wrote: post #108
jorvi wrote: post #81

Earlier quoted context omitted.

Its hostile for power users but it prevents grandpa from renaming 'IMG_144.jpg' to 'Idaho_grandkids', hammering enter on the 'are you sure you want this' nag screen and then wondering what broke his picture.

On Macs before 2001, that used to work! We didn't used to cram pieces of file metadata into file names. File type was stored its own slot. The hidden-ness of a file was stored in its own slot. I find it amazing that despite the industry's trend in recent years away from string-typing and towards static-typing, metadata-in-file-name just won't die. I'm all for removing old ways of doing things that were bad, when we h…

Apple used to be the innovator in file metadata. They stopped when Steve came back because proper metadata made it more difficult to share files with Windows and Unix. And we're still stuck with crap metadata to this day.

Re: Chrome hides www and https:// in the address bar again

#125

Post by dreamcompiler »

e12e wrote: post #104
jorvi wrote: post #81

Earlier quoted context omitted.

Its hostile for power users but it prevents grandpa from renaming 'IMG_144.jpg' to 'Idaho_grandkids', hammering enter on the 'are you sure you want this' nag screen and then wondering what broke his picture.

Does Mac still have resource forks? Either way, I'm sure it still has decent magic number decoding. Who (except family members in windows?) would care about the missing extensions? The only real reason i care is for vim file detection (in Linux). How sad is that? :'(

Resource forks are still supported. At least they were with HFS+. They might be gone in APFS. In any case with each release Apple makes it harder to access them.

Re: Chrome hides www and https:// in the address bar again

#126

Post by v7p1Qbt1im »

RobertRoberts wrote: post #84

This is a giant AMP scam. The next change will be that it will trick users into thinking they are on are on a real site like example.com but will instead be on Google.com/example.com. But chrome will remove google.com just like http/s.

Signed HTTP exchanges. It was actually the main complaint about AMP because it caused confusion among users. Technically it makes no difference wether the content is hosted by the author or any AMP CDN.

The question is more a philosophical one. If it’s wrong that the URL doesn’t point to where files are “actually” stored. Or rather that the package delivery and package creator aren’t the same party. In my mind this hasn’t been the case for a long time now anyway.

https://amp.dev/documentation/guides-and-tutorials/optimize-...

Re: Chrome hides www and https:// in the address bar again

#127

Post by dreamcompiler »

Consultant32452 wrote: post #59
mholt wrote: post #45

Earlier quoted context omitted.

Finder on macOS does this too. It's maddening... There was an article recently about "hostile architecture" and this is similarly a "hostile software design" to prevent users from doing something the developers don't want them to do.

And requires you to jump through non-obvious hoops to make "hidden" files and folders visible.

And now ~/Library is invisible by default, so that's yet another thing I have to fix on any new installation.

Re: Chrome hides www and https:// in the address bar again

#128

Post by magicalist »

danShumway wrote: post #94
ljoshua wrote: post #34

Earlier quoted context omitted.

I use Brave as my daily driver, but this trickled down into Brave as well this morning. I was confused for a minute what I had done with a subdomain on one of my sites, and then got very frustrated when I realized the Chromium team had put this back in place. A few #omnibox... tweaks later and I have it back, but it is certainly annoying.

This is why forking Chromium is not a solution. Unless a team is committed to maintaining that fork, eventually they'll be forced to merge in any of the changes that Google wants to push. The only way a Chromium fork works is if the team is willing to stop merging after they fork and take over development themselves.

> This is why forking Chromium is not a solution

Brave isn't a fork, though, it's a downstream consumer of Chromium.

> The only way a Chromium fork works is if the team is willing to stop merging after they fork and take over development themselves.

I mean, that's what a fork is, so yeah?

I don't think Brave demonstrates much about that situation.

Re: Chrome hides www and https:// in the address bar again

#129

Post by OrgNet »

mr_puzzled wrote: post #7

Off topic : there seems to be a disconnect between the chrome devs and users. Another instance was the automatic signing in to chrome incident. I've lost trust in the chrome team and have switched to Firefox full time and honestly there's nothing that I miss. The firefox devs seem to better understand their users, frequently blog about changes that positively impact users. I have a lot more faith in firefox even thou…

I still prefer Firefox but they removed many features that I liked... maybe because I dont share analytics but that doesnt matter to me

Re: Chrome hides www and https:// in the address bar again

#130

Post by xemdetia »

magicalist wrote: post #86
xemdetia wrote: post #53

Earlier quoted context omitted.

I doubt that, because the number of times they completely ruin chrome as an intranet browser in the last few years with TLS handling, self signed cert handling, and general settings window changing malarkey shows that they are not even catering to that market very well, especially when they add a workaround and take it away in a very short window which for better or worse is often much shorter than most large organiz…

> ruin chrome as an intranet browser in the last few years with TLS handling, self signed cert handling, and general settings window changing malarkey Just put it in the OS certificate store? It's worked like that since Chrome was released.

I'm talking about things like HSTS where the interface to purge HSTS entries that have become invalid has changed constantly.

Some people hit these which I had to solve for them because it was pretty opaque until Google started indexing the error message properly: https://security.googleblog.com/2016/10/distrusting-wosign-a... and this one https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

There are people whose entire workflow is constantly bypassing self signed certificate/browser warnings, and the interface to undo an override is persistently changing as well. The method to get the certificate details of the site you are connecting to (which helps for self signed soup) has also been changing constantly over the last 5 years for Chrome, but for browsers like Firefox have basically been the same thing. e.g. Chrome 56 https://www.ssl2buy.com/wiki/how-to-view-ssl-certificate-det... has a totally different procedure to what you can do in Chrome 75, where it is back in the site details drop down (where it was before Chrome 56).

Really it's any case that you navigate to a site and get the Chrome error page for a TLS related reason. Many people who administer enterprise applications are not technical people and so they don't even know this sort of thing is coming. They get other people to do the technical/software updates but are generally just there to keep the system alive and get value from the system, but Chrome doesn't clearly explain to them what happened and they go to IE/Firefox and it works fine. For most people this is the limits of their troubleshooting and they have no recourse. Then on top of it the procedure or documentation that they used last time (often generated by a technical resource they may not have anymore) no longer works and they are stuck. It's a very frustrating experience for a lot of people and I wish they handled it better.

Post reply on HN