| 01:22.43 | *** join/#qi-hardware newcup (newcup@peruna.fi) |
| 01:31.45 | *** join/#qi-hardware atommann (~atommann@210.3.149.230) |
| 01:40.53 | *** join/#qi-hardware fengling (~fengling@111.198.29.54) |
| 01:43.57 | *** join/#qi-hardware uwe_ (~uwe_@dslb-088-067-177-062.088.067.pools.vodafone-ip.de) |
| 01:48.18 | whitequark | wpwrak: (origin of browser plugin) browser plugins generally can request access to everything |
| 01:48.22 | whitequark | many do, like adblocker |
| 02:44.33 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 02:54.00 | *** join/#qi-hardware rodgort (~rodgort@105.ip-167-114-152.net) |
| 02:57.55 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 03:20.15 | *** join/#qi-hardware sandeepkr (~sandeepkr@111.235.64.135) |
| 03:55.33 | *** join/#qi-hardware archang (~archang@122.133.52.113.static.ximdns.com) |
| 06:33.14 | *** join/#qi-hardware unclouded (~neil@2001:4428:200:80fc:7e05:7ff:fe0d:d421) |
| 07:44.21 | *** join/#qi-hardware fengling (~fengling@111.198.29.54) |
| 07:53.54 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 08:12.03 | *** join/#qi-hardware pcercuei (~paul@p4FDE6D86.dip0.t-ipconnect.de) |
| 08:17.47 | *** join/#qi-hardware sandeepkr (~sandeepkr@111.235.64.135) |
| 08:23.18 | *** join/#qi-hardware sandeepkr (~sandeepkr@111.235.64.135) |
| 09:16.42 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.77.119.181) |
| 09:21.50 | *** join/#qi-hardware fengling (~fengling@111.198.29.54) |
| 10:16.16 | *** join/#qi-hardware sandeepkr (~sandeepkr@111.235.64.135) |
| 10:51.03 | *** join/#qi-hardware wpwrak (~werner@64-166-231-201.fibertel.com.ar) |
| 11:27.31 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.77.119.181) |
| 12:57.04 | wpwrak | 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 ? |
| 13:00.38 | whitequark | that has nothing to do with webusb |
| 13:00.47 | whitequark | I mean... a plugin can request webusb, a webpage cannot |
| 13:00.52 | whitequark | wait |
| 13:01.03 | whitequark | "run JS while" |
| 13:01.10 | whitequark | a plugin IS in javascript, in every major browser |
| 13:02.42 | whitequark | and webusb is a javascript binding to libusb essentially |
| 13:03.19 | whitequark | 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 |
| 13:09.24 | wpwrak | (plugin is js) oh, i thought they were native code |
| 13:09.36 | wpwrak | <-- web tech noob here :) |
| 13:11.08 | whitequark | errr |
| 13:11.14 | whitequark | looks back |
| 13:11.29 | whitequark | seems I first called it an "browser extension" which is more correct / what people usually say |
| 13:11.37 | whitequark | and then DocScrutinizer05 called it a plugin |
| 13:11.51 | wpwrak | 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 ? |
| 13:12.10 | whitequark | 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 |
| 13:12.15 | whitequark | and you don't want to ship native code |
| 13:12.30 | wpwrak | (terminology) perfect ;-) |
| 13:12.43 | whitequark | anyway, from what i know about webusb is it's libusb |
| 13:13.12 | whitequark | so you don't even need HID. but I don't know what chrome does on windows about it |
| 13:13.14 | wpwrak | looks like libusb + bureaucracy |
| 13:13.37 | whitequark | bureaucracy? |
| 13:13.53 | wpwrak | the procedure to be allowed to access webusb |
| 13:14.02 | wpwrak | some more usb descriptors, etc. |
| 13:14.11 | DocScrutinizer05 | sorry, no clue at all here. I use names based on what sounds right to me in this case |
| 13:14.53 | whitequark | ah, yeah |
| 13:15.19 | whitequark | speaking of login dialogs, you cannot readily determine what is a "login dialog" |
| 13:15.22 | DocScrutinizer05 | and I never before heard WebUSB |
| 13:15.39 | whitequark | I would instead add a context menu option "fill in username" "fill in password" since you know the URL |
| 13:15.43 | wpwrak | plugin + hidapi (or whatever) would still be the way to do until webusb is widely available, right ? |
| 13:15.51 | whitequark | no |
| 13:15.59 | whitequark | shipping plugins is a security risk |
| 13:16.10 | DocScrutinizer05 | wait! I have a weird idea since 3.5s |
| 13:16.20 | wpwrak | (determine) how does the browser do it ? there must be some hints / heuristics |
| 13:16.21 | DocScrutinizer05 | print page to USB printer... |
| 13:16.24 | whitequark | everyone who is not completely incompetent about infosec is going to dissuade anyone they know from ever installing any plugins |
| 13:16.43 | DocScrutinizer05 | ctrl-P, select printer 'anelok' |
| 13:16.49 | wpwrak | so you're saying there is no way without webusb ? |
| 13:16.55 | whitequark | native app |
| 13:17.23 | whitequark | (that cannot be poked by a malicious webpage and used to get access to the user's machine) |
| 13:17.40 | wpwrak | how would a native application intercept login dialogs ? |
| 13:17.46 | DocScrutinizer05 | should work on every brwoser and OS, no? |
| 13:17.53 | whitequark | why are you talking about "login dialogs"? there are no dialogs |
| 13:17.58 | whitequark | and it wouldn't |
| 13:18.01 | DocScrutinizer05 | no plugins or anything needed |
| 13:18.03 | whitequark | it would just make filling forms easier |
| 13:18.23 | wpwrak | whitequark: i mean pages that contain a login with a password field. however it's implemented. |
| 13:18.39 | whitequark | wpwrak: it's not implemented in any standardized way |
| 13:18.49 | wpwrak | DocScrutinizer05: universality would be nice. but may not be within easy reach at the moment. |
| 13:19.00 | whitequark | DocScrutinizer05: you got some postscript. what now? |
| 13:19.08 | whitequark | are you going to run OCR on anelok? doubt it |
| 13:19.13 | DocScrutinizer05 | grep for key strings |
| 13:19.18 | whitequark | there are no strings |
| 13:19.36 | DocScrutinizer05 | (postscript) depends on printer |
| 13:19.43 | whitequark | depends on the browser |
| 13:19.49 | DocScrutinizer05 | eeew |
| 13:19.59 | whitequark | and no browsers send raw text |
| 13:20.02 | DocScrutinizer05 | ok nevermind |
| 13:20.14 | wpwrak | 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-* ;-) |
| 13:20.17 | whitequark | they just take the internal vector model of the page content and send it there |
| 13:20.29 | DocScrutinizer05 | actually it's irrelevant what it sends as long as it has unique fingerprint |
| 13:20.30 | whitequark | wpwrak: yes, heuristics is what everything uses |
| 13:20.55 | whitequark | DocScrutinizer05: it sends vector graphics that has literally none of the information you want |
| 13:21.09 | wpwrak | if it's good enough for google, it shall be good enough for me ;-) so, how to intercept at the level of those heuristics ? |
| 13:21.25 | whitequark | no text, no info on what the text field is, no explanation of how to navigate into the field |
| 13:21.28 | DocScrutinizer05 | afk |
| 13:21.31 | whitequark | and there's still the keyboard layout issue |
| 13:21.34 | whitequark | wpwrak: you can't |
| 13:21.38 | whitequark | reimplement them yourself |
| 13:22.06 | whitequark | you get to inject arbitrary JS into the page + a few privileged APIs |
| 13:22.08 | whitequark | that's it |
| 13:22.14 | wpwrak | DocScrutinizer05: (fancy and impractical ways to get at page content) pretend to be USB storage and save the html page on that device (-:C |
| 13:23.20 | wpwrak | whitequark: reimplementing heuristics sound okay. so the apis / mechanisms for doing all this exist. good. that's what i wasn't sure about. |
| 13:25.07 | wpwrak | 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 |
| 13:25.27 | whitequark | you aren't shipping a browser plugin |
| 13:26.12 | whitequark | 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 ? |
| 13:26.14 | wpwrak | are they really that reviled ? or is that just your personal opinion ? :) |
| 13:26.50 | whitequark | they are the single worst offender in web security by a very large margin |
| 13:27.12 | wpwrak | 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 ? |
| 13:27.18 | whitequark | webusb. |
| 13:27.40 | wpwrak | and if webusb isn't available ? |
| 13:27.56 | whitequark | then there is no convenient option |
| 13:28.24 | wpwrak | so, plugin after all, it seems. and webusb as plan A for those who have it. |
| 13:29.01 | whitequark | that's a moronic strategy. exposing users to a security risk in a security-related device |
| 13:29.06 | whitequark | though not uncommon in the industry |
| 13:30.20 | whitequark | on second thought, it doesn't matter, because you can't do that |
| 13:30.45 | wpwrak | 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 ? |
| 13:30.45 | whitequark | on windows, plugins are run as "low integrity processes", and on linux they run in a seccomp-bpf sandbox |
| 13:30.53 | whitequark | essentially |
| 13:31.04 | whitequark | drive-by malvertising is a very common problem |
| 13:31.26 | whitequark | you use an ad network to distribute a link to a malware exploit kit. exploit loads plugin, feeds it bad input, escapes from sandbox |
| 13:32.59 | wpwrak | according to this, plugins are still tolerated in chromium: https://www.chromium.org/developers/design-documents/plugin-architecture |
| 13:33.07 | wpwrak | let's see what mozilla has to say about them ... |
| 13:34.21 | whitequark | https://wiki.mozilla.org/Sandbox#Permissions_burndown |
| 13:34.28 | DocScrutinizer05 | wpwrak: (save page) even better |
| 13:34.48 | wpwrak | plenty of cheerful development advices for plugins: https://developer.mozilla.org/en-US/Add-ons/Plugins |
| 13:42.54 | whitequark | note that NPAPI (the un-sandboxed API for plugins) was completely removed from Chrome and it's click-to-play in Firefox |
| 13:44.29 | whitequark | "September 2015 |
| 13:44.30 | whitequark | 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." |
| 13:45.09 | wpwrak | ah, very recent. https://support.google.com/chrome/answer/6213033?hl=en |
| 13:45.25 | wpwrak | but there's a new api, PPAPI :) |
| 13:45.44 | whitequark | PPAPI is sandboxed. |
| 13:45.55 | whitequark | you cannot even call open() from PPAPI, much less access USB |
| 13:46.16 | whitequark | the only thing you can do is communicate with the browser via pipes and put pixels in shared memory |
| 13:46.39 | whitequark | which was the very point of creating PPAPI |
| 13:47.59 | wpwrak | hmm, there seems t obe this: https://developer.chrome.com/apps/usb |
| 13:48.17 | wpwrak | this is what led me to it: http://stackoverflow.com/questions/19174943/usb-device-access-using-google-native-client-nacl |
| 13:48.52 | whitequark | that's webusb. |
| 13:48.58 | wpwrak | 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 |
| 13:49.21 | whitequark | NaCl is a Chrome-specific way of distributing native code and safely running it in a sandbox |
| 13:49.33 | whitequark | unless you have large amounts of C you don't want to rewrite, it is of no use to you |
| 13:50.08 | whitequark | in this case, it doesn't give you any capabilities, you still have to perform the communication using some JS with WebUSB |
| 13:50.18 | whitequark | since NaCl sits in the same sandbox as PPAPI plugins |
| 13:50.56 | wpwrak | (chrome.usb == webusb) sure about that ? it looks much simpler |
| 13:51.32 | wpwrak | it would seem that NaCl has a way to get out of the sandbox, using that chrome.usb API |
| 13:52.05 | whitequark | um, no, NaCl doesn't have access to that API. it can only talk to JS |
| 13:52.11 | whitequark | JS however has access to WebUSB |
| 13:52.48 | wpwrak | yes, but webusb seems to be something brand-new while chrome.usb seems to have been around for a while |
| 13:53.32 | wpwrak | also, it seems that chrome.usb just requires you to allow USB access while webusb has a lot more paperwork |
| 13:54.32 | wpwrak | more: https://developer.chrome.com/apps/app_usb |
| 13:55.05 | roh | i am not sure why anybody sane should allow a browser hw access that way |
| 13:55.08 | wpwrak | that looks more similar to webusb though. but still without the origins and stuff |
| 13:55.36 | whitequark | wpwrak: well, yes, you don't care about origins when you're in an extension |
| 13:56.06 | wpwrak | 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 ? |
| 13:56.38 | roh | wpwrak: then you need an api and some driver layer inbetween. |
| 13:56.39 | wpwrak | whitequark: ah, that sounds encouraging :) |
| 13:56.48 | whitequark | wpwrak: on second look I think you're right, chrome.usb is not webusb and I was incorrectly referring to it as such |
| 13:56.56 | whitequark | I assumed chrome.usb was just webusb exposed to plugins |
| 13:56.58 | roh | a browser should never have any hw access.. just run it as root if you allow it to access usb. |
| 13:57.20 | roh | i mean.. it could write to your harddisk then anyhow. so why bother sandboxing anyhing |
| 13:57.41 | whitequark | wpwrak: that's actually good news for you, I guess |
| 13:57.58 | roh | i understand what the idea is. and no. one cannot do that properly and secured in a broswer-plugin only. |
| 13:58.41 | wpwrak | this looks encouraging, too: https://github.com/ubinity/webhidapi-firebreath |
| 13:58.56 | roh | 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 |
| 13:59.46 | whitequark | roh: no such API to do that |
| 14:00.02 | whitequark | (which is rather unfortunate, yes) |
| 14:00.02 | roh | whitequark: huh? how does smartcard stuff work then? |
| 14:00.10 | whitequark | roh: via a plugin :( |
| 14:00.13 | roh | whitequark: an it does. ive seen people use it. |
| 14:00.31 | wpwrak | plugins for the win ! :) |
| 14:00.32 | roh | no. no 'plugins' in the classic way. it was something native |
| 14:00.39 | whitequark | and you're lucky if the plugin is not activex |
| 14:01.09 | roh | whitequark: it worked for every password field and also provided ssl keys |
| 14:01.18 | whitequark | hm |
| 14:01.37 | wpwrak | 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 |
| 14:01.41 | roh | i know who to ask. will do that |
| 14:02.17 | roh | anyhow.. such a thing is not easy to configure and needs nonstandard software. would not be plugnplay at all |
| 14:03.09 | whitequark | I've specifically checked just now and both chrome and firefox use a plugin |
| 14:03.30 | roh | whitequark: i think it was called 'certificate provider' |
| 14:03.32 | whitequark | or rather, various plugins from various smartcard vendors |
| 14:03.47 | roh | and its really ugly |
| 14:06.28 | whitequark | ok I see, yes, they do support this via NSS (on linux) and some windows mechanism |
| 14:07.02 | whitequark | so that would provide you PKCS#11 capability |
| 14:07.11 | whitequark | but filling password field means there was /also/ a browser plugin |
| 14:07.37 | whitequark | e.g. see this issue https://code.google.com/p/chromium/issues/detail?id=42073 |
| 14:07.50 | roh | meh |
| 14:08.00 | roh | so one needs both? |
| 14:08.19 | whitequark | I doubt many people using anelok will want PKCS#11 anyhow |
| 14:18.29 | wpwrak | task cards updated :) https://gitlab.com/anelok/doc/wikis/Task_hidapi https://gitlab.com/anelok/doc/wikis/Task_webusb |
| 14:18.54 | wpwrak | i love that git-based wiki. takes the pain out of managing wiki content |
| 14:21.58 | whitequark | you also need to figure out what to do on mobile |
| 14:25.44 | wpwrak | yes, there it's BTLE. apparently, for HIDAPI, there's no / not much of a difference between USB HID and BT HID |
| 14:26.14 | whitequark | yes, but I don't know what's the status on accessing BTLE from mobile browsers |
| 14:26.26 | whitequark | note that *nothing* on mobile has browser plugins |
| 14:29.15 | wpwrak | apparently, it may not be impossible: http://stackoverflow.com/questions/3960050/how-to-develop-plugins-for-the-native-android-browser |
| 14:30.25 | whitequark | there's no Android browser anymore on the stock firmware, it's just Chrome |
| 14:30.32 | whitequark | since... 4.2, I think? |
| 14:30.47 | wpwrak | yeah, it's from 2010 |
| 14:31.39 | wpwrak | this sounds fairly damning: https://support.google.com/chrome/answer/2710225?hl=en |
| 14:32.59 | whitequark | 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 |
| 14:33.17 | wpwrak | 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/ |
| 14:33.36 | whitequark | 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 |
| 14:34.28 | wpwrak | ;-))) |
| 14:34.33 | pcercuei | why would any sane person do that? :o |
| 14:35.01 | whitequark | some video player required it, I think |
| 14:35.14 | whitequark | but I uninstalled it pretty much immediately after, it was completely unusable |
| 14:36.30 | wpwrak | hmm, apparently they even shun extensions: http://www.omgchrome.com/chrome-android-extensions-not-planned-ama/ |
| 14:37.58 | wpwrak | 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 ?" |
| 14:38.18 | whitequark | the likely reason for that is when chrome adds extension... the first extension someone implements is an adblocker |
| 14:39.11 | whitequark | you may want to look into how lastpass on android works |
| 14:40.54 | wpwrak | hmm. there is a hint: https://helpdesk.lastpass.com/lastpass-mobile/lastpass-for-android/ |
| 14:41.12 | wpwrak | apparently 4.3 did something to make it easier |
| 14:42.58 | whitequark | ah, 4.3 added exactly an API for autofilling credentials |
| 14:44.22 | whitequark | hm, looking closer, it appears to be abusing accessibility APIs |
| 14:44.27 | whitequark | for screen readers and such |
| 14:44.29 | whitequark | well, close enough |
| 14:45.58 | whitequark | 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 |
| 14:46.06 | whitequark | that's actually better than I expected |
| 14:46.23 | whitequark | you'll still have to shell out $100 yearly and go through apple's ridiculous appstore review process |
| 14:51.54 | wpwrak | (accessibility) do you have a link ? |
| 14:52.18 | whitequark | your link exactly |
| 14:52.32 | wpwrak | oh :) |
| 17:01.40 | *** join/#qi-hardware pcercuei (~pcercuei@95.91.238.57) |
| 17:09.31 | *** join/#qi-hardware arossdotme-planb (~zxy@79-69-193-194.dynamic.dsl.as9105.com) |
| 17:27.10 | *** join/#qi-hardware woakas (~woakas@static.15.240.46.78.clients.your-server.de) |
| 18:05.14 | *** join/#qi-hardware wildlander (~wild@unaffiliated/wildlander) |
| 18:27.01 | *** join/#qi-hardware dandon (~dandon@185.16.52.184) |
| 18:53.45 | *** join/#qi-hardware arossdotme-planb (~zxy@79-69-199-64.dynamic.dsl.as9105.com) |
| 20:57.57 | *** join/#qi-hardware Luke-Jr (~luke-jr@unaffiliated/luke-jr) |