• 0 Posts
  • 97 Comments
Joined 1 year ago
cake
Cake day: July 18th, 2023

help-circle
  • Custom domains mean that if the alias provider enshittifies, you can switch to any other provider near-instantly. As long as you never use the domains to host illegal or dodgy shit it’s extremely unlikely you’ll ever lose them — far less likely than losing a gmail or whatever.

    With SL you can avoid spam by using the “beta” (been beta for 3+ years lol) “auto create” option instead of a catch-all, meaning that you can direct emails to different inboxes (or do nothing) based on specific regex strings you control — up to 100 of them. I had a catch-all regex (.*) as my # 100 and it took 2 years to receive catch-all fishing spam. Then I removed it and now have only random strings (e.g. .*fgyu.*) so new emails must have them if they want to get somewhere. Everything else bounces. All previous emails continue to work until you disable them individually.

    I use a mix:

    • SL-domains: anything I don’t give a shit about.
    • Non-PII domain: anything I would want to persist if I changed provider, but don’t need my identity, or can give out a unique email in-person.
    • PII-domain: banks and all other services tied to my identity.
    • Top-Secret-PII-domain: critical services that could compromise all others (password manager, email/OS accounts, domain name registrar).



  • The obvious solution to me is sponsorblock switching to sampling pixels out of each frame, like that project that encoded data into video streams (yet resilient to compression), there are algorithms that could fingerprint any ad with an extremely high degree of accuracy. It’d be more complex than the current implementation, but it’d also be more resilient. I’d settle for it hiding the video and suppressing the audio for the ads duration, possibly displaying a countdown timer, vs actually watching the ad. Then Youtube would get paid, but have no way of knowing you haven’t seen the ad, and the metrics around their ad effectiveness would ultimately suffer, so users still win.

    You could even go so far as to have the client cache the video, several minutes in advance, dropping all the ad frames, so it’s a seamless experience for the user. I got money, but will spend 10x as much ensuring Google gets less from me. It ain’t about money. It’s about sending a message!





  • One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is “Working Software over Comprehensive Documentation.”

    Requirements ≠ Documentation. Any project with CLEAR requirements will be most likely to succeed. The hard part is the clear requirements, and not deviating.

    One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”

    The inability of management to conduct productive meetings is even more well-known than their inability to conduct a decent hiring process, and we all know how broken that is.

    The study’s sample and methodology are not linked so I suspect a huge bias, in that the projects succeeding sans-Agile have been successful without it long term, while the Agile projects chose Agile because they were unsuccessful pre-adoption — you don’t adopt agile if you were already successfully delivering projects.





  • WhatAmLemmy@lemmy.worldtoAsklemmy@lemmy.mlSearch engines down?
    link
    fedilink
    English
    arrow-up
    12
    ·
    edit-2
    1 month ago

    I was thinking about this and imagined the federated servers handling the index db, search algorithms, and search requests, but instead leverage each users browser/compute to do the actual web crawling/scraping/indexing; the server simply performing CRUD operations on the processed data from clients to index db. This approach would target the core reason why search engines fail (cost of scraping and processing billions of sites), reduce the costs to host a search server, and spread the expense across the user base.

    It also may have the added benefit of hindering surveillance capitalism due to a sea of junk queries from every client, especially if it were making crawler requests from the same browser (obviously needs to be isolated from the users own data, extensions, queries, etc). The federated servers would also probably need to operate as lighthouses that orchestrate the domains and IP ranges to crawl, and efficiently distribute the workload to client machines.


  • WhatAmLemmy@lemmy.worldtoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    101
    arrow-down
    1
    ·
    edit-2
    2 months ago

    Should … Should we tell OP that nobody understands all of any moderately large codebase, especially the sub-dependencies … or that even the thousands of developers who wrote most of that code don’t understand how their own code works anymore?

    I could read the same book every year and I still won’t remember most of the minor events on my deathbed. Doesn’t mean I won’t remember the key components that make up the story — coding is like that, except the minor events and key components can be rewritten or removed by someone else whenever you go to read them next.



  • I think this question might be missing the point of TOTP and protection it provides. The reason 256/512 is used to encrypt data and passwords is to prevent the possibility of brute force and other attacks (e.g. using other data breaches). This doesn’t really matter with TOTP. They can’t reverse engineer a TOTP password out of you. They can’t use your info from prior breaches to gleen what your TOTP might be anywhere else. It’s not something where “cracking” the hash is likely to be attempted, as an attacker would still have to capture the generated codes and time of input in some way, then brute force hashes until they generate one that produces the correct codes at x time. Why would they ever do that when it would be a thousand times easier to compromise a device or TOTP app, and scrape the hashes directly from it; negating any need to brute force?

    Note: I am not a cryptographer and have not implemented a TOTP server, so I could be completely wrong.

    TL;DR 256/512 wouldn’t necessarily increase the security of TOTP at all.





  • a) why the fuck would they go to that effort for a filthy commoner like yourself, and b) what are the chances that 0.01% of recoverable data contains anything useful!?!

    Nobody is gonna bother doing advanced forensics on 2nd hand storage, digging into megabytes of reallocated sectors on the off chance they to find something financially exploitable. That’s a level of paranoia no data supports.

    My example applies to storage devices which don’t default to encryption (most non-OS external storage). It’s analogous to changing your existing encrypted disks password to a random-ass unrecoverable throwaway.