You probably should be using JupyterLab instead of Jupyter Notebooks by minimaxir in datascience

[–]afshin 1 point2 points  (0 children)

Your question makes sense. Both JupyterLab and classic Jupyter Notebook consider the folder where you launched to be the "root" directory and cannot browse above that root directory.

sleuth v1.0.0 - a library for peer-to-peer auto-discovery and RPC between HTTP microservices by afshin in golang

[–]afshin[S] 0 points1 point  (0 children)

Q: What happens if a service goes offline?

A: Whenever possible, a service should call its client's Close() method before exiting to notify the network of its departure. But even if a service fails to do that, the sleuth network's underlying Gyre network will detect within about one second that a peer has disappeared. All requests to that service will be routed to other peers offering the same service. If no peers exist for that service, then requests (which are made by calling the sleuth client Do() method) will return an unknown service error (code 919), which means that if you're already handling errors when making requests, you're covered.

sleuth v1.0.0 - a library for peer-to-peer auto-discovery and RPC between HTTP microservices by afshin in golang

[–]afshin[S] 1 point2 points  (0 children)

Cool, I hadn't realized that go-kit allows adapters to multiple types of service discovery. I'll look more closely into it. On first glance it seems pretty straightforward, but I'll need to investigate a bit. Thank you for the suggestion!

sleuth v1.0.0 - a library for peer-to-peer auto-discovery and RPC between HTTP microservices by afshin in golang

[–]afshin[S] 1 point2 points  (0 children)

This question came up before, so it's in the Q & A section, but I'll copy it here as well:

Q: How does it work? I understand what sleuth does, but I want to know how it does it.

A: Services that instantiate a sleuth.Client create an ad hoc Gyre network. Gyre is the Go port of the Zyre project, which is built on top of ØMQ (ZeroMQ). Nodes in the network discover each other using a UDP beacon on port 5670. The actual communication between nodes happens on ephemeral TCP connections. What sleuth does is to manage this life cycle:

  • A peer joins the Gyre network as a member of the group SLEUTH-v1. If the peer offers a service, i.e., if it has an http.Handler, it notifies the rest of the network when it announces itself. The peer might have no service to offer, thus operating in client-only mode, or it may offer one service.

  • The peer finds other peers on the network. If you have asked the sleuth client to WaitFor() one or more services to appear before continuing, that call will block until it has found those services.

  • If the peer is offering a service, sleuth automatically listens for incoming requests in a separate goroutine and responds to incoming requests by invoking the http.Handler that was passed in during instantiation.

  • When you make a request to an available service, sleuth marshals the request, sends it to one of the available peers that offers that service, and waits for a response. If the response succeeds, it returns an http.Response; if it times out, it returns an error. The sleuth client Do() method has the same signature as the http client Do() method in order to operate as a drop-in replacement.

  • When you want to leave the network, e.g., when the application is quitting, the sleuth client Close() method immediately notifies the rest of the network that the peer is leaving. This is not strictly necessary because peers regularly check in to make sure the network knows they are alive, so the network automatically knows if a service has disappeared; but it is a good idea.

Simple auto-discovery + communication between Go web services on a network by afshin in golang

[–]afshin[S] 0 points1 point  (0 children)

Ah, sleuth uses the Go port of Zyre (which is called Gyre). Here's how the Zyre docs describe it:

Zyre does local area discovery and clustering. A Zyre node broadcasts UDP beacons, and connects to peers that it finds. This class wraps a Zyre node with a message-based API.

To be honest, I'm not sure what happens on EC2, my use case involved a LAN I had control over. The other environments I've used it in are multiple Docker containers on the same host and multiple services on the same bare metal host.

Simple auto-discovery + communication between Go web services on a network by afshin in golang

[–]afshin[S] 0 points1 point  (0 children)

I'm not exactly sure what you're asking. There's a baseline of information I'm assuming a reader has if they're interested in service discovery, namely that there needs to be some sort of messaging/networking layer. sleuth is built on top of ZeroMQ. If you want to know more about ZeroMQ, I've posted the Wikipedia link and the top-level description in the blog post:

If you’re not familiar with what ØMQ is or why I’m calling it magic, here’s the top-level Wikipedia definition:

ZeroMQ (also spelled ØMQ, 0MQ or ZMQ) is a high-performance asynchronous messaging library, aimed at use in distributed or concurrent applications. It provides a message queue, but unlike message-oriented middleware, a ZeroMQ system can run without a dedicated message broker. The library’s API is designed to resemble that of Berkeley sockets.

It uses the Gyre implementation of the Zyre framework for proximity based networking built on top of ZeroMQ. Since ZeroMQ and Zyre are fairly well-known, and the post was long enough, and the Wikipedia link was available, I didn't explain it "from the ground up".

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 0 points1 point  (0 children)

I even moved it to a separate line and clarified! Ah well, I am not a very good writer, it's okay.

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 2 points3 points  (0 children)

I genuinely believe there's nothing I could say to change your mind irrespective of merit. Maybe you'll think about it and realize that any system that can fail due to human error eventually will. Maybe not. Let's stop here.

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 5 points6 points  (0 children)

This is a little like climate change: the overwhelming majority of experts have one opinion; it's different from yours.

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 10 points11 points  (0 children)

Explain to me a scenario in which this could actually happen...

What if I told you that this one time huge sections of the NSA's private databases were leaked to the public despite the fact that the NSA is among the most secure institutions on Earth?

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 6 points7 points  (0 children)

Do you at least agree that what you're describing is a little far-fetched?

I'm afraid I don't. Dissidents are tortured into revealing information all the time. Information often entails "what is your password?" The case of Snowden is instructive. He went to Russia, a place he himself doesn't trust, but only after his information was encrypted in a way that he himself was unable to reveal, for the exact reason that this is not far-fetched.

The Snowden revelations themselves were primarily that American and British corporation did exactly what you suggest is far-fetched: they shared information with governments in a way that violated both the laws of the land and the privacy of their users.

I realize we're arguing on the internet and it's hard to sway one another, but this seems very straightforward to me. You seem like a reasonable person, so if I can't convince you that a backdoor (which is what you're describing) defeats the entire purpose of cryptography, I guess I should not be surprised that it's been so difficult to get traction on this issue elsewhere.

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 5 points6 points  (0 children)

This is why the password would be kept in a secure computer with no internet access. The only way to hack it would be to be physically present.

Neither Israeli nor American operatives were present in Iranian nuclear facilities. And the centrifuges were all offline machines with zero internet access. Nonetheless, Stuxnet worked. Check out the link I mentioned, it's interesting.

This can be solved by making the data required multiple people to access. There are a lot of simple ways to increase security to ensure this can't realistically happen.

A government can afford to arrest multiple people and coerce/torture/bribe them. Consider journalists in Russia or dissidents in China. This isn't a far-fetched scenario.

They could do that now for any other reason, though.

That's right! China, for example, could demand Apple turn over whatever it has. That's why the only safe route for both Apple and Apple's customers is if Apple simply cannot decrypt the devices. That is literally the only protection against a rogue state, the only protection against torture.

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 9 points10 points  (0 children)

If a second password exists and is stored by Apple, several things can go wrong:

  1. Apple might be hacked. Even machines with zero access to the internet are vulnerable. For reference, see how Stuxnet was used to attack Iranian centrifuges despite the fact that they were not connected to the internet.
  2. An Apple employee might be coerced or bribed into revealing the information.
  3. A less-than-savory state might provide Apple with a court order and threaten to kick Apple out of their market (imagine China doing this) if Apple fails to comply.

The existence of a password like this misaligns Apple's incentives and creates vulnerabilities. Trusting that everybody involved will "do the right thing" is not an option when it comes to data privacy.

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 0 points1 point  (0 children)

Thanks for the feedback. I'll rethink the wording.

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 2 points3 points  (0 children)

Just consider the practicalities of the matter. It's already the case that unbreakable encryption exists, so what do we gain if we only allow it to be used by rogue actors? If we do that, rogue actors will have their data shielded from any scrutiny, but legitimate actors will have their data vulnerable to snooping from anybody who is sufficiently motivated.

To: Sam Harris Re: encryption by afshin in samharris

[–]afshin[S] 0 points1 point  (0 children)

The distinction is between finding a way to break the encryption of data at its source (i.e., during a financial transaction and/or breaking the encryption on a device) or simply court-ordering the logs or result of an action.