• 2 Posts
  • 104 Comments
Joined 2Y ago
cake
Cake day: Jun 16, 2023

help-circle
rss

The nixCraft headline is stupid, just because you are running on IPv6 without any NAT doesn’t mean your router doesn’t block incoming IPv6 traffic to hosts on the network - this is actually the default in 99.9999% of devices.


You should not trust those builds. Everything you need to know is documented here: https://learn.microsoft.com/en-us/windows/privacy/manage-connections-from-windows-operating-system-components-to-microsoft-services

Windows 10/11 Enterprise is recommended as that’s the version where Microsoft can’t fuck up.


No, that’s a myth. Registry edits may revert in some cases yes, but group policy is different as it designed exactly to configure machines in a stable way.


Group policy may be beyond the general skill level, which makes the constant Linux suggestions even more laughable.

Ahaha yeah, I’ve said that SO MANY times. People have issues setting a few toggles on a point-and-click UI but then it is okay to suddenly move to a entirely different OS that most likely won’t have the software they’re used to and requires terminal skills to deal with most things. Laughable indeed.


Completely bullshit, garbage clickbait title.

Windows 10 is near EoL, however that’s for Home/Pro/Enterprise versions, you can move to one of those for more time:

  • Windows 10 Enterprise LTSC - 2027
  • Windows 10 IoT Enterprise LTSC - 2032

To be fair I don’t really believe that Microsoft will kill it when they say they will. And even if they do it, porting security updates from those LTSC versions into the regular ones might be doable.

Now on Windows 11:

You can just disable copilot and all the other garbage using group policy, now that hard and you’ll end up with essentially Windows 10. https://www.xda-developers.com/how-disable-microsoft-copilot/


At least he is honest about who he / the platform supports, not some shady algorithm pending to one side, or some tv channel being left while another is right lol


No shit, but then even Obama used Twitter to win the elections. What’s new?


tax payer subsidies

It’s not subsidies, it is tax breaks if companies go there. A very different thing.


So what, people need cloud services and Netherlands did the same and became one of the top spot for datacenters in Europe and nobody is bitching around.




Here’s typical Mozilla not being the all mighty savior people think of them.


I’ll have to test it. Better to have one less extension.


Interesting… I wasn’t aware of ClearURLs for uBo. How good is that? Does it really filer all tracking elements like clear URLs does?


Innovation and privacy go hand in hand here at Mozilla

As well as profits and corporate interests.

People speak very good thing about Firefox but they like to hide and avoid the shady stuff. Let me give you the un-cesored version of what Firefox really is. Firefox is better than most, no double there, but at the same time they do have some shady finances and they also do stuff like adding unique IDs to each installation.

Firefox does is a LOT of calling home. Just fire Wireshark alongside it and see how much calling home and even calling 3rd parties it does. From basic ocsp requests to calling Firefox servers and a 3rd party company that does analytics they do it all, even after disabling most stuff in Settings and config like the OP did.

I know other browsers do it as well, except for Ungoogled and because of that I’m sticking with it. I would like to avoid programs that need no snitch whenever I open them. ungoogled-chromium + ublock origin + decentraleyes + clearurls and a few others.

Now you’re free to go ahead and downvote this post as much as you would like. I’m sorry for the trouble and mental break down I may have caused by the sudden realization that Firefox isn’t as good and private after all.



“This is an isolated, ‘one-of-a-kind occurrence’ that has never before occurred with any of Google Cloud’s clients globally. This should not have happened.

I don’t believe this is what that rare, what I believe is that this was the fist time it happened to a company with enough exposure to actually have in impact and reach the media.

Either way Google’s image won’t ever recover from this and they just lost what small credibility they had on the cloud space and won’t be even considered again by any institution in the financial market - you know the people with the big money - and there’s no coming back from this.



Excellent explanation, however, technically it does not constitute an “odd spot.” Rather, it represents a “100% acceptable and evident position” as it brings benefits to all stakeholders, from accounting to the CEO. Moreover, it is noteworthy that investing in services or leasing arrangements increases expenditure, resulting in reduced tax liabilities due to lower reported profits. Compounding this, the prevailing high turnover rate among CEOs diminishes incentives for making significant long-term investments.

In certain instances, there is also plain corruption. This occurs when a supplier offering services such as computer and server leasing or software, as well as company car rentals, is owned by a friend or family member of a C-level executive.


Also that’s besides the point. I’m trying to learn if the developer said they’d publish on the App Store, not the AltStore.

From what I see his fediverse accounts it doesn’t seem like it… there are multiple people asking him to publish on the App Store and he seems to be conveniently ignoring all of them.


That’s besides the point here. Riley Testut is bitching when he should’ve been the first to submit and have his own app approved.


Read his post again: “Delta has been **APPROVED for distribution with @altstore **”. There’s no App Store here.

I believe you may have missed that apps distributed using alternative stores still need to be summited and approved by Apple.


Yes, and why isn’t he publishing Delta to the App Store then? He’s clearly leveraging Delta to popularize his AltStore. I’m using “greedy” in a sense that he wants to gain something (that may or may not be monetary) by leaving Delta to be an AltStore exclusive.


GBA4iOS was never on the App Store, was it?

No, and it will never be because Riley Testut seem to be as greedy as Apple.

Look he was right, but he’s kind of bitching, he can just release GBA4iOS on the App Store and people will use it instead of that crap filled with ads. What if he just had summited GBA4iOS to the App Store before this developer? Oh I know why, because he’s trying to get his AltStore approved and wanted to have GBA4iOS exclusively there to drive people into it.


The original emulator is still up.

What are you talking about? GBA4iOS is NOT in the app store.


One key aspect that you seem to be missing is that Proton encrypts every mail, including those sent by or sent to unencrypted providers using your pgp key before storing them on the server. This isn’t a case scenario that can be handled without using a bridge

Yes it can, and I explained how. Maybe you’re the one not understanding how Proton actually encrypts emails sent by unencrypted providers/people…

In asymmetric cryptography the public key is used for encryption, then the related private key is used for decryption. This means the server just has to know your public key to be able to safely store incoming email from unencrypted providers. The Thunderbird that has your private key can decrypt the e-mails later on. This is exactly what Proton does but the decryption part is handled by the bridge.

There’s guide here explaining this in detail and providing an implementation example with Dovecot. This can be also done when a message is received by the MTA (before it is filed / stored by Dovecot) like discribed in this guide for Exim here. The process should be the same for Postfix.


The bridge does the decryption using credentials you give it locally.

Are you reading what I’m typing? I just described the full process they do on their apps and what can be done over IMAP to give you the same level of protection that Proton offers.

Besides, Proton doesn’t even provide zero access. In Proton there’s a bunch of data like e-mail headers that is NOT encrypted at all and they say it:

subject lines in Proton Mail are not end-to-end encrypted, which means if served with a valid Swiss court order, we do have the ability to turn over the subjects of your messages. Your message content and attachments are end-to-end encrypted. Source https://proton.me/support/does-protonmail-encrypt-email-subjects and https://proton.me/support/proton-mail-encryption-explained

Any generic IMAP/SMPT provider + Thunderbird with PGP provides the same level of security that Proton provides, assuming they didn’t mess their client-side encryption/decryption/key storage in some way. PGP is making sure all your e-mail content is encrypted and that’s it, doesn’t matter if it’s done by Thunderbird and the e-mails are stored in Gmail OR if it’s done by the Proton bridge and the e-mails are on their servers, the same PGP tech the only difference is the clients.


they always do client-side auth rather than tradition server-side auth

They must have some server-side auth as well, otherwise I could just emulate requests from the bridge an pull all your PGP encrypted email from their servers. Even though it would be mostly useless it would still be a big vulnerability issue.

IMAP/SMTP-based provider to whom you always send your passwords in plaintext

Why do you say that? What led you to believe it?

Most providers are running IMAPS (IMAP over SSL) or IMAP with StartTLS (upgrade to TLS) and the same for submission to make sure there are no passwords in plain-text. Furthermore mail clients and servers also support password hashing and some, like Google, even go further and push people into IMAP/SMTP authentication with XOAUTH2 (OAuth token unique for each e-mail client).

Non-plaintext mechanisms have been designed to be safe to use even without SSL encryption. Because of how they have been designed, they require access to (…) their own special hashed version of it. https://doc.dovecot.org/configuration_manual/authentication/authentication_mechanisms/#non-plaintext-authentication

Going back to Proton, if they do use PGP in a generic way it means all your e-mail are encrypted and whenever you want to open the website or use the bridge they’ve to decrypt them. As you described before, they do this client side and that’s okay.

Now the next question is: how do they decrypt your mailbox? Their servers hold your private PGP key encrypted with your login password, once a client wants to decrypt your mailbox it has to pull that private key from the server and then use your password to locally decrypt it. Said now plain text key can then be used to decrypt the e-mails. This is a common security practice to make PGP and other asymmetric encryption schemes work securely without forcing the user to store and mange its own private key - that’s okay as well.

For e-mail coming from external providers (and people who don’t use PGP) Proton receives the unencrypted message (over TLS) and then encrypts it with your public PGP key. After this point you are the only person who can decrypt the message because while they also hold your private key it is encrypted thus they can’t use it to decrypt the message. This is reasonable and okay.

Now the thing is, all this can be accomplished via IMAP/SMTP, with the same level of security, if you employ a few rules:

  1. Tell customers who want to use IMAP/SMTP that they’re required to configure PGP manually on their clients otherwise their mailbox will be encrypted / useless and they won’t be able to send e-mail;
  2. Submission (sending e-mail via SMPT) servers configured to refuse any e-mail that isn’t PGP encrypted;
  3. Only provide IMAP/SMTP authentication with SSL/TLS;
  4. Restrict the IMAP/SMTP authentication to a non-plaintext mechanism;
  5. If they don’t go for XOAUTH2, then force people into creating a specific app password for each e-mail client - like Google also allows for legacy stuff that doesn’t support XOAUTH2.

Note that their current apps/bridge also needs to authenticate itself with some hashed version of your password, otherwise I could just emulate requests from the bridge an pull all your PGP encrypted messages from their servers. Actually using XOAUTH2 tokens or unique app passwords would be even be safer than what they’re doing.

Considering their PGP implementation is standard then doing those tweaks isn’t impossible and they would provide the same level of security their apps provide but also be flexible enough for more advanced users.


Great find, even worse than what I was thinking. Like you I was also under the assumption they applied some kind of encryption to all metadata as well.


PGP is not closed. What proton has done is make a really cool JS library for PGP as part of their Web UI (openpgpjs.org) which other projects, even those unrelated to Proton have used, like Mailvelope.

I never said PGP was closed, what I was saying is that their implementation of the access to their service is closed (not using standard IMAP/SMTP) and subsequently “their” PGP might be questionable / opaque.

If they actually do everything with open standards and PGP by the book as they say, why can’t they provide IMAP/SMTP access to everyone who wants it BUT add the disclaimer that you’ve to use a PGP compatible e-mail client and configure it to deal with the encryption… they could even configure their submission to refuse any email that isn’t PGP encrypted to improve things further. The fact that they don’t do this leads me to believe that they either a) aren’t actually doing everything as “by the book PGP” and there might be security issues or b) they’re “privacy” as a catch all excuse in order to push a bit of vendor lock-in.

Their market niche is privacy conscientious people and those same people tend be to computer savvy and I bet half of them would mind setting up PGP on Thunderbird and use Proton without a bridge. Everyone else could still use their apps, web or the bridge.





Here’s what I think: if they actually do everything with open standards and PGP by the book, why can’t they provide IMAP/SMTP access to everyone who wants it BUT add the disclaimer that you’ve to use a PGP compatible e-mail client and configure it to deal with the encryption… they could even configure their submission to refuse any email that isn’t PGP encrypted to improve things further. The fact that they don’t do this leads me to believe that they either a) aren’t actually doing everything as “by the book PGP” and there might be security issues or b) they’re “privacy” as a catch all excuse in order to push a bit of vendor lock-in.

Their market niche is privacy conscientious people and those same people tend be to computer savvy and I bet half of them would mind setting up PGP on Thunderbird and use Proton without a bridge. Everyone else could still use their apps, web or the bridge.


You actually pose an interesting question, what happens if they go down. How much time will their apps / cache work? We don’t know.


I agree 100% with your ideia. The best path for this would’ve been for them to actually design that system you describe and THEN implement it on Dovecot and Postfix in their own fork or a Dovecot extension / Postfix add-on so others would start using them. Eventually after some times and other providers also optionally supporting the thing an RFC could be written. This is the usual course we see with protocols/extensions and is what should’ve happened here.

I want to share another thing, before Snowden there was Lavabit, they also did “encryption at rest” and the user password involved for some parts of the information and it was proven to be effective. It wasn’t a perfect model but it was certainly better than the havoc Proton did to e-mail by opening the precedent that is okay not to run on standard protocols.

What Proton is doing to e-mail is about the same that WhatsApp, Messenger and others did to messaging - instead of just using an open protocol like XMPP they opted for their closed thing in order to lock people into their apps. People in this community seem to be okay with this just because they sell the “privacy” cool-aid.

server-to-server communication, like for automatic pgp key negotiation, would be nice too.

I’m not sure if this is required. Any decent e-mail server uses TLS to communicate these days, so everything in transit is already encrypted.

Still, Proton has a easy to access data export that doesn’t require a bridge client or subscription or anything. I think that’s required by GDPR.

Yes, they have it because GDPR does require it. It works, but it’s not a real time sync alternative to anything and it is some kind of vendor lock-in.

As I said in other comments, not using standard protocols only makes thing worse. I used iOS as an example, for Android you can get a bridge but that’s just going to be one more thing going for your battery.

Now, consider this, there’s a TON of situation where having a standard SMTP-capable provider is interesting. Maybe you’re running in iOS, maybe you want to have an ESP32 to send a few emails, or some custom software in your computer. All those use cases are impossible or require more coding and more non-standard solutions just because Proton decided to be the first provider ever not to use standard protocols.


And, and what will happen when they decide to discontinue the bridge? What happens when you’re running on iOS and you can’t have the bridge? You’ll be forced into their apps, that’s pretty locked. Besides does the bridge even provide contacts and calendars to Thunderbird? Last time o checked it didn’t. What about notes?


The issue not that you can’t export in bulk, you’re locked into their apps daily. Every other email provider out there uses standard protocols that allow for any client to be used.

Besides, the export feature is all fun until you actually have to use it. There’s a bunch of metadata that gets lost, contacts, calendars and notes are exported in JSON with propriety structures that other systems can’t deal with. Note that there’s also CardDAV/CalDAV as open and interoperable solutions for those issues and they device not to use them.


There’s no vendor lock in until you realize your emails are essentially hostage of their apps and a bridge that may be shutdown at any point. If you can’t simply setup a regular email client then there’s vendor lock in, not even Microsoft does that.


The point is that you’ve tons of Chinese companies selling e-ink tablets with color displays and Kobo now decided to spend a couple more bucks doing the same in order to catch up.


Hey, I found this game I used to play a very long time ago and I wanted to experience it again. Unfortunately I wasn't able to run it in Windows 10 / Windows XP SP3 VM because it would lag on modern hardware. Here is what you need to do in order to get the game running: 1. Search for "Midtown Madness 2 (Europe) (Rerelease)" on TPB and download it 2. Load the disk with [WinCDEmu](https://wincdemu.sysprogs.org/) or other solution 3. Install the game (don't launch it) 4. [Enable DirectPlay on Windows](https://www.thewindowsclub.com/how-to-install-and-enable-directplay-on-windows) 5. Copy `Crack\midtown2.exe` to the gamefolder 6. Download dgVoodoo2 from http://dege.freeweb.hu/dgVoodoo2/dgVoodoo2/ 7. Copy `dgVoodoo2.exe` to the game folder 8. Copy all files inside `MS\x86` to the game folder as well 9. Run `dgVoodoo2.exe` as admin and set the following: - Click the button `.\` to create config file to MM directory - In "General" > "Output API" select "Direct3D 11 MS WARP (software)" - Go to "DirectX" tab and change the VRAM to 128MB - Click "Apply" > "OK" to exit. 10. Launch the game > Options > Graphics > select from Display drop down menu, "dgVoodoo DirectX Wrapper" > "Hardware (3D video card with T&L) from the Renderer drop menu. 11. Click "Done" and that's it! Note that whenever you change the resolution it won't apply any changes to the game menu - you'll only see it once you start a race. Midtown Madness 2 should now run very smoothly under Windows 10, even on Virtual Machines. Enjoy.
fedilink

Linus Torvalds Comments on ARM: Did he lose touch with reality?
tr:dr; he says "x86 took over the server market" because it was the same architecture developers in companies had on their machines thus it made it very easy to develop applications on their machines to then ship to the servers. Now this, among others he made, are very good points on how and why it is hard for ARM to get mainstream on the datacenter, **however** I also feel like he kind lost touch with reality on this one... He's comparing two very different situations, more specifically eras. Developers aren't so tied anymore like they used to be to the underlaying hardware. The software development market evolved from C to very high language languages such as Javascript/Typescript and the majority of stuff developed is done or will be done in those languages thus the CPU architecture becomes irrelevant. Obviously very big companies such as Google, Microsoft and Amazon are more than happy to pay the little "tax" to ensure Javascript runs fine on ARM than to pay the big bucks they pay for x86.. **What are your thoughts?**
fedilink