Keyoxide proof: $argon2id$v=19$m=64,t=512,p=2$GqANIZlip4069AD6refZlQ$ih86piuoJJDrbRmKV9dhzA

  • 4 Posts
  • 24 Comments
Joined 1 year ago
cake
Cake day: August 17th, 2023

help-circle






  • Pin codes are great for quick access if you have a lockout mechanism after 3 failed attempts and it is impossible for an attacker to get the hashed code. It is only secure if you pick a pin that cannot be guessed in 3 attempts like your birthdate but that applies to any password.

    Thats why they are used for credit cards, SIM cards or Bitlocker drive encryption. The hashed code never leaves the secure hardware so you cannot circumvent the lockout.

    Even a 16digit numeric code, which I guess is the upper limit of what you can remember and quickly input, would take just a couple of days to brute force if the attacker does get hold of the hash.



  • Spotify does not have the power to lock your credit card or paypal account. Account bans might happen and I have seen E-Mail screenshots of people who got banned. I am not sure if they would take down an entire set of family accounts.

    If you care about the content of your Spotify account (playlists, listening history) you should not use it for piracy. Just create a new one. If you are fine with 160kbps OGG files, you dont even need a paid account.

    Do not create Spotify accounts with trash mail addresses, they may work at first and get banned the next day (happened to me after I created some accounts for scraping their API).

    You can also export all your Spotify data as a precaution (GDPR export from the account page, they send you an email with a link to a zip file after a couple of days).









  • RSS feeds are XML files which contain a list of documents hosted on the internet (articles, audio/video). The feed entries contain basic metadata (title, date, author, summary) and a link to the original website (or audio/video file in the case of a podcast).

    Feed readers send a simple web request to the website hosting the feed, downloading it if it has changed since the last update. The content is then combined with other feeds and displayed. This way you can have a personalized news reading experience without needing to create an account at a a central provider or open every individual site.

    Alternative YouTube clients use RSS feeds provided by YouTube (example: https://www.youtube.com/feeds/videos.xml?channel_id=UC2DjFE7Xf11URZqWBigcVOQ), but they are only used to update subscriptions. All other requests (search, watching videos) are handled by the same web interface as the YouTube desktop application. Fetching the RSS feeds is a lot faster than opening the channel page, so the RSS featuee allows you update 100 or more channels in a few seconds.

    The way podcast ads work is either just like YouTube sponsorships (the podcaster gets paid by a company to speak an advertisement themselves) or they are dynamically inserted by the podcast provider (these are the interrupting ads). Since most podcast apps dont store cookies, there is no way to track users and personalization is done only via the IP-based location and topic of the podcast. RSS-based podcast players have no way of directly reporting back playback telemetry. The server hosting the podcasts can only count the number of downloads/playbacks. So there is no way to count the amount of watched ads when using a RSS-based podcast player like AntennaPod or Kasts. Note: this does not apply to podcasts on Spotify, Apple Music or similar platforms. These platforms absolutely track your listening activity. I have no idea whether this affects ad/sponsorship earnings.


  • One important thing if you are building a RSS application is that the server should support conditional requests (the If-Modified-Since header). This way, a client does not have to download the entire feed on every update. It simply sends the last update date with its request and the server returns an empty response if the feed is up to date.

    There are some applications (for example YouTube) which dont support this, resulting in higher-than-necessery data usage, especially on mobile.






  • Web applications may have vulnerabilities that allow an attacker to run code on the host system (Remote Code Execution). Famous example would be the log4shell vulnerability.

    If you want to expose your server to the internet, you have to make sure you are not suffering damage if an attack like this occurs.

    1. Give the server application minimum privileges on your system. Use either containerization, sandboxing or systemd hardening to prevent the app from running commands on your system or access important data. Jellyfin for example only needs to read your media library, so if you are using docker, mount it read-only.
    2. Keep both the reverse proxy and the application up-to-date. For a docker setup you can use watchtower.
    3. Make backups of both your media collection and the Jellyfin database in case you need to restore your system. You should also have a script or at least some written notes on how you set up everything.
    4. Ideally isolate the media server from the rest of your network. If someone manages to put malware on your server, they should not be able to access the rest of your network (PCs, smart home devices, cameras, etc). This requires a more advanced firewall than most consumer routers have, so I currently do not do it on my home setup.