[lucb1e]

> isn't any more secure

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.

[rndgermandude]

>Doing things in the browser shows customers that it's done properly and verifiably.

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.

[lucb1e]

> 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?

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.

[lev99]

> 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?

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.