Import only part of calendar to ICAL? about borg_calendar HOT 6 OPEN

The export limit exists solely to make sure that users with large calendars can still sync. Large calendars will make syncing too slow or even impossible on some ical servers and also with some android sync apps. I have 33 years in my calendar. It isn't feasible to sync it all.

Maybe the level of privacy that you desire would be best suited for fully encrypted calendar services?

from borg_calendar.

Ah I see. I didn't know the purpose of the export limit until now. Unfortunately, my problem isn't whether the data is encrypted in transit, but rather at the endpoints. For example, if I use an encrypted calendar service such as Proton.me's service, someone could still access my calendar at the vulnerable endpoint; by stealing my phone. It's not possible to fully lock down the phone without great inconvenience. A phone that's powered on could be vulnerable to a cold boot attack, so the only way to prevent all data access would be to have the phone powered off; a very impractical option. Also, there are quick ways such as fingerprint or facial unlock that I would have to give up if I wanted to allow access only via password. Fingerprint or facial unlock allow me to trade some measure of safety for increased convenience. I accept the tradeoff because I can limit how much data is stored on my phone.

Is it realistic to hope for a feature to export a custom date range? That way there would be no need to worry about how whether days, weeks, months, or years need to be imported. With such a feature, I could even export a custom time period in the past (e.g. the week during which I was camping last year). Such a feature would have uses beyond privacy protection; for example, I could share part of my schedule with someone without sharing my entire life with them.

from borg_calendar.

I don't plan to add such a feature.

Your use case is quite unusual. In a single Borg database you have data of no sensitivity mixed with data that is so extremely sensitive that you are worried about someone doing a cold boot attack on your stolen phone?

All of my sensitive data is encrypted at rest, even on my personal computers. My Borg database is kept on my google drive. The very few sensitive records that I keep in Borg are encrypted in Borg. All of my other data outside of Borg is gpg encrypted at rest.

from borg_calendar.

The cold boot attack scenario was hypothetical. I was only trying to say that a phone cannot truly be secure, so I don't try to store truly sensitive information on it. For example, I wouldn't store sensitive appointments on mobile devices. I would delete them before or after the export. But deleting the sensitive appointments would be much easier if I could select only the current week rather than the past year of appointments. Example: Export 1 week of all appointments to a different copy of Borg. Delete all sensitive appointments there. Export again, then move file to mobile device. Or: Export 1 week of all appointments and import directly into mobile device, then delete all sensitive records. This option has some problems because secure deletion on flash memory is difficult.

On personal computers, of course encryption is an option. Google Drive is not end to end encrypted, so the only true encryption there is within Borg itself. Even if we ignore this problem, there are at least 3 other problems. First, I'm actually not sure encryption within Borg would even work with third party apps on a phone. For example, there is no Borg Android app right now, so I would have to use a third party app to import the .ics file. Second, even if the app supported encryption, I would not want to memorize/enter another key on my phone. There are unique risks associated with mobile devices. For example, a CCTV camera could catch me typing in my Borg password. And I still prefer having facial or fingerprint unlock; less secure options that would work on a time-limited and sanitized calendar file. Third, if you encrypt only sensitive rcords in Borg, you have less plausible deniability if the rest of your calendar is viewable. An adversary who could not open the encrypted records would conclude you had something to hide.

There are also reasons unrelated to security why having the option of exporting only a certain time period would be advantageous. Suppose I'm working with a group on a project and I want to share only the part of my calendar pertaining to the timeframe of the project with the group. I certainly wouldn't need to share a year of my personal life with the group for this purpose. The easier way would be to export only the relevant time period, then clean up the file by deleting (or renaming) events unrelated to the project. The new group calendar would be derived from a subset of my personal calendar.

Hypothetically, if I implement exporting a selected date range to an .ics file, would you accept such a commit? I cannot commit (no pun intended) to being a general contributor to the project, but I may be able to add just the one feature if you would accept it.

from borg_calendar.

Would it make more sense for me to just add an option to not export (or sync) appointments marked as private? That would be a feature that makes much more sense to me.

If you implement a date-range export, I'd have to see the code before deciding whether to accept it in the master branch. I assume it would be a single new menu option for the ICS menu to Export with a date range, and then some dialog to select a date range.

from borg_calendar.

Marking appointments as private would solve most of the problems with decrypting a phone in public. No more having to memorize a password or worrying about plausible deniability. The data is just not there.

But I still have some concerns that I feel exporting a smaller set of data would be better suited to address. Even if I don't export any appointments marked private, having the entire year of all past appointments still reveals more information to someone who finds my phone than if I only had the past week. I don't have any real objection to marking appointments as private; I just think not having any appointments older than a certain date reveals even less information. If someone could see non-sensitive appointments for the past year, they may still know things like which restaurants you go to, hotels you check into, which pizza delivery services you use, etc.

Are these appointments individually a gigantic problem? Maybe not. But piece them together, and someone who stole your phone for its personal information may have more than you wanted them to have. They could call the pizza delivery service from your phone, and the restaurant may helpfully volunteer your home address from your phone's caller ID (Example: "Do you still live at 1735 Manchester Lane?"). They could call into the pharmacy with your address and get a naive associate to cough up your date of birth. They could then call your bank and maybe social engineer a Social Security number; not everyone can remember theirs, after all, and if they already have the DOB, maybe the SSN isn't a stretch.

In short, individual calendar entires may not have especially sensitive information, but with a year's worth of appointments to play with, a determined adversary can still know quite a bit about my personal life. Besides, it's easier for me to redact a week of data than a year of data. The reason I asked for a date range is because different people have different use cases, and someone else may want a month of data, while another person might want only 3 days or 2 weeks. Or I might want to export events up to 1 week into the future.

So what would be my options if I could mark appointments as private? Well, I could mark every exported appointment older than a week as private, but there are too many appointments and todos in a whole year for that to be practical. I could mark every appointment private, then unmark only the past week so I can export it. But I can also make mistakes and forget to mark certain appointments as private. At the end of the day, what I'm still trying to achieve - having only the newest data - would still take less effort if I filtered by date range rather than a private flag.

Here's an analogy: I use the same approach to emails. I forward all emails from my important inboxes to a different email account that I log into only with my phone. So I can read the emails, but I delete the emails as soon as I finish reading them. If someone happens to get ahold of my phone, they will have only emails that were sent in the past day or so, and I would kill forwarding as soon as I get to another device. The thief would be able to see the address the emails were originally sent to, but because the login information for the main emails aren't stored on the phone, they can't access the main email account either.

Could I set forwarding filters that only forward messages without sensitive information? (This would be the analogue of marking certain appointments in Borg private) Maybe, but it would take a lot more effort to decide which emails are sensitive and which ones aren't, and not all email services allow me to create filters that can discriminate between sensitive and mundane emails. Sometimes, a simpler solution really is best. Just as I don't want to be placed in a position where I have to decide which emails are sensitive enough to not forward and which emails are ok to forward, I wouldn't want to decide for an entire year which appointments are too sensitive and which ones are ok, especially when individual appointments reveal seemingly innocuous information that when pieced with other equally mundane-looking appointments could actually reveal information of some import.

To take another analogy, researchers have recently found that artificial intelligence can predict breast cancer risk better than standard tools, but we don't actually know how AI does it: https://news.yahoo.com/ai-predicts-5-breast-cancer-163234619.html. Because seemingly mundane pieces of information can be combined in obscure or unknowable ways, it would not be possible to protect a patient's privacy just by blacking out specific parts of a CT scan because we don't know which parts of the image were used by the algorithm to arrive at its diagnosis. The entire scan would have to be disassociated from the patient.

Just to be clear, I have no objection to not exporting appointments marked as private, if that's something you planned to do. Marking appointments as private is not mutually exclusive with setting a date range for data export. But marking certain appointments as private or encrypting individual appointments assumes that privacy can be adequately protected by redacting only specific appointments. But as I tried to show above, even mundane appointments can be revealing in sufficient quantity.

For my particular situation, I just don't think flagging individual appointments manually is a replacement for not having older data in the .ics file in the first place. I figured since there was already a feature to only export the past year of data, extending the feature to a custom range (or, as you said, having a single new menu export option with a date range) should not be too much more work.

I have long had suitable mobile third party calendar apps in mind, but I've never felt comfortable exporting an entire year of data from Borg to use them. To this day, the main reason I don't use a calendar on my phone is because Borg is my main calendar and I can't export Borg data by date.

from borg_calendar.