One safety tip: disable SSH Agent Forwarding before you connect, otherwise the remote server can theoretically reuse your private key to establish new connections to GitHub.com or prod servers (though this host is unlikely malicious).
What you're looking for is that there is no line that says something like
debug1: Offering public key: /Users/fragmede/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Upon further testing, the full command you want is:
ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop
to forcibly disable a local identity agent from offering up its identities as well, and not just agent forwarding.
Upon further testing,
ssh -o IdentitiesOnly=yes terminal.shop
still offers up my public key on my system (macOS, OpenSSH_9.6p1, LibreSSL 3.3.6), contrary to what StackOverflow and the Internet seems to think. Tested by hitting whoami.filippo.io, linked in child comment.
Aha, yes, `-o IdentityAgent=/dev/null` is better for my intent. I was confused that `-i` wasn't removing .ssh/id_rsa from the candidates, but that was ssh-agent.
ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop
It's quite useful! I can give someone access to my server by grabbing their public key and creating an account for them, no need figure out how to send them the password to my server.
> You can make a search for all users, which will tell you there are 97,616,627 users at the time of this writing, but you can only fetch at most 1000 results from a search, and they don’t come in any clear order, so you can’t just make the next search start where the previous one left off (or I didn’t figure out how).
> What you can do though is request accounts created in a certain time range. If you get the time range right, so that it has less than 1000 entries, you can paginate through it, and then request the next time range.
This reminds me of when I tried to add a google drive storage backend to camlistore/perkeep (because I had nearly-unlimited free quota at the time). One of the things a perkeep blobserver needs to be able to do enumerate all the blobs it has, in order. You can send millions of blobs to google drive without issue, but you can't directly paginate a search for them in sorted order.
You could just issue a search for all blobs under your perkeep drive folder, keep paginating the result until you run out of pages, and then sort in memory, but there's really no way of knowing how many blobs you're going to end up with and you might blow out your blobserver's memory.
Perkeep blobs are identified by blobrefs, SHA sums of the contents of the blob, so they look like sha-[0-9a-f]{64}. Google drive lets you search for files with a name prefix, so you can search for like /perkeep/sha-* and see if the result has a pagination token (indicating that there are more than 1000 results), and if so then you search for each of /perkeep/sha-0*, /perkeep/sha-1*, ... , /perkeep/sha-f*, each time checking to see whether there are too many matches. When there's not too many matches, you've found the prefix length that will let you fetch a bounded number of blobrefs, emit them to the perkeep client, and then release the memory before fetching more.
/pk/sha-\* 1000+ results (non-empty pagination token)
/pk/sha-0\* 1000+ results (non-empty pagination token)
/pk/sha-00\* 1000+ results (non-empty pagination token)
/pk/sha-000\* 193 results,
sort these in memory and emit to client
/pk/sha-001\* 179 results,
sort these in memory and emit to client
...
/pk/sha-fff\* 223 results,
sort these in memory and emit to client
I didn't end up landing the patch before I lost interest, partly because it was pretty much the first golang I had tried writing. It was fun working out the above details, though.
Offering your public key only allows them to identify the key and prove you have it. There is no security concern in sending this to an untrusted server.
I think you may want to clear the environment (e.g., of `SSH_AUTH_SOCK`) as well as isolate in a PID namespace as well. I also reflexively `--as-pid-1 --die-with-parent`.
(The `bwrap` manpage says “you are unlikely to use it directly from the commandline,” yet I use it like this all the time. If you do, too, then we should be friends!)
Honestly the only thing that you need is -a (and only if you made the bad choice to do agent forwarding by default). Sending your pubkey (and a signature, because the server pretends to accept your pubkey for some reason?) isn't a security risk and you're (in theory) going to be providing much more identifying information in the form of your CC...
(And as the siblings mentioned this won't work to prevent your key from being sent if you're using an agent)
SSH Agent Forwarding does not happen by default. You need to include the -A option in your ssh command, unless maybe you've enabled it globally in your ~/.ssh/config file.
They can't get your private keys, but they could "perform operations on the keys that enable them to authenticate using the identities loaded into the agent" (quoting the man page). This would also only be possible while you are connected.
What can also help is specifying the right options right in ~/.ssh/config for certain hosts and domains: E.g. do "ForwardAgent no" globally, use a "Match *.my-trustworthy-company-domain.com" block and add "ForwardAgent yes" there.
Also very good for other options that are useful but problematic when used with untrustworthy target hosts, like ForwardX11, GSSAPIAuthentication, weaker *Algorithms (e.g. for those old Cisco boxes with no updates and similar crap).
Another neat trick is just using a ""Match *.my-trustworthy-company-domain.com" block" with an "IdentityFile ~/.ssh/secret-company-internal-key" directive. That key will then be used for those company-internal things, but not for any others, if you don't add it to the agent.
Whenever possible, yes, but AIUI it's not always possible; the one use case for which I believe full-on forwarding is required is using your personal credentials to transfer data between two remote servers (ex. rsync directly between servers). If there's a way to do that I would actually much appreciate somebody telling me, but I have looked and not found a way.
Sorry, English is not my native language. I know I sometimes sound strange because most of my use of the language is around the internet and at work, not that much casual "normal" conversation.
I think that person was talking about having had 4 out of 5 squares in a line on their bingo card already, and stumbling across "baby+bathwater" earned them bingo. The card is metaphorical though... more of a mental buffer that just overflowed.
Mine too, and I think the post is fine also, but I have some idea of what that person was talking about. For a while, in some corporate environments, it was a recurring phenomenon to hear someone dismiss an urge to be cautious by saying "You're throwing out the baby with the bathwater."
So I can see where someone might count it toward buzzword bingo. But this post also offered an alternate solution when saying "baby+bathwater", so the bingo caller should refuse to score this one.
Your English is fine. That person was violating HN rules about snark (“Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.”)
Learned that rule the hard way. It’s crucial to the success of HN and I am grateful dang corrected me.
I don't see a rule where joking is prohibited. People sure love their buzzwords though. Must bring them a feeling of synergy in these unprecedented times :)
Glad that at least a few people above got the joke
AFAIK, this doesn't solve the SSH agent problem - the problem is the agent has access to all of those keys regardless of the host you connect to.
So forwarding your SSH agent means an administrator of the system you're connected to could use any of those host keys loaded in the agent to connect to their associated machine.
Depending on what it's serving, and how up to date it is, and who else is on that network and can access the server, and who else can come into that same room when you're not there, and from where you get the software that you install on that server... it might be less trustworthy than you think.
Just to be clear, ssh agent forwarding is disabled by default and enabling it is always a hazard when connecting to machines that others also have access to.
Is it not standard practice to make different keys for different important services?
I have a private key for my prod server, a private key for GitHub, and a private junk key for authenticating to misc stuff. I can discard any without affecting anything else that's important.
If I authenticated with my junk key, would my other keys still be at risk?
> If I authenticated with my junk key, would my other keys still be at risk?
Yes, if you authenticate with your junk key (or no key), and SSH agent forwarding is enabled, you are still at risk. It lets the remote machine login to any server with any keys that are on your local SSH agent. Parent's link shows how this can be abused.
Fortunately, it's disabled by default, at least on newer versions.
But if you do want to break up your keys more, make sure you specify IdentityFile and Identities Only in the per host definitions in your ssh config.
By default assuming you use an ssh agent (no forwarding) with multiple keys and a default ssh config, the behavior is to just try to auth with every key in order.
So if you're worried about the ssh server identifying you, you're still exposing yourself. I don't think this is much of a concern but worth noting.
Slightly more important: you're wasting time during the initial connection to fail authentication a few times. This can matter more with higher latency
Even more important: sshd has a configurable number of times a client is allowed to fail authentication in a session attempt. If you have too many other keys in your agent you will just fail to auth before it tries the key that is actually valid for that host.
The only reason/benefit for using different keys is to prevent someone from correlating your identity across different services... if you're worried about that go ham
I take it you mean disable ssh agent forwarding — the agent itself is fine. You should never forward your ssh agent to a box you don’t trust as much as your own.
Is it "yes" by default? If so, that seems insane given what the op said about it. But other comments say it's "no" by default. If it's "no" by default, why are people alarming us by bringing this up? And why for terminal.shop in particular?
Using discoverable and non-discoverable keys via FIDO security keys will require PIN + physical confirmation, or just physical confirmation, by default if anyone tries to use your agent's keys.
If you want to use SSH forwarding reasonably safely, use a yubikey for ssh so you have to tap once for each hop. Now a MITM can't use your key for more hops without you physically consenting to each one.
That's terrifying. I don't understand why the design requires Forwarding to work without more explicit consent from the client at use time. (That is, when the middle tier wants to make a connection, it should forward an encrypted challenge from the server that can only be decrypted, answered, and re-encrypted by the original ssh keyholder on the client, similar to how, you know, ssh itself works over untrusted routers.
I can't test this due to the product being out of stock, but I wonder what their approach to PCI compliance is.
Processing credit card data has a high compliance burden if you're unwilling to use a secure widget made by an already-authorized provider like Stripe. That's for a good reason, most web and mobile apps are designed such that their backend servers never see your full credit card number and CVV. You can't do this over SSH.
I also wonder whether you could even do this if you had to handle PSD2 2-factor authentication (AKA 3d Secure), which is a requirement for all EU-based companies. This is usually implemented by displaying an embed from your bank inside an iframe. The embed usually asks you to authenticate in your banking app or enter a code that you get via SMS.
You can take the easy way out of course and make the payment form a web page and direct the user to it with an URL and/or a Unicode-art rendition of a QR code.
They mention in the faq that they use Stripe - https://www.terminal.shop/faq. Stripe does offer integrations that are not natively using their widgets. Ultimately, the PII data is stored at Stripe.
PS: I work at Stripe but I don't really work on the PCI compliant part of the company.
The fact that the card number data is stored at Stripe doesn't matter that much. As parent commenter says, the card numbers are still visible on terminal.shop's network because it all goes over their SSH connection.
For most websites that use the Stripe widget, the website owner can never see the full card number, because the credit card number entry fields are iframed in on the page. That means website owners in this scenario are PCI compliant just by filling out PCI SAQ A (self assessment questionnaire A), which is for "Card-not-present Merchants, All Cardholder Data Functions Fully Outsourced": https://listings.pcisecuritystandards.org/documents/SAQ_A_v3...
But that questionnaire is only for merchants where "Your company does not electronically store, process, or transmit any cardholder data on your
systems or premises, but relies entirely on a third party(s) to handle all these functions;" For e-commerce merchants who CAN see the card number, they need to use SAQ D, https://listings.pcisecuritystandards.org/documents/SAQ_D_v3.... This includes additional requirements and I believe stuff like a pen test to be PCI compliant.
it's been a while since I did the full pci compliance rigamarole, but I don't recall it being that difficult. you basically just answer a bunch of questions correctly about how you are transmitting and storing the data using sufficient encryption and then they run some automated pen tests on your site and then you are done.
>run some automated pen tests on your site and then you are done
Haha you are obviously choosing to hide some pain away from your memories.
I agree that you run automated pen tests, but then securing up all networks servers with the results of those pentests can be incredibly time consuming and awkward.
I suppose on a very complex system, that could be a big deal. But I think the last site I did it on was running on AWS so all ports were closed unless I specifically opened them for a specific purpose and it was just a few tweaks I had to make to pass. I normally only have 80 and 443 open to the outside world.
To be clear, that is exactly what the PCI SAQ A-EP questionnaire covers. It basically says "You don't access any cardholder data, but you own the page that hosts/redirects to the third party processor (like Stripe)." So the questions in the SAQ A-EP are about ensuring that your page has enough basic security (at least as can be asked in a questionnaire) to prevent hijacking, whereby a nefarious script (through an XSS vulnerability for example) sends them to a site to phish their cc details. Note that a decent content security policy on your website can prevent most of these types of problems.
That wouldn't help, at least with my bank in the UK, the iframe just shows a message to open the mobile app to approve the payment. The payment details are then shown in the app, you don't interact with the page in the iframe at all.
But that would still require an eagle-eyed consumer, which (coming from experience working in the fintech space) is quite rare.. I.e., you may know the iframe is supposed to just ask you to open your mobile app, but I think the vast, vast majority of users wouldn't think twice if that iframe had been hijacked and instead asked them to enter their credit card information directly.
Interestingly Stripe started life as /dev/payments and I seem to remember the first iteration was an agent on your server that literally processed card payments when you wrote the details to /dev/payments
Not just EU companies. Also EU customers. I cannot use my cards in a Card-Not-Present transaction that does not support 3D Secure. This obviously isn't a concern for them yet since they only ship to the US, but it might become one.
In the past one of my banks required me to put in a One-Time Password on the frame I'm shown. While it's different right now, you do need to show that page in the general case. That would really break the immersion of their process :/
I remember seeing a 3D Secure screen in some app that didn't use a webview but rendered the form as native controls. It worked with Estonian LHV at least (I think?). If that can be done with Stripe, they could render the form as a TUI.
And if everything fails, they can just render the 3DS page in the terminal! (e. g. using Browsh [1]) Although I'm not sure if that would be compliant with the regulations.
I think that a better way (which is protocol-independent, and does not require a web browser, or even necessarily an internet connection), would be a kind of payment specification which is placed inside of a order file. This payment specification is encrypted and digitally signed and can be processed by the bank or credit card company or whatever is appropriate; it includes the sender and recipient, as well as the amount of money to be transferred (so that they cannot steal additional money), and possibly a hash of the order form. A payment may also be made by payphones or by prepaid phone cards (even if you do not have a bank account nor a credit card), in which case you may be given a temporary single-use key which can be used with this payment specification data; if you do not do this, then you can use the credit card instead.
I was asking myself the same thing while watching the live stream where they somehat explained how it works.
It's still not clear to me if they are compliant.
To make it work like in the browser it would require some sort of SSH multiplexing where your client is connected to both the shop and Stripe's SSH server and you enter your card data into a terminal region that is being rendered by stripe's ssh server. And then the triangle is completed by Stripe notifying the shop that the payment is ok.
I don't know if this is sarcasm or not, but in Poland we have BLIK and it is amazing. Paying online is as simple as entering a 6 digit code from the app and confirming transaction in the app. Afaik every major bank supports it too
Even if you're using a third party provider that handles both credit card entry and processing, you need to comply with some subset of the PCI/DSS requirements.
In the case of terminal.shop it's not even true, since they can see the credit card number on their side, even if all they do is to forward that number to Stripe and forget about it.
For small and medium-sized merchants, PCI/DSS classifies different types of handling through the concept of which SAQ (Self-Assessment Questionnaire) you have to fill in. Different SAQ have different subset of requirements that you need to fulfill. For e-commerce use cases, there are generally 3 relevant SAQs, in order of strictness:
- SAQ A: Applicable when the merchant redirects payment requests to the payment processor's page or shows an iframe that is hosted by the processor. This is the level required for Stripe Checkout or Stripe Elements.
- SAQ A-EP: Applicable when the merchant handles input on the browser, but sends the data directly to the processor without letting it pass through the merchant's server. This is equivalent to the classic Stripe.js.
- SAQ D: Applicable when the card data is transmitted, stored or processed on the merchant's own server, even if the merchant just receives the card number and passes that on to the payment provider. Stripe calls this type of usage "Direct API Integration" [1].
The level of compliance required for terminal.shop should be SAQ-D for Merchants, which is quite onerous. It covers almost all of the full set of PCI/DSS requirements.
But even if a merchant just uses Stripe.js, the PCI SSC still cares about the possibility of an attacker siphoning card data from the merchant's site through an XSS vulnerability.
And even if the merchant is using an iframe or a redirect (with something like Stripe Checkout or Stripe Elements) there is still the possibility of hard-to-detect phishing, where an attacker could replace the iframe or redirect target with their own site, made to look exactly like Stripe.
I think the important element is that terminal.shop's use case (likely SAQ D, likely level 4 or level 3 volumes) allows them to comply with relatively minimal expense and complexity.
Sure, there would be a non-zero time investment required to implement and ensure actual compliance with what is being attested, but it's quite doable for a person or small group of folks with a mix of SDE skills, SRE-like skills, and PCI-DSS experience.
The burden of PCI compliance is a lot lighter than you might think. You basically just have to fill out a bunch of forms, there's no inspection or anything.
No I'm not a manager, I'm a programmer. I haven't personally had to fill out the forms, we have a guy for that. Actually that's not his main job, but he used to work as a paralegal so he got volunteered for it.
A lot of people don't know that before Amazon started, there was a company out of Portland, OR called Bookstacks selling books via a telnet interface. In the early days, Bezos was quite worried about their potential to get "there" first (wherever "there" was going to be). It was a fairly cool interface, at least for 1994.
[ EDIT: worried to the point that we actually implemented a telnet version of the store in parallel with the http/html one for a few months before abandoning it ]
I remember ordering a CD via CDNow and a very rudimentary SMS interface on my phone around 1996. It took about 10 minutes to go through the entire process, but I did it while at the movies with my wife, waiting for the previews to start and we both thought it was just SO advanced.
Even back in 2010 lots of sites were http, like Facebook, & there was FireSheep which would snoop on public wifi for people logging into sites over HTTP
In 1994? Most of the internet was unencrypted, and it wasn't very commercial yet. https had just been invented, and ssh was a year away. There was no wifi, everything was dial-up unless you were at a university or something, and snooping just wasn't all that big a risk.
I can only talk from personal experience I did not trust most online payments around the turn of the millennium, but I did order quite a few things online. I usually payed either by collect on delivery or by invoice like regular good old fashioned mail-order, or by the early 00s VISA had something called e-card or similar, where you could generate a temporary one time use CC via a Java applet, this card was only valid for a day and could only be charged by a pre-determined amount, making the risk very low.
We were aware of this in the earliest days of amzn, and included a phone-in payment option to try to deal with this reluctance. It was rarely, rarely used.
hey! i'm one of the people who worked on this, we actually launched a few days ago and sold out quite quickly - we'll remove the email capture so you can poke around
we'll be back in a few weeks with proper inventory and fulfillment
we'll also be opensourcing the project and i can answer any questions people have about this
This joke is a clever play on words that merges elements of computer programming and coffee culture. Let's break it down:
New startup sells coffee through SSH: SSH stands for Secure Shell, which is a network protocol that allows for secure communication between two computers. In this context, the joke suggests that this new startup is selling coffee through a secure connection, presumably online.
Is it /usr/locally grown and single .'ed?: This part of the joke is a play on the directory structure in Unix-like operating systems, where /usr typically contains user-related programs and data. "Locally grown" suggests that the coffee is sourced locally, and "single .'ed" is a wordplay on "single origin," a term used in coffee culture to denote coffee that comes from a single geographic origin. The /usr/locally grown part humorously combines Unix directory structure with the concept of coffee sourcing.
How quickly can they mv it to my ~?: Here, "mv" is a command in Unix systems used to move files or directories, and "~" represents the user's home directory. So, "mv it to my ~" is a playful way of asking how quickly they can deliver the coffee to the customer's home. It's also a pun on the idea of moving the coffee to the user's home directory.
I'm curious how they built this. It's SSH but the IP address is Cloudflare's edge network. It could be using CF Tunnel to transparently route all the SSH sessions to some serving infrastructure, but I didn't know you could publicly serve arbitrary TCP ports like that.
Building it in serverless fashion on CF Workers would be ideal for scalability, but those don't accept incoming TCP connections.
Cloudflare Tunnels only open HTTP/S to the internet, you'll need their client to reach the other protocols. More likely that this is Cloudflare Spectrum.
Some protocols do not support virtual hosting; apparently this includes SSH.
It would be possible to support other protocols with a single IP address (either because they are running on the same computer, or for any other reason) if they support virtual hosting.
Of the "small web" protocols: Gopher and Nex do not support virtual hosting; Gemini, Spartan, and Scorpion do support virtual hosting. (Note that Scorpion protocol also has a type I request for interactive use.)
NNTP does not support virtual hosting although depending on what you are doing, it might not be necessary, although all of the newsgroups will always be available regardless of what host name you use (which requires that distinct newsgroups do not have the same names). This is also true of IRC and SMTP.
However, if you are connecting with TLS then it is possible to use SNI to specify the host name, even if the underlying protocol does not implement it.
(This will be possible without the client requiring special software, if the protocol is one that supports virtual hosting. There may be others that I have not mentioned above, too.)
┌──────────┬────────┬─────────┬───────┬────────────────────┐
│ terminal │ s shop │ a about │ f faq │ c checkout $ 0 [0] │
└──────────┴────────┴─────────┴───────┴────────────────────┘
nil blend coffee
whole bean | medium roast | 12oz
$25
Dive into the rich taste of Nil, our delicious semi-sweet
coffee with notes of chocolate, peanut butter, and a hint
of fig. Born in the lush expanses of Fazenda Rainha, a
280-hectare coffee kingdom nestled in Brazil's Vale da
Grama. This isn't just any land; it's a legendary
volcanic valley, perfectly poised on the mystical borders
between São Paulo State and Minas Gerais. On the edge of
the Mogiana realm, Fazenda Rainha reigns supreme, a true
coffee royalty crafting your next unforgettable cup.
sold out!
────────────────────────────────────────────────────────────
+ add item - remove item c checkout ctrl+c exit
ELisp and Emacs UI tools under the TTY version it's close.
Also, check gopher and gopher://magical.fish under Lynx or Sacc.
The news section it's pretty huge for what you can get with
very, very little bandwidth.
gopher://midnight.pub and gopher:/sdf.org are fun too.
And, OFC, the tilde/pubnix concept. SDF it's awesome.
I love the idea of TUIs, but I honestly don't have a lot of experience with them. There's a lovely Go library called Wish that I keep looking for reasons to use.
https://github.com/charmbracelet/wish
charm bracelet has some really great projects and my obsession for TUI interfaces is why I'm learning Go so that I can use one of their libraries in a peoject
For DOS TUI, the standard was https://en.wikipedia.org/wiki/IBM_Common_User_Access: Shift+Delete to cut, Ctrl+Insert to copy, Shift+Insert to paste. These worked in DOS utilities like EDIT.COM, QBASIC.EXE and HELP.EXE, in all Turbo Vision apps including Borland Pascal and Borland C++ IDEs, in Visual Basic and Visual FoxPro for DOS, and they still work today in any Windows app that doesn't try to play silly tricks with its UI by doing its own text input.
Shift+Insert has worked for decades in the XTerms I've used. It's bound in my muscle memory and is a source of frustration, for me, when attempting to use non-X Widows GUIs or odd-ball "terminals"/programs/foo.
The real power of the internet all along in my opinion was networked databases. Everything else is fluff and not a particularly great use of resources.
Command line dominates in quick flexibility. But is awful when it comes to discoverability. Most people can't even find the turn off ads button in windows 11. And people hate that. So what hope do they have at a terminal.
To be fair, would the button isn't hidden away too badly, most people have no reason to go into settings for anything. They go through the wizard at the beginning (if that) to do first-time setup, then when they decide they don't like something they just deal with it or complain incessantly until someone fixes it for them.
Someone complained to me a while back about the size of icons on the windows desktop being too small - I told them they can hold Ctrl and scroll the mouse wheel to change the zoom level. They've complained about the same thing a couple times since, and so far as I can tell have made no effort to fix it.
> # use the command below to order your delicious 12oz bag of Nil Blend coffee
> ssh terminal.shop
Oops, I thought I was supposed to enter it directly into the prompt on the webpage. The styling makes it look like an interactive console, I figured they included an embedded javascript SSH client for users who might not have one.
Reminded me of Hacker Scripts, specifically `fucking-coffee`:
> this one waits exactly 17 seconds (!), then opens a telnet session to our coffee-machine (we had no frikin idea the coffee machine is on the network, runs linux and has a TCP socket up and running) and sends something like `sys brew`. Turns out this thing starts brewing a mid-sized half-caf latte and waits another 24 (!) seconds before pouring it into a cup. The timing is exactly how long it takes to walk to the machine from the dudes desk.
Before a bunch of you run off and make more of these “because it’s cool”, they’ll likely lose access to stripe once stripes security team pay attention and realize that this can be trivially man in the middled and doesn’t actually offer the equivalent protection to https.
They give you the ed25519 host key to insert into your known_hosts file on their homepage, which itself is served over TLS with all of the protections you describe in your article. They could go into more detail on being careful with not falling into the tofu trap perhaps, but I don't see that there's an inherent PCI-critical problem here. ssh tells you who, cryptographically, you're connecting to.
If I mess with my DNS and point it at your "little demo", this happens:
$ ssh foo@terminal.shop
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Anyone ignoring a big scary warning like that probably isn't going to brew the coffee properly anyway.
And guess what? My browser lets me bypass HTTPS warnings too! Yes, even when HSTS is enabled I can take steps to bypass the warning.
I would blame this one on DDG, actually. PSA is an incredibly common acronym for public service announcement. Wherever DDG sources acronyms for might also be assuming people just know it. Try wiktionary or Wikipedia disambiguation pages for acronyms when they don't show up in search, I can often find them there.
Sorry to see this downvoted, I think it's a common courtesy to spell out acronyms on first use, no matter how widely understood one believes them to be.
I think that's because most people consider this requires unjustified. Do you think similarly about expanding acronyms like SSH, CLI, HTTP, HN, FYI, USD, US, EU, PKI? Why/why not?
The Everquests certainly seem dated today, but for their time, they were pretty neat! The gameplay was simple (especially by today's standards), but it was a pretty unforgiving game that required a lot of teamwork. It was the social aspect that kept most people playing, I think, especially in guilds.
I remember a lot of the playerbase kept asking for significant changes to make the game less grindy and hardcore, but the main game designer would always push back and reiterate The Vision™ (in their words) and stick to their plans. Not only did they not ask for feedback, they would actively fight back against it and reinforce their stance. Well, they must've done something right... 25 years later, EQ is still alive, celebrating its anniversary, and making new expansions (after several sets of publisher/developer changes, though).
If not for EQ, we wouldn't have had World of Warcraft and all the other MMOs. But today's MMOs have all become basically "massively singleplayer" in that grouping is rare outside of guilds and limited end-game raids, with bots and boosters of various sorts taking the place of what used to require multiple real people (AI really IS ruining everything!)
The social aspect has been heavily deemphasized nowadays (Diablo and Destiny don't even have global chats anymore) and you mostly just see the ghosts of people doing their own things with no real need to interact with them anymore. Too bad =/
Showing off /pizza or other fun commands (emotes, music, crafting, etc.) was a big part of the old-school experience. These days there are still some semi-social MMOs (New World has an awesome group music jamming system, where multiple people can get together and jam like Rock Band/Guitar Hero: https://www.youtube.com/watch?v=ggWZJNnaLNU)... but sadly no more in-game pizza that I know of.
To cost them a lot of money for all those pizzas. And to cost the pizza shop money if they can’t collect payment for the pizzas. And to cause general grief and misery, as trolls are wont to do :(
AFAIK the ol’ unlimited free pizza by killing the thread trick no longer works. It sure was nice while it lasted, especially on platforms that easily let you kill a thread id, even kids could do it.
Remember how on BeOS there was a GUI for it? Great for unfreezing a crashed app that had state you wanted to try to recover or free leaked pizza.
Now worker threads spawned for delivery hold a lock preventing new pizza being placed in the oven for that address, which is not released until the add payment callback is successful. Destroy the only thread holding the lock, and pizza orders just queue up forever. :(
> Demonstrating a deep understanding of what its computer-gaming audience, Sony has built the ability to order pizza into its latest online multiplayer game.
NBC's command of language might not be good, but it turns out it is consistent.
>is ordering via ssh secure?# you bet it is. arguably more secure than your browser. ssh incorporates encryption and authentication via a process called public key cryptography. if that doesn’t sound secure we don’t know what does.
Strong disagree. The encryption is the easy part, the hard part is the symmetric key exchange. And PKI used by browsers is much more robust for this usecase then TOFU model of ssh. Of course the proper way to fix this is checking the ssh key fingerprint, but almost nobody does this.
So unless you mean to exclusively sell coffee to users who don't have a white terminal background, you may want to consider your color scheme. I was missing the white text.
(I know this is considered an atrocity by some, but I happen to not really care enough about my terminal color to change the default)
Is there an environment variable defined for specifying if you want light or dark colours? If so, then it would help with local programs, and also with remote programs (such as this one) if you add a SendEnv command into the SSH configuration file to specify that SSH should use this environment variable.
Some of the older still-available services are listed below
SSH:
ascii.theater was mentioned here, so was mapscii.me
There's a bunch of games at https://overthewire.org/wargames/ (and there's likely still dozens of other small muds running over telnet as well)
chat.shazow.net is a chat server
Non-ssh (the games mostly require registration):
`curl wttr.in` for weather
`finger help@graph.no` for weather
`cat | nc termbin.com 9999` for a pastebin
`telnet telehack.com`
`telnet freechess.org`
`telnet gt.gamingmuseum.com`
`telnet fibs.com 4321` to pay backgammon
There's used to be Nyan cat through telnet, which I'd hacked into running on ssh but AFAICT there's no longer any servers around (my own server is no longer around either) https://nyancat.dakko.us
Love the idea! Congratulations (?) on being sold out!
My constructive feedback is that the text contrast is so low (in iTerm2 anyway) I can barely read anything. I thought only web pages had that problem, but I guess sufficiently sophisticated TUI apps have designer color problems too! What's next, incredibly tiny terminal fonts? (jk, designers...sort of)
It is SMS based. Each week they offer a different bean from a different roaster, and you reply with the number of bags you want. I've discovered a number of great roasters this way.
There is never a good reason for cookie banners, by definition.
The rule is that if you have a good reason for your cookies (i.e., basically one that isn't user-hostile), you have nothing to worry about and don't need a cookie banner.
It's only when you engage in user-hostile practices, such as tracking, that you need to ask for consent.
I'm being sightly snarky, but that's really the essence of it.
But beware the predatory lawyers who will come after you for ostensible violations of California’s Invasion of Privacy Act, California Penal Code section 630, et seq. (“CIPA”).
One company I work with received multiple arbitration demands (claimed "privacy" damages in excess of $25000 each, helpfully offered to settle for $5000 each!). And this company didn't even set any cookies or run any 3P tracking on their site!
Their (famous-you-know-them, expensive, California-based) lawyers said "yes, we are seeing this more and more. We can fight and win for $200K, or you can pay the $50K of claims outstanding and add a banner to your site".
Does the law even matter in this case? If the idea was to make you convinced you'd spend $200k to win a bogus case, you can be sued for literally anything...
This is true, but CIPA is the law that is being exploited for its ambiguous applicability. There are lawyers out there actively targeting companies who legitimately believe they do not need a cookie banner.
They seek out customers of the company ("Are you now, or have you been, a customer of X? You may be the victim of Y/eligible for legal settlement Z/etc.") They may even identify the corporate targets, and recruit new customers for their purpose.
And the way to avoid the issue completely is to add a stupid, superfluous, cookie banner. (Which, in the height of absurdity, requires adding a cookie).
It was a painful and semi-expensive lesson for this small company. And their expensive/prominent lawyers say they are seeing the problem increasing. (I asked why they didn't take the time to warn their clients, but did not get a satisfactory answer).
So it's worth a thought and a note when the idea of not needing a cookie banner comes up.
I believe that you need to inform users about the use of strictly necessary cookies as well. You just don't have to ask for consent before adding them.
> While it is not required to obtain consent for these cookies, what they do and why they are necessary should be explained to the user.
There's nothing about a cookie banner in GDPR, it's just the most convenient (and, often, laziest) solution to the question of how to confidently say you've told users something.
Lol, the subset of people buying coffee via ssh and shopping elsewhere via ssh is going to be insanely small, they can probably already more or less track you.
Additionally, you're probably giving a shipping address and using a card number of some sort.
Its extremely difficult to shop anonymously online for physical goods.
> Lol, the subset of people buying coffee via ssh and shopping elsewhere via ssh is going to be insanely small
Yeah, nerds. In the FAQ there is the question "What is SSH", and the answer is - "If you have to ask then it's not for you".
Edit: Seems the FAQ may have been updated or this simply wasn't part of the online version, https://imgur.com/a/igjGCFM here is a section of the FAQ sent to my email.
if you are aware of other stores-over-ssh, I’d genuinely love to hear about them because this one is so fun. Or even not-stores that are reachable via ssh. Any MUDs still going?
Oh, it seems to rickroll people with a referrer from this site :)
Copy-paste or manually type the URL to get around that!
Edit: They seem to be redirecting with a 301 permanent HTTP response, which seems slightly obnoxious since your browser might cache it. I can't visit the site anymore from the browser I'm using here, so maybe try a different one or incognito mode.
Be careful. If you have California customers you need to worry about California’s Invasion of Privacy Act, California Penal Code section 630, et seq. (“CIPA”).
It's not clear that it applies to the web! But predatory lawyers will come after you for it, if you are big enough and don't have a cookie banner.
They'd only need a cookie banner if they somehow could put a cookie on your machine using SSH.
Depending on how they're using any personal data you provide, they likely wouldn't need consent: for instance, if they use the personal data you provide to ship you your order, they don't need to ask (you supplied your information for the express purpose of placing an order, after all). However, if they want to do more with that data, they'd need consent.
https://www.clockwork.com/insights/ssh-agent-hijacking/ (SSH Agent Hijacking)