5 ms·

> "Randomly reading from various memory addresses might give the modern programmer some concern about security holes, maybe somehow reading leftover data on the

by pavlov 2y ago

> "Randomly reading from various memory addresses might give the modern programmer some concern about security holes, maybe somehow reading leftover data on the bus an application shouldn't be able to see. On the Apple II, there is no protected memory at all though, so don't worry about it! Loosen up! The hacker doesn't need a security hole if there's no security." I miss computers that didn't have the capability to send all my important data to an unknown address in Belarus in the blink of an eye. Maybe someone could design a modern desktop operating system whose outgoing network requests are batched and processed once a day, so you can look through the batch before letting it out. This would of course mean that applications must be designed to be extremely thrifty about what data they want to send, or users would simply ban them for making large opaque requests. No more telemetry, no more ad profile updates, etc.

tossandthrow 2y ago
That would be fun stuff when requesting a web address having to wait for the batch review! That would indeed be a return to the analog world.
- pavlov 2y ago
  I'd like to have a Slack bot that explains this situation: "Thanks for contacting pavlov. Due to operating system limits, his reply to your message won't be published until 3pm tomorrow. Your patience is appreciated." Would be a stress antidote.
  - rbanffy 2y ago
    Pluto will be prime real-estate for the people who don’t like interruptions.
- jandrese 2y ago
  Several years ago I worked on a system that operated quite like this. It used DTN (Delay/Disruption Tolerant Networking) and web proxies to allow really remote villages to get internet by bus or mule drawn carriage or however they got supplies. You would make the request, it would be batched up with all of the other requests and handed off to he supply vehicle that came around every week or twice a week. That vehicle would eventually make it to a bigger city where they had real internet and it would spider out the requests a few layers deep (up to a low number of MB), then the vehicle would make another trek and it would populate a web cache in the villages so someone hitting the same URL would be served a slightly stale version of the content. It also had email so the person who make the request would get a mail stating that it was ready and give them the link.
  - rietta 2y ago
    Was this ever actually used in real life or was it an experiment only?
    - jandrese 2y ago
      We handed it off to people who were supposed to deploy it, but I had to move on after that so I never got to see it live. I kind of suspect that the window of usefulness was very short since cell towers were springing up even in really remote areas and they'd be a thousand times more useful even with just GPRS level connectivity.
  - gary_0 2y ago
    This reminds me of back when e-mail clients would store your outgoing e-mails in the "outbox" waiting for the next time you dialed in. Nowadays networked software (and much of society) can't handle days of latency, only milliseconds, and I'm not sure that's a good thing.
    - rbanffy 2y ago
      This will be one of the upsides of living on Mars.
    - canucker2016 2y ago
      Not just for dialup network access. Microsoft Mail for PC Networks used two processes - one for the email client and one for sending/receiving email (aka the "email pump") . Since Windows 3.x used co-operative multitasking, only one process could run at a time, the email pump detected idle time and start sending/receiving email. Until that processing email time, the user could open the outbox and open outgoing emails, and modify and resend or cancel them. A few years pass and Exchange 4.0 is about to ship. But now the second process has been eliminated and emails are sent via RPC to the Exchange server. The user, though, has almost no chance to stop an email from being sent since the email spends almost no time in the outbox before the Exchange server sees and processes the outgoing email. People actually grumbled about Exchange being too fast. I took a look through the list of email message properties supported in Extended MAPI. One of them was a "time delay before sending" scalar, measured in seconds. The Exchange email client (as seen in Win95, also supported on Win3.x and NT) supported extension DLLs. I created an extension DLL that let the user specify a time delay for outgoing emails, and listened for an "email send" notification and then set the user-specified "time delay before sending" property on the outgoing email. Now outgoing emails would sit in the outbox for the user-specified amount of time before the Exchange server would process them. Problem solved. AFAIK the extension DLL was the only code that had set the "time delay before sending" property on emails. It worked the first time I ran the code. Someone did the appropriate testing. Eventually Outlook 97 shipped. The extension still worked. But a later Outlook update broke the extension DLL. Finally Outlook added support for the "time delay before sending" property for outgoing emails - no need for an extension DLL anymore.
- kalleboo 2y ago
  Stallman uses an email script to read the web https://stallman.org/stallman-computing.html#:~:text=I%20generally%20do%20not%20connect,mails%20them%20back%20to%20me https://stallman.org/stallman-computing.html#:~:text=I%20gen....
deleted 2y ago
[deleted]
ChuckMcM 2y ago
A number of routers can capture every destination address your network has sent data to. You can then go through that list and mark 'safe' the ones where you know where they are going. After about a week you'll go days and days with no new addresses but when one pops up it will be some IoT device or some vistor's phone or something.
- anyfoo 2y ago
  This may work for "casual" attempts, but if someone really want to exfiltrate data, they can still do so in any number of ways. For example, they can send DNS queries. To your usual DNS server, so you won't see a new address. Which will happily pass it along to whatever the registered nameserver for the queried domain is.
  - ChuckMcM 2y ago
    Absolutely correct, any APT won’t be caught this way. But script kiddies will be every day of the week. And if you’re browser is suddenly sending queries to China after that last add-on, it can be a good bread crumb to follow up. Security, like dressing for variable weather, is best done in layers.

by pavlov 2y ago

tossandthrow 2y ago

That would be fun stuff when requesting a web address having to wait for the batch review! That would indeed be a return to the analog world.

pavlov 2y ago
I'd like to have a Slack bot that explains this situation: "Thanks for contacting pavlov. Due to operating system limits, his reply to your message won't be published until 3pm tomorrow. Your patience is appreciated." Would be a stress antidote.
- rbanffy 2y ago
  Pluto will be prime real-estate for the people who don’t like interruptions.
jandrese 2y ago
Several years ago I worked on a system that operated quite like this. It used DTN (Delay/Disruption Tolerant Networking) and web proxies to allow really remote villages to get internet by bus or mule drawn carriage or however they got supplies. You would make the request, it would be batched up with all of the other requests and handed off to he supply vehicle that came around every week or twice a week. That vehicle would eventually make it to a bigger city where they had real internet and it would spider out the requests a few layers deep (up to a low number of MB), then the vehicle would make another trek and it would populate a web cache in the villages so someone hitting the same URL would be served a slightly stale version of the content. It also had email so the person who make the request would get a mail stating that it was ready and give them the link.
- rietta 2y ago
  Was this ever actually used in real life or was it an experiment only?
  - jandrese 2y ago
    We handed it off to people who were supposed to deploy it, but I had to move on after that so I never got to see it live. I kind of suspect that the window of usefulness was very short since cell towers were springing up even in really remote areas and they'd be a thousand times more useful even with just GPRS level connectivity.
- gary_0 2y ago
  This reminds me of back when e-mail clients would store your outgoing e-mails in the "outbox" waiting for the next time you dialed in. Nowadays networked software (and much of society) can't handle days of latency, only milliseconds, and I'm not sure that's a good thing.
  - rbanffy 2y ago
    This will be one of the upsides of living on Mars.
  - canucker2016 2y ago
    Not just for dialup network access. Microsoft Mail for PC Networks used two processes - one for the email client and one for sending/receiving email (aka the "email pump") . Since Windows 3.x used co-operative multitasking, only one process could run at a time, the email pump detected idle time and start sending/receiving email. Until that processing email time, the user could open the outbox and open outgoing emails, and modify and resend or cancel them. A few years pass and Exchange 4.0 is about to ship. But now the second process has been eliminated and emails are sent via RPC to the Exchange server. The user, though, has almost no chance to stop an email from being sent since the email spends almost no time in the outbox before the Exchange server sees and processes the outgoing email. People actually grumbled about Exchange being too fast. I took a look through the list of email message properties supported in Extended MAPI. One of them was a "time delay before sending" scalar, measured in seconds. The Exchange email client (as seen in Win95, also supported on Win3.x and NT) supported extension DLLs. I created an extension DLL that let the user specify a time delay for outgoing emails, and listened for an "email send" notification and then set the user-specified "time delay before sending" property on the outgoing email. Now outgoing emails would sit in the outbox for the user-specified amount of time before the Exchange server would process them. Problem solved. AFAIK the extension DLL was the only code that had set the "time delay before sending" property on emails. It worked the first time I ran the code. Someone did the appropriate testing. Eventually Outlook 97 shipped. The extension still worked. But a later Outlook update broke the extension DLL. Finally Outlook added support for the "time delay before sending" property for outgoing emails - no need for an extension DLL anymore.
kalleboo 2y ago
Stallman uses an email script to read the web https://stallman.org/stallman-computing.html#:~:text=I%20generally%20do%20not%20connect,mails%20them%20back%20to%20me https://stallman.org/stallman-computing.html#:~:text=I%20gen....

deleted 2y ago

[deleted]

ChuckMcM 2y ago

A number of routers can capture every destination address your network has sent data to. You can then go through that list and mark 'safe' the ones where you know where they are going. After about a week you'll go days and days with no new addresses but when one pops up it will be some IoT device or some vistor's phone or something.

anyfoo 2y ago
This may work for "casual" attempts, but if someone really want to exfiltrate data, they can still do so in any number of ways. For example, they can send DNS queries. To your usual DNS server, so you won't see a new address. Which will happily pass it along to whatever the registered nameserver for the queried domain is.
- ChuckMcM 2y ago
  Absolutely correct, any APT won’t be caught this way. But script kiddies will be every day of the week. And if you’re browser is suddenly sending queries to China after that last add-on, it can be a good bread crumb to follow up. Security, like dressing for variable weather, is best done in layers.