Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Re:It'll be obsolete by then... (Score 2) 221

by foom (#35210040) Attached to: As HTML5 Gets 2014 Final Date, Flash Floods Mobile
Nope. You've never been able to write pages against the HTML4 standard, and you certainly can't now. No browser "properly" implements HTML4, and to the best of my knowledge, never has, and never will. Just you try writing a document that looks like the below, and see if you can find a browser that renders it properly. Of course, if you do find such a browser, it probably can't render actual webpages properly...

This *is* valid HTML4 syntax:
<html<head<title/Foo/</><body<p<a href="foo"/link text/, hooray!</>

Comment: Cable box + firewire output (Score 2, Informative) 536

by foom (#30306162) Attached to: Best PC DVR Software, For Any Platform?

I use:
4) Cablebox with Firewire output + firewire port on PC.

It works really quite well.

Cable companies are required to offer cable boxes with firewire (usually the HD ones all come with it). However, depending on your cableco, the firewire output may or may not be encrypted. You can only connect it to your PC if it is not encrypted.

Note that the presence or absence of encryption on the Firewire output is *totally independent* from whether the data is encrypted on the cable line. The cable box decrypts the signal with its cable card, and possibly re-encrypts it for the firewire output, depending on the cableco's settings.

For me (with RCN Boston), I've found that all the extended-basic channels are sent unencrypted over the firewire output, except, paradoxially, *sometimes* the HD OTA channels. I dunno what's up with that, but my solution was to just not go through the cable box for those channels. I don't subscribe to premiums, so I don't know whether they are encrypted or not. Your mileage may of course vary, depending on provider and possibly even region.

Comment: Re:Have you tried the alternative store? (Score 4, Informative) 509

by foom (#28764189) Attached to: How Apple's App Review Is Sabotaging the iPhone

I'm sure part of the problem with the "unofficial" app store is that it's quite likely that one of these days, Apple will get serious, and make a bootloader without glaring security holes in it. (I mean come ON, Apple, the bootloader isn't that big!...)

When that happens, it may be impossible to "permanently" unlock an iPhone without hardware mods, which will seriously limit the Jailbreak community -- probably into irrelevance.

That's a rather big risk for anyone to take on in their development...

Heck, I'm not even bothering to learn to write for the iPhone as a *hobby*, because it'd be a waste of my time. Pretty much everything I want to write isn't allowed by Apple's rules, and while my phone is Jailbroken, Apple is trying (so far, completely incompetently...) to prevent me from being able to buy a new jailbreakable iPhone ever again. So it seems to me that the iPhone is basically a dead-end platform.

Comment: Re:Tracking Debian Stable instead of Testing (Score 1) 132

by foom (#28760879) Attached to: Linux Distributions' Tracking of Upstream Projects Examined

(they still consider critical bugs of almost unknow and barely used packages as release-critical bugs that can stop the release of widely used and know packages with no critical bugs?).

Not true. Unfixed release-critical bugs in unknown and barely used packages result in the package being removed from the release, not the release being delayed.

Security

New Firefox Standard Aims to Combat Cross-Site Scripting 160

Posted by ScuttleMonkey
from the fight-the-good-fight dept.
Al writes "The Mozilla foundation is to adopt a new standard to help web sites prevent cross site scripting attacks (XSS). The standard, called Content Security Policy, will let a website specify what Internet domains are allowed to host the scripts that run on its pages. This breaks with Web browsers' tradition of treating all scripts the same way by requiring that websites put their scripts in separate files and explicitly state which domains are allowed to run the scripts. The Mozilla Foundation selected the implementation because it allows sites to choose whether to adopt the restrictions. 'The severity of the XSS problem in the wild and the cost of implementing CSP as a mitigation are open to interpretation by individual sites,' Brandon Sterne, security program manager for Mozilla, wrote on the Mozilla Security Blog. 'If the cost versus benefit doesn't make sense for some site, they're free to keep doing business as usual.'"

Comment: Re:Optimistic guy (Score 1) 127

by foom (#28483991) Attached to: Kaminsky On DNS Bugs a Year Later and DNSSEC

Your statistic would be valid for no cache vs a cache.

But that's not the actual question at hand.

The question is:
What's the cache hit rate for a recursive cache serving a group of machines, vs. the cache hit rate for a recursive cache serving just a single machine.

I'm going to place my bet on nowhere near a 10x increase in traffic from having an unshared local cache.

But I haven't done the test. If anyone wants to (or knows of literature that's already explored this)...

Comment: Re:Optimistic guy (Score 1) 127

by foom (#28476447) Attached to: Kaminsky On DNS Bugs a Year Later and DNSSEC

A "validating stub resolver" will actually need to be (basically) a recursive resolver itself (it needs to do multiple queries to verify each signature in the delegation chain from the root down to the record it's actually interested in). And thus, if you want it to perform well, it'll need a local cache.

Now it's basically a caching recursive resolver.

So, is your claim that because the caching recursive resolver which you run on localhost can use a second-level remote cache instead of talking to the authoritative servers directly, DNSSEC is superior?

I suppose you can consider that an advantage...but heck, I sure can't see the point of it. If you're going to require a caching recursive resolver on localhost, just have it talk to the authoritative servers and be done with it... It certainly doesn't seem worth all the pain of DNSSEC to allow for an untrusted intermediate cache to be used!

I just don't see it.

Comment: Re:Optimistic guy (Score 1) 127

by foom (#28468249) Attached to: Kaminsky On DNS Bugs a Year Later and DNSSEC

Huh?

DNSSec doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because you can't do DNSSec from a stub resolver and have to use TSIG (which protects the client->server data transfer, not the zone data).

DNSCurve doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because DNSCurve protects the client->server data transfer (of each step of the process) not the zone data.

You're screwed either way.

Or, you can decide to either use a different resolver somewhere on the internet you *do* trust (and configure its key so you can be sure you're actually talking to it!), or run a caching recursive resolver on your laptop. Either of those will give you properly secured DNS with both DNSCurve and DNSSEC.

Comment: Re:Optimistic guy (Score 2, Interesting) 127

by foom (#28467377) Attached to: Kaminsky On DNS Bugs a Year Later and DNSSEC
I'm just going to repost my last comment on this subject. I don't think things have changed since then, but if they have I'd certainly be interested to know. :)

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

Businesses

Taking Gaming To the Next Billion Players 116

Posted by Soulskill
from the one-console-per-child dept.
Hugh Pickens writes "June marks the launch across Brazil of Zeebo, a console that aims to tap an enormous new market for videogaming for the billion-strong, emerging middle classes of such countries as Brazil, India, Mexico, Russia and China. Zeebo uses the same Qualcomm chipsets contained in high-end smartphones, together with 1GB of flash memory, three USB slots and a proprietary dual analogue gamepad. It plugs into a TV and outputs at a 640 x 480 pixel resolution. 'The key thing is we're using off-the-shelf components,' says Mike Yuen, director of the gaming group at Qualcomm. This approach means that, while Zeebo can be priced appropriately for its markets — it will launch at US $199 in Brazil compared to around US $250 (plus another US $50 for a mod chip to play pirated games) for a PlayStation 2 in the region — and next year the company plans to drop the price of the console to $149. But the most important part of the Zeebo ecosystem is its wireless digital distribution that gets around the low penetration of wired broadband in many of these countries, negates the cost of dealing with packaged retail goods, and removes the risk of piracy, with the games priced at about $10 locked to the consoles they're downloaded to. Zeebo is not meant to directly compete with powerful devices like Sony's PlayStation 3, Microsoft's Xbox 360, or the Wii. 'In Latin America, where there's a strong gaming culture, that's what we'll be, but in India and China we can be more educational or lifestyle-oriented,' says Yuen. One Indian gaming blog predicts Zeebo will struggle, in part due to the cultural reluctance toward digital distribution and also the lack of piratable games."

Comment: Re:DNSCURVE doesn't work... (Score 2, Informative) 179

by foom (#26053065) Attached to: DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

He who has but four and spends five has no need for a wallet.

Working...