Slashdot Mirror

The complete reversal and over the top priase, doesn't at all smell like money changed hands.

Oh, money changed hands all right. But it didn't involve Tesla.

UBS (an investment company that has been consistently anti-Tesla) paid Munro Associates to perform the Model 3 teardown. Munro's initial impression of the Model 3 was prior to the teardown, and they rightfully focused on the car's poor fit and finish. But after completing the teardown and realizing just how inexpensive the car would be to manufacture, Munro had to "eat crow", and publicly, otherwise his company would look foolish and it would hurt his business in the long run.

But then some "unknown entity" sued Munro over his latest "Model 3 is insanely profitable" pronouncement. It's pretty clear to everybody that the unknown entity is UBS. This didn't fit in with their narrative on the Tesla Model 3. Shortly afterwards, UBS put out their own hastily-organized teardown analysis of the Tesla Model 3, stating that it is unprofitable. By that point, a second teardown analysis by a German firm confirmed Munro's finding that the Model 3 will be profitable.

One thing the article left out is how Zug will convert BC to SF. I would guess they want to do that immediately since they would not want to expose themselves to BC's volatility but rather ensure the expected revenues are matched by actual ones. Since it is a small trial the volatility wouldn't be enough to make much of a difference but large scale adoption of BC for payments would require them to address the volatility and conversion to SF issues.

Good question.
I would imagine they'll simply resort to a payment processor? And thus defer to them the gory details of handling the BTC-CHF conversion ?

- They use payment processors for handling credit cards anyway (Six Payment is wide speard in most physical shops in Switzerland, Datatrans is popular for on-line payments)

- There are a few payment processor that both can handle CHF *and* BTC (Random example among the bitcoin-oriented payment processors, Coinbase is available in Switzerland) (Another more classical example: Sum Up is a start-up for classical credit card payments, focussing on using Apps on smartphones/tablets a.k.a. mPOS - thus perfect for small businesses on the move like food-trucks - which is partnering in Switzerland with UBS - one of the three biggest swiss banks, that's some cred - and apparently they've started featuring bitcoin, using Bitpay behind the scene for the BTC processing)

- Nearly any shop that I know which handles BTC (random example: Humble Bundle) uses a payment processor and defers to them the handling of BTC, the shop it self only receives its local currentcy on the bank account, like with credit card processors.
The only exceptions are shops ultra specialised in bitcoin technology (e.g.: butterlfy labs, they price all their mining hardware directly in BTC)

It will be interesting to see if other cantons / cities get on the train as it leaves the station or merely get pulled along into it by Zug...

I see what you did here... :-D

How would you make an urgent purchase by phone? More than once, I've purchased an airline ticket over the phone while I was literally in a cab on my way to the airport, I'd be pretty pissed if my bank would not allow that.

The problem is the same feature that enables you to buy a plane ticket over the phone with a "card not present" type of transaction, would enable absolutely any fraudster to impersonate you and empty you account / buy up to the card's limit simply by using some number printed on the face of your card that the fraudster could even have just glanced over.
(Yes, there are insurances against that, but still somebody is going to need to pay the cost. In the end this cost is passed to the customer as transaction fees and/or monthly fee).

The way I've seen "card not present" type of transaction handled here in around Europe, is out of band confirmation.

- A few years ago, I've got contacted by SMS by my bank asking to confirm directly to them the transaction.
(This part I haven't encountered for the last few years, so I don't know if it still exists.
Though I doubt that it is still in use, because back then the standard identification protocol was answering a couple of question that any one can quickly answer by searching modern social networks)

- Nearly every single transaction of the "card not present" type nowadays happens *on-line*. So still likely to happen over the phone, except using the "smart" part of the functionality of the phone.
A very huge proportion of online transaction I've seen use 3-D Secure system, which is basically also an out-of-band confirmation: a new intermediate page (in the purchase flow) or a new tab is opened asking you to log-in and confirm the transaction.
This confirmation is NOT served by the web merchant (or the plane company in your case) server, but by the bank's webserver. (Clearly indicated in the URL, all transaction authenticated using an up-to-date https).
Only once you confirm on the bank's website does the transaction goes through at the merchant.
(A fraudster would not only need the numbers visible on your card, but would also need to be able to log into your bank's 3dsecure page).
All the plan ticket I've bought online have gone through a 3d secure confirmation (EasyJet, StarAlliance, a few others...). Though I didn't by them while in the cab, but well in advance.

It's not that dissimilar from the way PayPal is handled by merchant: at some point the webshop redirect to page hosted on https://paypal.com/ that asks you to log-in to confirm the transaction.

And let's be serious for a minute:
you're speaking about airlines. with the present security circus, you're at least in for 60 to 90 minutes of queue in front of the security check. It's not that you're going to miss your plane if you take 5 minute more to buy the ticket before getting into the cab.
And there's still plenty of time to purchase your plane ticket at the airport using proper on-line identification while waiting on the queue.

Since I don't have a chip reader in my phone, I don't see how I'd be able to make a mobile web purchase either.

Actually, you do.

Phones' NFC, and card reader/credit card's RFID can talk to each other.

Some european bank do use as a 2-factor to authenticate your online session: stick your RFID card to your phone's NFC antena (example)

There's no *technological* limitation to your smartphone acting as a payment terminal using a simple app, though the only example I've seen use a bluetooth enabled contact-chip reader instead of directly accessing the card over NFC.
(I suspect current certifications won't allow a smartphone app to input a pin and sign a transaction)

but one day you could probably pay simply by sticking your RFID card against the phone's NFC antena.

This device uses a time-dependant (be it iterative or time-synchronised) password. It requires no input from the bank it self. The device simply gives you a number, you type it into the log-in screen and you're logged in.
Once logged in, a hi-jacked browser could pretty much change the account information on-the-fly during a transfer (the browser screen says your transfering money to the merchant you're buying from, but secretly the trojans changes it on the fly, so the bank is actually ordered to transfer money to a criminal. See case 2 in TFA).

In Switzerland, UBS use a slightly different device.
That device is closer to the kind of stuff you see in a public-key infrastructure : you just type a number in, and an encoded version is spit out.
The log-in is slightly different : UBS gives you a challenge on the log-in screen, and you must respond with the encoded version of it.

Where it gets interesting is, as the device can encode any string, you can also use it to secure wire transfers :
instead of directly typing the account number of the merchang you're paying, you type the account into the device, and give the encoded version to the web-form (for each new recipient. Once a recipient account is known as "safe", you can also do it without encryption).
Case 2-type injection can't work : the torjan can't change the recipient on the fly because there's no merchant's account number to replace. In theory, the trojan should replace the encrypted merchant's account with an encrypted criminal account. But that's impossible because the encryption is done on a separate device which isn't accessible to the trojan*.

*: That would require a rather more elaborated (and therefore more prone to detection) case.
The trojan should initially simulate internally a couple of failed logins, where it requires the user to attempt to log using a challenge which is actually the criminal's account. Thus the trojan gains knowledge of the number encoded with the victim's key.
Then it proceed as in case 2, but instead injects the encrypted criminal account number it obtained during the fake failed log-in step.
Could work, but the first step will look highly suspicious to lots of users. And is easily subverted if the bank starts to ask encrypting random part of the recipient account instead of a fix part - the torjan doesn't know in advance which part it must encrypt during the fake-log-in.

When the first part of the authentication is done by a Greasemonkey script, keyloggers don't see that. Or do they?

This may sound like a joke, but in fact I do have one part of the authentication scripted in Greasemonkey. That gets me directly to the next step with some sort of challenge-response system involving a calculator-like gadget with my bank card inserted in it.

Of course, if your bank requires nothing else than an account number and a password which you have in a GM script, I would be glad to borrow your computer...

The systems I know are the ones of the swiss post (pdf) and of UBS (pdf). I do wonder if these can be attacked by such instant keloggers.

Ghah, got "continue editing" and "submit" buttons mixed up. Anyway, all rates are taken from http://www.ubs.com/1/ShowMedia/ubs_ch/wealth_mgmt_ch?contentId=103982&name=eng.pdf and http://www.economist.com/finance/displaystory.cfm?story_id=11793125

Even in the financial services industry, there's disagreement over what a "bank" is. Consider

• PayPal. Probably ought to be regulated as a bank, but is not.
• Western Union, a regulated money transfer service.
• ETrade Etrade is a brokerage house, but owns a bank on the side. Both operate under the "etrade.com" domain.
• Bank of America is a major bank which owns a brokerage house on the side, the reverse of ETrade.
• L. F Rothschild. Once one of the old-line banking houses of Europe, after about three mergers and breakups, they do offer financial services to the public, but they're not regulated as a bank.
• UBS Financial Services. In the US, they're a brokerage house, but in Switzerland, they're the Union Bank of Switzerland.
• Provident Credit Union A credit union performs the basic functions of a bank; it takes deposits and makes loans. But it's not a bank.
• Provident Funding, which sells mortgages, but doesn't take deposits. They're the tenth biggest lender in the US, but not a bank.
• Mellon Financial Corporation. They own banks, but are not, themselves, a bank.
• Stanbic Bank of Nigeria Are they real?

OK, who gets to be in ".bank"?

TFA says that the analyst works for UBS Securities. He's a stock analyst, same as any other, who produces analysis that his employer sells as a product. The point is that the analysis is used by investors to help them decide where to put their money.

In this case, the analysis is probably really good news for investors in the companies supplying the parts for the 360, since it indicates that at least some of them are working to capacity, and it's still pretty good news for MSFT (though the part about them taking a loss on each unit makes that a little screwy - hopefully the slow supply will help them gauge software sales so that they can make better decisions on future supply).

• knowing your account number
• knowing your personal, secret password
• knowing the current, one-time-pad TAN

• know your account number
• posess the chip card
• unlock the chip card with a PIN of your choosing (and 3 bad tries block the card forever)
• read a challenge off the login screen, and type it into the login device
• post back the response the login device generates

same bank
swiss vs us ebanking
UBS Swiss Ebanking
UBS US Ebanking
how ebanking works for me sorry but everyone who doesn't understand this should not be allowed to have ebanking .. not even a bank account
i don't know why you americans let yourself be fisted by corporations like this!!!
maybe you are all masochists :p

http://www.ubs.com/e/index/about/research/pcc/publ ications.html
(See PDFs on bottom of the page.)

It's quite extensive, and answers essential questions like "How long do you have to work to earn a Big Mac?" in different cities around the world.