4 ms·

Really? Spam, scams, seo trash, bots and AIs, are utterly rampant. I don’t want Google and Microsoft to have the keys to the kingdom, but on the other hand, I

Really? Spam, scams, seo trash, bots and AIs, are utterly rampant. I don’t want Google and Microsoft to have the keys to the kingdom, but on the other hand, I really want a way to know that I’m having genuine interactions with real people. I wish government was getting more involved here.

xp84 3y ago
If government were, they would just be acting to further enhance the moats of the largest companies, which finance their campaigns. At least in the US. I’m not sure how EU politics is actually motivated, though they seem to advance the most useless political solutions to technological problems (browsers not having good defaults for cookies? Let’s make website owners show confusing cookie modals within the website context, that don’t usually even work!)
- Aerbil313 3y ago
  I live in Turkey and would totally love my government to distribute a national OS and a browser, even if with national TPM keys. Even if I did not trust my government to act in my interest. Because WEI and remote assertion will create absolute dependencies on American companies (who have no incentive to act on my interests anyway), even more than ever. And I don't think this is any good in terms of national security. F16 fighters sold to us which didn't fire on targets USA didn't want us to comes to my mind. Thankfully we were able to be independent from USA in weaponry in the recent years. What is a freedom problem for you is a national independence problem for us as well.
vetinari 3y ago
It won't solve any of these problem. But you will have to use hardware and software from approved vendors.
- mike_hearn 3y ago
  It can (that's why it's being pursued) and that, ironically enough, could even empower decentralized and P2P networks. Hear me out. If you look at the history of the internet it's basically a story of decentralized protocols with a choice of clients being outcompeted by centralized services with a single client, usually because centralized services can control spam better (+have incentives to innovate etc, it's not just one issue). Examples: USENET -> phpBB -> reddit, IRC -> Slack, ISP hosted email -> Gmail -> Facebook Messenger, SMS -> WhatsApp/iMessage, self-hosted git -> GitHub. The reason spam kills decentralized systems is that all the techniques for fighting it are totally ad-hoc security-through-obscurity tricks combined with large dollops of expensive Big Data and ML processing, all handled by full time teams. It's stuff that's totally out of reach for indy server hosters. Even for the big guys it frequently fails! Decentralized networks suffer other problems beyond spam due to their reliance on peers being trusted. They're fully open to attack at all times, making it risky and high effort to run nodes. They're open to obscure app-specific DoS attacks. They are riddled with Sybil attacks. They leak private data like sieves. Many features can't be implemented at all. Given all these problems, most users just give up and either outsource hosting or switch to entirely centralized services. I used to work on the Gmail spam team, and also Bitcoin, so I have direct experience of the problems in both contexts. Remote attestation (RA) isn't by itself enough to fix these problems, but it's a tool that can solve some of them. Consider that if USENET operators had the ability to reliably identify clients, then USENET would probably have lasted a fair bit longer. Servers wouldn't have needed to make block/allow decisions themselves, they could have simply propagated app identity through the messages. Then you could have killfiled programs as well as people. If SpamBot2000 shows up and starts flooding groups, one command is all it takes to wipe out the spam. Where it gets trickier is if someone releases an NNTP client that has legit users but which can be turned into a spambot, like via scripting features. At that point users would have to make the call themselves, or the client devs would need to find a way to limit how much damage a scripted client can do. So the decision on what is or is not "approved" would be in the hands of the users themselves, in that design. The above may sound weird, but it's a technique that allows P2P networks with client choice to be competitive against centralised alternatives. And it's worth remembering that for all the talk of the open web and maybe the EU can do this or that, Facebook just did the most successful social network launch in history as a mobile/tablet only app that blocks the EU. A really good reason to not offer a web version is because mobile only services are much easier to defend against spam, again, because mobiles can do RA and browsers cannot. So the web is already losing in this space due to lack of these tools. Denying the web this sort of tech may seem like a short term win but just means that stuff won't be served to browsers at all, and nor will P2P apps that want to be accessible from desktops be able to use it either. Anyway it's all very theoretical, because at this time Windows doesn't have a workable app-level RA implementation, so it's mobile-only for now anyway (Linux can do it between servers in theory, but not really on the desktop).
  - spixy 3y ago
    what is RA?
    - mike_hearn 3y ago
      Remote attestation. I updated the post to make that clearer.
    - Aerbil313 3y ago
      Remote assertion.
  - yjftsjthsd-h 3y ago
    > If SpamBot2000 shows up and starts flooding groups, one command is all it takes to wipe out the spam. Where it gets trickier is if someone releases an NNTP client that has legit users but which can be turned into a spambot, like via scripting features. At that point users would have to make the call themselves, or the client devs would need to find a way to limit how much damage a scripted client can do At which it comes back to not allowing anything but the most locked-down clients, and disempowering users... and still failing, bcecause all clients can be turned into spam bots with the most trivial application of autohotkey et al.
    - mike_hearn 3y ago
      It's all built in chains: - The OS can trivially expose to the app whether events are coming from real hardware or another app, information the app can then either report or not report. - The attested user-agent string given can be extended to include information about any scripts that are driving it, e.g. script hashes. And so on. Then these things can have reputations computed over them. If there's a script hash that shows up reliably in spam, and never shows up in ham, then you can auto-mark those posts as spam. If the scripts aren't known then messages can be throttled until enough users have voted on whether the messages are spam or not. All this is fairly straightforward to code up, again, in a theoretical world in which operating systems expose information like whether events are emulated or not (today they don't). The trick is that clients don't have to be locked down. The tech is fundamentally about letting you prove true statements. Those statements can be as complex as needed to allow whatever level of customization and control is desired. The more malleable clients are the more complex it becomes to determine what is and isn't considered OK, but in a decentralized system that policy complexity is up to the end users themselves to decide. They can share logic in the same way USENET users used to share killfiles. Anyway, my point isn't to try and design a full system here. It's research level stuff. Only to point out that this stuff brings spam/abuse control out of BigTech-only world back into the realm of small scripts that can be written and shared by users in a decentralized way.
xenator 3y ago
Sorry, but don't be silly. Government is part of the problem here. This is the reason why naïve freedom of wild west internet become what it is now is government's actions. Corporations and govs are actually the same structure. Look to healthcare, pharma, military it is so tight connected. Now IT is just part of the puzzle.
- joti6 3y ago
  [dead]

xp84 3y ago

If government were, they would just be acting to further enhance the moats of the largest companies, which finance their campaigns. At least in the US. I’m not sure how EU politics is actually motivated, though they seem to advance the most useless political solutions to technological problems (browsers not having good defaults for cookies? Let’s make website owners show confusing cookie modals within the website context, that don’t usually even work!)

Aerbil313 3y ago
I live in Turkey and would totally love my government to distribute a national OS and a browser, even if with national TPM keys. Even if I did not trust my government to act in my interest. Because WEI and remote assertion will create absolute dependencies on American companies (who have no incentive to act on my interests anyway), even more than ever. And I don't think this is any good in terms of national security. F16 fighters sold to us which didn't fire on targets USA didn't want us to comes to my mind. Thankfully we were able to be independent from USA in weaponry in the recent years. What is a freedom problem for you is a national independence problem for us as well.

vetinari 3y ago

It won't solve any of these problem. But you will have to use hardware and software from approved vendors.

mike_hearn 3y ago
It can (that's why it's being pursued) and that, ironically enough, could even empower decentralized and P2P networks. Hear me out. If you look at the history of the internet it's basically a story of decentralized protocols with a choice of clients being outcompeted by centralized services with a single client, usually because centralized services can control spam better (+have incentives to innovate etc, it's not just one issue). Examples: USENET -> phpBB -> reddit, IRC -> Slack, ISP hosted email -> Gmail -> Facebook Messenger, SMS -> WhatsApp/iMessage, self-hosted git -> GitHub. The reason spam kills decentralized systems is that all the techniques for fighting it are totally ad-hoc security-through-obscurity tricks combined with large dollops of expensive Big Data and ML processing, all handled by full time teams. It's stuff that's totally out of reach for indy server hosters. Even for the big guys it frequently fails! Decentralized networks suffer other problems beyond spam due to their reliance on peers being trusted. They're fully open to attack at all times, making it risky and high effort to run nodes. They're open to obscure app-specific DoS attacks. They are riddled with Sybil attacks. They leak private data like sieves. Many features can't be implemented at all. Given all these problems, most users just give up and either outsource hosting or switch to entirely centralized services. I used to work on the Gmail spam team, and also Bitcoin, so I have direct experience of the problems in both contexts. Remote attestation (RA) isn't by itself enough to fix these problems, but it's a tool that can solve some of them. Consider that if USENET operators had the ability to reliably identify clients, then USENET would probably have lasted a fair bit longer. Servers wouldn't have needed to make block/allow decisions themselves, they could have simply propagated app identity through the messages. Then you could have killfiled programs as well as people. If SpamBot2000 shows up and starts flooding groups, one command is all it takes to wipe out the spam. Where it gets trickier is if someone releases an NNTP client that has legit users but which can be turned into a spambot, like via scripting features. At that point users would have to make the call themselves, or the client devs would need to find a way to limit how much damage a scripted client can do. So the decision on what is or is not "approved" would be in the hands of the users themselves, in that design. The above may sound weird, but it's a technique that allows P2P networks with client choice to be competitive against centralised alternatives. And it's worth remembering that for all the talk of the open web and maybe the EU can do this or that, Facebook just did the most successful social network launch in history as a mobile/tablet only app that blocks the EU. A really good reason to not offer a web version is because mobile only services are much easier to defend against spam, again, because mobiles can do RA and browsers cannot. So the web is already losing in this space due to lack of these tools. Denying the web this sort of tech may seem like a short term win but just means that stuff won't be served to browsers at all, and nor will P2P apps that want to be accessible from desktops be able to use it either. Anyway it's all very theoretical, because at this time Windows doesn't have a workable app-level RA implementation, so it's mobile-only for now anyway (Linux can do it between servers in theory, but not really on the desktop).
- spixy 3y ago
  what is RA?
  - mike_hearn 3y ago
    Remote attestation. I updated the post to make that clearer.
  - Aerbil313 3y ago
    Remote assertion.
- yjftsjthsd-h 3y ago
  > If SpamBot2000 shows up and starts flooding groups, one command is all it takes to wipe out the spam. Where it gets trickier is if someone releases an NNTP client that has legit users but which can be turned into a spambot, like via scripting features. At that point users would have to make the call themselves, or the client devs would need to find a way to limit how much damage a scripted client can do At which it comes back to not allowing anything but the most locked-down clients, and disempowering users... and still failing, bcecause all clients can be turned into spam bots with the most trivial application of autohotkey et al.
  - mike_hearn 3y ago
    It's all built in chains: - The OS can trivially expose to the app whether events are coming from real hardware or another app, information the app can then either report or not report. - The attested user-agent string given can be extended to include information about any scripts that are driving it, e.g. script hashes. And so on. Then these things can have reputations computed over them. If there's a script hash that shows up reliably in spam, and never shows up in ham, then you can auto-mark those posts as spam. If the scripts aren't known then messages can be throttled until enough users have voted on whether the messages are spam or not. All this is fairly straightforward to code up, again, in a theoretical world in which operating systems expose information like whether events are emulated or not (today they don't). The trick is that clients don't have to be locked down. The tech is fundamentally about letting you prove true statements. Those statements can be as complex as needed to allow whatever level of customization and control is desired. The more malleable clients are the more complex it becomes to determine what is and isn't considered OK, but in a decentralized system that policy complexity is up to the end users themselves to decide. They can share logic in the same way USENET users used to share killfiles. Anyway, my point isn't to try and design a full system here. It's research level stuff. Only to point out that this stuff brings spam/abuse control out of BigTech-only world back into the realm of small scripts that can be written and shared by users in a decentralized way.

xenator 3y ago

Sorry, but don't be silly. Government is part of the problem here. This is the reason why naïve freedom of wild west internet become what it is now is government's actions. Corporations and govs are actually the same structure. Look to healthcare, pharma, military it is so tight connected. Now IT is just part of the puzzle.

joti6 3y ago
[dead]