Activitywatch: Remove extraordinary-seeming claims of security

[ErikBjare]

We currently advertise ActivityWatch as secure. This makes me a bit uneasy since we rely on the host machine being compromised haven't actually done anything except forbid connections from anyone else than localhost by binding to 127.0.0.1.

Things that could go wrong:

• If an attacker hacks the host computer, all historical data is leaked unencrypted.
  
  
  
  • Could be solved by encrypted backups/sync.
  
  
• More?

We don't have much security in place right now (and we don't use any crypto anywhere). That's not a problem right now since there is little need: we don't interact with anything outside the host system.

Anyway, removing claims of security and instead focusing on advertising privacy would feel a lot more honest.

Places where we might make claims about security:

• README
• Docs
• Website

It's my ambition that we one day will be able to once again claim some above non-standard level of security. But it might be a while.

Edit: I just had a crazy déjà vu. Feels like I've written about something similar before.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[johan-bjareholt]

Personally I think it's stupid to try and secure something if the host
computer is already compromised. That isn't activitywatchs problem but the
users fault. If the user wants to encrypt the folder where the aw buckets
are stored that's up to them, but to add it as built-in functionality is
either a 2.0 feature or a feature that should never be implemented at all
in my opinion. Even if the computer was hacked they could just install a
keylogger and wait for the next time the user inputs the password if they
have patience. It only becomes security by obscurity.

As long as activitywatch runs locally on the computer and binds to
127.0.0.1 everything should be considered secure, but as soon as we start
with syncing and want want the possibility to expose aw-server and/or webui
to the internet (or even on a local network) with authentication is when we
should be cautious, not now.

On Jun 16, 2017 10:45, "Erik Bjäreholt" [e-mail] wrote:

We currently advertise ActivityWatch as secure. This makes me a bit uneasy
since we actually completely rely on the host machine being compromised.

Things that could go wrong:

• If an attacker hacks the host computer, all historical data is leaked
  unencrypted.
  
  
  
  • Could be solved by encrypted backups/sync.
  
  
• More?

We don't have much security in place right now (and we don't use any crypto
anywhere). That's not a problem right now since there is little need: we
don't interact with anything outside the host system.

Anyway, removing claims of security and instead focusing on advertising
privacy would feel a lot more honest.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ActivityWatch/activitywatch/issues/71, or mute the
thread
https://github.com/notifications/unsubscribeauth/ABVW5GC21wp_eV2wY7nTpI7U5LJtRjaNks5sEkCTgaJpZM4N8MEg
.

[ErikBjare]

Personally I think it's stupid to try and secure something if the host
computer is already compromised.

Agreed, that was unnecessary to write of me.

If the user wants to encrypt the folder where the aw buckets
are stored that's up to them, but to add it as built-in functionality is
either a 2.0 feature or a feature that should never be implemented at all
in my opinion. Even if the computer was hacked they could just install a
keylogger and wait for the next time the user inputs the password if they
have patience.

Well, the user doesn't necessarily need to input a password very often. We could for example encrypt all events older than 7/30/90 days. If we also used asymmetric encryption then a password would only be needed if the user wanted to query the old data, encryption would only need the public key.

As long as activitywatch runs locally on the computer and binds to
127.0.0.1 everything should be considered secure, but as soon as we start
with syncing and want want the possibility to expose aw-server and/or webui
to the internet (or even on a local network) with authentication is when we
should be cautious, not now.

Agree with the bolded, it's just that calling it secure makes me feel like an impostor when I haven't actually implemented any significant security measures. Not sure what people really think about that.

[johan-bjareholt]

Good points, just wanted to verify that we are on the same page. Seems reasonable.

[Otto-AA]

Are there any future plans on this?

I personally feel a bit uncomfortable knowing, that anyone who gets access to my computer at one time (either virtual or physical) can download my whole interaction with it. If this was limited to 7/30 days, and all events past this would be encrypted and/or summarized (#189 ) I would feel much more secure. Encrypting would be good against unintended physical access of the computer and (judging from my narrow knowledge about this topic) make it harder to automatize the attack. Summarizing would only give vague use statistics instead of an extremely detailed one.

That's why I would love an option to encrypt/summarize old events. But I understand if you have other priorities, just want to know the status of this :)

[ErikBjare]

@Otto-AA I agree that would be great, but that plan is currently on hold. However, encryption of data will become a lot easier with the import/export system being put in place (almost done, I just need to add an import-button in the web UI). With this, a quick solution would be to: export bucket, encrypt the export, delete bucket in the server, then decrypt + import the export to restore/visualize.

This could be built as a ActivityWatch client, and anyone who'd be willing to build an MVP would greatly speed up the process.

[leoschwarz]

Since https://activitywatch.readthedocs.io/en/latest/features/filtering-data.html still says this is a planned feature and there's this discussion, I just want to mention to avoid duplicate efforts that I'm starting to implement this feature as a client, from a quick look at the API the essential tools should be around.

I agree with the privacy concerns, and it's the reason I've ended up here instead of some cloud based tracker. I think there's a tradeoff between how much raw data do I want to store for future insights and how much at most am I willing to store. For example having every single URL you visited over the last 10 years around might not be something you want, but maybe the last week or two.

I have an idea about the design already, but I'm still not sure how custom mutations to the data (e.g. remove everything other than the domain from an URL) could be specified. Initially I'll allow Python snippets but this might not be a viable option later.

[johan-bjareholt]

@leoschwarz

For example having every single URL you visited over the last 10 years around might not be something you want, but maybe the last week or two.

I have an idea about the design already, but I'm still not sure how custom mutations to the data (e.g. remove everything other than the domain from an URL) could be specified. Initially I'll allow Python snippets but this might not be a viable option later.

Yeah, I can see how some people are not comfortable with that.

To start we could start with making our DELETE endpoint for events in aw-server better so it becomes easier to delete for example all events in aw-watcher-web within a timeperiod similar to how you get events within a timeperiod, then it should be easy to make a simple script which deletes all events older than 30 days which can be run every day. Should be good enough as a start before we make this feature built-in to activitywatch.

Modification of events is currently not possible though, in the future we hope to implement this but it is not a high priority.

[leoschwarz]

Modification of events is currently not possible though, in the future we hope to implement this but it is not a high priority.

In aw_datastore there is the def replace(self, bucket_id: str, event_id: int, event: Event) -> bool method, it would just need to be exposed however I'm not sure if you want this to be part of the "public" REST API? (Also I just noticed the contract is not the same with regards to setting event.id = event_id for all implementations.)

[johan-bjareholt]

@leoschwarz

In aw_datastore there is the def replace(self, bucket_id: str, event_id: int, event: Event) -> bool method, it would just need to be exposed however I'm not sure if you want this to be part of the "public" REST API?

Yeah, there are no technical reasons why we can't just make an API for it, we simply just have not decided on one or implemented it since we have had no use for it. The replace method is currently only used for heartbeats.

(Also I just noticed the contract is not the same with regards to setting event.id = event_id for all implementations.)

The only datastore methods we care about are peewee and sqlite and sqlite does not set event.id because it batches sqlite inserts to speed up performance very significantly. SQLite really is not made for lots of small inserts and using peewee therefore creates a lot of unnecessary disk I/O which makes it much slower than the sqlite datastore. The flaw with this performance improvement is though what you have discovered, since the inserts are batched and are simply queued until more requests go in we cannot return the ID as we don't know what ID SQLite will assign the event.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.