All of this user’s content is licensed under CC BY 4.0.

  • 5 Posts
  • 14 Comments
Joined 1Y ago
cake
Cake day: Oct 20, 2023

help-circle
rss
Can a Unified Push push server see/read notifications?
By "push server" I mean something like [Ntfy.sh](https://ntfy.sh/). --- ::: spoiler Cross-posts - https://sh.itjust.works/post/27577324 :::
fedilink


Not really as those are public things.

Would you mind citing an example of exactly what you are referring to? I feel like I’m presuming a lot of things in your statements here.


Dhcp is more of a issue.

I don’t know if it’s “more”, or “less” of an issue, but all these things are worthy of concern.


That would certainly also be worthy of concern.


have the machine pretend you’re in UTC.

That is a possible solution, though not exactly the most convenient, imo. That is, if I understand you correctly that you are talking about setting the OS timezone to be UTC.


could be defeated by doing an analysis of when the commits were made on average vs other folks from random repositories to find the average time of day and then reversing that information into a time zone

This is the first thing I thought of upon reading the title

It’s also in the post body.


Any given time zone there are going to be millions if not billions of people.

One more bit of identifying information is still one more bit of identifying information.


Git also “leaks” your system username and hostname IIRC by default which might be your real name.

This is only part of a fallback if a username and email is not provided [1].

References
  1. Git. Reference Manual. git-commit. “COMMIT INFORMATION”. Accessed: 2024-08-31T23:30Z. https://git-scm.com/docs/git-commit#_commit_information.

    In case (some of) these environment variables are not set, the information is taken from the configuration items user.name and user.email, or, if not present, the environment variable EMAIL, or, if that is not set, system user name and the hostname used for outgoing mail (taken from /etc/mailname and falling back to the fully qualified hostname when that file does not exist).


A fake name and email would pretty much be sufficient to make any “leaked” time zone information irrelevant.

Perhaps only within the context where one is fine with being completely unidentifiable. But this doesn’t consider the circumstance where a user does want their username to be known, but simply don’t want it to be personally identifiable.


UTC seems like it’s just “HEY LOOK AT ME! I’M TRYING TO HIDE SOMETHING!”

This is a fair argument. Ideally, imo, recording dates for commits would be an optional QoL setting rather than a mandatory one. Better yet, if Git simply recorded UTC by default, this would be much less of an issue overall.


if you sleep like most people, could be defeated by doing an analysis of when the commits were made on average vs other folks from random repositories to find the average time of day and then reversing that information into a time zone.

I mentioned this in my post.


It’s better to be “Jimmy Robinson in Houston Texas” than “John Smith in UTC-0”

That decision is contextually dependent.



Fair point. I think “leak” is likely the wrong term to use here. “Exposes” is probably a better one. I’ll update the post promptly.


PSA: Git exposes timezone metadata
Git records the local timezone when a commit is made [1]. Knowledge of the timezone in which a commit was made could be used as a bit of identifying information to de-anonymize the committer. Setting one's timezone to UTC can help mitigate this issue [2][3] (though, ofc, one must still be wary of time-of-day commit patterns being used to deduce a timezone). ::: spoiler References 1. Git documentation. git-commit. "Date Formats: Git internal format". Accessed: 2024-08-31T07:52Z. https://git-scm.com/docs/git-commit#Documentation/git-commit.txt-Gitinternalformat. > It is `<unix-timestamp> <time-zone-offset>`, where `<unix-timestamp>` is the number of seconds since the UNIX epoch. `<time-zone-offset>` is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is `+0100`. 2. jthill. "How can I ignore committing timezone information in my commit?". Stack Overflow. Published: 2014-05-26T16:57:37Z. (Accessed: 2024-08-31T08:27Z). https://stackoverflow.com/questions/23874208/how-can-i-ignore-committing-timezone-information-in-my-commit#comment36750060_23874208. > to set the timezone for a specific command, say e.g. `TZ=UTC git commit` 3. Oliver. "How can I ignore committing timezone information in my commit?". Stack Overflow. Published: 2022-05-22T08:56:38Z (Accessed: 2024-08-31T08:30Z). https://stackoverflow.com/a/72336094/7934600 > each commit Git stores a author date and a commit date. So you have to omit the timezone for both dates. > > I solved this for my self with the help of the following Git alias: > > ``` > [alias] > co = "!f() { \ > export GIT_AUTHOR_DATE=\"$(date -u +%Y-%m-%dT%H:%M:%S%z)\"; \ > export GIT_COMMITTER_DATE=\"$(date -u +%Y-%m-%dT%H:%M:%S%z)\"; \ > git commit $@; \ > git log -n 1 --pretty=\"Autor: %an <%ae> (%ai)\"; \ > git log -n 1 --pretty=\"Committer: %cn <%ce> (%ci)\"; \ > }; f" ::: --- Cross-posts: - https://sh.itjust.works/post/24495744 - https://sh.itjust.works/post/24495795
fedilink

Ah, right. I forgot that they’re based in Sweden. That’s understandable if it’s simply a lack of familiarity with the language, but, still, I would expect a company like Mullvad to at least have one native-equivalent English speaker to look over their public facing English stuff. None of this is the end of the world, ofc — I’m just mildly surprised.


There are a surprising number of grammatical errors in that blog post. Did anyone proof read it, I wonder?


Nearly 90% of their servers are blocked to do common internet tasks .

Perhaps your browsing habits are severely impacted by Mullvad being blocked, but that doesn’t seem to be the universal case. I’ve had the occasional hiccup with a few sites that block VPNs (Mullvad’s IPs), but “90%” is quite an exaggeration when compared to my personal experience.


Cross-posted from: https://sh.itjust.works/post/19987854 --- > We have previously highlighted the importance of not losing your account number, encouraging it to be written down in a password manager or similar safe location. > > For the sake of convenience account numbers have been visible when users logged into our website. This had led to there being potential concerns where a malicious observer could: > > - Use up all of a user's connections > - Delete a user's devices > > From the 3rd June 2024 you will no longer be able to see your account number after logging into our website. --- - "Hiding account numbers". Mullvad. 2024-05-27. Mullvad Blog (https://mullvad.net/en/blog/2024/5/27/hiding-account-numbers). - [Archive](https://web.archive.org/web/20240528005229/https://mullvad.net/en/blog/2024/5/27/hiding-account-numbers)
fedilink

>Danish banks have implemented significant restrictions on how Danish kroner (DKK) used outside Denmark can be repatriated back into Denmark. > > Due to these circumstances, which are unfortunately beyond Mullvad’s control, Mullvad will no longer be able to accept DKK from its customers. We will continue to credit DKK received until the end of the month, but considering postal delays, it is best to stop sending it immediately. - [Source](https://mullvad.net/en/blog/2024/5/23/regarding-cash-payments-dkk) - [Archive](https://web.archive.org/web/20240523081707/https://mullvad.net/en/blog/2024/5/23/regarding-cash-payments-dkk)
fedilink

For annotating PDFs:

For arranging PDFs:


That’s a rather self-centered statement, imo. Just because you may not be bothered by the idea, does not mean that it does not have merit for others. That line of thinking is in a similar vein to saying “We don’t need freedom of speech because I have nothing to say.”.


It’s all about reducing the surface area for an attack — if you do become compromised, it’s one less thing to have to worry aobut. It would be preferable to not have to worry about your data and someone bribing you with some video footage.


Is it unnecessary to cover one’s webcam on Linux?
Cross-posted to: https://sh.itjust.works/post/15859195 --- From other conversations that I've read through, people usually say "[Yes, because it's easy on Windows](https://www.reddit.com/r/linuxmasterrace/comments/5dthes/comment/da766gt/?utm_source=share&utm_medium=web2x&context=3)", or "[Yes, because they simply don't trust the webcam](https://www.reddit.com/r/linuxmasterrace/comments/8ytkkx/my_webcam_is_safe/)". But neither of these arguments are enough for me. The former I feel is irrelevent when one is talking about Linux, and the latter is just doing something for the sake of doing it which is not exactly a rational argument. Specifically for Linux (although, I suppose this partially also depends on the distro, and, of course, vulnerabilites in whatever software that you might be using), how vulnerable is the device to having its webcam exploited? If you trust the software that you have running on your computer, and you utilize firewalls (application layer, network layer, etc.), you should be resistant to such types of exploits, no? A parallel question would also be: How vulnerable is a Linux device if you *don't* take extra precautions like firewalls. If this is the case, what makes Windows so much more vulnerable?
fedilink