SoylentNews is people
SoylentNews
Google has tried on and off for years to hide full URLs in Chrome's address bar, because apparently long web addresses are scary and evil. Despite the public backlash that came after every previous attempt, Google is pressing on with new plans to hide all parts of web addresses except the domain name.
A few new feature flags have appeared in Chrome's Dev and Canary channels (V85), which modify the appearance and behavior of web addresses in the address bar. The main flag is called "Omnibox UI Hide Steady-State URL Path, Query, and Ref" which hides everything in the current web address except the domain name. For example, "https://www.androidpolice.com/2020/06/07/lenovo-ideapad-flex-5-chromebook-review/" is simply displayed as "androidpolice.com."
(Score: 5, Interesting) by looorg on Monday June 15 2020, @12:46PM (11 children)
I was thinking about this to. I can't really imagine why they want to do it. This whole excuse about security by hiding information just doesn't really make much sense. The only thing I could really on short notice come up with is that this has to do about ads and clicks. They want people to go thru the front page all the time to click on things and get ads shown to them -- or well the people probably doesn't want that but Google does. So by skipping straight to the page you want to go you are in essence stealing money from Google.
That said Bookmarking will still work and such since it's at the moment just hiding the information, it isn't (yet) sanitizing or cropping the input to only allow you to visit top-level.
(Score: 0) by Anonymous Coward on Monday June 15 2020, @01:43PM (8 children)
(Score: 2, Insightful) by Anonymous Coward on Monday June 15 2020, @02:31PM (7 children)
This is still the default. I have seen it cause many issues. It's just a pain in the ass.
(Score: 2) by Freeman on Monday June 15 2020, @02:46PM (6 children)
The pointy haired boss needed to make an arbitrary change somewhere, and that was it.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by EEMac on Monday June 15 2020, @04:28PM (5 children)
It was done to copy classic MacOS, where file types were part of the resource fork of a file [wikipedia.org]. When it worked, files were automatically identified with the correct type and opened in the program that created them. Documents were just documents, of a particular type, with exactly the name the user created. It was great!
. . . unless you wanted to change which application opened a file, or the type it was identified as, or if you downloaded something on-line that didn't magically get the correct type applied. Then you had to: search online for how to solve the problem, install ResEdit, open RedEdit, go into the resource fork structure, and change a four-letter type code.
. . . which couldn't possibly be part of the file name, because that would be difficult.
(Score: 0) by Anonymous Coward on Monday June 15 2020, @05:34PM (2 children)
Ugh, another reason (I guess) that I won't be switching to Macs anytime soon, unless it's possible to drag any file onto any application?
Sometimes I want to see what's in a file that was sent to me (or my file, before I send it out)...so I open in MicroEmacs, where I can see everything. Usually lots of binary (displayed as 8-bit chars), but every now and then there is some interesting text to be found inside. For example deleted parts of documents are often still in the file, although they don't display in the original word processor.
(Score: 0) by Anonymous Coward on Monday June 15 2020, @06:23PM (1 child)
Until System 7, the Mac's OS didn't have drag-n-drop for files.
Trying to work with a file across multiple programs or import data from a foreign system on an old Mac is honestly quite awful and there were dozens of little utilities that allowed you to "quickly" switch file types so you didn't need to actually know or have ResEdit. Even into the OS 9 days, you still had to muck about with type switchers (but at least you could drag and drop onto the switchers at that point, I had a folder full of 'em on my desktop for dealing with image files).
OS X/macOS largely abandoned all of that, and just uses file extensions like everyone else. I think all of the weird things like resource forks and file/creator codes are still there, but software mostly doesn't bother anymore.
One useful thing for this is to pipe the file into the "strings" command. It looks for low-ASCII sequences and displays them without all the other binary junk so you can see if there's interesting text.
(Score: 0) by Anonymous Coward on Tuesday June 16 2020, @01:57AM
Only windows uses extensions to decide anything. OSX and other *nix systems use mimetypes.
(Score: 2) by Rich on Monday June 15 2020, @08:17PM
Creator and Type codes were part of the "FinderInfo" that was kept with the directory information. The resource fork is separate. On OS X, both are represented as extended attributes: "com.apple.FinderInfo" and "com.apple.ResourceFork". And OS X is a mess compared to Classic as far as file typing goes.
(Score: 2) by Bot on Monday June 15 2020, @09:08PM
Or, you could have dragged the file to open to the app to open it with (easy as apps could reside in tabs, kind of docks), and then saved it, so it acquired the proper creator.
I had less probs with type/creator than with renames borking an extension in later systems.
Account abandoned.
(Score: 0) by Anonymous Coward on Monday June 15 2020, @01:49PM
What they display is annoying, but not life changing, except maybe for nerds who peek and poke into things.
That they give you the whole/exact/ungoogalized url if you click, copy and paste, or bookmark is critical.
If they manage to hide/own/control that, then it puts them in the position to be an unnecessary central gatekeeper.
(Unnecessary because it breaks the idea of url without adding value to the users. But maybe critical to their business/power/not-no-evil grand plan.)
Make it stop, indeed.
(Score: 0) by Anonymous Coward on Monday June 15 2020, @02:23PM
it's because there's "processing" going on in the URL bar.
it seems the way they bolted "smarts" onto the original static html web server is to add the variables and stuff to the URL ... this makes for "smart" or not-static websites but also for bloated URLs and pages that can hardly be cached (by a proxy server)?
"GET your PUT today(tm)!"