I just tested it on my instance. You can create a public share by setting the mode to "Write", which is accessible without logging in as a user (but with optional password).
It works, but one does not see any files, not even the ones you uploaded yourself. So for example if you updated the file and need to re-upload it, there is no way for you to delete the previous one.
You can also create a shared "virtual folder" that is seen by multiple users, and then you have fine grained control on a user basis (Users > burgermenu > edit > ACLs > Per directory permissions) there you can mix and match from a list of ~15 permissions. To upload anything to that virtual folder, you'll have to properly log in as a user.
AAAAH sorry I misunderstood your point before. I thought users should not see files prior to their joining of that folder, but see files that come in after their joining.
But you mean, users should only see files they upload, while an admin or so sees all files.
I don't know the details, but from just trying out both jShelter worked better for me.
When a website didn't work, I know to toggle the toggles one by one until it works. With chameleon, I have tried clicking around through it's 7 tabs and 20 options, but failed to make the websites work. It also wasn't clear what it does with the useragent and such, as creepjs was still able to detect everything.
So yeah, I recommend to try creepjs with either one and see what changes. Then you know which the better one is for privacy. And if it's neither, then you know that js is really fucking creepy, because it can use a lot of tricky ways to figure out stuff about your browser and os. The only way is to fully block js.
They claimed there will be no CSAM because of the given reasons.
I wanted to highlight that those reasons do not actually prevent it.
My tone might be harsh (the sarcasm at the end definitely is) because I see this as a marketing push for their crypto platform. "marketing" - as in they will be making money from users, so it is in their interest to tell lies or ignorant half-truths, to make more users come over.
Any normal platform tackles this problem with proper moderation. Platforms that make money, often hire moderators.
I guess my question should be how they managed to do this without having to create an account and profile users
cookies
If it's a cookie, the history should not be there if you clear your cookies or open it in a private tab.
The whole chat could be stored "in the browser" but more likely they have it on their server and associate it to you via the cookie. *edit: I guess it is this then according to what afk posted.
If it is not a cookie, there is also your IP and lots of alternative fingerprinting ways of uniquely identifying your browser (see creepjs ). You could use a VPN and disable js in your browser, but that breaks half the internet nowadays.
the protocol is text only, to embed media, you need to host it on the regular ( Centralized ) internet
except we already figured out how to encode images (or any file) as text when E-Mail was created. That is how images in E-Mails, attachment or embedded, are done. I can easily imagine a userJS script that will render them in the browser, but even if not you just copy the text and decode.
if a community is badly moderated, the user will never see it, it wont be recommended to him. the user can visit bad communities directly just like you can visit a bad website directly, but it’s not recommended to you so it’s safe to use.
Ah... so you're guaranteed to have a dark CSAM subculture on there at some point.
being p2p, seedit is not private, so it can’t really be used for illegal activity
As if that has ever stopped anybody. See all the people that got caught for sharing it on the clearnet. Or on Signal, Telegram or similar, where you have to enter your phone number, which is personally tied to you.
All in all - Great way to adress the concerns, by admitting they are in fact possible. "Hurray crypto" or whatever.
I'm using a selfhosted forgejo but in case something goes wrong with that, everything is also mirrored to sr.ht (which has a shit GUI if you are liking github/lab).
you can read the HTML like structures inside a PDF and then find out details about the elements you want to remove and then remove them by using that found common property.
and open it with a text editor like kate. You will see a lot of encoded content data, but also the "html-like" structure in plaintext (in between the encoded stuff but also more at the bottom)
You might find that editing the PDF by hand will break it completely, that is because it is complicated. Iirc you'd need to fix the index, recalculate the checksum or do some other magic bullshit. But that is often taken care of by the library.
Here is a shitty python example for that demo pdf that redacts the image at the last page by drawing a white rectangle over it. There is no way in pymupdf to delete an image or a textblock ... but this is just an example. Other libraries might be able to do it (the one I used a decade ago in java could). I just wanted to point you in the general direction, hope you can see from here how iterating over all the pages, picking the right element and redacting it would work.
python
import pymupdf # PyMuPDF
# Open the PDF
doc = pymupdf.open("./file-sample_150kB.pdf")
# Get the last page
page = doc[-1]
# Get all images on the page
images = page.get_images(full=True)
if images:
# Get the xref of the first image
xref = images[0][0]
# Find all instances of the image and redact their bounding boxes
for info in page.get_image_info(xrefs=True):
if info["xref"] == xref:
rect = pymupdf.Rect(info["bbox"])
page.add_redact_annot(rect, fill=(1, 1, 1)) # white fill
page.apply_redactions()
# Save the modified PDF
doc.save("./modified.pdf")
doc.close()
A way simpler approach might be to crop all pages at the bottom.
import pymupdf # PyMuPDF
doc = pymupdf.open("input.pdf") # open the PDF
for page in doc:
rect = page.rect # original page size
new_rect = pymupdf.Rect(rect.x0, rect.y0 + 100, rect.x1, rect.y1) # crop bottom 100px
page.set_cropbox(new_rect)
doc.save("output.pdf") # save the cropped PDF
doc.close()
There has been a fork recently (by a controversial figure tbh) but you can probably go use that with a DE that has it as the default, then you won't get pushed into anything.
A PDF is (or at least can be) similar to a HTML document on the inside. A long time ago we used that at my company to edit PDFs through java code.
Is it possible for you to share the document so we can take a closer look at it? Or if you don't want it on the internet, is there a way to share it privately?
There have been manual interventions required for a lot of things.
Why did you not see conspiracy theories when they broke something java related for example?
Because thats how it works with arch, shit can not be resolved nicely when everything changes all the time, so you have to do an intervention and they tell you what to do and you just do it and then it just works. So stop being a delusional nut, nobody cares about you using whichever package.
privacy - in my opinion that depends more on your behaviour and the installed extensions than the browser.
functionality - a little bit, but of course that matters only if you need any of the listed features (see link). The big one is the additional extensions/plugins that you can install.
idk about you (and how many 800x600 games you have), but I have to edit the run command for a quarter of my games anyway, since they don't interpret my setup correctly and look like shit or are simply unplayable. So I copy paste my default gamescope command and viola, chefs kiss, everything works.
I think fullscreen worked differently on xorg vs wayland. I am on plasma 6 on a rolling distro and I like wayland a lot, especially when mixing monitor sizes and resolutions.
Sorry, I am just gonne dump you some links from my bookmarks that were related and interesting to read, cause I am traveling and have to get up in a minute, but I've been interested in this topic for a while. All of the links discuss at least some usecases. For some reason microsoft is really into tiny models and made big breakthroughs there.
I just tested it on my instance. You can create a public share by setting the mode to "Write", which is accessible without logging in as a user (but with optional password).
It works, but one does not see any files, not even the ones you uploaded yourself. So for example if you updated the file and need to re-upload it, there is no way for you to delete the previous one.
You can also create a shared "virtual folder" that is seen by multiple users, and then you have fine grained control on a user basis (Users > burgermenu > edit > ACLs > Per directory permissions) there you can mix and match from a list of ~15 permissions. To upload anything to that virtual folder, you'll have to properly log in as a user.
Hope either one of the ways works for you. Cheers