“We plan to hide ‘https’ scheme and subdomain ‘www’ in Chrome omnibox in M76”
bugs.chromium.org
bugs.chromium.org
Seriously speaking: If browsers are simplifying the URI scheme for the alleged benefit of users, how do we expect these users to know anything about addresses? Isn't this rather undermining security than enhancing it? Highlighting significant parts may be preferable to hiding those deemed insignificant. Moreover, regarding https, I personally prefer positive affirmation over lack of warning.
For me, this worked best for desktop browsers with the padlock icon (and, before this, the key icon) shown together with a display of link targets in a status bar as a separate, reserved area. (While allowing pages to overwrite `window.status` was certainly not a good idea.) A consistent display of the authority issuing the certificate of the current page in a status bar like this may be also nice. I'm not convinced that less but more opaque information is the way to go.
Dedicating 20 vertical pixels of virtual real estate to security relevant information may be worth it. It may be also easier to parse than an overloaded omnnibox/location/search/navigation/security/menu bar. Cutting down any information which is displayed too densely right from the beginning won't help the issue. How many bits of information are there in this "everything bar"? Yes, there's still a bit of grouping left, mainly by spacing, but color is mostly gone as a signal in order to make the information density bearable. So users will be applying quite an amount of selectivity when parsing this display, by this inevitably missing relevant information. (That this densely combined display is rather homogenous both for esthetics and acceptance just aggravates the need for selective parsing, which is likely to become a habit.) "We'll pre-filter this for you" isn't addressing the problem, it's rather "living with the outcome".
Edit: A legitimate reason for redacting the host name are extensive names, crafted to exceed the space available in the location display in order to deceive users regarding the identity of the host. Here, abbreviating by an ellipsis (compare text-overflow: ellipsis) in order to fully display the domain may be a way to go.
--
P.S.: What's the general lesson taught by such redactions by the browser vendor? That it is OK to ignore these things, as they are truly irrelevant? (Must be without significance, since Google told me so?)
You're right! Google and Cloudflare are already jointly destroying the meaning of URLs through their "AMP real URLs" specification which allows any AMP gateway to impersonate a host, guaranteeing authenticity of the content through public-key cryptography.
https://blog.cloudflare.com/announcing-amp-real-url/
These changes to the fundamental bricks of the web are not without consequences. They are deliberate attacks on a free and neutral network of equal peers.
Or, from another perspective, they’re pushing for a URL shown in a navigation bar to represent the origin of a document, rather than where you attained it from. (Which is already true of SOCKS and HTTP CONNECT proxies, of course.)
Personally, I’m for that change, because if it becomes a predictable part of clients, formats will emerge to attach signed origins to more document types (e.g. images; PDFs) and then people won’t be able to do easily lose the source of these documents. Imagine Wikipedia being able to automatically cite the “original origin” of anything you link!
Very good points, but the devil lies in the details. Preserving authenticity of web content through public-key cryptography is of course a welcome change. But HTTPS is for encryption from the client to the server (Transport Layer Security). So browser UIs were designed so a lock next to a URL meant you securely connected to the host of the URL. That's what we've been teaching people browsing the web for more than a decade.
Subverting the meaning of URL bars and HTTPS indicators to make Google's control over the web less visible to the end user is of course a very politically-motivated choice and is yet another direct attack on the web as we know it to promote corporate interests. I would be all in favor of adding cryptographically-enforced authorship information in browser UIs, but would rather add a clickable "person" icon next to the HTTPS lock.
So in the end you would end up with visual indication that a secure connection was established to the Google AMP gateway (or whatever website) and that this website is sharing content that provably originated from somewhere/someone; you would just have to click the button to figure it out (just like for TLS connection details).
Also, if authentication of content is a concern or interest of yours, maybe content-addressable systems such as IPFS/DAT (among others) could interest you.
> formats will emerge to attach signed origins to more document types (e.g. images; PDFs) and then people won’t be able to do easily lose the source of these documents.
There are already standards for doing precisely this on the web. ActivityStreams with Linked Data Signatures comes to mind, for example. But these corporations have no interest whatsoever in building an open and federated web.
We're talking about Google. The company who, for example (among many other scandals) stopped federating their XMPP server (GTalk). From the switch of the button, they consciously chose to prevent millions of people who were previously chatting just fine to do just that. If that's not a manifestation of evil corporate power, i don't know what is.
That's just not the way Google is headed.
Well clearly Google expect people not to. They expect people to "Google" for whatever they want.
Imagine a world where 99% of users do not have any concept of URLs or any other fundamental WWW concepts. Instead, they open Chrome type whatever they want and get the results. It is not difficult to imagine a world where the non-tech users do not think of google as search engine but as internet in itself.
What chrome did by training users to enter their searches in the address bar (via the default tab’s fake google search box which moves the cursor to the URL field) was stupid, expensive, and probably undermines Google’s ability to be a destination web site in the long term.
At this point, the overwhelming number of devices are not Google’s. There is no reason to think that in the future they will be. After this anti trust stuff their influence over android may be even less than it is now.
Sadly then Android will probably falter. As much as things are a shitshow, the unified app ecosystem is a big deal to allow competition for smartphones themselves which allows users to switch without getting burnt on app costs. Otherwise corporations are all about vendor lockin and fucking over the consumer for short term gain because greed is king these days.
Someone should fund a "cash back for not using google" browser extension.
They've introduced mouse support (in 2019 no less), but even then it's disabled by default and buried in the Accessibility settings menu.
While I'm not a fan of obscuring what a URL is actually doing, this already is happening with headers.
But this is news because it's Google.
Apple does this and it's a "feature".
Marketing is a dangerous tool.
Edit: come to think of it, a keyword in Japanese is easier to remember/type than an url in latin characters. Sure, now there's IDN in domains and TLDs, but that wasn't a thing until relatively recently, and that's still harder to remember/type than keywords.
i.e. instead of a poster telling you to go to "https://news.ycombinator.com" it might say
Search: Hacker News
I get the discussion about Google changing the web to something that pleases their pockets over everything else, but I am not so sure whether that's the actual motivation in this case. Non-technical users can't do a lot with the rest of the URL anyway and even I as a technical user didn't mind Safari hiding the path and scheme up to now.
Granted, they revoked his cert after he published, but it goes to show how easy it would be to fake an EV cert and have safari users have no idea.
I'm just blown away that Apple hasn't reverted this. Imo it's a huge vuln.
I know it's fashionable to hate Google right now, but this reaction seems a little over the top.
Who uses Safari? People depend on Chrome on all sorts of platforms. Screwing with the URL field affects millions of people.
On a more generally level, I think, it's probably more about amplification vs augmentation, the kind of human-computer symbiosis, what this dialog really is. (Actually, I do prefer Licklider over Engelbart.) Take for example a middle-aged worker in India, who has now one of those new, cheap, not-that-smart phones on a $2/month mobile plan. S/he connects to streaming services via voice search and communicates by the press of a single button. For the first time in her/his life, s/he's able to reach out on her/his own. This is certainly empowering. There's much to be said in favor of such interfaces on devices like this.
However, Licklider's vision of a human-computer symbiosis was of a completely different nature, of partners in cooperation on equal levels. This was not about amplification in this sense, it was about mutual comprehension and directing work flows, with the later heavily depending on the former. This is the desktop environment. Here, simple amplification models are ultimately doing more harm as they may be convenient.
Now, where are the growing markets, what should a company care about? However, this may be a question and an answer too simple. When will our Indian worker gain access to a laptop? The answer may be quite well, "never". Is this still the same market, the same product, the same network?
Maybe in the future we’ll have 2 different apps with a UI optimized for each usage, ie Chrome for Apps and Chrome for web, even if the rendering is the same.
I think the point is that Google doesn't want users to be able to parse this much information. Keep the people dumb, if you want to call it that way. Or uninformed, uneducated, whatever.
"Enter whatever you want to know or see in this field and we will do some magic so you get what you want".
That's where they want to go, no doubt about it as Google probably profits the most from technically-uneducated users of its services.
What I am trying to point at is the vast number of users born after 1990 that have a decent basic understanding of these technologies. And within that generation, the portion that has a similar deep understanding to 1990s users is a population which by absolute size is several orders of magnitude larger what it was in the 1990s. And it is going to keep increasing.
> the proportion of technically litterate users will go up over time not down.
I take the proportion to mean "out of all internet/computer users". That has gone down. And that's the proportion that I think matters as it's what dictates the direction internet/computer technologies go. The proportion is going down, precisely because more people are using these technologies and the majority are not willing to learn as much.
arguably the web is the legacy thing for places that dont have apps, and native apps are mostly what they are familiar with.
See also the classical 2013 rant on the topic: http://www.coding2learn.org/blog/2013/07/29/kids-cant-use-co....
This has always driven me bonkers about the ProofPoint URL-obfuscation 'security'. My work started enforcing this recently, and it drives me crazy:
1. rather than training you to think more carefully about links in e-mails, it trains you to click blindly, because the software says it's safe;
2. it obscures the target of the URL, so that a URL that even a novice would recognise as fishy becomes a garbled string like any other—here's an example (but safe) mangled URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__escholarship.org_content_qt5dj9b74w_qt5dj9b74w.pdf&d=DwIC-g&c=7Q-FWLBTAxn3T_E3HWrzGYJrC4RvUoWDrzTlitGRH_A&r=fDFfg5N-sxMSxbW3hS6WsQ&m=giTLUqirmM6FZGAOLKIp-AHow2YDDWYuGHGz6jjxykY&s=FhP_G8aKAp6QmXR9rR0Pl8L5Z5_XlDPql2uQqmKhDxM&e=
Phishing is definitely possible inside your email org, anything from a malicious browser extension to desktop malware might be geared to send bad links to all users (or a subset) within the logged-in Gmail/Outlook directories.
But ya, that sounds like some pretty bad anti-phishing software. Sounds like vendor lock-in more than anything, especially if it's replacing the email links on the mail server itself.
What are the chances it just runs the domain through Google safe browsing? :P
That it drives traffic to their search engine and increases their revenue. A lot of people always use a search engine to navigate to sites anyway, even if it's a site they've been to many times before and even if the URI is as simple as https://somecompany.com.
Personally, I always want to see the full URI.
I guess they are meant to color up speech / break monotony, but it gets irritating when metaphors are overused and nobody just says "battery", so in the end, just using the boring regular word feels more refreshing. Similarly for articles that keep overuse words like "whopping" instead of usual formal words (to appear more friendly, I guess), or infallibly say "invest" for everything rather than just "buy".
Empirically (I've done the comparison), desktop browser UIs have been growing in vertical screen occupation since Netscape Navigator 2 quite continuously, including the most recent versions, while reducing the amount of information and control provided by the interface. (That is, tabs introduced a new demand of some legitimacy. – However, another vertically stacked horizontal bar isn't the single imaginable solution to the problem. Previously, there had been sidebars with extracted link lists, we can do it for bookmarks and reading lists… We're even better at scanning vertical lists. There's quite some dogma involved. Arguably, a horizontal tab list shouldn't exceed 5 items.)
. / - _ (dot, slash, dash, underscore) all mean very specific things, and different things in different context (period specifically), and if you dont have their meanings memorized and what order to read things in, (right to left from the tld, pausing at each period, then left to right from the first slash, pausing at each slash) then URLs look like illegible nonsense.
Users are able to parse post addresses and apply specific meaning and rules to the various parts. (Compared to URIs post adddresses are exceptionally messy und full of edge cases and exceptions.) Before mobile, users have been able to identify phone numbers by country, region, city and district. Where is the crucial difference? Isn't just because they are told it does 't matter and they won't understand anyway!
Here's an experiment: walk down any street in the US. Actually, scratch that, because there's a good chance that you live in SF or Seattle and your streets are filled with computer programmers.
Call a random number in a random area code. Ask them what the difference between HTTP and HTTPS is.
The users already don't know.
Do you have a plan to educate even 90% of users? That would be a dream come true, but that still leaves a gaping hole of 10%. I would guess 90% of programmers could explain the difference between HTTP and HTTPS (the other 10% being the dreadfully incompetent).
Right now I'm guessing we're at 5% or so and no amount of wanting that to not be true will change that.
No, but I could easily create one if I was paid to put my mind to it. Just as a hobby, I already educate peers about how a lot of the internet and web and technology work anyway.
I don't really have a desire to add to my life the stress of dealing with the terrible decisions, past and present, of "modern" UI driven almost completely by shady marketing tactics encouraged and often forced by business. I certainly don't have the desire to do so without compensation to offset that stress.
Users already don't know anything about addresses. Even security professionals botch the "look at some visual indicator of connection security" all the time (see SSLStrip). As a security feature the URL bar is almost entirely useless for the huge majority of users.
URL bars also don't really tell you where your content is coming from. Iframes don't have URL bars. All that javascript downloaded from somewhere when the page loaded doesn't have a URL bar. The web isn't made of uniquely identifiable documents anymore.
- current situation: http is normal, https with bad certificate is bad, https with good certificate is good
- future situation: http is bad, https with bad certificate is bad/acceptable, https with good certificate is normal
i.e instead of telling people to check for the padlock icon and the green name that should be everywhere, tell people to check for the red warning that indicates a problem. I think it's lifting the expectation to something more secure by default.
Understanding the basics of a secure connection and what possible consequences are is part of liability and being of sound mind. Teach them first, what it is and why it matters, to never engage in a critical communication without a verified secure connection as indicated by this and that signal. Facilitate users in asserting the mode of their electronic interactions. Then put an additional warning line on. But never replace the former by the latter. There is no "easy mode" when it comes to your livelihood.
And, if users are able to grasp these basics (and sure they are – heck, not that long ago drivers had to understand and to be able to describe the workings of a car engine and transmission in order to pass a drivers test), understanding why a basic connection has become unbearable, shouldn't be much of a problem.
Edit: E.g., have a dedicated status bar, displaying to whom the certificate was issued by what CA and what the security level (level of identification) is, possibly color coded. (Your bank must have a red certificate issued on its name, otherwise, run.) Prefetch certificates for links and display them side by side with the link target in said status bar, etc,...
What we are working towards is the thing users had been assuming was true all along, that when they visit google.com that's google.com, else why would it say so? They are astonished to learn that Tim's toy hypermedia system didn't do that and we're only fixing it now in the 21st century.
Whereas you're talking about the sort of imaginary world where everybody begins a novel by perusing the copyright notice just inside the cover, to discern whether they are in fact permitted to read further.
Users aren't going to try to figure out what your "dedicated status bar" means, they'll be annoyed that they can't switch it off since it wastes space with things they don't care about and then they'll just stop seeing it, the way they don't really see those channel ID logos (DOGs) on a modern TV channel.
Your "prefetching" idea is not only terrible for privacy it also doesn't actually do what you probably expect it does, because web pages are too complicated and have been for decades, for this to be effective. In practice because there are so many HTTP transactions _only_ the checks the software can do automatically are worth anything, any time you start talking about how a user should be examining certificate details you're talking about an idea that can't actually work.
We gave all the information to users already, they didn't know what to do with it.
> Just establishing "any TLS" as the new normal doesn't especially help in a world, where you get a certificate for free with a new domain.
Establishing non-TLS as insecure is the end goal.
> possibly color coded. (Your bank must have a red certificate issued on its name, otherwise, run.) Prefetch certificates for links and display them side by side with the link target in said status bar, etc,...
Colors mean different things in cultures and have to be manually learned. Due to frequently broken TLS configurations and similar users will ignore the warnings as well. I really really don't think warnings help, either a fail-shut behavior is enforced (with annoying bypasses) or it might as well not exist.
That all you need is keywords and a good search engine. Platform companies hate URLs because they enable interoperability.
they will replace the domain with google.com, and it already started
It's how Google has approached most things lately. "Oh yeah, we're removing this API for user security. No, it has nothing to do with the same move killing ad-blockers in one blow, why do you ask?! And we're very offended you even think we'd do it for that reason! We'd never..."
You've accurately assessed the current state of affairs. The current average user knows essentially nothing about addresses. They might have a vague sense that domain matters, but that's about it.
Displaying more information that they do not understand does not enhance the security of the average user. Displaying more information useful to the exceptional user (i.e., us) has to be weighted the degree to which it leads average users to a learned helplessness reaction.
(My go to example is the level of understanding required to operate a kitchen and to prepare a meal, which is surprisingly high, but not worth even mentioning. Users do understand the difference of a spoon and a knife, as long as they understand the relevance of this to them. They are even able to operate an oven and to deviate from complex recipes in creative ways, while finding and managing all kind of equipment and managing time critical work flows. Is a similar operational understanding of what may be the most important technology of our time really asking too much?)
In my opinion, what's changed is that someone won the political battle between "URIs are so simple and well-defined! Everyone understands them." and "Users don't understand URIs" camps.
With that said, it's perhaps worth considering that most users might regard computers as essentially magical and fundamentally incomprehensible things. In such a context, could it be possible that it might actually be too much to ask for your average user to have a good operational understanding of something that seems to them to be fundamentally incomprehensible? A great many people have already learned helplessness in the face of technology. Could it be that decades of exposing people to the elegant simplicity of URLs has not created widespread operational comprehension?
(What's the alternative? Just stumble into the pits the dogma didn't provide for? If I'm hurt, it's the will of the Web? – "Nexus vult", as the web-fathers put it?)
I strongly suspect that this (and the eventual goal of making the whole web hosted by Google) is actually the rationale behind the decision.
Previous discussion: https://news.ycombinator.com/item?id=17927972
Also, training the user to treat the URL as text, so that you search for domains (type "amazon" instead of "amazon.com"), is better for them. The "URL" bar is for Chrome also a search bar (and every domain you enter is sent to Google "for search suggestions").
Let's assume that you have a blog platform offering subdomains for each user and 'm.blogplatform.com' is available. Now, any user can get that subdomain and impersonate the homepage because Emily from Chromium decided that eliding parts of the URL without any spec is a reasonable decision.
https://m.tumblr.com/ != https://tumblr.com
When they initially decided to hide the "m" subdomain, https://m.tumblr.com/ was shwon as tumblr.com.
It's not the only website with that issue.
Hiding "www" seems less meaningful. I'm not really sure what the motivation is there, beyond the fact that the "www" prefix is mostly just aesthetics. My best guess is they want the url to start with "google.com" instead of "www.google.com", except that's not helpful from a security standpoint at all and might be slightly detrimental, if it trains people that the very first word they encounter is the most important, as paypal.whatever.com is not in fact paypal. But a lot of domains already elide the "www" anyway.
Of course, in both cases I am assuming that putting focus on the URL bar will display the full URL.
It won't. From the issue tracker: "The full URL is also revealed by clicking twice in the URL bar on desktop," in other words, merely focusing the URL bar won't be enough.
http://manchester.gov.uk -> https://manchester.gov.uk which gives me a bad tls cert error
Also, we love change as long as we are the ones doing it. All other changes are bad.
We == developers
This part is puzzling though:
> The full URL is also revealed by clicking twice in the URL bar on desktop, and once on mobile.
Twice? I can't picture how that will work as a UI. What happens after the first click?
It seems reasonable to me. I get the hate for FAANG, but some people just lose their minds.
tiny padlock
ok
It is a change made by Google and it also dares try to simplify things for non tech savvy users so it has to be evil !
Whether this is a real concern for usual end users no I don't think so. It's mostly more annoying for the HN crowd who need to see it for development or are very security sensitive.
If we remove meta data like this from everyday browsing maybe it will be harder for people to even grasp the idea of how domain names work?
Essentially Google know more about the state of a website than a user can learn from the domain alone, and they should display that to the user. Once that's happening the various parts of the domain are less important. The downside of this is that it increases Chrome users reliance on Google.
Paypal has good SEO, but not every shopping cart does, and its not like Google are manually vetting the content like AOL keywords did...
I'm not in a position to actually do it though, and Google are (for themselves, without sharing the API), so for now that's the best we've got. Maybe someone who has the resources to compete with Google will step up.
and how is a user supposed to know who to trust for this information, if there are multiple sources?
At the root, the problem is one of verification - that who you are communicating with is who they claim to be. At some level, there needs to be trust in one entity as a definitive source (that the site you're looking at is indeed created by the business that the site is claiming to be representing). There has to be some level of trust somewhere...
They could choose the provider they trust most. Which, for the majority, would probably be Google.
Certificates weren't expensive before Let's Encrypt, several outfits offered free certificates, especially on a "trial" basis that would be adequate for criminals even if it was largely useless to legitimate users.
But expensive certificate were, and still are, available to those with the Apple mindset. DigiCert will sell you a certificate for $218. Lasts 12 months.
And you're probably thinking: Right, that's a _proper_ certificate, that'll assure me of who bought it, and it comes with true security and all this amazing stuff. Nope, that's the same DV assurance that Let's Encrypt gives away, except DigiCert gets $218 of your money, and why not?
If there's a guy wants to buy one glass of water from me for $100 who am I to insist drinking water is free?
Anyway, no, certificates did not require "proof of identity" prior to Let's Encrypt, in fact back then they only required that the CA use "Any other method" a term of art in the rules that meant the CA could use its own best judgement (perhaps clouded by commercial considerations) to decide what was enough to be sure you controlled example.com before issuing you an example.com certificate.
_After_ Let's Encrypt, and with substantial input _from_ key Let's Encrypt people this was reformed to the Ten Blessed Methods (there are not actually ten of them today, but I like that name and it seems to have stuck) in which there are explicit methods defined for how a CA must check that you control the DNS names you want certificates for.
You are living in an all too common fantasy world. A world where you needlessly spend more money to achieve less security because you don't want to be confronted with facts.
Who's the "they" in that sentence? As it stands, a certificate reseller knows that the Paypal account "some.name.here@gmail.com" paid for a SSL certificate for "www.unrelatedcompany.TLD"
The certificate itself tells you nothing about who paid for it - it doesn't even tell you which email account was used to confirm some level of association with the unrelatedcompany.TLD domain.
Paypal.com vs random-Name.com: much easier to distinguish.
> We've worked with other browser representatives to incorporate URL display guidance into the web URL standard (https://url.spec.whatwg.org/#url-rendering-simplification). The URL spec documents that browsers may simplify the URL by omitting irrelevant subdomains and schemes in security-sensitive surfaces like the omnibox.
Google is trying to make this obfuscation a standard.
The Chrome team is almost incapable of reversing course on their decisions. Even when they get massive pushback and enough negative press to effectively force them to reverse course, it's only ever temporary.
"Widespread criticism over a decision? That just means people aren't ready yet, or they're too emotional to think clearly about our position. Give it a couple of months to a year, and they'll all have calmed down enough to realize we're right."
"People are complaining about breaking standards? It's not that our decision was wrong, people are just upset we didn't check all the right boxes and fill out all the right forms before we made it. It's not real criticism, it's just people being legalistic about the standards process. Fine, we'll play that game."
And then they wonder why people automatically assume the worst whenever Chrome devs propose something new.
Breaking that cycle requires putting effort into understanding both sides and going beyond quick comments.
One side can't put in all of the work, or we'll end up in the same exact situation within another year.
I've seen the conversation around Chrome degrade dramatically even over the past year or two. Back when Chrome accidentally broke web audio, the community was putting a lot of time into brainstorming possible solutions. You had authors behind some of the biggest games and platforms on the web trying to be constructive.
More recently with the V3 manifest, actual adblock developers from the most popular extensions on the store have weighed in, written performance tests, and shared thoughts. But they've been less willing to go out of their way to assume the best of the Chrome team than game developers were in 2018.
There's a very visible degradation of trust, and an assumption that there's no point in engaging constructively with Google because Google just does not respond to criticism.
Back in 2018, I myself wrote up a massive blog post[0] going over the problems with Google's Web Audio changes. I was careful to assume the best of maintainers, that they really did have the best interest of the web in mind, and that they really were trying to make something great. However, I pointed out:
> These mistakes create a narrative undercurrent that will undermine Google's future efforts to get developers to trust them when they're forced to make difficult decisions... Given enough examples of Google dismissing concerns about its pet projects, the public will simply stop believing that the company cares.
So now in 2019, I'm not going to write a massive blog post going into extensive detail about why obfuscating URLs is a bad idea, because I've fallen victim to the same thought pattern I warned about above. I don't believe that Google cares, and I have better uses of my time.
Why should I waste my time writing this stuff, when I know it's not going to make a difference, and when I know Google is just going to do whatever they want anyway? Why should someone like Gorhill waste their time building detailed breakdowns of an extension API, if there's no chance of getting that API decision reversed?
None of this just arbitrarily happened -- even two or three years ago, developers used to engage with the Chrome team with a lot more patience and a lot more good faith. There are still a lot of members of the community that aren't polarized, they're just tired. And if there was any evidence that Chrome developers were willing to listen to people like Gorhill or Ashley, those people would still be willing to step up.
I think not doing your homework is fine (I am often lazy about this) but it should be combined with open-mindedness and acknowledging uncertainty.
Yes. It’s security sensitive. Any incorrect or misleading information placed here can trick a user proceeding with actions they otherwise would not.
So we should let the URL-bar present the unmangled URL and nothing else.
For TLS you need to look for the presence of a single character. For most people, "http://" and "https://" are both gibberish and remembering which one is good is not obvious. For domain names you now need to look past all of the subdomains since mybank.evil.com isn't safe. But don't look all the way to the right since that is usually full of gibberish and everything after the "/" isn't trustworthy either. Oh and watch out for homoglyphs too.
URLs suck for security.
Also I bet you are upset that port numbers aren't included in the displayed URL too.
(Read "less clear" as a synonym for "misleading".)
Imagine if the URL bar showed the full set of HTTP headers instead. That's more information, and it's more accurate and less mangled than showing just the URL. But it's a much worse interface and harder to use securely.
* New stuff comes out -> niche
* Some smart people want to simplify it, but theres too “magic”, and fades away
* General public learns about the underlying tech or at least structure
* Big adoption happens as people trust it
* Some people want to make it “magic”/simple again, but therefore creating a black box Forward a few years, and the industry seems inaccessible for a long time
* people figure out again how things work
Medical, construction, tech, space, movies.. almost everything has this pattern
Compare with how email headers work in gmail. You don't see email addresses anymore by default, but there's a dropdown that shows them.
It's a really bad feature. If you have contacts with multiple e-mail addresses on different domains, it takes effort to ensure it's going to the right one.
A+, do love, great UX (for me)
You have to press edit for it to put the address back into the input field
Yes they receive money for having google.com as the default homepage if I remember correctly. The way you worded it makes it sound like Google controls them.
https://www.zdnet.com/article/chrome-69-kills-off-www-in-url...
"In Chrome M69, we rolled out a change to hide special-case subdomains “www” and “m” in the Chrome omnibox. After receiving community feedback about these changes, we have decided to roll back these changes in M69 on Chrome for Desktop and Android."
I don't think there's any going back this time around...
#omnibox-ui-hide-steady-state-url-scheme / #omnibox-ui-hide-steady-state-url-trivial-subdomains / #omnibox-ui-hide-steady-state-url-path-query-and-ref / #omnibox-ui-one-click-unelide
Forgive me for being skeptical.
To be fair, Google has previously experimented with hiding the entire path part of the URL, which does hinder URL-based navigation by making the displayed text unusable as a URL. However, that's different from this change, where typing the displayed text into a browser's URL bar would normally get you to the same page (unless the site is configured strangely).
How? If the users are supposed to learn "what the URL consists of", how removing and hiding all but one piece of it helps?
It's like saying, "to make postal addresses easier to understand, we'll hide everything except the recipient's name and surname".
I would support making HTTPS the default when a URL fragment is entered without an explicit scheme, and site operators should just drop the obsolete www domain name prefix. However, the browser should not be masking the full name of the site you're visiting. At the very least it should verify that www.example.com and example.com resolve to the same IP address(es) and use the same TLS certificate before presenting them as equivalent, though that still doesn't guarantee that they have the same content.
I thought I'd be able to find a counter-example where the two forms of URL get handled differently - perhaps by redirecting the bare URL to "m" but still serving the desktop version on "www" - but a quick survey of whatever sites happen to be open in my browser right now says nobody does that.
From a tech literacy standpoint I still dislike the obfuscation, but /shrug.
That said, I dislike the default behavior of hiding the entire path until you click, as opposed to just the URL scheme.
Many tech people don't seem to care about Google and the Chrome monopoly
Maybe it was the same in the 90s, but the only tech people I knew were on usenet and slashdot, and thus it only seemed everyone was against Microsoft's behaviour.
Either way, we know how bad that behaviour was
That chrome can become shit in the future is not to be discussed...
In a way, with your browser choice you're effectively voting for the internet you want in the future.
If that's Chrome and, despite the practical benefits of using Firefox, you trust Google above Mozilla to work in your best interests, then use Chrome.
- Better fingerprinting resistance (AFAIK Firefox is the only browser currently uplifting Tor features).
- Tab containers. They're still reliant on extensions, but get past that and they're incredibly handy, even if you don't care about privacy at all. Tab containers allow you to have multiple different sessions running at the same time without switching profiles, so you can be logged into sites with multiple accounts at the same time. If you've ever used private browsing just so you can log into something twice, tab containers let you do that faster and more flexibly.
- Built-in screenshots. Yes, your OS already has this, but Firefox's screenshot tool is integrated into the DOM, so it lets you select a DOM container to screenshot, or screenshot the entire page, even if it's not all visible. It's a tiny feature that I regularly use, and I appreciate not needing to install another extension to get it.
- Better SVG performance. There are some parts of the browser rendering process that Firefox just does better than Chrome. There are some things it does worse, but my (subjective) experience has been Firefox is usually faster than Chrome at non-JS heavy tasks like browser repaints. Chrome is investing heavily into JS right now, Firefox is investing heavily into repaint/CSS performance.
- Keeping with that theme, Firefox dev tools have a bit of an edge when it comes to HTML/CSS editing (better rulers, font selection, Flexbox/Grid editing, stuff like that). Chrome dev tools are still better if you're doing heavy Javascript editing, but I prefer to debug CSS and do page layout in Firefox.
- Better defaults on small features like autoplay-blocking. Chrome allows videos on inter-site navigation to autoplay, Firefox doesn't. Chrome uses a behavioral algorithm to whitelist sites, Firefox doesn't. Just more sensible defaults in general. Chrome suffers from the same problem as a lot of Google products, where they're mostly sensible, but you'll occasionally run into really quirky design decisions that just seem like no one thought them through enough.
- I know you're not looking at the future, but it is almost certain that the Chrome Manifest V3 changes are going to go in for extensions in the near-ish future, and that happens Firefox will also be the best platform for Adblockers. I'm including that just because it's a relatively certain change that isn't very far off and that will have a very obvious effect on day-to-day browsing experience for a lot of people.
- Speaking of adblocking, if you're on Android, Firefox supports all of its desktop extensions, including ad blockers, which IMO is a killer feature -- extensions like UMatrix will save you a ton of mobile data. And if you're already using Firefox on Android, you might as well use it on the desktop as well so you can maintain the same extension-list or sync bookmarks between your devices.
Terrible decisions, the developers should be ashamed.
I think it's a bad idea for that reason, and for another higher level reason. As a developer and sys admin before that I've always tried to assume my users are smart people and try to educate them about what they might not know, instead of assuming they are dumb and attempting to PICNIC-proof software/systems. I think hiding the scheme indicates an assumption that users are dumb and need to be told what to do. I've seen reporting on other indicators of this from Google over the last decade (e.g., Google Reader's sunset, Google+, working with China's censors, and others).
FYI, PICNIC = Problem In Chair Not In Computer
I believe the more common term is “PEBKAC”:
That's extra painful because browsers keep on changing what those indicators are.
We are all inextricably linked to technology and yet I wonder if the newest users even know what a file extension is; because we hide that by default for some reason now. How many people have been the victims of phishing because an alias is more prominently displayed than the actual domain which the email originated from?
I'm ready for a return to function over form. Do not hide information from me. If I suspect that your product development is driven by the lowest common denominator then I will look for alternatives.
http and https are distinct and as such cannot be hidden; you could replace them with icons (barf) or ports (unlikely).
www.site.com is a subdomain and is again distinct from site.com with the 'www.' omitted. Just because they tend to resolve to the same server does not mean that they must.
Let's just call PI 3 because those decimals are an eyesore.
Guess it is that time again.
Also, seriously people, ditch www. subdomains already. It's not 2002 anymore. I cringe so hard when I see that crap in print ads and billboards.
Sweet, unless you use any other subdomains for web pages, or want to in the future.
Usually you don't want cookies for domain.com to affect api.donain.com, admin.domain.com, test.domain.com etc.
I actually love www subdomains - the origin tells you it is a website.
And with HTTP/2 you don't have to worry about static stuff slowing down or crowding out API req-resp data.
It lacks that connotation for the regular user.
Adding all the new TLDs have made the www prefix more useful than ever.
Put www.somthing.com on there and it is obvious to most how to find your business online.
https:// is ugly and longer IMHO.
To do a bunch of new things browser vendors want, they need to put more stuff into DNS. For example eSNI needs keys in DNS, and HTTP/3 (HTTP over QUIC, which is the new encrypted transport protocol) wants a way to discover HTTP/3 availability before connecting with TLS.
So at IETF 105 last week there was stuff pinging around about the idea of a single new record, perhaps just for HTTP or perhaps more, that wraps all this stuff up, with all the SRV features too.
The DPRIVE work is having the effect of reducing the pressure to not use DNS, because crappy DNS servers break all the time when you add new things, but DPRIVE servers are operated by people who actually know what they're doing so that isn't a risk, and eSNI in particular makes no sense without DPRIVE, so why not.
A couple question for those with this point of view:
1) Do you think users notice when they are using AMP articles today, even though the URL has not been hidden yet?
2) Do you think it would actually matter if they did notice a Google-hosted URL? Would they boycott Google or change their behavior somehow?
3) Do you think Apple has the same motivations as Google? Safari has been hiding www, scheme, and path for a while now. Do you think they have any valid reason for having done this?
4) What do you say to Google's stated reasons for making this change (simplicity and security)?
If you asked any person- How do go to your favorite website before the omnibox, they had a clear set of steps that worked. If you asked them, how do you search for recipes they had a clear set of steps for that too.
Google's omnibox/(aka keyword logger) made that boundary fuzzy and made it confusing for people. Earlier, people very quickly learned to recognize what is and isn't a valid url, because an invalid URL simply didn't work - this was a very very useful skill/knowledge to have. And every-time you had a typo you noticed it immediately. But then Google insisted on merging the URL and search bar and started correcting their typos and mistakes and people started losing this knowledge/skill. So now.. a lot of non technical folks I know type the url in google's search box in weird ways .. like "wwwfacebook" or "facebook .com" or other typos. So now, nobody actually knows what a valid URL is. That makes them easy targets for phishing and scamming. I'm not blaming this entirely on Google, but they did play a part. Google doesn't seem to realize how they're fucking up things even if that is not their intent.
They rolled this out 10 months ago but rolled it back after community backlash.
For those that become engineers, it will take even longer to untrain all the handholding they've had to endure.
If the web is apparently so damn complicated maybe we should rebuild it to be "simpler" instead of hiding it how it works. I'd prefer to leave it exactly how it is until there is a clear reason to revisit the design.
The Chromium team desperately need new leadership.
(I don't have it on Android yet.)
Seriously. What kind of incompetent, lazy people are working at Google these days? Because clearly nobody gave this any real thought.
I already hate the fact that chrome on mobile totally removes the URL when you focus the navbar, sucks if you want to go to some other subreddit etc.
www must go, it's a remnant of the past, the sooner the better.
protocol is not a detail that should be ever exposed to the end user, at least not in text form. visual cues "you're safe" or "your connection isn't secure" are much more effective.
i'll let you sort out the rest.
Regarding the context of the example, all this is about navigating and about communicating how to navigate. Real live addresses tend to be much more messy, but they are bearable and users have been able to operate them for what is now several centuries.
Which then is a thing for websites to do, not for browsers to lie about.
it's just like your opinion man. not showing redundant information is good. if you disagree where's your rant about browsers lying about port 80 by not showing it?
if your point is that www.name.com can be different site from name.com - i disagree even more, this is a case of incompetent developers at name.com so redirect your rage accordingly :)
> a thing for websites to do
they'll do it eventually, doesn't mean browsers shouldn't be getting rid of redundancy.
The host name is not redundant information.
> if you disagree where's your rant about browsers lying about port 80 by not showing it?
Why should I write idiotic rants?
> if your point is that www.name.com can be different site from name.com - i disagree even more, this is a case of incompetent developers at name.com so redirect your rage accordingly :)
Well, great that you disagree. Now, please do the work of changing the relevant standards instead of making yourself look like an idiot by calling people who read and follow standards "incompetent developers".
> they'll do it eventually, doesn't mean browsers shouldn't be getting rid of redundancy.
Which is not the topic of this disucssion.
> Why should I write idiotic rants?
You are not aware that all browsers currently hide port numbers in the URI bar if they are 80 or 443? For example, https://www.google.com/ is actually https://www.google.com:443/, but the browsers choose to hide this part. Wouldn't it be better if you actually saw which port the browser connects to? That way you can write https://www.google.com:13000 for example to try to connect to another port, but now you believe that those addresses doesn't exist. Removing these two standard ports from the address bar is therefore exactly the same as removing other standards parts, like https:// or www.
Which is why hiding the protocol is stupid. How do you know which port is being used if you don't know the protocol. You are actually arguing against your own point.
I know it is port 80 or 443 based on the protocol - it's deterministic. I don't know that www or m maps to the same place as the apex domain name.
by using the browser you opt into vieweing the web, which historically is used via http/https on ports 80/443, and just as historically, majority of web sites have www subdomain, which these days makes no sense to expose to users just like ports and protocols.
The whole idea of writing standards is completely useless if you can not rely on what a standard says. If something conforms to a standard, that guarantees that if you also conform to the standard, you will be able to interoperate with it. That is the whole point of writing standards. If either party does not conform to the standard, there is no value to the standard in the first place. If you are supposed to know what some random people consider sane, or the implementation details of everything that you want to interoperate with, and build your stuff for that, then you don't need a standard. The whole reason for writing standards is to eliminate the gigantic overhead and friction of that approach and to enable everyone to instead read only one document to ensure interoperability. All of that becomes worthless when you implement what you think is sane over what the standard says.
No, I am not, for the simple reason that that is not the case. Browsers hide port 80 only for HTTP and port 443 only for HTTPS, because those are the well-known ports for those protocols, and the specifications of URIs and those protocols define that no port in the URI is equivalent to the well-known port, and what the well-known ports are.
https://tools.ietf.org/html/rfc3986#section-3.2.3
https://tools.ietf.org/html/rfc2616#section-3.2.2
https://tools.ietf.org/html/rfc2818#section-2.3
> For example, https://www.google.com/ is actually https://www.google.com:443/, but the browsers choose to hide this part.
No, the browsers simply follow the relevant standards, as you can see from the links above.
> Wouldn't it be better if you actually saw which port the browser connects to?
No, there is no additional information in displaying the well-known port, as per the standards cited above, so it would be a completely useless waste of space.
> Removing these two standard ports from the address bar is therefore exactly the same as removing other standards parts, like https:// or www.
What do you mean by "standards parts"? Also, could you please cite the relevant standard that specifies that http[s]://www.domain/ is equivalent to http[s]://domain/?
how is that different from "browsers only hide www part of domain name because this is a well known historical artifact and default behavior of any sane website should be to either redirect one name to another or serve the same content on both"
you're being unnecessarily and angrily pedant.
That one of those is part of the relevant standards, the other is not. What your personal opinion is as to what a "sane" anything should do is just completely irrelevant for this discussion. You build reliably interoperable systems by implementing what the standard says, not by implementing what you would prefer the standard to say, because (a) if everyone just implements what they think is sane, that's guaranteed to fail at interoperating because everyone else will consider something else sane and (b) the process for building the consensus as to how to do things is the standards writing process, so if you think a standard is insane, you have to participate in the standards writing process to change the consensus on how to do things sanely, which then will be reflected in a new revision of the standard.
Whether something is well known is also completely irrelevant. "Well-known port" is simply a fixed term for "ports that have been standardized as the default port for a protocol", and the only relevant fact here is that the behaviour of not displaying the port number is standardized.
> you're being unnecessarily and angrily pedant.
No, your kind of reasoning is precisely how a ton of interoperability problems arise, costing humanity probably billions of dollars to work around each year.
do show me the standard that regulates how browsers ought to display identity of the site. because everything you've said is irrelevant otherwise.
in context of browsing web sites in the browser, www is absolutely redundant information.
> do the work of changing the relevant standards
since you're so much into standards, there is no standard for how browsers ought to display identity of the site provider that is being browsed. i also don't know of a standard that mandates anything specific about "www" subdomain. and i completely stand by the statement that serving different content on "name.com" and "www.name.com" is utter incompetency.
> Which is not the topic of this disucssion
then why did you bring it up?
Please cite the relevant standard that says so.
> since you're so much into standards, there is no standard for how browsers ought to display identity of the site provider that is being browsed.
Which is just willfully not understanding the problem? There is a standard for which URIs are equivalent to one another, and I linked you to it. Browsers displaying one URI as a different URI that according to the relevant standards is not guaranteed to be equivalent is obviously in conflict with that standard.
> and i completely stand by the statement that serving different content on "name.com" and "www.name.com" is utter incompetency.
Great, I understand that that is your opinion. But the standardized consensus differs from your opinion, and the standardized consensus has precedence over your opinion. If you think the standardized consensus is insane, then work on changing the standardized consensus rather than promoting breaking interoperability.
> then why did you bring it up?
I didn't. Different host names are not redundant, that claim is simply your invention because you don't like that they are not redundant.