[HN Gopher] I recorded user behaviour on my competitor's website...
___________________________________________________________________
I recorded user behaviour on my competitor's websites (2018)
Author : metadat
Score : 219 points
Date : 2022-10-25 14:37 UTC (8 hours ago)
(HTM) web link (dejanmarketing.com)
(TXT) w3m dump (dejanmarketing.com)
| Abecid wrote:
| Wow
| dmingod666 wrote:
| I always ctrl click and open multiple tabs, back button doesn't
| come into play. I assume a lot of people do this.
| avg_dev wrote:
| I would be shocked if a lot of people did that.
| bentcorner wrote:
| In a similar way that I choose to use backspace vs ctrl+z, I
| may use the back button or open a new tab (or duplicate tab,
| then go back), depending on if I want to keep current context
| or discard my current work.
| Loughla wrote:
| Middle mouse button click for any link. I don't remember the
| last time I used back. Just open and close tabs based on what I
| want to do. I learned this during research methods in graduate
| school as a way to avoid losing valuable studies while working
| on the various archaic databases, and it stuck. I know every
| graduate student at my university learned the same thing.
|
| I also assumed most people did this.
| metadat wrote:
| > Middle mouse button click for any link
|
| Yes, this is one of the best parts of having a desktop +
| mouse compared to a laptop + trackpad (or nub).
| lolinder wrote:
| I always configure three-finger tap on the trackpad to act
| as the middle mouse button. I haven't tried this on a Mac,
| but it can be done on Windows and Linux with Gnome (and I
| believe KDE, too).
| vermilingua wrote:
| BetterTouchTool TipTap on macOS, gamechanger
| gondo wrote:
| Or free alternative:
| https://github.com/artginzburg/MiddleClick-BigSur
| jcims wrote:
| (2018)
| huitzitziltzin wrote:
| Should have the date: (2018)
| jonplackett wrote:
| Rewriting history in general is pretty dumb that it's allowed.
| notriddle wrote:
| As much fun as it is seeing everybody reiterate the "SPAs are
| stupid and we should all go back to native apps" argument for
| the thousandth time with exactly the same arguments again...
|
| It's all a moot point, because you can reproduce this
| particular attach using nothing but 2001-era DHTML. Start with
| a page that has a hidden iframe, a link that targets it, and a
| timer that polls the contents of the iframe. When the page
| first loads, use JS to click the link to add a new item to the
| back stack. If clicking the link with JavaScript doesn't add a
| back stack item, make the link visible, but also attach an
| onclick event handler to it so that the link can simultaneously
| do what you want and also do what the victim wants.
|
| After you've poisoned the back stack, you can detect that the
| user clicked "back" when the iframe gets reset back to its
| initial page. Once this is done, use `document.body.innerHTML =
| whatever` to set up your fake SERP.
| astura wrote:
| Doesn't X-Frame-Options in the response header prevent this
| attack?
| quickthrower2 wrote:
| This attach is similar to linking to g00g1e.com and setting up
| a mock page there. Impersonating sites is going to be hard to
| secure technically at all.
| warent wrote:
| Beautiful example of a chaotic-good grayhat.
| hedora wrote:
| The quote from a security researcher at the end treats this like
| a vulnerability.
|
| If this were early days of the web, I'd agree, but web browsers
| allow so many other shady tactics, this feels more like the web
| working as intended.
|
| (Yes, phishing attacks are bad, but the browser back button spec
| is specifically designed to allow these sorts of shenanigans,
| with basically zero legitimate use cases -- the only use case I
| can think of is telling the browser certain actions should not
| push themselves onto the back button stack).
| ysavir wrote:
| Being part of an official spec doesn't eliminate it as a
| vulnerability. If it has potential to be an attack vector, it's
| a vulnerability.
| bogwog wrote:
| > with basically zero legitimate use cases -- the only use case
| I can think of is telling the browser certain actions should
| not push themselves onto the back button stack).
|
| I agree on the "legitimate" part, but I suspect one of the main
| reasons is that Google and Apple both really want people to be
| creating SPAs that pretend to be real apps, and that's hard to
| do without being able to hijack the back button for navigation.
| daveidol wrote:
| I agree. Users should be trained to pay attention to the
| address bar - in this example that exposed the truth of the
| matter, as intended.
| TonyBar wrote:
| From what I can see, it is still very easy to hijack the back
| button. Wild that I never heard about this.
| larsrc wrote:
| Which RTM is that referenced in the quote at the end?
| erpellan wrote:
| https://en.wikipedia.org/wiki/Robert_Tappan_Morris
| chrismorgan wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=17823886 (Aug 23, 2018, 766
| points)
| placatedmayhem wrote:
| Thanks for posting this. I am increasingly frustrated with
| browsers' weak stance on user control. Hijacking back buttons,
| right clicks, copy functions, and other items has become quite
| commonplace and even expected. For example, YouTube puts some
| functions only in the right-click menu and TinkerCad's viewport
| rotation is primarily right-click and drag.
|
| Presumably, this is in pursuit of making web pages behave more
| like apps, but it is truly frustrating. If I wanted app behavior,
| I'd install an app (even something like Chrome's apps). While I'm
| in a web browser on a web page, I expect to interact with the web
| browser primarily and the web page through the browser
| intermediary.
|
| The Line of Death discussion is highly relevant:
| https://news.ycombinator.com/item?id=13400291
| yamtaddle wrote:
| Ding ding ding.
|
| Ever letting Javascript initiate requests on its own was a
| mistake, to pick one major blunder.
| fazfq wrote:
| >For example, YouTube puts some functions only in the right-
| click menu
|
| If you double-right-click (huh) you can see the "normal" menu.
| If you use Firefox you can shift-right-click also.
| [deleted]
| Slurpuff wrote:
| >Hijacking back buttons
|
| There's nothing that infuriates me more than trying to read an
| article and suddenly being forced to either spam the back
| button or close the tab entirely.
| sudobash1 wrote:
| This depends on your browser, but on desktop firefox I can
| get out of these by holding down the back button a moment. It
| pops up a list of my (real) browsing history in that tab. I
| can then select where I want to go back to.
|
| Agreed on how infuriating this is though!
| ummonk wrote:
| Ideally I'd want to be able to toggle between app mode (which
| would allow hijacking) and browse mode (which wouldn't).
| chrisshroba wrote:
| As a counterpoint, I don't want to download apps when webapps
| suffice. I appreciate when a right click gives me the options
| I'm hoping for rather than a set of generic Chrome actions that
| aren't what I want. I also appreciate when copying works how I
| want it to (e.g. copy paste in google docs or Figma work as I
| expect it to, including all styles). And hijacking browser
| history doesn't seem to me like it adds much exposure, because
| the attack vector is still there without browser support (when
| a user enters your site, auto redirect to google.mydomain.com,
| which then auto redirects to your content. Back button now will
| return you to google.mydomain.com without relying on custom
| browser back button shenanigans)
|
| Disclaimer: I work for Figma.
| warent wrote:
| Your post seems to suggest that you feel Figma is a prime
| example of how webapps are sufficient over desktop/mobile
| apps. Yet Figma actually does offer desktop/mobile apps so
| I'm a bit confused by how Figma helps make your point haha
| sangnoir wrote:
| > Yet Figma actually does offer desktop/mobile apps so I'm
| a bit confused by how Figma helps make your point haha
|
| Im not parent, but given a choice between native app & web
| app, I'd take the browser. That it's possible at all to
| have parity is amazing
| bigyikes wrote:
| I'd wager that the web app is far more popular than the
| desktop app, and that the web app is one of the primary
| reasons for Figma's runaway success.
|
| I work for a company that uses Figma and I haven't seen
| anyone use the desktop app. I didn't even know there was
| one.
| lmm wrote:
| If a webpage implements something _perfectly_ , it enhances
| the experience. E.g. webpages that mess with scrolling -
| maybe for 20% of sites that do this it makes them 20% better,
| but 80% of sites that do it become 80% worse.
|
| I'm not sure the benefits of allowing the Figmas of this
| world to offer a good app experience outweigh the costs of
| putting the same tools in the hands of every shitty news
| site.
| userbinator wrote:
| Turn off JS except on whitelisted sites and you'll experience a
| saner web. Unfortunately even static text is often hidden
| behind such "app-site" monstrosities these days.
| [deleted]
| NaughtyShiba wrote:
| Jesus christ they are douches. This ain't their first unethical
| dark-pattern-kind thing.
| O__________O wrote:
| Reminds me of the Google Maps profile hijacking, which included
| injecting proxied phone numbers to record the calls.
|
| Examples of press on topic:
|
| https://valleywag.gawker.com/how-a-hacker-intercepted-fbi-an...
|
| https://www.theverge.com/2014/2/28/5458610/fake-google-maps-...
| josefresco wrote:
| > "Users seldom read home page "fluff" and often look for things
| like testimonials, case studies, pricing levels and staff
| profiles / company information in search for credibility and
| trust. One of my upcoming tests will be to combine home page with
| "about us", "testimonials", "case studies" and "packages". This
| would give users all they really want on a single page."
|
| Shady tactics aside, this was interesting but could also have
| been measured by simply tracking his own website.
| rhplus wrote:
| _could also have been measured by simply tracking his own
| website_
|
| Perhaps his competitors were established, trusted brands,
| whereas his is one that hijacks back-buttons to trick his own
| customers.
| chiefalchemist wrote:
| "While I was too deep into spying on my competition, my
| competition was focused on serving its customers."
|
| A fool with a tool is still a fool.
| teknopaul wrote:
| Or they noticed the URL and were trying to check validity
| z3t4 wrote:
| Was expecting to land on a fake HN page after clicking back
| [deleted]
| toxicFork wrote:
| You did!
| snappythrowaway wrote:
| i always open everything in new tab. Is it safer this way?
| tgsovlerkhgsel wrote:
| It's not true that researchers always do a minimal PoC. I've seen
| soo many people release fully weaponized attack toolkits,
| ostentibly for red teams etc., that then end up being abused by
| actual attackers. These are not just PoCs, but ready-to-reuse,
| universal toolkits.
|
| OTOH, sometimes a harmless PoC isn't enough to induce action, and
| a proper attack PoC does. I think this may be such a case.
| Arrath wrote:
| I despise sites that hijack my back button (No, I don't want to
| check any of these DENTISTS HATE THIS MOM'S NEW TRICK clickbait
| articles thanks) so I can't say I'm surprised there are malicious
| uses for it, but wow!
| [deleted]
| shadowgovt wrote:
| Unfortunately, the feature itself is vital for making web apps
| work in anything like a coherent fashion, so it isn't something
| that can be disabled (though there may be meat on the bones of
| permission-gating it).
| ghayes wrote:
| I think there are some solutions to this problem. Akin to
| "after a back navigation, you cannot add to the history state
| without a user interaction"-- or better "the history stack
| can never grow beyond the number of user interactions".
| Basically, I should always be able to navigate back to the
| referrer in a definitive number of actions.
| shadowgovt wrote:
| I think that can still be gamed by forcing nonsense
| interactions that seem meaningful on the user.
|
| This is a really tricky one to solve because the protection
| that is intended to guard against it ("The user is aware
| the current domain they are accessing doesn't match the
| site they expect it to match") isn't working. I think that
| aspect is the larger problem... IRL, people know if they're
| standing in a Target vs. a used car dealership, but they
| rarely know if they're at target.com instead of
| target.used-car-dealership.com.
|
| It's possible the browser's framing should be changed to
| make it harder to be confused about that (color-and-
| texture-hash the TLD and apply it to the URL bar as a
| background, so there's a major visual difference if I'm on
| the wrong site?).
| ysavir wrote:
| So removing it will simplify web pages? Sounds like a win/win
| to me.
| shadowgovt wrote:
| Not for users of Sheets, Docs, AutoCAD Web, myriad tools
| companies have built for their intranets, and hundreds of
| other apps, no. It will make them more complicated.
| ysavir wrote:
| I can't see any argument for how _removing javascript
| navigation_ will make apps _more_ complicated. The
| desired functionality is literally built into the
| browser.
| shadowgovt wrote:
| Not more complicated in the sense of "more code;" more
| complicated in the sense of "harder to use." You had said
| "win/win" and I disagree that making apps bigger,
| clunkier, and slower by requiring more server-side
| negotiation would make them better for end-users. The
| hard-coded behavior of the browser doesn't always match
| the user's concept of what has happened when performance
| optimizations are added in.
|
| For example: for performance reasons, many web apps are
| logically divided into sections. Navigating between
| sections doesn't unload the current page, it retains it
| and context-switches to another page. This is done for
| several reasons (the main ones being performance and
| flicker-stoppage, so users aren't hit with a screen-blank
| navigating from one section to another). This trick is
| often accompliahed by being very creative with the
| routing so the user's experience is as if they are
| navigating around to different pages on a site (while in
| reality, a page navigation never occurs).
| console.cloud.google.com is an example of a site that
| works this way. AWS console does too; look closely while
| navigating around AWS and one will observe that the URL
| looks like https://us-
| east-2.console.aws.amazon.com/cloudformation/home...,
| i.e. the sub-panel is encoded locally in the fragment
| instead of up in the resource name, and going from
| subpanel to subpanel changes the fragment and pushes
| entries into history.
|
| ... but to get that seamless behavior, it has to inject
| history entries so that the back button takes the user to
| a previous _logical_ page, not a previous URL the browser
| requested. Writing the app will be more complicated if
| the back button navigates the user entirely off of
| console.cloud.google.com instead of taking them to the
| previous pane they had open.
| ysavir wrote:
| > Not more complicated in the sense of "more code;" more
| complicated in the sense of "harder to use." You had said
| "win/win" and I disagree that making apps bigger,
| clunkier, and slower by requiring more server-side
| negotiation would make them better for end-users.
|
| People always say that, yet every time I encounter an app
| that doesn't use JS navigation, it always feels faster
| and smoother...
|
| And as for them being bigger and clunkier, in almost all
| cases I've experienced, the frontend code is by far the
| clunkier and bigger of the two. But maybe it's because I
| use Ruby and other backend languages are less generous in
| their accommodations.
|
| > The hard-coded behavior of the browser doesn't always
| match the user's concept of what has happened when
| performance optimizations are added in.
|
| Eliminating JS navigation doesn't mean eliminating JS.
| You'd still be asynchronously modifying backend state and
| browser state on a single page, you're just not using it
| to change pages.
|
| > For example: for performance reasons, many web apps are
| logically divided into sections. Navigating between
| sections doesn't unload the current page, it retains it
| and context-switches to another page. This is done for
| several reasons (the main ones being performance and
| flicker-stoppage, so users aren't hit with a screen-blank
| navigating from one section to another). This trick is
| often accompliahed by being very creative with the
| routing so the user's experience is as if they are
| navigating around to different pages on a site (while in
| reality, a page navigation never occurs).
| console.cloud.google.com is an example of a site that
| works this way. AWS console does too; look closely while
| navigating around AWS and one will observe that the URL
| looks like https://us-
| east-2.console.aws.amazon.com/cloudformation/home...,
| i.e. the sub-panel is encoded locally in the fragment
| instead of up in the resource name, and going from
| subpanel to subpanel changes the fragment and pushes
| entries into history.
|
| Do you have a study that demonstrates the impact of this
| website organization with JS navigation and without JS
| navigation? There's a lot of talk about this being more
| performant and eliminating flicker, but are those real
| problems? Does HN flicker for you when you move across
| pages? I've heard these reasons a hundred times, but
| rarely see evidence that they hold up under scrutiny.
| Usually it's an after-the-fact justification rather than
| an upfront necessity.
|
| > Writing the app will be more complicated if the back
| button navigates the user entirely off of
| console.cloud.google.com instead of taking them to the
| previous pane they had open.
|
| I feel like this answer is almost intentionally
| forgetting that URI paths exist without JS. Am I missing
| something in your answer that explains why they are
| insufficient?
| shadowgovt wrote:
| > Am I missing something
|
| Yes.
|
| - navigating to a new page triggers a page reload
|
| - a page reload tears down the page context
|
| - the new page must be loaded from scratch, a new context
| set up, JavaScript started from scratch, and the page
| parsed and executed
|
| Even if the resources between the two pages are shared
| and those shared resources properly cached, time is lost
| relative to the more instantaneous process of making
| partial edits to an already loaded page and only loading
| the JavaScript necessary to pull in features that weren't
| on the page navigated away from.
|
| I recommend popping the browser inspector open when using
| AWS console or Google Cloud console and look at what's
| going over the wire. As the user navigates around, these
| web apps are only loading the chunks of the interface
| necessary, not the Chrome or the sidebar or any of those
| other already-loaded components. Those components are
| already live in the JavaScript context and don't need to
| be rebuilt from scratch because they weren't destroyed,
| since no page navigation occurred.
|
| You can make the case that those consoles are over
| complicated and could be replaced with a handful of web
| forms (not by comparing them to hacker news, the relative
| complexity of the pages are apples to oranges... If I
| were to make the case, I would make it by saying that the
| Google app engine console that predated Google Cloud
| console was perfectly serviceable, clunky and slow as it
| was). But given that they are what they are, the dynamic
| loading is much faster than tearing down and building new
| pages as a user navigates around the panels in the
| console.
|
| And given the way they work, the user expects the back
| button to go to the previous panel, not to navigate
| completely out of the web app because they happened to
| enter the experience from a specific URL.
| Dylan16807 wrote:
| And it can be as simple as clicking on an image to expand
| it, like on twitter.
|
| It's nice to be able to hit back to close it, especially
| on phone browsers. And it's also nice to stay on the same
| page context the entire time, so it can respond much
| faster and doesn't screw up the scrolling.
| ysavir wrote:
| > Even if the resources between the two pages are shared
| and those shared resources properly cached, time is lost
| relative to the more instantaneous process of making
| partial edits to an already loaded page and only loading
| the JavaScript necessary to pull in features that weren't
| on the page navigated away from
|
| Technically, yes. Whether it's significant difference is
| reflective of the engineering, and sometimes, on the
| product design.
|
| And the beauty of not using JS navigation is that you
| don't need to draw the page using JS templates. The
| dynamic data, sure, but the rest can load pretty
| instantaneously.
|
| Out of curiosity, when's the last time you built a web
| app that doesn't rely on JS navigation, and architected
| it with that in mind? What was that experience like, and
| how does it compare to your JS experiences?
| post-it wrote:
| Just include a back button in the webapp.
| shadowgovt wrote:
| Users will not understand why there are two back buttons.
| That'd be like working around pastebin issues by including
| a different "copy selection" button.
| tgsovlerkhgsel wrote:
| It would be pretty simple to open a web page, do a few user
| interactions that shouldn't trigger this behavior, and then
| penalize or deindex web sites that hijack the back button.
|
| Add manual penalties for the ones that slip through the
| automated testing.
|
| Once it becomes known that doing this means saying bye-bye to
| your traffic, sites will stop doing it.
| svnpenn wrote:
| > web apps work in anything like a coherent fashion
|
| Why should I care about that? If you have to break the
| browser for your app to work, maybe you should be doing a
| desktop/mobile app instead.
| shadowgovt wrote:
| > Why should I care about that?
|
| Because they are major use-cases for the web browser
| framework. I mean, that's a bit like asking why you should
| care about Web Audio API, or the accessibility layer... The
| fact _you 're_ not using it doesn't mean it isn't vital for
| those who do.
| rrwo wrote:
| If people have to install an app just to us your site, then
| many of them won't bother.
|
| And a significant portion of business users will be in
| desktop browsers with restricted permissions, so they can't
| install an app
| veddan wrote:
| We actually had an accidental back button hijack at a place I
| used to work at. It was an SPA, where if you navigated to / it
| would check if you were logged in. If so, you would be
| redirected (client-side) to /home, otherwise you were sent to
| /login. This was done with pushState() instead of
| replaceState(), so going back from /home would take you to /
| which would immediately see that you were logged in and send
| you back to /home.
| avg_dev wrote:
| I'm usually not interested in social engineering which I think is
| boring stuff, but I think that (1) this is a weakness on my part
| as a developer with something of a security focus, and (2) this
| is perhaps the perfect sweet spot of social engineering and
| programming.
|
| It is an utterly fascinating takedown of the back button hijack.
| Totally unethical but also very eye-opening for me.
|
| Is this kind of back button hijack and history rewriting still
| possible in modern browsers? Edit: this link leads me to believe
| this may still be possible: https://developer.mozilla.org/en-
| US/docs/Web/API/History - would love a confirmation.
| neuronflux wrote:
| How do other browsers handle this behavior? The author mentioned
| Chrome specifically.
| dmingod666 wrote:
| The moment you are impersonating Google and your competitors,
| it's very clearly in fraud/criminal behaviour territory. No
| serious business will even consider doing something like this.
| eftychis wrote:
| I don't think the site suggests serious businesses would do
| that.
|
| P.S. Yet it is not like "serious businesses" do not partake in
| fraud: Enron, _cough_ _cough_ some /most banks(creating of
| unauthorized accounts, mortgage fraud, investor fraud, etc).
| carrotcarrot wrote:
| > later used it to mess with conspiracy theory people
|
| I always find it funny how these hackers grasp for some othered
| group that they can justify mistreating. If you're gonna be a
| hacker stop pretending that you're a moral being and accept what
| you are
| [deleted]
___________________________________________________________________
(page generated 2022-10-25 23:00 UTC)