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

I've dropped Twitter. Their iOS client regularly pushed so many ads down my throat (in stream) that (a) I noticed and (b) I noticed it every day.

When I got to the point of blocking every advertiser (confirmed views +1!) but they popped back up under different special handles I resigned myself to defeat.

I will miss the serendipitous discovery of tidbits of information that it enabled, but the signal/noise (or rather, content/ads) ratio was overpowering. It needs to make money, but I think it's killing itself or at least transforming itself into the equivalent of TV -- content producers broadcasting to a largely passive audience.


They've made it increasingly annoying to use their site, particularly as a logged out user.

Their mobile site on android breaks -- forwarding me to an error page -- about 1/3 times I attempt to use it. This is the stock os and browser on a nexus 5.

The desktop site no longer allows me to view sensitive content by clicking the button: not on chrome w/ ghostery, not on ff with no plugins, and not on safari with no plugins.

I'm prompted to login at least 1x day, and you can't see who someone follows without creating an account.


I haven't dropped it 100% but I've turned off all notifications. I've even unfollowed some users and brands that I got push notifications from where I wasn't even @mentioneded. The iOS app is getting really spammy now.


What magic directory names? The special case for "pkg" is the only one I saw.

The main proposal is one of scoping by directory hierarchy - /a/b/c can import a/b/d but a/g/x can't.


> /a/b/c can import a/b/d but a/g/x can't.

No - x can import d because d isn't in a directory literally named internal. That's the magic name.


> What magic directory names?

"internal"

> The main proposal is one of scoping by directory hierarchy - /a/b/c can import a/b/d but a/g/x can't.

/a/b/c can import a/b/d, and /a/g/x and /z can too. The new rule is that /a/g/x can not import /a/internal/y.


> The new rule is that /a/g/x can not import /a/internal/y.

As I understand it, /a/g/x CAN import /a/internal/y, because /a/g/x is in the directory tree that starts at /a/. However, /b/h/z CANNOT import /a/internal/y/ (while previously, it could).


Can you remove/align the localizations on the phone number in loopd? I'm in Australia and can't put in a phone number.

Looks good otherwise, I'll try it around Sydney tomorrow.


yeah it was an oversight to lock it into US-based numbers! We'll release a version soon that has more support for international numbers


It's cute that you're both naming your products after New Zealand's national bird.

Both of your products sound like dating sites dedicated to meeting New Zealanders. That's....a niche market.

Kiwi != kiwifruit, if you talk if eating a nice juicy kiwi in the rest of the world you're either salacious, a cannibal, or undertaking some kind of illegal feast (main course: roast bald eagle perhaps)


the only bit I'd prefer clarification on is:

Timestamp with Timezone

There’s seldom a case you shouldn’t be using these.

For recording most event times that's true but:

Birthdates (which can include times) shouldn't use them.

Calendaring should think very carefully too, should the 9am meeting move to 10am due to DST? or should it "stay put" but potentially move for other timezones?


Definitely some great points and valid cases. In the calendaring case I actually may enjoy the shift, but that would probably be a surprise to most. Will work to add these examples where you wouldn't want the with timezone behavior in.


Birthdates (which can include times) shouldn't use them.

I don't understand why you don't want to use timezone with birthdates(with time). Can you explain this, please?


I think because the common usage of birthdates doesn't take the timezone into account. e.g. if you were born on January 1st 9pm PST, that's January 2nd 12am EST – but your birthday is still considered January 1st no matter where you are in the world. So trying to correct such dates for timezones will show users their incorrect birthdate.


Birthdates are particularly difficult to handle properly in a database if there is even a slight chance that you'll need to enter a foreign immigrant into the data.

Just for instance, older Iraqis (if I remember correctly) tend to be part of a culture where their individual birthdates were never recorded, and each person was considered 1 year older on some September date (maybe even talking the Islamic calendar there too). Should you store that date in your database, pretending that it means the same thing as an American who knows they were born at 7:08pm EST on July 17th, 1977?

And that's just one example of many.

I think I learned about this one because intelligence officials were freaking out when they eventually noticed all these people sharing a "birthdate", and it made the news.

Data about human beings is highly un-normalizable, as evidenced by everyone trying to stuff anthroponyms into the American "first name, middle name, last name" paradigm.


http://www.postgresql.org/docs/9.1/static/datatype-datetime....

The postgresql manpage says it loud: don't fucking use timestamp with timezone. It is bounded to political decision that makes it unusable compared to an UTC TS. Plus good practices says: store UTC present in local

Does any one Read The Fantastics Manual these days?


The docs say "don't use time with time zone".

That's very different than timestamp with time zone, which you should be using unless you have a very good reason to not.


If you want to know if the connection went down in a reasonable timeframe e.g tens of seconds, then you need to implement heartbeating over TCP. This is the first thing any new protocol on TCP usually does.



The lack of a preprocessor looks to be really hurting the impl of the rounds there.


New words for my vocabulary:

congaed - past tense&participle of conga scrod - young cod/haddock/white fish split and boned. (also schrod, also available).


"Strip out the baseband" of a dongle and you won't have a device that can connect to the network, authenticate, shift cells or anything else. It's like stripping the firmware off your disk drive.

Fully support the initiative for an open baseband. One reason it's not open is the (fairly legit) fear that intentional and unintentional DoS attacks would occur, affecting everyone in the area. It's really really simple to be an obnoxious cellular network citizen and it's pretty damn hard to police.

Baseband bugs that impact networks are common too due to the complexity. I saw a function point analysis of GSM vs 3G once, seem to remember 1-2 orders of magnitudes difference. Ahh Function Points, you flawed devil of a management metric.


The idea is that your "high side" device is a phone, with all your apps, etc. It communicates over a well defined interface (USB seems like the best, but bt or wifi could be adequate given certain considerations) to a fully-functional mifi dongle or whatever which does normal cell/public-wifi/etc. functionality. No compromise of the external cell modem can get at high side data. The current "baseband can DMA your main device" is absurd; security processors (only on iOS and BB and maybe WP, really) help a little, but not enough.

Yes, it is two small boxes right now, but there's no reason you couldn't build a "baseband firewall" which puts baseband in one area, a firewall in between, and the regular phone, with only a well defined open interface in between.


Snapdragon and every other baseband coming out has them on an 'all in one' chip which is application CPU and baseband sharing direct memory. Unless you have a microscope you can't build a hw firewall.

Cryptophone uses an older Samsung to do this but has no SIM protection. The firewall isn't foolproof either it only detects extended use of the baseband cpu without the application cpu being busy then shuts down the device, which makes it a brick open to denial of service.

A hardened Android build is fine for most shady activity and avoiding dragnet surveillance. If you are a drug lord or foreign spy use a laptop or tablet with ostel or silent circle, internal mic removed and running hardened free software, your dongle should have TurboSIM or similar wrapper that can be coded to reject OTA updates and not reply to silent tracking SMS. Marlinespike is also working on a new Whispercore, I have a forensics resistant project, and there is of course Cryptophone GSMK. Is the project you're talking about the build that runs Xen then boots Android in phony isolation because the snapdragon chip can still access memory.

Another problem is simply walking around with 2 phones which is an opsec indicator for feds that you are up to something and req targeted surveillance. They have full automated access to every cell tower db to look for this as per snowden docs dumped on cell meta data


The idea is you don't use baseband functionality at all in the main high-side device. It can be a PDA, connected over USB to a separate radio. There's no way the radio can do anything particularly evil except if there are implementation bugs over USB (API problems with whatever interface you build between them, most likely), but at least that can be inspected by end users and problems found/fixed.

These highly-integrated devices are basically inimical to decent security.

No (that project was an earlier version of blackphone/geekphone, actually! from what I've heard)


I believe you have the right idea. To isolate audio/message encryption in one box, stream it via IP to cellular (LTE/4G/etc) towers in another box. Then, the customer puts those two boxes into one box.

It could basically be done today with an Android PDA running VoiP app only, connected over wifi to a cellular hotspot in one's pocket. The next evolution would be to replace the wifi with a wired network.


I'm probably going to submit this + some specific privacy/location/etc. protecting services as a turnkey thing to DC/BH 2014. Also looking at a kickstarter for something on the "travel router which isn't a complete piece of crap" front.


I'm curious what you'd like to see in a travel router. Is it mainly the software or hardware you think needs work, or both?

On the software front, I have an OpenWRT image which I think works pretty well for travel which I've been meaning to publish (routes all traffic over an OpenVPN tunnel and can act simultaneously as a WIFI client to the hotel network and as an access point for your own network). The hardware is nothing special (WRT54GL) and it would definitely be nice if it were more portable. I'd love to hear your thoughts and will be looking forward to that kickstarter.


Hardware. USB powered. Dual radio, ideally dual dual band (so 4 radios which can be 1-4 in use). Ethernet port. Probably a USB port for 4g. Ideally a good form factor. Probably no battery, use a USB battery or laptop.

My goal would be to never ever connect my devices to wifi, and run everything through the device.

There are lots of attempts to make current hw work for this, but while you can get close, nothing is good enough IMO. I have the tplink, the belkin, etc with different firmware.

Enough flash and ram to run sane openwrt, and maybe options for a VPN client, and a stretch of Tor. Fitting that within the power budget would be the issue.


Thanks.

Yes, it sounds like it will be challenging to fit everything in the power budget. Do you think there's a need to use this on battery power? Won't most people be using it in a hotel room? A wall wart that's compact and dual-voltage would work for me and would provide much more power than USB.

I'll also put in a pitch for at least two Ethernet ports, so you can use one for connecting to the hotel and another for your LAN, in case WIFI's not cutting it or you need to connect a non-WIFI device (in my case, a VoIP phone).

One usability problem which has vexed me is that most hotels force you through a captive portal, which doesn't work if you're routing all traffic over a VPN. (Some even make you do it every 24 hours!) My latest solution is a special Ethernet port that's on a separate subnet which isn't routed over the VPN. You use that for going through the captive portal and then you switch over to WIFI or another Ethernet port. I think a hardware switch to turn the VPN on and off would also be a good solution.


Yeah, a hardware switch for VPN/non-VPN. Two ether might make as much sense as one, and it gives you a lot of flexibility. Ultimately I'd like to see something better than dumb captive portals, too, so some kind of partnership with the roaming wifi pass providers might make sense.

For the power budget, I really want to be able to use this powered by my laptop's USB port (or a big usb battery) so when I'm at an airport or something I can safely use wifi without having to find a power socket. One option is using more power than USB, and having a battery which is charged via USB, but that would suck.

I believe everything except Tor can fit within the power budget, even with 2 normal and 2 lower power radios, though.


There are also software features missing on current devices, especially in stock firmware. A really good firewall, VPN client, and other security tools would be nice. Central enterprise management and/or managed service as an option would also be wonderful. My main goal is execs who travel to China regularly.


For a portable firewall/router, I use a cubieboard running OpenBSD. It has a USB to DC cable that powers the device (no hdd attached) and runs LTE sticks fine. Costs $50 and runs a complete install to run Tor or whatever you want. Right now I have it running pf filtered VLANs to segregate devices, an authenticated AES wireless hotspot and Jondonym mix, which I tunnel all traffic through including Tor and i2p traffic. That way the local wireless carrier who you're using doesn't see any tor traffic.


The problem with doing wifi weird bridge mode where you are on both networks leads to performance issues on busy networks because you are necessarily on the same channels.

It might be worth giving that up since then existing hardware is usable.


Yeah, it's definitely suboptimal but it seems to work. If it's easy to have a second radio then you should probably have one. On the other hand, urban areas are usually so saturated with access points that using a separate channel might not gain you much.


Have you talked to The Grugq about this? Sounds like a beefed up version of PORTAL: https://github.com/grugq/portal


Yes, I talk to The Grugq a lot, although our relationship does not involve bonds of affection and/or personal obligation, and/or where the I and the foreign national share private time together in a public or private setting where sensitive professional and personal information is discussed or is the target of discussion.

But yeah. Grugq's doing a lot of other cool stuff now too.


I just tried this with a Huawei E1762 (casing removed) and a stripped down dongle. Crammed them both into the back of a Nexus and attached it using the case I have for a Seidio Innocell 3800mAh battery extention.

Activated airplane mode to kill the baseband, PPP widget runs fine on 4.2.2. Success. (kernel module loading not avail Android 4.3+ though obviously can build your own, or get a Moto G with native USB OTG support)


> Another problem is simply walking around with 2 phones which is an opsec indicator for feds that you are up to something and req targeted surveillance. They have full automated access to every cell tower db to look for this as per snowden docs dumped on cell meta data

Do you happen to have a link? That's pretty terrible for anyone with a work phone and a personal phone.


"Another problem is simply walking around with 2 phones which is an opsec indicator for feds that you are up to something and req targeted surveillance. They have full automated access to every cell tower db to look for this as per snowden docs dumped on cell meta data"

They, the feds, must be surveilling an awful lot of ordinary citizens because in my day job, delivery driver, I carry two phones. One issued by my company and my personal phone and on days when I'm working with another driver we'd have four phones in one vehicle. I can imagine there are quite a few people who have good reason to carry two phones regularly.


How can having two phones be an indicator that you are up to something? It is extremely common for working professionals to have both a personal mobile and a company mobile these days.


They do really complex analysis of patterns of how phones move, how they're powered up, call history, etc. It's actually really fascinating if you think about it and dig into it a bit, just like being able to largely identify (and sometimes effectively decipher) network traffic through analysis of encrypted message flows.

Just carrying two phones with you isn't the most interesting thing; it's a pair of people who normally have one phone during normal activity, and then at some location turn that phone off and turn on another phone which isn't used for anything except calling the other person briefly and hanging up without saying anything, and then those phones moving closely together, etc.

In my proposed case, there's no actual "second phone" on the cellphone network; your "phone" is a wifi only device which talks to a box which talks over data.

Traffic analysis is one of the things NSA does exceptionally well; the open crypto world is like 5 and maybe NSA is 7, but the open traffic analysis world is more like 2 and NSA is a 9.


Fully support the initiative for an open baseband.

I would love to live in a world where this can happen. But we don't live in that world.

The carriers have paid billions of dollars for exclusive use of their frequency bands. And their hundreds of billions of dollars of revenue depend upon smooth operation of all devices on the network using those bands. They will use whatever means to protect this.

OK, so let's talk to the FCC (and all the other agencies around the world), and get some other frequency band we can use for our totally open phones.

Well... there aren't any open ones left in the good range of approximately 700MHz to 2GHz. This is the part of the frequency spectrum that has decent carrying capacity, good penetration, and not too high power requirements. It is basic physics. Go lower in frequency, and you can't carry enough bits to be useful. Go higher in frequency and you start getting stopped by walls and such.

All the good bands have been allocated in the USA and elsewhere for TV, existing carriers, military, satellite, and so on. At a minimum, you'd need tens of billions to lobby for and buy a decent chunk of spectrum. And you need to get the current users moved off, which they won't like.

All we have left are the 'crap' bands like 2.4GHz (microwave oven interference). 5GHz isn't too bad (not a lot of other interferers) but it is short range with the current regulations. Another open band for unlicensed use at 60GHz gets stopped by walls, air (oxygen)...


I don't understand. If I come to a carrier and say "Here's a codebase for your baseband. It's OSS, well tested, secure, and supported. Buy support from me." why won't they go for it. Surely, an OSS solution is cheaper for them than developing an in-house crap solution that I'm sure it is now.

Also, is there any harm in just open sourcing their baseband code? It seems to me that it's worthless without the license to use the frequency anyways, so who cares if the code is open from a losing business point of view. On the other hand, things like security review are to the carriers' and manufacturers' benefit, no?


If I come to a carrier and say "Here's a codebase for your baseband.

The carriers don't want baseband code, they just want finished products to sell.

It's OSS, well tested, secure, and supported. Buy support from me." why won't they go for it. Surely, an OSS solution is cheaper for them than developing an in-house crap solution that I'm sure it is now.

OK, assuming you get a current-generation baseband chip for free (it actually costs a ton of money to develop) with full documentation, you're still talking hundreds of millions to develop that software. GSM (a 2G technology) is complicated. UMTS / HSPA (one of the 3G techs) is an order of magnitude more complex. LTE (4G) is another order of magnitude more complex than 3G. The baseband code, plus all the testing code, plus all the testing required by the FCC, standards bodies and the carriers is a ton of money.

It costs millions to take an existing chipset (which has already been approved), an existing baseband codebase (which has also already been approved for use with that chipset) and put that into a modem and get that approved.

The chip vendors have their own baseband code now, and they are all in fierce competition with each other. They aren't going to just use your code, and they aren't going to let you use their chips either.


OK, thanks for the explanation. So it sounds like this comes down to vendors competing and not wanting to have their code exposed for fear that others might copy their chip + code when the vender is the one paying all the fees to make the chip + code usable. I guess this is similar to Nvidia vs AMD (vs Intel I suppose), except perhaps even more entrenched and without much hope of a community reverse engineering a solution.

This sucks. Do we have any alternatives? Are there any completely open radio chips in development?


> except perhaps even more entrenched

By a lot. On the plus side, all the specs to create a component in a cellular network(protocols, procedures, network architecture and so on). are open and free.

On the other hand, the specs that cover all the parts of a cellular system is _many_ thousands of documents - and there's patents hidden in quite a lot of them.

> without much hope of a community reverse engineering a solution.

* specs for the chipsets are not available.

* You might get the spec. for the pinouts for the chips if you sign an NDA, but not the specs for being able to run your own code on it.

* But the chipset manufacturers won't talk to you unless you're serious about buying quite a few million of them anyway.

http://bb.osmocom.org/ have managed to reverse engineer an old GSM chipset (with help from leaked documents and source code) and created an open source GSM base band for those old phones. But there's little to suggest doing the same for 3G or 4G will be possible in the near future.


So it sounds like this comes down to vendors competing [...] I guess this is similar to Nvidia vs AMD (vs Intel I suppose) [...]

Yes, exactly. Sometimes just seeing how something is organized, or the API can give significant clues to how it is done. It is much harder to start from scratch.

Do we have any alternatives? Are there any completely open radio chips in development?

See my parent post. First you need a few billion dollars to buy some spectrum.


> See my parent post. First you need a few billion dollars to buy some spectrum.

So that's the tragedy of the mobile computing revolution isn't it then? That communication tech is technically a free market but realistically is controlled by very few corporations with very deep pockets. I did not realize that this is how it was set up and now I am sad.


Are you aware of Fabrice Bellard's 4G LTE software base station?

http://bellard.org/lte/


I was not aware of this. It is not open-source though, and it is really just for research purposes.

Its actually quite impressive how much they've implemented, though it is still a small fraction of the software you'd need to run an actual cell network.


It's not just for research purposes, as it's sold by Amarisoft as Amari LTE 100:

http://www.amarisoft.com/?p=amarilte

It's also not "they", as it's been developed by a single programmer. Certainly, Bellard is no ordinary programmer, but this should still give some perspective to your claim of the millions of dollars required for development.


If it's OSS, then users are empowered to modify the code for their own purposes in ways that degrade or deny service to others.

Code could be released for inspection, but you can't be allowed to actually run modified code on real radios outside of RF-isolated testing facilities.


Ironically, the market seems to be not optimizing for optimal net revenue (income minus costs, where here you're minimizing costs), but for control. This is partly because of the control freak nature of these companies, partly because the government demands it, but also, again ironically, because of long term thinking: if these companies can lock people out and control them, that helps to guarantee future profits. The free market can sometimes be a cruel bitch bent on the end-user's oppression.


Sounds more like the market is stuck at a local profit maximum instead of a global profit maximum. As in, they think they are making as much profit as they can, but in reality if they invested more into something that's not directly consumer facing they'd be end up making more money in the long run. Except this long term thinking is less appealing than the status quo so they just stick with what they know.


I think theres a misunderstanding here. Nobody wants to buy the actual frequency spectrum or compete with carriers; we just want to control the software and processor that does the GSM, 3G and LTE communication, on whatever frequency.

(That is not to say carriers won't do everything in their power to stop actual open source software and hardware implementations; mobile only works because all the devices behave nicely according to the specification, an attacker could with very little power severely compromise the network. There is just a very large barrier to entry, and dumb, bruteforce solutions can be triangulated.)


> Fully support the initiative for an open baseband.

How do you ensure that the manufacturer doesn't modify the baseband code?



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

Search: