Hacker News Reader

Comment by renewiltord | Hacker News Reader

If I want to iframe a website that doesn't want to be iframed on my browser so I can make some quick local tool, how do I even do it now? Previously I could just nuke x-frame-options and the CSP headers and that's all accessible via extension hooks but cookies aren't easy enough to do that way.

Like, go ahead and try iframing linkedin.com, with x-f-o and CSP nuked it'll work on Firefox today but not Chrome. Even trying to intercept the cookie doesn't work.

I wish there were a way to just easily turn this stuff off so I could manipulate my user agent more easily.

View on HN

Isn't it the case that you can easily turn it off, in your own user agent?

For example, in this case (Firefox), to turn this new behaviour on ahead of time, the article says you can go to about:config and set network.cookie.sameSite.laxByDefault and network.cookie.sameSite.noneRequiresSecure . I'm sort of hoping/assuming that after this becomes the default, you'll still be able to override it using those exact about.config properties.

You should probably also do that in a separate FF profile, which is easy enough. After all, you probably shouldn't disable security/privacy features like this for your normal browsing.

Firefox does have that, thank you, but I think the Chrome equivalents don't do the trick. I believed for no reason that would be the problem on Firefox too.

For Chrome:

chrome://flags/#same-site-by-default-cookies

chrome://flags/#cookies-without-same-site-must-be-secure

I found that at least the #same-site-by-default-cookies flag behaved as I would expect when setting it to "Disabled". Use case was to load an iframe that sets it's own cookies with no SameSite value and still have that value default to "None".

We fixed this issue properly ("SameSite=None; Secure" in the cookie set in the iframe), but using the #same-site-by-default-cookies flag was a workaround for a little while.

What was a bit strange was the default behavior on Chrome was different for users even on the same Chrome version. They seemed to be rolling it out in phases. More info on that here: https://www.chromium.org/updates/same-site

Hmm, I did toggle those flags over to no avail. Perhaps linkedin.com is using additional protections that don't show up. It _is_ a 200, but the Chrome page just shows the broken icon with "www.linkedin.com refused to connect." even with x-f-o suppressed, CSP suppressed, and those flags tripped. All on 84.0.4147.105 on Linux/Mac.

Ah well, I guess I take the L on this.

We figured it out. They moved some of CSP/X-F-O to `extraHeaders` in a recent release and it was being rolled out slowly across the world, so we were on an early batch of rollouts. Works now.

In general: Use a custom proxy instead of using your browser as a proxy, in essence.

I'm curious too - what's the use case for this? Why would you want to iframe linkedin?

It was a trivial half-hour project that I sunk-cost-fallacied into a couple of hours. I wanted to embed LinkedIn into our recruiting lead qualification tool so that you don't have to open a new tab (it's right on the page in a two-pane display). It was enough of an improvement that people could just start their day, qualify some 10 leads, and then bang on with the day. We had a chap build it and it worked really well actually till SameSite became required on Chrome. Opening in a new tab was frustrating enough that people would feel like maybe doing a couple and then push it to the rest of the day and it would fall by the wayside against their "real job", so to speak. Besides, they'd be doing it feeling like an obligation which I don't think puts one in the right frame of mind.

Yeah, so I think this is pretty much the a kind of scenario the feature is designed to break - an essentially stock browser navigating to some site, that can then wrap a trusted site, and potentially be a stepping stone for phishing or other nastiness. Obviously, if you have detailed control over the client - everything goes! But for fairly standard browsers, you don't want to allow this kind of nesting; at least not when the two sites aren't cooperating (and clearly linkedin isn't).

It's possible there's some addon api to work around this, otherwise you'll need to use a proxy - which isn't too hard, really. Essentially: you need to have admin level control over the browser to allow this, or some other proxy; the browser won't allow a random website to see another site's cookies, even indirectly - which is by design.

So in your case: since this is a feature, not a bug - a trivial workaround looks unlikely.

Oh yeah I totally understand why it is what it is. But I like being able to choose a configuration combination that releases me from the rules.

There are better ways than iframing for test/dev - eg. Fiddler, Selenium

Many sites have been blocking iframes for a decade or more.

They’re not good tags, if you want a link then make a link.

If you're happy using extension hooks already, you could consider a greasemonkey userscript - allowing you to run javascript when the browser is already at linkedin.com

I did exactly this in Chrome the other day. What worked was to put the iframe on a chrome-extension:// page and give the extension <all_urls> permission.

Reply on news.ycombinator.com