• 0 Posts
  • 67 Comments
Joined 3 years ago
cake
Cake day: July 11th, 2023

help-circle






  • they started out as openstreetcam. they turned out to be not open, in source code and licensing of uploaded content. their app couldn’t even be open source, as it used closed source components (including facebook data mining components), that they did not want to remove. they have got renamed to kartaview and belong to a crappy company. they also don’t value user privacy, shown partly by using facebook (among other) tracking code both on the website and in the app.


    at first, they turned out they don’t value privacy of its users, but with an openstreetmap adjacent project that is essential. most OSM editors and users are here partly for the privacy properties of the services and accompanying apps, and like that we can’t honestly recommend something to others that we ourselves wouldn’t use.

    openstreetcam privacy policy said they share user data with third parties for analysis of the users. that alone shows how they treat their users, but their website contained facebook tracking technology among others, which is significantly worse for reasons I will not detail here.

    in the openstreetmap ecosystem another thing that is important is openness and free software. because that’s how you can know how is your data handled, or how you can continue development if the original devs abandoned the project. all significant android osm apps are available on the F-droid store. F-droid vets all apps it accepts, including all updates to them, and closed source components are not allowed in any of them, because what they do can not be audited.
    openstreetcam (at some point renamed to kartaview) was not willing to remove the unauditable components for f-droid inclusion. it was more important for them to collect enormous amounts of user data for facebook and other data brokers.

    then the open source app completely stopped being open source. they did not officially stopped development, they just started to forget uploading the source code changes. they even tried to argue other points with “but our app is open source!” when it could not be built from source for several years already. that shows they only used open as a marketing term.

    later it turned out the app was owned by a crappy company, and that they take all rights, irrevocable, for all images uploaded.

    probably other things also happened I don’t remember now.





  • They got access but connecting to another database:

    We did not have pgcrypto installed in the peertube database, but I overlooked that someone could connect to the main postgres database if they say had a nodejs plugin running.

    how? did they use the same database user account for all databases? unless I misunderstood it, peertube’s database user shouldn’t be able to operate in other databases of the same server.

    VLAN’s suck. They allow for traffic to travel within each VLAN them, unmonitored and unrestricted. Sometimes red teamers call that “hard outside, soft inside, like an eggshell”.

    nonsense. if you don’t use VLANs, you are essentially using a single huge VLAN. of course using VLANs don’t exclude monitoring and firewall restrictions. could as well say, networking sucks, lets disconnect everything. if you don’t set up monitoring, and you don’t set up restrictions, then yeah, there will be no monitoring and no restrictions, like on any network.

    Better, is a private VLAN. Private VLAN’s enable the firewall to monitor or block all traffic within them.

    didn’t you just say VLANs wholesale suck?

    also, peertube will require access to the internet…

    You just block everything within itself from communicating with eachother,

    only if it was so simple. you can set up routing restrictions between subnets on the IP level, but the switch will gladly forward all traffic anywhere inside of the VLAN, according to the destination MAC address. with that, a compromised system can confuse every other on the VLAN with ARP poisoning and faking DHCP servers.

    In all seriousness, you should be able to migrate them into the same database by dumping the database with pg_dump or a similar utility, and then loading them up using pg_restore. Other databases have equivalent tools. I used the Dbeaver open source database GUI to do this a few days ago.

    yeah, that’s the easier part. but one of the databases is mysql, which I want to get rid of completely. and conversion is nontrivial. probably dbveaver could handle it though.


  • If a user can’t log in to a DBMS, they don’t have query permission.

    weren’t they having access through peertube? you can’t revoke access to something that needs it.

    sure, they could run dedicated postgreses for each service, but I think this kind of bug is so rare that it is not worth wasting lots of RAM on that, and even then, it would rather just deter people from hosting services they want.
    also at that point, the question arises why not just run everything in qubes OS, each service in its own VM and its own VLAN. and the response is that it is unfeasible, and it was unfeasible even before the RAM shortage, unless you have enterprise hardware with 100+ GB RAM, consuming way too much power compared to a server made from desktop PC hardware, even when there is no meaningful CPU load.

    But it’s not that much more, and you can make it fit easily.

    I run 3 separate database servers on the same OS because I made a bad decision at one point, and I regret it. I just don’t have time to merge them.


  • Use a separate DBMS (that is, a separate postgres/mariasql/etc container) for each service. Give each one service unique passwords, which you can define in the docker compose.

    unique passwords is good practice, but separate db server for each of the services is extreme. it brings much more resource consumption. the solution here is being subscribed to security releases and updating soon. those application kernels also sound like a good idea. and as I understand, postgres permissions were not at fault, the permission system had a bug.

    Even if one application that connects to a database gets owned, it doesn’t have access to other postgres databases, preventing data leaks/exfiltration.

    except that because of the bug, anyone with query permission could have become postgres superuser.


  • I would like to click on a peertube link and for it to create a user on the peertube system using any relevant customizations from my parent user

    unauthorized exfiltration of your user data, including all settings, your email address and possibly your subscriptions.
    but probably this could be solved with some agreement dialog.

    and if I modify options on peertube I wish it would save that to my piefed user somewhere

    intransparent and unauthorized modification of arbitrary settings in the origin user