Embedded dashboard gets blocked on Brave

[ukutaht]

When using plausible in embedded dashboard mode, the UI gets blocked by Brave. I believe this is caused by attempting to use localStorage in the UI while it's running in a third-party context. Brave blocks storage for third-party scripts and admits that it will break some sites. We can work around by just not using localStorage when the dashboard is embedded. The storage is very much optional just to remember which tab the user had selected in various reports.

[metmarkosaric]

Another report on this via email but for Chrome/Chromium/Firefox. Seems like disabling third party cookies disables localstorage too which blocks the embed:

"When I embed plausible stats in an iframe, I get an error message about unable to access localstorage. When I allow third-party-cookies, there is no error and the iframe shows as expected. Personally, I'm never going to allow third party cookies, and I encourage all my clients to block them. Tested in Chromium. I get the same error in Firefox and Chrome but I haven't tried unblocking 3rd party cookies in either of those browsers."

[alstr]

From my experience embedding a password-protecting dashboard:

• Firefox: works fine, if I add an exception to uBlock Origin.
• Safari (no extensions): iframe loads. Upon entering the password for the dashboard, nothing happens and the following error appears in the console: Blocked a frame with origin "https://plausible.io" from accessing a frame with origin "https://mysite.co.uk". Protocols, domains, and ports must match.
• Chrome (no extensions): same as Safari, but no error appears in the console.

Safari and Chrome are pretty much the stock browser with no customisation. I'm not aware of any cookies or storage issues.

To me it seems like a CORS/X-Frame-Options issue as the embedded dashboard is not the same origin. I am not 100% sure I am experiencing the same issue as you, however.

[ryanbr]

Does enabling Enable Ephemeral Storage in brave://flags help @ukutaht ?

[ukutaht]

Thanks @ryanbr. It does help but with the #971 PR it shouldn't be an issue going forward.

More problematic is the following filter rule: https://github.com/easylist/easylist/blob/3ad8e0971dbc258f2fe4f545c4edf6381703de50/easyprivacy/easyprivacy_trackingservers.txt#L1796

It's my understanding that it breaks the embedded dashboards since they're running from the plausible.io domain in third-party context.

There's another rule introduced recently that blocks the https://plausible.io/js/plausible.js file more percicely here. Is the first rule necessary after the second one was introduced? The plausible.js file is the only tracker on the plausible.io domain.

I suppose it would require some trust from your end to delete the first rule since we could change the filename in the future. As long as we promise to not host any other trackers on the plausible.io domain so the filename block stays effective, would you be open to deleting the first rule?

[ryanbr]

Does this fix help? @ukutaht

[ukutaht]

The blockage is caused by the ||plausible.io^$third-party rule. Maybe I'm missing something but since that commit doesn't change the rule that causes the blocking, I don't see how it could solve it.

I tried adding the /plausible.js$domain=~plausible.io to my uBlock origin but it doesn't change the picture above.

[ryanbr]

Right, easylist/easylist@34f0ddf

The most I can do tbh

[ukutaht]

I think that's all that's needed to solve this issue. Amazing thank you @ryanbr!

[alstr]

From my experience embedding a password-protecting dashboard:

* Firefox: works fine, if I add an exception to uBlock Origin.

* Safari (no extensions): iframe loads. Upon entering the password for the dashboard, nothing happens and the following error appears in the console: `Blocked a frame with origin "https://plausible.io" from accessing a frame with origin "https://mysite.co.uk". Protocols, domains, and ports must match.`

* Chrome (no extensions): same as Safari, but no error appears in the console.

Safari and Chrome are pretty much the stock browser with no customisation. I'm not aware of any cookies or storage issues.

To me it seems like a CORS/X-Frame-Options issue as the embedded dashboard is not the same origin. I am not 100% sure I am experiencing the same issue as you, however.

Is this a separate issue?

[ukutaht]

@alstr yes I can replicate this on Chromium. It only affects password-protected embeds, looking into it now.

[ukutaht]

@alstr

This commit should fix embedding password-protected sites. I've deployed it live, can you confirm it's working?

The issue I see is that now the password form is vulnerable to clickjacking since the authentication request is missing X-Frame-Options. This means we cannot guarantee the security of the password protection.

I'm leaning towards not allowing embeds for password-protected shared links. What do you think? Any ideas on how to make password protection secure cross-domain without being vulnerable to clickjacking attacks?

[alstr]

This commit should fix embedding password-protected sites. I've deployed it live, can you confirm it's working?

Still not working for me at the moment. Behaviour in Chrome and Safari remains the same as originally reported.

As regards a solution, I think iframes are going to intrinsically always have these problems when not the same origin. I'm not aware of any way around this other than self hosting, or some kind of API to retrieve stats that you can then render yourself.

[metmarkosaric]

I just checked and the embedded dashboard works all fine on Brave standard mode and on Chrome/Firefox with uBlock Origin enabled. Thanks @ryanbr!

[ukutaht]

@alstr thanks for testing :)

I will remove all attempts to support password-protected embeds. As mentioned they are vulnerable to clickjacking type attacks. Since we cannot guarantee the safety of authentication, we will instruct users to implement authentication on their side.

[metmarkosaric]

Hi @ryanbr! We have several new reports of our embedded dashboards getting blocked in Brave and Firefox with uBlock Origin. The block is caused by ||plausible.io^$third-party in EasyPrivacy again so it seems like the change you made for us has been reverted. Would you be able to help out please? Thanks!

[ryanbr]

Came from easylist/easylist@261dccf

Given that plausible is adding more scripts, we're not going to keep adding specific script blocks. We're not going to have 101 plausible specific blocked scripts. I have no patience at all. For the end user if we don't want to be tracked, plausible.io^$3p is probably the best option going forward.

[metmarkosaric]

thanks @ryanbr! we haven't made any changes on our side. embed dashboard has no tracking, it allows people to display their dashboard on their sites to be transparent to their visitors. currently, the page where they embed their dashboard ends up being blank for users on uBlock Origin etc so they get reports from their visitors that something is broken on their website and then they send these reports to us.