this post was submitted on 18 May 2025
243 points (97.3% liked)

Buy European

5873 readers
467 users here now

Overview:

The community to discuss buying European goods and services.

Matrix Chat

Rules:

  • Be kind to each other, and argue in good faith. No direct insults nor disrespectful and condescending comments.

  • Do not use this community to promote Nationalism/Euronationalism. This community is for discussing European products/services and news related to that. For other topics the following might be of interest:

  • Include a disclaimer at the bottom of the post if you're affiliated with the recommendation.

  • No russian suggestions.

Feddit.uk's instance rules apply:

  • No racism, sexism, homophobia, transphobia or xenophobia
  • No incitement of violence or promotion of violent ideologies
  • No harassment, dogpiling or doxxing of other users
  • Do not share intentionally false or misleading information
  • Do not spam or abuse network features.
  • Alt accounts are permitted, but all accounts must list each other in their bios.
  • No generative AI content

Benefits of Buying Local:

local investment, job creation, innovation, increased competition, more redundancy.

European Instances

Lemmy:

Matrix:

Related Communities:

Buy Local:

Continents:

European:

Buying and Selling:

Boycott:

Countries:

Companies:

Stop Publisher Kill Switch in Games Practice:

Banner credits: BYTEAlliance

founded 3 months ago
MODERATORS
maam@feddit.uk
alex@jlai.lu
circledot@feddit.org
Argyle13@lemmy.world
Sunshine@feddit.is
Sunshine@lemmy.ca
buyeuropean@lemmy.ca
buyeuropean@feddit.org
lazycog@feddit.uk
243
"We would be less confidential than Google" โ€“ Proton threatens to quit Switzerland over new surveillance law (www.techradar.com)
submitted 2 days ago by sunshine@lemm.ee to c/buyeuropean@feddit.uk
46 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[โ€“] 52fighters@lemmy.sdf.org 32 points 2 days ago (2 children)

Can we have technology that's secure enough that it doesn't matter what country we are in?

[โ€“] AwesomeLowlander@sh.itjust.works 45 points 2 days ago (2 children)

Not as long as somebody else is hosting the server.

[โ€“] Angry_Autist@lemmy.world 1 points 2 days ago (1 children)

I think you are confusing secure with available

There are several dozen paths to securely hosting on someone else's service but they can still pull the plug on your server

If you do it right, they can image and pen test it all they want and get nothing out of it.

Just almost no one bothers to take the time

[โ€“] AwesomeLowlander@sh.itjust.works 3 points 1 day ago* (last edited 1 day ago) (1 children)

That's you hosting the service on somebody else's server. I meant somebody else hosting the service, which means somebody else running the software and having admin rights, and there's no way you're securing that.

Just almost no one bothers to take the time

Obviously. Imagine if we applied the same logic to food safety, or anything else. There's no practical way to be self-sufficient in all aspects, and no reason we should be.

[โ€“] Angry_Autist@lemmy.world 2 points 1 day ago (1 children)

Not really, okay I am going to give you the back of the napkin black box operation.

So you lease the instance and spin it up from the console. The first thing you do is set up a SSH key only access instance so from the moment its spun up, the only logins will be from a key that the hosting service is not privy to.

Once established and you make a shell connection, you can SEE how many logins there are and there will be only you. Ok then you set up a virtual machine within that system that maps to the NIC of the host.

Now you have a virtual machine inside a virtual machine that the host service has no access to.

that second virtual machine's secure shell login is set to a non-rotating one time pad that is delivered while monitoring virtual machine 1 for alternate logins. If at any time it is suspected, the entire instance can be wiped and the one time pads discarded and a new pair generated and the process begun again

Once the nested virtual machine is operating, its memory operations are also encrypted by the one time pad, provided it was uploaded completely within the window where you were the only logged in user to VM 1, this means even with the most sophisticated memory reading technology, without that one time pad the data is unreadable, and the only way to get the pad is to have been watching while the pad was uploaded to the 2nd virtual machine.

In this scenario since we have maintained theoretically perfect end to end encryption thrice over, so the one time pad doesn't need to be large, because when you get to the end of the shared key list the last record can be used to safely transmit another arbitrarily large one time pad.

The ONLY way this scenario is compromised is:

  1. A compromised kernel and since we are being careful with our distros, we know it is valid and tested by millions of man hours, this is unlikely

  2. Someone using a quantum computer to crack the public key set used to secure the 2nd virtual machine via direct reading of the physical server's memory, jumping in as an invisible Man in the Middle attack in the time between the 2nd instance is spun up and the first one time pad record is received (we are talking fractions of a second)

And EVEN THEN they just have the digits of the one time pad don't contain their method, that's in the 2nd VMs kernel and is unreadable in memory unless you can guess the method perfectly the first time.

Let me give you an example, this is ridiculously simplified:

say the one time pad first entry is:

5TF7M828D3

and the method is 'add the hex value of every 3rd character and xor it with the hex value of every 2nd character', and that is the base encoding for the private key that will be secure

See?

you can be aware of the string: 5TF7M828D3, but not know how to manipulate it to get the desired secure private key

[โ€“] AwesomeLowlander@sh.itjust.works 2 points 1 day ago (1 children)

I understand the scenario you are describing to me, and that it's perfectly plausible. (I do see a potential weakness or two which I'd love to discuss separately). Let me try to clear up the confusion in the current discussion thread. What you are describing is somebody running their own software service. This is possible, I'm not arguing that. My original assertion, is that if you allow somebody else to run the SOFTWARE service for you, you are inherently at their mercy. Based on what you've just described, I'm absolutely certain you agree with that assertion. This is also the only reasonable way most of the world would have access to most online services. The idea of everybody hosting their own software stack for every service they would like to use is laughably impractical and implausible.

[โ€“] Angry_Autist@lemmy.world 1 points 1 day ago (1 children)

I think what you are trying to say is that if they have shell access it is insecure and yes I agree with that

But even if they have shell access, as long as I can be assured no one else is logged in, I can make any linux box just as secure in about twelve minutes using the above scenario.

Yes in what I described there are weaknesses such as L1 cache doping to vastly reduce uncertainty making identification of prime stripes in packets trivial, but to practically pull that off you need an electron microscope installed above a naked operating processor meaning the entire room has to be sub zero and sealed from contaminants and prepared days beforehand

Which means that any joe schmo spinning up a digitalocean droplet isn't going to be hosted on a machine with NSA grade top level memory and CPU observation installed

[โ€“] AwesomeLowlander@sh.itjust.works 1 points 1 day ago (2 children)

I was more thinking that, in theory, anything you install and run could be compromised from the get go. With enough prep, any distro could be replaced with a compromised version on the fly and you would have no way to tell. Any tools you use could similarly be compromised to give you untrustworthy output. It would require a heck of a lot of investment, but not beyond the scale of nation states, and would be pretty scalable.

[โ€“] Angry_Autist@lemmy.world 1 points 1 day ago (1 children)

How are they 'changing on the fly' the distro I downloaded the week before and ran a CRC check on?

Any tools you use could similarly be compromised to give you untrustworthy output.

Serious question, do you have any background in IT security?

I ask that because to cover this properly will take effort, and I'm not prepared to waste that on someone who won't understand what I'm writing.

[โ€“] AwesomeLowlander@sh.itjust.works 1 points 1 day ago (2 children)

How are they 'changing on the fly' the distro I downloaded the week before and ran a CRC check on?

Well, you're uploading it remotely at some point. Essentially it's a supply chain attack, where during the process of upload it's compromised by the remote server. The logic would be - they can fingerprint any reasonable distro you might use, and replace it with a pre-prepared compromised version. Any tools you might use to check its veracity could potentially be poisoned the same way, no? As I said, remote possibility and high cost, but not implausible.

Serious question, do you have any background in IT security?

A little. I'm in IT, and know the basics.

[โ€“] Angry_Autist@lemmy.world 1 points 1 day ago

and as for 'tools I might use to check', literally anyone can code their own CRC checker in python with no python experience in like 20 mins using widely attested public algorithms

[โ€“] Angry_Autist@lemmy.world 1 points 1 day ago

A little. Iโ€™m in IT, and know the basics.

Then you understand how statistically impossible it is to craft a modified distro that passes a CRC check?

And by statistically impossible, I mean this in a thermodynamic sense, as in that it is much more likely that you are a brain floating in a void that cohered completely from nothingness due to vacuum energy than it is that any given iteration of a modified file of considerable length will match the same CRC as an established, published, vetted copy.

It is about 100 times easier to randomly guess the private key of a bitcoin wallet than it is to iterate arbitrary changes to match CRC results.

There is a reason it is still the gold standard of file authenticity despite it being literally based on a largely unchanged 50 year old technology.

[โ€“] eldain@feddit.nl 0 points 1 day ago

If you are running an 'illegal' service, why not host it on a virally distributed botnet and embrace the chaos and mistrust in your host systems? Might be the best way to detach from anyhing physical with a fixed location that causes traceable bills.