Really wish this was applied to phone apps. In Android at least, app A linking to app B will FREQUENTLY break the "back" functionality, allowing app B to handle the "back" action instead of doing what every user would expect 100% of the time, which is to go back to app A.
A new spam policy for “back button hijacking”
351–360 of 532 posts
Re: A new spam policy for “back button hijacking”
#352Great. Can we do ctrl-f search hijacking next. So jarring when websites replace core functionality with their own broken crap because they think they’re special. Some also seem to hijack right click menu now
CTRL+F hijacking is necessary in some cases when apps are not displaying the full text that the user would expect to search. E.g. when there's a 10K-line code file and the UI is not loading the whole thing into DOM, but the user would expect a "find" to search that whole code file.
Re: A new spam policy for “back button hijacking”
#353Now do paywalls next.
How would you recommend that creators of valuable content get paid?
Paywalls are, of course, the author's choice.
But a paywall is a rather useless page, so it shouldn't be shown in search results. Normally, serving Google one page (e.g. a full article) and showing users something else (e.g. a paywall) would be grounds to ban that site forever, but Google built a special exemption for paywalls.
Showing search results that the user can't actually use is user hostile. It's essentially an ad disguised as a search result, with the problem that those ads displace other results that I might actually be able to read.
Of course, if the policy was to not index paywalled content, we might have avoided the paywallization of the Internet. Somehow, decades ago, when the Internet was smaller and there were fewer eyeballs, high quality content could successfully get monetized with non-tracking ads.
Now we have invasive ads that try to profile you, ads that are full of scams because quality control has gone out the window, and yet, somehow, everything needs to be behind a paywall...
Re: A new spam policy for “back button hijacking”
#354Since this is Google we’re talking about, I’m fully expecting them to penalize benign uses of the back button override.
Re: A new spam policy for “back button hijacking”
#355Are they considering all uses of window.history.pushState to be hijacking? If so, why not remove that function from Chrome?
It's a valid question how they detect it. As there are valid usages, just checking for the existence of the function call would not be correct. These sites likely pushState on consent actions so it appears like any user interaction.
No idea how they actually do it, but I wouldn't be surprised if manual reports and actions play a big role. The policy doesn't need to be enforced reliably as long as it is plausible for reasonably big actors to get caught sooner or later and the consequences of getting caught are business-ruining.
But detecting it on a technical level shouldn't be hard either. Visit the page, take a screenshot, have an AI identify the dismiss button on the cookie/newsletter popups, scroll a bit, click something that looks inactive, check if the URL changes, trigger the back action. Once a suspicious site is identified, put it in the queue for manual review.
Re: A new spam policy for “back button hijacking”
#356Earlier quoted context omitted.
Huh? I exclusively view r/all and its loading fine for me across all devices.
Even manually typing reddit.com/r/all (or r/All, which was a workaround for a while) in the address bar on iOS Safari redirects you to reddit.com/. Since I'm guessing you're not browsing reddit.com, what client are you using?
This is available for me on iOS https://old.reddit.com/r/all/
Re: A new spam policy for “back button hijacking”
#357Earlier quoted context omitted.
Just like finally getting rid of r/all on mobile just happens to bury a bunch of political stuff reddit executives and their friends don't agree with
Huh? I exclusively view r/all and its loading fine for me across all devices.
https://www.theverge.com/tech/906314/reddit-r-all-deprecatin...
it's dead, per official comment from reddit.
Re: A new spam policy for “back button hijacking”
#358Earlier quoted context omitted.
Those features that can't be used to show more ads will be used for fingerprinting.
I feel like we need a complete black box layer or something, where a website can send requests to the browser to do something, but never gets any kind of reply, as to whether anything actually happened. But that would limit usefulness of it quickly, I guess.
I've been toying with an idea of creating a JS runtime that tries to run all code two times, one which runs all identifying information inside a runtime that has any network API's stubbed, and another that replaces the identifying info with garbage.
Most likely needs manual quirk code overlays for sites, but it's totally a solvable problem.
Re: A new spam policy for “back button hijacking”
#359There should be some browser-level enforcement of this. For example, it would seem possible to detect a user frustratingly mashing the back button, and offer a remediation dialog to disable any hackery that's hijacking the back buttons.
Re: A new spam policy for “back button hijacking”
#360[dead]