keithwinstein

18 ms·

91.
by keithwinstein 6y ago
ObShameless reminder that https://puffer.stanford.edu remains free of charge. The site streams San Francisco affiliates and local stations of NBC/CBS/ABC/PBS/FOX/CW as part of a university study on video
92.
by keithwinstein 6y ago
You know, I totally buy that 70% of the vulnerabilities in complex C++ code relate to memory safety, especially in something like Chromium, which is incredibly complex and includes a lot of third-party code that wasn't always designed
93.
by keithwinstein 6y ago
For guardian-agent to live up to its security claims, it needs to correctly deny requests on the "unhappy path." So yeah, that's a primary goal. As far as we know it lives up to that. Requests are locked to (a) [identity of r
94.
by keithwinstein 6y ago
Thanks for this. Wanted to put in a pitch for Dima Kogan's more-secure way of doing ssh-agent forwarding: https://github.com/StanfordSNR/guardian-agent It works with SSH and Mosh. The basic idea is that before agr
95.
by keithwinstein 6y ago
Ok, but that decision would have to be made by the project maintainer, in this case Google, not the person using Bazel to compile protobuf. (And not particular to Bazel -- a developer can make any build system effectively hermetic by vendor
96.
by keithwinstein 6y ago
I've been confused for a while about the common claim that Bazel gives "full hermeticity" of builds -- it doesn't seem to be true in practice (at least for packages with system dependencies). Maybe you can help me clear
97.
by keithwinstein 6y ago
No -- Mosh is careful to make sure that a transient network attack can only result in a transient application-layer consequence. So a single misrouted IP datagram can't permanently affect the connection. Mosh does this at the cost of
98.
by keithwinstein 7y ago
That's true in practice with current radios, but it was a beautiful discovery in 2006 that it's not true in theory! In a world where radios are perfect and nodes cooperate to do decentralized beamforming, the capacity-per-node of
99.
by keithwinstein 7y ago
You're right that the government did a big investigation and ultimately didn't find a major problem with the software/electronic throttle control system, but mistaken about the other causes of unintended acceleration. Ultimat
100.
by keithwinstein 7y ago
Hmm, I don't quite follow (but I know you were there!). I know there was disagreement about the right way to do multihomed hosts on the Internet; RFC 1122 gets at this with its discussion of the "strong ES model" vs. "we
101.
by keithwinstein 7y ago
Thanks for your kind words -- you're certainly welcome to contact us if you think we can help. Yes, as I wrote elsewhere here, it would probably be possible to do everything Salsify does within the context of WebRTC, if you get to chan
102.
by keithwinstein 7y ago
Well, we've never installed a rootkit on anybody's computer, so at least we've got that going for us... More to the point, we don't have an empirical end-to-end measurement of Zoom the way we do for Skype, FaceTime, Goog
103.
by keithwinstein 7y ago
Thanks! (1) Salsify is mostly about how you control the video encoder (e.g., a VP8/VP9/AV1/H.264/H.265 encoder) and transport protocol (e.g., RTP/UDP). H.264, RTP, and UDP themselves don't say anything about
104.
by keithwinstein 7y ago
This is an interesting question! I think getting our codebase to use the WebRTC framing and setup would probably not be that hard. We could probably use the same libraries that WebRTC.org is built on (libjingle, etc.), and maybe even just
105.
by keithwinstein 7y ago
Yeah, that would definitely help if it were efficient. In general the reason people don't use scalable/layered/incremental codecs in 1:1 video transmission is that they're less efficient than just encoding a single strea
106.
by keithwinstein 7y ago
Realistically it would probably be a major refactor to adapt the WebRTC.org codebase to a Salsify-style design. The WebRTC.org codebase is about a million lines of code (about half of which is vendored third-party code, e.g. libvpx) so any
107.
by keithwinstein 7y ago
It does a different thing. RTSP is mostly about control and framing. It doesn't specify any particular algorithm to estimate the network's capacity, how a video encoder should try to match that estimated capacity, or how to recove
108.
by keithwinstein 7y ago
Hi all -- Salsify co-author here. Surprised to see us here again, but happy to be part of the conversation (here's a previous one: https://news.ycombinator.com/item?id=16964112 ). This work was led by my student Sadjad
109.
by keithwinstein 7y ago
Well.... now that I've gone to read the code again, you're absolutely right that I was too hasty in calling it the "byte-by-byte" state. It's more like the "slice-by-slice" state. libmpeg2 goes header-by-h
110.
by keithwinstein 7y ago
I think the MPEG people and the authors of pl_mpeg probably just differ on how "very hairy" it is to represent the byte-by-byte state of a single-threaded decoder. In other words, how hard is it to create a continuation object tha
111.
by keithwinstein 7y ago
The core of libmpeg2 is 3,810 lines of C (not including any systems-stream demultiplexer or audio decoder) versus about 2,400 for pl_mpeg.h. So not dramatically larger. On the other hand, for progressive-scan 30fps video on computers withou
112.
by keithwinstein 7y ago
Sure -- we actually already have an OpenWhisk backend. The IR is sufficiently stupid that it's pretty easy to write a new backend. At least a low-performing one -- it gets harder if you want to use (a) persistent workers [instead of in
113.
by keithwinstein 7y ago
(Co-author here) It really depends (see Figure 2). On the question of Lambda vs. EC2, EC2 instances take much longer to start. So depending on the job, to get the performance you can get with a "burst parallel" flock of Lambda wor
114.
by keithwinstein 7y ago
Finally, note that Zoom effectively does not pay for bug bounties, so researchers should think twice about donating their expertise to a selfish for-profit corporation I've read this a few times and am curious if this has really beco
115.
by keithwinstein 7y ago
There's a passage of Carl Sagan's "Contact" that's on point and interesting to read 34 years later. The billionaire who helps to decode the Message (from outer space) and ends up building the working copy of the Mac
116.
by keithwinstein 7y ago
Low-latency packet video can work incredibly well over a dependable network connection (with a known constant throughput and no jitter), low end-to-end per-packet latency, and good isolation between everybody's microphone and speaker
117.
by keithwinstein 8y ago
Here's a plug for our mahimahi tool (available in Debian and Ubuntu with an "apt install mahimahi", and at https://github.com/ravinet/mahimahi ). The intention is to have a set of easy-to-use network emul
118.
by keithwinstein 8y ago
I believe your calculations are too high by a factor of 1000... 53 bytes/(typical tweet) * 6000 typical tweets/second is 318 KB (or 0.3 MB) per second, not 318 MB.
119.
by keithwinstein 8y ago
Not sure I quite follow -- the video goes through the same pipeline that it would with conventional DASH (MSE to a video element to whatever decoder the browser provides), and the performance is basically the same. You're welcome to tr
120.
by keithwinstein 8y ago
One (emerging) area is ABR video delivered over a WebSocket. Throughput estimation can be done using server-side TCP statistics that are updated at each ACK segment (the tcp_info structure includes a delivery_rate member that is pretty help

More ›