Hacker Newsnew | past | comments | ask | show | jobs | submit | janinge's commentslogin

OpenWRT also got it packaged. So a solid and easy way to run it is to just throw the client on some old routers with OpenWRT support, connected to $20 USB DACs with S/PDIF.

https://www.behringer.com/product.html?modelCode=P0484


Yes, you wouldn't get this running on an existing smart speaker (without first rooting it and some serious hacking).

If you'r in the Apple ecosystem and are using AirPlay with your smart speaker(s), it's however possible to also play synchronized audio across to your own DIY speaker setup, using another open source project.

https://github.com/mikebrady/shairport-sync

Or you could of course choose to only use your old dumb speakers with this, and they will pop up as easily selectable sound output devices on all Apple devices connected to your network.

Or combine it (and librespot[2], owntone[3]...) with Snapcast to create a virtual speaker for your whole house that shows up everywhere.

[2] https://github.com/librespot-org/librespot

[3] https://github.com/owntone/owntone-server


Yes. If you’ve bought a consumer router, and not an “access point”, it will likely have a Ethernet port labeled WAN. Due to this label, the OpenWRT profile for this model will most likely also set up this port as a WAN port for you by default (where it requests DHCP from somewhere and applies NAT and some basic firewall rules). Just delete this interface, and make the LAN network also span the WAN port. Then disable DHCP and IPv6 RA on the LAN interface. Your router is now a dumb “access point”.


You could also make the OpenWRT router connect trough your phone’s hotspot feature temporarily, while you set up your primary connection. Three clicks in the GUI is all that’s needed to join a wireless network for WAN connectivity.


Zoom also use the Selective Forwarding Unit (SFU) architecture. Or a central server that kind of "mix" streams and send them to all participants, if you will.

Jitsi Videobridge does this by receiving simulcast streams from each participant. This server individually picks out streams and qualities that will fit in each recipient's downstream pipe based on measured bandwidth and configured priorities (e.g. you could choose to give more bandwidth to those who are actively speaking, or shut down all but the last N speakers video streams).

Yes, the available network bandwith on a Jitsi Videobridge could be a bottleneck. Each meeting need to fit on a single bridge instance. However, using common servers connected at 1 Gbps or 10 Gbps, it shouldn't be any problem to have meetings with substantially more than 2-4 people. Say a HD stream from most webcameras outputs 3 Mbps at full blast, with 50% overhead due to the simulcasting. That's over 2000 participants on a single server connected at 10 Gbps, all receiving all video streams in full quality.

For meetings with 2 participants the streams run peer to peer, so here you get the best possible latency and quality.

We've set up Jitsi on a VPS instance at a nearby provider, and have not seen any problems with meetings of 10-15 people. Stability and performance also outperforms all the other solutions I've tried. There's currently a bug in Firefox's simulcast implementation, so if you have any participant using this browser, this feature gets disabled for everyone. Even with this issue, I haven't noticed anything but excellent performance with this few number of participants.

The following article might also be interesting.

https://bloggeek.me/webrtc-vs-zoom-video-quality/


It is not, or was not? Did this issue get rectified by Telegram?


No, they still use MTProto and not an AEAD construction.


I was referring to the padding attack. Did they patch this?

And are there any property of MTProto that makes it infeasible to replace AES IGE in a later revision of the protocol?


The problem isn't IGE. It's that they're using SHA1 (not HMAC-SHA1) in a "MAC and Encrypt" construction.


I really like this feature. A page redraw generally takes less time than the time needed for my eyes and brain to re-parse the page. When I have to stare at a blank page for a varying amount of time after having decided to go back, the entire navigation process feels very sluggish and slow. Using other browsers I find myself opening a lot more temporary tabs to account for this. Swipe and hold is also nice when you just need to go back to reread a few sentences, etc.

Most pages shouldn't need a refresh when you go back after a few seconds or minutes. What annoys me are websites that set stupid expiry times or Cache-Control values.


Having a modernized pause/break key on your keyboard can also be handy if you ever have to use software that acts stupid on purpose, like these "Safe Exam LockDown Browsers" that some schools and universities around here have started forcing upon their students. Software like this typically just run a timer or similar to make sure that only their windows are running in the foreground, but sending them a SIGSTOP stops this annoyance.


This problem is mentioned in the article.

"Mastering engineer Bob Ludwig created ultra-loud master of Led Zeppelin II, but his version was pulled when it skipped on a record player owned by Atlantic boss Ahmet Ertegün’s daughter"


For that to work the networks themselves would have to securely distribute a list of locations, or it would have to be configurable on the devices. Many business and educational networks (like eduroam) span multiple locations. Even my "home" network is available multiple places (home, cottage, boat...).

Smartphones mostly use wireless networks and cell towers to determine their approximate location, which can be easily spoofed, except for the current active cell (which could be miles away). If devices had to acquire GPS fix every time they reconnected to a network, batteries would drain much faster. And satellite navigation doesn't work properly indoors. Civilian GPS can also be spoofed.

Manufacturers would probably prioritize usability over rectifying such a "problem" which never had bothered anyone before, except maybe if there was PR involved. I think there's still no way to list all configured wireless networks on iOS devices? Fixing this would probably improve privacy more (if people cared) than this randomized MAC feature.


I am not really sure why networks would have to distribute a list of locations: the default for connecting is simply 'do not autoconnect or look for any network I have not already connected previously in this location'.

If the user does not want to incur the GPS battery impact triangulating with cell towers already should give you enough location information not to look for your home network at work, or the network you saw in Spain last month when you are in the Netherlands.

And finally obviously everything can be spoofed, however I don't think it's reason enough not to have a minimal set of protections: the user can decide how much battery to dedicate to the task (i.e. no checking, cell tower checking, gps checking in increasing order of impact)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: