Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not check for new version of Threema Web on every route change #909

Open
ovalseven8 opened this issue Oct 7, 2019 · 7 comments
Open
Labels
chore enhancement Enhances functionality

Comments

@ovalseven8
Copy link
Contributor

Bug Description

Currently, Threema Web sends a request to check if a new update is available every time you switch conversations within Threema Web. This is some kind of activity tracking that is unnecessary.

Potential Solution

@lgrahl wrote in #183 (comment):

We can use a service worker to pre-fetch all pages and then just check the version every once in a while.

@ovalseven8 ovalseven8 added awaiting triage Should be triaged by a developer. bug It's a bug! labels Oct 7, 2019
@lgrahl lgrahl changed the title Do not track the user to check for new version of Threema Web Do not check for new version of Threema Web on every route change Oct 7, 2019
@lgrahl
Copy link
Contributor

lgrahl commented Oct 7, 2019

The title was misleading since we absolutely do not track. This is about the possibility that we could gather some usage info.

@lgrahl lgrahl added chore enhancement Enhances functionality and removed awaiting triage Should be triaged by a developer. bug It's a bug! labels Oct 7, 2019
@rugk
Copy link
Contributor

rugk commented Oct 7, 2019

Not only you, the threat model also has to consider a third-party, i.e. an network level attacker. They can certainly see the request and an estimated size. And regular pings of a similar size would likely be able to correlate to this type of request.

@dbrgn
Copy link
Contributor

dbrgn commented Oct 7, 2019

We can use a service worker to pre-fetch all pages and then just check the version every once in a while.

That won't work, since there may still be a mismatch between the template and the controller, leading to UI errors

What we could do is inlining all HTML templates into the JavaScript files. That means a larger initial page load, but no template requests after the webapp has been loaded.

Note that we do not request the templates ourselves. That is part of the AngularJS "partials" system.

Not only you, the threat model also has to consider a third-party, i.e. an network level attacker. They can certainly see the request and an estimated size. And regular pings of a similar size would likely be able to correlate to this type of request.

I don't understand that. This is only about the fact that the webserver could track how often someone switches a conversation, because that's when the GET version.txt request is being sent. There is no other information being leaked. Once the template is loaded, it stays cached in the browser.

No conversations or chat messages are ever transferred to that webserver.

@lgrahl
Copy link
Contributor

lgrahl commented Oct 7, 2019

That won't work, since there may still be a mismatch between the template and the controller, leading to UI errors

You open web.threema.ch. It then pre-fetches all templates via the service worker. Subsequent fetches will return the same template version. What's the problem?

@dbrgn
Copy link
Contributor

dbrgn commented Oct 7, 2019

Ah, if you guarantee that the templates will not survive a page reload, then that's fine. If you only check the version "every once in a while" and cache the templates for longer than a single page load, then the JS (which probably isn't cached) will expect newer templates, but you'll get older templates from the cache.

Caching will work if you either cache and then invalidate all static files (js, css, templates, images, etc) or none.

You'll also need to get AngularJS to load those templates via a fetch request. Not sure if that's possible or not. If privacy of those version requests really is a concern, then inlining the templates is much simpler and much less error-prone. Note that once a service worker is caching data that isn't properly invalidated, we have no way to easily fix that using a new release.

@lgrahl
Copy link
Contributor

lgrahl commented Oct 7, 2019

AFAIK, the browser will always use fetch underneath which is what you're hooking into. There's also a way to do cache versioning if we really want that. Take a look at it before calling it more error-prone prematurely. 😜

@dns2utf8
Copy link

I like the prefetch everything with a service worker idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore enhancement Enhances functionality
Development

No branches or pull requests

5 participants