“Like” at Your Own Risk • Hacker News Board

Re: “Like” at Your Own Risk

#31

Post by [deleted] » Thu, Jan 23, 2020, 9:22 PM UTC

kerkeslager wrote: post #28

close04 wrote: post #16

Earlier quoted context omitted.

This doesn't work if you're just linking to some dynamic content. People will like the link and the link itself is static but the content provided by clicking it can change without notice.

Responding to this post, since it looks like you edited it (to clarify) and I responded to my misunderstanding based on what your post previously said: That comes down to making sure you like what you actually intend to like: you probably don't intend to like the literal bytes of the URL, you probably intend to like the content at the URL. UIs can aid in this[1] but ultimately I don't think people think that specific…

[deleted]

Re: “Like” at Your Own Risk

#32

Post by close04 » Thu, Jan 23, 2020, 9:36 PM UTC

kerkeslager wrote: post #25

close04 wrote: post #22

Earlier quoted context omitted.

The content being a dynamic webpage where if you change a single byte (ads, page logo, anything) the hash changes? Try to load any webpage twice and see if you can get exactly the same bits. And just imagine how much of the internet FB would have to periodically hash, and what impact it would have on those sites too.

That's a feature not a bug. Not only is it a feature, it's the feature. That's the entire point. It doesn't have to be the entire page that's hashed, only the content being liked. Facebook would probably never implement this, because their entire business model relies on them being a trusted authority, so trustless architectures would actively undermine them. In general, if you see my name above a post, you can assum…

> It doesn't have to be the entire page that's hashed, only the content being liked.

I think there's a disconnect here... The page to which your posted link points is the content. Whatever loads when clicking the link is the content you hash, with ads, scripts, the main body, the comments, the everythings. If I link to the front page of HN it's guaranteed it will never ever have any likes. If I link to an article that says something like "posted 6 minutes ago" then every minute the page changes.

A FB robot loads the link, receives some data (the full page), hashes that, attaches it to your "Like". Then rehashes periodically.

But every time someone clicks the same link they load slightly different content. Simply because something on that page changes. A new comment in that page, an evolving story where the site puts updates, a live blog, or a different ad loaded on the page, which are all valid reasons for a page to change. They would all invalidate the like.

So what happens next time? FB robot loads page, gets data, hashes, new hash doesn't match. Your Like is removed because the page changed. You might as well remove the Like button for anything linking outside of FB.

Educating users is an option, big warning that the content behind the link may change but let's be honest, most people will be oblivious to the implications.

Re: “Like” at Your Own Risk

#33

Post by sundvor » Thu, Jan 23, 2020, 11:05 PM UTC

buran77 wrote: post #23

beerandt wrote: post #13

Earlier quoted context omitted.

Why difficult? Just put the same permissions on the "like" as the parent object being liked, and leave those permissions alone if the parent object updates.

Likes could be counted on "what" they were given to. Liking a private post would only count when the post stays private while liking a public post would be counted/displayed either way.

Yep. But the more responsible option (for FB engineers) would be to never allow opening up the privacy level - users should only be allowed to restrict it!

If they really want to share same content with the whole world, then that should be a completely new post.

Re: “Like” at Your Own Risk

#34

Post by dmurray » Thu, Jan 23, 2020, 11:20 PM UTC

DarkWiiPlayer wrote: post #9

sebastianconcpt wrote: post #8

Scary o.O But is it the author editing the post who change it or what?

Simple example: - You upload an image of a cute cat to your webserver - You post the link to the image on some social network (using a throwaway account) - You send the link to the post to a friend, who likes the post - You switch out the image on the server for a photo of hitler (url stays the same) - You wait a day for all the caches involved to update - You act disgusted and ask your friend wtf they were thinking…

That's basically it, and this "attack" works perfectly when the web is just HTML and hyperlinks.

The remarkable thing is that it still works in the walled garden of social networks like Facebook, even though their main value-add is that they can stop people abusing the system like this.

Re: “Like” at Your Own Risk

#35

Post by kerkeslager » Fri, Jan 24, 2020, 2:31 PM UTC

close04 wrote: post #32

kerkeslager wrote: post #25

Earlier quoted context omitted.

That's a feature not a bug. Not only is it a feature, it's the feature. That's the entire point. It doesn't have to be the entire page that's hashed, only the content being liked. Facebook would probably never implement this, because their entire business model relies on them being a trusted authority, so trustless architectures would actively undermine them. In general, if you see my name above a post, you can assum…

> It doesn't have to be the entire page that's hashed, only the content being liked. I think there's a disconnect here... The page to which your posted link points is the content. Whatever loads when clicking the link is the content you hash, with ads, scripts, the main body, the comments, the everythings. If I link to the front page of HN it's guaranteed it will never ever have any likes. If I link to an article tha…

> The page to which your posted link points is the content.

I disagree, the page is not the content of the page. I hear where you're coming from though: what you're saying is a widely-accepted approximation because "semantic HTML" is not semantic, so we don't have a way to get the actual content from an HTML page. This is by design: lots of big websites have a vested interest in making it impossible to separate their content from their presentation. But I don't think future implementations have to be bound by previous bad decisions.