I had a strong gut feeling Google has one or multiple ulterior motives for doing this - motives that aren't very user-friendly (as they claim) but more Google-friendly. I thought it may be so that it can track every link you type in Chrome without 99.9% of the users being aware of it. Right now Google does that only for "searches" in the omnibox.
I hadn't thought about the amp angle, but that could be another reason for pushing this, too. Perhaps there are more we won't know until it's too late to do anything about it (other than changing browsers, of course).
According to this blog post[0], IE misbehaves with cookies and allows breaking SOP.
The spec says that a cookie flagged with the domain "domain.com" is supposed to only be valid for requests to "domain.com" and not "subdomain.domain.com". A cookie that is intended to be valid for all subdomains is supposed to have a preceding dot, like ".domain.com".
Older versions of IE (That may still be in use) will treat "domain.com" cookies like ".domain.com" cookies, allowing malicious.subdomain.domain.com to access cookies only intended for "domain.com".
This is actually a lot harder than it sounds. You can CNAME www, but you can't CNAME your apex (some DNS providers pretend you can, they will resolve your CNAME for you and provide A/AAAA records to recursive resolvers -- but if you wanted to CNAME to a DNS based load balancer, that doesn't really work)
This causes browser security problems, it creates load balancing issues, it makes failover harder, etc. Only works for small sites that don't need to be highly available.
I don't understand your argument, unlike "http://" the www subdomain had no real technical implication, it's just a common naming choice for web servers.
It's about the principle. www is a valid subdomain.
Browsers are supposed to be as unopinionated as possible since they are browsers, not mediators, and their job is to implement the standards of the web.
I didn't realize that the standards of the web specified anything about how an address bar should be displayed (or, for that matter, that it specified anything about an address bar even existing).
> This document describes the syntax and semantics for a compact string
representation for a resource available via the Internet. These
strings are called "Uniform Resource Locators" (URLs).
Safari doesn't show you the url at all until you click either; so the URL bar is just a domain indicator -- in that case, it seems less objectionable that it doesn't show the FQDN, but instead something different -- copying the url from a screenshot was bound for disappointment anyway.
This is a fair point. A possible counterpoint is that one can draw a line at malware. A fairly strong argument can be made that controlling popups is an exceptional security measure that is the only way, or the most effective way, to control the spread of objectively dangerous software. It is also a matter of UI - popups could appear faster than a human could control them, so it makes sense to make popups opt-in (which they are).
No similar argument can be made about disabling "www." It is purely an opinionated decision amounting to "you don't need www" - assuming it's not a bug, of course.
No, but I want my browser to notify me that its blocking popups rather than just hiding them from me entirely and assuming I never wanted to see them anyway.
My site, although one can argue it is a poorly configured (although it is intentionally configured this way), is a great example of why this is problematic.
I never set up a www cname, but now unless you're paying attention (or actually reading error messages) you might not notice that the reason it failed is because you're not at the domain but on the `www` subdomain. The URL bar doesn't convey this information until you click it and then it shows the full URL.
It's really minor but I also don't see a good reason to do this. All the sites hosted by the company I work for are hosted on `www.` with the intention that it "looks more professional".
Looks like this is intentional. To change it back go to chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains and disable the setting.
Until Firefox leadership decide to make the same change "because that's what Chrome does". Sadly, over the history of Firefox (and before that, Mozilla/Seamonkey) the leadership there has always been WAY too obsessed with following IE and/or Chrome rather than just building the best browser and taking some chances.
Seriously, trawl through Bugzilla sometime and look how many bugs are closed with the the justification being some variation of "That's how IE does it" or "IE doesn't support that", etc. And then substitute "Chrome" for "IE" later in history once Chrome took over the universe.
Additionally, if this flag ever goes away, the "kFormatUrlOmitTrivialSubdomains" is the internal flag for this, it seems[1], though its description says it's "Not in kFormatUrlOmitDefaults"[2].
Back when they removed the "http:" off of URLs, I used to use a hex editor to turn the kFormatUrlOmitHTTP bit flag off every time I got a new build, so I'd get the URL formatting I wanted, but eventually lost the mental wherewithal to continue the hack every week.
While sure, www seems odd now, it's still a subdomain and we're inching into territory of obscuring things that matter for small gains in end-user perception that aren't _that_ impactful.
I've heard people say "backslash" when they insist on reading out the whole URL with protocol, which I'm pretty sure is the wrong slash, I honestly don't know, but I've never understood why people felt the need to say it at all. Do they type the protocol into the address bar when they visit sites?
My bet is this decision is driven somewhere by marketing morons who want 'www.google' (presumably a domain that will at some point exist, the TLD already does) to render as simply 'google'
Technically there's no reason why a TLD can't have an A record. If they own "google." they can point it to whatever address and serve whatever they want.
My guess is they’re patiently trying to train users to prepare them for a post-url era. I don’t remember where but I recall hearing the google was trying to replace the standard. Sort of like how Apple has had to retrain people to not think so much in terms of files but in terms of apps.
Same exact reason that api.domain.com or beta.domain.com matters - you're on a subdomain, not the root domain. That the internet and world at large made www the "kind of" root domain in many cases is an unfortunate thing, but I've not seen a modern server configuration that doesn't handle this case by default.
But when using HTTP(S), you nearly always expect the "www." domain and the root domain to host the same content. It's very, very rare that this isn't the case. Chrome appears to be hiding "m.", too, which is unfortunate (as would api. or beta. being hidden), but "www." is such boilerplate for HTTP at this point that I don't think it matters whether it's displayed or not.
I think it matters, quite a bit actually. My expectation as a user is that the URL I see in the bar is the URL of the site I'm visiting. If it's not accurate, then why show it at all?
Because the second level domain is far more important than the subdomain. The second level. www.example.com and example.com usually have the same contents, but are always controlled by the same group.
It's not true that the second level and third level are always controlled by the same group (most of .uk for example). You can put an SOA record anywhere.
But the entity that controls the second level domain always controls all of its subdomains, not just www. Historically www has been a special case, but that's not a requirement and that's on the decline.
It seems like the confusion this change causes negates any benefit it could have.
This is just going in a circle. If they don't care about it then it makes no difference. A few characters in an address bar that they pay no attention to is not significant noise. Meanwhile the people that do care have less information.
They don't need to care about checking whether it's there or not or seeing it at all. But in a general sense, users do care about reduced clutter and aesthetics, and this is a way of improving aesthetics and creating a more consistent URL bar. It's a tiny bit more consistency and a tiny bit less clutter, but it's not nothing.
The users who truly care can just click the URL bar. (Someone said you also have to press the left arrow, which if true seems like a bad decision. I would agree the full URL should always be visible whenever the cursor focus is in the URL bar.)
This is going to be a problem weather or not Chrome changes www.example.org to example.org. There is a _very_ non-trivial chance the person was going to write down example.org anyways.
If in most uses minds, "www.example.com" is the same as "example.com", then "example.com" is less confusing because they have probably never heard of the word "subdomain".
My admittedly anecdotal evidence suggest that they do not. From my other comment: I worked as tech support for a large org (300+ users) most of my career and have dealt with most types of users. I've only seen them interact with the address bar in one of two ways: explorer shortcuts on the desktop/browser bookmarks (few) or stick-it notes on the monitor or keyboard (many).
If you count only the people who require tech support then of course you're only going to see the people who require tech support. But they're not the only users.
Developers and techies are users too and they're much less likely to call tech support in general.
This harms them far more than it helps the people who need help.
And this move was made under the guise of improving ux for normal users and not users who know how subdomains work. What's the point you're trying to make?
Anyone know if this checks for a DNS record that supports equivalency between the www/empty subdomains? It's possible for them to have different values.
Have any of you with corporate-type proxies been seeing authentication issues? Since moving to Chrome 69 a number of our users are reporting repeated proxy auth prompts when this should normally be handled transparently by Kerberos.
If the browser uses some technique to detect that www.domain.com is functionally identical to domain.com for a given domain, then I don't see a serious problem with this. But if they are short of that certainty, they're obscuring a critical part of the URL, and harming usability (e.g., if I want to jot down a site's URL for later use, I might get something unexpected).
> If the browser uses some technique to detect that www.domain.com is functionally identical to domain.com for a given domain, then I don't see a serious problem with this.
Say, for example, if the canonical URL doesn't have a "www" in it?
That's not the case. I run a server that does not respond to "www." If I enter "www.myserver.com" into the address bar, I get a DNS lookup failure, but the address bar is now showing "myserver.com." That's damn confusing, and this is an idiotic default on Chrome's part.
Likewise, something is saying that their bank only works through www.bank.com. But the URL says bank.com. If they try to type in bank.com it doesn't work.
But hey, now we don't have to see www which has been around forever and is a surprise to no one!
Funny enough, I visited a site for some task or other just yesterday for which I just typed the base domain, and got ... nothing. It still required the "www." prefix -- no redirect, "ANAME" DNS-side hacks, VIPs or anything in place to make the base domain a reachable URL. This new Chrome change, if it's truly doing naive subdomain hiding, would be a really bad UX for sites like that.
"If you click into the address bar to copy/paste, the full URL will come back."
Which is also terrible behavior. Unwanted characters hidden into your paste buffer is at best unexpected and capricious behavior and at worst a source of serious, possibly catastrophic consequences (depending on what, and where, you are pasting).
How soon until a doctored up paste buffer contains, by design, a newline character ? I'm sure there must be some use-case that (appears to) call for this ...
Thank you for validating that I'm not the only person who hates Chrome's horrible clipboard behavior. When I highlight something and copy it to my clipboard I expect exactly what I've highlighted to be on my clipboard-- not some editorialized version of it.
Well, browsers already support a better form of this feature. On the server you setup a redirect to your preferred domain. You redirect https://www.example.com to https://example.com or vise versa.
This isn't entirely without precedent. Firefox does something similar by greying out the `www` in the UI, Chrome just decided to take things a step further by hiding it entirely.
Firefox's behaviour is that is makes everything except the eTLD+1 grey, because that's what's normally useful for evaluating authenticity. There's no distinction made between `www` and any other subdomain.
This is idiotic and harmful. We already lost information about the protocol, because somebody believed it is "too complex" for users. Now we're losing other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me? It used to signify that a "known authority" certified that I'm connected to whatever I see in the URL bar. But now that browsers take liberties with modifying the URL bar as they see fit, it becomes increasingly meaningless.
Google wants to destroy the URL so the only way to find something will be via Google... They also want to tie your identity to each webpage that you author via a certificate so that all governments can clamp down on fake information or have the opportunity to in the future.
It started being meaningless thanks to Let's Encrypt. Before it meant you had to show your ID and banking info to a "reputable" corporation for them to make a cert for you. Yes I know I know, not always the case, but...
LE means that the mantra "if it's https then it's a secure and reputable website" is now outdated.
> Before it meant you had to show your ID and banking info to a "reputable" corporation for them to make a cert for you.
No it didn't. Let's Encrypt made free certificates easier to get, but Let's Encrypt doesn't do less verification than some other CAs/some of their products.
No, the padlock means that you are likely connected to the website that the URL bar shows you. This is useful and should not be discarded because of condescending ideas about "average users". It also has the advantage of being easy to explain.
Some people assign additional meaning to the padlock, which should not be done. It doesn't mean you are talking to your bank, it only means that you are talking to the website shown in the URL bar and that reasonable (simple) checks were performed to make sure that is the case.
I'd suggest we invent something better before we start breaking it.
Given the adoption rate of SSL, I imagine the padlock itself will become useless even without Chrome's changes. Does it mean anything if almost every website has it?
The clearly announced intent of at least Mozilla and Google (and I'd assume Apple and Microsoft but I don't pay as much attention) is to focus on highlighting the insecure state because that has much better security UX. Labeling one site you visit today "Not Secure" stands out. With luck it might be enough that you don't type in your credit card details.
That's why Chrome is moving away from showing the padlock to displaying "Not secure" for sites that aren't secure. The padlock will be going away entirely; secure is the default state.
They didn't care so far because it was so confusing. The hope is that by showing something that's user-relevant (the name of the website name and the security level), it will become more useful for the average user.
Because arguments aren't always useless like in your example. Might as well just do away with the whole URL bar and just have a green checkmark if Chrome thinks it's the site you want.
I mean, why should a user see "Wikipedia.org/wiki/Canada" when all they care about is "This is the Wikipedia Page for Canada"?
I know you’re being sarcastic, but if chrome could, with perfect accuracy, indicate if this was “the site you want”, why not do away with the url?
Mind you, I’m not suggesting to do away with linking, as some rando suggested this implies. (While chrome doesn’t show the protocol prefix, it still copies the prefix when you copy the url, so imagine a similar ui.) But for most users, wouldn’t a ui that shows “server identity” in some more user-coherent way be what they want?
In particular, do subdomains help or hurt phishing detection?
If we could, I'd be all for it. Have an option that says "show URL bar or not" and by default hide the URL bar, optionally show the whole thing. Especially on space-constrained devices like cell phones where every pixel counts. Just show the page's title.
I think we're a long way away from that ideal, though, and some web pages may not be designed with this ideal in mind.
You're making a hypothetical based on "with perfect accuracy"... but the much simpler change here (www vs. no www) is not done "with perfect accuracy", as clearly outlined by a bunch of comments in this thread.
So you're saying we should show all users www., just because that one site in a billion that shows a different non-www. page, for that one user in a million that would even notice that difference? Chrome is a browser for the mainstream people. The feature you're asking for is for power users and extreme edge cases.
do not have to be the same website
and there are cases where it isn't the same site!
Which site you visit does matter and not just for internet banking.
If it becomes that easy if we hide things maybe we should hide the half of the traffic lights as well.
Those examples don't prove anything. First off, the http ones would appear different, they would have no lock. And 99.999999% of websites don't have a different www. and non-www. page. Showing www. for that 1 in a billion site, for that 1 in a million user, is insane.
What if the user sees "Wik1pedia.org/wiki/Canada"? Or "аррӏе.com"?
Hiding random parts of the address isn't going to make browsing the web better. The main purpose of URLs is for hyperlinks, not as a highly intuitive user interface. Users who don't know how URLs work don't care what is up there. They only care that what they are looking at is what they expect, and a way to get to where they want to go. And that's a complicated problem.
The URL bar hiding thing isn't for users, it's for Google to push Google search. That's why they attempted to remove the URL bar entirely four years ago and replace it with a search bar.
Also, if you go into about:config and turn off keyword.enabled, the address bar will no longer search.
It's very useful if you don't want to Google internal/client URLs just because you accidentally copied a space at the start or the hostname doesn't resolve in your current environment, etc.
Right. So messing with the URL bar is pointless. If people actually don't like it, get rid of it, but provide some other means to establish authenticity of what you're looking at.
That has nothing to do my argument. Just because people can't detect homoglyphs doesn't mean we should keep overloaded urls and shouldn't strive to make them more user friendly.
There's still value to be gained from having easily readable urls.
If the browser absolutely 100% of the time knew that difference and showed "Wikipedia FR > Canada", wouldn't it be much simpler for the average user?
The browser could even show specialized UI such as "FR" as a clickable dropdown menu to allow users to switch languages. Chrome already does this for searching a single website through the address bar (type domain.com TAB)
Basically these changes are not thought for you.
You are not representative of the average Web user.
Maybe it could show "Canada - Wikipedia" like the page authors intended as a title. Maybe if the page authors want to have links between languages, they could code that in a standard markup language themselves.
These aren't decisions for a useragent to make, and there aren't enough browsers out there that people have a reasonable choice.
Bastardising the url isn't a solution to anything, it's a step towards something that Google, not users, want (in making AMP "trivial").
A useragent is literally a user's agent, it is supposed to help its user browse their target website. It is not supposed to help the target website show things to the user.
Hiding the URL would be a terrible idea, no matter how much "simpler" it would be for the average user: it would either only be enabled for a handful of websites chosen by Google (which would mean having an inconsistent UI) or create a lot of security issues (what if someone creates a website and manages to also display "Wikipedia FR" with a similar layout?).
No, it's really important to retain all those dots and slashes. This is not sarcasm. I'm being completely serious when I say this. It's really easy notation, and the differentiation of context for dots, slashes, question marks and hashtags is really useful.
Wikipedia FR > Canada
I look at that angle bracket with the white space, and I get chills. And I'm not even drawing attention to that oh-so-glaring omission of the /wiki/ context. Truly horrifying.
It matters because deep-linking is possible on the web.
Hiding it just seems like a trivial UI matter that makes things slightly more obnoxious when you do care.
I'd be surprised if only showing the domain vs domain+path made any difference on phishing results.
I don't think these little tricks do much for the user. For example, browsers now highlight https websites with green in the url bar and show a little lock icon. But how is that actionable information for the user? To what extent does that mean you can trust that website, and how does the average person interpret it? Phishing websites use https, too.
I would avoid stealing any pages from Safari's UI. That browser doesn't even show favicons on browser tabs to let you quickly distinguish them.
This is a very bad analogy. Anyone in a car crash potentially benefits from airbags without knowing anything about them (or even if they exist at all).
The 99.9% of people who don't even know the difference between www and non-www will never directly benefit from seeing www, ever.
We must avoid friction between two types of user, 99.9%er and 0.1%er. We could have separate browsers aimed at each.
One browser should be dead simple, secure, and streamlined, aimed at the 99.9%s. Maybe it could be named after a metal.
Another browser, for the 0.1%s, should include technical arcana on screen and have more mutability, perhaps even at the cost of some performance and security. This one could be named after some kind of canid.
> The 99.9% of people who don't even know the difference between www and non-www will never directly benefit from seeing www, ever.
You don't need to know the difference to be able to read the URL off, potentially to someone who does.
It's not impossible (though it's not a good idea) for “example.com” and “www.example.com” to both host web content, and whether or not they know or care about the meaning of the domain name, someone accessing one should be able to, in the event they have a problem, be able to read off which one they are accessing to the person trying to help them resolve the problem.
Let's dumb down the internet even more because non technical users feel confused. Maybe we can actually remove the url field and just let the isp decide where they should go? They could offer a choice of 10 popular sites, like TV channels.. :)
We're always going to need to see URLs. They're not going away. They're just talking about a better default view to show the user relevant information about where they are, which would be a good thing.
Being generous, maybe half of users can look at a URL and immediately identify the domain they are on. That's terrible, and goes a long way to explaining why phishing attacks are so prevalent.
I'm actually pretty excited to see what they come up with. If it's even marginally better than what we have now I'd be all for it. I'm guessing they'll end up showing some combination of the domain and page title by default (which might incentivize more sites to FIX THEIR GODDAM TITLE SCHEMES!).
I can see the future now: User enters his target (mybank) into the Google search bar on his Google Android device, the device opens Google Chrome with the Google amp page form mybank already loaded. The user never has to worry about urls or where exactly he is entering his banking information and login critera. Google makes everything a clean and seamless experience and user never has to leave its warm embrance.
Add eyeball tracking into this mix, and we can "allow" users to "experience" unskippable ads.
In all seriousness, I have no doubt this is due largely to Google's frustration at Ad Blockers. If there is no URL, and you're in the Google Garden protocol, there is no way to block ads, or at least no way to NOT download them.
Great idea! Hey, since these are non-technical users, why don't we just eliminate those pesky hard-to-use computers and just put the whole thing inside their TV? Y'know, kinda like 23 years ago... https://en.wikipedia.org/wiki/MSN_TV
You're missing jwr's point. He's arguing that this is harmful for users, especially the ones who don't know what the words mean.
If I were solving this, I'd instead push to eliminate "www" altogether, not sweep it under the rug. It was useful circa 1996, when users might plausibly be using something other than the WWW with a browser. But it has become entirely vestigial.
It's actually very useful for isolating access to the root of the domain. Say for instance you use a third-party SaaS/CMS to host your website and have other services on other subdomains. If it's hosted on the root of the domain it had more power than if it's on a subdomain.
It's not the same issue at all, in that domains with different suffixes are controlled by different people while foo.com and www.foo.com are controlled by the same people.
If you have an example of somebody who needs to serve different web content for foo.com and www.foo.com, I look forward to seeing it. But I've never seen one, and when I've seen it happen accidentally it's due to idiocy.
> while foo.com and www.foo.com are controlled by the same people
Sometimes. Far from always.
In some environments, `www` may be under an entirely different administrative domain, with lesser authority than the top level domain which is delegating web services to the `www` group by way of creating a dns record and/or adding an http(s) redirect to the parent domain.
Having some string values arbitrarily considered trivial is dangerous.
See:
lbl.gov has address 128.3.41.146
vs
www.lbl.gov has address 35.196.135.136
The root domain points to hosts at the lab. The subdomain has been delegated off to Google.
Either way, www.example.com and example.com can differ in terms of IP address, underlying hardware, actual website content, and probably other things I don’t know. They are different URLs. It seems problematic to assume they are the same.
Not at all. People already assume they are the same. And they have for 20 years. Nobody reasonable serves up different content on the two URLs. Anybody clueful redirects one to the other. The only reason they're separate is that a) the web wasn't dominant when it was introduced, and b) technology of the time made it hard to manage traffic in ways we can now.
The 9th comment is explicitly described as "bad results"; it's about somebody who doesn't have a redirect. So that for me is in the "unreasonable" category.
The 3rd is about pool.ntp.org, which is a random ntp server, and which shouldn't be serving up web content. They did happen to pick www.pool.ntp.org as the URL for the docs on the NTP Pool Project, but if "www" never was a thing, the would have happily picked something else. E.g. poolproject.ntp.org or ntp.org/pool/ would have been fine.
It's due to different groups controlling different parts of the infrastructure, allowing for separation of privilege -- and is the whole reason www even existed to begin with.
Often these separate groups aren't part of the same organization. They're a different organization or contractor paid to maintain a web presence.
Yes, but those are decisions made by whoever controls foo.com. This may not be a good decision by Google, but I don't think they should be held responsible for a decision that was made by whoever controls foo.com.
This may be true for LBL, but it's not necessarily so. They don't serve different content, and I don't see anything running on lbl.gov that couldn't be handled.
These string values are already considered equivalent, which is why Chrome is making this change, and why every reasonable site has one redirect to the other.
I realize it is an important distinction, I'm glad you do as well.
Just as ftp.mysite.com is not mysite.com and mysite.com in not mysite.io and http://mysite.com is not https://mysite.com. You get the point.
They are all different and important in my opinion. Any argument that hiding the "www." part makes it easier for the user is equally applicable (and wrong) to ".com"
You can keep repeating your point, but if you want to convince me, you'll have to actually address my demonstration that the two are in fact not equal in practice.
I'm not arguing for Chrome's implementation. I'm saying we should do the more useful but harder thing of just not using "www" as a thing in browser URLs. They have correctly identified it as redundant, but instead tried to fix it by being too clever.
As I mention elsewhere, the first two are bad examples. (In fact. ntppool.org and www.ntppool.org are the same thing.) The third is a hack from the era where responsive design, browser sniffing, and polyfills didn't exist. It should probably die too, but doesn't have to here. The m.tumblr.com name is distinct from tumblr.com and is of the form I think better. Note that they didn't use www.m.tumblr.com.
With "only" 46.5% of all domains being ".com" I guess you are technically correct. When the next highest TDL (.org) rings in at only 5.1%, I think we can agree the the overwhelming majority of sites are based on .com.
Of the TDL you mention the top one is .jp at less than 2%. If you remove the qualifier under the .uk TLD you get an additional 2%. The rest don't make the chart.
Modern solution to these issues is having SRV record on appropriate protocol sub-domain which AFAIK (and somewhat surprisingly) is honored by most modern browsers.
> If I were solving this, I'd instead push to eliminate "www" altogether, not sweep it under the rug. It was useful circa 1996, when users might plausibly be using something other than the WWW with a browser.
No, it was useful when abstracting machine identity from domain names such that there was a many-to-many relationship was less common, so “www” was the most specific domain name element for the server being accessed. (And a system that needed more than one server might have a homepage on “www”, and various subsites and apps on “www1”, “www2”, etc.)
OTOH, there may be places that still allocate servers that way for simplicity.
Presumably your question is for the Chrome team, and I'm gonna assume the answer is: yes, of course they did research. They did research for the padlock, etc too.
Well, might as well drop then entire stuff after the domain.com/{dump all this out} (the file path) since non-techy people don't really care about it. All they care is about clicking links and navigating...
There thankfully is a setting to show the full url, but yeah, Safari on macOS does that by default. The change occurred around Lion (give or take a major version) if memory serves me well.
Maybe the address bar UI will next hide query string parameters because they are an implementation detail? So Google News would be displayed as "news.google.com" instead of "news.google.com/?hl=en-US&gl=US&ceid=US:en".
From the business point of view that would make perfect sense. The user wont be able to remember the url and even second guess it so that would need the "help" of google, cause everyone knows that "google is your friend".
TBH, so long as there always remains the option to show the full URL, I'd be totally fine with completely hiding it by default. Safari all but does that right now.
99.9% of users don't know either way. The change neither improves nor harms their experience, it merely obfuscates what's actually going on under the guise of "user friendly."
Anytime the "average user" or numbers like "99.9% of users" are mentioned, red lights should go off. These kinds of claims are condescending, often untrue, and rarely based on facts.
You can still click and see the whole URL. This is just making it easier for the average user to see the most important thing to them, which is the domain name.
It's not like they're just changing stuff randomly. The TLS padlock change has been going on for a while now, and not without reason. As we get to a point where almost everything is served over TLS it doesn't make sense to tell the user every time. It makes more sense to only notify them of the exceptional situation where we're on an insecure connection.
The certificate authority system is terrible, but it's what we have for now. There's been some advances to help make it better though. CT for example, ensures that if anyone starts making fake certs we can all see it at least.
I suspect (and hope) that browsers will slowly transition to using trusted spotters to verify certificates in addition to (and eventually instead of) authorities. If you remember a few years back when moxie marlinspike made that promising, but underspecified cert verification system that relied on the user supplying a list of trusted verifiers and the browser basically goes to each of them asking "I see cert 88:A4:etc" for domain "google.com", do you see the same thing? The idea was to make it really hard to MITM someone since you'd also have to MITM every verifier the browser asked. Not impossible, but probably harder than getting a fake cert under our current system.
Clicking doesn't reveal the URL. You have to click and use the left arrow key, at which point the protocol and www prefix appear.
Just like when Chrome hid the protocol part of the URL, you can even click in the URL bar and copy it without seeing the protocol (or, now, www prefix) at all. I think it results in a confusing experience when you paste it. (Ordinary users will say: "I copied example.com but I pasted https://www.example.com … why??)
> You can still click and see the whole URL. This is just making it easier for the average user to see the most important thing to them, which is the domain name.
Thanks for adding a step when that user's most important thing is telling us folks supporting them what the actual URL they went to. From other folks in this thread[1], it isn't as simple as just a click.
> This is just making it easier for the average user to see the most important thing to them, which is the domain name.
It's not like they're just changing stuff randomly.
Can you link to the user study or general cost/benefit analysis or something else saying it's not random? I'm having a hard time concluding that the cost of removing parts of a domain name only in some cases is outweighed by the benefit of removing a few characters from the user's address bar.
> "This is just making it easier for the average user to see the most important thing to them"
This is exactly the wrong way. The domain name system is simple, easy to learn, partly, among other, exactly because it is without ambiguity. It has been an essential part of our lives for several decades by now and users should be expected to undergo the effort of looking into how it works for 5 minutes once in their lifetime. (Arguably, parsing a URL is an important and essential skill nowadays, like adding.) Obscuring it and introducing ambiguity doesn't only not help, it is an essential hinderance to understanding.
How do you verify the authority owns the content? For instance: AMP urls serve content from a different authority than the one that produces the content.
This and many other changes over a course of a short period of time have caused me to go to Firefox exclusively now. I heard Firefox is going to stop third party cookie tracking altogether. Why not give Google the big finger and use a different browser? Vote with your cold hard actions if you feel so strongly about something.
I would love to, but Firefox just feels more clunky. Not sure what it is, but the scrolling doesn't feel native to me (MacOS, Magic Trackpad and Logitech Mouse)
I switched to firefox a year ago. Its a little slower, but im a lot happier.
Ive been trying to degoogle as much as reasonable. I moved to fastmail as well. Still using an android, but would switch if a reasonable alternative that wasnt iphone came up. Im not paranoid or a privacy nut, just think google is too involved in my life.
Same here. Have you found any viable alternative to the Google Calendar? I'm at the point where I'm thinking about hosting a calendar project from GitHub myself.
Nextcloud, whether self-hosted or otherwise, works great! It's just WebDAV. You can get calendar, contacts, task, and note syncing, and it can even host your documents for reference management software like Zotero.
If you own a Samsung phone, the calendar app is good. I wonder if you can install those Samsung apps (which for some are just forks of unmaintained AOSP apps) on a regular Android if you somehow get the apk.
I was in exactly the same camp as you a year ago. Then I played with a hand-me-down iPhone 6s and couldn't believe how much more pleasant it was to use iOS than to use Android (Nougat at the time). Having owned an iPhone 3G and 5, my memories were of a restrictive OS and a dumb Siri but both have really has come along since. I made the switch and can't imagine going back to Android now.
Having to use both for supporting complex web apps, I can't really agree that FF is noticeably slower. Chrome does seem to have less silly bugs though, like quick searching doesn't find multi-select box text in FF. Works great in Chrome.
Regardless of FF's little quirks, I use it almost exclusively for personal stuff. I would rather deal with those types of things than the mentality Chrome brings to table.
Have you tried Searx? Meta search engine, open source, multiple instances (domains) to choose from. Once configured to your particular needs, searx can prove very powerful.
I've been using Edge on Windows for at least a year now and I'm quite happy. Now that it supports plugins, I haven't fired up another browser for months now.
Firefox does similar things though. They hide the URL scheme by default. And subdomain are displayed in a more subtle colour than the rest of the domain.
Firefox hides the scheme IFF it is `http://`. It doesn't hide `https://`. Also the subdomain AND the path is slightly toned down. The net effect is precisely what Google tries to do and Apple has been doing (namely, only showing the second level domain) without actually hiding any information.
Upvoted from Firefox. Only reason I use Chrome nowadays is when apps launch it directly (whereupon I strongly consider uninstalling them) or when work requires it (... which is utterly ridiculous, and very likely why our web rendering performance and consistency is utter trash).
Hangouts and GotoMeeting are the only things I open in Chrome. I'm also completely sold on Tree Style Tabs, and I don't think I could now live without...
I use Firefox as my "at home" / private browser. However for work i unfortunately feel forced to continue using chrome. First I just really prefer the chrome devtools and i just can't seem top find an equivalent replacement for the "manage people"/multi user built ion function that chrome offers. I really wish Firefox had something similar...
the containers are great thanks for sharing, will definitely use those at home! You're right I should have emphasized the feel part of my comment since the dev tools especially are just a matter of preference. However I stand by my point that the profiles are definitely not on par with chrome, since there doesn't seem to be a way to have multiple profiles open at once.
I’m sure there are other ways to do this, including specifying a profile when you initially launch the browser, but you can enter about:profiles in the address bar to see a UI to manage the profile. One of the options is to launch that profile in a new browser.
If you just need a "personal" profile and a "work" profile, what I do as a workaround is to use normal firefox for personal and firefox developer edition for work. They are completely sandboxed from each other.
I'm pretty sure the eventual plan is to force everyone to browse the web using a version of the App Store, which we all know is incredibly secure, and never difficult to use.
Since everyone is wondering why, and since I happened to stumble across a reason during my time as a pentester, here you go:
Spearphishing is still one of the most common ways of breaching a corporate network. If I target you, you will likely fall for one of my attempts. If you are a company rather than a person, my odds go way up, because I have N chances to trick someone rather than 1 (where N is roughly the number of people at the company with email access).
This is one of those things that everyone says "Ha, I'm smart. I'd notice. You can't trick me."
And maybe you are. But you're also distracted. And that's my greatest advantage against you. All I need is to sneak in an unexpected Github prompt that looks completely authentic, and now I have your Github password. Wanna bet you don't have 2FA turned on, even though you know you really ought to? And even if you do, it's getting easier to social engineer your way past AT&T's lovely customer support: https://www.youtube.com/watch?v=caVEiitI2vg
Ok, what's the point?
This: Every character in the URL bar unrelated to the apex name is a deadly distraction.
Right now, how do you know you're actually on HN instead of some knockoff? "ycombinator.com".
How many characters do you have to read unrelated to that? "https://news. /item?id=17927972"
The most vital part of a URL for vetting identity is also, usually, the hardest to see.
Now, I don't know whether google made this change in order to assist with this. But it's one possible justification, and a step in a good direction.
We may not like it, just like we didn't like when Google removed the clickable "cached" links from search results, but in this case consumer protection outweighs our urges as a power user.
I was just looking at the URL bar in firefox and thinking yea, I know it's ycombinator.com because it's right there, and there's a big green lock on the left.
Google can do what they want with Chrome, as far as I'm concerned it's the new IE.
Wasn't this (partially?) solved by making the domain black and the rest of the text gray? That's how it appears in Firefox. It makes it very easy to see "ycombinator.com".
According to the PSL their list is also used for this purpose in Internet Explorer, but not other browsers.
(The Public Suffix List is the Mozilla project that knows .co.uk isn't the same kind of thing as .google.com even though they both have two DNS labels. These days every non-crap browser uses it to restrict cross domain cookies but they aren't consistent when it comes to other features)
Is this specific to a version of Firefox, or an extension?
I'm using Firefox 62.0, and I do not see a difference in color between the domain and the rest of the URL.
(Windows 10, 1080p screen.)
ETA: Holy crap, if I zoom into a screenshot, I can see the difference. My eyes cannot benefit from this feature under normal circumstances, though. Looks like black (#000000) and gray (#807D7D).
I get #9D9D9D on Firefox 61 on Ubuntu (1080p). It is perfectly clear to me.
If you have trouble distinguishing between the grey and black, perhaps file a bug report requesting to slightly lower the saturation of the grey? Or perhaps your browser's theme is using that darker grey?
You may want to check your monitor's brightness/gamma settings. That's a major difference to be invisble, and there's many sites that use light grey on white which are much much closer than this (sadly :( )
Funny that you mention that, i never noticed, but firefox displays "ycombinator.com" in the URL "https://news.ycombinator.com/" in black, while other parts you are talking about are light gray. Seems more reasonable then hiding parts.
if the idea is to protect users so that you don't end up clicking on https://news.ycombinator.com.myhackerdomain.com , you then open the attack of a platform where they offer custom subdomains, and you have
if I make them look the same, and the address will hide the subdomain, it looks like a step backwards in securing the web
now, imagine the actual platform has a payment section, and I create a fake subdomain that looks pretty similar, email you, boom, I get your cc info because I tricked you into entering new cc info (assuming your scenario of someone being distracted)
Only supposed "trivial" subdomains are hidden, such as www. and m.
Anything else is still shown. fake-original.blogger.com will still show up as fake-original.blogger.com because fake-original. isn't a trivial subdomain.
I still think it's a stupid move, though. It's a simplification that is incredibly unnecessary and may be harmful when dealing with the rare site that doesn't treat www.domain.com and domain.com as the same.
Do not hide the relevant info. Nearly every character in the URL is relevant info.
Instead, make the key part stand out, so even a cursory glance catches it instantly. It still allows more careful examination without clicking anywhere, or second-guessing.
Also, detect anomalies like www.google.com.hacked.domain.wtf, and show them in a really contrast way. Both Chrome and FF do this already.
I think Firefox shows normal URLs about right; they could add even more contrast.
> This: Every character in the URL bar unrelated to the apex name is a deadly distraction.
I'm not convinced. When your tools lie you (as this does), you are LESS likely to notice a problem when you're busy. Another way to view this approach is:
> Every character in the URL bar different from the actual URL is a deadly lie.
Distraction is a problem, I totally agree, but other methods like Firefox's color-shading seem to work just fine.
Flag websites that look like phishing URLs - websites that contain domain names of popular websites in their subdomains or other parts of the URI. But initially, don't do anything. it could be harmless. AMP has domain names in the URI, right?
But, as soon as the user starts typing into a text-entry field (especially a password one), you bring a pop-up warning them that this might be a phishing site.
To be clear, the "www" is only missing from the URL that is displayed in the address bar, while the browser is still attempting to resolve and fetch the URL with the "www." So instead of something that would completely break many websites, this is just something that is as confusing as hell for no good reason.
When a website requires "www" to resolve and respond, who in their right mind would want it hidden in the displayed URL?
Why does this matter? Users don't care and its easier to remember/understand that all websites are just "x.com" rather than sometimes being "www.x.com". If you have some server/troubleshooting/network/dev problem with it, the missing info should be moved to developer tools.
This is just removing data that is useless and confusing to 99.9% of users - whats the problem?
Now every single website that wants to support Chrome needs to ensure that https://foo.com is always redirected to https://www.foo.com, or at least works as if it's www. It doesn't matter that most websites already do this, it's not standard, and represents Google breaking standards because they are big enough to do their own thing.
It's just one of the 1000s of papercuts that google is inflicting to keep users from switching web browser.
This is only visually what's displayed in the address bar, similar to how they started dropping http/https from the start of URLs a while back.
While I'd personally disagree with these kind of changes, and I would always prefer it to show the http/https and the www dot, it doesn't actually break things like copy and pasting the URL from the address bar. You still go to www.google.com when you type in www.google.com, it's just trimming away the www dot displayed in the address bar.
I think for the vast majority of non-technical people it's not really going to make even a little bit of difference. If anything it'll make it easier to spot what domain they're on, assuming they're even checking to begin with.
Just updated to see it in action. Seems like a nice improvement for end users. Don't think there is any reason not to do this, other than a nostalgic desire for things to stay the same. Most sites already have a www. to . redirect in place and if you don't its a trivial change.
The obvious difference is that that's higher up in the hierarchy rather than lower in it. www.example.com and example.com are controlled by the same entity; example.com and example.foo may well not be.
> Don't think there is any reason not to do this [...] Most sites already have a www. to . redirect in place
Most. Not all.
The browser is doing something out-of-spec for really no reason at all and it has the chance to break some sites.
www.domain.com and domain.com are never guaranteed to go to the same page. Yes, out of modern convention, they do now, but it's only a convention. Sites are free to break it, and some do, so to make this change is a bad idea.
I'm much more okay with Safari's implementation, because it's significantly more discoverable. Safari also makes it much simpler to disable this behavior altogether, with it earning a place in the settings ... rather than being behind some "flag" that may disappear in some future release.
I'm assuming you can always click to expand and show the full URL.
For a lot of people (devs especially) it would be nice to be able to change an option to see the whole URL at a glance, but for most people it's just a confusing mess they have to look through for the domain name.
Thank you to whomever submitted this. My main annoyance is that when I want to go to a subdomain, I'll typically start typing foo.domain.com, but now the browser sets it to www.foo.domain.com. Annoying.
Let me clarify: since the subdomain is hidden, I now have to munge with the URL input field to just get the full url to show up so that I can then modify the subdomain.
918 comments
[ 5.1 ms ] story [ 431 ms ] threadhttps://www.ampproject.org/
Please submit any complaints you have as a video on YouTube.
I hadn't thought about the amp angle, but that could be another reason for pushing this, too. Perhaps there are more we won't know until it's too late to do anything about it (other than changing browsers, of course).
The spec says that a cookie flagged with the domain "domain.com" is supposed to only be valid for requests to "domain.com" and not "subdomain.domain.com". A cookie that is intended to be valid for all subdomains is supposed to have a preceding dot, like ".domain.com".
Older versions of IE (That may still be in use) will treat "domain.com" cookies like ".domain.com" cookies, allowing malicious.subdomain.domain.com to access cookies only intended for "domain.com".
[0] https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-c...
Browsers are supposed to be as unopinionated as possible since they are browsers, not mediators, and their job is to implement the standards of the web.
https://www.ietf.org/rfc/rfc1738.txt
Safari also won't show "www" until you click on the location bar, but it'll show once you click.
* Chrome encourages you to sign in to the browser with a Google account.
* Firefox's new tab page shows stories and articles from Pocket.
* The news feed shown by default in Edge provides stories from MSN.
No similar argument can be made about disabling "www." It is purely an opinionated decision amounting to "you don't need www" - assuming it's not a bug, of course.
Is there a standard saying how the URL should be displayed in the toolbar?
https://www.aishitei.ru vs https://aishitei.ru vs https://kimiwo.aishitei.ru
I never set up a www cname, but now unless you're paying attention (or actually reading error messages) you might not notice that the reason it failed is because you're not at the domain but on the `www` subdomain. The URL bar doesn't convey this information until you click it and then it shows the full URL.
It's really minor but I also don't see a good reason to do this. All the sites hosted by the company I work for are hosted on `www.` with the intention that it "looks more professional".
Is it really a big deal if you serve the wrong content 1% of the time?
Seriously, trawl through Bugzilla sometime and look how many bugs are closed with the the justification being some variation of "That's how IE does it" or "IE doesn't support that", etc. And then substitute "Chrome" for "IE" later in history once Chrome took over the universe.
Back when they removed the "http:" off of URLs, I used to use a hex editor to turn the kFormatUrlOmitHTTP bit flag off every time I got a new build, so I'd get the URL formatting I wanted, but eventually lost the mental wherewithal to continue the hack every week.
[1] https://github.com/chromium/chromium/blob/3d41e77125f3de8d72...
[2] https://github.com/chromium/chromium/blob/78aae16be65e409075...
That's when you automate it as part of your "set up my environment exactly the way I like it" scripts ;-)
Incidentally I want to figure out how to do this on Linux.
I presume I need debug symbol files, which I can download easily.
How would I do this?
While sure, www seems odd now, it's still a subdomain and we're inching into territory of obscuring things that matter for small gains in end-user perception that aren't _that_ impactful.
I've heard people say "backslash" when they insist on reading out the whole URL with protocol, which I'm pretty sure is the wrong slash, I honestly don't know, but I've never understood why people felt the need to say it at all. Do they type the protocol into the address bar when they visit sites?
oOoO
Pretty similar to 4 average characters, really.
See: http://to. (it redirects to an advertising/malware site for me, so be warned)
https://www.icann.org/news/announcement-2013-08-30-en
Just a guess though.
Don't give them any ideas. They've been moving towards this path for a long time. Full paths being hidden from URLs could be up next.
It seems like the confusion this change causes negates any benefit it could have.
Those tend to be the cases when I care very much.
The users who truly care can just click the URL bar. (Someone said you also have to press the left arrow, which if true seems like a bad decision. I would agree the full URL should always be visible whenever the cursor focus is in the URL bar.)
> How will you distinguish http://www.pool.ntp.org vs http://pool.ntp.org ?
> One takes you to the website about the project, the other goes to a random ntp server.
I come across enough sites were one or the other is broken I'd call it important.
I don't know.
2. Google directs user to www.example.org.
3. User sees url as example.org and notes it down.
4. User needs to visit example.org again, but for some reason it doesn't work.
5. User goes to coworker who shows him that example.org does in fact work (hidden www).
6. Endless confusion ensues.
This is bad UX decision on Google part (on top of it breaking published standards)
Perhaps they should be taught.
Otherwise let's move on to making nuclear reactors less confusing.
Developers and techies are users too and they're much less likely to call tech support in general.
This harms them far more than it helps the people who need help.
https://bugs.chromium.org/p/chromium/issues/detail?id=872665
Say, for example, if the canonical URL doesn't have a "www" in it?
You can write a small script to look up all PSL domains and check if the www and APEX domain has the same dns records.
Our implementation (we control 15 or so) does not, have a www-subdomain for the domains. Anybody can register the www-subdomains.
But hey, now we don't have to see www which has been around forever and is a surprise to no one!
First click gives you a suggested list of URLs and related searches.
Second click gives you the full domain name.
Which is also terrible behavior. Unwanted characters hidden into your paste buffer is at best unexpected and capricious behavior and at worst a source of serious, possibly catastrophic consequences (depending on what, and where, you are pasting).
How soon until a doctored up paste buffer contains, by design, a newline character ? I'm sure there must be some use-case that (appears to) call for this ...
http://www.pool.ntp.org vs http://pool.ntp.org ?
One takes you to the website about the project, the other goes to a random ntp server.
There was a time when IE misbehaved. Not sure if this fixed in Edge: https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-c...
Pretty sure that was fixed in Edge and IE (as a security issue).
So, not similar at all?
http://blogoscoped.com/archive/2010-09-17-n17.html
LE means that the mantra "if it's https then it's a secure and reputable website" is now outdated.
No it didn't. Let's Encrypt made free certificates easier to get, but Let's Encrypt doesn't do less verification than some other CAs/some of their products.
No, it didn't. DV certs never meant that (EV certs did and still do, but LE doesn't offer EV and EV isn't and never was necessary for the padlock.)
Some people assign additional meaning to the padlock, which should not be done. It doesn't mean you are talking to your bank, it only means that you are talking to the website shown in the URL bar and that reasonable (simple) checks were performed to make sure that is the case.
I'd suggest we invent something better before we start breaking it.
Except, those same users also don't care about things in the address bar. So the change hurts the group of users that actually do care.
Why should a user see: https://www.wikipedia.org/wiki/Canada?utm=asdioasd&arg=j210d... when all they care about is "Wikipedia.org/wiki/Canada"?
great work
I mean, why should a user see "Wikipedia.org/wiki/Canada" when all they care about is "This is the Wikipedia Page for Canada"?
Mind you, I’m not suggesting to do away with linking, as some rando suggested this implies. (While chrome doesn’t show the protocol prefix, it still copies the prefix when you copy the url, so imagine a similar ui.) But for most users, wouldn’t a ui that shows “server identity” in some more user-coherent way be what they want?
In particular, do subdomains help or hurt phishing detection?
I think we're a long way away from that ideal, though, and some web pages may not be designed with this ideal in mind.
https://www.example.com
http://example.com
https://example.com
do not have to be the same website and there are cases where it isn't the same site!
Which site you visit does matter and not just for internet banking. If it becomes that easy if we hide things maybe we should hide the half of the traffic lights as well.
Hiding random parts of the address isn't going to make browsing the web better. The main purpose of URLs is for hyperlinks, not as a highly intuitive user interface. Users who don't know how URLs work don't care what is up there. They only care that what they are looking at is what they expect, and a way to get to where they want to go. And that's a complicated problem.
The URL bar hiding thing isn't for users, it's for Google to push Google search. That's why they attempted to remove the URL bar entirely four years ago and replace it with a search bar.
Yet neither company runs a search engine. I don’t suppose it’s possible this is just better for most users?
[1]:https://www.techworld.com/download/internet-tools/firefox-63...
Now you can go to menu -> Customize and drag it where you want.
It's very useful if you don't want to Google internal/client URLs just because you accidentally copied a space at the start or the hostname doesn't resolve in your current environment, etc.
Expecting users to use the URL bar to detect phishing via homoglyphs is insanity.
There's still value to be gained from having easily readable urls.
The browser could even show specialized UI such as "FR" as a clickable dropdown menu to allow users to switch languages. Chrome already does this for searching a single website through the address bar (type domain.com TAB)
Basically these changes are not thought for you. You are not representative of the average Web user.
These aren't decisions for a useragent to make, and there aren't enough browsers out there that people have a reasonable choice.
Bastardising the url isn't a solution to anything, it's a step towards something that Google, not users, want (in making AMP "trivial").
Repeat. This is not sarcasm.
Dark roads ahead, friends.
Hiding it just seems like a trivial UI matter that makes things slightly more obnoxious when you do care.
I'd be surprised if only showing the domain vs domain+path made any difference on phishing results.
I don't think these little tricks do much for the user. For example, browsers now highlight https websites with green in the url bar and show a little lock icon. But how is that actionable information for the user? To what extent does that mean you can trust that website, and how does the average person interpret it? Phishing websites use https, too.
I would avoid stealing any pages from Safari's UI. That browser doesn't even show favicons on browser tabs to let you quickly distinguish them.
The 99.9% of people who don't even know the difference between www and non-www will never directly benefit from seeing www, ever.
One browser should be dead simple, secure, and streamlined, aimed at the 99.9%s. Maybe it could be named after a metal.
Another browser, for the 0.1%s, should include technical arcana on screen and have more mutability, perhaps even at the cost of some performance and security. This one could be named after some kind of canid.
You don't need to know the difference to be able to read the URL off, potentially to someone who does.
It's not impossible (though it's not a good idea) for “example.com” and “www.example.com” to both host web content, and whether or not they know or care about the meaning of the domain name, someone accessing one should be able to, in the event they have a problem, be able to read off which one they are accessing to the person trying to help them resolve the problem.
https://www.wired.com/story/google-wants-to-kill-the-url/
Being generous, maybe half of users can look at a URL and immediately identify the domain they are on. That's terrible, and goes a long way to explaining why phishing attacks are so prevalent.
I'm actually pretty excited to see what they come up with. If it's even marginally better than what we have now I'd be all for it. I'm guessing they'll end up showing some combination of the domain and page title by default (which might incentivize more sites to FIX THEIR GODDAM TITLE SCHEMES!).
I can see the future now: User enters his target (mybank) into the Google search bar on his Google Android device, the device opens Google Chrome with the Google amp page form mybank already loaded. The user never has to worry about urls or where exactly he is entering his banking information and login critera. Google makes everything a clean and seamless experience and user never has to leave its warm embrance.
In all seriousness, I have no doubt this is due largely to Google's frustration at Ad Blockers. If there is no URL, and you're in the Google Garden protocol, there is no way to block ads, or at least no way to NOT download them.
If I were solving this, I'd instead push to eliminate "www" altogether, not sweep it under the rug. It was useful circa 1996, when users might plausibly be using something other than the WWW with a browser. But it has become entirely vestigial.
It is exactly the same issue.
A domain is a domain. Google is arbitrarily dictating your CNAME from the user's perspective.
What if you don't serve your site off of mysite.com is google going to automatically try again at www.mysite.com?
What if you have distinct content at both domains?
This decision is stupid.
If you have an example of somebody who needs to serve different web content for foo.com and www.foo.com, I look forward to seeing it. But I've never seen one, and when I've seen it happen accidentally it's due to idiocy.
Sometimes. Far from always.
In some environments, `www` may be under an entirely different administrative domain, with lesser authority than the top level domain which is delegating web services to the `www` group by way of creating a dns record and/or adding an http(s) redirect to the parent domain.
Having some string values arbitrarily considered trivial is dangerous.
See: lbl.gov has address 128.3.41.146 vs www.lbl.gov has address 35.196.135.136
The root domain points to hosts at the lab. The subdomain has been delegated off to Google.
The third and ninth comments in the linked bug present real world examples of this behavior.
The 3rd is about pool.ntp.org, which is a random ntp server, and which shouldn't be serving up web content. They did happen to pick www.pool.ntp.org as the URL for the docs on the NTP Pool Project, but if "www" never was a thing, the would have happily picked something else. E.g. poolproject.ntp.org or ntp.org/pool/ would have been fine.
Often these separate groups aren't part of the same organization. They're a different organization or contractor paid to maintain a web presence.
These string values are already considered equivalent, which is why Chrome is making this change, and why every reasonable site has one redirect to the other.
Just as ftp.mysite.com is not mysite.com and mysite.com in not mysite.io and http://mysite.com is not https://mysite.com. You get the point.
They are all different and important in my opinion. Any argument that hiding the "www." part makes it easier for the user is equally applicable (and wrong) to ".com"
http://www.ntppool.org is not http://pool.ntp.org
and
https://citibank.com.sg is not https://www.citibank.com.sg
and
https://m.tumblr.com/ is not https://www.tumblr.com/
Yet Google makes them all appear to be the same.
There are lots of other odd filtering behaviors in the issue if you want to check out the comments
For example, should:
www.www.www.subdomain.www.www.www.domain.com show as subdomain.domain.com
How is that right?
How does making those two destinations appear to be the same thing make the user "safer" under any stretch of the imagination?
As I mention elsewhere, the first two are bad examples. (In fact. ntppool.org and www.ntppool.org are the same thing.) The third is a hack from the era where responsive design, browser sniffing, and polyfills didn't exist. It should probably die too, but doesn't have to here. The m.tumblr.com name is distinct from tumblr.com and is of the form I think better. Note that they didn't use www.m.tumblr.com.
This happen fairly often in universities and some other organizations that can have convoluted structure.
Most sites in English, and even that is doubtful.
There's a full world out there of people and businesses using ccTLD like .fr, .nl, .co.uk, .hr, .rs, .es, .jp...
Of the TDL you mention the top one is .jp at less than 2%. If you remove the qualifier under the .uk TLD you get an additional 2%. The rest don't make the chart.
https://www.statista.com/statistics/265677/number-of-interne...
Browsers don't use SRV records for HTTP. With them one wouldn't need www subdomain CNAME hacks.
No, it was useful when abstracting machine identity from domain names such that there was a many-to-many relationship was less common, so “www” was the most specific domain name element for the server being accessed. (And a system that needed more than one server might have a homepage on “www”, and various subsites and apps on “www1”, “www2”, etc.)
OTOH, there may be places that still allocate servers that way for simplicity.
Did you ask anyone? Did you do any research?
/end sarcasm
Should chrome redirect all DuckDuckGo queries to Google.com because 99.9% use Google anyways?
That's why they're getting rid of it.
https://blog.chromium.org/2018/05/evolving-chromes-security-...
https://www.wired.com/2016/11/googles-chrome-hackers-flip-we...
It's not like they're just changing stuff randomly. The TLS padlock change has been going on for a while now, and not without reason. As we get to a point where almost everything is served over TLS it doesn't make sense to tell the user every time. It makes more sense to only notify them of the exceptional situation where we're on an insecure connection.
The certificate authority system is terrible, but it's what we have for now. There's been some advances to help make it better though. CT for example, ensures that if anyone starts making fake certs we can all see it at least.
I suspect (and hope) that browsers will slowly transition to using trusted spotters to verify certificates in addition to (and eventually instead of) authorities. If you remember a few years back when moxie marlinspike made that promising, but underspecified cert verification system that relied on the user supplying a list of trusted verifiers and the browser basically goes to each of them asking "I see cert 88:A4:etc" for domain "google.com", do you see the same thing? The idea was to make it really hard to MITM someone since you'd also have to MITM every verifier the browser asked. Not impossible, but probably harder than getting a fake cert under our current system.
Just like when Chrome hid the protocol part of the URL, you can even click in the URL bar and copy it without seeing the protocol (or, now, www prefix) at all. I think it results in a confusing experience when you paste it. (Ordinary users will say: "I copied example.com but I pasted https://www.example.com … why??)
Thanks for adding a step when that user's most important thing is telling us folks supporting them what the actual URL they went to. From other folks in this thread[1], it isn't as simple as just a click.
1) https://news.ycombinator.com/item?id=17928598
Can you link to the user study or general cost/benefit analysis or something else saying it's not random? I'm having a hard time concluding that the cost of removing parts of a domain name only in some cases is outweighed by the benefit of removing a few characters from the user's address bar.
This is exactly the wrong way. The domain name system is simple, easy to learn, partly, among other, exactly because it is without ambiguity. It has been an essential part of our lives for several decades by now and users should be expected to undergo the effort of looking into how it works for 5 minutes once in their lifetime. (Arguably, parsing a URL is an important and essential skill nowadays, like adding.) Obscuring it and introducing ambiguity doesn't only not help, it is an essential hinderance to understanding.
https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=...
(there's a couple of hits when I search for 'scrolling' in that thread)
Ive been trying to degoogle as much as reasonable. I moved to fastmail as well. Still using an android, but would switch if a reasonable alternative that wasnt iphone came up. Im not paranoid or a privacy nut, just think google is too involved in my life.
Regardless of FF's little quirks, I use it almost exclusively for personal stuff. I would rather deal with those types of things than the mentality Chrome brings to table.
I'm still undecided on which search engine to use though.
https://www.theverge.com/2018/1/4/16805216/google-chrome-onl...
The containers have a great UI/UX. I'm looking at the profile stuff now (after having not in years) and it seems counterintuitive and clunky
https://support.mozilla.org/en-US/kb/profile-manager-create-...
https://support.mozilla.org/en-US/kb/containers
Anyway, "forced" is a strong word when you simply mean "prefer". The firefox dev tools are in the same league as the chrome ones, imo.
For bonus fun, also install Temporary Containers: https://addons.mozilla.org/en-GB/firefox/addon/temporary-con...
So they're doing it again, just slower: https://www.extremetech.com/computing/276454-google-wants-to...
I'm pretty sure the eventual plan is to force everyone to browse the web using a version of the App Store, which we all know is incredibly secure, and never difficult to use.
https://news.ycombinator.com/item?id=17911009
Spearphishing is still one of the most common ways of breaching a corporate network. If I target you, you will likely fall for one of my attempts. If you are a company rather than a person, my odds go way up, because I have N chances to trick someone rather than 1 (where N is roughly the number of people at the company with email access).
This is one of those things that everyone says "Ha, I'm smart. I'd notice. You can't trick me."
And maybe you are. But you're also distracted. And that's my greatest advantage against you. All I need is to sneak in an unexpected Github prompt that looks completely authentic, and now I have your Github password. Wanna bet you don't have 2FA turned on, even though you know you really ought to? And even if you do, it's getting easier to social engineer your way past AT&T's lovely customer support: https://www.youtube.com/watch?v=caVEiitI2vg
Ok, what's the point?
This: Every character in the URL bar unrelated to the apex name is a deadly distraction.
Right now, how do you know you're actually on HN instead of some knockoff? "ycombinator.com".
How many characters do you have to read unrelated to that? "https://news. /item?id=17927972"
The most vital part of a URL for vetting identity is also, usually, the hardest to see.
Now, I don't know whether google made this change in order to assist with this. But it's one possible justification, and a step in a good direction.
We may not like it, just like we didn't like when Google removed the clickable "cached" links from search results, but in this case consumer protection outweighs our urges as a power user.
Google can do what they want with Chrome, as far as I'm concerned it's the new IE.
(The Public Suffix List is the Mozilla project that knows .co.uk isn't the same kind of thing as .google.com even though they both have two DNS labels. These days every non-crap browser uses it to restrict cross domain cookies but they aren't consistent when it comes to other features)
I'm using Firefox 62.0, and I do not see a difference in color between the domain and the rest of the URL.
(Windows 10, 1080p screen.)
ETA: Holy crap, if I zoom into a screenshot, I can see the difference. My eyes cannot benefit from this feature under normal circumstances, though. Looks like black (#000000) and gray (#807D7D).
If you have trouble distinguishing between the grey and black, perhaps file a bug report requesting to slightly lower the saturation of the grey? Or perhaps your browser's theme is using that darker grey?
For starters, it doesn't work for non "www." subdomains, for example... news.ycombinator.com isn't protected by this solution.
A better solution IMHO, would be to do it like firefox, grey it out.
https://original.blogger.com
and then
https://fake-original.blogger.com
if I make them look the same, and the address will hide the subdomain, it looks like a step backwards in securing the web
now, imagine the actual platform has a payment section, and I create a fake subdomain that looks pretty similar, email you, boom, I get your cc info because I tricked you into entering new cc info (assuming your scenario of someone being distracted)
Anything else is still shown. fake-original.blogger.com will still show up as fake-original.blogger.com because fake-original. isn't a trivial subdomain.
I still think it's a stupid move, though. It's a simplification that is incredibly unnecessary and may be harmful when dealing with the rare site that doesn't treat www.domain.com and domain.com as the same.
Try opening
https://opensource.googleblog.com/
https://security.googleblog.com/
Both opensource and security are shown.
Disc: Googler but don't work on this project.
Instead, make the key part stand out, so even a cursory glance catches it instantly. It still allows more careful examination without clicking anywhere, or second-guessing.
Also, detect anomalies like www.google.com.hacked.domain.wtf, and show them in a really contrast way. Both Chrome and FF do this already.
I think Firefox shows normal URLs about right; they could add even more contrast.
I'm not convinced. When your tools lie you (as this does), you are LESS likely to notice a problem when you're busy. Another way to view this approach is:
> Every character in the URL bar different from the actual URL is a deadly lie.
Distraction is a problem, I totally agree, but other methods like Firefox's color-shading seem to work just fine.
Flag websites that look like phishing URLs - websites that contain domain names of popular websites in their subdomains or other parts of the URI. But initially, don't do anything. it could be harmless. AMP has domain names in the URI, right?
But, as soon as the user starts typing into a text-entry field (especially a password one), you bring a pop-up warning them that this might be a phishing site.
https://www.wired.com/story/google-wants-to-kill-the-url/
WTF? People get angry when you just move their cheese without notice.
Sorry, unrelated, but ahah, what is this saying? I love it and have never heard it before. I guess it's from some sort of book? https://hbswk.hbs.edu/item/cheese-moving-effecting-change-ra...
https://www.quora.com/What-exactly-does-who-moved-my-cheese-...
When a website requires "www" to resolve and respond, who in their right mind would want it hidden in the displayed URL?
This is just removing data that is useless and confusing to 99.9% of users - whats the problem?
What happens when you copy and paste that URL?
Now every single website that wants to support Chrome needs to ensure that https://foo.com is always redirected to https://www.foo.com, or at least works as if it's www. It doesn't matter that most websites already do this, it's not standard, and represents Google breaking standards because they are big enough to do their own thing.
It's just one of the 1000s of papercuts that google is inflicting to keep users from switching web browser.
While I'd personally disagree with these kind of changes, and I would always prefer it to show the http/https and the www dot, it doesn't actually break things like copy and pasting the URL from the address bar. You still go to www.google.com when you type in www.google.com, it's just trimming away the www dot displayed in the address bar.
I think for the vast majority of non-technical people it's not really going to make even a little bit of difference. If anything it'll make it easier to spot what domain they're on, assuming they're even checking to begin with.
Most. Not all.
The browser is doing something out-of-spec for really no reason at all and it has the chance to break some sites.
www.domain.com and domain.com are never guaranteed to go to the same page. Yes, out of modern convention, they do now, but it's only a convention. Sites are free to break it, and some do, so to make this change is a bad idea.
The "trivial subdomain" will show when you click the url bar, however.
I'm assuming you can always click to expand and show the full URL.
For a lot of people (devs especially) it would be nice to be able to change an option to see the whole URL at a glance, but for most people it's just a confusing mess they have to look through for the domain name.