I suppose it's a question of your threat model. Do you trust the website to not do that? Given that FBI is willing to take over and continue operating websites that distribute child porn, the default answer to that question ought to be no. You have no way of knowing if someone else has taken a server over.

Maybe a browser extension would be a good way to do PGP encryption for websites, keeping the key out of their reach but allowing a one-click encryption right in the browser.

Less kindly, one could argue that Tor devs want to increase the anonymity set, in order to better hide US government users. That was, after all, one reason why Tor's initial Navy funders agreed with open release of the software.

There are similar issues around other Tor vulnerabilities. Such as how easy it is for apps to bypass Tor. Which has allowed the FBI's phone-home malware to pwn users.

https://blog.torproject.org/tor-heart-whonix

https://blog.torproject.org/tails-36-out

But I fully agree the main site should make the risks of TBB clearer and promote Whonix/similar.

Encrypting a confidential message for another party is a public key operation. It’s the fact that the plaintext was sent to a remote server that’s problematic.

It's definitely more secure. But depending on your level of paranoia, yeah, it's often not enough.

Doing things in the browser shows customers that it's done properly and verifiably. It also makes attack way more public than being able to do it quietly server-side. I wish people applied security client-side more often.

I mean, if the server is compromised, you're fucked, regardless of whether you applied your crypto in js or on the server. But if it is done client-side, at least there's a chance that you notice you're fucked.

So customers are skilled enough to check the (webpacked together with other stuff and minified) JS code running in their browser before they run it? Even if this was actually feasible, it would be still orders of magnitude easier to just do GPG in a terminal.

And don't forget that, according to the article, we're talking about a crowd where even a lot of the long-standing big sellers are not smart enough to remove GPS meta-data from their product pictures.

>It also makes attack way more public.

You can still serve different (malicious) JS to a select bunch of your users who are least likely to notice and kinda spearfish with that. E.g. it's entirely feasible to just bug new first customers you fingerprinted as using default Tor Browser installs (most likelihood they are tech newbies too).

Even if users make sure the code they run is verified, how do users make sure the public key they are encrypting with is the public key of the party they intent and not a key the (rogue/police) operators of the website put there themselves, doing a good old active MITM key switcheroo? It's not like there is an independent web of trust in the realm of a tor drug market that you can check for that information. Even if the public keys of the big players (most of which would be sellers) are widely known, the key of Joe Newcustomer is not, so you can at least eavesdrop on communication directed to him by replacing his key with your own, look what the seller is writing and also at all those "Joe Newcustomer wrote: >" lines too, and nobody will ever notice until the police knocks on their doors.

Rather than posing the obvious as a question, yes, I am aware that the overwhelming majority of users will not be able to inspect it themselves. But there are also loads of people who are, and we also roam the internet.

And it's not about inspecting before it runs, it's about noticing weird changes before you typed your credentials. Currently it's a strange idea to open an element inspector before regular actions such as logging in, and indeed, it'd be quite the hassle. But if this were commonplace I imagine tools would jump up to aid in this for both experts and laymen. It isn't terribly hard to trace which pieces of code do something with the password field (such as reading out its value, and trace where the variable is used and copied to) and alert on changes to those. Upon such an alert, customers of a bank might wait a few days to see if there was a breach, and security experts of said bank might like to see the diff that the browser detected. Just a thought of what could be if security was applied client-side more often.

Checking code before it runs is possible. What is much easier is watching the network traffic on the web browser and examining it for sensitive material. It's an order of magnitude better to know that a security breach has _just_ happened than to find out much later, possibly when that information is being leveraged against you.

> spearfish

Almost all significant criminal activity leaves some trace. The buyer, by nature, has more trust in the seller because the buyer must pick up a package a specific location in a date range. The seller would be the most significant market players (spearfish targets), but give up less information in each transaction. The best way to attack would be watching for user mistakes (gps meta-data), social engineering, and zero days.

https://news.ycombinator.com/item?id=16554286

PGP-encryption server-side is meaningless, even if it was done client side, there's a MITM. Eve can replace public keys (though at the risk of exposing her MITM if people are double checking their own public keys listed on the site against their client side public keys)

>They tweaked a feature designed to automatically encrypt messages with users' PGP keys, so that it secretly logged each message's full text before encrypting it

Unless this is Wired's way of saying a MITM as described above.

It's not meaningless, it prevents past messages from being compromised by a future breach. Future messages are still compromised, but past messages are secure.

By your logic you could say that forward secrecy is meaningless. But yet security professionals recommend that you use a TLS key exchange with forward secrecy.