2015-09-23 00:54 wildlander has quit [Quit: Saliendo] 2015-09-23 01:22 newcup has joined #qi-hardware 2015-09-23 01:31 atommann has joined #qi-hardware 2015-09-23 01:35 jwhitmore has quit [Ping timeout: 250 seconds] 2015-09-23 01:38 uwe_ has quit [Ping timeout: 260 seconds] 2015-09-23 01:40 fengling has joined #qi-hardware 2015-09-23 01:43 uwe_ has joined #qi-hardware 2015-09-23 01:48 wpwrak: (origin of browser plugin) browser plugins generally can request access to everything 2015-09-23 01:48 many do, like adblocker 2015-09-23 02:43 xiangfu has quit [Ping timeout: 250 seconds] 2015-09-23 02:44 xiangfu has joined #qi-hardware 2015-09-23 02:47 rodgort has quit [K-Lined] 2015-09-23 02:54 rodgort has joined #qi-hardware 2015-09-23 02:57 xiangfu has quit [Ping timeout: 244 seconds] 2015-09-23 02:57 xiangfu has joined #qi-hardware 2015-09-23 03:20 sandeepkr has joined #qi-hardware 2015-09-23 03:55 archang has joined #qi-hardware 2015-09-23 04:54 unclouded has quit [Quit: Leaving] 2015-09-23 06:06 wpwrak has quit [Ping timeout: 265 seconds] 2015-09-23 06:33 unclouded has joined #qi-hardware 2015-09-23 06:39 unclouded has quit [Read error: No route to host] 2015-09-23 07:43 fengling has quit [Ping timeout: 245 seconds] 2015-09-23 07:44 fengling has joined #qi-hardware 2015-09-23 07:50 sandeepkr has quit [Ping timeout: 264 seconds] 2015-09-23 07:53 fengling has quit [Ping timeout: 245 seconds] 2015-09-23 07:53 fengling has joined #qi-hardware 2015-09-23 08:12 pcercuei has joined #qi-hardware 2015-09-23 08:17 sandeepkr has joined #qi-hardware 2015-09-23 08:22 sandeepkr has quit [Excess Flood] 2015-09-23 08:23 sandeepkr has joined #qi-hardware 2015-09-23 08:54 fengling has quit [Ping timeout: 245 seconds] 2015-09-23 09:16 jwhitmore has joined #qi-hardware 2015-09-23 09:21 fengling has joined #qi-hardware 2015-09-23 09:25 sandeepkr has quit [Ping timeout: 268 seconds] 2015-09-23 10:16 atommann has quit [Quit: Leaving] 2015-09-23 10:16 sandeepkr has joined #qi-hardware 2015-09-23 10:35 archang has quit [Remote host closed the connection] 2015-09-23 10:51 wpwrak has joined #qi-hardware 2015-09-23 11:08 jwhitmore has quit [Ping timeout: 250 seconds] 2015-09-23 11:27 jwhitmore has joined #qi-hardware 2015-09-23 12:57 whitequark: hmm yes, plugins could do anything. but would it be easy for them to use such a WebUSB mechanism ? i.e., do interfaces exists for a plugin to a) run JS while b) passing or bypassing the origin test ? 2015-09-23 13:00 that has nothing to do with webusb 2015-09-23 13:00 I mean... a plugin can request webusb, a webpage cannot 2015-09-23 13:00 wait 2015-09-23 13:01 "run JS while" 2015-09-23 13:01 a plugin IS in javascript, in every major browser 2015-09-23 13:02 and webusb is a javascript binding to libusb essentially 2015-09-23 13:03 I don't mean plugins in the sense of arbitrary binary code, that's practically impossible to run in modern browsers and for a good reason 2015-09-23 13:09 (plugin is js) oh, i thought they were native code 2015-09-23 13:09 <-- web tech noob here :) 2015-09-23 13:11 errr 2015-09-23 13:11 * whitequark looks back 2015-09-23 13:11 seems I first called it an "browser extension" which is more correct / what people usually say 2015-09-23 13:11 and then DocScrutinizer05 called it a plugin 2015-09-23 13:11 so it wouldn't be possible to make a plugin that intercepts login dialogs and then uses HIDAPI (to avoid the need for a dedicated driver on platforms where that's a problem) to talk to anelok ? 2015-09-23 13:12 you're right, the proper name for the thing in JS is an "extension" and a "plugin" is something like flash that's in native code 2015-09-23 13:12 and you don't want to ship native code 2015-09-23 13:12 (terminology) perfect ;-) 2015-09-23 13:12 anyway, from what i know about webusb is it's libusb 2015-09-23 13:13 so you don't even need HID. but I don't know what chrome does on windows about it 2015-09-23 13:13 looks like libusb + bureaucracy 2015-09-23 13:13 bureaucracy? 2015-09-23 13:13 the procedure to be allowed to access webusb 2015-09-23 13:14 some more usb descriptors, etc. 2015-09-23 13:14 sorry, no clue at all here. I use names based on what sounds right to me in this case 2015-09-23 13:14 ah, yeah 2015-09-23 13:15 speaking of login dialogs, you cannot readily determine what is a "login dialog" 2015-09-23 13:15 and I never before heard WebUSB 2015-09-23 13:15 I would instead add a context menu option "fill in username" "fill in password" since you know the URL 2015-09-23 13:15 plugin + hidapi (or whatever) would still be the way to do until webusb is widely available, right ? 2015-09-23 13:15 no 2015-09-23 13:15 shipping plugins is a security risk 2015-09-23 13:16 wait! I have a weird idea since 3.5s 2015-09-23 13:16 (determine) how does the browser do it ? there must be some hints / heuristics 2015-09-23 13:16 print page to USB printer... 2015-09-23 13:16 everyone who is not completely incompetent about infosec is going to dissuade anyone they know from ever installing any plugins 2015-09-23 13:16 ctrl-P, select printer 'anelok' 2015-09-23 13:16 so you're saying there is no way without webusb ? 2015-09-23 13:16 native app 2015-09-23 13:17 (that cannot be poked by a malicious webpage and used to get access to the user's machine) 2015-09-23 13:17 how would a native application intercept login dialogs ? 2015-09-23 13:17 should work on every brwoser and OS, no? 2015-09-23 13:17 why are you talking about "login dialogs"? there are no dialogs 2015-09-23 13:17 and it wouldn't 2015-09-23 13:18 no plugins or anything needed 2015-09-23 13:18 it would just make filling forms easier 2015-09-23 13:18 whitequark: i mean pages that contain a login with a password field. however it's implemented. 2015-09-23 13:18 wpwrak: it's not implemented in any standardized way 2015-09-23 13:18 DocScrutinizer05: universality would be nice. but may not be within easy reach at the moment. 2015-09-23 13:19 DocScrutinizer05: you got some postscript. what now? 2015-09-23 13:19 are you going to run OCR on anelok? doubt it 2015-09-23 13:19 grep for key strings 2015-09-23 13:19 there are no strings 2015-09-23 13:19 (postscript) depends on printer 2015-09-23 13:19 depends on the browser 2015-09-23 13:19 eeew 2015-09-23 13:19 and no browsers send raw text 2015-09-23 13:20 ok nevermind 2015-09-23 13:20 whitequark: i guess one could use a) the heuristics browsers use for this, and b) maybe add an explicit hint that web sites can use. worst-case, call it anelok-* ;-) 2015-09-23 13:20 they just take the internal vector model of the page content and send it there 2015-09-23 13:20 actually it's irrelevant what it sends as long as it has unique fingerprint 2015-09-23 13:20 wpwrak: yes, heuristics is what everything uses 2015-09-23 13:20 DocScrutinizer05: it sends vector graphics that has literally none of the information you want 2015-09-23 13:21 if it's good enough for google, it shall be good enough for me ;-) so, how to intercept at the level of those heuristics ? 2015-09-23 13:21 no text, no info on what the text field is, no explanation of how to navigate into the field 2015-09-23 13:21 afk 2015-09-23 13:21 and there's still the keyboard layout issue 2015-09-23 13:21 wpwrak: you can't 2015-09-23 13:21 reimplement them yourself 2015-09-23 13:22 you get to inject arbitrary JS into the page + a few privileged APIs 2015-09-23 13:22 that's it 2015-09-23 13:22 DocScrutinizer05: (fancy and impractical ways to get at page content) pretend to be USB storage and save the html page on that device (-:C 2015-09-23 13:23 whitequark: reimplementing heuristics sound okay. so the apis / mechanisms for doing all this exist. good. that's what i wasn't sure about. 2015-09-23 13:25 now ... how to go from there to talking to anelok ? i would equate "plugin" to "native app" for most purposes, including access to libusb / hidapi / etc. the big exception would be that one has an intrinsic link into the browser while i don't know how the other would talk to our login-interceptor.js 2015-09-23 13:25 you aren't shipping a browser plugin 2015-09-23 13:26 you're shipping an extension. scrap a page, look for username/password fields in forms, show button in the browser UI. when pressed, send URL to anelok, get back password, fill in ? 2015-09-23 13:26 are they really that reviled ? or is that just your personal opinion ? :) 2015-09-23 13:26 they are the single worst offender in web security by a very large margin 2015-09-23 13:27 using what mechanism do i send the URL to anelok ? i.e., how do i get data from the extension (login-interceptor.js) to the usb-attached anelok device ? 2015-09-23 13:27 webusb. 2015-09-23 13:27 and if webusb isn't available ? 2015-09-23 13:27 then there is no convenient option 2015-09-23 13:28 so, plugin after all, it seems. and webusb as plan A for those who have it. 2015-09-23 13:29 that's a moronic strategy. exposing users to a security risk in a security-related device 2015-09-23 13:29 though not uncommon in the industry 2015-09-23 13:30 on second thought, it doesn't matter, because you can't do that 2015-09-23 13:30 most of the issues of plugins seem to come from them just doing bad things. but a native application would have similar issues. you seem to have said that it was easy for a bad web page to also manipulate the code of a plugin ? 2015-09-23 13:30 on windows, plugins are run as "low integrity processes", and on linux they run in a seccomp-bpf sandbox 2015-09-23 13:30 essentially 2015-09-23 13:31 drive-by malvertising is a very common problem 2015-09-23 13:31 you use an ad network to distribute a link to a malware exploit kit. exploit loads plugin, feeds it bad input, escapes from sandbox 2015-09-23 13:32 according to this, plugins are still tolerated in chromium: https://www.chromium.org/developers/design-documents/plugin-architecture 2015-09-23 13:33 let's see what mozilla has to say about them ... 2015-09-23 13:34 https://wiki.mozilla.org/Sandbox#Permissions_burndown 2015-09-23 13:34 wpwrak: (save page) even better 2015-09-23 13:34 plenty of cheerful development advices for plugins: https://developer.mozilla.org/en-US/Add-ons/Plugins 2015-09-23 13:42 note that NPAPI (the un-sandboxed API for plugins) was completely removed from Chrome and it's click-to-play in Firefox 2015-09-23 13:44 "September 2015 2015-09-23 13:44 In September 2015 (Chrome 45) we will remove the override and NPAPI support will be permanently removed from Chrome. Installed extensions that require NPAPI plugins will no longer be able to load those plugins." 2015-09-23 13:45 ah, very recent. https://support.google.com/chrome/answer/6213033?hl=en 2015-09-23 13:45 but there's a new api, PPAPI :) 2015-09-23 13:45 PPAPI is sandboxed. 2015-09-23 13:45 you cannot even call open() from PPAPI, much less access USB 2015-09-23 13:46 the only thing you can do is communicate with the browser via pipes and put pixels in shared memory 2015-09-23 13:46 which was the very point of creating PPAPI 2015-09-23 13:47 hmm, there seems t obe this: https://developer.chrome.com/apps/usb 2015-09-23 13:48 this is what led me to it: http://stackoverflow.com/questions/19174943/usb-device-access-using-google-native-client-nacl 2015-09-23 13:48 that's webusb. 2015-09-23 13:48 no sure what the "NaCl" is they're talking about. i know NaCl as the name of a crypto library, but that seems to be something different 2015-09-23 13:49 NaCl is a Chrome-specific way of distributing native code and safely running it in a sandbox 2015-09-23 13:49 unless you have large amounts of C you don't want to rewrite, it is of no use to you 2015-09-23 13:50 in this case, it doesn't give you any capabilities, you still have to perform the communication using some JS with WebUSB 2015-09-23 13:50 since NaCl sits in the same sandbox as PPAPI plugins 2015-09-23 13:50 (chrome.usb == webusb) sure about that ? it looks much simpler 2015-09-23 13:51 it would seem that NaCl has a way to get out of the sandbox, using that chrome.usb API 2015-09-23 13:52 um, no, NaCl doesn't have access to that API. it can only talk to JS 2015-09-23 13:52 JS however has access to WebUSB 2015-09-23 13:52 yes, but webusb seems to be something brand-new while chrome.usb seems to have been around for a while 2015-09-23 13:53 also, it seems that chrome.usb just requires you to allow USB access while webusb has a lot more paperwork 2015-09-23 13:54 more: https://developer.chrome.com/apps/app_usb 2015-09-23 13:55 i am not sure why anybody sane should allow a browser hw access that way 2015-09-23 13:55 that looks more similar to webusb though. but still without the origins and stuff 2015-09-23 13:55 wpwrak: well, yes, you don't care about origins when you're in an extension 2015-09-23 13:56 roh: the high-level objective is to let your browser look up accounts on anelok when you're about to perform a login. how would you implement it then, without the things we discussed ? 2015-09-23 13:56 wpwrak: then you need an api and some driver layer inbetween. 2015-09-23 13:56 whitequark: ah, that sounds encouraging :) 2015-09-23 13:56 wpwrak: on second look I think you're right, chrome.usb is not webusb and I was incorrectly referring to it as such 2015-09-23 13:56 I assumed chrome.usb was just webusb exposed to plugins 2015-09-23 13:56 a browser should never have any hw access.. just run it as root if you allow it to access usb. 2015-09-23 13:57 i mean.. it could write to your harddisk then anyhow. so why bother sandboxing anyhing 2015-09-23 13:57 wpwrak: that's actually good news for you, I guess 2015-09-23 13:57 i understand what the idea is. and no. one cannot do that properly and secured in a broswer-plugin only. 2015-09-23 13:58 this looks encouraging, too: https://github.com/ubinity/webhidapi-firebreath 2015-09-23 13:58 wpwrak: check out how the crypto/account stuff works on browsers and connect that to anelok. so anelok is a crypto-provider for the browser 2015-09-23 13:59 roh: no such API to do that 2015-09-23 14:00 (which is rather unfortunate, yes) 2015-09-23 14:00 whitequark: huh? how does smartcard stuff work then? 2015-09-23 14:00 roh: via a plugin :( 2015-09-23 14:00 whitequark: an it does. ive seen people use it. 2015-09-23 14:00 plugins for the win ! :) 2015-09-23 14:00 no. no 'plugins' in the classic way. it was something native 2015-09-23 14:00 and you're lucky if the plugin is not activex 2015-09-23 14:01 whitequark: it worked for every password field and also provided ssl keys 2015-09-23 14:01 hm 2015-09-23 14:01 but look at the bright side: if anelok needs to use a particularly dirty mechanism to get its stuff done, that may provide motivation for getting a proper interface from the browser 2015-09-23 14:01 i know who to ask. will do that 2015-09-23 14:02 anyhow.. such a thing is not easy to configure and needs nonstandard software. would not be plugnplay at all 2015-09-23 14:03 I've specifically checked just now and both chrome and firefox use a plugin 2015-09-23 14:03 whitequark: i think it was called 'certificate provider' 2015-09-23 14:03 or rather, various plugins from various smartcard vendors 2015-09-23 14:03 and its really ugly 2015-09-23 14:06 ok I see, yes, they do support this via NSS (on linux) and some windows mechanism 2015-09-23 14:07 so that would provide you PKCS#11 capability 2015-09-23 14:07 but filling password field means there was /also/ a browser plugin 2015-09-23 14:07 e.g. see this issue https://code.google.com/p/chromium/issues/detail?id=42073 2015-09-23 14:07 meh 2015-09-23 14:08 so one needs both? 2015-09-23 14:08 I doubt many people using anelok will want PKCS#11 anyhow 2015-09-23 14:18 task cards updated :) https://gitlab.com/anelok/doc/wikis/Task_hidapi https://gitlab.com/anelok/doc/wikis/Task_webusb 2015-09-23 14:18 i love that git-based wiki. takes the pain out of managing wiki content 2015-09-23 14:21 you also need to figure out what to do on mobile 2015-09-23 14:25 yes, there it's BTLE. apparently, for HIDAPI, there's no / not much of a difference between USB HID and BT HID 2015-09-23 14:26 yes, but I don't know what's the status on accessing BTLE from mobile browsers 2015-09-23 14:26 note that *nothing* on mobile has browser plugins 2015-09-23 14:29 apparently, it may not be impossible: http://stackoverflow.com/questions/3960050/how-to-develop-plugins-for-the-native-android-browser 2015-09-23 14:30 there's no Android browser anymore on the stock firmware, it's just Chrome 2015-09-23 14:30 since... 4.2, I think? 2015-09-23 14:30 yeah, it's from 2010 2015-09-23 14:31 this sounds fairly damning: https://support.google.com/chrome/answer/2710225?hl=en 2015-09-23 14:32 the main reason is that some people will deploy shitty plugins that eat tons of CPU and then the people who have to use that complain that Android gets no battery life 2015-09-23 14:33 here (page loads a painful amount of junk), they do it by installing a different browser :) http://www.pcadvisor.co.uk/how-to/google-android/install-flash-on-android-kitkat-smartphone-tablet-lollipop-3417930/ 2015-09-23 14:33 on my galaxy s ii i've installed the flash plugin while that was still possible. actually opening a flash thing caused my phone to become so hot I could not hold it in my hands 2015-09-23 14:34 ;-))) 2015-09-23 14:34 why would any sane person do that? :o 2015-09-23 14:35 some video player required it, I think 2015-09-23 14:35 but I uninstalled it pretty much immediately after, it was completely unusable 2015-09-23 14:36 hmm, apparently they even shun extensions: http://www.omgchrome.com/chrome-android-extensions-not-planned-ama/ 2015-09-23 14:37 whitequark: that adobe experience was probably a warning: "you're about to make a pact with the devil. here is a quick demo of what to expect. sure to proceed anyway ?" 2015-09-23 14:38 the likely reason for that is when chrome adds extension... the first extension someone implements is an adblocker 2015-09-23 14:39 you may want to look into how lastpass on android works 2015-09-23 14:40 hmm. there is a hint: https://helpdesk.lastpass.com/lastpass-mobile/lastpass-for-android/ 2015-09-23 14:41 apparently 4.3 did something to make it easier 2015-09-23 14:42 woakas has quit [Ping timeout: 246 seconds] 2015-09-23 14:42 ah, 4.3 added exactly an API for autofilling credentials 2015-09-23 14:44 hm, looking closer, it appears to be abusing accessibility APIs 2015-09-23 14:44 for screen readers and such 2015-09-23 14:44 well, close enough 2015-09-23 14:45 and LastPass for iOS works by embedding a browser in itself, which it can control, and which shares the cookie storage with the system browser 2015-09-23 14:46 that's actually better than I expected 2015-09-23 14:46 you'll still have to shell out $100 yearly and go through apple's ridiculous appstore review process 2015-09-23 14:51 (accessibility) do you have a link ? 2015-09-23 14:52 your link exactly 2015-09-23 14:52 oh :) 2015-09-23 16:18 pcercuei has quit [Ping timeout: 240 seconds] 2015-09-23 16:56 arossdotme-planb has quit [Ping timeout: 256 seconds] 2015-09-23 17:01 pcercuei has joined #qi-hardware 2015-09-23 17:09 arossdotme-planb has joined #qi-hardware 2015-09-23 17:27 woakas has joined #qi-hardware 2015-09-23 18:05 wildlander has joined #qi-hardware 2015-09-23 18:22 dandon has quit [Ping timeout: 264 seconds] 2015-09-23 18:27 dandon has joined #qi-hardware 2015-09-23 18:40 arossdotme-planb has quit [Ping timeout: 256 seconds] 2015-09-23 18:53 arossdotme-planb has joined #qi-hardware 2015-09-23 19:54 jwhitmore has quit [Ping timeout: 244 seconds] 2015-09-23 19:58 pcercuei has quit [Ping timeout: 240 seconds] 2015-09-23 20:55 Luke-Jr has quit [Read error: Connection reset by peer] 2015-09-23 20:57 Luke-Jr has joined #qi-hardware 2015-09-23 22:29 apelete has quit [Ping timeout: 250 seconds] 2015-09-23 23:06 sandeepkr has quit [Ping timeout: 264 seconds]