<DocScrutinizer05>
Domain Status: renewPeriod -- HMMMM I wonder if that means what I think it does
<DocScrutinizer05>
anyway folks, until dos1 gets around to do sth about fixing this, http://78.47.150.252/ should still work
* kerio
doesn't believe in accessing websites with an ip address
<DocScrutinizer05>
I don't believe in single points of failure. Bus Factor is terrible in Neo900
* DocScrutinizer05
feels his flu cheering
b1101 has quit [Ping timeout: 250 seconds]
<DocScrutinizer05>
MonkeyofDoom: many thanks!
ddark has joined #neo900
<ddark>
pointed neo900.info to the server, till dos1 fixes the original domain, let's see who's quicker dos or godaddy's dns =)
<Wizzup>
neo900.org works here
* Wizzup
reads up and nods
<wpwrak>
(nfc) it's a bit sad but i'm not entirely surprise. after all, there may be very few real-life use cases for NFC on neo900. it's used a lot for payment and such, but that usually requires a proprietary "app" from the provider of that service, which we're rather unlikely to ever see on neo900 (unless it gets hacked)
<wpwrak>
there are a bunch of "open" uses, e.g., for BT pairing or advertizement, but they're more or less just gadgets
SylvieLorxu has joined #neo900
<DocScrutinizer05>
I still wonder how much hacking of apps it needs to make payment work on e.g. replicant
<mvaenskae>
it's a bit difficult trying to read the paper if it 404s :)
<mvaenskae>
sadly i had no time to read up anything the past weeks apart from exam-stuff >.>
<kerio>
freemangordon: of course not, linux is only for x64 servers and desktops
<freemangordon>
Pali: wasn't SMM code executed in some extended real mode?
<freemangordon>
where you can set more bits in CS than first 16?
<Pali>
freemangordon: red hat said that they are behind closed door with HP/AMD/Intel and when first arm server will be there in production all will have UEFI and ACPI
<DocScrutinizer05>
annoying sidenote: devuan chanop went mad and kickbanned me. So my support for devuan also dropped to ~ zilch
<Pali>
and then linux kernel will be forced either support those server or not
<freemangordon>
oh, so no more linux on embeded?
<kerio>
lol
<Pali>
they know that kernel devs are agains ACPI and other shits
<Pali>
so they cannot communicate with them about it
<kerio>
what's wrong with acpi? :o
<freemangordon>
kerio: you really?
<Pali>
~lart kerio
* infobot_
cuts off kerio's head with a halberd that could have been a little bit sharper
<freemangordon>
check the ACPI table on your PC and see all the "Microsoft..." entries in there
<kerio>
joke's on you, i have a mac
<kerio>
:>
<freemangordon>
uh
<Pali>
do you really do not know what is ACPI??
<kerio>
i know what it is
<Pali>
ok, its virtual machine interperter running in kernel which execute code which is passed by BIOS/FW to kernel
<kerio>
in the general sense
<kerio>
well ok it's a shitty design
<kerio>
so?
<kerio>
most of modern computing is
<freemangordon>
with even shitier execution
<Pali>
this is BIG shit
<mvaenskae>
acpi is a vm interpreter?!
<freemangordon>
there is VM in the kernel
<mvaenskae>
but indeed, let's see what people are going to say about systemd in a couple years and how freedom friendly it is
<mvaenskae>
freemangordon: one or many?
<kerio>
apparently you're supposed to run some weird proprietary microcode that comes from whatever crappy chinese manufacturer's mobo you're using
<kerio>
in kernel space
<kerio>
in theory
<Pali>
also in practice
<kerio>
fuck the trees
<freemangordon>
mvaenskae: many what? ACPI VMs?
<kerio>
uninstall acpid
<mvaenskae>
freemangordon: many vms :)
<mvaenskae>
not exclusive to acpi
<kerio>
i wanna tinker with nftables at some point
<freemangordon>
I am not aware of any other
<kerio>
in theory you should be able to route packets based on their content
<freemangordon>
but don;t quote me on that :)
<kerio>
freemangordon: newer ipfilter
<freemangordon>
could be, I tend to leave that stuff to the admins :)
<kerio>
*netfilter
<kerio>
basically they looked at the mess that is iptables and said "how do we move this shit off the kernel?"
<kerio>
so now the kernel runs a tiny vm to route and filter packets
<kerio>
which is programmed by the userland tools
<freemangordon>
Pali: BTW I am not sure I can do much more on the aes issue, I lack too much bits to continue. Unless Phil jups out of nowhere and responds to my mail and is willing to cooperate
<Pali>
kerio: but that accept only safe programs
<kerio>
which is a really nice design
<kerio>
yeah, it's a vm :)
<kerio>
afaik it even does JIT compiling
<Pali>
freemangordon: ok
<mvaenskae>
freemangordon: aes issue? is something broken with it? :o
<Pali>
freemangordon: can you comment on g_nokia patch?
<DocScrutinizer05>
DNS fixed
<freemangordon>
Pali: seems the only solution is to disable the aes driver in the board dts
<Pali>
mvaenskae: n900 has hw aes support, but it needs special bootloader
<Pali>
freemangordon: already disabled
<freemangordon>
anyway we don;t have much use of it
<freemangordon>
I know
<mvaenskae>
DocScrutinizer05: nice \o/
<Pali>
who did that change in DNS?
<freemangordon>
Pali: hmm, what needs to be commented?
<Pali>
freemangordon: I sent patch which add removable optional mass storage support to g_nokia.ko driver
<DocScrutinizer05>
Pali: some weird "convenience" automatism of OVH
<freemangordon>
Pali: yes, I saw that
<Pali>
and I would like to hear of other developers that this support is really usefull
<DocScrutinizer05>
Pali: ... that kicked in when dos1 fixed the mail stuff
<freemangordon>
but honestly didn;t get what felipe's problem is
<Pali>
freemangordon: currently only one gadget driver can be linked into zImage and external .ko gadgets are broken
<freemangordon>
and your patch is fixing that?
<Pali>
when you link g_nokia.ko to zImage it is working
<Pali>
when you link g_mass_storage it is working too
<Pali>
but you can link only one gadget
<freemangordon>
and who is supposed to fix that issue?
<Pali>
so you need to decide at boot time if you want usb networking or mass storage
<Pali>
and my patch add optional mass storage support to g_nokia
<DocScrutinizer05>
which idiot invented that crap?
<freemangordon>
really?
<freemangordon>
isn;t that a regression?
<Pali>
so via sysfs you can enable/disable mass storage at runtime
<DocScrutinizer05>
a mega-regression
<Pali>
always was possible to link *only* one gadget to zImage
<DocScrutinizer05>
why can't I load any arbitrary .ko I like?
<freemangordon>
wait, you can;t un/load modules like we do in stock nokia kernel?
<Pali>
but having more external .ko gadget is possible
<Pali>
problem is that modprobe g_nokia.ko cause device reboot :-)
<DocScrutinizer05>
WTF??
<Pali>
its regression
<Pali>
some kernel crash
<Pali>
bug in musb code
<Pali>
somebody broke it
<kerio>
is this in mainline
<DocScrutinizer05>
shoot him,
<Pali>
yes mainline
<freemangordon>
oh, so you want the default driver to be g_nokia with mass storage enabl;ed?
<Pali>
I bet I know who was it
<DocScrutinizer05>
and revert his patches
<Pali>
freemangordon: yes
<Pali>
DocScrutinizer05: it is for more kernel versions, and hard to git bisect it
<freemangordon>
Pali: I doubt upstream will agree, we'd better find what broke it and fix it
<Pali>
not easy and maybe not possible :-(
<Pali>
pavelm already tried something
<Pali>
but unsuccesfful
<DocScrutinizer05>
monolithic kernel, I think I'm in a bad dream
<freemangordon>
Pali: honestly, I am not sure it is a good idea to put *any* usb gadget in the zImage
<DocScrutinizer05>
exactly
<Pali>
if you want nfsboot without initrams it is only way
<Pali>
and pavelm booting in this way
<freemangordon>
sure, I get your point
<freemangordon>
but sill
<freemangordon>
*still
<Pali>
there are developers who use g_nokia in zImage
* DocScrutinizer05
afk, puking
<Pali>
DocScrutinizer05: do you think it is better to have initramfs with modules?
<Pali>
as modules needed to mount roofs in zImage?
<DocScrutinizer05>
I think it is better to revert to 2.8
<Pali>
hahaahha not possible :D
<Pali>
udev does not support 2.6.28 kernel anymore
<DocScrutinizer05>
guess what, it IS possible
<freemangordon>
:D
<Pali>
and you cannot use older udev
<Pali>
because new applications (like lsusb) depends on new udev
<DocScrutinizer05>
when idiots brwak kernel, we roll back to older version
<Pali>
it was possible before ~poettering
<DocScrutinizer05>
I think a lot of people losing their common sense
<DocScrutinizer05>
a kernel that reboots on rmmod, BWAHAHAHAHA
<DocScrutinizer05>
FIx THAT SHITE!!!
<freemangordon>
Pali: I have never used nfsboot as 1. I have another device to play with and 2. your scripts can put maemo on the uSD card. so it is possible to develop without g_nokia/mass storage loaded
<DocScrutinizer05>
if you (kernel devs) can't fix it, retrain for windows admin
<Pali>
sd card in boot time is broken too :-(
<freemangordon>
since when?
<Pali>
pavelm wrote that when he link mmc support into zImage no mmc devices are found
<Pali>
but when are loaded as external modules it is working...
<Pali>
do not remember
<freemangordon>
weird
<freemangordon>
last time I tried it, it was ok
<DocScrutinizer05>
I'm not too concerned about regressions in monolithic kernels
<DocScrutinizer05>
I'm going hamuk with regressions in midular kernel though
<freemangordon>
Pali: oh, I remember, it was something about rootwait, correct?
<Pali>
rootwait did not helped
<freemangordon>
iirc finally he was able to fix the issue
<DocScrutinizer05>
initrd got invented for some reasdon
<DocScrutinizer05>
anyway, afk bbl
* freemangordon
too, my daughter is hungry :)
<freemangordon>
Pali: seems we need a bughunter, going to get back to kernel :)
<Pali>
anyway, that mass storage support in g_nokia is usefull for users too... they do not need to unload/load modules when want to switch between pc-suite and mass storage mode
<Pali>
just some echo to sysfs
<freemangordon>
Pali: sure, but we can load g_nokia later in the process, be it in initrd or in startup scripts
<Pali>
if that crash bug will be fixed
<Pali>
but its not
<freemangordon>
Pali: does 3.19-n900 on gitoruous boot?
<Pali>
in rescueos yes
<Pali>
and also in qemu
<freemangordon>
ok, will see what I can do about that crashing g_nokia
<freemangordon>
it crashes on modprobe, correct?
<freemangordon>
Pali: ^^^
<Pali>
yes, crash on modprobe
<freemangordon>
ok
<DocScrutinizer05>
often / many crash on rmmod
<DocScrutinizer05>
I cloudily recall that's been a very common problem at times
<DocScrutinizer05>
sth not properly freed
<DocScrutinizer05>
iirc
<dos1>
wifi on freerunner had this problem at some point iirc (crash on rmmod)
<DocScrutinizer05>
yep
* freemangordon
hates gitorious
<freemangordon>
Pali: we should move the kernel repo to github
<Pali>
ok, no problem
<Pali>
I have github account too
<DocScrutinizer05>
github gives me PITA when trying to scroll, sth is totally borked with their HTML rendering
<Pali>
I can push changes to both servers (github and gitorious), no problem...
<DocScrutinizer05>
pressing space bar it takes ~1.0 seconds until next screen pops up
<Wizzup>
github has an easy raw view
<DocScrutinizer05>
Wizzup: TA!! :-)
<DocScrutinizer05>
indeed that's usable
<DocScrutinizer05>
I wonder what's wrong with the HTMLified pages
<DocScrutinizer05>
prolly nuked by sh*tloads of JS, eh?
<Wizzup>
I think they used a lot of divs or something, basically also making (older) firefox versions grind to a stop
<DocScrutinizer05>
slo you don't think it's JS like in <script type="text/javascript" async="" src="//collector-cdn.github.com/assets/api.js"></script>
<DocScrutinizer05>
((lots of divs))) can confirm that
<Wizzup>
but I'm no expert on this subject...
<DocScrutinizer05>
err, later on they use lots of tr
* DocScrutinizer05
frowns at names like js-line-number js-file-line
<DocScrutinizer05>
OO webpage
<DocScrutinizer05>
they had same sort of crap in Qt textedit RTF, where every char was an object and a 600k of text used 120MEGAbytes of storage when you displayed them, and another 120MB on top on closing the textedit box
<DocScrutinizer05>
(maybe I'm wrong by one magnitude, it's like 8 years ago. But hardly more than one mag)
<DocScrutinizer05>
iirc it was like factor 30 to 40, and twice that on closing the textedit, for running all the destructors
<DocScrutinizer05>
which been funny on a 160MB RAM laptop, when watching a 4MB logfile ;-P
<dos1>
DocScrutinizer05: efficient syntax coloring in HTML is hard to do without lots of DOM nodes
<DocScrutinizer05>
I've seen fine coloring in MXR/LXR, without that sort of lagging
<dos1>
because lots of markup alone won't hurt performance so much
<dos1>
but when you start to operate on these nodes somehow...
<DocScrutinizer05>
who wants to operate on a sourceode listing?
<DocScrutinizer05>
I mean, this is not an IDE
<dos1>
github has some code line commenting options, integrated stuff git blame etc. in its default view
<dos1>
like git blame*
<DocScrutinizer05>
then please offer a light version
<dos1>
like raw? :D
<kerio>
maybe use a decent browser? :>
* kerio
flees
<DocScrutinizer05>
honestly, a website loaded with features to death, that's plain useless
<DocScrutinizer05>
kerio: lynx?
<kerio>
ew
<Wizzup>
he probably means safari
<kerio>
w3m is actually a real browser
<freemangordon>
Pali: does 3.19-n900 have your g_nokia patch included?
<kerio>
if we want to go there
<Pali>
yes, my patch is there
<freemangordon>
I guess I shouls revert it
<freemangordon>
*should
paulk-collins has joined #neo900
freemangordon has quit [Remote host closed the connection]
freemangordon has joined #neo900
<freemangordon>
Pali: seems qemu in 14.04 does not support n900 and there is no qemu-linaro, at least I can't find it :(. Any hint?
<freemangordon>
14.04 is ubuntu
Kabouik_ has quit [Quit: WeeChat 1.1.1]
Kabouik_ has joined #neo900
sparetire has joined #neo900
Kabouik_ has quit [Quit: WeeChat 1.1.1]
Kabouik has quit [Quit: No Ping reply in 180 seconds.]
<freemangordon>
phew: "Linux version 3.19.0-rc5+ (ivo@ivo-H81M-S2PV) (gcc version 4.7.2 20120701 (prerelease) (Linaro GCC 4.7-2012.07) ) #2 PREEMPT Thu Feb 5 19:46:47 EET 2015"
che11 has quit [Ping timeout: 255 seconds]
<kerio>
is this on device? :O
<freemangordon>
no
<freemangordon>
qemu, but on the device is next
<kerio>
^_^
<Oksana>
NFC: so it's basically choice between smart PN544 and dumb TRF7970A, with PN544 supporting more protocols in target role, and TRF7970A supporting all protocols in initiator role. I would like to know, with TRF7970A being a dumb chip, is it possible that it will support All protocols in target role, too, once appropriate software is written? Or is it a hardware limitation?
<wpwrak>
Oksana: i'm not sure we could actually get the pn544 to work. there's very little documentation for it. i mean we could put it in and hope for the best, but that's about all.
<Oksana>
Yes, that's why I like TRF7970A more. I am just curious why it has such little support for target roles.
<wpwrak>
it's very hard to tell what roles a chip _can_ support (as opposed to the ones the manufacturer explicitly mentions). by and large, i think that the trf7970a is probably the most flexible of all the chips i looked at, so chances are probably good.
<wpwrak>
my main concern would be whether, when forced to "bit-bang" the radio interface, we can keep up with encoding/decoding
<freemangordon>
wpwrak: wouldn't and additional dedicated CPU help a bit?
<wpwrak>
i like DocScrutinizer05's suggestion to have a "raw" link to the omap in addition to the mcu i suggested. that way, we have two chances to get it right. the mcu has the advantage that it can throw all its resources at the problem while the omap has the advantage of having access to considerably more resources. so that's two ways to attack the problem and we won't really know which ones really work until somebody actually tries to do this.
<wpwrak>
freemangordon: yes, that's why i'm proposing to have a little kinetis there. so that we're not forced to maneuver the huge omap into place. that would be a bit like using a 747 to go to the supermarket :)
<freemangordon>
you wouldn;t be able to power up the omap in case of passive NFC
<freemangordon>
though, there still remains the problem with certification
<freemangordon>
no matter adittional mcu or not
<wpwrak>
oh, i think passive NFC is something we shouldn't try to support. i mean a smartphone is generally capable of running from battery, so all-passive would be an exceptional state anyway. and it means that you hand a lot of control to things you don't control.
<wpwrak>
(cert) you mean FCC and such ?
<freemangordon>
yep, makes sense
<freemangordon>
no, I mean PayPass/PayWave
<freemangordon>
L1 certification
<wpwrak>
what would such certification certify ?
<wpwrak>
if you have a SIM card that speaks paypass/paywave, we should be able to let it talk to a reader through the NFC RF: SIM - SWP - NFC - air - reader
<wpwrak>
so the paypass/paywave wouldn't actually see what we are. other than "some NFC radio"
<DocScrutinizer05>
transparent proxy ;-)
<DocScrutinizer05>
I don't care a lot about any "cert"
<wpwrak>
we don't have anything of our own that would qualify as Secure Element. not do we really want to. (i mean, we could lock-shut the kinetis but that would kinda spoil the fun
<DocScrutinizer05>
meh, I don't see anything illegal in our design
<wpwrak>
freemangordon:
<DocScrutinizer05>
maybe customer is not *allowed* to use his paypass SIM in a non-certified device. Bit then, modems were illegal too back in the early 80s here in Germany
<wpwrak>
in what would the illegality consist if one of our users uses their neo900 to talk to paypass et al. ?
<DocScrutinizer05>
but*
<DocScrutinizer05>
exactly
<freemangordon>
well, lets replace illegal with "not approved"
<DocScrutinizer05>
I don't care a lot about any "cert"
<Oksana>
wpwrak: SIM - SWP - NFC - air - reader : How would that work if TRF7970A doesn't have SWP? :confused:
<freemangordon>
what will happen if you dispute a transaction originated on such non-approved device?
<DocScrutinizer05>
aiui SWP is mostly just another alternative PHY layer
<wpwrak>
Oksana: did you read the paper ? :) we'd implement SWP in sw, e.g., by the kinetis
<wpwrak>
freemangordon: you're in deep shit either way :)
<DocScrutinizer05>
freemangordon: who will tell what device you used 2 weeks ago?
<freemangordon>
DocScrutinizer05: the acquirer, the issuer and the network have that information
<Oksana>
How so?
<DocScrutinizer05>
anyway my rear is holy, I won't bent over for a club of MoFos like Visa/maestro/amex dunnowhom to get a cert on Neo900
Kabouik has joined #neo900
<Oksana>
If the SIM you used for NFC payment was not ever used for cellular network, nobody will know what phone you used it in.
<wpwrak>
freemangordon: i.e., there's not exactly a shortage or precedent where banks denied claims that "secure" solutions had been used without the client's approval,these denials were upheld in court, and only much later it became known that there were actively exploited holes in the system. so you're basically at their mercy, even if you're doing everything right.
<DocScrutinizer05>
pfff, not even that will be allowed in any sane country. Sure you *could* figure Visa asking AT&T about the IMEI this SIM been used on last month
<freemangordon>
ok, it could be that I am bent because of my job :)
<Oksana>
Surely, you can use the NFC-bank SIM for payments without connecting the SIM to cellular network? That's what the switch is for, right? AT&T will not know any IMEI
<wpwrak>
DocScrutinizer05: well, they could ask the court to subpoena AT&T
<Oksana>
And AT&T could say: this SIM never contacted a cellular network ;-) Or something similar.
<freemangordon>
BTW what is the procedure to get such SIM where you live?
<freemangordon>
as it is still on the pilot stages here
<DocScrutinizer05>
wpwrak: and what would that prove? can it prove that I did NOT swap SIM to an arbitrary "certified" handset for 5 minutes to do the transaction?
<Oksana>
wpwrak: Thank you. I am beginning to read section 8 :-)
<wpwrak>
"Something between 200’000 and 400’000 Euro is a normal value."
gypsy has quit [Remote host closed the connection]
<DocScrutinizer05>
LOL
varu|zZz has joined #neo900
<freemangordon>
yeah, networks are greedy :)
<DocScrutinizer05>
how's that related to networks?
<wpwrak>
freemangordon: (sim) dunno. DocScrutinizer05 wants SWP + SIM. i have no idea about them.
* DocScrutinizer05
neither ;-P
<freemangordon>
DocScrutinizer05: by networks I mean Banknet/Visa etc
<wpwrak>
freemangordon: i just read the standards, try to make sense of them, and put little boxes on paper that show how we might implement these standards :)
<freemangordon>
wpwrak: oh, sure, I was asking in case you know
<DocScrutinizer05>
wpwrak: (SWP) I just know it was a complaint already with N9
<wpwrak>
DocScrutinizer05: if we can't get a SIM with SWP, that would complicate the design testing a bit ..
<wpwrak>
okay, so the complainers should send us their SIMs :)
<DocScrutinizer05>
there are test SIMs available for ~ everything
<DocScrutinizer05>
they won't cost $$$$$$
<DocScrutinizer05>
remember the SIM of CMU200?
<wpwrak>
freemangordon: but it's a useful data point if such SIMs are rare. i was thinking of building a test rig that can talk to a SIM (with the "modem" protocol) to check if it supports SWP, then use a positively identified SIM for further testing. but if chances are low to find such a critter, there's probably no point in going through that effort.
<DocScrutinizer05>
Oksana knew about such SIMs iirc
<wpwrak>
didn't know the CMU200 had a SIM. i just watched them. sometimes, in the lab, when running some arcane testing ritual. or sometimes when stacked five high in the corner of a room, each the price of a luxury sports car, and nobody in evidence even having an idea of what they could be good for (that was at our unfriendly visit to fiwin)
<Oksana>
Afaik: Any SIM can support SWP, hardware-wise. The problem is to get a SIM with an SWP-oriented app on it - an app for bank payments, transport payments, identification, or something. Since SIM is "protected" by cellular network provider, you need cooperation of bank (or transport authority) with cellular network provider , to put such an app on a SIM.
<DocScrutinizer05>
well, for our purposes layer-1 will suffice
<DocScrutinizer05>
which should be implemented on a SWP-capable SIM even when there's no payment/SWP app at all on it
<freemangordon>
yep, should be enough
<DocScrutinizer05>
the card needs to talk SWP to tell there's no APP
<freemangordon>
having the sent APDUs answered should be enough
<DocScrutinizer05>
:nod:
<wpwrak>
Oksana: for testing, just support of the very basics would be enough. basically "hello UICC !" "hello CLF !" (and that's all)
<freemangordon>
even if the answer is not 90 00
<DocScrutinizer05>
wpwrak: (cmu200) you need some SIM for the phone to "sign in" to the CMU200 ;-)
<wpwrak>
but even that is optional. and we can only reliably find out whether it should work or not by querying the SIM over the regular comm pins
<DocScrutinizer05>
wpwrak: you don't want the C;U200 to accept all arbitrary network codes
<DocScrutinizer05>
wpwrak: (query) sure
<DocScrutinizer05>
just saying a dummy SIM with no real APP at all is possible
<DocScrutinizer05>
it's even possible that 40% of UICC have SWP implemented already, worldwide
<wpwrak>
sure. as long as it speaks SWP, we can use it for testing :)
<Oksana>
Creation of SWP: adoption of USB leaves one pin free on the SIM face, and it is over this single wire that the SIM can, in theory, communicate with NFC hardware on the handset. http://www.theregister.co.uk/2008/02/14/swp_sim_nfc/
<DocScrutinizer05>
maybe SWP PHY is even mandatory for UICC
<wpwrak>
DocScrutinizer05: at least in the standard i've read, it isn't
<DocScrutinizer05>
Oksana: yes, so?
<DocScrutinizer05>
wpwrak: grr, suckers
<wpwrak>
why make it easy if you have a choice ;-)
<DocScrutinizer05>
this is err interesting: >>“With the availability of the VaultSecure IC, smartphone manufacturers, mobile network operators and other trusted third parties can co-own the SE and install, personalize and administer their own open- or closed-loop payment, access control, transit, loyalty or other secure applets,”<< http://www.nfcworld.com/2012/10/29/320799/inside-secure-launches-multi-owner-secure-element/
<kerio>
"trusted"
<DocScrutinizer05>
>>The chip also comes “with the largest and most comprehensive suite of pre-loaded and certified branded payment, access control and banking applets in the industry” says Inside Secure. These include Visa VMPA, MasterCard PayPass Mobile, First Data CertiFlash Mobile, OSPT Cipurse, HID Seos and SecureKey OneTap applets.<<
<DocScrutinizer05>
kerio: that's the whole point basically
<DocScrutinizer05>
the SE is a trusted environment, and you should know only trusted signed apps may run in such trusted environment, or it will get tainted
<kerio>
who decides who to trust?
<DocScrutinizer05>
the chip manuf?
<DocScrutinizer05>
just like Nokia decided whom to trust on N9 repos
<DocScrutinizer05>
the idea being: Visa send an email to you with a binary lob that only the (*your*) SIM SE environment can decrypt
<DocScrutinizer05>
you load that crypted stuff to your SIM et voila: your NFC credit card
<DocScrutinizer05>
Visa signs/encrypts your mail with a cert that got signed by the chip manuf
<DocScrutinizer05>
NB I'm just concluding, not reproducting learned knowledge
<DocScrutinizer05>
maybe freemangordon can confirm
<wpwrak>
maybe the easiest approach would be if we just offer our own payment solution :) doesn't "NeoPay 900" have a nice ring to it ? :)
* Oksana
wonders if there is an open-source Java Card operating system... Because currently, SIM just seems too closed
<DocScrutinizer05>
who cares?
<freemangordon>
something like that, though it is the chip manufacturer that provides the "applet" to the bank, personalized for that bank
<DocScrutinizer05>
who would want to run own apps on the SIM?
<freemangordon>
and bank certifies with Visa etc
<wpwrak>
maybe we could enlist the FSF as well. they must hate those "trusted" critters quite a bit. what better revenge than to compete with them ?
<freemangordon>
such "applet" could be either pre-loaded or downloaded later
<DocScrutinizer05>
freemangordon: aaah, yes prpbably. See quoate above >>The chip also comes “with the largest and most comprehensive suite of pre-loaded and certified branded ... aps<<
paulk-collins has quit [Ping timeout: 240 seconds]
<Oksana>
wpwrak: That would be like attempt to create our own radio-communication system because we don't like cellular modem. "Our own payment solution" should be interoperable with banks, transport, identification, and such. Currently, there are three choices for that: SIM-SWP, embedded SE, or microSD card.
<freemangordon>
that download could happen OTA (MNO sends SMSes) or via an application ont the device, by using SWP
<DocScrutinizer05>
no, there are mifare, a few ISO etc. The hw-IF is absolutely irrelevant
paulk-collins has joined #neo900
<DocScrutinizer05>
no matter if SWP, embedded SE or whatever
<DocScrutinizer05>
technically a NFC reader can't distinguish between a contactless credit card and a smartphone with NFC and SIM
<DocScrutinizer05>
afaik
<Oksana>
Yes...
<DocScrutinizer05>
but our own app would be absolutely useless even when it was certified by the SIM/chip manuf, since nobody will care about it. No POS terminal will use it
<DocScrutinizer05>
it doesn't know the secrete cert that authenticates a true payment app to the reader/server
<DocScrutinizer05>
it would be as useless as a selfmade maestro card, with random nonsense on the magnet stripe
<DocScrutinizer05>
yes, we could create our own unique independent access control, for the Neo900 lab and club rooms worldwide
Pali has quit [Remote host closed the connection]
vakkov has quit [Ping timeout: 252 seconds]
<DocScrutinizer05>
((<freemangordon> that download could happen OTA (MNO sends SMSes))) which is why Cinterion/Gemalto told us "why do you want dual SIM? That's so yesterday technology. Nowadays providers send your virtual SIM OTA to your phone, and you can have multiple virtual SIM (as in 'the SE that authenticates to cellular network') on one physical SIM, so you don't need Dual-SIM"
paulk-collins has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
I recall several years ago somebody (either c't/Heise or CCC) offered first prize of some competition being a SIM sponsored by O2 with one year of $n free minutes per month, *PLUS* developer feature which meant the hackers could write their own java(?) code to the SIM since it wasn't locked like regular SIMs are (were?)
<DocScrutinizer05>
the real life usefulness of such developer SIM is arguable
<DocScrutinizer05>
particularly back when in times pre-NFC
<DocScrutinizer05>
ooh there are freely programmable smartcards you AIUI can convert to a "SIM" using just a pair of scissors
<DocScrutinizer05>
some 10 to 40 bucks per card iirc
<wpwrak>
Oksana: i think you misunderstand the purpose: it would be to create confusion and give us a convenient excuse for not supporting anything else. i mean, if apple can do it, why can't we ? ;-)
<wpwrak>
Oksana: one problem could be "intellectual property". so i think what neo900 ug should have is a very simple but complete example for one of the safer protocols (e.g., 14443A), both as proof of concept and for testing, and not get involved with whatever else people may do with it.
<DocScrutinizer05>
ooh one thing: a few hours ago I paid with my maestro in a shop at POS (the POS is connected to the POTS line), and the thing started printing out the receipt and told me "payment completed" ~0.1s after I pressed the green button after entering PIN. :-o
<DocScrutinizer05>
how the heck can this thing verify my PIN in "less time than it needs" to transfer the 4 digits via phone line?
<DocScrutinizer05>
or dies the smartcard chip on the CC the whole PIN verification nowadays?
<DocScrutinizer05>
does*
<DocScrutinizer05>
I know for *sure* that POS have no way to do the PIN verification locally. Those verifier computers are small cigar boxes with massive metal shiled that destroy the chip with the algo when you try to open them, and they are deployed in official ATM only
<wpwrak>
maybe something was wrong and it used one of those lovely fallback modes ? :)
<DocScrutinizer05>
maybe, yes
<wpwrak>
"chip not responding ? use mag stripe. mag stripe bad ? just type in the number. no connection to hq ? have them mail in the receipt later" never ever decline a payment because of technical difficulties :)
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
:-D
<DocScrutinizer05>
though... I never seen a POS with such low reaction time. I seen POS rejecting card payment due to "technical issues" a zillion times, statistically ~ 15..20%, maybe slightly less