At the bottom of the page there's a link to the pdfresurrect package, whose description says
"The PDF format allows for previous changes to be retained in a revised version of the document, thereby keeping a running history of revisions to the document.
This tool extracts all previous revisions while also producing a summary of changes between revisions."
> I don't think that in iran there would still be any available ipv4 entry nodes that they would allow. They would filter/block it as well?
That's what bridges are for.
Blocking is a cat and mouse game. It depends how heavy handed they are about it, but unless they totally cut off the external internet, its unlikely tor is 100% blocked, although it might be effectively blocked for most people.
Right, I should have written "IPv4 bridges" (which can be obfuscated and distributed out of band), not "IPv4 entry nodes": https://bridges.torproject.org/
But you can reach the IPv6 internet through those too.
What happens if you declare that you don't have any social media accounts?
There are already forms that ask for social media info, e.g. student visa applications. Surely some of the applicants just don't have any social media profiles. Maybe some of them are reading this. I'm curious about their experiences.
Then they'll do a quick lookup to confirm if you actually don't have any accounts, and if they find any, they'll reject you because you lied. US agencies already are keeping track of what individuals have what online accounts, so they're asking to confirm, not to learn.
If you truly don't have social media, their search won't show any hits, and there isn't much you can do about it. Just make sure you're actually answering the question truthfully.
Literally all data coming in/out of the US (lots of it, even between other countries sometimes routes in-between US network transit points) is kept, and considering the possibilities that just private companies have today by dealing with data brokers and others offering "social media protection" (or whatever they call it today), it's hard to even imagine what the government and its agencies can do.
Did we really forgot about what happened back in 2013 so quickly? Did people assume all these agencies suddenly stopped doing what they've been doing for decades? Nothing you do on the internet with regular network connections are hidden to these entities, don't live falsely under the impression that you can.
No part of hosting or visiting onion services involves exit nodes. Onion service traffic stays within the Tor network instead of exiting to the clearnet.
>In October 2025, data stolen from the Salesforce....
Seems like a salesforce leak. Not to single out sales force here. Could easily be fill in the ____ big corp. When are people going to get there is no absolute digital security. And at currently state, it is much more secure to NOT have all the data aggregated in one place. Of course this would go against the data mining operation. We should look at this from a perspective that benefits the user in the long term.
Server/relay should be very thin layer NOT storing any identifiable info about the user except for public keys. All other info should be stored locally where ONLY the user has access to them.
I don't think Salesforce itself was hacked. It says "data stolen from the Salesforce instances of multiple companies".
HIBP links to [1], which links to [2], which says
>The FBI last week warned airlines in the US that the group was targeting the aviation sector. In a post on X, the FBI said the group uses social engineering techniques, often impersonating employees or contractors to deceive IT help desks into granting access, and bypassing multi-factor authentication.
So it sounds like phishing attacks against the individual airlines. It sounds pretty much the same as [3], which goes into detail of the exact mechanism that phishers can use to steal Salesforce data. It does sound like it is a little bit Salesforce's fault, because Salesforce's UI makes it really easy to grant an attacker access to your database without realizing it. Salesforce needs to improve the permission granting UI so that it's clearer what is going on.
There are lots of Saleforce customers getting hacked. [1]
> Insurance giant Allianz Life, Google, fashion conglomerate Kering, the airline Qantas, carmaking giant Stellantis, credit bureau TransUnion, and the employee management platform Workday, among several others, have confirmed their data was stolen in these mass hacks.
Perhaps it's bad security defaults which are in some sense user error, but when it becomes common pattern then I think the company needs to make systematic fixes.
Compare with many Snowflake customers getting hacked.
"No tags were pushed to AOSP for the July 2025 monthly release of Android. We asked about this on the android-building group but each of our posts was rejected. We emailed people at Google we've previously contacted about mistakes pushing tags but received no response this time."
That's about the monthly and quarterly releases of Android, not the Android security patches. The post title is misinterpreting what's wrong. There is a lot wrong but that's not it. The baseline Android security patches are being delayed for Android as a whole, not AOSP specifically.
Not having the very tiny monthly updates pushed to AOSP is an annoyance which will delay a subset of non-security bug fixes until the quarterly releases. It's a bad change, although we know have a good idea why it happened and need the reason it happened to be reversed for them to push those again.
We've been told by multiple people at Google that the quarterly releases would still be pushed and that monthly releases are largely being phased out. However, the quarterly update was not pushed as expected on September 3rd. If it's pushed on Monday, it will be 6 days late. There hasn't been a similar delay for quarterly and yearly releases in the past.
GrapheneOS can still provide security updates but not having the quarterly release is a major problem and it's not clear why it wasn't pushed when they said it was going to be pushed.
There's a separate issue not specifically tied to AOSP impacting security patches which is what the initial part of our reply was about. See https://x.com/GrapheneOS/status/1964754118653952027 for an explanation.
Serious question: do we know as a matter of fact that iOS and family are safer than Android, including Pixel, especially when it comes to 0-day exploits?
No, but Google has significantly downgraded security from it used to be and Apple isn't sharing security patches very broadly outside their company 4 months ahead of fixing them. They don't have partners to share it with. That's not to say there aren't people in the company leaking them but they likely don't take that long to fix most patches. We considered the Pixel stock OS largely competitive with iOS on security but recent changes including but not limited to this are changing our mind. Both the Linux kernel and Google with Android are doing a horrific job with security. Apple has their own issues but it's not this embarrassingly bad and getting consistently better. Google could easily provide strong security for Pixels and AOSP but is downgrading them to appease OEMs failing to keep up with the previous already bare minimum patch system they were expected to follow.
An issue reported to Google 3 months ago and fixed today would likely get disclosed to partners around November 2025 or December 2025 and then officially fixed in March 2025. It's not just 1 month of early access for OEM partners now but rather around 4 months. Patches are artificially delayed beyond the time to fix them by 4 months. This is completely ridiculous. Google also doesn't control the patch releases for many projects such as the Linux kernel and many other external projects they use. This means they're always going to be at least around 4 months behind on including a small number of patches for those projects as mandatory to fix for Android OEMs. The bar for Android OEMs was already ridiculously low and they've made it far lower. It's dragging down the Pixel stock OS with it to a significant extent.
Google realizes this system is horrible and has therefore added a binary-only exception to the embargo which is a complete joke since they know it's easy to reverse the patches. However, it's not really being used in practice. It's just an option to ship binary-only patches without the long delay now. We have this option for GrapheneOS since we do have access to the partner bulletins via an OEM partner. We could also ask our OEM partner not to share them with us and instead obtain them another way with no NDA to publish them right away. We haven't asked for the December patches yet since we haven't decided how to handle it. The current embargo would allow us to publish a special delayed source release variant of GrapheneOS this month with December 2025 patches, but we want to provide source code for all our releases and do not want to have a special variant of the OS needed for the latest Android patches. With how broadly they've distributed the December 2025 patches, they can't seriously be considered private and it should be permitted to simply ship them now.
Android's partner licensing people are destroying the security work. Play Integrity API is similar pretend security actually just enforcing Google's partner licensing model while actually disallowing using much more secure devices. That's highly anti-competitive and so is what they're doing with security patches. Both should result in substantial regulatory action against them, and perhaps it will, but it will probably come a very long time from now when the damage is done.
> Both should result in substantial regulatory action against them, and perhaps it will, but it will probably come a very long time from now when the damage is done.
Instead of focusing on ChatControl, the EU should look into that...
The section Benefits (after Introduction) lists 9 reasons why it makes sense. Some of them are about working around a mismatch with existing standards, but not all.
"The PDF format allows for previous changes to be retained in a revised version of the document, thereby keeping a running history of revisions to the document.
This tool extracts all previous revisions while also producing a summary of changes between revisions."