Multicast is common - at constrained scopes. It's used for router communication (OSPF, IS-IS, RIP2, GLBP), rendezvous/zero-conf (mDNS), and as some other commenters have noted, also for single-carrier IP TV, depending on the carrier. There's a few education and research networks that use it, too.
Global multicast is non-existent, because it's hard to charge for.
The well known ports part is right, the rest is not quite right.
TCP connections are identified on each host by a 4-tuple of (my IP, my Port, their IP, their Port). So as a web server I can have multiple active connections on port 80, but they must all be with distinct combinations of remote IP and port. As a web browser, I can open multiple connections to the web server as long as I use different local ports.
I can demonstrate this by running a network socket listening program on two hosts (let's call them 10.0.0.1 and 10.0.0.2 to protect the innocent) both on port 9001. I can then use one of those hosts to open two TCP connections, one to each of the hosts, and both from source port 9002. My netstat output after doing this:
tcp4 0 0 10.0.0.1.9001 10.0.0.1.9002 ESTABLISHED tcp4 0 0 10.0.0.1.9002 10.0.0.1.9001 ESTABLISHED tcp4 0 0 10.0.0.1.9002 10.0.0.2.9001 ESTABLISHED
You can see that host 10.0.0.1 has both halves of the same connection (10.0.0.1:9002 -> 10.0.0.1:9001) and one half of the other connection (10.0.0.1:9002 -> 10.0.0.2:9001). All three connections are uniquely identified by their 4-tuples; if I try to create another connection from 10.0.0.1:9002 to 10.0.0.1:9001, I get an error: "Address already in use." Slightly misleading, since it's the entire 4-tuple that's already in use, but nevertheless could be solved by using a different local address.
They're the same authors who use nothing but a big Flash object.
In any case, a canvas element is not opaque. If you do your own obnoxious advertising, it's an easy decision to avoid your site. If you pull it in from a partner, it's easy to filter out that scripting resource request based on domain.
Not too worried about HTML5 'filling the void' myself. NoScript covers a large number of the potentially obnoxious uses already. The same techniques used for blocking Flash object/embed elements can be trivially extended to canvas, video and audio elements. CSS animations can be manipulated in the DOM (or at load time) to either strip them out completely, remove unconstrained animations, or toggle them on and off.
Better yet, though, video and audio elements can just have autoplay disabled. The asset can begin to download, so you don't need to wait, but there's no way for some fuckface web designer to decide their choice about when the video plays trumps yours; no more videos starting up in two or three tabs at once. Very hard to do with Flash, very easy to do with a video element.
... security researcher Mila Parkour reported it to Adobe after analyzing a rogue PDF document attached to spam.
Reads like Parkour reported an exploit being used actively in the wild to Adobe, to me. Which would make the sequence of events (1), (2), and this a zero day exploit. Silly term in any case, the relevant terms are, imo, "fixed" and "ongoing."
See the iOS Programming Guide information for details. The second last bullet point in the transition guide that, of course, every developer read before rebuilding for iOS 4.0 is:
Remove sensitive information from views before moving to the background. When an application transitions to the background, the system takes a snapshot of the application's main window, which it then presents briefly when transitioning your application back to the foreground. Before returning from your applicationDidEnterBackground: method, you should hide or obscure passwords and other sensitive personal information that might be captured as part of the snapshot.
I guess whatever map you were looking at doesn't count as sensitive personal information. Sounds like there's a market opportunity for iThief - obscures your maps so the cops don't know where you picked your kids up from last week when they catch you in the vicinity of a crime via cell tower triangulation!
Apple keeping the carriers out of the phone operating system was by far the greatest contribution of the iPhone to the mobile market place, in my opinion. I'll take slavish obedience to Apple over slavish obedience to my carrier.
(And my carrier has never let me get away with anything so cheap as US$99/yr to develop and install whatever the hell I like on my phone - remember, Apple's restrictions all apply at the App Store's gates, as a tinkerer, I have no issues and no need to jailbreak my phone).
Feel free to adjust the original statement to "Macs (and the non-jailbroken iPhone) do not yet have any active viruses in the wild." I don't mind, I'm not here to attack or defend the iPhone.
I do find it interesting that a worm with limited scope and no stealthiness is still sufficiently active to attack new targets inside a short window of opportunity. One might say it's active in the wild, even:-)
Macs (and the iPhone) do not yet have any active viruses in the wild.
True, that. No self-replicating agents that infect host applications for iPhone or Mac.
But there are self-replicating agents that survive independent of host applications for the iPhone. The rickroll worm is still active and scanning network ranges frequently enough that you probably want to turn off 3G while you install sshd, so you have time to change the root password. And there's a more malicious but less common strain seen in the Netherlands that lifts banking credentials.
The particular vulnerability used by the jailbreak team is the type that's very commonly used to add a Windows host to a botnet, by injecting a malicious PDF or Flash object into an advertising network or through a hosted web exploit of some kind. It's disturbing to think that my iPhone could be added to a botnet by visiting a web site. It'd be pretty expensive to have my 3G connection flooded by spam delivery or a DoS attack. While I support the notion of jailbreaking, this is one hole I hope is closed very soon.
I also wonder if this problem applies to the Mac PDF software. Not necessarily true, different architectures and all, but possible.
It does mean you're carrying around that extra weight all the time, and your laptop has to accommodate both the extra size of the brick and the extra heat generated by it.
I'm gonna add to the masses praising Apple's laptop bricks. The magsafe connectors are great, but as a relatively frequent international traveller the swappable pins are a massive boon.
While it's true that the ocean is teeming with life, there's not so many human settlements out at sea, so an increase in the surface area of the oceans isn't really optimal for human life.
AGW means fewer humans can live on the planet at once. Care to volunteer your genetic line to be the fat that gets trimmed?
I don't really think the cost of supporting WP7 is likely to be met by the potential returns on the platform.
But if you really want to go there, and you really want to maximise code sharing, and you're OK with throwing away large feature sets of both platforms to achieve that, you can use C++ with #defines to work around the syntax differences for pointers. You can't use any of the other C++/CIL features, but then, neither can you use any of the Objective-C++ features.
I'm not defending Apple's policy. The Lemmings app was written in C, and does not fall afoul of that clause. I haven't seen a developer agreement for WP7, but if the platform itself forces you into vendor specific languages, it doesn't seem necessary to have it in legalese.
Dev environment, no. Code translator, no, if the project was originally written in Objective-C, C, C++, or JavaScript. Since it was written in C, it doesn't even come into play.
But bonus points for noting that Apple is fascist! Take that, The Man! Woo!
They need to stop selling a product and start selling a service.
The product, a digital file, has no value. It costs nothing to make. Therefore, if you attempt to compete by selling your zero-cost item for less money than the other guy, you're in a race towards free. If the other guy has no production costs of offset, you lose. And there's no extra value you can add to a digital file that can't also be copied for nothing.
The service, distributing digital files, has value. The act of aggregating, recommending, categorising, and indexing digital files offers a convenience. You can charge for that service. iTunes charges per track. Some of these shadier places charge per month. Either way, the charge is really for the service, not the product.
The service itself can now compete based on its technical merits (imagine an iTunes store that wasn't locked to a tab-less embedded browser!) or on its content. Production costs are now an investment in providing the service with exclusive content. Costs sunk currently on buying chart positions become a marketing cost for the service, instead of the content.
The best thing about this is that iTunes has already proven that this service model works. It's been over two years since the iTunes music store passed Walmart to become the #1 retailer in the US. It's been over two years and the music distribution industry hasn't had the lightbulb turn on over their heads yet.
You can self-publish books to the iBookstore. When you can self-publish music to the iTunes store, the RIAA will die.
The thing is, few people would ever pay a $2mil judgement. Most would be forced into bankruptcy. Many would be forced there by $54k - of the rest, most would be forced to sell their home to cover it.
I dunno about you, but in terms of generating fear, starting my life from scratch is nearly as bad as bankruptcy. I'd sooner boycott buying and pirating of RIAA labels than risk either one.
Sort of like the endless stream of touch-screen phones that launched in the wake of the iPhone, with vision-less product designers somehow thinking that it was touch alone that made the iPhone popular.
Except just copying the suck.
I expect next week we'll hear a leak about non-replaceable batteries.
If by "many" you mean "two"... then, yes. Mac virus scanners of the time were not able to detect them, either, so you know, still not a good argument for the dungware that is AV software.
Apple still isn't targeting the mass market with their computers. They continue to produce and market as trendy consumer items, not attempting to compete on price. So I have my doubts that their market share will ever grow large enough to (a) be a serious threat to Microsoft or (b) be a worthwhile investment in virus development.
(But I still take reasonable steps to protect myself, with an external firewall, NoScript, and avoiding anything made by Adobe).
The extensions documentation has an entire section on blocking unwanted content.
The biggest problem is that extensions can't have any sort of significant UI - no pull-downs, no sub-menus in the context menu, just a button on the toolbar, a new toolbar, or injected HTML. Despite that, and the examples in the documentation being subtly wrong, I was able to throw together a proof-of-concept NoScript in a few hours.
It'll work very well for social networking type stuff, blogger bars, yahoo adware bars, that sort of thing.
What's interesting is that extensions are signed with a free to obtain certificate. That implies Apple will be able to revoke certificates for misbehaving extensions, disabling them. But since it is free to obtain a certificate, that's not a useful way to control popular extensions that do something Apple would rather they didn't, only extensions that do things individuals would rather they didn't, ie, trojans.
It would be cheaper to give the commissioner a free hotel room for the night, $100 worth of chips, and a hooker. Bonus points if you put a camera in the room and hold the footage for blackmail in case bribery ever stops working.
Insurance companies, after all, can't afford to pay out if claims are ever made.
Of course he did. He referred the matter to the AFP. The investigation is at his request.
I worry about the precedent that this case may set, if the sharks are allowed to smell blood in the water. If it's illegal to receive unencrypted broadcast packets on a public spectrum, what does that say about common devices which bind to the first available open network?
Hopefully sense will prevail in the courts.
Conroy is not a canny enough politician to be taking on Google's public affairs team, so hopefully prodding the giant will cause him sufficient hell that at the very least he loses his seat; I'd prefer something terrible enough that he's asked to resign, since that'll put him out of politics for good.
Slashdot Mirror
Multicast is common - at constrained scopes. It's used for router communication (OSPF, IS-IS, RIP2, GLBP), rendezvous/zero-conf (mDNS), and as some other commenters have noted, also for single-carrier IP TV, depending on the carrier. There's a few education and research networks that use it, too.
Global multicast is non-existent, because it's hard to charge for.
The well known ports part is right, the rest is not quite right.
TCP connections are identified on each host by a 4-tuple of (my IP, my Port, their IP, their Port). So as a web server I can have multiple active connections on port 80, but they must all be with distinct combinations of remote IP and port. As a web browser, I can open multiple connections to the web server as long as I use different local ports.
I can demonstrate this by running a network socket listening program on two hosts (let's call them 10.0.0.1 and 10.0.0.2 to protect the innocent) both on port 9001. I can then use one of those hosts to open two TCP connections, one to each of the hosts, and both from source port 9002. My netstat output after doing this:
You can see that host 10.0.0.1 has both halves of the same connection (10.0.0.1:9002 -> 10.0.0.1:9001) and one half of the other connection (10.0.0.1:9002 -> 10.0.0.2:9001). All three connections are uniquely identified by their 4-tuples; if I try to create another connection from 10.0.0.1:9002 to 10.0.0.1:9001, I get an error: "Address already in use." Slightly misleading, since it's the entire 4-tuple that's already in use, but nevertheless could be solved by using a different local address.
They're the same authors who use nothing but a big Flash object.
In any case, a canvas element is not opaque. If you do your own obnoxious advertising, it's an easy decision to avoid your site. If you pull it in from a partner, it's easy to filter out that scripting resource request based on domain.
Not too worried about HTML5 'filling the void' myself. NoScript covers a large number of the potentially obnoxious uses already. The same techniques used for blocking Flash object/embed elements can be trivially extended to canvas, video and audio elements. CSS animations can be manipulated in the DOM (or at load time) to either strip them out completely, remove unconstrained animations, or toggle them on and off.
Better yet, though, video and audio elements can just have autoplay disabled. The asset can begin to download, so you don't need to wait, but there's no way for some fuckface web designer to decide their choice about when the video plays trumps yours; no more videos starting up in two or three tabs at once. Very hard to do with Flash, very easy to do with a video element.
From TFSummary:
Reads like Parkour reported an exploit being used actively in the wild to Adobe, to me. Which would make the sequence of events (1), (2), and this a zero day exploit. Silly term in any case, the relevant terms are, imo, "fixed" and "ongoing."
See the iOS Programming Guide information for details. The second last bullet point in the transition guide that, of course, every developer read before rebuilding for iOS 4.0 is:
I guess whatever map you were looking at doesn't count as sensitive personal information. Sounds like there's a market opportunity for iThief - obscures your maps so the cops don't know where you picked your kids up from last week when they catch you in the vicinity of a crime via cell tower triangulation!
Apple keeping the carriers out of the phone operating system was by far the greatest contribution of the iPhone to the mobile market place, in my opinion. I'll take slavish obedience to Apple over slavish obedience to my carrier.
(And my carrier has never let me get away with anything so cheap as US$99/yr to develop and install whatever the hell I like on my phone - remember, Apple's restrictions all apply at the App Store's gates, as a tinkerer, I have no issues and no need to jailbreak my phone).
I guess, technically, bogans are a subset of real Australians.
And I'll glass any cunt that calls me a bogan.
That's only 10,000 combinations. Brute force script it. Don't bother testing for success, just blast 10,000 HTTP requests at them.
Feel free to adjust the original statement to "Macs (and the non-jailbroken iPhone) do not yet have any active viruses in the wild." I don't mind, I'm not here to attack or defend the iPhone.
I do find it interesting that a worm with limited scope and no stealthiness is still sufficiently active to attack new targets inside a short window of opportunity. One might say it's active in the wild, even :-)
True, that. No self-replicating agents that infect host applications for iPhone or Mac.
But there are self-replicating agents that survive independent of host applications for the iPhone. The rickroll worm is still active and scanning network ranges frequently enough that you probably want to turn off 3G while you install sshd, so you have time to change the root password. And there's a more malicious but less common strain seen in the Netherlands that lifts banking credentials.
The particular vulnerability used by the jailbreak team is the type that's very commonly used to add a Windows host to a botnet, by injecting a malicious PDF or Flash object into an advertising network or through a hosted web exploit of some kind. It's disturbing to think that my iPhone could be added to a botnet by visiting a web site. It'd be pretty expensive to have my 3G connection flooded by spam delivery or a DoS attack. While I support the notion of jailbreaking, this is one hole I hope is closed very soon.
I also wonder if this problem applies to the Mac PDF software. Not necessarily true, different architectures and all, but possible.
It does mean you're carrying around that extra weight all the time, and your laptop has to accommodate both the extra size of the brick and the extra heat generated by it.
I'm gonna add to the masses praising Apple's laptop bricks. The magsafe connectors are great, but as a relatively frequent international traveller the swappable pins are a massive boon.
While it's true that the ocean is teeming with life, there's not so many human settlements out at sea, so an increase in the surface area of the oceans isn't really optimal for human life.
AGW means fewer humans can live on the planet at once. Care to volunteer your genetic line to be the fat that gets trimmed?
I don't really think the cost of supporting WP7 is likely to be met by the potential returns on the platform.
But if you really want to go there, and you really want to maximise code sharing, and you're OK with throwing away large feature sets of both platforms to achieve that, you can use C++ with #defines to work around the syntax differences for pointers. You can't use any of the other C++/CIL features, but then, neither can you use any of the Objective-C++ features.
I'm not defending Apple's policy. The Lemmings app was written in C, and does not fall afoul of that clause. I haven't seen a developer agreement for WP7, but if the platform itself forces you into vendor specific languages, it doesn't seem necessary to have it in legalese.
Dev environment, no. Code translator, no, if the project was originally written in Objective-C, C, C++, or JavaScript. Since it was written in C, it doesn't even come into play.
But bonus points for noting that Apple is fascist! Take that, The Man! Woo!
Sorry your boss sucks so bad, man.
They need to stop selling a product and start selling a service.
The product, a digital file, has no value. It costs nothing to make. Therefore, if you attempt to compete by selling your zero-cost item for less money than the other guy, you're in a race towards free. If the other guy has no production costs of offset, you lose. And there's no extra value you can add to a digital file that can't also be copied for nothing.
The service, distributing digital files, has value. The act of aggregating, recommending, categorising, and indexing digital files offers a convenience. You can charge for that service. iTunes charges per track. Some of these shadier places charge per month. Either way, the charge is really for the service, not the product.
The service itself can now compete based on its technical merits (imagine an iTunes store that wasn't locked to a tab-less embedded browser!) or on its content. Production costs are now an investment in providing the service with exclusive content. Costs sunk currently on buying chart positions become a marketing cost for the service, instead of the content.
The best thing about this is that iTunes has already proven that this service model works. It's been over two years since the iTunes music store passed Walmart to become the #1 retailer in the US. It's been over two years and the music distribution industry hasn't had the lightbulb turn on over their heads yet.
You can self-publish books to the iBookstore. When you can self-publish music to the iTunes store, the RIAA will die.
... you mean Disneyland?
The thing is, few people would ever pay a $2mil judgement. Most would be forced into bankruptcy. Many would be forced there by $54k - of the rest, most would be forced to sell their home to cover it.
I dunno about you, but in terms of generating fear, starting my life from scratch is nearly as bad as bankruptcy. I'd sooner boycott buying and pirating of RIAA labels than risk either one.
All well true, but I wonder why you think (pre-conviction) rapists and murderers aren't voters too? :-)
Sort of like the endless stream of touch-screen phones that launched in the wake of the iPhone, with vision-less product designers somehow thinking that it was touch alone that made the iPhone popular.
Except just copying the suck.
I expect next week we'll hear a leak about non-replaceable batteries.
If by "many" you mean "two" ... then, yes. Mac virus scanners of the time were not able to detect them, either, so you know, still not a good argument for the dungware that is AV software.
Apple still isn't targeting the mass market with their computers. They continue to produce and market as trendy consumer items, not attempting to compete on price. So I have my doubts that their market share will ever grow large enough to (a) be a serious threat to Microsoft or (b) be a worthwhile investment in virus development.
(But I still take reasonable steps to protect myself, with an external firewall, NoScript, and avoiding anything made by Adobe).
The extensions documentation has an entire section on blocking unwanted content.
The biggest problem is that extensions can't have any sort of significant UI - no pull-downs, no sub-menus in the context menu, just a button on the toolbar, a new toolbar, or injected HTML. Despite that, and the examples in the documentation being subtly wrong, I was able to throw together a proof-of-concept NoScript in a few hours.
It'll work very well for social networking type stuff, blogger bars, yahoo adware bars, that sort of thing.
What's interesting is that extensions are signed with a free to obtain certificate. That implies Apple will be able to revoke certificates for misbehaving extensions, disabling them. But since it is free to obtain a certificate, that's not a useful way to control popular extensions that do something Apple would rather they didn't, only extensions that do things individuals would rather they didn't, ie, trojans.
It would be cheaper to give the commissioner a free hotel room for the night, $100 worth of chips, and a hooker. Bonus points if you put a camera in the room and hold the footage for blackmail in case bribery ever stops working.
Insurance companies, after all, can't afford to pay out if claims are ever made.
Of course he did. He referred the matter to the AFP. The investigation is at his request.
I worry about the precedent that this case may set, if the sharks are allowed to smell blood in the water. If it's illegal to receive unencrypted broadcast packets on a public spectrum, what does that say about common devices which bind to the first available open network?
Hopefully sense will prevail in the courts.
Conroy is not a canny enough politician to be taking on Google's public affairs team, so hopefully prodding the giant will cause him sufficient hell that at the very least he loses his seat; I'd prefer something terrible enough that he's asked to resign, since that'll put him out of politics for good.