Reisen · HackerTrans

vor 3 Monatendiscuss

Wait so the engineers doing novel work are ousted; you fire the engineer that had the skill set to produce the work in the first place? Surely this is creating a Stasi-like neighbour snitching environment with chilling effect where the better you do the faster you become a target for replacement by engineer's incentivized to win points by replacing you. Even being very charitable where the scenario is the code was so poor that the code the employee is working on is so entrenched in domain knowledge they've become a huge bus factor, an LLM is going to make that kind of code worse. I'm struggling to imagine the subset of people this replaces that is not a long term detriment to everyone working there. Those people became "key personnel" for a reason no?

Reisen

vor 2 Jahrendiscuss

I agree with the principle here wholeheartedly. One addendum though is I think this isn't quite the same as the mud puddle test. The idea behind the mud puddle test is if you've forgotten everything, but then manage to recover your data, then the principle must be that someone other than you has to have had access. With Signal, they intentionally refuse to sync data as an extra security step even if you have the keys, the software just refuses to do the syncing step. I'm glad they do personally and I'm not contradicting your point, just adding some notes. Just thought it worth noting.

Edit: Actually, yeah that proves your point.

Reisen

vor 3 Jahrendiscuss

This is something I have been wanting for nearly a decade. A lot of writing software isn't just implementing your logic and abstractions but actively thinking about how to organize code to the constraints of the filesystem. Having to actively model your modules around file paths, Rust for example tightly binding the use of `mod` to your layout. Refactoring is the same, a non-trivial amount of time on large projects when re-factoring is realising you need to re-organise some module hierarchy and that involves modifying the file system too.

I really dislike this, instead of a fuzzy file finder I want a fuzzy function finder, where all functions are just kept in a database that I can pull into buffers at will. Where hierarchy is only based on the logical structure of your program and the filesystem ceases exist. "New Function" over "New File". You can get the "Fuzzy Function" finder part somewhat with LSP Symbols, but it doesn't get rid of the having to think about files.

Unfortunately I don't think you can get this without first-class support by the language itself, and new languages getting critical adoption isn't a regular thing.

Reisen

vor 3 Jahrendiscuss

It's worth considering that spying on DNS is a tremendous privacy leak, much more than "the most they can do" implies. An aware user might configure their system with DoH and use a privacy respecting DNS provider but for many users on a default home connection the ISP is pretty much able to build up a traffic profile of everything you visit and when you visit it. A VPN provider can close this hole too quite easily.

Just from DNS, your ISP can:

1. Infer shopping habbits.

2. Infer which communication services you use (flag users hitting signal.org)

3. Infer when you install, update, or open programs based on telemetry DNS, potentially the versions being run, and how long they run for.

4. Infer when you're most active, infer sleeping habits.

5. Infer probability of health problems if you're hitting more medical sites.

6. Infer political alliance from news sites you visit.

And much more.

Since US congress dropped the rules preventing ISPs selling this data this might be the most insidious thing your ISP can do today.

If you believe that a VPN provider is less likely to spy due to it being the incentive for a paying customer, then a VPN with a no-log DNS option is a huge privacy win. I would argue DoH with NextDNS by itself does more for your privacy than any VPN does with IP masking.

Reisen

vor 3 Jahrendiscuss

I hadn't! I just gave it a shot and it seems sadly it suffers from the same problem. If I try and reply to an email received via SimpleLogin, it leaks my real email address (no option to reply as the receiving address), protonmail-bridge rejects it as a sender as well same as a catch all reply. Unfortunate.

Edit: Seems there is a reverse alias option, and seems to work well, will give it an honest go before migrating, thanks for the tip.

Reisen

vor 3 Jahrendiscuss

Sure. I'm not sure what case you're trying to make. Lack of competition does not mean there is no place for criticism, if the service works for you by all means you should use them if that's the best decision for yourself. These are just my reasons for avoiding a product like Proton Pass from this particular company and why I will migrate away and would not recommend them for users who might be similar to myself.

Reisen

vor 3 Jahrendiscuss

At least last I checked they didn't have a protonmail-bridge equivalent for IMAP support, so you're locked into the web UI unfortunately. It might be that if you value privacy the best choice at the moment is actually to pick a non-encrypted provider with a strong GDPR/deletion policy and IMAP pull everything and simply keep your account clean by purging the remote at all times.

Reisen

vor 3 Jahrendiscuss

I am a current user of Proton about to search for a solution to move away from this company, I am quite disappointed in my experience with them in general.

1) Their mail import tool reports wrong email set count and sizes leading to low confidence the tool worked, in the end I mbsync'd from both fastmail and proton and compared the email set because the migration UX was so poor (this is reported by other users also).

2) Their alias address implementation is severely limited, on Fastmail I used *@domain to have infinite emails, on Proton you have to add every alias you want manually one by one, if you do not, you cannot reply from any address. This is not only limited in the UI, but everywhere, protonmail-bridge for example will reject sending any email that is not in your alias list, and as they limit it to 100 addresses you can't work around it programatically either.

3) Their bridge software is buggy, and poorly documented, it's better with the recent release but for a while it made heavy assumptions about your installation and would log you out sporadically, sometimes requiring gpg-agent to be restarted (for no reason I could figure out) before being able to re-auth.

4) Their Proton Drive offering is basically useless, it is not available on Linux so can't use it as a target for backup software like Kopia/restic etc, and desktop apps have been in development for as long as I can remember. The WebUI for it will break if you try and drop too many files at once. It has problems with file name limits which don't appear until you try and access the filesystem again; after uploading several documents with extremely long names I found they were straight up inaccessible on my phone or via the web, so as far as I can tell if I hadn't had a second backup I would have lost these files.

All this would have been rough, but acceptible for me if I felt their client attention / support was good, but the support I received was terrible. Multi-day back and forths with support agents who did not seem to understand my questions, where with fastmail I would have a technical response to almost any question within an hour.

Their uservoice page is full of basic requests that are unanswered after years: https://protonmail.uservoice.com/

I've never regretted migrating to a company as much as I do Proton and I would not recommend switching to their applications, everything feels half baked or limited by poor focus on reaching feature parity with other competing services. The fact I can't do basic catch-all domain with their email service without being forced to reply via a limited alias list (if I can, their support was incapable of telling me how), was my last straw.

It's a shame there's basically no other encrypted mail host that competes.

Reisen

vor 3 Jahrendiscuss

This is a correct intuition yes. A program written in Cairo taking your balance (private) and a minimum collateral (public) and outputs a boolean for pass/fail, where the lender can only see "pass/fail" but trust the program was executed correctly is right.

However the technology isn't particularly useful in this scenario. It's enough for your bank to just reply to a request with "yes" without running the program because in theory you are forced to trust the bank no matter what as you have no guarantee the bank didn't just lie about your balance in the input to the Cairo program, so in this scenario the proof doesn't bring much. This technology is a lot more useful when the data being verified is combined with something that guarantees that the data input wasn't forged somehow, which is why this is more useful in blockchain environments where all transactions and balances are signed, so someone can't just invent a balance out of thin air.

Reisen

vor 3 Jahrendiscuss

Paranoia about untrusted hardware is absolutely warranted but just to try and convince you of what this is trying to do. Imagine you have a file that you have never shown anyone, and some untrusted host wants to convince you they also have that file. They can prove this to you without you revealing the file to them (or them to you) by having them send you the hash of the file that you can compare to your own. If it matches there is an overwhelming probability they also have the file even though you completely distrust them or their execution environment. In other words, you are able to verify the computation (via the hash) was executed even though you don't trust them. Cairo is using similar techniques that let you verify other forms of computation than just hashes using more advanced primitives.

The obvious caveat to this just as with hashes is you trust the underlying cryptography is secure.

comments