<whitequark>
a web browser that is proven to never leak your private data to third parties
<whitequark>
(assuming there is no combination of webkit and kernel exploits that allow malicious code to escape sandbox, which is a pretty good assumption)
<ysionneau>
Chromium and Firefox are starting to get there in term of sandboxing and security
<ysionneau>
small steps by small steps
<whitequark>
"starting to get there"?
<whitequark>
Chrome pioneered the sandbox technique years ago
<ysionneau>
getting there* ?
<ysionneau>
yes
<ysionneau>
it's starting to become nicely secured
<ysionneau>
so I'm not sure running in a chroot will add much security , maybe not today but in the short term
<whitequark>
chromium already effectively runs every tab into chroot, or in fact in a better thing than chroot
<whitequark>
secconp
<whitequark>
*seccomp
<ysionneau>
chromium is using seccomp, it filters
<ysionneau>
syscalls
<ysionneau>
yes
<whitequark>
you have read(), write(), exit() and some other one
<whitequark>
that is all
<ysionneau>
indeed
<larsc>
all you need ;)
<ysionneau>
if their list of syscalls is correct then it's secured
<ysionneau>
I bet they don't filter everything
<ysionneau>
it's very hard to do so
<ysionneau>
but it's getting there
<larsc>
there have been breakouts from the sandbox in the past
<DocScrutinizer05>
whitequark: looks good
<ysionneau>
Mozilla is doing the exact same for B2G (boot2gecko, AKA firefox OS)
<larsc>
and there probably will be breakouts from the sandbox in the future
<larsc>
it's still better to have sandbox than not have one though
<ysionneau>
the theory would be to only allow read/write/exit
<ysionneau>
I bet they allow more
<larsc>
s/have one/have none/
<qi-bot>
larsc meant: "it's still better to have sandbox than not have none though"
<whitequark>
ysionneau: they filter everything for browser tabs
<whitequark>
they use seccomp-bpf for flash
<ysionneau>
even open? and mprotect?
<whitequark>
although that is somewhat of a futile endeavour
<whitequark>
sure
<whitequark>
why would a tab require open?!
<ysionneau>
well it depends
<ysionneau>
for instance on Android
<ysionneau>
for the android app
<ysionneau>
err not android app
<whitequark>
ah, the fourth one is sigreturn
<ysionneau>
for the Chrome OS I mean
<whitequark>
ysionneau: it's not the tab that accesses the file
<larsc>
I think we might realize not too far in the future that the micro-kernel folks were right
<ysionneau>
whitequark: indeed the usual stuff is to make the parent process do the open() and send you the file descriptor via socket
<whitequark>
ysionneau: no recvmsg
<whitequark>
it would just transfer the data to the tab with a multiplexed channel, I guess.
<ysionneau>
recvmsg on a socket
<ysionneau>
to receive the file descriptor
<ysionneau>
well actually you have several techniques for passing a file descriptor
<ysionneau>
13:56 < whitequark> they use seccomp-bpf for flash < so i guess they have a smaller list of forbidden syscalls for flash then
<whitequark>
yes
<larsc>
It restricts a thread to a small number of system calls:
<larsc>
exit()
<larsc>
write()
<larsc>
read()
<larsc>
sigreturn()
<ysionneau>
larsc: then you can use BPF, and you can use BPF to accept or refuse a syscall
<ysionneau>
and have whitelist or blacklist
<ysionneau>
you can then either kill the process , or trap in a handler
<DocScrutinizer05>
anyway I think I'll just run browser under a dedicated user that has no access to *anything* outside of own $HOME
<ysionneau>
whitequark: when your browser is not just a browser, but for instance an "OS" like firefox OS or Chrome OS
<ysionneau>
then it's harder to just refuse everything except read/write/exit
<DocScrutinizer05>
or even better: in a VM
<ysionneau>
because of libhardware crap that want to open /dev/files to take wakelocks or to take locks on framebuffer etc
<ysionneau>
it's usually hard to forbid open()
<ysionneau>
or mprotect (for JS JIT)
<ysionneau>
but they will find a way :)
<whitequark>
DocScrutinizer05: VMs can be exploited too
<larsc>
ysionneau: well only a subset of the browser runs in the sandbox
<ysionneau>
the 'content process'
<ysionneau>
(mozilla term)
<larsc>
you have a 'trusted' part, that you assume is bug free
<ysionneau>
yes
<ysionneau>
and which interacts less directly with the content
<ysionneau>
(html/js/css)
<larsc>
if the sandboxed thread can get the trusted thread to do stuff it shouldn't do you have broken out of the sandbox
<ysionneau>
yep indeed
<ysionneau>
it's still really not perfect yet
<ysionneau>
but it's better and better :)
<larsc>
and if I understand things correctly with that quark browser they verified that the trusted part is bug free
<ysionneau>
frankly I think it's hard for hackers to exploits bugs in the browsers nowdays
<larsc>
(assuming that their formal verification is bug free)
<larsc>
which we probably shouldn't
<ysionneau>
I'm really amazed each time I hear about a new 0day on a browser
<ysionneau>
the guy who worked on it must be very clever
<whitequark>
larsc: formal verification *is* bug-free, that's the point of it
<DocScrutinizer05>
whitequark: I think any usual exploit via browser will have a hard time to figure it's running in a VM and to breakout and taint my host system
<ysionneau>
even when you found a bug, you escaped ASLR, canaries on the stack, X^W memory mappings etc, then you can execute your payload ... in a sandboxed process ... you can't do all the syscalls you want etc
<ysionneau>
very hard
<whitequark>
larsc: the possibility of Coq being flawed in some respect that not only escaped the attention of the authors but also somehow leads to an exploitable vulnerability in the code proven correct by Coq is so vanishingly small, it's almost not worth consiering
<whitequark>
DocScrutinizer05: hahaha, you seriously underestimate today's malware
<DocScrutinizer05>
well, then HTML is dead
<whitequark>
it is almost always able to detect VMs, and frequently able to exploit them, though a more usual mode of operation would be to not exploit the system at all
<whitequark>
since it's likely to be a honeypot or a security researcher's machine
<whitequark>
no, it's not
<whitequark>
you don't avoid going out on the street because a meteorite can hit you on the head
<DocScrutinizer05>
yes it is, since when a VM doesn't help then you need a separate physical machine to use HTML
<whitequark>
what I mean is, no measure you can take (short of 100% formally verified sandbox stack) will provide you with guaranteed security
<ysionneau>
anyway, isn't HTML turing complete ?
<whitequark>
no
<ysionneau>
or maybe it's XML
<whitequark>
not even with CSS
<whitequark>
neither is XML
<whitequark>
a browser with JS disabled is almost entirely harmless, the only thing left is image parsers
<DocScrutinizer05>
aha!
<whitequark>
anyways, two things
<whitequark>
1) nothing you can practically do will provide you with 100% guarantee. but you can do 99.99...% for arbitrary number of 9's
<whitequark>
2) your machine is not really interesting anymore these days
<whitequark>
unless you are specifically targeted, and if you are, you *will* be owned
<whitequark>
what is interesting is your data elsewhere, and it is usually waaaay easier to access than hacking browser, secured by best minds ever
<ysionneau>
I don't remember where I read that, but I saw somewhere that XML language was "adjectif" which then proved it was not possible to ever parse it correctly, there will ever be a document that will not get correctly parsed
<ysionneau>
is that BS?
<whitequark>
ysionneau: perhaps for XML--definitely not for HTML
<larsc>
with drive by attacks it's a bit like in nature you don't have to be the fasted gnu in the herd, just faster than the slowest gnu in the herd
<ysionneau>
whitequark: ok
<larsc>
if somebody targets you though you are screwed
<whitequark>
if somebody targets you, you probably shouldn't even try, it's an exercise in futility
<whitequark>
otherwise... first you need to understand your threat model. without that you are stumbling in the dark
<whitequark>
DocScrutinizer05 probably doesn't have a coherent one :p
<ysionneau>
sure, security without threat model is pointless
* DocScrutinizer05
wonders why he feels pissed again
<larsc>
well that probably means that the sensor has a programable threshold and until the motion does not reach that threshold the motion is not reported
<larsc>
-> no IRQ -> CPU sleeps
<larsc>
your typical accellerometer is able to detect samll changes, e.g. the desk is vibrating because somebody tramples on the floor
<larsc>
or because you are typing on your keyboard
<nicksydney_>
larsc: yes the sensor works that way...what i was trying to figure out whether this is a new kind of sensor or this is the same accelerometer sensor but with 'smarts' built into the firmware
<larsc>
nicksydney_: all kinds of sensors have such a threshold
<larsc>
e.g. the adxl345 and that one is a few years old
<nicksydney_>
Kionix & ST LIS3DSH
<larsc>
I think what is special about them is the programable statemachine
<larsc>
rather than a fixed function pipeline
<wpwrak>
(neo900) heh, 358 ! and almost at 75 kEUR. now we know where he went, to celebrate !
<nicksydney_>
larsc: "The LIS3DSH is an ultra low-power high performance three-axis linear accelerometer belonging to the “nano” family with embedded state machine that can be programmed to implement autonomous applications."
<nicksydney_>
screen orientation, Tap/Double-Tap, step recognitio n, and more."
<nicksydney_>
state machines that can be defined with up to 16 states each, along with programmable actions initiated at state transitions. This allows users to implement a wide range of recogniti on algorithms, such as wake-up, free-fall,
jekhor has quit [Ping timeout: 252 seconds]
porchaso0 has quit [Read error: Connection reset by peer]
porchao has joined #qi-hardware
jekhor has joined #qi-hardware
rz2k has quit []
<apelete>
Hi larsc
<larsc>
sup
<apelete>
been a while, hope you're doing well
<apelete>
larsc: are you at work ?
<apelete>
I've resumed debugging the dma in jz4740_mmc.c and I think I'll need your help
<larsc>
ok
<apelete>
we can talk about it later if you're busy right now (I was reading the channel backlog just now and noticed you were there)
<larsc>
I can neither confirm or deny that I'm currently at work ;)
<larsc>
nor
* pcercuei
looks
<apelete>
haha, ok ;-)
<pcercuei>
he's at work :)
<apelete>
pcercuei just dropped the ball ;-)
<apelete>
no problem, we'll talk later
<wpwrak>
after he was reassigned to the NSA he's always been rather vague about what he's doing
atommann has quit [Quit: Leaving]
<apelete>
:)
jekhor has quit [Ping timeout: 252 seconds]
porchao has quit [Read error: Connection reset by peer]
<wpwrak>
yes, i've been watching their progress. it does seem that they've started shipping. yet people are still heavily guessing
michael_lee has joined #qi-hardware
sb0 has quit [Ping timeout: 252 seconds]
<rjeffries>
industrial design is not bad. Is tehir display about same as your anelok, or smaller?
<rjeffries>
wpwrak fwiw I think your jog wheel will be a nice user input method. I still dream that someday somebody will mod your code so the character being selected is displayed 2x or 3x teh size. but am NOT holding my breath.
<wpwrak>
it may be the same size. in any case very similar
<wpwrak>
(wheel) i'm actually gravitating towards a slider. results so far don't look too bad.
<wpwrak>
and the password input was just a very very early demo. nothing final there :)
sb0 has joined #qi-hardware
michael_lee has quit [Remote host closed the connection]
<wpwrak>
(slider experiments) i made a very simple slider sensor made of two triangles, one of them ground, the other the actual sensor. the signal strength is pretty good.
<wpwrak>
what doesn't work so well are a) fall and rise times (that should be mainly a question of proper filtering - right now i just use the raw samples without further ado), and
<wpwrak>
b) high variability depending on finger position (e.g., whether a little above or below the sensor or moving diagonally across it) and finger pressure
<wpwrak>
the data i can gather doesn't look as if it was sufficient for auto-calibration of all the relevant parameters (i could auto-calibrate "idle", but there's no good way to determine, for instance, the values at the left and right border of the sensor, without actually asking the user to put a finger there)
<wpwrak>
however, if i had little more information, i could probably just eliminate the variable common offset and multiplier
<wpwrak>
this "little more information" could come from turning the ground triangle into a sensor, too. that would add a second channel and give me an essentially complementary value
michael_lee has joined #qi-hardware
<wpwrak>
that's still fairly rough, but then, we don't need superb precision there anyway
<wpwrak>
it's more about detecting things like "left tap", "swish to the right", and so on
rjeffries has quit [Ping timeout: 240 seconds]
<apelete>
<wpwrak> (wheel) i'm actually gravitating towards a slider. results so far don't look too bad.
<apelete>
is the jog wheel that bad ? me would take mechanical input method over touch anytime (unless it's really bad)
<wpwrak>
the wheel feels reasonably nice but has many drawbacks: 1) high cost - it's the 2nd most expensive component in the design (after the display), 2) size - it's big and defines the minimum thickness of the whole device,
<wpwrak>
3) sourcing risk - there's only one source i know of, so if that one dries up, it may be difficult to find a replacement, and even less a mechanically identical one,
<wpwrak>
4) wear - it can break due to intense use, particularly in the presence of dirt or other contaminants,
<wpwrak>
5) wear 2 - it produces (a little) mechanical stress on the PCB,
<wpwrak>
6) limited flexibility - all you can do is press the button and turn left or right, while a slider could have multiple tap zones and perhaps also a variable resolution
<wpwrak>
7) makes case design more demanding because the case needs fairly precise clearance around the wheel. too much and it will look sloppy. too little and the wheel will rub against the case.
<apelete>
that's a lot of limitations indeed
<apelete>
oh well... :-(
<wpwrak>
advantages of the wheel are: a) feels nice, b) gives anelok a unique look, c) very clearly defined behaviour (things are either on or off, no calibration required)
<wpwrak>
regarding c) of course, rotary encoders have a tendency of getting bouncier with time, and eventually they bounce more than the debouncing algorithm expects ...
<wpwrak>
ah, and advantage d) no power required in standby.
rz2k has joined #qi-hardware
<wpwrak>
regarding a), larger amount of rotation don't feel so nice, though. so a slider should be more pleasant there, too, since you just move the finger back and forth, without having to perform a proper rotation.
<apelete>
and drawback 3) seems to be a real problem too
<wpwrak>
yeah, it's the sort of risk i very strongly dislike
<wpwrak>
DocScrutinizer51: wouldn't you agree, about sourcing risks and the fun it is when parts turn into unobtainium ? :)
<wpwrak>
actually, i should make a little video of the critter i have this far
<apelete>
w00t, shiny new video :-)
arielenter has joined #qi-hardware
<wpwrak>
video shot. now the post-processing ...
jekhor has joined #qi-hardware
atommann has joined #qi-hardware
pcercuei has quit [Ping timeout: 240 seconds]
jekhor has quit [Ping timeout: 264 seconds]
kristianpaul has quit [Quit: leaving]
kristianpaul has joined #qi-hardware
kristianpaul has quit [Changing host]
kristianpaul has joined #qi-hardware
<sb0>
grrr, how to open a .lib created with kicad libedit?
<sb0>
it won't show it in "current library" even after adding its path to the search list
* sb0
will soon open altium designer again
<sb0>
why didn't they simply have a normal file->open dialog box?!?
<sb0>
oh and saving a project file is the same crap. you can't select a path...
<sb0>
but you can zip and unzip files from the menu. useful feature, that.
<sb0>
seriously even setting the name of the project file is a struggle
pcercuei has joined #qi-hardware
<sb0>
right click on it, and it proposes "New directory"
<sb0>
wtf
<sb0>
ah, re. the library you have to 1) go in eeschema preferences 2) add it specifically in the list of libraries. adding the search path is not enough.
<sb0>
phew
<sb0>
usual open source UI design
michael_lee has quit [Quit: Ex-Chat]
arielenter has quit [Quit: Leaving.]
arielenter has joined #qi-hardware
<wpwrak>
;-)
<wpwrak>
hint: when you begin your project, save the "preferences". that's your .pro
<wpwrak>
then exit eeschema and add libraries directly to the .pro file
<wpwrak>
likewise for cvpcb and pcbnew
<wpwrak>
warning: pcbnew will delete the libs you added for cvpcb and replace them with the default list
<wpwrak>
so make sure you keep an up to date copy of your .pro around (e.g., in git)
<wpwrak>
and yes, agreed on the suckishness of library handling
<wpwrak>
countless hour of expert work must have been poured into pessimizing the user experience there ...
atommann has quit [Quit: Leaving]
<sb0>
I think I'll soon cut my losses and get back to altium
<sb0>
now trying to create a footprint, and I can't even figure out how to open the damn footprint editor
<sb0>
since they put the schematic symbol editor in the eeschema tools menu, I thought they would put the footprint editor in the pcbnew tool menu, but NO
<sb0>
that would be intuitive
<apelete>
larsc: are you there
<wpwrak>
don't use the footprint editor. use fped.
<wpwrak>
the footprint editor is somewhere there but it really really sucks
<sb0>
I'm also noticing that Gerber export is missing from "Fabrication Outputs" in pcbnew. since this is the feature that everyone is going to use to make any PCB, it's only logical they hid it somewhere else, preferably in another tool...
<larsc>
apelete: yes
<sb0>
oh, it's an ICON
<sb0>
whoa
<sb0>
did anyone, like, thought about the UI? or did every programmer add some option here and there, without any coordination and in the way that was easiest to code?
<larsc>
sb0: they a strong belivers in natural evolution of UIs rather than intelligent designed UIs ;)
<larsc>
survival of well works at least somehow
<wpwrak>
gerber is in "plot"
<wpwrak>
(neo900) drums, please ! 359 and crossed 75 kEUR.
<wpwrak>
dos1: what kind of marketing stunt did you guys just pull off ? :)
<dos1>
wpwrak: woah, just looked few minutes ago and it was 358
<dos1>
wpwrak: do you have some kind of automated notifications of something? :D
<apelete>
larsc: so, about dma on jz4740_mmc.c
<dos1>
well... we're working on marketing stunt right now, but I guess that doesn't count :P
<apelete>
was wondering where I can put a breakpoint or printf to see the beginning of data transfers in dmaengine