Hacker News new | ask | show | jobs
by WatchDog 1533 days ago
Functionality aside embedding random scripts from twitter seems like a big risk for security and privacy.

At a minimum, it should probably be embedded in a sandboxed iframe.

Just taking a screenshot, and linking to the tweet, seems like a more robust solution, that won't randomly stop working, and doesn't have the same privacy issues.

6 comments

"Functionality aside embedding random scripts from twitter seems like a big risk for security and privacy."

When I started blogging again, I wanted to render my Twitter feed on the homepage, as a sort of bitesize alternative to the regular content, but I too have a deep aversion to allowing external scripts on my websites. So I added some code to my Hugo theme that pulls the tweets from my profile via the Twitter API and renders them statically.

This is still "vulnerable", in a way (though not the same kind of vulnerability as embedding third-party scripts): if Twitter disappears—or just stops returning your tweets for some other reason (e.g. they shut down their API or your account)—then you lose access to your content. It can be mitigated by making sure your SSG output is also in version control—not just the input. (While you're at it, it's a good idea to make sure your SSG is version controlled, too. That doesn't have to be a whole copy of the SSG source and/or binary in your repo; it can be e.g. its version string.)

That of course still leaves open the matter of whether/how you're making sure to trigger a new build for every new tweet.

For me, all I cared about was not loading their script. I'm not at all attached to my tweets, so I'm not really willing to put any effort into preserving them for posterity.

> That of course still leaves open the matter of whether/how you're making sure to trigger a new build for every new tweet.

Cron every five minutes.

Back when I was applying for my first career position, one of the companies asked for a demo project, with one of the options being something that could poke at the Twitter API.

It was pretty darn simple to get the text of a tweet, and just apply some styles to it. If one was motivated, making something to replace Twitter's version of embedding would not be very difficult.

Hey Victor, would you mind sharing that piece of code?
Hey, sure, I set up a repo just now. Lemme know if it works for you or not: https://github.com/victorstanciu/hugo-tweets
That said, screenshots of such things bear their own problems in terms of accessibility for screen readers and other supportive devices.
> bear their own problems

Sure, but these problems were anticipated in the design of, certainly later, HTML specs. One example: the ALT text tag for images, which has been part of the spec since at least HTML4, originally published as a recommendation in 1997.

Every image on your website(s) should have ALT text to be screenreader friendly and, if it doesn't, that's on you: it doesn't make using images an inherently bad or accessibility-unfriendly idea.

The unstyled blockquote is probably enough, without pulling down the JS to embed twitter's marketing, tracking, and whatever else they might be observing.

Is it necessary for a quoted tweet to look exactly like it came from Twitter when the text and a link serves an identical purpose?

That said, if someone wants to delete a tweet or otherwise correct the record, are you prepared to issue a correction of your own when quoting a tweet? The internet is particularly unforgiving when it comes to this.

There should be an HTML <remote> tag or something that downloads and embeds HTML from a remote site without scripting
Don't [i]frames solve this problem? They can use scripts, sure, but those scripts are contained and cannot reach outside their box.
A quick sandbox attribute and the scripts will be disabled: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element#em...

<object> or <portal> already exist. maybe they would work?

<portal> is an experiment/pet project pushed (and only implemented!) by one browser vendor, which as far as I know remains feature flagged.

It was shipped behind a flag with an initial implementation vulnerable to a same origin policy bypass as well as local file disclosure. As far as I can tell the only reason it wasn't assigned a Moz standards position of "harmful" is because Google argued "it's actually still a work in progress!" (three years ago).

Refs:

- https://research.securitum.com/security-analysis-of-portal-e...

- https://github.com/mozilla/standards-positions/issues/157

Ok, but then Twitter is just going to make that return a 404. How does this solve the problem?
The behavior of the object element is to use its child nodes as fallback content in the event that the resource cannot be loaded, similar to the the treatment of images' alt attributes for images that fail to load. This isn't to say that this protects against a determined adversary (who might then chose not to return HTTP 404/410 and instead HTTP 200), but the mechanism is there.
why would they?
Because you're requesting a resource from them, and they consider that resource to be deleted?
i was responding re/ security and privacy. showing that the tweet is deleted would be expected behavior
Are you asking or telling, I'm prepared to answer if asking.
That's exactly what an <iframe> is.
iframe is loading a whole page with script permissions (and sandboxed). it seems there isnt any tag for adding a remote snippet of html, like you can do with ajax
What do you mean by "remote snippet of html"? An iframe loads whatever's on the other end of the src URL. If that's a "whole page", then it loads a whole page. If it's just a "snippet" of content, then it loads that. Any snippet you think of can be loaded by iframe exactly as described. The only hitch, really, is that it's always treated as block-level content instead of CSS-style "inline" flow-level content, but that's clearly not relevant to the use case at hand—embedded tweets are already block-level.

It's not clear what you're asking for. (E.g. do you want that snippet not to be sandboxed?)

iframe is a full page. i mean some HTML code, a div or some text or a table etc. the kind of things we load with Ajax. The equivalent of <img>, but for HTML content : <remotehtml src="https://twitter.com/snip/12345678" />
This isn't really any clearer than your earlier comment.

> iframe is a full page.

An iframe loads whatever you give it. If you give it a URL to a "full page"/"whole page", then it loads that. If the URL leads to e.g. "a div" or "a table", then that will be loaded. That's under the control of the person who's putting stuff on the other end of the URL. To repeat, there is exactly one case where this doesn't hold up: when you want the loaded content to be inline and not block-level (e.g. "some text"—and if inline content is what you meant, then you should say that instead of just giving another vague response; again, though, even if that is what you want, how would that be relevant to the use case we're talking about here: embedding tweets?)

Guess I'll start on that exploit now, beat the crowd.
Totally agree. I wonder if this is by-design. Lots of companies would love to have control of a javascript snippet operating on the worlds biggest websites.
This practice can hardly come as news. They all do this with their social buttons and have been for almost 20 years
> Just taking a screenshot, and linking to the tweet, seems like a more robust solution, that won't randomly stop working, and doesn't have the same privacy issues.

And have none accessibility.

You can include a copy of the text along with a screenshot, or put it in alt text…
No, it is not for that.
also this is why you use those sha integrity hashes.. so other sites dont randomly update their script to do evil things