>what stops the state from just asking the domain registrar for the details of who purchased the domains
Some domain registrars don't ask for your personal data and the registrars who ask for it won't verify them.
>then ask the datacenter who owns the server at IP x ...
Many datacenters in China and Russia doesn't care about some warez and if the zlib staff pays over Tor with cryptocurrencies the datacenter also don't know who rents the server
I see enough people in companies and privately using Adobe Acrobat. However, given the quality of the software (from Adobe in general) and all the security holes that have been exploited for Acrobat over the years, I can advise everyone not to use Adobe PDF Acrobat Reader and instead open PDF files in Firefox (pdf.js) or Chrome (pdfium).
A look at the PDF specification is enough to know that it is a hard task to parse such a complex file format without memory bugs: the file is read backwards, which is why the x-ref table is at the end of the file, actually PDF is supposed to be exclusively ASCII... except that every PDF contains binary streams and in addition functions and properties which are defined are ignored even by Adobe Reader.
I wrote some PDF-fuzzers a few years ago and the whole file format is a huge mess..
> can advise everyone not to use Adobe PDF Acrobat Reader and instead open PDF files in Firefox (pdf.js) or Chrome (pdfium).
I agree that Acrobat should be avoided whenever possible but I advise everyone not to use any PDF reader that's found in a browser either because PDF is a minefield and you can expect that the most popular (default) readers will be the most heavily targeted by attackers who will inevitably find security issues. 80% of the time, users are best off downloading PDF files to disk and converting them to text or PNG before opening while resorting to a non-browser/adobe reader for any other cases excepting the ones where you're just forced to use Adobe's software because of some advanced feature.
It won't work for everybody, and it's not as if PDF converters and less common PDF readers are immune from bugs either, but if the vast majority of the time you open a PDF file all you really want is text it can be nice to know your file isn't doing things like making network connections, running JS, playing multimedia or some other bullshit PDF allows for at the same time.
The advantage of pdf.js/pdfium is they are just web pages themselves. To exploit it you need to not only find a PDF exploit but a browser exploit - at which point it'd be many times easier to just serve the browser exploit via a normal page.
Converting PDFs to text or PNG on the machine just means you're now getting rid of the need for that 2nd level exploit by running something natively on the machine.
I see it as the other way around. Now you only need a single PDF exploit to compromise the browser and in bad cases, a single PDF can compromise the entire system.
Could you explain why a PDF exploit would bypass the need for an exploit that bypasses the web sandbox? As mentioned the pdf engines in browsers are not written in native code, I don’t see any way to bypass the need for both a pdf exploit AND a browser sandbox exploit.
that's nice except that I periodically receive PDFs created by other companies, or even gov. orgs, which I find I am unable to fill out and/or sign using anything other than Acrobat on Windows :/
When I was doing my military service (about 5 years ago) an officer handed me a USB stick. I was supposed to digitize a few printed tables in Excel and save them to the stick. When I plugged it in, the antivirus, which hadn't been updated for years, immediately popped up. Conficker was found. The officer simply said, "Ignore it. Just click the window away."
I had to smile, because I knew that USB sticks are a typical spreading method of Conficker.
If every job of IT-Security is obsolete (including exploit dev, reverse engineering, pentesting) I would prefer a job in drug discovery preferably as a bioinformatician. I can't believe AI is able to find cures against every kind of cancer (even if I wish).
There's a lot of CVE submissions lately that seem badly sourced and derived from 'disagreements' at best.
Another recent example is https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2405... which is for a purely theoretical exploit - not even a PoC - with the only 'sources' being Reddit/Twitter scaremongering, and 'support forum posts' that quote these exact same Twitter threads.
Unsafe defaults like "we run all plugins, unless someone goes through all the right motions of closing that door in all the right ...config.xml, ...config.enforced.xml" (and who knows what others) is just terrible. Terrible for any software, and worse for a piece of software that has no purpose at all besides security. What if there's a typo in your lockdown incantations? Not locked down.
That CVE isn't just a disagreement, it's a warning. Avoid security related software from people who enjoy keeping a security edge over the unwashed masses who aren't in the know, who don't get a kick out of locking down. Because that's why they keep the unsafe defaults, they keep them because they enjoy going the extra mile for their own safety. That is, unless they (also) have worse reasons for keeping unsafe defaults, but, well, Hanlon to the rescue.
Convenience and tradeoffs are inevitable. KP is meant for regular users with moderate risk tolerance and profile. Without plugins KP is much less useful. If the alternative is no password manager or trusting a SAAS then it may be worthwhile.
That's answered in the SourceForge discussions linked from the CVE: if you assume the password manager to be only as secure as the user's configuration files, why don't you just skip the hassle and put your passwords in a csv?
A .csv file on an encrypted hard drive, in a single user system or with proper user permissions arguably does provide 90% of the security benefit of KeePass.
But:
1. Ease of use is a security concern - if it's a pain in the ass to use a security measure, users won't.
2. There's also attacks that for whatever reason aren't able to achieve persistence, but are able to obtain files. Let's imagine a browser or scp or rsync or whatever exploit that tricks it into uploading unintended files. These cases will be blocked by KeePass but not by your .csv
3. Users want to sync their password database via untrusted means (e.g. cloud providers). This is easier when the database is itself encrypted. (This attack targets the application config, not the database config, which is a strange choice to sync).
an argument could be made that it's more likely for the password manager file to end up in a malicious actor's hand (in which case an unencrypted csv would be worse), than it is for a malicious actor to get access to your local filesystem.
Has the configuration the same permissions as the exe? IIRC, binaries under windows are often saved with different permissions than the user-profile.
Similar, a virus-scanner will look intensively at exe-files and access to keyboard-input, but not so much at some random configuration, which is supposed to change all the time anyway.
>I ran a tor webserver for discussing geopolitics with friends on a pi for a few months before finding it had been compromised.
Not the fault of Tor. HSDir nodes could snoop on announced v1 .onion adresses. This isn't the case anymore for Onion v2 addresses.
But even if an attacker has the onion address of your webserver, he needs a way to compromise it.
Either through a vuln in your website or your webserver.
I've found the clearnet IP of some darknet markets by typing their <title> into the text input at search.censys.io. That's such poor opsec that I have to assume I identified a phishing proxy to the market rather than the actual origin server of the market itself.
It is really hard to believe that a malicious actor is throwing expensive tor 0-days at random onions.. or your website to "discuss geopolitics with friends" was a bit greater.
In both cases you could run a honeypot to catch 0-days.
the webserver was a simple nanohttp hackup on the oracle jvm, so Ill take some convincing java has an rce in its network stack, and they disguised it by spawning a process on the tor user after hacking the OS and covering that up sufficiently to leave no other evidence.
The only reason I spotted it was because I was checking for compromise by comparing any file/process changes every few weeks.
It was a few years ago, my guess back then was tor is the honeypot, given what happened recently with encrochat I wouldnt be surprised if a few years down the line it turns out it was.
Or maybe I misconfigured the server, or maybe the binary I used for tor was compromised, it was as much a test for whether I could trust tor as anything else and it failed. delete, move on.
>So if there was anything I was considering doing where if it became public I would be hurt, I wouldn't do it.
Sounds like a pretty boring life and you will miss pretty much chances in life and also would be a nightmare for every buddy who has a premium account on fetlife.
Privacy is hard to gain these days, but it's possible. Some private data is safed on small book, which is hidden under my floor and some on an older laptop with Qubes installed and internet is only accessed over Whonix VMs. (Depends on the threat scenario)
>I might as well take advantage of it by making things public on my own.
This is a great way to make yourself an easy target. There's a difference if big tech & three-letter agencies have access to your private data and being totally exposed on the internet for every identity thief and Kiwifarms-Stalker. You should share as less data as possible or create as much fake data as possible about yourself. Fake shedule, fake pictures with fake exif-data, fake friends, etc.
>location based restraining orders can be automatically checked (automatically alert the police if this person comes within X distance of this other person) then keeping locations secret may become unimportant
Except the stalker is smart enough to follow you outside a big city (or wearing a mask) where no cams are placed and doesn't use a tracking device like a Smartphone. Also a data leak of the position data will happen. Stalkers will use these data to track their victims even better.
>parents that worry that the foolish things their middle schoolers write on the internet might come back to haunt them. Right now, their concerns may be correct. Longer term, our society has some adjusting to do to a world where more information is public
No, there will be always more boring people than you, who do nothing of that. These people will be the fools who get hired in future and you have become more boring like them to compete on the job market. This means no porn, drugs and politically-incorrect jokes with to your friends and family.
I would rather be dead than live in a world where the most boring people judge the most intimate moments of my life.
