kscz's comments

This looks like a re-discovery of a 2014 University of Texas at Dallas paper - https://science.sciencemag.org/content/343/6173/868 ?

I am missing something? You can see the hackaday article about this here: https://hackaday.com/2014/02/21/researchers-create-synthetic...

Here is another, earlier iteration also from MIT: https://gizmodo.com/mits-new-plastic-muscles-could-bring-us-...

Well there's two important things to address there, and they're both a bit long-winded, but bear with me.

First, despite all the discussions of Uber's/Lyft's full-time drivers, there are some proportion of drivers who are just people looking to make an extra buck on their ride home from the airport and whatnot. These drivers really don't expect/require a lot of money, and are just padding their income driving somewhere they were already going. I had a friend with a six-figure income who would do Uber rides in San Diego just because it was an easy way to cover gas occasionally. This is important because it changes the market for taxi drivers - suddenly a regular and lucrative set of rides (to and from airports) have clientele who expect much cheaper rides - even if the cost those clients expect to pay can't support an individual working full time at that rate. But even if full-time drivers attempt to avoid the platform, the market has substantially changed - they can no longer get the same price for their rides. Now, this may just be a market correction, but let's look at the second factor...

Uber and Lyft and burning VC money to power their operation - Uber lost ~$1.1 billion dollars in Q1 2019 [0], and Lyft lost ~$1.14 billion in Q1 2019 [1]. These sorts of numbers tell us that Uber and Lyft are generating demand for an artificially low price for a service, which all but guarantees that the market for sustainably-priced taxi rides will be destroyed. Why would a customer purchase a ~$20 taxi fee when a VC-subsidised ~$10 ride exists?

The contention that Taxi drivers can "just not use Uber/Lyft" is pitting the depth of the pockets of taxi drivers against the pockets of Uber/Lyft's backers - it's not a reasonable expectation that taxi drivers can afford to wait out venture-capital subsidizing an unsustainable business model which destroys their livelihood in the meantime. According to the Federal Reserve in 2016, 46% of Americans reported that they would be unable to cover a $400 expense if some emergency came up [2]. I don't think we can look at Uber and say "Taxi drivers could choose not to use it" - it's looking at the choice to use the platform in absence of the context of venture capital and the support which exists for low-skilled workers against predatory employment practices.

[0] https://www.businessinsider.com/uber-earnings-q1-2019-losses...

[1] https://techcrunch.com/2019/05/07/lyft-lost-1-14b-in-q1-2019...

[2] https://www.washingtonpost.com/news/wonk/wp/2016/05/25/the-s...

Craigslist sellers decide on the price, how to exchange goods and money, etc. Uber and Lyft are not free marketplaces where drivers can offer a ride for a price they believe to be fair for their services - the platform owners decide the prices and the drivers are forced to accept that rate in order to get rides.

Sorry, you're absolutely correct - I had misinterpreted the dev board layout screenshots as the final phone layout screenshots.

That'll teach me to post after I should be asleep!

I'm a bit confused on the comment "Modern phones (and all the flagship phones) have had separation between their basebands and APs for years; a modern smartphone baseband is essentially a USB peripheral."

As far as I can tell [0], the flagship phones (i.e. everything except the iPhone) are pretty heavily invested in the Qualcomm integrated baseband CPU + general purpose CPU [1]. And unless something has changed radically in recent years, the baseband CPU has had direct DMA access to the same memory as the main CPU, and thus any vulnerabilities or backdoors in the baseband CPU have the ability to directly access memory.

With the rising prevalence of devices like the LimeSDR [2] putting the ability of intercepting and communicating with the baseband CPU, vulnerabilities in the baseband like this one [3] are even more of a risk than before.

I don't think anyone is arguing that Purism is going to have produced the world's most secure software, but the design space they've put themselves in allows them to be audited internally and externally - something that while you say "Apple and Google have spent a lot of money on it" I can't really verify that it's lead to a quality product. As flaws like Intel Management engine fiascoes have shown [4], even heavily audited code can have terrible flaws. The thing people don't like about the current approach with cell phones is that if the phone is too old you just have to throw it away because no one will update it. Purism is offering you something where you can throw away just the vulnerable modem or wifi card, and keep your phone. Even if you don't know of a flaw, you could purchase a different vendor's M.2 4G LTE card and swap it in, and make your attack surface different than other owners of the Librem 5.

There are other things which Purism will doubtless be way worse at catching/auditing, but honestly this is going to be like Linux: the benefit in terms of security is going to be that you are one of maybe 1,000 people using that device in that specific configuration, and you won't be worth exploiting.

[0] https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_sy...

[1] https://www.qualcomm.com/media/documents/files/snapdragon-80...

[2] https://myriadrf.org/projects/limesdr/

[3] https://arstechnica.com/information-technology/2016/07/softw...

[4] https://www.wired.com/story/intel-management-engine-vulnerab...

Hygon is just AMD's EPYC CPU [0]. I am uncertain if they will differentiate themselves more as time goes on, but at the moment almost the only difference in the kernel is that it has a different name.

I think you're more likely to see some ARM CPUs which have comparable performance to low-end and mid-range x86 before you see a new x86 competitor [1] - the overhead to making x86 perform well is just so high that I can't imagine anyone new bothering to get into the space. VIA has been in the market forever as the third seller of x86, and despite the theoretical benefits of entering into the datacenter CPU market, they've never made that leap (though I don't know enough about their history to know if they tried).

I'm hoping that ARM becoming competitive in the client CPU space ends up making the cross-compile overheads of enough drivers/kernel stuff that we can start to see some more diversity in the CPU market overall. I'm excited about RISC-V, especially now that they have shipping hardware you can play with today [2]. The Mill CPU sounds super cool in a bunch of ways, but the architecture has made so many decisions that I'm unsure will play out in practice I'm holding my excitement until I see real silicon somewhere [3]

[0] https://arstechnica.com/information-technology/2018/07/china...

[1] https://www.engadget.com/2018/08/16/arm-says-chips-will-outp...

[2] https://www.sifive.com/products/hifive-unleashed/

[3] https://en.wikipedia.org/wiki/Mill_architecture

The whitepaper linked in the upper-right is highly informative: https://www.shutterstock.com/labs/compositionsearch/static/c...

or for btrfs users out there:

btrfs scrub start /mnt/volume_name

In Rust overflows generally will cause a panic. So "2 + 2" will return 4 or panic if you're on a 2-bit system (they provide .saturating_add() and .wrapping_add() to get code that will never panic)

Thus, you could have caused a denial of service by crashing a rust-based Curl, but the crash would have been modeled and just uncaught.

It's mostly a question of mobile support: IRC (over TLS or otherwise) requires a continuous connection, where matrix and signal are designed to support polling a push notification endpoint.

Out of curiosity: what makes you say Matrix is over-engineered?

How about Open Street Map? http://osmand.net

It's not perfect, but it provides a good base of functionality, and gets you to big tour destinations. It will also get you to most restaurants in a big city, but it doesn't have hours of operation or star ratings, so it's less useful in that regard.

I wish there were more alternatives to Google Maps though. You're absolutely right that it feels indispensable to most people these days...

Riot can do audio and video calls, I've had good luck with it (currently gets used between my friendgroup instead of phonecalls). Check out http://matrix.org/ for the server implementation details and https://riot.im for the biggest client. Currently, it only supports 1-on-1 audiocalls/videocalls. No group calls yet.

Forewarning that while it supports end-to-end encryption for the chatting bits, the actual audio data is not encrypted. The call request/advertisement can be encrypted though!

I've found matrix[0] to work pretty well. Main downside is that the calls themselves are not end-to-end encrypted, but there is end-to-end encryption for the call setup. Riot[1] is available via f-droid[2]. You can host your own homeserver to prevent metadata leakage if you want, and run the TURN/STUN server to setup the calls if one of both parties are behind a NAT.

[0] http://matrix.org/

[1] http://riot.im

[2] https://f-droid.org/wiki/page/im.vector.alpha

You're right, anything can be monitored, but we shouldn't take that as a reason that we should lay down and accept it. You should assume that any sufficiently motivated person/organization/state can get access to your information. But what we should absolutely do is make sure that state actors and companies have to demonstrate that they are motivated to take that information. That they have to devote resources to getting it. We shouldn't hand them broad access to everyone's information just because any one person's information is possible to obtain.

But regardless of that point, your other argument feels to me like a discussion against the problems of mono-culture: we should all endeavor to have diversity of implementation, if possible. The more we can work towards federated standards and the ability to quickly pivot when someone loses our trust, the more capable we are of defeating attempts to undermine that trust. If we only have 1 implementation of signal and everyone uses it, then all an "evil" party has to do is find flaws in that 1 implementation. If we have 2 implementations, then some users are protected. If we have 1,000 implementations, and they all inter-communicate, then we have some hope that only some users are affected by each compromise. I'm digging matrix.org as a federated protocol, and I'm hoping that it takes root because it has many clients; an open, federated protocol; and the ability for me to run my own server.

I would advocate that even though we're relatively mono-culture on linux, supporting it at least gives linux access to the source code which would allow other implementations (anyone else keeping a close eye on Redox [1]? I know I am!). Support open protocols! Support federated protocols! I'll advocate that signal is a great, easy-to-use system for secure communication, and that the ideas of Signal are percolating elsewhere (see "olm" [2] the implementation of Signal's crypto protocol for matrix). But I would like to see stabilization in Signal leading to federation.

[1] http://www.redox-os.org/

[2] https://matrix.org/git/olm/tree/

The difficult thing is convincing people that something could go wrong with all the trust they're investing in the government and large corporations. The thing which I think has been most frustrating is that when demonstrable situations come up [1], people seem eager to dismiss them as "just a few bad actors" and not as evidence that it's a bad idea to continue investing trust. Watching people in interviews like those in the "Inside the Creepy Russian Internet" video [2], feels to me like they're resigned to the fate of having social networks know everything about them, not that they want them to know everything about them.

What I want people to consider, frequently, is whether or not we should fight these anti-privacy measures not because anything is wrong now, but because of who might eventually be given access to that information. We should fight to make sure that tools to oppress and enforce terrible regimes aren't freely available, even if we find the current leaders trustworthy. The current administration in the Whitehouse is trying desperately to dismantle the sweeping powers to exercise drone strikes without oversight [3], because the next administration doesn't feel as trustworthy to them.

I don't know that there is any downside to having the NSA know everything about you now. I don't know that it will be a bad idea within the next administration. But I know that it's a bad idea to let any random person have that trust, and I don't know that the election system has enough safeguards to prevent abuse by the next person elected. Or the next. Or the next.

[1] https://www.washingtonpost.com/news/the-switch/wp/2013/08/24...

[2] https://news.ycombinator.com/item?id=13102972

[3] https://theintercept.com/2016/12/06/after-8-years-of-expandi...

I think a big difference is the flags. At least for g++, if you don't specify -march=native -mtune=native you're going to take a performance hit. How much of a performance hit depends on the features.

The sorttest.zip Makefile has only the following flags specified: -O3 --std=c++11

Where bjourne has: -O3 --std=c++11 -fomit-frame-pointer -march=native -mtune=native

I might rerun your tests with bjourne's additions!

Well, I'm not really qualified to talk about the BoM costs relative to the sale price because I don't do manufacturing, but the Beaglebone Black team claims they charge at margin based on the BoM: "Currently there is $0 margin on these boards [...]" [0]. I normally compare the BeagleBone Black to the Raspberry Pi in terms of cost: the initial Raspberry Pi cost $35, but came with no internal flash. So with 4GB of internal flash the BBB seemed like a reasonable deal at $50. If you're willing to go without HDMI, the Beaglebone Green is $39 [1]

The Allwinner CPUs are always extremely cheap, but I don't support the company because of what jerks they are to the open source community [2]

[0] http://elinux.org/Beagleboard:BeagleBoneBlack#Revision_C_.28...

[1] http://www.digikey.com/product-detail/en/seeed-technology-co...

[2] https://en.wikipedia.org/wiki/Allwinner#Linux_controversies

But the CHIP uses an Allwinner CPU, and for those of us who like to support manufacturers that actually play nice with the open source community: the CHIP is a no-go.

The specific CPU in the CHIP appears to have mainline support, so it's less terrible than things like the "Banana Pi M2+" ( http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B ), but I like to support CPU manufacturers who aren't Allwinner.

Well, I think we'll have to agree to disagree here on terminology!

When a browser gets a malicious advertisement or a user gets a malicious cross-site scripting attack, I consider that remote exploit. Yes, it required the client to do something (i.e. visit a malicious page), but there are plenty of things which you can do to create that state without much user interaction. If I might ask, what do you call attacks like these?

I agree though that my Jetty example wasn't a good one, I was just making the point that the exploit was still in client code (i.e. something running on the victim's machine).

I think perhaps the point that the others in this thread are making should be rephrased: you execute untrusted code in the browser, and giving that untrusted code effectively direct access to the USB peripherals is frightening. If you trust some website with "webUSB permissions", and that website has a cross-site scripting vulnerability, you've given a remote actor the ability to manipulate some USB device(s).

That being said, I'm a little confused about your definition of "remote" access. If I have a jetty server with a remotely exploitable hole in it, someone who exploits that hole is depending on me running a local client, but I would still consider it a "remote" exploit. In the same vein, someone running a browser that I can compromise with purely code on external websites is still being "remotely exploited." The attack vector requires the client to visit a specific page or click a specific link, but I didn't have to walk up to their computer and insert a USB stick. That's what makes the attack a "remote" attack for me.