It’s interesting to note that some research “discovered thousands of vulnerabilities in 693 banking apps, which indicates these apps are not as secure as we expected.”

deleted by creator

That’s interesting. It sounds like browsers could be designed smarter. I get “403 Forbidden” chronically in the normal course of web browsing. In principle if a server is going to refuse to serve me, then I want to give the server as little as possible. Shouldn’t Tor browser attempt to reach the landing page of the host first just to check the headers for a 403, then if no 403 proceed to the full URL?

#dataMinimization

I suppose you could even say text-based clients are at a disadvantage because when we opt to render the HTML graphically, a full-blown browser is launched which is likely less hardened than something like whatever profile and engine Thunderbird embeds.

In my case I created a firejailed browser with --net=none so I could hit a certain key binding to launch the neutered browser to render an HTML attachment in a forced-offline context— but I was too fucking lazy to dig up what keys I bound to that which is why I (almost?) got burnt.

Indeed, but what what was logged? Suppose the tracker pixel is something like:

https://www.website.com/uniqueDirForTracking/b1946ac92492d2347c6235b4d2611184.gif

and I visit that URL from Tor. The server at www.website.com can easily log the (useless) Tor IP and timestamp, but does it log the b1946ac92492d2347c6235b4d2611184? I’m not an expert on this which is why I am asking, but with my rough understanding I suspect that transaction might break down to multiple steps:

1. a TLS negotiation just with the www.website.com host
2. if successful, a session cookie may or may not be sent.
3. the “document” (“image”) is fetched by an HTTPGET req (using the cookie, if given).

If the negotiation is blocked by the firewall, does the server ever even see the request for b1946ac92492d2347c6235b4d2611184.gif?

I don’t think so because it would have to involve deliberate deception. (source)

The first customer to enounter the problem could send a registered letter to the vendor and then a second customer could perhaps later use the 1st customer’s letter to prove the vendor knew about the defect. The vendor would then perhaps try to argue that they did not know a particular customer was vulnerable to the defect. I don’t imagine that the debate could unfold in a chargeback dispute. A bank that is less consumer friendly than what you have in the US and UK would probably say it’s not obvious fraud.

Note as well fraud legally requires 5 components to all be present. I think 3 of them are: deception, someone must profit, someone must be damaged, … and I forgot the other two components.

(edit) I should add that when banks refer to “fraud” they may not be using the legal definition. I think it’s simpler for banks. They might ask “do you recognize the charge?” If yes, they likely don’t treat it as fraud. Of course I am speaking speculatively. I’ve not worked in a bank and a banker might have better answers.

That would indeed be the practical answer assuming he has a credit card with those protections. Credit cards not issued in the US or UK often lack chargeback protections in non-fraud situations.

Note as well that even in the US the chargeback merely moves the money back to the consumer and does not affect legal obligations. If AXS were motivated, they could sue the customer in that case and likely point to a contract that indemnifies them from software defects and incompatibilities.

I think most banks have a threshold where they eat the loss. I did a chargeback once for around ~$20 or 30. Then I found out that the bank’s cost of investigating the chargeback exceeds something like $50, so the bank just takes the hit instead of the merchant. I found that a bit disturbing because a malicious or reckless merchant has no risk on small transactions. But in the case at hand for $200, the bank would likely clawback the money from AXS.

!smartphone_required@lemmy.sdf.org captures these kinds of cases. @FoxyFerengi@lemm.ee, if you know of any situations where your prof faced difficulty for not having a smartphone, consider posting about it there.