Hacker News new | past | comments | ask | show | jobs | submit login

That's still trackable via JS for instance. Selecting & copying plain text are (AFAIK) not trackable, hence the suggestion from parent.



Nearly everything that you do on a page is trackable if you have JS enabled including how you moved your mouse on the page (https://api.jquery.com/mousemove/).

To keep the technical details short: the events are logged with JS and sent over either ajax or a websocket in the background as you navigate the site.


Text select and copy raises the respective events in supported browsers. See https://developer.mozilla.org/en-US/docs/Web/Events/copy for the copy event.


Selecting and copying are both definitely trackable.


Is "right click and copy url" trackable as well? Genuine question.


Yes, it is. I've tried it on Facebook several times (since I try to avoid clicking on external links on the platform) and it shows related links the moment I finish the right click and copy link location action. There is some variation depending on where one clicks (on the image that has a link or the actual hyperlink), but Facebook definitely knows in most cases what URLs someone is copying to the clipboard. The first time I saw it I was very annoyed.


Because the website notorious with spying on every single user action was spying on a user action?


I get annoyed by it too, because sometimes I want to read an article but don't necessarily want fb to continue serving those articles to me. I don't really know what happens inside the Facebook machine, but I imagine clicking a link indicates you are interested in a topic. Sometimes I just want to read trash.


So google the title in an incognito window, or alternative and preferably, stop using that site all together.


Yes, I tend to do something along those lines when I don't want to be tracked. To the original point, it's an annoying extra step to have to do but not unreasonable enough to stop using the site, I'm simply answering your question on why someone might find it annoying.


Yes and yes - Right click raises an event, and copy specifically raises an event.

If in doubt: If it happens over or in a browser window, it is probably trackable from JavaScript.

See: https://developer.mozilla.org/en-US/docs/Web/Events/copy


Over a browser Window? So If my 1Password window overlaps with my browser window, the page I'm on could sniff the entire 1Password window? Seems like a bunch of FUD..


It's not really polite to call it FUD right off the bat, especially when you're probably just misunderstanding. A browser obviously can't get events from a different app.


Moving your mouse over the window, despite not interacting with it, will allow the page to track your cursor, and could provide a surprising amount of information. That's why I wrote "over".


You built a strawman, but it can actually be dangerous to interact with an application on the same screen as a browser!

https://jameshfisher.github.io/cursory-hack/


Subject to the same origin policy.

https://en.wikipedia.org/wiki/Same-origin_policy


That protects you (to some extend) from page A accessing resources from page B.

Same origin policy doesn't do anything to stop you from being tracked, though.


Yeah, of course, I was replying to a post about the concern about a website getting your entire 1password database.


Maybe not in itself, but "user mouse pointer is above the url" and "user right clicked" are.


It is trackable in itself through the `copy` clipboard event (https://developer.mozilla.org/en-US/docs/Web/Events/copy). Both keychord and contextual menu will trigger the event.


The parent was asking whether the "Copy Link Address" (Chrome) or similar is other browsers is trackable though, not the more general copy to clipboard.

I don't think that one is.


Presumably if you select and copy from a page's source view (eg via Inspect in FF) then you'd overcome tracking of specific interactions?

Or if you just block scripts.


The site serves no JS. Of course you shouldn't trust the site, so you should disable JS explicitly (via NoScript or other means) too.


In that case a clickable maybe link isn't trackable. Afaik that requires js


not if the link itself is unique for each user trivial to implement, this is how email campaigns track what you clicked in a email ( email after all do not server js)


doesn't that only work for sites the link creator has control of? i don't see how the technique can be used with links a search engine finds and then gives out to anon users.


This is how it would work.

1. The search engine adds itself to the tracker list in the magnet URI (&tr= query parameters), but with a unique subdomain and using HTTP (i.e. it adds http://asdfkja.skytorrent.in/announce to the tracker list)

2. The client announces itself to the tracker, sending the unique "Host" in the GET request (asdfkja.skytorrent.in in the example).


In that case the plain text link would be just as trackable.


magnet links are user-side. They're like email addresses or phone numbers.


This doesn't prevent their users from being tracked.

Email addresses can be used for tracking by having each request for an address (e.g. each GET of a "contact us" page) return a different email address (e.g. contact43327@example.org). Checking which address gets used allows the GET request (and all associated information) to be associated with the email message (and all associated information).

Likewise, magnet links can be tracked by looking for torrent clients trying to access them. A sibling has pointed out that unique tracker URLs can be used for this. Another way would be to make up a unique content hash for each request, then lurk on the DHT looking for queries for those hashes.

If the operator has no qualms with transferring data (e.g. being directly exposed to copyright infringement) they could even service such requests, with the user being unaware of the fact they're being tracked: the operator alters the hash by making some innocuous "watermark" change to the content, e.g. altering a filename inside an archive; each time a chunk is requested, the operator fetches it from the "original" and passes it on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: