This change visibly hides subdomains. On some domains subdomains represent different sites from different unrelated authors. That being said it is of trivial effort to clone a site to capture sensitive information hosted under any subdomain with a valid HTTPS certificate.
Shouldn't it actually help, seeing as the domain name is the important part? Now users can't get tricked into interpreting the path as part of the domain name.
Even if it does help in some cases, it's hiding the path, which in itself could cause other vectors of attacks. Just host malicious pages on legit sites where you can host and phish for clicks to it, faking the home page look and feel.
For phishing to work you need a similar domain if you want to maximize the conned people. Copying the path from the attacked website is the easiest part.
I can even argue that if you take away the path from the URL, then it's actually easier to spot a phishing website since all you see is the domain if you don't hover over the address bar.
While I don’t welcome hiding full URLs at all and won’t use any browser that doesn’t allow to turn that off easily, this matter is more or less orthogonal to phishing.
If domain-owning organization fails to prevent a third party from hosting a phishing site under a path or a subdomain, that third party is likely well-positioned to deface the existing pages. With a subtle alteration (scripts that capture credentials and transmit them out), the existing pages grant an attacker all of the users with no extra effort—as opposed distributing a link to a fake page, convincing the user that the page is legit, and in the end getting a fraction of the user base.
This might be harmful to github pages where it would hide the repository name.
If they include this without offering an option to turn it off, I will quit using Chrome.
Chrome is the new IE. Some sites don’t work (well) with others browsers, so people are annoyed when the browser they are forced to use does stupid things.
Before Edge came out, I always preferred IE11 over Chrome (on machines that only had those two installed), because IE11 kept the legacy "must compete with Netscape" features like decent contentEditable context menus. And websites that didn't work in IE11 generally weren't worth using anyway.
Now… well, IE11 doesn't even support ES6 properly, and good sites have started relying on that, and Edge is just evil Chrome – unless it's got Firefox installed, Chrome's your only option. But sites that use Chrome-only APIs aren't worth using anyway.
(Oh, wait, Zoom needs either Chrome or a malwarey desktop program.)
This analogy would work if Google was deliberately holding back new features on the web to favor its proprietary operating system but in fact the situation is pretty much the opposite.
I also don't understand why everyone is up with pitchforks at Google on this when Apple did the same thing to URLs a while ago. I guess engineers are just as susceptible to groupthink as anyone else.
>This analogy would work if Google was deliberately holding back new features on the web to favor its proprietary operating system but in fact the situation is pretty much the opposite.
They do kind of do that. Rather than going through the consensus process for getting a web standard added, they implement it in chrome then unilaterally write a standard for themselves. See for example, the SGX (signed exchange) "standard" they pushed out.
Yes, it is kind of weird to like a browser where the company behind it are actively working against the web when there are decent alternatives (arguably better alternatives) that does not contribute to a monopoly that we can not break.
Do you think IE6 was bad? Remember how long it took to get rid of it? Imagine a world where the monopoly leader doesn't just walk away from the browser (which is what MS did with IE6) but actively abuses the situation. It will be orders of magnitude worse. Say hi to amp. Say hi to chrome. Say hi to google. Say goodbye to the web.
I suspect a lot of people in this conversation are not old enough to remember, even if they wanted to.
Maybe universities should have an obligation to promote nonprofit tools (i.e. Firefox) rather than shady commercial software that only happens to be gratis.
Passwords and bookmarks are in Chrome. That's the main point of friction. But I do re-evaluate Firefox from time to time. So far there has often been small things which made me reluctant.
I think this feature is important enough for me to consider switching this time.
That being said, I admit that staright out of the box Firefox doesn't have the same experience but you can customize every little thing about it to make it suit your needs.
That’s too close for comfort to the Windows/Linux comparison.
This said, I honestly don’t understand what people mean when they say the experience is “superior” in Chrome. It’s a web browser. It browses. You get passwords saved and synchronised. Everything else is an extension. What’s so bad about FF...?
As a Safari user it boggles my mind that Firefox's send to device feature is considered good at all. All my Safari tabs are automatically synced to my phone at all times with no intervention needed from me. It's one of the few things keeping me from switching to Firefox actually.
I guess I'm forgetting there are people with dozens of tabs open at a time that probably wouldn't like this. The Safari thing does keep them separate though from your mobile tabs until you open one.
The last time I tried to use Firefox for a daily desktop driver, I found its dev tools far less discoverable and powerful. It may be that they're as good or better and just harder to learn. Related, if you're debugging hybrid mobile apps, Chrome is pretty much the only game in town on Android, IIRC.
It also felt noticeably slower at the time.
Finally, with Chrome's market share, good extensions that Just Work are more common there, in my experience. I use a whole host of plugins on desktop, and when I looked at switching back to FF last year, I did not find equivalents for everything.
I did go back to FF on mobile, because I do remember the nightmare of IE 6 and want to protect the web from total Google control. On mobile, I miss the dev tools and array of extensions less.
You can import your passwords into a 3rd party password manager and enjoy having them available on any devices and browsers supported by the password manager.
As for bookmark, firefox should be able to import chrome bookmark. It can even import saved passwords and cookies so your active session is preserved.
I don't like to trust too many entities with my passwords. You can't avoid having to trust the browser maker but adding another third party password manager to the mix would just make me twice as vulnerable for no good reason.
the latest version of Firefox has an "import Passwords from another browser" feature. just go to "about:logins" and click the menu in the top right hand corner.
Is that all? I had no trouble migrating. Maybe it will be a pain going back and forth a lot. Add-ons/extensions might be more painful though. I found it was a good time to clean up and get rid ones i anyway no longer care about.
Firefox donating to what is literally a encrypted message service for open societies foundation agitprop groups is what made me purge firefox from all my systems. I'd rather be tracked up the A by google for commercial purposes than supporting anti-democratic agitprop bullshit.
You do realise that you don't get to choose between getting tracked by Google or "supporting" the goals of Mozilla Foundation (such as freedom of speech for all including your political enemies)? That is, by choosing Chrome you also "support" any and all political goals of Google (such as replacing the open web with AMP).
Mozilla donated to riseup.net some years ago, after they shunned Brendan Eich from his own creation. Riseup.net is a encrypted mail service for OSF agitprop groups.
I never switched away from Firefox. I am old enough to know that nothing comes free, especially from a Big Corporation. As customers, all we can do is to always keep a good alternative alive, no matter what.
But Chrome is not free (well kind of). It saves lot's of money in royalties for Google (because Google search is the default search engine in Chrome). So even if it's 'free' it saves money for Google.
Hah, that actually makes me happy as a no-break Firefox user since 2003. At least that means Google will continue to support Firefox independently for as long as they're in the browser business.
True, but then I’m not sure Mozilla would be able to survive if Google stopped their deal with them due to say, adding ad-blocking to Firefox by default. Not the same, but it certainly influences the direction of FF.
I don't think Mozilla's trying to please Google in any way. Google's keeping Firefox around to try to avoid the appearance of a total monopoly.
But Mozilla's behavior certainly is influenced by trying to find alternative business models, sometimes not perhaps with the best results, (Mr Robot promotion everyone), I still think it's worth using it over Chrome.
This is true, but then again absolutely all browsers are being funded by ads. We are talking Edge, Safari, Brave, all of them.
Did you know that Apple does in fact get more money from Google than Mozilla does, for keeping their search engine as the default? 12 billion dollars in 2019. Do you think Apple would activate ad blocking by default and risk losing that many billions of dollars? Speaking of which, Safari's ad blocking is the joke of the industry.
You could make the case that Safari might survive if Google cuts its funding, but judging from the history of IExplorer, I have my doubts. One could make the case that Safari is alive just because Apple is making a shit ton of money on it.
Did you know that Microsoft's Bing Ads platform made them 8 billion dollars in 2019? Do you think Microsoft would do anything to jeopardize that ads revenue? Did you know that Windows 10 has an "advertising ID" used to personalize ads, that via Edge is transmitted to Bing?
Did you know that Brave, that leech which is piggybacking on other people's work, that's supposedly blocking ads by default, is effectively replacing publisher ads with their own, then forcing those publishers to enter into deals with them for a piece of the action, while making it really hard to detect and block Brave? All the while pushing shady cryptocurrency affiliate ids straight in their source code?
---
Mozilla might not push for ads blocking by default.
But they do block trackers by default and their browser is afaik the only one that has legitimately supported uBlock Origin on top of Android. And uBlock Origin is the best, most aggresive ads blocker available and given Google deprecating the blocking ability of the WebRequest API, Firefox might remain the only one with a uBlock Origin implementation.
Could Firefox survive without Google?
I don't know, but can any other browser survive without Google or Bing? I have my doubts and you'd be naive to think otherwise. Plus this is just whataboutism.
None of the things you mentioned about Brave make them funded by Google, and the system they want for ads is clearly better for the consumer than the status quo.
Brave is essentially a repackaged Chrome and does nothing to help undermine the Blink monopoly. They're not directly funded by Google, but their browser depends directly on Google funding Chrome's development.
If Google disappeared tomorrow, Brave would continue to exist and would continue to get updates.
Brave does not depend on Google, directly or otherwise. They depend on an open source project called Chromium, which is largely developed by Google, but because it is open source anyone can build off of it.
Brave funds their development through the BAT token and through affiliate marketing, both of which are much better for user privacy and security, and much more resilient to Google than where Mozilla is getting its money.
No, I don't think Apple would integrate thorough ad-blocking by default, just as I don't think Mozilla will do this either. Brave has already done it. Brave's ad-blocker works better by default than any ad-blocker I've used, and I've tried them all.
HN's hate-boner for Brave is very strange. They clearly care more about user privacy than any other browser vendor (except maybe Safari, but again they have a conflict of interest), and it is built on a core that is arguably the best at handling the modern web (Chromium).
> If Google disappeared tomorrow, Brave would continue to exist and would continue to get updates.
Microsoft wasn't able to keep developing a browser on their own, I doubt that Brave could. The problem is that a browser nowadays is so complex to develop that you need serious resources to invest in it. Without Google's ongoing development, Brave would not survive. And given Google's changes to undermine ads blockers, it's going to be interesting to see Brave struggling to maintain their fork.
---
> much better for user privacy and security
Right, keep telling yourself that.
Btw, I actually wonder how what Brave is doing isn't copyright infringement, given they are directly profiting from blocking the ads of publishers. I guess they are small enough to not matter, for now.
---
> Brave's ad-blocker works better by default than any ad-blocker I've used, and I've tried them all.
I worked on anti-ad-blocking technology.
Nothing beats uBlock Origin running on top of Firefox, everything else was strictly inferior. Not even blocking JavaScript in the page, because you can easily force the user to enable JS for you by breaking the content on that page. uBlock Origin is so bad that we avoiding it entirely, being useful for people frustrated with AdBlock Plus to turn to, sort of like in the Matrix.
> Microsoft wasn't able to keep developing a browser on their own, I doubt that Brave could. The problem is that a browser nowadays is so complex to develop that you need serious resources to invest in it. Without Google's ongoing development, Brave would not survive. And given Google's changes to undermine ads blockers, it's going to be interesting to see Brave struggling to maintain their fork.
IE was woefully out-of-date. MSFT then tried to build a browser from scratch. That was a lot of effort, so they decided to fork Chromium (like Brave) instead. What exactly do you think would happen in Google dissappeared tomorrow in their case? Do you think they would go back to trying to build their own browser from scratch? No, they'd just keep developing Chromium. Many (most) changes would probably be upstreamed. Forking a browser and maintaining it is orders of magnitude easier than starting from scratch in [current year]. As you point out, there are not multiple parties building on Chromium, so I'm sure slack could be picked up if Google switches gears. But you're right, maybe Brave won't be able to keep up with upstream changes that make ad-blocking harder. In that case, you can always just switch browsers. In the meantime, however, I'll use the browser that does a better job of protecting privacy by default.
> Right, keep telling yourself that.
Luckily, I don't need to. A browser that blocks ads by default is objectively better for user privacy and security than one that doesn't.
---
> Btw, I actually wonder how what Brave is doing isn't copyright infringement, given they are directly profiting from blocking the ads of publishers. I guess they are small enough to not matter, for now.
They aren't directly profiting off of ad-blocking, so maybe that helps.
---
> I worked on anti-ad-blocking technology. Nothing beats uBlock Origin running on top of Firefox, everything else was strictly inferior.
Have you actually tried Brave? Works better for me, and I've tried Firefox with uB0. Have also tried Chrome with uB0. Brave blocks both ads and tracking more consistently across the board. It occasionally breaks a webpage, but I have reported those to Brave and two of them have been fixed (out of like 5). This process is clearly better for users than everyone having to configure their uB0 Matrix and such separately. Brave is creating a web where all the privacy violating / attention grabbing shit is very much blocked by default in a much stricter way than other options. When this breaks the internet, they fix it and because this fix is part of the blocker it fixes it for everyone.
> If Google disappeared tomorrow, Brave would continue to exist and would continue to get updates.
"Updates" may be, large, architectural upgrades? Doubt it. There's a reason they didn't start fresh and I very much doubt they'd muster the resources to maintain development were Google to drop it. Google has invested billions, probably tens of billions into Blink engineering.
What I could see happening is Brave forming some sort of a coalition with KDE and the wider open-source community in the better case or trying to switch to WebKit in the worse case as that is exchanging one corporate overlord for another.
Not to mention Brave's VC funded, so they'd want some form of a meaningful exit at some point.
The bigger concern however is not that Google will not fund Blink development, but that it will increasingly implement features that primarily benefit itself and Brave, as a dependent player, will be spending an increasing amount of resources trying not to get eaten by Google's "direction tax", as all developers depending on a 3rd party corporation they're in some sense competitors with find out eventually.
See also Twitter 3rd party client developers or the many AppStore devs Apple burned and ruined their business overnight.
That Safari doesn't ship with an ad blocker, indeed, that was the point, and it never will.
And its content blocking, speaking both as a user and as somebody that worked on anti-ad-blocking technology, is really easy to circumvent and only useful on websites that haven't adapted yet.
As an iPhone user for me it's bad enough to make me want to switch to Android. What works consistently well has been DNS-level blocking (Pi-hole, NextDNS).
For you it might be OK, but I can tell you Safari is a favorite among the big players in this space [1].
Given that Firefox slowly adds all the things we hate about Chrome due to the argument "we need to compete for normal users", how much do you want to bet Firefox will hide the URL in a few months (and even remove the setting that lets you change it)? :(
Firefox is already doing this! I recently had to dive into the about:config to find a setting that was hiding part of the URL. Although I can no longer find the setting that I configured so perhaps this has been changed in a recent update?
Edit - found it: the setting "browser.urlbar.trimURLs" hides the "http://" protocol if it's used. I do a lot of local development and found it annoying that Firefox was hiding it.
Thanks for this! Turned it off. I guess I haven't noticed because my focus was always attracted to the padlock with a red line through it in front of the URL.
Next step: an "education campaign" to tell people that that part of the web is "insecure". In fact you should only get any content from a handful of domains. And in non-net-neutrality jurisdictions, the ISPs will start offering packages that work with pre-approved domains only. And since it'll be enough for 90% people, it'll work.
This already kind of happens in Firefox. If you have a non public certificate authority, when you visit a site signed by that CA it says that it's not verified by an authority known to Firefox.
I don't know if there is a way to "bless" such an authority once it's added to the trust store.
So what’s the problem? Mozilla didn’t add the CA to the trust store, you did, that’s why Mozilla doesn’t recognize it. It doesn’t sound like it interferes with normal operation and differentiating bundled and added CAs on inspection sounds like a good idea.
That's technically correct, but as far as the security of the website is concerned example.com, example.com/~eviluser/uh-oh, and example.com/nefarious/sub/directory/pretending/to/be/google.com/ are all exactly the same. The issue Google are trying to "fix" is making it more clear that the domain the user sees is what they're really looking for. If a user on a website is being evil it's up to the website owner to stop that, not Google. Google are trying to protect people against evil website owners (or so they say...).
It is, there’s a long special list for domains that host arbitrary subdomains, GitHub pages is one of them. It’s explained well in https://youtu.be/0-wB1VY3Nrc
Wait, seriously? Their default behaviour is so broken that they have to whitelist a ton of sites, and screw anybody who slips through the net (or is trying to start a new service)?
Most browsers use the Mozilla public suffix list [1] that is frequently updated, and a new service can easily submit a new entry. This list is used for many different features.
This list is necessary anyway, because you have top level domains that look like .co.uk, so you can't just split the domain name by dots and take the last component to determine the top level domain.
So, not saying I unconditionally like the fact they are hiding important information in the URL bar, but I would not say their default behavior is that broken.
[1] https://publicsuffix.org - probably the list being mentioned in the video linked by the parent commenter, I guess
This list seems to be actually used to determine how cookies can be shared across domains, but not by Safari? Does this mean that Safari might have different behaviour as to when cookies can be shared across domains?
A common convention with system administrators is to have the canonical name at www.* and redirect www-less requests to the former. If you argue that a browser implementation should fix uncommon configurations, I would argue that administrators should fix their configurations in the first place.
You don’t have this issue at all for domains that don’t have a www subdomain.
Furthermore it would be extremely confusing to have different content for www.example.com & example.com.
Yeah, I don't like the current trend to redirect www to root. You can easily doing simple dns-based load balancing by having multiple ip addresses on the www subdomain. You can't do that on root domain, you'll have to use a dedicated load balancer even if all you want is just simple load balancing among a small set of servers. It only benefit cloud vendors and hurt hobbyist/small website operators if this trend continues to the point that visitors expect all websites to be served from root insetad of www.
Multiple A records is fine on root domain, but root can't use CNAME, which is used by some people to implement their dns load balancing (I use cname so I forgot that you can still do it using A records). By using root domain instead of www, your options for load balancing is diminished.
Edit: another common use case is hosting your static website on S3 or github pages. Typically it's done by adding a cname entry to s3 or github.io (been a while so hopefully I remember it right). You can't do this on root, unless you're using another server as reverse proxy (e.g. cloudflare's cname flattening service). Again, it's benefits cloud vendors (cloudflare got more potential customers by offering this service for free) but ultimately hurt people that want to host their small websites.
If we could ever be bothered to implement SRV records for http then load balancing and failover could be significantly more straightforward and robust, without worrying about root vs. www at all.
The fact that www.example.com and example.com resolves to the same place is a happy accident due to someone explicitly configuring it so.
As a practical example, the website for my current employer had not configured their "bare" domain. When applying for a job I decided to check out their website, and copied only the "bare" domain and pasted it in my browser. Didn't work, just timed out.
I tried a few times and through "huh, website down for a few days, that sure doesn't look good". Then on a whim I figured I might try the "full" domain, and sure enough that loaded up straight away.
One of the first things I got done when I was hired was to ensure the "bare" domain worked.
Yeah but would you discover that by looking at the url? In the vast majority of cases it'll be mentally filtered out by the user anyway for the same reason why nobody cares about the http and :// part, they just want to know if it's secured or not.
You and maybe the 3 other people that might also notice if a site is serving different pages for http vs https. If it's accessible in the browser its already part of the world wide web so what information is it even conveying?
They're two different web pages. Possibly with entirely different information. Possibly run by entirely different people. Possibly with entirely different trust levels and threats. It conveys which of the two web pages I'm looking at. How is that not useful information?
All WWW was supposed to mean was HTTP accessible. Now that every domain why should a user using a http* browser have to specify that they intend to access it via http* when they have no other choice? Either the server responds or it doesn't. www.foo.com and foo.com both return http traffic then they are both part of the world wide web.
The specific of how you've decided to run your site or serve your pages is irrelevant. You may serve a page depending on if the http request came over port 80 or some other port or via http or https or at this time or that time or other.
www.example.com and example.com might be two different websites.
If you want the content at www.example.com and you go to example.com, then may not get the content that you wanted. One might be a shop selling shoes and the other might be a shop selling hats.
If you want a hat and you go to the one selling shoes then you're going to be disappointed.
'www.' doesn't 'mean was HTTP accessible'. You can make any system HTTP accessible, or not if you want to.
It doesn't matter how you or I set up our websites, or whether you or I think it's a good idea to have different websites at these addresses, it matters how other people set up their websites and if they choose to do this or not. Some do! Therefore the user needs the information.
You could send different websites based on what port the request comes from. But doing so would be bad and wrong, and showing the user the outgoing port is definitely not necessary.
> You could send different websites based on what port the request comes from.
But that's you controlling that, as the person running the website.
When it's the user controlling it, by setting which domain to visit, that's in their control, so they need to see it in their UI.
If you're going to reduce to the absurdity of 'anyone could serve anything from anywhere' then why show a domain at all? ebay.com could serve me the content of google.com, so let's not bother with domain names? Is that your argument?
The person controlling the website is responsible for making www and non-www show the same thing, as well as making http and https show the same thing. (Redirects are fine.) A user's ability to affect something doesn't automatically mean it's their responsibility.
I'm not making an argument about what should be shown right now, I just think your argument, based on what "might be different", is pretty flawed.
> The person controlling the website is responsible for making www and non-www show the same thing, as well as making http and https show the same thing. (Redirects are fine.)
But there's no standard that requires this, that I'm aware of.
Chrome are acting like there is, but I believe there isn't.
There's no standard that says you have to deliver the same data to anyone as far as I'm aware. It's still an absolute abomination if http and https are different sites, for example.
The company I worked for had www.* as a web presentation for the SaaS app and SaaS app running on *.
So yeah, hiding www is annoying and confusing in this situation, because Google just assumed something about the web/domains and forced their assumptions on everyone.
How, in the 21st century, has USFCA not gotten the memo to redirect HTTP requests to a root domain to a default subdomain instead of black-holing them?
At this point, That's just sloppiness on USFCA's part.
The question is, why haven't you quit already? The only things it offers others don't, are anti consumer vendor lock in nonsense like hangouts and google earth. (Not sure about hangouts and meet these days, mozilla likely made it work, but not for lack of scumbag google trying otherwise).
I'm not sure I understand. Are you asking whether Firefox supports browser extensions? If so, the answer is yes. Firefox has always had extensions including epic breakthroughs such as Adblock (Plus) from 2002 and Firebug from 2006. (Google Chrome has had extensions since 2010.)
> If I need the whole URL visible at all times as a developer, that's an hour of chrome extension writing to make it always viewable.
Interesting. Other comments in this thread indicate that the only extension that can do this has its ID hard-coded in the url parsing code to be whitelisted.
An extension can get window.location and can then paint it anywhere on the page the developer chooses, or put it in a drop down, or send it to an external service via an HTTP request and beam it to the moon, if the developer wishes.
I would also add that, to personal use, Firefox has some features that seem half-baked. Like:
1 - Selecting multiple tabs and saving to bookmarks: you can't add to an existing folder without creating a subfolder.
2 - Add keywords to bookmarks: no way to filter bookmarks that have keywords. Also, when typing on the address bar, the keyword doesn't get highlighted or anything
3 - can't add a custom search engine. You have to add its extension, if available. Or add as a bookmark with a keyword, but then you won't be able to see a list of all search engines...
> 3 - can't add a custom search engine. You have to add its extension, if available. Or add as a bookmark with a keyword, but then you won't be able to see a list of all search engines...
As a full time, happy Firefox user, this annoys me to no end, increasingly so as there are more and more competing search engines that I want to try.
I’m pretty sure that you used to be able to add arbitrary search engines too (by specifying the search URL with %q for the search query). It’s amazing to me that they would remove this.
> more and more competing search engines that I want to try
Not only that, but on Chrome I have Amazon, Youtube, Reddit, all setup as search engines. For reddit, besides 'rdt' for general search, I also added keywords for searching inside /r/anime, /books, /ps4, and a few other subs I occasionally search.
I also think they used to have this, as Chrome still has. But no idea why they changed it.
Yeah, I think having it intelligently bold/highlight or perhaps reduce significant parts of the URL would go a long way and likely makes more sense as a next step.
That's exactly what Firefox does. I am typing this on Firefox and in the address bar "ycombinator.com" is in black and the rest of the address is in grey.
Well chrome has been doing that for a while too but what I mean is more like significant parts of the url for trust like say the user in github.com/<user>/<project>, because the user represents a significant silo similar to if it were instead organized like <user>.github.com/<project>
Well, whilst that is a nice idea I can't see it happening anytime soon. Attempting to work out if a part of a URL represents a user name seems like a bit if an impossible task to me. I guess you could encode rules for specific well known sites but I doubt you could ever create a general solution, and if a site changed its URL you would become unstuck until you rolled out a fix.
It would be harmful for any site, whose content 'root' is not (sub)domain. Thus most user-submitted content - projects on github, youtube channels, ...
"URLs as breadcrumbs" solve this cleanly. They've already been visible for years in web search results.
Here the address bar would show "(padlock) [Github Inc] Github.com > Name Of Account > Name Of Project" for example. This is much clearer for end users.
Developers can always toggle an option to always show the URL or something.
So Chrome is only showing the domain part now? Just like Safari has been for a long time?
Personally I quite like it. From what I understand the main goal is to make phishing attacks more clear to the user, since this is ultimately only a thing the end-user can protect against. Removing the noise definitely helps for that.
Having had it like this in Safari for a long time, I must say I greatly prefer this over the older behavior---the only time I care about a full URL is when I select it to copy it.
Safari has an option to include the full URL. As a developer, I need the full URL so I turn on the option. If Chrome by some miracle actually goes through with this, I'll try to see if I can get around it (because at the end of the day, everyone uses chrome and chrome dev tools are by far the best).
Chrome dev tool used to be far better than any native alternative. Including Firefox, but Firefox has caught up. A tad too late as Firefox had, prior to chrome, the best native dev tool.
I agree. I spent a few minutes confused as to what everyone was so mad about. Surprised this is an issue for anyone.
Unless you need to modify the URL often, but it has the hover behavior and if even safari has an option for it, I can't see google removing that option.
A couple of Google Chrome devs talk about the issues surrounding the readability of urls and their security implications and possible solutions in an episode of their podcast[0]. I think they make a compelling argument for hiding most of the url in part to prevent phishing however I do think they should allow this behaviour to be toggled via a flag.
Their goal is full AMP dominance.
Just look at these evil guys faces.
It's clear enough that they're going to pass their frustrations onto you, no matter what.
The claimed purpose is basically just to prevent phishing.
They explain a number of reasons why it is difficult for people to extract from a URL the part which is relevant to security, ie. the bit that affects who has authority over the page and how your cookies will be separated by the browser. The cookie sharing actually had some rules I didn't know about as a non-web developer but experienced URL user. They show how every browser is already going some way towards this but they all have some problems, for example Safari shows the full domain not just the important part.
Looks like this will be great for reflected XSS attacks. Even advanced users will not be able to notice there's something weird going on outside of the domain name part of the URL. Perfect!
Basically any page on the website with this vulnerability will be useable to show a fake login page, and user will not even notice he's not on the /login, but on some weird path + ?_sort=somejavascript
Not that it's that hard to clean up url via history api after you get access to the page via XSS atm, but there's still some short period of time where the full url is shown in such a case, that may provoke suspicion.
This, along with the inability of disabling the async dns feature in the latest Chrome for desktop versions (thus making pihole/adguard irrelevant), makes me accelerate the change to another browser.
Because I want to use my own DNS server and block ads at the DNS level rather than the browser level. With this move, Google has effectively white listed adsense / adwords to not be blocked regardless of the network settings of the device.
That is a good point, I might have been pointing at the wrong issue in Chrome. I have only seen this behavior happen since 2-3 days ago and all my research pointed me to async dns being the culprit. I am really eager to find out if this can be disabled in any way, but my Chrome time has come to an end with recent developments.
Seems like a bug. Some environments cannot reach external DNS servers, so it would break resolution in general. This happened before and was fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=265970 I couldn't find any report for the current issue though - maybe you should start one.
Chrome doesn't respect DNS settings anyway. I have in my resolv.conf:
search my.home
And entering hostname of my server would just googles the hostname of my server, instead of trying a lookup and googling only afterwards (or never, I don't see why the browser should contact the owner just because I mistyped the url).
This point merits an explanation. The file /etc/resolv.conf is a configuration file for the `dns` NSS module used by the glibc resolver.
Google's async DNS feature uses Chrome's own internal DNS resolver which doesn't call gethostname(). It would be incorrect for Chrome to parse this file and attempt to "respect" your settings because NSS is a series of black-box system-specific modules. If you removed the dns module from /etc/nsswitch.conf then resolv.conf wouldn't even enter the mix on your system and then Chrome would do the wrong thing. If the dns module behaved differently on your system and /etc/resolv.conf was actually /etc/resolv.json or /etc/resolver.conf then Chrome would again do the wrong thing.
When resolving a name applications have two choices, either look up the name with glibc, send the request through the NSS gauntlet of black-box modules and take whatever it returns of perform the DNS request itself and ignore everything on the system. Any sort of hybrid approach would be more confusing.
I hate to be the person who's like "you're holding it wrong" but your usage of DNS is incorrect according to the RFCs. All configured DNS servers are assumed to serve the same content. The idea of every DNS request "trying" the first server, timing out, and then the next, and the next is a calcified implementation detail.
A DNS client looking at the list of servers, and marking the speed and reachability of each server is the most basic optimization. It makes no sense for clients to add n seconds to every request for every unreachable DNS sever.
The async DNS feature using Chrome's internal DNS client which behaves differently than glibc and so pihole appears to not work. Chrome is not injecting its own DNS servers into the mix or whitelisting anything, it always uses your system's DNS servers, it just looks them all up in parallel which it is allowed (and encouraged) to do by the RFC.
Make sure all your configured DNS servers are pihole and everything will work.
At chrome://flags there is one called #omnibox-context-menu-show-full-urls, which I have turned on.
This enables you to right click on the address bar, and turn on the option "Always show full URLs". It will always shows the full URL including the protocol, but I suspect they will remove this flag at some point.
If you happen to close your browser and lose your tabs, use the reopen closed tab menu option, it'll bring all the closed tabs (even if multiple tabs).
I can't find this option on Chrome on Linux. I had to get an extension to show the full URL, but it only works for 'https://' URLs, not for 'http://'.
This drives me crazy when debugging. Whenever I copy-paste IP addresses from the browser address bar into my console, I have to manually delete the `http://` at the front. I work on a P2P project so this is an extremely common situation for me.
Are you running version 83 or later? I think they introduced the flag in that one.
Another solution for Windows and macOS users (no Linux sadly) is to use Edge Chromium, which does it by default, and you prefer to donate your data to Microsoft rather than Google like me :)
This is exactly what I'm afraid of. there used to be chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains (when I google how to make chrome show the full url bar, this is the recommended answer) but it's been gone entirely for several Chrome versions. I even toggled a flag to undo flag deprecations in Chrome 78 to get this back but that didn't work very long - I think this flag has been totally dead since Chrome 80ish.
I personally don't care much what the default is for the normal user, but I want to be able to have my full urls.
Firefox is going down the toilet as well. Lots of me-too-isms are appearing.
Really my point was in jest. I think we need to trash the entire www and start again with something content only focused and hard same-origin policy and far far far lighter than what we have. I tried browsing the web on a dual core celeron N3010 recently and it was unusable on all mainstream browsers.
Signed exchanges are quite neat actually, they do not seem to depend on AMP at all. You could even use them to get arbitrary static resources hosted via IPFS in a seamless way.
For sure, just as AMP is also a neat technology that can be used by companies other than google.
But my understanding is that they intend to use signed exchanges specifically for their amp URLs, finally finishing their efforts of forcing people to go to google.com without them ever having realized it.
I can see the arguments for why this might be advantageous security-wise. I just hope they make it easy to disable (and it remains possible to disable in future) for those of us who are technically minded and are able to read URLs.
To enable the old behaviour you need to edit a browser flag. I don't know of any of the flags that disable Google 'engagement' features which have been kept around over the long term. The flags I've had to set in the past have all been removed after a few months.
Two recent examples off the top of my head are the recommended stories on the new tab page and the ability to disable images appearing in the omnibox.
I just hope firefox doesn't follow this trend. It was too difficult for me to adjust to their "one click select all" address bar that I now use ctrl + L for address bar interactions.
Isn't this a good example of "feature creep"? I dont see any reason why it makes a browser more useful when the URL is partially hidden.
It reminds me of a company which developed a product which was more or less done. So the SWE manager and the product manager made up new (pretty useless) features just to tell their bosses the devs are busy and the team must stay intact.
I'm starting to wonder when the EU will raise the anti-trust flag. It seems obvious to me that Google tries to use it's start page market dominance to become the only webpage served on the Internet.
What are the other browsers' intentions then, who are doing almost the same thing? What about the economic incentive of generally increasing trust in the web and ecommerce, which is highly relevant to their core business?
Also consider the sibling comment about AMP - looks like they already have special behaviour for that so this is barely relevant.
They don't do this for the benefit of the user, but to benefit themselves. Its all about making the web into google lah lah land where they control everything.
I increasingly find myself using other search engines when looking up political contents. Google's seems to be censored, or wheigthed in a way that gives it heavy political bias. I wish they would just give good search results, like they used to. Would be a lot less hassle.
That's the filter-bubble you're seeing. It's showing you things it thinks you'll engage with, and hiding things it thinks you won't, and the algorithm is too stupid to do that properly but they use it anyway.
To try and think of an upside for the user, it might help people detect phishing by making the domain name more prominent.
I've seen phishing sites like support.google.com.8n.cn where the right side (the most important) just disappears into the /path. Though this attack is even more brilliant on mobile devices that truncate the right hand side and leave with you with "support.google.com...".
Aside, I encourage fellow HNers to purposely visit seedy websites in a VM without an ad blocker. Especially if you haven't been exposed to crappy behavior since the popup/under days. Great way to see the state of hostile web practices, like unblockable popups and fake macOS notifications.
Try moving in the other direction. Have the browser always show a little bit of the HTML code or some Javascript variables. Will that make it better or worse? What's the correct amount of internal coding information to display to all users? I don't think URLs are the sweet spot of important information without useless mess.
It benefits Google in a number of ways - amp pages being the biggest one. It benefits nobody else as best I can tell, as it further obfuscates technology from the user
OK, I just don’t get it anymore. I mean I’m a happy Firefox user, so it’s not like this personally impacts me, but how in the heck is seemingly nobody acknowledging that this has been the behavior in Safari for a long time now? This seems to be a recurring pattern.
I've got a couple of guesses. Apple is somehow regarded as being a pro-user company, not having plans of taking over the web. Also, Apple users are accustomed to UI changes that result in visual simplicity. Nevermind that their actions result in patronizing the user just the same as Google does, in their case those actions are more likely to be perceived as innocuous.
Cmd+f Safari, I'm equally surprised no one but you mentions it.
However: I believe Apple's motives are aligned with their users and they want their browser to be as safe and as easy to understand/use as possible. Their primary intention is to sell their shiny expensive hardware.
With Google it's more controversial, because who knows what's the plan. Combined with AMP there is a reason to be wary.
Ofc, one can make bad decisions based on good motives.
While this might be useful for a casual user, hidden URLs are a huge problem for web developers. Asking for a screenshot from client is not enough, now I'll have to provide additional instructions how to copy/paste full URL when reporting issues.
Not to mention all possible problems with misconfigured servers when www and www-less domains lead to same website, but some script refuses to work on one of those. While it was easy to spot with just a glance at URL bar, now one has to do additional clicking or opening devtools.
Probably we are at the crossroads where developers need separate, not dumbed-down version of browser.
there is a trick for at least chrome before 85, where if you install the google-made extension "suspicious site reporter" it will show the full url including protocol (which you can't even do with flags so it tampers with something internally which means they don't have to do this at all)
I looked into it several months ago and it looks like that extension is whitelisted to do it. If you try to repack the crx file and install it, the address bar doesn't get changed.
True, but the distance between Firefox source and Firefox is config+compile.
You cannot compile Chrome. I've heard that Chromium can be compiled and run, but I've never actually seen it, or hear of anyone using that professionally.
I'm not sure what your point is... You thought it was weird that an extension would get preferential treatment, and I pointed out that this is true for Firefox also.
If you're relying on bug reports to find why a page is broken you're in for a bad time because 99% of the time the user isn't going to report anything. They're just going to think your page is broken and stop using it. Use a telemetry and error reporting service like Sentry or Rollbar. These services can strip sensitive data on the client before it gets logged.
Not every bug results in an error being thrown or any other signal that you could automatically detect. From my experience most of them are way more subtle.
While parent’s point is for devs, any kind of support situation falls into the same issues.
Grand-parents/friends/org users not being sure to be on the right site after a redesign, not seeing amazon in the right language, etc. There’s countless of questions that can be solved faster by looking at the URL.
How can I tell you don't work in IT? Almost all companies including mine have ONE site to choose from to do any one thing. If it doesn't work, they either ask their colleagues (which only works if it's not the first time someone is using this around them) or create a ticket for IT.
I've been a web developer for about 25 years. I can assure you if something doesn't work the users usually won't raise a ticket. They'll work around the problem. On the occasions when they do raise a ticket it'll usually contain minimal information. Having a telemetry system to correlate it against gives you some information to use to debug the problem. That's helpful.
Understanding that users have more important things to do than spend time on bug reports is an important lesson to learn. If you can gather data without relying on someone whose job is to worry about other things then you will make everyone's life easier.
Google does have an amazing access to data on how 80 - 90% of users are using the Internet, for many Google is the entry point for their Internet experience. Maybe their data is telling them that the URL bar is basically unused?
Honestly, if most "advanced" users turn off the features that Google uses to gather data to improve UX, it's strong signal UX isn't important enough to "advanced" users for Google to optimize for it.
Missing data leaves its own wake. Google has numbers to extrapolate how many turn off usage reporting. They lack automated signal in how the users use the tools.
Automatic metrics are only one tool in a toolbox that includes focus testing and design aesthetic.
But if a whole subset of users exclude themselves from that tool, they're going to get the UX that's only as good as the other tools in the toolbox are capable of building.
Definitely, and it continues to exist after as well.
But telemetry gives web developers an extremely simple and convenient tool to know what users are actually doing without even inconveniencing the users with explicit questions. I've done web development with a good telemetry set built into a page, and it is extremely informative regarding how users actually use the tool, as opposed to how the UX designers have predicted flow through the tool will be.
To give a concrete example, a user might tell you that configuring permissions is "hard," and sitting with them during over the shoulder testing (which is expensive) might tell you a little bit about why. But without even asking the user, page telemetry can tell you that they are making a transition jump from the permissions configuration page to the page listing all of the resource names, because that's what's slowing them down---the UI didn't give them enough information to configure the resources because we assumed they knew what the resources were named.
For a browser, anonymized usage stats can tell you whether most users keep all their bookmarks flat at the top of the bookmark bar or deeply nested in multiple subfolders, and that's usually valuable for deciding whether you want to emphasize a flat bar or folder management in the design.
If most power users disable automatic anonymous telemetry and also use deeply-listed folders, no one should be surprised if deeply nested folders doesn't get better.
Yeah, invading people's privacy always makes things easier for everyone else, doesn't it? Doesn't mean people who care about it don't want or deserve quality...
"Deserve" is complicated. To a first approximation that ignores a lot of details... What have they done to "deserve" it? They didn't buy it. They aren't making the process of figuring out what they want particularly easy.
People who don't show up to vote also "deserve" a good government by virtue of being people who have to live in a governed society. It's harder to make one for them if the system for selecting leaders is missing their input, regardless of what they deserve.
Popping out of the government analogy and back to software, power users are also in a position where they are more capable of adjusting their experience to suit their needs. All things being equal, a company with finite resources to develop software should dedicate those resources to assisting the non-power users more often than power users.
While you argue your case, that one has to vocalise if one wants something, well, you are still ignoring the basic want of not having your privacy violated and the fact that you can vocalise something willfully, without it being spied away from you. I'm also extremely suspicious of the suggestion that this is something only power users would want.
You can certainly vocalize something willfully. But the people who don't have to do any vocalization at all and are generating megabytes to gigabytes of data on how the application is used by their mere use of it are going to always have a default stronger voice than people who bother to show up on message boards to voice specific concerns.
I actually agree that if you are willing to ignore privacy concerns and a potentially large part of your userbase, then you can simply send megabytes to gigabytes of telemetry and pretend that is the best you could have done and that you have the best data. I'm simply saying that's not a good idea.
> a) It's not a large part of the user base who switches off telemetry and they have the telemetry to know that
So you're claiming that it is typical for software with telemetry support to ignore your choice and still send telemetry about you turning off telemetry? That sounds wrong, but I cannot say I investigated this deeply.
> b) for being "not a good idea", it's pretty much industry standard now for everything from business software to video games.
As I understood the discussion, we were in fact discussing whether this is a good idea and whether it makes sense, so I think it's fair game to comment on it. As for it being an industry standard, that sounds like an overgeneralization. It is certainly not typical of software I use.
> So you're claiming that it is typical for software with telemetry support to ignore your choice and still send telemetry about you turning off telemetry? That sounds wrong, but I cannot say I investigated this deeply.
No; I'm saying missing data leaves holes that can be measured. They know, for example, how many people have downloaded Chrome and how many daily Chrome users they get at google.com (because Chrome will still send a valid UA string if it has telemetry turned off). They can estimate how many users have telemetry turned off from those signals to a pretty decent degree of accuracy; certainly enough to know whether telemetry is telling them about 90% of users of 30%.
For (b), I'm curious what software you use. It's pretty standard in games, online apps, and business software. It's absent in a lot of open-source (mostly because a lot of open-source lacks a centralized vendor who would be willing to pay the cost to collect and interpret that data to improve the software).
Is Chrome's telemetry so invasive that it reports about all URLs visited? Otherwise I don't see how daily Chrome visitors on google.com would be helpful in this estimate.
I avoid online apps, I don't play a lot of games (and if I do, they're not big titles which are likely to have telemetry) and yes, I primarily use FOSS.
> (mostly because a lot of open-source lacks a centralized vendor who would be willing to pay the cost to collect and interpret that data to improve the software).
This is almost surely an element of it, but I think a respect for privacy and a general distaste for telemetry among FOSS users are more important.
It doesn't matter if .1% of users turn off their telemetry, their use case wasn't going to be optimized for either way. In fact the Google employees themselves are part of that .1%, they don't need the data to tell them what's important to advanced users.
That would be nice. They should share that data to help others understand the decision they are making. Or at least they could reference the data in their decision making.
Developers at least the experienced ones never left firefox. For the new developers who got hooked on chrome over the last 10/15 years time to move to a developer friendly browser.
Blink is the most common browser engine. Firefox has some nice developer tools but if you don't test in blink throughout the day then you're just asking for problems.
As the smaller vendor, it's incumbent upon Mozilla to break it. Expecting individual devs to do it collectively when it really isn't in their selfish interests is waiting for a unicorn to appear.
> As the smaller vendor, it's incumbent upon Mozilla to break it.
That's kind of impossible to do for a smaller vendor without wider developer cooperation.
I remember Mozilla only started to breach IE's dominance once devs were so sick of IE that they installed Firefox on their mom's computer despite tons of sites being made for IE.
It's possible for something like it to happen again with Chrome, but less likely since Google's a lot smarter and not too lazy to implement latest tech, so it will sure take longer without some activism and evangelism from web devs.
> expecting individual devs to do it collectively when it really isn't in their selfish interests is waiting for a unicorn to appear
Selfishness is a lot more complicated thing than people give it credit for. A lot of 'selfless' acts could be alternatively described as selfish in that it makes one feel good. Free software developers already do a lot of work for the wider community, where probably it would be a lot easier to just use the proprietary, already feature-rich, counterpart than trying to develop a libre alternative. But the movement understands that long-term, having as much free software as possible is what will in the end help preserve general-purpose computing in the sea of silos. It takes some discipline, sure, but long-term it's actually in one's selfish self-interest.
But that's the thing, if Google is responsive enough to implementing new technologies and improving their browser, there's no reason for most web devs to advocate for an alternative browser. A (high-quality) monoculture is actually much much easier on most web devs, because it minimizes the number of browsers they have to support for quirks.
> A (high-quality) monoculture is actually much much easier on most web devs, because it minimizes the number of browsers they have to support for quirks.
Short-term, sure. Long-term it opens devs to Google's whims and makes the "open" web barely more open than Apple's AppStore.
But that's short-term vs long-term thinking and I can't deny most would prioritize the short-term. Here's hoping there's still enough idealists, even among web devs to avoid that fate and bring about for the web what GNU did for UNIX in the 80/90s.
GNU did great things for UNIX. It hasn't really demonstrated much utility in the user experience improvement space. The flow there, in general, appears to be that the big, closed source commercial interests devise new approaches for user interface operation and the open source community copies the ones that work.
The only space I can name off the top of my head where my open-source architectures have outstripped Windows and Mac in UX is virtual desktops.
If you're taking casual computer experience, KDE's still way more customizable than any of the commercial desktop environments out there.
Of course proprietary software has more funding to hire designers and such, but in terms of actual functionality, I'd contest your claim.
If you're talking developer user experience, it's not even a race. The FLOSS ecosystem has a landslide lead here. In fact the whole point of WSL is to try to keep devs on the Windows platform by bringing that experience to Windows more directly.
Same as saying a benevolent tyrant is the best govt. Viewed from a certain angle it could be arguably true, yet none of us would trade democracy for it because we understand quality and efficiency are not the only factors but need to be weighed with other ethical and social ones.
The history of biological evolution shows that monocultures invariably fail catastrophically. Diversity is the main way to guard against unpredictable events of the future. Software is not exempt from these general rules I'd presume.
I'd be conservative extrapolating from lessons of government and biology to software engineering principles. Software doesn't change via random mutation and natural selection pressure; most open source projects are benevolent dictatorships of some flavor or other.
Sorry to interrupt the party here but I feel compelled to point out that Firefox's is actually the third most common engine after Blink and WebKit. The web is not and will not be a monoculture as long as the iPhone exists. There's already two ~trillion dollar juggernauts involved.
Perhaps Mozilla should never have made breaking changes that pushed people away? The UI change that killed my extensions made me look elsewhere. Chrome's much faster js engine sealed the deal.
I've looked into switching back to Firefox, but what I've found is that they don't allow me to use my own extensions. I would have to use a beta version of Firefox or submit all of my extensions that only I use for approval to Mozilla or have to reinstall my extensions every time I close Firefox. None of these seem good options to me.
This is just simply inaccurate. I have 25 years of web dev experience and left Firefox because Chrome's dev tools were far, far superior to those of Firefox.
Start Firefox in the Profile selector and try using a fresh new profile. Or start in safe mode. Some old, forgotten configuration or addons are sometimes the cause. For example a privacy-enhancing addon CleanURLs disables ETag functionality by default. So all sites using ETag for caching content won't be cached. Big loss.
Not for serious web development (dito for Safari): the developer tools are atrocious compared to Chrome, the battery life experience is way worse with FF, and while Chrome is a notorious CPU and RAM hog, FF is worse.
That combined with both FF and especially Safari being way behind in terms of standards adoption/development really sucks at the moment. Chrome desperately needs competition.
In my experience FF is not behind chrome with new features. It's usually on par, or even better. Sure safari is annoying. But the developer tools in firefox are alright. I even find them better when it comes to debugging css stuff.
Why do you say so with such certainty, though? I find it nearly impossible that you never saw someone claiming the opposite. There's even such a response to your own comment so clearly this experience is not universal.
It's odd that you mention how Chrome needs competition but also decry lack of features in other browsers. That is one of the ways they are attempting to monopolize the space.
The standards are meant to be agreed upon by several parties, including both Google and Mozilla. Google implements new features in order to control the way they work, instead of allowing input by all the parties involved. It's always faster for one company to just do whatever they want than for a group of organizations to come to an agreement on what to do. The slower way results in better and more equitable implementation for everyone though.
I'm already annoyed by the hassle it has become to copy a substring of the URL into the clipboard, due to the schemes being hidden. Nothing has been won by hiding http(s):// as well as the www subdomain.
The URL bar is a disaster for end users. It's full of random junk that users can't read so they stop trying, which means they can then be tricked by phishing websites hosted on any domain at all. Research shows about 25% of users don't look at the URL bar at all even when typing in passwords, they navigate purely by sight, so it's impossible to stop them being phished. The human cost of the resulting hacking is significant.
The fact that the software industry has routinely prioritised historical inertia, the needs of web developers, and all kinds of other trivialities over the security of billions of people is embarrassing. I'm glad to see the Chrome team finally get a grip on this and make the URL bar actually useful for people.
> The URL bar is a disaster for end users. [...] 25% of users don't look at the URL bar at all even when typing in passwords
"Side view mirrors are a disaster for drivers. 25% of drivers don't even check them before making a turn."
[I'll stop the metaphor here, as I think my point was clear]
This change does exactly nothing to improve security. As for usability, it just puts one more layer of paint over the underlying "complexity" - and we've seen before how well that works (see basically every part of Windows 10 for examples).
As someone who has worked on the front line of the fight against phishing and account takeover in the past, I can assure you and others that you're dead wrong. Making this change was a recommendation I made to the Chrome team years ago because the number of people who would reliably type in their username and password to a site hosted on hacked web servers (supershop.co.hk/account_login.php etc) was just so high. And when those accounts got hacked, scamming and sometimes even extortion would follow.
Your side view mirror metaphor is unfortunately not clear at all. The side view mirror is simple and performs its function correctly as designed. It can't really be improved without totally replacing it with something else like a camera. Now of course not everyone will use the URL bar even if it's redesigned to work correctly. But right now the bar is practically designed to look as intimidating and useless as possible.
Perhaps you're so used to parsing URLs in your head you don't realise it, but URLs are a baroque and absurd design that nobody without training could properly figure out. It's basically random bits of webapp memory and protocols splatted onto the screen in a large variety of different encodings. In a desktop app dumping RAM straight onto the screen would be considered a severe bug. On the web it's tolerated for no good reason beyond history.
To give just one example that has regularly confused people in the past: URLs are read left to right except for the domain name (the important part) which is read right to left. You don't stop reading a domain name at .com, you stop reading it at the third slash or possibly a colon, but that form is rare.
As someone who has had to teach grumpy old high school teachers how to not fall for phishing and mitm attacks, I really can't see the problem here.
The way I used to teach was very simple and very effective: there are 3 parts to a URL - the first part tells you if the connection is secure, the second part tells you who you're connected to and the third part tells you where on that site you are. The first part needs to be httpS, the second part needs to be the site you're expecting and the third you can ignore. They're even shaded differently to make it easier to read. "If you're going to Google and the black part ends with anything but google.com, call IT" made sense to even the oldest and most reluctant people I've had to deal with. The problem was actually getting them to check every time and not forget.
It seems to me that this change will not help people without training, change nothing for people with training, and make sharing links even more confusing for everyone.
Are you saying someone is less likely to get phished on "supershop.co.hk" than on "http://supershop.co.hk/account_login.php", even where the http:// part is replaced with a red padlock and /... is grayed out?
I see only one real solution to phishing: don't let users type passwords manually. WebAuthN and password managers both automatically read the domain and won't try to authenticate on a domain that isn't a perfect match. I've had more success with that than any other anti-phishing measure I've tried deploying (history-based domain trust, explicit trust on first use popup, detecting unicode gaps and domains in credential fields...).
Sure, absolutely. People understand domain names, they're found on billboards, adverts, business cards, all over the place. And it's a simple text match. Does the bar say "google.com" or "google.co.uk"? Yes? Then you're on Google. So when it's simple people get used to checking and can be reasonably told they're expected to do it.
The greying out and replacement of padlocks etc, the anti-phishing training, it's all just working around a historical design problem in browsers. There's no need for it to exist. Notably, mobile apps don't have this problem.
Even when the scheme is visible I have problems copying a URL substring. Chrome always wants to select the ENTIRE URL instead of just the subpath I'm double-clicking... endlessly frustrating >:(
I had a frustrating experience with this only yesterday.
I was trying to search for the word "aquarium" but chrome kept filling in "https://aquarium.org", I would delete the ".org" and only the word "aquarium" was shown in the search bar, which was the word I was trying to search.
Of couse "https://" was hidden, so I was actually submitting "https://aquarium" which was not a valid domain and it took many frustrated clicks and enters to actually google the word that was shown. Absolutely infuriating as the true state of the search bar was hidden.
It's a pretty obvious solution, especially to any programmer.
I'm having a hard time thinking of a situation where you have information, some more important and some less, where the correct solution is to delete the less important information. It still has importance!
What you described is more like highlighting the function signature in one color and the entire body in another. Syntax highlighting for the URL would be more like domain/subdomain in one color, emphasising query fields in one color and params in another, with colors potentially varying potentially based on their type/significance.
That might help make the URL more readable but again doesn't really help if the relevant parts of the path/query string for trust isn't immediately apparent.
Using color to convey information is very difficult to make it be accessible while still working with themes and being aesthetically pleasing at the same time.
If their goal is really to help detect fraudulent sites (the sorts of google.com.notahacker.tk), they can just show the domain in a more prominent way -- they're already deemphasizing the part of the URL after the domain name anyway.
This is clearly not their motive.
What Google is trying to do here is to drift the web from its most iconic components: the URL. This is the biggest threat to the web that we loved for so many years.
I honestly don’t think people are paying attention to the URL bar, at least not the people this feature it trying to protect.
If it looks like Google.com, then it Google.com. The logo even says so.
It’s a dumbing down of the internet, in an attempt to help the average user, but it won’t work and you’re just making life harder for those who know just a bit more then average.
What the heck? A regular user doesn’t understand or care what the technical difference between a “regular” page and AMP is. I wouldn’t call this ignorance per se.
Not knowing and not caring is the very definition of ignorance.
Sometimes I wonder if feudalism must have felt like this from the perspective of the noble people. Will there be a dark age followed by enlightenment? Because right now we seem to encounter self-imposed nonage.
I'm pretty sure regular people can tell the difference between a regular page and an AMP page. The AMP page simply doesn't work right and it's quite difficult to miss that.
Just because they don't care doesn't mean exploiting their ignorance is okay. I don't know that I agree with the GP that this is a targeted move to get AMP to slide under the radar, but if it is we should totally care. AMP undermines the fabric of the web. Just wait for the day that Google starts serving AMP for sites that aren't even configured for it. When they serve an AMP page, they are doing more than being a middle man, they are controlling the traffic and the display of the site, and the user is none the wiser. Google penalizes you for doing the same thing, specifically because it's nefarious.
Word! Frankly at this point I'm even starting to think that the whole weird "SJW" angle of this thread is also disingenuous and taking us away from the boiling frog death of the Internet, replaced by AMPed up centralized comoditization of users, with death to all liberty and openness.
In fact, I think the evidence is not only overwhelming but the tech community is thoroughly comprimised, proven so on account of all the recent purges and attacks on wrong-think.
> While some 19th-century experiments suggested that the underlying premise is true if the heating is sufficiently gradual, according to contemporary biologists the premise is false: a frog that is gradually heated will jump out. Indeed, thermoregulation by changing location is a fundamentally necessary survival strategy for frogs and other ectotherms.
I assume the goal is to make sure that people never remember the URL and always use Google to get anywhere. Most people probably already do, but maybe increasing their number from 80% to 90% is still worth it.
If this is indeed the real motivation, the next obvious target would be bookmarks. What can be done about them? Replace the bookmarked URLs by Google queries? It would be an interesting functionality if Google could look at a page and give you the smallest query that would have returned exactly this page as a first result. Then bookmark the query instead of the URL. And if the search results change in the future... I suppose, it would be possible to spin this as a feature. ("Self-improving bookmarks" perhaps? You don't have to worry about link rot; with latest Google self-improving bookmarks, your bookmark will always point to the best existing page on given topic!)
> give you the smallest query that would have returned exactly this page as a first result
Just out of curiosity, is there a publicly accessible Google service, or a third party service, that does this? That would be useful to find more content or point-of-view about a topic (by looking at the other results)
The bookmarking functions in chrome are already extremely weak, I guess for the reason you point out. No tagging, only folders, results when searching don’t get top position in the omnibar.
Bookmarking is one of the areas where firefox is clearly superior.
Same for the history, I much prefer it in Safari than Chrome. It looks like Chrome make it worthless on purpose so that we use Google instead of looking through our history.
And what’s worse is that none of the other Chromium browsers change it, it really is the worst history/bookmarking UI out there. Firefox’s isn’t much better as it feels plucked straight out of 2003.
It made the Safari 13 Extension-pocalypse so much harder to bear. Every browser I can pick from has something important I have to compromise on.
> Google could look at a page and give you the smallest query that would have returned exactly this page as a first result
Maybe like a decade ago this was a student project that Google sponsored (maybe as either Summer of Code or some precursor to that). A student group developed a system for “tagging” a page with a series of “random” but memorable words that could be used to identify a page. Kinda like how imgur and other other sites generate URLs now. Like “glittery hamster bananas” or something like that.
Maybe this is just one of those pet issues that I can't get behind. Hiding "www" does not strike me as some evil scheme to prevent savvy users from bookmarking websites. It just doesn't.
They already had the feature you are worried about and it's existed since like 1999. Do you remember the "I'm Feeling Lucky" button? You could bookmark a query and it would redirect you to the first result for that search. It was discontinued in 2010 [Wikipedia].
I feel like there are a lot more sane things to be paranoid about in the world right now, but mandatory "I'm feeling lucky" doesn't reach my top 20000.
"I'm Feeling Lucky" was never discontinued [https://www.google.com]. It just got moved to the bottom of the autocomplete list that appears when you start typing.
A better comparison would be mybank.com/logmein vs mybank.com/login vs mybank.com/l.jx?s=AU8NE6FX5IKMD2
And no, users do not need to care the slightest whether they go to the first, second or 3rd URL.
What they care about is that they are entering their sensitive information on mybank.com's domain and not a russian counterpart, that's it.
That URL is utterly indecipherable by 99.99% of Internet users, so displaying it in full does absolutely nothing to protect users.
The onus to protect against a website takeover is on the domain/server owner, certainly not on the browser vendor although they try to mitigate simple attack vectors.
> Well, it switches that 99.99% to 100% now, so a step backwards.
Refraining from collecting malicious links happens before you click, by the time it's in the URL bar it's already pretty late to mitigate against attacks.
No, they already were doing that by using color to make the other parts less prominent. There is no good explanation to to this change than making people rely more on Google search.
It still feels like you dove into the deep-end of the data collection conspiracy pool before considering other more-likely explanations, like "They have the information now to know that, in general, using color to make the rest of the bar less prominent wasn't sufficient to minimize users feeding data to malicious sites."
Bad analogy. AMP is a Google content proxying technology, and Google isn't generally understood to be a "sketchy site."
Users with the level of paranoia that puts Google in the "untrusted site" space should be sidestepping this whole conversation by avoiding using the browser Google develops regardless of what Google does to its URL bar.
> AMP is a Google content proxying technology, and Google isn't generally understood to be a "sketchy site."
The whole idea of AMP pages is sketchy by default, as it's Google taking content from websites run by news media outlets and hosting it on their own servers so they have even more control over user-tracking.
In the long term, this has the potential to further centralize the Internet, something the Internet was never meant to be.
It's not that difficult to imagine a future where news media won't even host their own stuff anymore but instead outsource it all to Google.
Very comparable to how Facebook has become the de-facto place for small businesses, with little to no IT knowledge, to have their own little web-presence.
Which has certain advantages, but it's dangerous to belittle the very real disadvantages that kind of centralization of content will have in the long term.
Again, people concerned over this risk scenario should be switching to another browser regardless of what it does to the URL bar, right? I doubt we're going to find many users who's thought process runs "I'm really concerned about the long-term risk of Google building a dystopian information warehousing monoculture, but I was still going to use chrome. But now that they're changing the UI to, I assume, support their goals of building a dystopian information warehousing monoculture, it's A BRIDGE TOO FAR."
But switching to another browser does nothing to challenge AMP, as these changes are mostly pushed on the server-end while changes to the browser end, like this one, serve to further obfuscate this consolidation of Google's dominance on the web.
In that context, it's a bit cynical to belittle the problem as you are doing there when this has been a very real issue for several years. As by now Google, Facebook, and Amazon control the vast majority of web traffic and have been doing so for years already [0].
This isn't some hypothetical scenario, it's something that's already very real.
>people concerned over this risk scenario should be switching to another browser
IMHO it's our duty as technical users to advocate for a more private, open and de-centralized web for everyone.... We should especially be doing it on behalf of the users who don't understand the long term implications of Google's (anti-) features.
'Just switch to another browser if you don't like it' is not a compelling argument.
That's fine. In my humble opinion it's our duty as technical users to build a web that is both safe and usable by non-technical users. Sometimes we do that via improved privacy, more openness, and decentralization; sometimes we do it by centralization (lists of threat websites, certificate chains of trust baked into browser defaults), less privacy (expecting users to authenticate before making meaningful changes on sensitive data or people's money), and more closed architecture (ad spam countermeasures).
The URL bar takes up a huge amount of screen real estate and is a piece of information that the user almost never needs once they have confirmed they navigated successfully to the desired page. Developers are a special case user and capable of handling advanced UIs that hide information until it is needed.
It's iconic but it's a UI space resource hog. To improve browser experience, sometimes one has to be willing to try slaughtering a sacred cow.
1) I'm not generally in the habit of prognosticating all of the reasons a corporation the size of Google tries to do something, especially not when there's an apparent and obvious win possible from the change itself. Minimizing the URL bar leaves room for other things on the page, including chrome extensions and, possibly, page content.
2) UI improvements are not "cosmetic reasons," they directly translate to ease and efficiency of task completion. As a UI engineer, hearing my category of work called "cosmetic changes" can be, quite frankly, exhausting. If someone were to halve the default font sizes on all browsers, would we consider that a mere "cosmetic change" or would it be a change that would have direct and immediate impact on people's ability to accomplish tasks?
Well I'm exhausted by UI/UX engineers oversimplifying things that are inherently complex. To the point to not really helping people simplifying their work and totally hindering advanced user. There is a reason industrial UI usually don't suffer this, because complex interfaces are there for a reason.
You know what else is "a UI space resource hog" on the web ? Advertising. And I'm sorry but "wasted" space is generally much bigger. So, no, I'm not ready to loose my address bar for bigger ads.
There's a reason most commodity software doesn't adhere to industrial UI standards.
Chrome is well into the commodity software scale, and one should assume its UI decisions will lean in the direction of maximum utility for the most users.
Hmm, don't all mobile browsers already autohide the URL bar when the page starts scrolling up? Seems like that worked fine so far. Besides the OP is about hiding part of the URL (path), not the URL bar of the browsers.
The URL can already be longer than the screen to begin with, so they could still do that and show as much as will fit, showing the rest if you click on it. This is already what Firefox does.
But from a UI standpoint, having a text box that is too small for its common displayed content is sloppy. If the path usually makes things too long, hide the path by default until the user asks for it.
But that's useful information that's told me redundantly by the page title and the banner at the top of the page also. I don't need the URL bar for that.
In fact, using the URL bar for it assumes that the path has semantic meaning, which is not an assumption that the URL standard actually requires.
> But that's useful information that's told me redundantly by the page title and the banner at the top of the page also. I don't need the URL bar for that.
The page isn't required by anything to contain that information or to give it accurately. How do you distinguish example.edu/financial-aid/ from example.edu/~some-student/ ?
> In fact, using the URL bar for it assumes that the path has semantic meaning, which is not an assumption that the URL standard actually requires.
It doesn't assume anything, it just shows you the URL. If it has semantic meaning then you can see that -- which it commonly does.
> How do you distinguish example.edu/financial-aid/ from example.edu/~some-student/
That's an unrealistic example because no website worth its salt is going to let students put arbitrary content in the same domain as the financial aid system. That's a recipe for leaking cookies that contain session tokens, and displaying a full URL won't save a user.
By the time you see the ~some-student in the URL bar, the security game is over.
It could be that example.edu/financial-aid/ is just information and PDFs and doesn't have any sessions or cookies. Or the real financial aid system is on another domain, but a first time user doesn't know that, they're just looking at www.example.edu/~some-student/ which appears to be a financial aid page that Chrome only says is example.edu.
Or any other case where the contents of the URL matters. How about example.edu/~some-student/ vs. example.edu/~a-different-student/ or example.edu/~your-professor/?
That hypothetical naive first-time user is going to be as fooled by ~financial-aid, or by ~some-user/financial-aid. Showing the full URL path doesn't fix that risk scenario.
The other scenario you describe, if the risk is someone intentionally deceiving users by cloning a page on the university network owned by someone else for deceptive purposes, is better solved by a university disciplinary hearing than by expecting every student to understand URL paths.
> That hypothetical naive first-time user is going to be as fooled by ~financial-aid, or by ~some-user/financial-aid.
The attacker may not be able to get ~financial-aid, only ~juan-ramirez, and even if you don't know about home directories, the first thing that strikes you about ~juan-ramirez/financial-aid is that something is wrong because you are not Juan Ramirez. If you do know about home directories then it's a giant red flag which you can't see if the browser is hiding it from you.
It doesn't have to prevent 100% of attacks. Preventing 7% of attacks is still 7% better than nothing.
> The other scenario you describe, if the risk is someone intentionally deceiving users by cloning a page on the university network owned by someone else for deceptive purposes, is better solved by a university disciplinary hearing than by expecting every student to understand URL paths.
The most common way things like that happen isn't the actual student who would have to be using their own name, it's that the student uses a weak password or gets their computer infected with malware and then some Russian hacker sets up on their school account.
You also don't need every user to understand them, only one who then reports it. If you don't show the paths to anybody then much more likely that nobody notices, or that it takes longer for somebody to notice and more people get compromised in the meantime.
> the first thing that strikes you about ~juan-ramirez/financial-aid is that something is wrong because you are not Juan Ramirez
User studies indicate that the first thing a user notices is... Nothing. The gobbledygook in the path is so much noise for the average user that they don't notice if the path seems off. In fact, it makes sense to hide it from a security standpoint to decrease the odds that users go information blind to the domain, because we already know that improper domain routing to lookalike domains is, by far, the most common vector for credential theft.
There isn't even a guarantee that showing the path to address the 7% case (which really looks like more 0.07%) will on average cause the incidence of users being compromised to go down, if it means users are less likely to notice that the subdomain and domain are off.
I'm sure that for the people who really care, it won't take long to hack together a chrome extension that drops the full URL into the page title or a pop-up box on the page itself.
> User studies indicate that the first thing a user notices is... Nothing.
There are a thousand ways to screw up a user study, but one of the best ways to detect a screw up is if they say that users either always or never do something.
> In fact, it makes sense to hide it from a security standpoint to decrease the odds that users go information blind to the domain, because we already know that improper domain routing to lookalike domains is, by far, the most common vector for credential theft.
Which is why it makes sense to highlight the domain. Make it a different color. Make it a bigger font size. That still doesn't require you to omit the rest of the URL.
> I'm sure that for the people who really care, it won't take long to hack together a chrome extension that drops the full URL into the page title or a pop-up box on the page itself.
Except that the people who actually do that really are the 0.07% and you've still lost the 6.93% who would've noticed if you'd put it in front of them but aren't about actively change the default you gave them ahead of time.
You're using concrete numbers but you don't have the statistics or analysis to know what the numbers are. I'm going to assume the company that has telemetry on its own product does.
... but probably more importantly, nobody likely needs to hack together an extension after all. Older news story about how Chrome will add an option to show the full URL bar as non-default.
Seems Firefox previews doesn't, and I honestly prefer it that way. They moved it to the bottom of the screen which makes it easier to use and less intrusive.
To improve browser experience all you have to do is use a computer that doesn't suck. The fact that your primary browser is on a tiny phone display is a problem with phones, not with browsers. Browser for phones can evolve to match the disabled nature of their device's but lets hope such gimpings don't filter back into actual desktop computers.
I'm actually not thinking about the phone form factor at all. A shorter URL bar in the desktop allows for to take up less horizontal space, which leaves more room for chrome extensions.
Also, "use a real computer" is a pretty elitist attitude that misses Google's goals overall. Google is not targeting exclusively users that have desktop machines with multiple cores and graphics accelerator cards. They want to provide internet services and internet access to people whose only portal to the web is a mobile device.
Oh, I'm not missing that. Google's software offerings are now primarily designed for bad computers with bad UI, bad network, and bad energy storage. Because people love those crappy devices and most use them primarily. We both agree.
>A shorter URL bar in the desktop allows for to take up less horizontal space,
Which really doesn't matter if you're on a desktop computer with an actual monitor. The only reason to do this is more "convergence" BS and thinking phone crutches are required on desktop.
Agree to disagree, because my primary device is a multi-core desktop with a curved monitor over two feet long and I still think the URL bar takes up too much horizontal space in my browser top bar.
The problem is maybe, a widescreen is bs for most things anyway. In most applications there is so much emtpy space on the left and the right side.
I use not just with monitors because of it, they are also height. 43" 4K is nice to work with.
"Spend more money on your computer" is a fine solution for a bay area software engineer. It's not a solution at all for the half of America that would have to sell their car to cover a $400 ER visit.
I make under $12k/year. I live in the midwest. I would have to sell my car for a $1k ER visit.
It's still cheaper to build a $450 real desktop computer (that lasts decades+) than it is to buy a $800 4 year life gimped smart phone that can't do any productive work any isn't in my control.
(And my $20 nokia dumb phone has worked perfectly since 2006 for phone calls/text.)
You live in the midwest United States; you're not the user we're talking about.
We're talking about the person in small-town India who has a Micromax Black Q385 spark 3, 8GB store, 1GB ram, 5.5" screen, which they bought for $50. They also get their Internet access through the cellular equivalent of a drinking straw.
(Even still, my personal guess is that this URL bar change isn't about them; it's about the desktop experience).
> What Google is trying to do here is to drift the web from its most iconic components: the URL. This is the biggest threat to the web that we loved for so many years.
Safari has hidden the full URL since 2014. For the vast majority of users, the full URL is just noise.
Pretty ironic for a company that wouldn't exist except for the ability to crawl and index URLs. So now only the domain and TLDs are to be shown. I presume that a "full" URL can be typed once the URL bar is clicked though? But any guesses how long until they remove the ability to enter URLs?
732 comments
[ 3.6 ms ] story [ 436 ms ] threadI can even argue that if you take away the path from the URL, then it's actually easier to spot a phishing website since all you see is the domain if you don't hover over the address bar.
If domain-owning organization fails to prevent a third party from hosting a phishing site under a path or a subdomain, that third party is likely well-positioned to deface the existing pages. With a subtle alteration (scripts that capture credentials and transmit them out), the existing pages grant an attacker all of the users with no extra effort—as opposed distributing a link to a fake page, convincing the user that the page is legit, and in the end getting a fraction of the user base.
Now… well, IE11 doesn't even support ES6 properly, and good sites have started relying on that, and Edge is just evil Chrome – unless it's got Firefox installed, Chrome's your only option. But sites that use Chrome-only APIs aren't worth using anyway.
(Oh, wait, Zoom needs either Chrome or a malwarey desktop program.)
And there are alternatives to Zoom, e.g. Jitsi.
...and the malwarey desktop program is also Chrome.
I also don't understand why everyone is up with pitchforks at Google on this when Apple did the same thing to URLs a while ago. I guess engineers are just as susceptible to groupthink as anyone else.
They do kind of do that. Rather than going through the consensus process for getting a web standard added, they implement it in chrome then unilaterally write a standard for themselves. See for example, the SGX (signed exchange) "standard" they pushed out.
Do you think IE6 was bad? Remember how long it took to get rid of it? Imagine a world where the monopoly leader doesn't just walk away from the browser (which is what MS did with IE6) but actively abuses the situation. It will be orders of magnitude worse. Say hi to amp. Say hi to chrome. Say hi to google. Say goodbye to the web.
I suspect a lot of people in this conversation are not old enough to remember, even if they wanted to.
Maybe universities should have an obligation to promote nonprofit tools (i.e. Firefox) rather than shady commercial software that only happens to be gratis.
I think this feature is important enough for me to consider switching this time.
That being said, I admit that staright out of the box Firefox doesn't have the same experience but you can customize every little thing about it to make it suit your needs.
This said, I honestly don’t understand what people mean when they say the experience is “superior” in Chrome. It’s a web browser. It browses. You get passwords saved and synchronised. Everything else is an extension. What’s so bad about FF...?
I just could not live without firefox and being unable to share tabs/links from anywhere in my phone to my desktop and or laptop
I hate the hell out of that. My phone is my phone, my laptop is my laptop, just leave them alone.
It also felt noticeably slower at the time.
Finally, with Chrome's market share, good extensions that Just Work are more common there, in my experience. I use a whole host of plugins on desktop, and when I looked at switching back to FF last year, I did not find equivalents for everything.
I did go back to FF on mobile, because I do remember the nightmare of IE 6 and want to protect the web from total Google control. On mobile, I miss the dev tools and array of extensions less.
As for bookmark, firefox should be able to import chrome bookmark. It can even import saved passwords and cookies so your active session is preserved.
https://github.com/AlessandroZ/LaZagne
I don't think Mozilla's trying to please Google in any way. Google's keeping Firefox around to try to avoid the appearance of a total monopoly.
But Mozilla's behavior certainly is influenced by trying to find alternative business models, sometimes not perhaps with the best results, (Mr Robot promotion everyone), I still think it's worth using it over Chrome.
Did you know that Apple does in fact get more money from Google than Mozilla does, for keeping their search engine as the default? 12 billion dollars in 2019. Do you think Apple would activate ad blocking by default and risk losing that many billions of dollars? Speaking of which, Safari's ad blocking is the joke of the industry.
You could make the case that Safari might survive if Google cuts its funding, but judging from the history of IExplorer, I have my doubts. One could make the case that Safari is alive just because Apple is making a shit ton of money on it.
Did you know that Microsoft's Bing Ads platform made them 8 billion dollars in 2019? Do you think Microsoft would do anything to jeopardize that ads revenue? Did you know that Windows 10 has an "advertising ID" used to personalize ads, that via Edge is transmitted to Bing?
Did you know that Brave, that leech which is piggybacking on other people's work, that's supposedly blocking ads by default, is effectively replacing publisher ads with their own, then forcing those publishers to enter into deals with them for a piece of the action, while making it really hard to detect and block Brave? All the while pushing shady cryptocurrency affiliate ids straight in their source code?
---
Mozilla might not push for ads blocking by default.
But they do block trackers by default and their browser is afaik the only one that has legitimately supported uBlock Origin on top of Android. And uBlock Origin is the best, most aggresive ads blocker available and given Google deprecating the blocking ability of the WebRequest API, Firefox might remain the only one with a uBlock Origin implementation.
Could Firefox survive without Google?
I don't know, but can any other browser survive without Google or Bing? I have my doubts and you'd be naive to think otherwise. Plus this is just whataboutism.
Brave does not depend on Google, directly or otherwise. They depend on an open source project called Chromium, which is largely developed by Google, but because it is open source anyone can build off of it.
Brave funds their development through the BAT token and through affiliate marketing, both of which are much better for user privacy and security, and much more resilient to Google than where Mozilla is getting its money.
No, I don't think Apple would integrate thorough ad-blocking by default, just as I don't think Mozilla will do this either. Brave has already done it. Brave's ad-blocker works better by default than any ad-blocker I've used, and I've tried them all.
HN's hate-boner for Brave is very strange. They clearly care more about user privacy than any other browser vendor (except maybe Safari, but again they have a conflict of interest), and it is built on a core that is arguably the best at handling the modern web (Chromium).
Microsoft wasn't able to keep developing a browser on their own, I doubt that Brave could. The problem is that a browser nowadays is so complex to develop that you need serious resources to invest in it. Without Google's ongoing development, Brave would not survive. And given Google's changes to undermine ads blockers, it's going to be interesting to see Brave struggling to maintain their fork.
---
> much better for user privacy and security
Right, keep telling yourself that.
Btw, I actually wonder how what Brave is doing isn't copyright infringement, given they are directly profiting from blocking the ads of publishers. I guess they are small enough to not matter, for now.
---
> Brave's ad-blocker works better by default than any ad-blocker I've used, and I've tried them all.
I worked on anti-ad-blocking technology.
Nothing beats uBlock Origin running on top of Firefox, everything else was strictly inferior. Not even blocking JavaScript in the page, because you can easily force the user to enable JS for you by breaking the content on that page. uBlock Origin is so bad that we avoiding it entirely, being useful for people frustrated with AdBlock Plus to turn to, sort of like in the Matrix.
IE was woefully out-of-date. MSFT then tried to build a browser from scratch. That was a lot of effort, so they decided to fork Chromium (like Brave) instead. What exactly do you think would happen in Google dissappeared tomorrow in their case? Do you think they would go back to trying to build their own browser from scratch? No, they'd just keep developing Chromium. Many (most) changes would probably be upstreamed. Forking a browser and maintaining it is orders of magnitude easier than starting from scratch in [current year]. As you point out, there are not multiple parties building on Chromium, so I'm sure slack could be picked up if Google switches gears. But you're right, maybe Brave won't be able to keep up with upstream changes that make ad-blocking harder. In that case, you can always just switch browsers. In the meantime, however, I'll use the browser that does a better job of protecting privacy by default.
> Right, keep telling yourself that.
Luckily, I don't need to. A browser that blocks ads by default is objectively better for user privacy and security than one that doesn't.
---
> Btw, I actually wonder how what Brave is doing isn't copyright infringement, given they are directly profiting from blocking the ads of publishers. I guess they are small enough to not matter, for now.
They aren't directly profiting off of ad-blocking, so maybe that helps.
---
> I worked on anti-ad-blocking technology. Nothing beats uBlock Origin running on top of Firefox, everything else was strictly inferior.
Have you actually tried Brave? Works better for me, and I've tried Firefox with uB0. Have also tried Chrome with uB0. Brave blocks both ads and tracking more consistently across the board. It occasionally breaks a webpage, but I have reported those to Brave and two of them have been fixed (out of like 5). This process is clearly better for users than everyone having to configure their uB0 Matrix and such separately. Brave is creating a web where all the privacy violating / attention grabbing shit is very much blocked by default in a much stricter way than other options. When this breaks the internet, they fix it and because this fix is part of the blocker it fixes it for everyone.
"Updates" may be, large, architectural upgrades? Doubt it. There's a reason they didn't start fresh and I very much doubt they'd muster the resources to maintain development were Google to drop it. Google has invested billions, probably tens of billions into Blink engineering.
What I could see happening is Brave forming some sort of a coalition with KDE and the wider open-source community in the better case or trying to switch to WebKit in the worse case as that is exchanging one corporate overlord for another.
Not to mention Brave's VC funded, so they'd want some form of a meaningful exit at some point.
The bigger concern however is not that Google will not fund Blink development, but that it will increasingly implement features that primarily benefit itself and Brave, as a dependent player, will be spending an increasing amount of resources trying not to get eaten by Google's "direction tax", as all developers depending on a 3rd party corporation they're in some sense competitors with find out eventually.
See also Twitter 3rd party client developers or the many AppStore devs Apple burned and ruined their business overnight.
And its content blocking, speaking both as a user and as somebody that worked on anti-ad-blocking technology, is really easy to circumvent and only useful on websites that haven't adapted yet.
As an iPhone user for me it's bad enough to make me want to switch to Android. What works consistently well has been DNS-level blocking (Pi-hole, NextDNS).
For you it might be OK, but I can tell you Safari is a favorite among the big players in this space [1].
[1] https://www.betterads.org/members/
> I never switched away from Firefox.
I switched to Firefox... from Netscape/Mozilla.
Edit - found it: the setting "browser.urlbar.trimURLs" hides the "http://" protocol if it's used. I do a lot of local development and found it annoying that Firefox was hiding it.
I hope I'm just being alarmist.
I don't know if there is a way to "bless" such an authority once it's added to the trust store.
When I wrote the message I wasn't in front of Firefox, now I am. So to summarize:
* The CA's certificate is added to the Firefox store and trusted.
* Visiting a site gets the lock in the address bar.
* Clicking on the lock in bar shows "Connection secure. Connection is verified by a certificate issuer that is not recognized by Mozilla"
Screenshot: https://imgur.com/a/T4rznXK
This list is necessary anyway, because you have top level domains that look like .co.uk, so you can't just split the domain name by dots and take the last component to determine the top level domain.
So, not saying I unconditionally like the fact they are hiding important information in the URL bar, but I would not say their default behavior is that broken.
[1] https://publicsuffix.org - probably the list being mentioned in the video linked by the parent commenter, I guess
You don’t have this issue at all for domains that don’t have a www subdomain.
Furthermore it would be extremely confusing to have different content for www.example.com & example.com.
My company uses DNS load balancing for a root domain, though, so either I'm misunderstanding you or you're mistaken about what's possible here.
We use Constellix's DNS management to have round-robin DNS via multiple A records for 'nxtbook.com'.
If you're thinking of some other form of DNS load balancing, would you please clarify?
Edit: another common use case is hosting your static website on S3 or github pages. Typically it's done by adding a cname entry to s3 or github.io (been a while so hopefully I remember it right). You can't do this on root, unless you're using another server as reverse proxy (e.g. cloudflare's cname flattening service). Again, it's benefits cloud vendors (cloudflare got more potential customers by offering this service for free) but ultimately hurt people that want to host their small websites.
Definitely simpler, and a good argument against using the root domain.
Thanks for clarifying!
But why?
But www.example.com isn't necessarily the same website as example.com.
As a practical example, the website for my current employer had not configured their "bare" domain. When applying for a job I decided to check out their website, and copied only the "bare" domain and pasted it in my browser. Didn't work, just timed out.
I tried a few times and through "huh, website down for a few days, that sure doesn't look good". Then on a whim I figured I might try the "full" domain, and sure enough that loaded up straight away.
One of the first things I got done when I was hired was to ensure the "bare" domain worked.
If I want to be on www.example.com and I'm actually on example.com, then yes I can discover that by looking at the URL.
I feel like I'm going in circles.
They're two different web pages. Possibly with entirely different information. Possibly run by entirely different people. Possibly with entirely different trust levels and threats. It conveys which of the two web pages I'm looking at. How is that not useful information?
The specific of how you've decided to run your site or serve your pages is irrelevant. You may serve a page depending on if the http request came over port 80 or some other port or via http or https or at this time or that time or other.
www.example.com and example.com might be two different websites.
If you want the content at www.example.com and you go to example.com, then may not get the content that you wanted. One might be a shop selling shoes and the other might be a shop selling hats.
If you want a hat and you go to the one selling shoes then you're going to be disappointed.
'www.' doesn't 'mean was HTTP accessible'. You can make any system HTTP accessible, or not if you want to.
It doesn't matter how you or I set up our websites, or whether you or I think it's a good idea to have different websites at these addresses, it matters how other people set up their websites and if they choose to do this or not. Some do! Therefore the user needs the information.
You could send different websites based on what port the request comes from. But doing so would be bad and wrong, and showing the user the outgoing port is definitely not necessary.
But that's you controlling that, as the person running the website.
When it's the user controlling it, by setting which domain to visit, that's in their control, so they need to see it in their UI.
If you're going to reduce to the absurdity of 'anyone could serve anything from anywhere' then why show a domain at all? ebay.com could serve me the content of google.com, so let's not bother with domain names? Is that your argument?
I'm not making an argument about what should be shown right now, I just think your argument, based on what "might be different", is pretty flawed.
But there's no standard that requires this, that I'm aware of.
Chrome are acting like there is, but I believe there isn't.
So yeah, hiding www is annoying and confusing in this situation, because Google just assumed something about the web/domains and forced their assumptions on everyone.
A screenshot of the browser will not show the www, making it more difficult to find the website.
At this point, That's just sloppiness on USFCA's part.
Can I pull that off in FF?
Interesting. Other comments in this thread indicate that the only extension that can do this has its ID hard-coded in the url parsing code to be whitelisted.
1 - Selecting multiple tabs and saving to bookmarks: you can't add to an existing folder without creating a subfolder.
2 - Add keywords to bookmarks: no way to filter bookmarks that have keywords. Also, when typing on the address bar, the keyword doesn't get highlighted or anything
3 - can't add a custom search engine. You have to add its extension, if available. Or add as a bookmark with a keyword, but then you won't be able to see a list of all search engines...
As a full time, happy Firefox user, this annoys me to no end, increasingly so as there are more and more competing search engines that I want to try.
I’m pretty sure that you used to be able to add arbitrary search engines too (by specifying the search URL with %q for the search query). It’s amazing to me that they would remove this.
Not only that, but on Chrome I have Amazon, Youtube, Reddit, all setup as search engines. For reddit, besides 'rdt' for general search, I also added keywords for searching inside /r/anime, /books, /ps4, and a few other subs I occasionally search.
I also think they used to have this, as Chrome still has. But no idea why they changed it.
For example if I were to go to something like https://raw.githubusercontent.com/<user>/<proj>/<path> or
the most relevant parts of the url as far as security/trust is concerned is the domain githubusercontent and <user> not the raw subdomain
https://publicsuffix.org/
What's taken you so long ?
Here the address bar would show "(padlock) [Github Inc] Github.com > Name Of Account > Name Of Project" for example. This is much clearer for end users.
Developers can always toggle an option to always show the URL or something.
Personally I quite like it. From what I understand the main goal is to make phishing attacks more clear to the user, since this is ultimately only a thing the end-user can protect against. Removing the noise definitely helps for that.
Having had it like this in Safari for a long time, I must say I greatly prefer this over the older behavior---the only time I care about a full URL is when I select it to copy it.
How are they better than those in Firefox? It looks like you did a thorough analysis.
Unless you need to modify the URL often, but it has the hover behavior and if even safari has an option for it, I can't see google removing that option.
[0] https://youtu.be/0-wB1VY3Nrc
Hiding the https and www is already frustrating enough, and this change would make Chrome barely usable for my purposes.
They explain a number of reasons why it is difficult for people to extract from a URL the part which is relevant to security, ie. the bit that affects who has authority over the page and how your cookies will be separated by the browser. The cookie sharing actually had some rules I didn't know about as a non-web developer but experienced URL user. They show how every browser is already going some way towards this but they all have some problems, for example Safari shows the full domain not just the important part.
Basically any page on the website with this vulnerability will be useable to show a fake login page, and user will not even notice he's not on the /login, but on some weird path + ?_sort=somejavascript
Not that it's that hard to clean up url via history api after you get access to the page via XSS atm, but there's still some short period of time where the full url is shown in such a case, that may provoke suspicion.
https://www.xda-developers.com/fix-dns-ad-blocker-chrome/
seems that the problem is not async itself, but that chrome ignores the system DNS settings and uses googles own DNS servers instead.
Google's async DNS feature uses Chrome's own internal DNS resolver which doesn't call gethostname(). It would be incorrect for Chrome to parse this file and attempt to "respect" your settings because NSS is a series of black-box system-specific modules. If you removed the dns module from /etc/nsswitch.conf then resolv.conf wouldn't even enter the mix on your system and then Chrome would do the wrong thing. If the dns module behaved differently on your system and /etc/resolv.conf was actually /etc/resolv.json or /etc/resolver.conf then Chrome would again do the wrong thing.
When resolving a name applications have two choices, either look up the name with glibc, send the request through the NSS gauntlet of black-box modules and take whatever it returns of perform the DNS request itself and ignore everything on the system. Any sort of hybrid approach would be more confusing.
A DNS client looking at the list of servers, and marking the speed and reachability of each server is the most basic optimization. It makes no sense for clients to add n seconds to every request for every unreachable DNS sever.
The async DNS feature using Chrome's internal DNS client which behaves differently than glibc and so pihole appears to not work. Chrome is not injecting its own DNS servers into the mix or whitelisting anything, it always uses your system's DNS servers, it just looks them all up in parallel which it is allowed (and encouraged) to do by the RFC.
Make sure all your configured DNS servers are pihole and everything will work.
This enables you to right click on the address bar, and turn on the option "Always show full URLs". It will always shows the full URL including the protocol, but I suspect they will remove this flag at some point.
This drives me crazy when debugging. Whenever I copy-paste IP addresses from the browser address bar into my console, I have to manually delete the `http://` at the front. I work on a P2P project so this is an extremely common situation for me.
Another solution for Windows and macOS users (no Linux sadly) is to use Edge Chromium, which does it by default, and you prefer to donate your data to Microsoft rather than Google like me :)
I personally don't care much what the default is for the normal user, but I want to be able to have my full urls.
Is there also a #upgrade-to-firefox-immediately flag ?
Seriously, I keep looking at the address bar to make sure the URL is still there and I'm not dreaming.
Now how does this new flag interact? Has anyone enabled both to see?
1: https://bugs.chromium.org/p/chromium/issues/detail?id=106157...
2: https://bugs.chromium.org/p/chromium/issues/detail?id=883038...
https://developers.google.com/web/updates/2018/11/signed-exc...
Really my point was in jest. I think we need to trash the entire www and start again with something content only focused and hard same-origin policy and far far far lighter than what we have. I tried browsing the web on a dual core celeron N3010 recently and it was unusable on all mainstream browsers.
But my understanding is that they intend to use signed exchanges specifically for their amp URLs, finally finishing their efforts of forcing people to go to google.com without them ever having realized it.
Two recent examples off the top of my head are the recommended stories on the new tab page and the ability to disable images appearing in the omnibox.
It reminds me of a company which developed a product which was more or less done. So the SWE manager and the product manager made up new (pretty useless) features just to tell their bosses the devs are busy and the team must stay intact.
Also consider the sibling comment about AMP - looks like they already have special behaviour for that so this is barely relevant.
I've seen phishing sites like support.google.com.8n.cn where the right side (the most important) just disappears into the /path. Though this attack is even more brilliant on mobile devices that truncate the right hand side and leave with you with "support.google.com...".
Aside, I encourage fellow HNers to purposely visit seedy websites in a VM without an ad blocker. Especially if you haven't been exposed to crappy behavior since the popup/under days. Great way to see the state of hostile web practices, like unblockable popups and fake macOS notifications.
(I actually like Gnome's statement)
However: I believe Apple's motives are aligned with their users and they want their browser to be as safe and as easy to understand/use as possible. Their primary intention is to sell their shiny expensive hardware.
With Google it's more controversial, because who knows what's the plan. Combined with AMP there is a reason to be wary.
Ofc, one can make bad decisions based on good motives.
Not to mention all possible problems with misconfigured servers when www and www-less domains lead to same website, but some script refuses to work on one of those. While it was easy to spot with just a glance at URL bar, now one has to do additional clicking or opening devtools.
Probably we are at the crossroads where developers need separate, not dumbed-down version of browser.
Can anyone reproduce this?
You cannot compile Chrome. I've heard that Chromium can be compiled and run, but I've never actually seen it, or hear of anyone using that professionally.
There are other factors at play which mitigate the preferential treatment, but it's definitely there in Firefox as well.
Grand-parents/friends/org users not being sure to be on the right site after a redesign, not seeing amazon in the right language, etc. There’s countless of questions that can be solved faster by looking at the URL.
Understanding that users have more important things to do than spend time on bug reports is an important lesson to learn. If you can gather data without relying on someone whose job is to worry about other things then you will make everyone's life easier.
But if a whole subset of users exclude themselves from that tool, they're going to get the UX that's only as good as the other tools in the toolbox are capable of building.
But telemetry gives web developers an extremely simple and convenient tool to know what users are actually doing without even inconveniencing the users with explicit questions. I've done web development with a good telemetry set built into a page, and it is extremely informative regarding how users actually use the tool, as opposed to how the UX designers have predicted flow through the tool will be.
To give a concrete example, a user might tell you that configuring permissions is "hard," and sitting with them during over the shoulder testing (which is expensive) might tell you a little bit about why. But without even asking the user, page telemetry can tell you that they are making a transition jump from the permissions configuration page to the page listing all of the resource names, because that's what's slowing them down---the UI didn't give them enough information to configure the resources because we assumed they knew what the resources were named.
For a browser, anonymized usage stats can tell you whether most users keep all their bookmarks flat at the top of the bookmark bar or deeply nested in multiple subfolders, and that's usually valuable for deciding whether you want to emphasize a flat bar or folder management in the design.
If most power users disable automatic anonymous telemetry and also use deeply-listed folders, no one should be surprised if deeply nested folders doesn't get better.
People who don't show up to vote also "deserve" a good government by virtue of being people who have to live in a governed society. It's harder to make one for them if the system for selecting leaders is missing their input, regardless of what they deserve.
Popping out of the government analogy and back to software, power users are also in a position where they are more capable of adjusting their experience to suit their needs. All things being equal, a company with finite resources to develop software should dedicate those resources to assisting the non-power users more often than power users.
b) for being "not a good idea", it's pretty much industry standard now for everything from business software to video games.
So you're claiming that it is typical for software with telemetry support to ignore your choice and still send telemetry about you turning off telemetry? That sounds wrong, but I cannot say I investigated this deeply.
> b) for being "not a good idea", it's pretty much industry standard now for everything from business software to video games.
As I understood the discussion, we were in fact discussing whether this is a good idea and whether it makes sense, so I think it's fair game to comment on it. As for it being an industry standard, that sounds like an overgeneralization. It is certainly not typical of software I use.
No; I'm saying missing data leaves holes that can be measured. They know, for example, how many people have downloaded Chrome and how many daily Chrome users they get at google.com (because Chrome will still send a valid UA string if it has telemetry turned off). They can estimate how many users have telemetry turned off from those signals to a pretty decent degree of accuracy; certainly enough to know whether telemetry is telling them about 90% of users of 30%.
For (b), I'm curious what software you use. It's pretty standard in games, online apps, and business software. It's absent in a lot of open-source (mostly because a lot of open-source lacks a centralized vendor who would be willing to pay the cost to collect and interpret that data to improve the software).
I avoid online apps, I don't play a lot of games (and if I do, they're not big titles which are likely to have telemetry) and yes, I primarily use FOSS.
> (mostly because a lot of open-source lacks a centralized vendor who would be willing to pay the cost to collect and interpret that data to improve the software).
This is almost surely an element of it, but I think a respect for privacy and a general distaste for telemetry among FOSS users are more important.
* Apple Watch battery cycle count (not viewable in any UI but is viewable in telemetry logs)
* Clues about why a particular app recently crashed
Yes, we are.
Funny enough, Firefox has a 'Developer edition', but that's just the Beta build, with some features turned-on by default.
https://www.mozilla.org/en-US/firefox/developer/
At this point ie becomes more useful.
The goal of most web developers is to make pages users can use, not get mired down in the never-ending browser wars.
As the smaller vendor, it's incumbent upon Mozilla to break it. Expecting individual devs to do it collectively when it really isn't in their selfish interests is waiting for a unicorn to appear.
That's kind of impossible to do for a smaller vendor without wider developer cooperation.
I remember Mozilla only started to breach IE's dominance once devs were so sick of IE that they installed Firefox on their mom's computer despite tons of sites being made for IE.
It's possible for something like it to happen again with Chrome, but less likely since Google's a lot smarter and not too lazy to implement latest tech, so it will sure take longer without some activism and evangelism from web devs.
> expecting individual devs to do it collectively when it really isn't in their selfish interests is waiting for a unicorn to appear
Selfishness is a lot more complicated thing than people give it credit for. A lot of 'selfless' acts could be alternatively described as selfish in that it makes one feel good. Free software developers already do a lot of work for the wider community, where probably it would be a lot easier to just use the proprietary, already feature-rich, counterpart than trying to develop a libre alternative. But the movement understands that long-term, having as much free software as possible is what will in the end help preserve general-purpose computing in the sea of silos. It takes some discipline, sure, but long-term it's actually in one's selfish self-interest.
Short-term, sure. Long-term it opens devs to Google's whims and makes the "open" web barely more open than Apple's AppStore.
But that's short-term vs long-term thinking and I can't deny most would prioritize the short-term. Here's hoping there's still enough idealists, even among web devs to avoid that fate and bring about for the web what GNU did for UNIX in the 80/90s.
The only space I can name off the top of my head where my open-source architectures have outstripped Windows and Mac in UX is virtual desktops.
Of course proprietary software has more funding to hire designers and such, but in terms of actual functionality, I'd contest your claim.
If you're talking developer user experience, it's not even a race. The FLOSS ecosystem has a landslide lead here. In fact the whole point of WSL is to try to keep devs on the Windows platform by bringing that experience to Windows more directly.
Customizability is orthogonal with out-of-the box UX, the original axis of comparison here. In fact, the two are often at odds.
The history of biological evolution shows that monocultures invariably fail catastrophically. Diversity is the main way to guard against unpredictable events of the future. Software is not exempt from these general rules I'd presume.
I've looked into switching back to Firefox, but what I've found is that they don't allow me to use my own extensions. I would have to use a beta version of Firefox or submit all of my extensions that only I use for approval to Mozilla or have to reinstall my extensions every time I close Firefox. None of these seem good options to me.
Due to slow loading, I'm considering whatever they call the Microsoft browser today.
I am honestly surprised Firefox on Windows is slow for you. I don't personally use Windows, but many on here say it works well there since v57.
Maybe I don't know what to Google.
That combined with both FF and especially Safari being way behind in terms of standards adoption/development really sucks at the moment. Chrome desperately needs competition.
The standards are meant to be agreed upon by several parties, including both Google and Mozilla. Google implements new features in order to control the way they work, instead of allowing input by all the parties involved. It's always faster for one company to just do whatever they want than for a group of organizations to come to an agreement on what to do. The slower way results in better and more equitable implementation for everyone though.
The URL bar is a disaster for end users. It's full of random junk that users can't read so they stop trying, which means they can then be tricked by phishing websites hosted on any domain at all. Research shows about 25% of users don't look at the URL bar at all even when typing in passwords, they navigate purely by sight, so it's impossible to stop them being phished. The human cost of the resulting hacking is significant.
The fact that the software industry has routinely prioritised historical inertia, the needs of web developers, and all kinds of other trivialities over the security of billions of people is embarrassing. I'm glad to see the Chrome team finally get a grip on this and make the URL bar actually useful for people.
"Side view mirrors are a disaster for drivers. 25% of drivers don't even check them before making a turn." [I'll stop the metaphor here, as I think my point was clear]
This change does exactly nothing to improve security. As for usability, it just puts one more layer of paint over the underlying "complexity" - and we've seen before how well that works (see basically every part of Windows 10 for examples).
Your side view mirror metaphor is unfortunately not clear at all. The side view mirror is simple and performs its function correctly as designed. It can't really be improved without totally replacing it with something else like a camera. Now of course not everyone will use the URL bar even if it's redesigned to work correctly. But right now the bar is practically designed to look as intimidating and useless as possible.
Perhaps you're so used to parsing URLs in your head you don't realise it, but URLs are a baroque and absurd design that nobody without training could properly figure out. It's basically random bits of webapp memory and protocols splatted onto the screen in a large variety of different encodings. In a desktop app dumping RAM straight onto the screen would be considered a severe bug. On the web it's tolerated for no good reason beyond history.
To give just one example that has regularly confused people in the past: URLs are read left to right except for the domain name (the important part) which is read right to left. You don't stop reading a domain name at .com, you stop reading it at the third slash or possibly a colon, but that form is rare.
The way I used to teach was very simple and very effective: there are 3 parts to a URL - the first part tells you if the connection is secure, the second part tells you who you're connected to and the third part tells you where on that site you are. The first part needs to be httpS, the second part needs to be the site you're expecting and the third you can ignore. They're even shaded differently to make it easier to read. "If you're going to Google and the black part ends with anything but google.com, call IT" made sense to even the oldest and most reluctant people I've had to deal with. The problem was actually getting them to check every time and not forget.
It seems to me that this change will not help people without training, change nothing for people with training, and make sharing links even more confusing for everyone.
Are you saying someone is less likely to get phished on "supershop.co.hk" than on "http://supershop.co.hk/account_login.php", even where the http:// part is replaced with a red padlock and /... is grayed out?
I see only one real solution to phishing: don't let users type passwords manually. WebAuthN and password managers both automatically read the domain and won't try to authenticate on a domain that isn't a perfect match. I've had more success with that than any other anti-phishing measure I've tried deploying (history-based domain trust, explicit trust on first use popup, detecting unicode gaps and domains in credential fields...).
The greying out and replacement of padlocks etc, the anti-phishing training, it's all just working around a historical design problem in browsers. There's no need for it to exist. Notably, mobile apps don't have this problem.
I was trying to search for the word "aquarium" but chrome kept filling in "https://aquarium.org", I would delete the ".org" and only the word "aquarium" was shown in the search bar, which was the word I was trying to search.
Of couse "https://" was hidden, so I was actually submitting "https://aquarium" which was not a valid domain and it took many frustrated clicks and enters to actually google the word that was shown. Absolutely infuriating as the true state of the search bar was hidden.
google could make an amp-only web experience without dissent.
hide the URL bar
javascript -> webasm
hiding all this benefits data collection and advertising. Seems obvious to me.
I'm having a hard time thinking of a situation where you have information, some more important and some less, where the correct solution is to delete the less important information. It still has importance!
That might help make the URL more readable but again doesn't really help if the relevant parts of the path/query string for trust isn't immediately apparent.
This is clearly not their motive.
What Google is trying to do here is to drift the web from its most iconic components: the URL. This is the biggest threat to the web that we loved for so many years.
If it looks like Google.com, then it Google.com. The logo even says so.
It’s a dumbing down of the internet, in an attempt to help the average user, but it won’t work and you’re just making life harder for those who know just a bit more then average.
What better way to keep people on AMP pages, than to make them so ignorant as to not even know how to tell the difference?
Sometimes I wonder if feudalism must have felt like this from the perspective of the noble people. Will there be a dark age followed by enlightenment? Because right now we seem to encounter self-imposed nonage.
AMP adds 2-3 additional actions to that user flow.
For me, it’s to get information. Why do I care what format the information is presented in?
In fact, I think the evidence is not only overwhelming but the tech community is thoroughly comprimised, proven so on account of all the recent purges and attacks on wrong-think.
I no longer trust my software.
I guess some people just feel guilty/ashamed!
That metaphor is based on a false premise[1]:
> While some 19th-century experiments suggested that the underlying premise is true if the heating is sufficiently gradual, according to contemporary biologists the premise is false: a frog that is gradually heated will jump out. Indeed, thermoregulation by changing location is a fundamentally necessary survival strategy for frogs and other ectotherms.
[1]: https://en.wikipedia.org/wiki/Boiling_frog
If this is indeed the real motivation, the next obvious target would be bookmarks. What can be done about them? Replace the bookmarked URLs by Google queries? It would be an interesting functionality if Google could look at a page and give you the smallest query that would have returned exactly this page as a first result. Then bookmark the query instead of the URL. And if the search results change in the future... I suppose, it would be possible to spin this as a feature. ("Self-improving bookmarks" perhaps? You don't have to worry about link rot; with latest Google self-improving bookmarks, your bookmark will always point to the best existing page on given topic!)
Just out of curiosity, is there a publicly accessible Google service, or a third party service, that does this? That would be useful to find more content or point-of-view about a topic (by looking at the other results)
Bookmarking is one of the areas where firefox is clearly superior.
It made the Safari 13 Extension-pocalypse so much harder to bear. Every browser I can pick from has something important I have to compromise on.
Maybe like a decade ago this was a student project that Google sponsored (maybe as either Summer of Code or some precursor to that). A student group developed a system for “tagging” a page with a series of “random” but memorable words that could be used to identify a page. Kinda like how imgur and other other sites generate URLs now. Like “glittery hamster bananas” or something like that.
https://bugs.chromium.org/p/chromium/issues/detail?id=24349
They already had the feature you are worried about and it's existed since like 1999. Do you remember the "I'm Feeling Lucky" button? You could bookmark a query and it would redirect you to the first result for that search. It was discontinued in 2010 [Wikipedia].
I feel like there are a lot more sane things to be paranoid about in the world right now, but mandatory "I'm feeling lucky" doesn't reach my top 20000.
And no, users do not need to care the slightest whether they go to the first, second or 3rd URL. What they care about is that they are entering their sensitive information on mybank.com's domain and not a russian counterpart, that's it.
The onus to protect against a website takeover is on the domain/server owner, certainly not on the browser vendor although they try to mitigate simple attack vectors.
edit: added a few 9s
They already used colors to de-emphasize other components, this doesn't look like anything else than pushing people to rely more on google search.
Refraining from collecting malicious links happens before you click, by the time it's in the URL bar it's already pretty late to mitigate against attacks.
There are a couple of reasons they could be making this change highlighted in these threads.
Users with the level of paranoia that puts Google in the "untrusted site" space should be sidestepping this whole conversation by avoiding using the browser Google develops regardless of what Google does to its URL bar.
The whole idea of AMP pages is sketchy by default, as it's Google taking content from websites run by news media outlets and hosting it on their own servers so they have even more control over user-tracking.
In the long term, this has the potential to further centralize the Internet, something the Internet was never meant to be.
It's not that difficult to imagine a future where news media won't even host their own stuff anymore but instead outsource it all to Google.
Very comparable to how Facebook has become the de-facto place for small businesses, with little to no IT knowledge, to have their own little web-presence.
Which has certain advantages, but it's dangerous to belittle the very real disadvantages that kind of centralization of content will have in the long term.
In that context, it's a bit cynical to belittle the problem as you are doing there when this has been a very real issue for several years. As by now Google, Facebook, and Amazon control the vast majority of web traffic and have been doing so for years already [0].
This isn't some hypothetical scenario, it's something that's already very real.
[0] https://staltz.com/the-web-began-dying-in-2014-heres-how.htm...
IMHO it's our duty as technical users to advocate for a more private, open and de-centralized web for everyone.... We should especially be doing it on behalf of the users who don't understand the long term implications of Google's (anti-) features.
'Just switch to another browser if you don't like it' is not a compelling argument.
Every tool in the toolbox to make the web better.
“Jerry, you don’t deserve the internet” https://m.youtube.com/watch?v=lcR4h4eIR2E
It's iconic but it's a UI space resource hog. To improve browser experience, sometimes one has to be willing to try slaughtering a sacred cow.
2) UI improvements are not "cosmetic reasons," they directly translate to ease and efficiency of task completion. As a UI engineer, hearing my category of work called "cosmetic changes" can be, quite frankly, exhausting. If someone were to halve the default font sizes on all browsers, would we consider that a mere "cosmetic change" or would it be a change that would have direct and immediate impact on people's ability to accomplish tasks?
You know what else is "a UI space resource hog" on the web ? Advertising. And I'm sorry but "wasted" space is generally much bigger. So, no, I'm not ready to loose my address bar for bigger ads.
Chrome is well into the commodity software scale, and one should assume its UI decisions will lean in the direction of maximum utility for the most users.
https://old.reddit.com/r/space/
Fits fine and tells you at least three useful things that just "reddit.com" doesn't.
https://old.reddit.com/r/space/comments/h8t50n/i_often_get_a...
Doesn't fit, but even truncated it still tells you the same useful things.
In fact, using the URL bar for it assumes that the path has semantic meaning, which is not an assumption that the URL standard actually requires.
The page isn't required by anything to contain that information or to give it accurately. How do you distinguish example.edu/financial-aid/ from example.edu/~some-student/ ?
> In fact, using the URL bar for it assumes that the path has semantic meaning, which is not an assumption that the URL standard actually requires.
It doesn't assume anything, it just shows you the URL. If it has semantic meaning then you can see that -- which it commonly does.
That's an unrealistic example because no website worth its salt is going to let students put arbitrary content in the same domain as the financial aid system. That's a recipe for leaking cookies that contain session tokens, and displaying a full URL won't save a user.
By the time you see the ~some-student in the URL bar, the security game is over.
It could be that example.edu/financial-aid/ is just information and PDFs and doesn't have any sessions or cookies. Or the real financial aid system is on another domain, but a first time user doesn't know that, they're just looking at www.example.edu/~some-student/ which appears to be a financial aid page that Chrome only says is example.edu.
Or any other case where the contents of the URL matters. How about example.edu/~some-student/ vs. example.edu/~a-different-student/ or example.edu/~your-professor/?
The other scenario you describe, if the risk is someone intentionally deceiving users by cloning a page on the university network owned by someone else for deceptive purposes, is better solved by a university disciplinary hearing than by expecting every student to understand URL paths.
The attacker may not be able to get ~financial-aid, only ~juan-ramirez, and even if you don't know about home directories, the first thing that strikes you about ~juan-ramirez/financial-aid is that something is wrong because you are not Juan Ramirez. If you do know about home directories then it's a giant red flag which you can't see if the browser is hiding it from you.
It doesn't have to prevent 100% of attacks. Preventing 7% of attacks is still 7% better than nothing.
> The other scenario you describe, if the risk is someone intentionally deceiving users by cloning a page on the university network owned by someone else for deceptive purposes, is better solved by a university disciplinary hearing than by expecting every student to understand URL paths.
The most common way things like that happen isn't the actual student who would have to be using their own name, it's that the student uses a weak password or gets their computer infected with malware and then some Russian hacker sets up on their school account.
You also don't need every user to understand them, only one who then reports it. If you don't show the paths to anybody then much more likely that nobody notices, or that it takes longer for somebody to notice and more people get compromised in the meantime.
User studies indicate that the first thing a user notices is... Nothing. The gobbledygook in the path is so much noise for the average user that they don't notice if the path seems off. In fact, it makes sense to hide it from a security standpoint to decrease the odds that users go information blind to the domain, because we already know that improper domain routing to lookalike domains is, by far, the most common vector for credential theft.
There isn't even a guarantee that showing the path to address the 7% case (which really looks like more 0.07%) will on average cause the incidence of users being compromised to go down, if it means users are less likely to notice that the subdomain and domain are off.
I'm sure that for the people who really care, it won't take long to hack together a chrome extension that drops the full URL into the page title or a pop-up box on the page itself.
There are a thousand ways to screw up a user study, but one of the best ways to detect a screw up is if they say that users either always or never do something.
> In fact, it makes sense to hide it from a security standpoint to decrease the odds that users go information blind to the domain, because we already know that improper domain routing to lookalike domains is, by far, the most common vector for credential theft.
Which is why it makes sense to highlight the domain. Make it a different color. Make it a bigger font size. That still doesn't require you to omit the rest of the URL.
> I'm sure that for the people who really care, it won't take long to hack together a chrome extension that drops the full URL into the page title or a pop-up box on the page itself.
Except that the people who actually do that really are the 0.07% and you've still lost the 6.93% who would've noticed if you'd put it in front of them but aren't about actively change the default you gave them ahead of time.
... but probably more importantly, nobody likely needs to hack together an extension after all. Older news story about how Chrome will add an option to show the full URL bar as non-default.
https://www.zdnet.com/article/googles-chrome-will-give-you-a...
Also, "use a real computer" is a pretty elitist attitude that misses Google's goals overall. Google is not targeting exclusively users that have desktop machines with multiple cores and graphics accelerator cards. They want to provide internet services and internet access to people whose only portal to the web is a mobile device.
Oh, I'm not missing that. Google's software offerings are now primarily designed for bad computers with bad UI, bad network, and bad energy storage. Because people love those crappy devices and most use them primarily. We both agree.
>A shorter URL bar in the desktop allows for to take up less horizontal space,
Which really doesn't matter if you're on a desktop computer with an actual monitor. The only reason to do this is more "convergence" BS and thinking phone crutches are required on desktop.
Are you seriously claiming you need all (or even just more than like 10%) of your 1920+ pixels of screen width for your Chrome extensions?
It's still cheaper to build a $450 real desktop computer (that lasts decades+) than it is to buy a $800 4 year life gimped smart phone that can't do any productive work any isn't in my control.
(And my $20 nokia dumb phone has worked perfectly since 2006 for phone calls/text.)
We're talking about the person in small-town India who has a Micromax Black Q385 spark 3, 8GB store, 1GB ram, 5.5" screen, which they bought for $50. They also get their Internet access through the cellular equivalent of a drinking straw.
(Even still, my personal guess is that this URL bar change isn't about them; it's about the desktop experience).
A few months back, people on HN were wondering why creating a new tab in Firefox causes the URL bar to become magnified.
I wonder if this is part of the reason. Perhaps Firefox believes they have to educate users about the URL bar because Chrome is attacking it.
Safari has hidden the full URL since 2014. For the vast majority of users, the full URL is just noise.
It's called "kicking the ladder after climbing the wall".