Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Slashdot Deals: Deal of the Day - 6 month subscription of Pandora One at 46% off. ×

Comment Re:Easiest technical solution for this (Score 1) 138

I know every Android device I've used has either had non-existent support or barely functional implementations that were obviously set up and then forgotten about.

Quit using shitty devices that have been bastardized by the carrier and/or a fuckhead OEM that thinks they need to be a special snowflake.

My phone runs a pretty much pure build of the Android Open Source Project and all three forms of tethering work great. It even supports USB tethering to WiFi, which I've used to get my desktop online when my switch failed.

If it's broken on the devices you've used its because someone went out of their way to change it from the stock Android solution and either didn't care to test or intentionally wanted to break tethering.

Comment WAAAAY Overblown! (Score 5, Informative) 113

Here's a link to a page that actually describes the "vulnerabilities" they found:

All of them only apply to Voice over LTE environments, which are different from traditional mobile phone networks in that the LTE network is purely IP traffic so it's effectively a voice over IP call using standard protocols like SIP the same as an internet-based VoIP service would.

As someone who's been working in VoIP for over a decade I just have to laugh at this crap.

Let's start:

The Android operating system does not have appropriate permissions model for current LTE networks; the CALL_PHONE permission can be overruled with only the INTERNET permission by directly sending SIP/IP packets. A call made in such a manner would not provide any feedback to the user. Continually making such calls may result in overbilling or lead to denial of service.

Translation: A VoIP app doesn't require phone permissions if it's not accessing any of the OS' phone subsystems. No shit, sherlock.

The only way this could result in billing or denial of service is if the carrier was not properly authenticating the SIP traffic and was just assuming that anything from that phone aimed at the right IP address must be a legit call. That's 100% a carrier fault, not any flaw with the system. Do they propose that Android should be specifically watching for SIP traffic and require an app have the phone permission to be able to send it?

Apple reports that iOS is not affected by this issue.

I smell bullshit, but I don't have an iOS device to confirm. I doubt Apple requires that VoIP clients have special permissions over anything else.

Some networks allow two phones to directly establish a session rather than being monitored by a SIP server, thus such communication is not accounted for by the provider. This may be used to either spoof phone numbers or obtain free data usage such as for video calls.

This is carrier logic if I've ever heard it. Using the data service I pay for to send IP traffic (which happens to contain voice or video) directly to another user on the data service they pay for is somehow a vulnerability? Again I'm not sure how this is platform-specific.

Spoofing numbers again would require that the carrier have their network configured in a stupidly open and trusting fashion. None of my customers can spoof numbers unless I allow them to (hint: I don't) and it wasn't rocket science to set things up that way.

Some networks do not properly authenticate every SIP message, allowing spoofing of phone numbers.

Repeating themselves here, while this time acknowledging that it's the network's problem.

Some networks allow a user to attempt to establish multiple SIP sessions simultaneously rather than restricting a user to a single voice session, which may lead to denial of service attacks on the network. An attacker may also use this to establish a peer-to-peer network within the mobile network.

Well at least this time they blame the network from the start. I wouldn't limit users to a single session, that restricts 3/4 way calls, but reasonable limits are good there. Still not sure what would be wrong with endpoints directly contacting each other via the data service they're paying for.

I have no doubt that some carriers' networks are truly insecure enough to allow the spoofing and fraudulent usage described here, but that's entirely down to their own stupidity because none of these things are hard to prevent at the network level, even the ones that aren't actual problems.

Comment Re:The Line (Score 1) 928

There is a place for profanity laced arguments. There are times when the cluebat need to be applied. They should be the exception and preferably done in private. The problem comes when every discussion quickly devolves into name calling and profanity.

It is the exception though. LKML runs around 5000 messages a week and this sort of "Linus is mean" drama only comes up a few times a year if that. It's by no means every discussion. Linus has over 800 posts to the mailing list this year, which comes to somewhere around four a day assuming he's not working 7 days a week. All the examples I've ever seen have been preceded by much more polite conversation or have been flagrant violations of well known kernel dev policies by people who definitely should know better (such as the two cases Ms. Sharp specifically picked out a few years ago).

In at least one documented case with her Linus actually did take it off-list and she brought it back in to the public.

Just because a woman has brought it up does not make it a gender issue. In the end this is not a man or woman issue it is a civility issue.

You say this, but then you follow it up with making it a gender issue by saying this:

To all those who say "women should get thicker skins and not take things personally" I say "certain men should stop equating being right with their worth/masculinity or go back to the cave where they belong".

In a meritocracy, which all technical projects should strive to be, being right is directly equated with your worth as far as the project's concerned. Masculinity has nothing to do with it.

If someone who has been trusted with the maintainer role of an important subsystem, as both of the people in Ms. Sharp's earlier examples are/were, it's fair to expect that they understand the basic rules of kernel development. If they then try to violate those rules and go out of their way to defend those violations, it's fair to drop the politeness. If it's a recurring problem as Linus claims and I'm very willing to believe, it's not unexpected that someone might have very little patience.

Comment Re:Build timestamps mess this up (Score 1) 130

Why would a lot of code need to be "fixed" just because someone anally retentive wants deterministic builds? If they truly care they can LD_PRELOAD fake date/time libs.

The reason for deterministic builds is to allow those of us who want to use binaries from our distros for convenience sake verify that the binary is actually built from the source it claims to be from. It only takes a few people actually doing it to confirm things are good for all of us.

Basically it lets the lazy masses gain the same level of confidence in what they're running as those who compile everything from source.

I thought this problem was solved a long time ago by the bitcoin developers w/ gitian.

Bitcoin solved it as far as they needed for their own purposes, this project aims to solve it sufficiently to be generally applicable across the entire Debian operating system. The goal is that the entire Debian binary package repository could be audited by anyone who cares to do it. Obviously if it's generic enough to cover all of Debian the same techniques should be usable pretty much across the entire computing world.

Comment Re: Build timestamps mess this up (Score 1) 130

I know this is Slashdot and all, but you really should RTFA. Again that's covered and a variety of solutions are offered, but you are basically right in that doing this right requires that those things all be the same where they're used.

The tricky part here is determining in which cases those sorts of macros are actually required and thus must be worked around versus where they can be replaced with something else to achieve the same goal (replacing time/datestamped builds with git commit IDs for example) versus where they were just pointless (embedding the hostname of the build machine in to the binary for example).

Comment Re:Build timestamps mess this up (Score 4, Informative) 130

Pages 6 and 7 of the PDF linked cover time-related issues and basically agree, anything that builds time/date in to the binary is a problem that needs to be fixed.

Git revision on the other hand is a recommended solution, since it points at a specific state of the code and will always be the same if the code is unchanged.

Comment Re:This seems like a job for Virtual Box (Score 4, Insightful) 130

On the otherhand I don't quite understand why, if one can compile the source, one needs to worry about untrusted binaries. Perhaps the intent here is for some master agency to watch for tinkered binaries or to post it's own Checksums apart from Debian. Then everyone has two sources for validated checksums.

Almost right, except without the master agency. This isn't for the incredibly paranoid types who would already be compiling from source. This is for the rest of us, the lazy people who would rather "apt-get install foo" and just assume the distro's doing things right. If the builds are reproducible then eventually someone's going to verify them. If no variations are discovered, the rest of us lazy masses can be a lot more confident that we're not running anything unexpected.

Comment Re: Uninstall would be nice (Score 1) 80

Or at least disable. Some of these apps don't even let you disable them. I know that doesn't actually free up any space if you just disable, but uninstalling doesn't help so much either because these preinstalled apps are on the /system partition, and removing them doesn't give you any more space on your /data partition.

Actually it can, sometimes. The copy in /system is undeletable to a normal Android system, but that also means it can't be updated. Where do the updates for these apps go? /data of course.

That said I'm pretty sure stock Android allows you to remove updates for those apps and regain that space, but I'm not 100% sure since I haven't run a stock Android system in years.

Comment Re: Uninstall would be nice (Score 1) 80

"easy". "need to know what you're doing".

Does not compute.

Riding a bicycle is easy, but you still need to know what you're doing.
Driving a car is easy, but you still need to know what you're doing.
etc, etc.

There are plenty of things we do every day that are really easy once you know what you're doing, but can be incredibly intimidating to someone who's never done it.

Comment Simple... (Score 1) 373

This one's really easy. Don't buy a car where the core system is internet connected unless you're confident in its security.

The Fiat/Chrysler hack was insane, the result of a total disregard for security.

The Tesla "hack" barely deserves being called that as it requires physical access to the car's data bus to work. Pretty much every car on the market these days is "vulnerable" to that, but it's stupid to worry about because that's like saying your brake system is "vulnerable" to being cut.

Likewise with the Corvette.

I wish the fucking stupid media would stop publicizing any of these that require installing extra hardware in to the car as if they actually mattered.

Comment Re:More practical.... (Score 1) 90

"Most common 1000 words" is great for making a point.

Far more practical would be using a vocabulary that almost all 10-year-old native speakers can read and that a vast majority of non-native speakers who have spent the last few years living in a English-speaking environment (that is, an environment that pretty much forces you to learn to speak and read English at a basic level in order to survive).

I would expect this to be far more than 1000 words.

I believe the idea is based on the Simple English Wikipedia which suggests sticking to the same top 1000 common words where possible. Now your same point may apply there, I can't find an actual justification for the recommended limit other than the basic thought that "it's simpler", but it's not unprecedented.

Comment Re:But... but? (Score 2) 172

LOL ... who the hell still has access to usenet feeds?

Usenet is alive and well with some nice automated tools that handle all the processing of downloads and even download things for you. Search "NZB" and have fun. I just tell my home server what I want to watch and it handles the rest for me.

Were there fewer fools, knaves would starve. - Anonymous