Data Consolidation: Infochimps Buys YC Startup Data Marketplace - <AUTHOR> http://techcrunch.com/2010/12/14/data-consolidation-infochimps-buys-yc-startup-data-marketplace/

<comment><USER2> I was about to say "talent acquisition" but given they're keeping the tech it's probably not the right term. But the price point seems likely to be about that of a talent acquisition.

<comment><USER3> Yup, not a talent acquisition. Matt and I have both moved on to other things. I'm working on a retail initiative at <http://www.propersuit.com> if anyone's interested.

<comment><USER4> Just out of curiosity, what makes Proper Suit better than Indochino or others? Also, where are your suits made?

I've never bought a suit online, but am considering.

</comment></comment></comment><comment><USER5> This seems like a win for everybody: Infochimps gets to build its business, YC-funded founders get to exit profitably and move onto another project, Paul Graham & Co. claim another successful start-up, and YCombinator's share of the buyout money can fund more start-ups.

<comment><USER2> I'm not sure YC made money out of this one, certainly not by angel standards. Angels invest with the aim of a 10x exit, because that's what they need from the successes to cover the cost of the failures (probably less in YC's case as they have a lower failure rate).

15k at 6% is a 250k valuation, Infochimps just took 1.2 million of investment themselves, so it's questionable whether they got a 1x multiple, a 4x+ multiple is out of the question. Infochimps don't have that kind of money.

</comment></comment><comment><USER6> Infochimps is bringing in the DataMarketPlace user base and community to expand its data sources and resources exponentially. This is only the beginning of what Infochimps could be. :)

<comment><USER7> I agree. Infochimps has a whip-smart group of folks and they're rapidly acquiring the resources needed to be the major player in the data market. Not only that, but knowing a lot of them, they're genuinely decent, helpful people. It's great to see another Austin startup rocking and rolling.

<comment><USER8> Thanks Cody!

</comment></comment></comment><comment><USER9> Congratulations to both Data Marketplace and Infochimps. You guys are rockin this space.

</comment><comment><USER10> One marketplace to rule them all! Man o man, too much LoTR.</comment>


Microsoft Surface Duo - <AUTHOR> https://www.microsoft.com/en-us/surface/devices/surface-duo <comment><USER2> Previous discussion from five months ago. [1]

As far as I can tell, there's no new information on the linked page, so I'm not sure why it's resurfacing (ba dum tisss).

[1] [https://news.ycombinator.com/item?id=21137450](https://news.ycombinator.com/item?id=21137450)

</comment><comment><USER3> This seems very impressive. In my opinion it looks like the best multi-screen phone/phablet to date.

<comment><USER4> To me, the bigger potential is from the OS and not the hardware itself.

As more manufacturers move to foldable devices, I see them licensing MSFT's android skin instead of going through the arduous process of developing one anew.

It might be what lets microsoft finally get a foothold in the smartphone market, after many failed attempts.

</comment></comment><comment><USER5> The "laptop" one with the flipout keyboard looks great.

I wasn't sure in the video - are these separate devices (large and small versions of the same thing)?

The laptop sized one would be awesome as a travel device if it were full- featured proper x86 device... I get the feeling these are android phones though right?

Edit: The larger device appears to be a "Surface Neo": [https://www.microsoft.com/en-us/surface/devices/surface- neo](https://www.microsoft.com/en-us/surface/devices/surface-neo)

The marketing video for it has an Intel "CPU" animation so guessing this will be a "real" device?

<comment><USER2> The Surface Duo is an Android phone running a Qualcomm CPU, whereas the Surface Neo is a Windows 10X device using an Intel CPU.

</comment></comment><comment><USER6> It looks like this is based on Android? I wonder why they used that instead of some Windows version.

<comment><USER7> Microsoft tried pushing their own mobile OSes for years before finally giving up when they were down to low-single-digit marketshare in the US.

<comment><USER8> "Tried" is maybe the wrong word. Windows CE was a leading OS on smart handheld devices for a good long while.

Arguably, the biggest single thing that killed their market position (aside from the launches of iOS and Android, of course) was that they didn't retain backward compatibility, so Windows Phone 7 and later were effectively a completely different OS. Getting into competition with yourself is rarely a winning strategy.

<comment><USER9> Yes! So yes. But also no.

When Microsoft released Windows Phone 7, it really got people excited. It was a shot across Skeuomorph UI's bow. Big fonts, dark mode by default, flat and chromeless to an almost fault. It was a serious departure from the Windows Mobile days. People were (more) comfortable with it not being backward compatible. Plus WM had turned into a mess of scaling problems, 3rd party skins, over the top launchers, and apps that weren't necessary cross device compatible.

But then they did it again, Windows Phone 8 was not coming to any Windows Phone 7 devices. Even though MS originally said it would. Instead, all the WP7 phones got some 7.x feature update. Everyone showing off their shining new Nokias were burned during the honeymoon and that cooled interest. Especially when compared to Apple's sterling record.

And then, they did it again, sorta. Many of the Windows phone 8 devices were not going to get updates to Windows 10 Mobile. Worse yet, Microsoft walked the striking UI way back. Except for the launcher, things starter looking rather conventional.

There was no coming back from that. 41MP and real OIS, Zeiss optics and xenon flash. Things that were basically unheard of until 2019 (rip xenon) were not going recollect all that lost good will.

</comment></comment></comment></comment><comment><USER10> My knee jerk reaction was to pan it for having huge gap in the middle. But then I'm looking at my own monitor desktop. On left side, I have work application. On right side I have web browser. exactly 50:50 split. They may be onto something.

<comment><USER11> Right. I think people who are used to a dual screen desktop env will feel at home with this setup.

<comment><USER12> And, for as much as they are charging for foldables, this setup seems like it will be much more resilient than the flexible plastic screens used elsewhere.

</comment></comment></comment><comment><USER13> Will Microsoft have their own app store for the Duo?

<comment><USER2> No, it comes with Google Play.

</comment></comment><comment><USER14> Conceptually and form factor wise this looks good, but those bezels just make the whole device look outdated.

<comment><USER2> The rumor is that the Duo has been hardware-final since 2018. They were waiting for Windows 10X to be ready, but eventually decided to just launch it with Android instead of attempting to make a phone version of Windows 10X.

Source: [https://www.windowscentral.com/surface-duo-spring-summer- ear...](https://www.windowscentral.com/surface-duo-spring-summer-early- launch-2020)

<comment><USER14> That explanation makes sense, if it's been in work for so long it's probably difficult internally to get the resources to bring it into line with current expectations.

Unfortunately v1 will probably bomb in its current state and we won't see the proper potential of the device.

</comment></comment></comment><comment><USER15> I definitely dig the PDA form factor on this, classic!

</comment><comment><USER16> Excuse my ignorance but I've never considered buying a surface up until now (they looked like "powerpoint toys" to me, hopefully I am wrong).

My two most important criteria are not listed on their product page:

\- do they usually sell matte screen?

\- how is the hardware support for linux at launch?

<comment><USER17> Matte touchscreen..?

<comment><USER16> Believe it or not, matte touchscreens do exists.

</comment></comment></comment><comment><USER18> I will never buy this. Even looking at the screen with the borders between the two screens, I find it super misleading. The screen pretends to be one, but you open an app by touching an icon and it opens on the left one only. The icons remain hidden, and half of the desktop is on the right. Can I scroll the right scree? I mean.. scrolling left and right on one screen, and up and down on the other?

Nope. Thank you.

<comment><USER19> Funnily enough, I had the opposite reaction. This is the first tablet-like device that I would consider buying. I use two screens with my computer which works really well, and this seem just like that.

<comment><USER13> It really has the Courier vibe and I was very ready to buy one of those if they ever actually made it.</comment></comment></comment>


Visualizing binaries with space-filling curves - <AUTHOR> http://corte.si/posts/visualisation/binvis/index.html <comment><USER2> Why, hello there Hacker News. Just a note that I've written two follow-on blog posts after this one, developing the idea a bit further.

First, using a color function that encodes local entropy to show how crypto keys and other high-entropy data can be picked straight out of a visualization:

<http://corte.si/posts/visualisation/entropy/index.html>

And next, using this in bulk on samples from a malware database, with what I think are beautiful and interesting results:

<http://corte.si/posts/visualisation/malware/index.html>

<comment><USER3> I'm curious as to how it would look if you used some other measure of entropy besides local symbol frequency. Probably a general purpose compression algorithm should give you a good idea, like gzipping the blocks.

Hmm, I'm not sure if this could work, but perhaps if you use a stream based compression algorithm you could relatively precisely see how much compressed data it takes to represent up to a certain point in the file, with only a single pass (rather than having to compress a huge number of local windows). Of course this is probably going to weight earlier parts of the file heavier, simply because the compression won't be calibrated yet to efficiently encode. So you could also run it on a byte-reversed version of the file, and a "rotated" version of the file (i.e. file[n/2:n]+file[0:n/2]), and a rotated- byte reversed version, and combine all those metrics together in some way (maybe min(entropy1,entropy2,entropy3,entropy4)).

That way you could get an entropy measure which compensates for the sort of alphabet runs that fooled shannon entropy.

<comment><USER2> I'm working on something like this for the next evolution of the entropy visualizations. I've toyed with compression, but have had nicer results so far with other randomness estimators. I'll do a writeup once I have something to show.

For a continuous compression function your idea of running on a rotated or reversed version of the file and then taking a minimum is a cunning one! Right now, I'm still working with sliding windows, but I'll keep it in mind if I turn back to compression.

<comment><USER3> I'm curious what other randomness estimators you'll be using... (or maybe I'll just have to wait for another blog post).

</comment></comment></comment></comment><comment><USER4> This reminds me of a guy who took the address pins and the data bus pins and hooked them up to two digital-to-analog converters and fed them into an oscilloscope.

The resulting 'knot ball' of traces could actually be discerned once you watched a few of them. You can pick out all sorts of things like when the video was refreshing, keys were being processed, etc.

<comment><USER5> "You get used to it. All I see is blonde, brunette, red-head"

</comment></comment><comment><USER6> Its amazing how much data we can process through our retinas if it is just presented intelligently.

</comment><comment><USER7> I remember I did something similar (although much less sophisticated) in the 90s; I'd write a small program to switch into VGA mode 0x13 and just load a file into the 320x200 framebuffer at 0xa0000. Even with just the default VGA palette, identifying areas of interest and patterns was quite possible.

Nice writeup(s) and interesting approach with the entropy calculations!

</comment><comment><USER8> I wish hexdump had an option to create an output image like those.

</comment><comment><USER9> Can someone please note down what are the benefits of such a visualization?

<comment><USER10> Humans are awesome at recognizing visual patterns. It's difficult to get a sense of what a file contains from a hex editor, but if you apply the right transformations on the data, distinct features stand out in the visualization.

This allows people to recognize similarities between different files as the resulting patterns are revealed. Take this previous blog post by the same author:

<http://corte.si/posts/code/sortvis-fruitsalad/index.html>

This shows various sort methods operating on a set of unsorted data. If all you had visibility into was how the data was manipulated, by generating an image based on the data transformations, your pattern matching brain will quickly be able to see which sorting algorithm was used.

</comment></comment><comment><USER11> I really enjoyed these posts. What a great use for a mathematical concept that was developed over one hundred years ago.</comment>


Show HN: I wrote a BASIC interpreter in Go - <AUTHOR> https://github.com/skx/gobasic <comment><USER2> A while ago I started making a game ([https://www.youtube.com/watch?v=GwBiJR_rj_w](https://www.youtube.com/watch?v=GwBiJR_rj_w)) that was going to be about typing in program listings from magazines and books (like "back in the day")... but the "twist" was going to be that the whole world turned out to be alterable and scriptable with BASIC. The WIP title was "BASIC Instincts".

The problem was I spent way to much time having fun making the interpreter (in JavaScript) and then Else.HeartBreak() was released and it took the wind out of my sails (because it was great!)... I might go back to it now though, writing interpreters is really enjoyable!

</comment><comment><USER3> I still have fond memories of the various BASICs. I first used BBC basic at school (unofficially), and it seemed like magic. I had an Atari ST and a got a copy of STOS at home.

Whilst BASIC encourages all kinds of spaghetti, I'm still convinced it is a better language than Python to start on. Control flow is so obvious to non- programmers when it has line numbers.

<comment><USER4> Not all BASIC dialects have line numbers, there are some very elegant version of basic out there. GFA basic for instance and BBC Basic. Both have named functions and do not use line numbers.

<comment><USER5> Not sure which BBC basic you used, but it certainly DID have line numbers when I used it. (BBC Model B)

However there were user defined functions and procedures as I recall.

<comment><USER4> Yes your are 100% right, the line numbers were there in BBC Basic, but mainly for editing rather than control purposes (though you could use the dreaded GOTO statement if you absolutely had to). Keep in mind that this was just before the days of the full screen editor embedded in your favorite programming language.

GFA did away with them entirely.

The BBC had an odd editor, it was partly line and partly screen based, allowing you to move a secondary cursor across the screen with the arrow keys, and then a ´copy´ key to copy whatever character was under the second cursor to the input cursor as though that key had been pressed. It sounds terrible but it was actually quite quick in actual use.

<comment><USER6> What you're describing there was pretty standard across all of the 8bit micro computers. A few machines had the copy feature (eg the CPC464) and the control flow in the BBC BASIC wasn't anything that couldn't be done in pretty much every other dialect from that era (be it Microsoft BASIC, Locomotive or whatever).

Personally I think it's a bit of a stretch to say line numbers were mainly there for editing. Even if you ignore GOTOs the most common method of running pseudo-functions on the BBC Micro was GOSUB.

<comment><USER7> The BBC personal computer (that ran BBC Basic) also had a cool feature that allowed you to drop down into 6502 assembly language right in the middle of your BASIC program, just by enclosing your assembly language statements in [ and ].

I remember trying it out at a British Council library which had one such machine available for members to use. Although I had done a little 6502 assembly language programming earlier (using both the PEEK and POKE approach as well as using an assembler), just for fun, on other home computers, I never got to do a lot of it, since by then, I moved on from BASIC and assembly to languages like Pascal and then C. Good times.

<comment><USER6> There were actually a few machines that ran BBC BASIC. I've got a BBC Micro model B hooked up in my "man cave" and I still play on that from time to time.

I've also got a few Amstrads CPCs - another range of British 8bit micros. They ran Locomotive BASIC which was largely inspired by BBC BASIC so there is a hell of a lot in common between those two dialects.

<comment><USER7> >There were actually a few machines that ran BBC BASIC.

Interesting, didn't know that.

>I've also got a few Amstrads CPCs - another range of British 8bit micros.

Cool. Had read about them in computer mags.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Does anyone remember some installs shipped with a game called gorilla.bas? A fun little game where you had two gorillas across a cityscape and the whole idea was to take turns throwing bananas at each other to see who can get a critical hit.

What made it hard is you had to enter both an angle and speed and hope you calculated the right combination to hit the other player.

Eventually I wrote my own version of the game in flash/actionscript....but it's long gone.

<comment><USER9> Here's a js/html5 port: [http://www.kylem.net/stuff/gorilla.html](http://www.kylem.net/stuff/gorilla.html)

<comment><USER8> Yep that looks like a legit clone of it. Thanks for the link.

</comment></comment></comment><comment><USER10> Peter Norvig did one for Python, and it's pretty cool: [https://github.com/norvig/pytudes/blob/master/ipynb/BASIC.ip...](https://github.com/norvig/pytudes/blob/master/ipynb/BASIC.ipynb)

<comment><USER9> Interesting abuse of a regex as the tokenizer. Cool.

<comment><USER11> How is it an abuse? I thought using regex as the tokenizer was the main approach

<comment><USER9> I've never seen a tokenizer as one big regex that finds all the types/functions/keywords all at once.

<comment><USER12> To get a bit theoretical, one way to write a lexer is to use a state machine called a deterministic finite automata - a fancy term for a state machine that is finite and always gives the same output given an input. Each new character moves the state, and there are terminal states when you reach e.g. a space which will spit out what kind of token you just read.

You can show that the things a regex can compute are the same things that this kind of state machine can compute. I believe that most regex under the hood use such a state machine, so it's very natural to use regex to tokenize.

</comment></comment></comment></comment></comment><comment><USER13> A fun project! I had a buddy tried this, wrote it in C++ over a week. Had console, graphics, formatting and networking (I think).

The trick was first a parser, then use C++ objects for each construct and instantiate one for each parsed element. The objects had a 'list' and a 'run' method. They were linked in programmatic order. So run the first one, which returns the next one to run (since it may vary with IF, GOTO etc)

Here it is! [http://www.moondew.com/basic/](http://www.moondew.com/basic/)

<comment><USER14> Sounds like interpreting from an instance of the AST. Pretty easy but there are gotchas; like handling break/continue in loops. It's an interesting excercise everyone ought to try IMO.

</comment></comment><comment><USER15> I once wrote a Logo interpreter in BASIC... For my Computer Studies GCSE (UK national exams at 16) final project. It never actually _worked_ , but it was a heroic effort!

<comment><USER16> I once wrote an assembler in BASIC. We extended the instruction set of a microprocessor by some external circuitry, so the standard assembler was not very useful. BASIC was fine for the job. And it actually worked :)

</comment></comment><comment><USER17> I think BASIC is something that everyone has to write at least once in their lifetime.

My personal take is here (over 7 year old code, beware): [http://tech.nimbus.fi/minibasic/](http://tech.nimbus.fi/minibasic/)

And I wrote that just to make this functional: [http://tech.nimbus.fi/c128/](http://tech.nimbus.fi/c128/) (Try the "help" command.)

<comment><USER18> Yep, and here was mine: [https://github.com/darius/parson/blob/master/eg_basic.py](https://github.com/darius/parson/blob/master/eg_basic.py) written to exercise a parsing library. It's super-slow.

<comment><USER19> Mine in c# is here [https://github.com/peteri/ClassicBasic](https://github.com/peteri/ClassicBasic)

</comment></comment></comment><comment><USER4> Could someone that has the ability to compile this check the output of

PRINT 3+4*5

please?

<comment><USER9>
      $ echo 'PRINT 3+4∗5' > test.bas
      $ go run main.go test.bas
      34

      $ echo 'PRINT (3+4*5)' > test.bas
      $ go run main.go test.bas
      23

      $ echo 'PRINT (3+4)*5' > test.bas
      $ go run main.go test.bas
      35

No idea where it's getting 34 from though.

<comment><AUTHOR> Grr. Expressions are hard:

        10 LET a = 3+4*5
        20 PRINT a, "\n"

Produces the expected outcome:

        -> 23

Bug filed:

[https://github.com/skx/gobasic/issues/41](https://github.com/skx/gobasic/issues/41)

<comment><USER4> Yes, but it should not require that LET statement. The expression evaluator looks subtly broken.

<comment><AUTHOR> Bug filed, as per the edited comment above. I definitely agree this is wrong!

<comment><USER9> Don't know if it's the same bug, but "PRINT 1/0" returns 1. "PRINT (1/0)" prints nothing. Using "LET a=1/0" raises a div by zero error. Also, "LET a=1%0" panics.

<comment><AUTHOR> The issue with the "PRINT 1/0" and "PRINT (1/0)" are the same as the previous one.

LET a = 1/0 SHOULD produce a division by error, so I think that's correct. But 1%0 shouldn't panic. I'll fix that.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I wrote a BASIC interpreter in VAX assembly language (in 1986). I feel old..

I enjoyed Atari 800 BASIC, so it was modeled after that, tokenized during line entry so that it would not allow you to enter lines with bad syntax.

VAX assembly had instructions for spanning over characters given in a set or scanning to a character in a set, so string processing was very nice.

You should use floating point for the line numbers so that you can always insert more statements between existing lines :-)

</comment><comment><USER21> Oooh wonderful! I wrote hundreds of games as a kid in QBasic and have had the idea for years to write a QBasic to JavaScript transpiler so I could actually showcase some of them online. With Go adding its WASM support, I've actually been considering a Go interpreter as an option.

This is super inspiring. Nice work.

<comment><USER22> Did you search for existing ones?

[https://github.com/smhanov/qb.js/blob/master/README.md](https://github.com/smhanov/qb.js/blob/master/README.md) [https://news.ycombinator.com/item?id=1042896](https://news.ycombinator.com/item?id=1042896)

</comment></comment><comment><USER23> That's how Bill Gates started

<comment><USER24> Technically, I believe they (Paul Allen & Gates) ported the Basic from the Harvard Dec-10 using a cross compiler. This was before there was licenses in code.

<comment><USER25> No. They wrote a fresh version, but they did use an 8080 assembler on a Dec-10.</comment></comment></comment>


Want to know what went wrong at GM? See our visualization on GM's fall.? - <AUTHOR> http://www.mint.com/blog/finance-core/the-fall-of-gm-a-visual-guide/ <comment><USER2> He misses the CAFE standards, which forced them to produce more low profit vehicles. Saturn was an incredibly bad business decision. 5 billion to create a noisy, slow, ugly car (with dumb innovations like the plastic panels) for the least profitable segment of the market. They could have bought Honda outright for less. OTOH, Cadillac did a great job re inventing themselves. Now it seems the government wants them try the Saturn experiment again.</comment>


Rotterdam's floating dairy farm project - <AUTHOR> https://www.theguardian.com/sustainable-business/2016/jul/04/do-cows-get-seasick-rotterdam-floating-dairy-farm-netherlands <comment><USER2> A bit off topic: I watched a TV show, it was a competition for the best young chef. At one point they took the chefs out into the country side to cook somewhere, on the drive they got caught up in some sheep that were out in the road. All the chefs in the car looked around in amazement, one said, "This is where our meat comes from?"... I was just amazed. They had no idea how big a sheep is, or that it is a real live animal with feelings and a desire for food, shelter, comfort etc.

There is also a local farmers show where they let you come and see the cows. I love standing there and seeing the amazement in peoples eyes as they realise that cows are huge, smelly and hot. People touch them, they are fury and warm and nice. Yes, we kill them and eat them. There is a massive disconnect here. Urban farms are a really good idea.

Oh and third boring story. We had a friend over and we sat outside. We could hear the cows moo-ing. She didn't know what the noise was and was amazed when we told her. They moo because the farmer has sold the calves. It takes them days to mourn the loss. Drink up your milk.

[edit] I drink milk and eat meat. Not much, but I still enjoy both. I think the fact that as a society we 'hide' this from most people is wrong. Let people know about where their food comes from and let them choose.

<comment><USER3> I agree that people should be more connected to their food supply, even if for no other reason than to be able to select better produce for themselves.

I was witness to a cattle being slaughtered while staying on a beef property. It is confronting, I'll give you that. However I still enjoy eating meat but I strive to always eat locally produced and I try and eat what is in season. Again this is more of a quality preference than a moral stand. I worked in a butcher for a while and that taught me a lot.

I am lucky to live in an area abundant in food, so I do feel for those trapped in a big city at the end of industrial supply chains. For dinner tonight I had freshly caught fish that were swimming around yesterday. The difference is amazing.

</comment></comment><comment><USER4> This is another step in the wrong direction. Animals are very resource intensive and give almost no resources in return.

The only way animals were kept in the past was by using resources humans couldn't use themselves. Cows and sheep grazing on marginal land that can't be used as farmland. Pigs fed on food scrap and in pannage.

<comment><USER5> > _This is another step in the wrong direction. Animals are very resource > intensive and give almost no resources in return._

That is a most obscure statement. Where I live, northern Europe, people couldn't survive without animals, until historically recent inventions of transport. Not just cows and sheep grazing marginal land (though that is not insignificant, because all land is "marginal" here) but also because animals have provided much of the essentials materials for life: skins, wool, even the bones were used for material. That is now largely replaced by using mineral oil resources, which will not last indefinitely.

And if you are promoting "organic and sustainable" agriculture, remember that to do it, you will need to _increase_ the amount of animals in agriculture - otherwise you cannot get the fertilization and nutrition needed by plants.

</comment></comment><comment><USER6> Well, the degree to which costs would have to be scaled down can't be understated; 2.5 million euros for 40 cows. Yikes.

<comment><USER7> Here I was thinking that it wasn't ridiculously out of line like some of these urban farming projects. Looking at the farms for sale in my area, there's a traditional land-based dairy farm in a rural area – with 50kg of quota (approximately 50 cows) – listed at $4M Canadian dollars, or just shy of €2.8M at the current exchange rate.

<comment><USER8> Thise numbers say a lot more about the need to reform Canada's supply management system for dairy production which is basically analogous to taxi medallions for dairy cows. It's why cheese and milk are roughly twice as expensive as in the US.

<comment><USER9> The US isn't much better. The subsidies farmers get block more efficiently farmed dairy here in New Zealand and are a source of some frustration to NZ farmers.

</comment></comment></comment></comment><comment><USER10> Why? Anyone that been to the Netherlands would tell you they got enough cows on Land.

Rotterdam is surrounded by farmland, what's the point of putting them on water? If anything this would be an environmental disaster with bovine excrements being flushed into the ocean...

<comment><USER11> Learning how to raise cattle on floating ocean platforms in a country with 2/3s of its land threatened by ocean flooding sounds like a solid plan.

<comment><USER10> Not really, raising cattle on the ocean is a very bad idea as far as the environment goes.

And if 2/3rd's of your land will be flooded (which is has been the case since well forever as most of those windmills are water pumps that pump water out of the ground) you have bigger problems than finding your cows a new home (Belgium works just fine also).

It's an expensive and more or less pointless exercise, heck based on the cost of building artificial islands especially now since China became a world leader in doing so if you really want to expand into the ocean that's a better idea.

The excrement from cattle farms is a horrible source of pollution, it's one of the main sources of pollution of water in the world, raising cattle on barges means that you are going to pump metric tons of shit into your coastal waters which would have very bad effects on the sea life.

</comment></comment></comment><comment><USER12> I wonder how they're going to handle and get rid of manure, the render doesn't show anything for that, and you don't want to dump raw manure in the water.

<comment><USER13> I'd expect it to be collected and sold? There's lots of demand for fertilizer.

<comment><USER9> In the volume cows make it, demand would be satisfied fast. New Zealand's waterways aren't dead or dying while people want the run off. They are being destroyed because of the volume dairy farms produce so badly exceeds that which is easily used.

<comment><USER14> I think this will probably be one of the biggest challenges for this project. Bovine excrement and odour are very briefly mentioned in the article, but not nearly in enough detail.

While the dairy machinery itself is usually well cleaned after every milking, and the milk itself will be tested for bacteria counts, the areas surrounding a dairy are almost always very, very difficult to keep clean. Even with regularly cleaned dairy machinery, the heady aroma mix of sloppy faeces, urine and dried milk will be pervasive.

I'm personally not bothered by it, having worked on a dairy for several seasons, but I can imagine that not everyone will be quite as comfortable in that environment.

</comment></comment></comment></comment><comment><USER15> "My husband ... visited New York, there was Hurricane Sandy and he saw the shelves were empty; there was only food for two days. He thought we had to do things in another way, and the idea came: why not build a floating farm?"

Would floating farms fare well in hurricanes? Vertical farms, on the other hand, could supplement some of the food for places which are too far from farmland (although upstate New York is not all that far) or places inhospitable to farming.

<comment><USER16> If they're anything like the casino barges in the Katrina wake, the answer is "No": [http://www.hospitalitynet.org/news/4024377.html](http://www.hospitalitynet.org/news/4024377.html)

That's not to say they can't be designed to withstand hurricanes. You need a very, very sturdy pier to anchor them in place, but it's not impossible to imagine such a thing.

The good news is Rotterdam doesn't get a lot of hurricanes, and nor does San Francisco or Seattle.

<comment><USER17> Of all the things we could add to try and revitalize Seattle's waterfront, I'm not sure the pervasive smell of cow poop is the answer. We've got places like Duvall and Enumclaw for that.

</comment></comment></comment><comment><USER18> It'll be interesting to see what happens when the technology to generate milk from artificial mammary glands becomes a thing. We are already on the path to eliminating the need for bovine meat processing.

<comment><USER19> > We are already on the path to eliminating the need for bovine meat > processing.

You might be. I'm not.

</comment></comment><comment><USER20> wow 2.5 million. rotterdam is among the poorer cities in the netherlands. they could have done a lot of other things with that money. like give a thousand people a job for a year. or expand the subway or the docks (its main economic engine).

<comment><USER21> A hundred people, not a thousand.

</comment></comment><comment><USER22> Doesn't that take away from the enjoyable water?

</comment><comment><USER23> "Reconnect with food"? How about we stop enslaving and exploiting animals for food? Or is that too radical of an idea?</comment>


California Covid-19 risk screening and testing - <AUTHOR> https://www.projectbaseline.com/study/covid-19/ <comment><USER2> > A Google account is needed to access the Baseline Platform. The information > you provide will be stored in a secure, encrypted database. Verily personnel > who need to contact you, such as staff to schedule your testing, will have > access to direct identification information (your name, street address, > phone number, and email).

> The information you provide may also be shared with the health care > professionals who collect your specimen, the clinical laboratory that > processes your specimen, the California Department of Public Health, and > potentially other federal, state, and local health authorities, and other > entities that assist with the testing program. Information may also be > shared with certain service providers engaged to perform services on behalf > of Verily, including Google, which Verily leverages for certain technology > and services, including cloud services, security services, data storage, > website hosting, and other support functions.

<comment><USER3> This is infuriating, I am visibly shaking. Why can't Google act out of the interest of user privacy and stop collecting data in these dire times for once? Charge me $5, but stop collecting data about me.

Edit: Sorry about my language.

<comment><USER4> Imagine you worked at Google. Imagine you were tasked with building this website as quickly as possible. You have available internal tools designed to work with Google accounts. These tools have already been tested and validated. They have already gone through some level of security and privacy review. They have already scaled to high QPS production uses.

<comment><USER5> I think most of us could do this without Google signin in about 15 minutes.

<comment><USER6> I'll get the stopwatch and generously double your time limit to 30 minutes. Maybe if they've covered California you could do some of the other states.

</comment></comment></comment></comment></comment><comment><USER7> > My child is under 18 but I'm concerned they need to be tested. Can I fill > out the screener questions for them?

Unfortunately no. At this time, only those who are 18 years or older are eligible through this program and anyone who is prioritized for testing will need to provide a valid ID to confirm identity at the testing site. Please consult with your physician if you have concerns about your family's health.

I don't understand why this is the case.

<comment><USER8> In Canada, the communication I've been seeing is basically that they are only interested in testing you if you might need treatment. Since people under 18 are at such low medical risk from this virus, they're probably very low priority to test. Combine that with the fact that laws probably exist that make it inconvenient to provide this service for them, and it likely makes sense to just blanket exclude them from the program.

<comment><USER9> As far as I know there is no treatment for COVID-19. Why do they need testing to determine treatment?

<comment><USER10> There is absolutely treatment for the disease. It's just that the treatment is largely restricted to ameliorating the symptoms while the root cause, the virus proliferation, is left to the immune system. (The possible exception are antivirals currently being tested.) Symptom treatment includes things like concentrated oxygen and mechanical ventilation.

</comment></comment></comment></comment><comment><USER11> I looked for "HIPAA" and didn't find it anywhere. Nor the ability to request that data be deleted. I wish they would take privacy for this more seriously than Google's baseline level of privacy.

<comment><USER12> from the FAQ:

> How will you protect my privacy?

>We are committed to maintaining high privacy standards and keeping your data safe. Project Baseline follows federal and state regulations governing the collection and use of an individual's data, including the Health Insurance Portability and Accountability Act (HIPAA). Data is stored in advanced systems with best-in-class security and privacy protocols.

[https://www.projectbaseline.com/faq/](https://www.projectbaseline.com/faq/)

<comment><USER13> Note that this text only appears under "How will you protect my privacy" _under the FAQ page_. If you look at the question with the same title on the landing page, HIPAA is not mentioned

<comment><USER14> That's because one is about Project Baseline in general (the one that mentions HIPAA) and one is about the special COVID-19 project (the one that does not.) They are different FAQs about different efforts.

</comment></comment></comment></comment><comment><USER15> I was curious what this site did, but it just says "Unfortunately, we are unable to schedule more appointments at this time." at the end of the survey.

</comment><comment><USER16> Interesting how it goes from `projectbaseline.com` to `baseline.google.com` after you complete the initial questionnaire, but the site continues to look the same. Why not just have one consistent domain then? Obviously it doesn't matter as long as it works, and it was built extremely quickly, though it does make me wonder.

<comment><USER17> I imagine the simplest explanation is that all of these things came together at the same time by different teams.

</comment></comment><comment><USER18> Across the top, looking for the gist, and you can "Get Involved", see "Our Team", peruse "FAQ", and delve into the "Blog".

Next, decide "If you are interested in getting tested for COVID-19, complete an online screener".

What's the audience? Some might have confusion about terms like Teams, FAQs, Blogs, and Online screeners.

From the FAQ: "Together with researchers, clinicians, engineers, designers, advocates, and volunteers like you, we're collaborating to design the next generation of healthcare tools and services."

</comment><comment><USER19> The following text is the contents of the Authorization Form that I signed with I signed up. It was presented to me in a web page, and once I agreed, a PDF of it was made available to me via a Drive link. Although the file is not in my Google Drive, I do not know if the link/document is unique to me, so instead of providing the link, I have copied the text. I did my best effort to reproduce the formatting: Wherever you see _italicized text_ , that appears bold in the Authorization Form.

 _COVID-19 PUBLIC HEALTH PROGRAM AUTHORIZATION FORM_

 _Background_

Public health and healthcare professionals are responding to an outbreak of respiratory disease caused by a novel (new) coronavirus that was first detected in China and which has now been detected in more than 100 locations internationally, including in the United States. The virus has been named "SARS-CoV-2" and the disease it causes has been named "coronavirus disease 2019" (abbreviated "COVID-19").

Current diagnosis efforts of COVID-19 are primarily focused on symptomatic and/or high risk individuals.

Verily, the Alphabet company focused on life sciences and healthcare, has offered to support public health efforts by providing its data collection infrastructure to help individuals understand their risk profile for COVID-19, help facilitate testing if indicated, and provide test results back to tested individuals in an efficient manner.

 _What will I need to do?_

 _1) Complete a short survey._

This will include questions about yourself, including age, gender, home address, contact information, recent travel history, current health status, and any known contact with others who may have been exposed to SARS-CoV-2.

 _2) For those deemed eligible for free testing with this program, schedule an appointment to go to a local facility to provide a test specimen._

Based on your survey results, if you are identified as eligible for testing under this program for COVID-19 disease, you will be asked to provide a biospecimen using a nasopharyngeal (NP) swab.

• You will be asked to schedule an appointment at a local facility. You may be contacted directly to schedule this appointment or this may be facilitated through an app or web portal.

 _3) Go to the test facility at your assigned time for the test swab._

At the test facility, you will need to bring a form of identification to confirm your identity prior to performing the swab collection.

A trained healthcare professional will perform the swab collection.

• This will be done by having you tilt your head back while a trained healthcare member inserts a sterile cotton swab into your nostril towards the back of your nose. The swab will be inserted to a depth about the distance from your outer nose to the outer opening of the ear. Once inserted, it will be held in place for a few seconds then slowly removed with mild rotation. This may cause temporary discomfort.

• Your sample will be coded and associated with the data you provided in your survey.

Your sample will be tested by a clinical laboratory to determine if your sample is either positive or negative for SARS-CoV2.

4) Follow recommended guidelines based on results of your lab testing.

The lab results will be provided directly to you via email, text, phone call or through an app or web portal. The testing may take a few days and results will be returned to you when available.

In addition, results of your test will be provided to public health authorities, including the California Department of Public Health and potentially other federal, state, and local health authorities.

 _How will my data be protected?_

Privacy is a top priority.

• Your data will be kept in a secure, encrypted database with restricted, monitored access

• This database complies with applicable state and federal laws that protect the privacy and security of your health information

 _Who will access my data and in what form?_

Verily will have access to information that directly identifies you, including your name, street address, email address, and phone number. This information may also be provided to Verily's contractors, the healthcare professionals who collect your specimen, the clinical laboratory that processes your specimen, he California Department of Public Health and potentially other federal, state, and local health authorities, and other entities that assist with the testing program. The information collected will be sed to perform the test, administer and improve the testing program, and for public health purposes.

In addition, your survey responses and test results will be provided to Verily, and may be further shared with the clinical laboratory performing the testing (for example, Quest Diagnostics), and public health authorities, including the California Department of Public Health. Public health officials may use this information to inform public health actions to help protect our community. Verily will not use your data for research purposes without your permission. In the future, you may be invited to share data collected during this process for research purposes.

Verily leverages certain technology and services from Google, including cloud services, security services, data storage, website hosting, and other support functions. Google's access to data is strictly limited to the purpose of providing such services. Your data collected by Verily through the services described in this permission form will never be joined with your data stored in Google products without your explicit permission.

 _Does it cost me anything?_

This survey and lab test will be provided at no cost to you.

</comment><comment><USER20> How does something like this really help? It seems like an automated phone answering system for COVID testing. This seems like, maybe, 0.1% of the problem we have in this country with dealing with this virus. I'm not saying it's unhelpful, just that it doesn't seem all that helpful either. It seems like a bunch of hot air from Trump and Google.

Also, isn't verily a bioscience company? I would expect them to be working on testing, or treatments, or almost anything other than a website. This drastically lowers my opinion of what I thought verily was, which admittedly, I didn't know much, I just figured it would being doing something a little more "hands on" here. Hopefully they're doing that too...

Also:

> Your data collected by Verily through the testing program will never be > joined with your data stored in Google products without your explicit > permission.

Who outside of even a subset of software engineers know what this means?

<comment><USER21> Better data improves the probability of "flattening the curve" to avoid overwhelming the health care system. Many lives can be saved if this can be achieved. In Italy they failed to do this, ran out of ventilators, and people are dying who would not otherwise be dying. For another example, google "flattening the curve st louis vs philadelphia 1919 swine flu".

</comment></comment><comment><USER22> Why does it take 4 seconds to load each page? Is that just me?

<comment><USER3> That's normal. We've bloated the javascript ecosystem so much that its impossible to expect a fast loading page these days.

</comment></comment><comment><USER23> That was quick

<comment><USER24> Interestingly they don't mention anything past California as an ambition, was this the idea Trump was talking about?

<comment><USER25> There are two projects related to Google going on - one is this one, from Verily, another is broader information website, led by Google. From TC[1]:

Google later clarified is that there are at least two different efforts here. Google's work around bringing more information about COVID-19 to its users across its various services — and Verily's efforts to launch a pilot website "that will enable individuals to do a risk assessment and be scheduled for testing at sites in the Bay Area."

I can not say which one Trump meant - and am not sure if he really goes into the details beyond "we're working with Google folks on making information available" \- the President usually doesn't do such things by himself, he delegates - but I would assume he probably meant the other one. But maybe both. Or maybe just Verily effort and extending it to broader reach. We'll see.

[1] [https://techcrunch- com.cdn.ampproject.org/v/s/techcrunch.com...](https://techcrunch- com.cdn.ampproject.org/v/s/techcrunch.com/2020/03/15/trump-says-google-ceo- sundar-pichai-called-to-apologize/amp/)

<comment><USER26> > [https://techcrunch- > com.cdn.ampproject.org/v/s/techcrunch.com...](https://techcrunch- > com.cdn.ampproject.org/v/s/techcrunch.com/2020/03/15/trump-says-google-ceo- > sundar-pichai-called-to-apologize/amp/)

Your AMP link is 404, here's the direct link:

[https://techcrunch.com/2020/03/15/trump-says-google-ceo- sund...](https://techcrunch.com/2020/03/15/trump-says-google-ceo-sundar- pichai-called-to-apologize)

</comment></comment></comment></comment><comment><USER27> Santa Clara and San Mateo counties? Where google has the most employees?

Not a hot county like Solano?

Hmm. Wonder why that is.

<comment><USER28> Bay Area counties, as of 2020-03-15:

       Alameda County: 15 cases
       Contra Costa County: 29 cases
       Marin County: 5 cases
       Napa County: 0 reported cases
       San Francisco County: 37 cases
       San Mateo County: 32 cases, 1 death
       Santa Clara County: 114 cases, 2 deaths
       Solano County: 6 cases
       Sonoma County: 5 cases

[https://abc7news.com/health/coronavirus-updated-number-of- co...](https://abc7news.com/health/coronavirus-updated-number-of- covid-19-cases-deaths-in-bay-area/6008027/)

<comment><USER27> Yes, this makes it obvious.</comment></comment></comment>


There are no secure smartphones - <AUTHOR> https://www.devever.net/~hl/nosecuresmartphone <comment><USER2> The folks at [http://neo900.org/](http://neo900.org/) are well aware of this and that phone is designed accordingly (details at [http://neo900.org/faq#privacy](http://neo900.org/faq#privacy)). Hype-driven products like BlackPhone misrepresent their devices as being perfectly secure when this significant attack vector is completely unmitigated.

On the Neo900, the modem is connected via USB (bus; there is no physical connector) which means it doesn't have DMA. There is no feasible open-source baseband. OsmocomBB ([http://bb.osmocom.org/trac/](http://bb.osmocom.org/trac/)) is the closest thing to one, and it is relatively incomplete and works on a very limited range of mostly badly outdated hardware, none of which would not really be reasonable to use in a phone to be manufactured today.

It's incredibly difficult to get people to care and help with the lack of software for tasks like GSM communication. Somehow even among people who describe themselves as "hackers", most just want to run Android or iOS and buy/run closed-source apps, and are more interested in Javascript and employment than reverse-engineering and doing things that have never been done before. The potential of reprogrammable computers that, at a low level, run the code you ask them to doesn't seem to get through to most of the HN crowd.

<comment><USER3> > On the Neo900, the modem is connected via USB (bus; there is no physical > connector) which means it doesn't have DMA.

You'll find the modem on most smartphones is connected via USB - or rather its chip-to-chip version, HSIC. For SoCs where it's on-die - on the same bus/fabric - they will (if it's not an idiotic design) use an IOMMU of some sort, to prevent DMA from having access outside of its sandbox.

Even if it's a modem on the other end of USB - which will almost certainly be using DMA, but at least host-programmed DMA - that's no guarantee. Google "Evil USB". USB is a overly complex stack which has and will continue to result in countless vulnerabilities, regardless of what you do with it.

<comment><USER4> "Evil USB" (or "bad USB") is possible thanks to the U part of USB - universal. If you connect a pendrive to your computer, it can easily say that it's a keyboard, because your computer cannot easily verify that you haven't just connected a keyboard. It would need to ask you in some trustworthy way to be sure, which sometimes can be problematic.

OTOH, on the device like Neo900 it is well-known what kind of device is connected to the internal bus and software stack (at least on Linux) can easily be advised to not accept anything that doesn't look and behave like the included modem should.

In a properly configured user OS, the modem would need to use some software vulnerability to exploit the USB stack, so the same principles apply there as with, say, OpenSSL, browser or the kernel. Secret zero-days aside, when some bug is found, it is patched and you upgrade the vulnerable component, just like on PC.

<comment><USER5> This is correct. The problem in this example is not the pendrive, but the automatic selection of device drivers based on the PC OS 100% trusting physical access.

An easy way to see this is recompile the USB keyboard driver to ignore keyboard descriptors with a particular address or vendor ID. If you do this, the pendrive can't do anything because USB is host-controlled, as implemented by the OS. Without the OS _initiating_ a conversation with the pendrive and saying "ok, I'll configure you as a keyboard and interpret responses from you as keystrokes", it can't happen.

As you point out, the main CPU on a phone does not implement HID autoconfig on the internal baseband bus.

<comment><USER3> I picked a terrible example which doesn't demonstrate what I intended to.

Any USB link requires the host to maintain some persistent state in data structures mirroring what it thinks the state of the device is. There's no "DMA" in the sense that the device has direct access to the host - but that doesn't preclude something as mundane as a buffer overflow, use-after-free and so on.

"DMA", with appropriate IOMMU, is just fancy shared memory communication. You're just as likely to mess that up as a serial link. It's happened. A lot.

<comment><USER5> Yes, parsing of untrusted data, race conditions, etc. are still a problem in general. My complaint was with the uninformed article, not your analysis.

</comment></comment></comment></comment></comment></comment><comment><USER6> It's good to draw attention on baseband processors, but there are technical assertions in this post that are probably not accurate (lack of auditing and the notion that you can assess the security of a whole phone system by whether or not there's an IOMMU).

The systems security of modern phones is surprisingly complex. Google and Apple both care very deeply about these problems, and both have extremely capable engineers working on them. Without getting too far into the weeds: they haven't ignored the baseband.

<comment><USER7> The team behind Replicant reported that they found a baseband backdoor in Samsung Galaxies[0][1]. I think it's perfectly fine to extrapolate from that that you probably shouldn't trust the baseband, even if Google and Apple are looking into it. Until they have a concrete solution shipped, all the in-the- closet work on the problem is meaningless.

0: [https://www.fsf.org/blogs/community/replicant-developers- fin...](https://www.fsf.org/blogs/community/replicant-developers-find-and- close-samsung-galaxy-backdoor) 1: [http://redmine.replicant.us/projects/replicant/wiki/SamsungG...](http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor)

<comment><USER6> I don't think you should trust the baseband.

My objection is with the idea that you can look at a design, not see an IOMMU, and extrapolate from that the notion that the baseband has full access to the memory of the other chips in the design.

That's a reasonable assumption in a PC design. There may have been a point, for some phones, where it was a valid assumption for phones. It's not with a modern phone design.

<comment><USER8> In my research on phones from the Unrevoked project (admittedly, 4+ years ago), this was the case: the baseband and the CPU shared the same memory. The baseband memory was carved out from the CPU such that the CPU could not access it, but the microcontrollers serving the baseband had CPU access, as I recall from the Qualcomm boot documentation: the chain of trust from CPU boot was established by the baseband processor, not the other way around.

I would imagine that things have changed a little bit, but the baseband back then, and I imagine still now, is considered to be the ultimately trusted element of the system. I'd be surprised to hear that they've changed so much that the baseband doesn't still have full control over its host system.

<comment><USER6> The baseband doesn't have full control over phone systems.

<comment><USER9> You should qualify which specific phone designs you are referring to (or if it's "all new phones", when the cutoff date was). After all, you are responding to someone who has researched this and found (like others) that indeed, the baseband in older phones _did_ have full control.

Your statement is general to the point of misinformation.

</comment></comment></comment></comment></comment></comment><comment><USER10> Semi-related: I feel like there should be an open source dumbphone project. Smartphones have a lot of bells and whistles with a large attack area but many people just want to make calls. Sure this wouldn't fix the baseband issue, but it seems the safest way to ensure isolation between personal information and potentially hostile cellular blobs is to never put the information on the device in the first place. A small, open, dialer-only yet potentially extensible cellular platform would be really welcome, I think. Maybe something like this [1] using the rpi zero as a base with some 3d printed cases, reverse engineer what you can otherwise. Replicant is a noble project, but chasing android versions, screen sizes, video codecs, proprietary hardware locks etc is an uphill battle and kind of a distraction IMHO.

[1] [https://www.raspberrypi.org/blog/piphone-home-made- raspberry...](https://www.raspberrypi.org/blog/piphone-home-made-raspberry-pi- smartphone/)

edit: typo

<comment><USER11> [http://web.media.mit.edu/~mellis/cellphone/index.html](http://web.media.mit.edu/~mellis/cellphone/index.html)

</comment></comment><comment><USER12> Would really love to see this upvoted more. This basic truth should be common knowledge for privacy-minded or security-minded technologists/developers.

There are lots of reasons GSM won't/is hard to make work. What are the options? As more and more carriers in the USA provide wifi-dongles that are connected to 3G, maybe it's better to just do that, and move off making calls directly from your phone completely?

For example, it might make sense to buy some phone, connect it to a device (or flash it with some software) that makes it essentially a portal for phone calls of sorts, and give it sandboxed access to your network. It's significantly harder for GSM backdoors to be effective if the entire device is sandboxed right? Maybe this way, as you roam around, you can somewhat securely communicate over IP to your call-making device, and make/receive calls?

[EDIT] - Thinking about it, the suggestion is moot, since all someone would have to do is write some software to replay messages, or leak messages or some other nefarious thing, and stick it on the baseband of the device -- even if it can't damage your network it's still quite insecure.

Maybe we should just give GSM up altogether, and start trying to move ourselves (and the world) to only communicating over IP (which we have a shot at securing, assuming modern crypto isn't completely broken)? What is the situation like with completley open source wifi connectivity?

<comment><USER4> LTE is basically VoIP, a 180° change from the monstrosity of 3G, although the providers still manage to fail spectacularly at it.

[https://media.ccc.de/v/32c3-7502-dissecting_volte](https://media.ccc.de/v/32c3-7502-dissecting_volte)

<comment><USER12> LTE is a protocol/standard with more efficient methodology/tech right? -- my main issue was the involvement that certain agencies have with the basebands put into mobile phones and the resistance that people trying to develop completely open-source basebands encounter.

LTE doesn't seem like a solution to this problem, it sounds like just a more efficient baseband. Even if it's easier to reverse engineer, use of it might still be outlawed (as is an issue with the neo9000).

Does LTE use some publicly accessible/modifiable spectrum that I don't know about or something?

<comment><USER4> LTE, when compared to 3G, drops a lot of complexity and basically defines a data link for IP to flow in. Telephony services are then implemented via IP.

Of course the transmission itself is still as proprietary and filled with regulations as all GSM standards; I just noted that it should be easier to somehow "sandbox" the communication via LTE now than with older technologies.

It's still not the solution and I'm fully aware of it.

</comment></comment></comment></comment><comment><USER13> The article asserts:

        > It would, in my view, be abject insanity not to
        > assume that half a dozen or more nation-states (or
        > their associated contractors) have code execution
        > exploits against popular basebands in stock.

To me this ignores the flip-side of the argument. If US intelligence services really thought the Chinese and Russians could remotely and invisibly hack all/most smartphones then no-one with access to sensitive information would be allowed to do work on one, unless they're very confident that they've managed to secure their devices without leaving a stone unturned.

Soz Hilz[0].

[0] [http://media4.s-nbcnews.com/i/newscms/2015_10/913276/150303-...](http://media4.s-nbcnews.com/i/newscms/2015_10/913276/150303-hillary- clinton-text-mn-1100_c4f740ee15e6224bb75a5f58fecc072a.jpg)

<comment><USER14> Following your logic, then any other sovereign non-US states must forbid their their citizens and companies to use US technology in order to avoid US stealing the data. At least they should forbid it to those organisations and citizens who as you say access sensitive information.

Still, even after Snowden, the whole world uses Microsoft, Apple, Intel, Google technology everyday.

This is not a prove that your logic is wrong, but I am wondering how much today's intelligence services are interested in protecting their own companies and citizens from data breaches. It might be that they are more interested into stealing as much data as possible themselves in order to be able to negotiate with foreign states/services.

</comment></comment><comment><USER15> _> Modern smartphones have a CPU chip, and a baseband chip which handles radio network communications (GSM/UMTS/LTE/etc.) This chip is connected to the CPU via DMA. Thus, unless an IOMMU is used, the baseband has full access to main memory, and can compromise it arbitrarily._

Indeed. Such design coupled with very obscure and closed baseband firmware is a security nightmare. One should ask, who was pushing for such an approach.

</comment><comment><USER16> > For devices with cellular access, the baseband subsystem also utilizes its > own similar process of secure booting with signed software and keys verified > by the baseband processor.

According to the iOS security white paper, the baseband firmware is part of the secure boot chain, and has its own secure boot chain.

This allows me to assume it's very hard to inject or replace the the firmware with a malicious code. Whether or not the firmware itself has a backdoor or whatever I don't know, but at least one major phone manufacture knows this firmware is very important for security.

<comment><USER17> That's just iOS being iOS, on Android the baseband firmware can usually be flashed using fastboot. However, there will presumably still be a bootloader on the baseband processor that checks the authenticity of what you just flashed to it.

It's very interesting to just download a baseband firmware (usually called radio.img) from a random Android forum, unpack it and run _strings_ on the code you get. It'll usually be an ARM processor running a homebrew RTOS, which is concerning enough. When you search for _NMEA_ and realize the baseband processor is running the GPS chip, that's when you are starting to get doubts. And when you finally realize theres a bunch of audio codecs and the baseband is controlling the microphones, that's when the full force of despair hits you. You don't own it, you don't control any part of it. Your Android doesn't either, it begs the baseband for a slice of its information.

<comment><USER18> > Testing DDR Read/Write.

> _Testing DDR Read /Write: Memory map.

> Testing DDR Read/Write: Data lines.

> Testing DDR Read/Write: Address lines.

> Testing DDR Read/Write: Own-address algorithm.

> Testing DDR Read/Write: Walking-ones algorithm.

> Testing DDR Deep Power Down.

> Testing DDR Deep Power Down: Entering deep power down.

> Testing DDR Deep Power Down: In deep power down.

> Testing DDR Deep Power Down: Exiting deep power down.

> Testing DDR Deep Power Down: Read/write pass.

> Testing DDR Self Refresh.

> _Testing DDR Self Refresh: Write pass.

> Testing DDR Self Refresh: Read pass.

> Testing DDR Self Refresh: Entering self refresh.

> Testing DDR Self Refresh: In self refresh.

> Testing DDR Self Refresh: Exiting self refresh.

Yes Galaxy s4 modem, please provide unlimited access to all government agencies of all my phones content and communications.

> Samsung Root CA cert1%0#

Fantastic, you also inject your own root certificate. Thanks.

</comment></comment></comment><comment><USER19> Don't modern ARM chips encrypt memory (for DRM reasons)? If that's in use (modulo the area the the baseband needs to read/write), it doesn't matter. An adversary can read the memory, but can't read the encryption key out of the CPU.

If it could, anyone with a logic probe could grab un-DRM'd video data out of the RAM, which would make many people very unhappy.

</comment><comment><USER20> The Samsung i9300/i9500/etc use separate Exynos application processors coupled with stand-alone communication chipsets from Intel (originally Infineon). Check out the Replicant wiki for more info. The Replicant devices are unfortunately quite old (i9300 being the latest), but newer models do continue the trend (SM-G920H for the S6 international Exynos, I believe). You'll just be stuck on their proprietary OS, or need to fund a bunch of CM/Replicant development.

Of course the same branded (eg "Galaxy S6") has many different models for across the world, most using integrated Qualcomm chips. Honestly looking at the list of variants and thinking about the conservatism of RF and telecom regulatory regimes, you'd have to be naive to think the whole ecosystem doesn't simply exist under the control of major intelligence agencies. Communications have always been regarded as dangerous.

</comment><comment><USER21> The article author is not well-informed. You can verify this yourself by physical inspection, via leaked schematics, by paying a teardown analyst or via examination of available documentation for the components used in modern smartphone designs.

</comment><comment><USER22> There is something in between nothing and a full IOMMU. I've been working with a TMS570 processor lately whose DMA engine supports an IOMPU. This hardware is equivalent to the Cortex-R/M Memory protection unit.

An MPU has all of the same protection domains that an MMU does, except for a few major differences:

\- The total number of protected regions is very small (12 or so), such that the hardware cost is somewhat smaller than a TLB cache.

\- To offset the small number of regions, the size of each region can be almost any power of two.

\- The MPU does not perform address translation, again reducing the hardware cost.

Thus, the kernel can configure the peripheral's DMA engine to only allow access to a page or few.

</comment><comment><USER23> Based on what I've read from more authoritative sources (or is the author an authority in this area?), this information is outdated:

> It can be safely assumed that this baseband is highly insecure. It is closed > source and probably not audited at all. My understanding is that the genesis > of modern baseband firmware is a development effort for GSM basebands dating > back to the 1990s during which the importance of secure software development > practices were not apparent. In other words, and my understanding is that > this is borne out by research, this firmware tends to be extremely insecure > and probably has numerous remote code execution vulnerabilities.

I've read in several places that basebands now widely use the OKL4 microvisor,[1] based on the formally verified (fwiw) seL4 microkernel, and are much more secure than before. Does anyone know more about this?

[1] [https://gdmissionsystems.com/cyber/products/trusted- computin...](https://gdmissionsystems.com/cyber/products/trusted-computing- cross-domain/microvisor-products/)

<comment><USER24> > I've read in several places that basebands now widely use the OKL4 > microvisor,[1] based on the formally verified (fwiw) seL4 microkernel, and > are much more secure than before. Does anyone know more about this? > > [1] > [https://gdmissionsystems.com/cyber/products/trusted- > computin...](https://gdmissionsystems.com/cyber/products/trusted-computing- > cross-domain/microvisor-products/)

Surely baseband processors are _not_ based on seL4, since it currently has no realtime support (though it is in development: [https://wiki.sel4.systems/seL4%200.0.1-rt- dev](https://wiki.sel4.systems/seL4%200.0.1-rt-dev)).

OKL4 is based on a kernel of the L4 family (source: [https://en.wikipedia.org/wiki/L4_microkernel_family#Commerci...](https://en.wikipedia.org/wiki/L4_microkernel_family#Commercial_deployment)):

> > [https://en.wikipedia.org/wiki/L4_microkernel_family](https://en.wikipedia.org/wiki/L4_microkernel_family)

seL4 is another kernel of this family that has been formally verified.

</comment></comment><comment><USER25> I have address as a response to gue5t how creating a chain of trust may not be a doable goal as probably every part of the system is not trust-able.

However I'm thinking a different approach can be taken, suppose we abstract the different ways for communication a device has and use them as sockets or layers and then create an algorithm that distributes the communication through several channels.

For example two cellphones

-one against another using the light on one screen against the camera of the other

-the vibrator motor captured by the microphone

-introducing certain pattern of noise in Bluetooth communication by the other radios

-communication through stenography

-sending huge amounts of information (the more information the more power needed to discriminate, understand)

-abuse how things are not supposed to work (instead of sending packets in the correct order, use ping as a way of sending data by crafting the requests).

-Custom network stack

-use of a customized version of encryption with extra large keys (think 20480 bits instead of 2048)

-and last but not least use an algorithm that mutates the distribution logic based on certain algorithm dependent on time (in the same fashion virus mutate themselves)... using as key for example your voice

edit: explanation

<comment><USER26> > extra large keys (think 20480 bits instead of 2048)

Don't think it's a wise idea. This was briefly discussed recently: [https://news.ycombinator.com/item?id=10794991](https://news.ycombinator.com/item?id=10794991)

<comment><USER25> Thank you for the comment, I learned something new today.

Resume: "if you could break a 4096-bit RSA key, you've probably found a fundamental weakness in RSA that means you should move to a different algorithm entirely"

</comment></comment></comment><comment><USER27> Would this device be protected? [http://www.gsmarena.com/blackberry_priv-7587.php](http://www.gsmarena.com/blackberry_priv-7587.php)

</comment><comment><USER28> This is just a special case of the fact that there's no secure anything.

In 2016 that's just the price you pay for using computers. You just have to live with it. Mitigate it the best you can, rely on the ol' "mossad or not mossad" strategy now and then, hope for the best, etc. If you have a strong need for increased security, well, god help you (spoilers: you will receive no help), you're going to pump a lot of effort into building something that will still have tons of vulnerabilities.

<comment><USER18> Just get an FSF laptop for security. You can even trust the hard drive if you use software encryption of all your data. I'm not sure what remains insecure on that class of hardware?

<comment><USER29> They have a better story about firmware than other devices, but they're still running Linux and GNU software, which often has remotely exploitable vulnerabilities. Just today OpenSSH (which is neither Linux nor GNU but which you would obviously use on your FSF laptop) announced an extraordinarily serious remotely exploitable vulnerability. That's presumably not the last vulnerability of that severity in an operating system you install today onto your FSF laptop.

It's not obvious that FDE will totally mitigate hard drive firmware attacks because your boot loader and kernel are likely running from an unauthenticated partition (for instance, most Linux-based systems with LUKS today have all of /boot on a separate non-LUKS partition, and something like a GRUB boot sector too). If the hard drive understood how to recognize the kernel in /boot, it could inject a vulnerability into it. In a few presentations a couple of years ago, I walked through a real example of how a single bit flip in a binary can introduce (or re-introduce) a fencepost error that can compromise security, because the opcodes for extremely similar yet different conditional branches often differ by a single bit. One form of the conditional branch like jump-if- less may be the correct invariant, while another form like jump-if-less-or- equal may be the exploitable erroneous form of the same loop.

I'm not knocking people's work on trying to get a handle on what firmware is running on their devices; I think that work is great. The trouble is that attackers are looking for exploits and persistence in every layer of the system, so you won't get a silver bullet against all attacks by shoring up one aspect.

Good stuff on this: Halvar Flake's "Why Johnny Can't Tell if He is Compromised", and Joanna Rutkowska's recent CCC presentation on persistent state.

</comment></comment></comment><comment><USER30> Or you can just use WIFI and turn the baseband off like I do. The cell companies are all crooks anyways (in the US), and I don't want to do business with them.

<comment><USER31> Problem is, when you use VoIP over WiFi, you loose echo-cancellation, because the echo cancel hardware resides in the baseband and is not used in WiFi calls.

<comment><USER32> You may also consider echo cancellation software that is capable of doing server side echo cancellation that can handle the long echo tail. For example, take a look at the options provided by SoliCall.

</comment></comment></comment><comment><USER33> "...no secure smartphones." There's always a weakness somewhere. Makes me wonder why governments want backdoors. Just in case we manage to make a perfectly secure device? It's too onerous to ask a judge for permission to "hack" a phone through weaknesses rather than asking permission for an escrowed key?

</comment><comment><USER34> How about those [http://www.cryptophone.de/en/company/news/gsmk-introduces- ne...](http://www.cryptophone.de/en/company/news/gsmk-introduces-new- groundbreaking-secure-mobile-phone/) phones? Is a "baseband firewall" just a gimmick?

<comment><USER35> It's basically (the older Samsung models) a Stingray detector, plus will shut down the device if activity is detected in the baseband CPU while the application CPU is dormant meaning shenanigans like SMS 'stealth' spamming is going on or evil OTA update.

You can always walk around with a portable hotspot and leave the phone on airplane mode. Only use textsecure/signal and download a free software reversed clone of Google services app to use GCM. If going to all this trouble to avoid targeted spying probably easier to just buy a chromebook with RockChip instead and use OTR or Signal whenever it comes out with desktop client (if not already, I haven't kept up with their current status of porting).

</comment></comment><comment><USER36> Tor has a discussion (2014) of Android security, including baseband processors, [https://blog.torproject.org/blog/mission-impossible- hardenin...](https://blog.torproject.org/blog/mission-impossible-hardening- android-security-and-privacy#MicrophoneRemoval)

</comment><comment><USER37> When I spoke to John Callas he said there was a serial link to the baseband on the Blackphone. I might be misremembering, but it certainly is an issue that designers are working on solving.

</comment><comment><USER11> That's right. Focus on the baseband is kind of the new fad in mainstream ITSEC. These problems are long-known in high-assurance as the cert requires _all things that can compute, store, or do I /O_ to be assessed. The reason is that, historically, these were all where attacks came in. I'm pretty tired but I can do at least a few points here.

1\. Software. The phones run complex, low-assurance software in unsafe language and inherently-insecure architecture. A stream of attacks and leaks came out of these. The model for high-assurance was either physical separation with trusted chip mediating or separation kernels + user-mode virtualization of Android, etc so security-critical stuff ran outside that. There was strong mediation of inter-partition communications.

2\. Firmware of any chip in the system, esp boot firmware. These were privileged, often thrown together even more, and might survive reinstall of other components.

3\. Baseband standards. Security engineer Clive Robinson detailed many times of Schneier's blog the long history between intelligence services (mainly British) and carriers, with the former wielding influence on standards. Some aspects of cellular stacks were straight designed to facilitate their activities. On top of that, the baseband would have to be certified against such requirements and this allowed extra leverage given lost sales if no certification.

4\. Baseband software. This is the one you hear about most. They hack baseband software, then hack your phone with it.

5\. Baseband hardware. One can disguise a flaw here as debugging stuff left over or whatever. Additionally, baseband has RF capabilities that we predicted could be used in TEMPEST-style attacks on other chips. Not sure if that has happened yet.

6\. Main SOC is complex without much security. It might be subverted or attacked. With subversion, it might just be a low-quality counterfeit. Additionally, MMU or IOMMU might fail due to errata. Old MULTICS evaluation showed sometimes one can just keep accessing stuff all day waiting for a logic or timing-related failure to allow access. They got in. More complex stuff might have similar weaknesses. I know Intel does and fights efforts to get specifics.

7\. Mixed-signal design ends up in a lot of modern stuff, including mobile SOC's. Another hardware guru that taught me ASIC issues said he'd split his security functions (or trade secrets) between digital and analog so the analog effects were critical for operation. Slowed reverse engineering because their digital customers didn't even see the analog circuits with digital tools nor could understand them. He regularly encountered malicious or at least deceptive behavior in 3rd party I.P. that similarly used mixed-signal tricks. I've speculated before on putting a backdoor in the analog circuits modulating the power that enhances power analysis attacks. Lots of potential for mixed- signal attacks that are little explored.

8\. Peripheral hardware is subverted, counterfeit, or has similar problems as above. Look at a smartphone breakdown sometime to be amazed at how many chips are in it. Analog circuitry and RF schemes as well.

9\. EMSEC. The phone itself is often an antenna from my understanding. There's passive and active EMSEC attacks that can extract keys, etc. Now, you might say "Might as well record audio if they're that close." Nah, they get the master secret and they have everything in many designs. EMSEC issues here were serious in the past: old STU-III's were considered compromised (master leaked) if certain cellphones got within like 20 ft of them because cell signals forced secrets to leak. Can't know how much of this problem has gotten better or worse with modern designs.

10\. Remote update. If your stack supports it, then this is an obvious attack vector if carrier is malicious or compelled to be.

11\. Apps themselves if store review, permission model, and/or architecture is weak. Debatable how so except for architecture: definitely weak. Again, better designs in niche markets used separation kernels with apps split between untrusted stuff (incl GUI) in OS and security part outside OS. Would require extra infrastructure and tooling for mainstream stuff, though, plus adoption by providers. I'm not really seeing either in mainstream providers. ;)

That's just off the top of my head from prior work trying to secure mobile or in hardware. My mobile solution, developed quite some time ago, fit in a suitcase due to the physical separation and interface requirements. My last attempt to put it in a phone still needed a trusted keyboard & enough chips that I designed (not implemented) it based on Nokia 9000 Communicator. Something w/ modern functions, form-factor, _and_ deals with above? Good luck...

All smartphones are insecure. Even the secure ones. I've seen good ideas and proposals but no secure[ish] design is implemented outside _maybe_ Type 1 stuff like Sectera Edge. Even it cheats that I can tell with physical separation and robust firmware. It's also huge thanks to EMSEC & milspec. A secure phone will look more like that or the Nokia. You see a slim little Blackphone, iPhone, or whatever offered to you? Point at a random stranger and suggest they might be the sucker the sales rep was looking for.

Don't trust any of them. Ditch your mobile or make sure battery is removable. Don't have anything mobile-enabled in your PC. Just avoid wireless in general unless its infrared. Even then it needs to be off by default.

</comment><comment><USER38> So what are the tools and knowledge required for one to tinker hardware enough to understand and build security for smart phones?

</comment><comment><USER39> What does one need a secure smartphone for?

</comment><comment><USER40> Between -sec, cloudcuckoolander designers, and architecture astronauts it feels like all the fun has vanished from tech.

</comment><comment><USER41> Why is it that the baseband has full access to main memory?

<comment><USER42> Because most chips and peripherals that work at a decently high speed on any computer use DMA. A parallel port on a computer, a thunderbolt connector, Ethernet cards, etc all use DMA for similar desires to speed up communication, and all can have the potential to be attacked. In order for a phone to give decent performance, DMA becomes more and more of a necessity.</comment></comment>