1713414 - Fingerprinter protection breaks motorola.com.br by blocking https://io.vtex.com.br/

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect)

Description

[08xjcec48]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

https://www.motorola.com.br/smartphones only shows the items after I turn Tracking Protection off for this site.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Johann Hofmann [:johannh]]

Seems to be related to FP protection and goes away when I unblock https://io.vtex.com.br/

Comment 3

[Thomas Wisniewski [:twisniewski]]

It turns out that this is a rather deep rabbit hole to go down if we want to use a shimming approach, as it looks like Motorola relies on a lot of io.vtex.com resources for their storefront pages. And not only does io.vtex.com serve a copy of jQuery as a dependency, but also several custom UI-widget rendering scripts and the Dust templating library they rely on, plus their base API script -- all of which Motorola's site seem to rely upon. I'm of course assuming that they also rely on io.vtex.com cloud servers to do any actual cart check-out, wherein users actually shopping would need to send data to those servers at some point regardless of the protections we offer them.

So we really have a few choices here, and none of them feel all that great:

1. shim just the minimal resources for the broader smartphones listing, but not the product pages (which involves having a copy of jQuery 1.8.3 core, and a shim for their core API). Those pages would remain broken.
2. shim the above, plus what's necessary for their individual phone pages (which involves cached copies of the custom io.vtex.com UI element scripts, Dust, etc). This would still require allowing requests if the user makes an actual purchase.
3. just let the user know when they're on a page requiring these storefront scripts, and let the user opt into just allowing the truly necessary io.vtex.com resources, rather than dropping all protections for the page.

I certainly wouldn't advise the second choice, since it means having to bundle delicate-looking third party scripts, and keeping them up to date, plus a great deal of testing to ensure the pieces all fit together. The first isn't much better, but at least we'd be bundling only a shim for the API along with a copy of jQuery 1.8.3, so keeping it up to date and vetting the code for security issues should be a fair bit easier. But it's still a sub-par experience if we don't also do #3 for the still-broken pages.

So honestly, the third option seems like the practical way forward here (presuming that we cannot use some kind of anonymizing proxy). I already suspect that we'll have to do the same for Digital River's storefront in strict mode, so I have been thinking about how to do this with the shim code already. Of course it does mean some UX considerations at the very least, but that seems relatively realistic to me compared to the other options.

Comment 4

[Johann Hofmann [:johannh]]

Thank you Thomas for the thorough analysis, that doesn't look great indeed. I think Arthur volunteered to own outreach for this so I think I'd like to see if we get any response from them on this.

Do you reckon we'd have any success allow-listing specifically the harmless resources hosted on io.vtex.com that are needed to make the site work, i.e. jQuery and the rendering stuff, but leaving their main API script blocked?

Comment 5

[Thomas Wisniewski [:twisniewski]]

Unfortunately it looks as though their scripts rely on the window.vtex and window.vtexid objects to be present before they even try rendering the full UI, so we would need to shim them even if we allowed the jQuery and UI-rendering scripts.

Comment 6

[Ksenia Berezina [:ksenia]]

There is a similar issue with https://www.drogariavenancio.com.br, they have a number of resources on https://io.vtex.com.br/:

The resource at “https://io.vtex.com.br/front-libs/jquery/1.8.3/jquery-1.8.3.min.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/rc/rc.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/portal-ui/v1.14.7/scripts/vtex-events-all.min.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/portal-ui/v1.14.7/scripts/vtex-analytics.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/front-libs/front-i18n/0.7.2/vtex-i18n.min.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/front-libs/front-utils/3.0.8/underscore-extensions.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/front-libs/dustjs-linkedin/2.3.5/dust-core-2.3.5.min.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/portal-plugins/2.9.13/js/catalog-sdk.min.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/vtex.js/v2.12.0/vtex.min.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/portal-plugins/2.9.13/js/portal-sku-selector-with-template.min.js?v=1.4.1787.2340” was blocked because content blocking is enabled.
The resource at “https://io.vtex.com.br/portal-plugins/2.9.13/js/portal-template-as-modal.min.js?v=1.4.1787.2340” was blocked because content blocking is enabled.

Comment 7

[Paul Zühlcke [:pbz]]

Same issue with swift.com.br, see Bug 1718211

Comment 9

[Thomas Wisniewski [:twisniewski]]

Another case here: https://www.tiendasjumbo.co/

Comment 10

[Paul Zühlcke [:pbz]]

Fixed along with the other vtex issues, since it's no longer on the FP list.

Comment 11

[Thomas Wisniewski [:twisniewski]]

Paul, was this maybe regressed recently? On today's nightly I see io.vtex resources being blocked on https://www.suzukiautos.com.co/ in a private browsing tab, and it's blocking io.vtex resources.

Comment 12

[Paul Zühlcke [:pbz]]

io.vtex.com.br is no longer on the fingerprinter list, but it's still on the tracking list. This list is not enabled by default in normal windows, but it is enabled in private browsing or when ETP is set to strict.

Comment 13

[Thomas Wisniewski [:twisniewski]]

Oh right.. then that's something we're not going to be able to easily resolve. The best I think we could realistically offer here would be to detect that the site is using io.vtex.com and present that fact to the user so they can make an informed decision to allow their resources and refresh the page. I'll be exploring that sort of option ASAP, hopefully as part of SmartBlock 4.0.