Forgot your password?

Comment: Re:Is this technically impossible - no. (Score 2) 189

This works because iMessages are stored on your device, and not the server. So when you change your password, and update your devices password's the iMessages will re-transmit their history to other devices. So no, not wrong.

If you pull all of your devices offline and reset them, and then take them back online, the history won't be available to sync so all your messages will be gone. Apple does manage delivery, but the initial handshake is done by a peer to peer key exchange, so while Apple is caching and flinging data, they don't sit in the middle of the key exchange, so they can't read messages.

Email is another matter. The nature of how email works means they probably have some sort of access.

All the complaints about how buggy iMessages is make sense when you look at all the mechanics that they go through to keep messages secure.

Comment: Re:Ask anyone still on Dial Up (Score 1) 526

by maccodemonkey (#47895285) Attached to: AT&T Says 10Mbps Is Too Fast For "Broadband," 4Mbps Is Enough

4mbps is 100 times faster than dialup, if not more because where I can usually get the full speed of my broadband connection, I almost never got the full speed of dialup, usually around 33kbps. What took a week to download on dialup takes 1 hour on 4 mbps.

You're right. It's faster than dial up. That STILL doesn't make it broadband. The definition of broadband is not 'It's faster than dial up."

If we're still calling the 100 mbps cable connection I have now broadband 30 years from now because it's faster than dial up... Well that's just going to be stupid.

Comment: Re:I don't care. (Score 1) 108

by DaphneDiane (#47861971) Attached to: Why Google Is Pushing For a Web Free of SHA-1

That's why I always use ROT-13 twice. It completely eliminates the risk of that form of decryption.

Because I had to worry about clients using XP SP2, I'm stuck using ROT-1. But I found that if I use it 26 times, it gives just as good protection and also avoids the inverse directional issues ROT-1 has with some implementations.

Comment: Re:Ask anyone still on Dial Up (Score 5, Insightful) 526

by maccodemonkey (#47857567) Attached to: AT&T Says 10Mbps Is Too Fast For "Broadband," 4Mbps Is Enough

Give anyone 4 mbps connection who is living in an area that still has dialup as their only option, and ask them if its broadband. If someone works to bring 4/1 mbps connections to more areas, they should be able to advertise it as broadband.

That's like saying I should be able to advertise my bicycle as a car if I'm selling it in an area that is still using horses.

Comment: Re:Sigh (Score 1) 748

by maccodemonkey (#47705437) Attached to: News Aggregator Fark Adds Misogyny Ban

It's not even that. He can still hate people. He just can't ACT on it.

I'm not sure someone in that position could actually promise that, and I understand why the board would be uncomfortable with that.

His job entailed using his judgement to guide a company. Whatever he promises, his biases are part of that opinion. If the board doesn't like the sort of judgement he'd exercise in running the company, they're free to boot him. Especially if there was a risk that he might treat homosexual employees unfairly, which both opens the company to lawsuits, and could keep away good talent.

This reminds me of what the CEO of Urban Airship said: "Sure, I visit swingers clubs and sexually assaulted my girlfriend, but that's entirely separate from my work life." When you run a company, your personality and views are entirely relevant to your work life because they affect your judgement, which affects the company.

"My personal and work lives are entirely separate and I won't let me ideas from one affect the other" is totally a bogus excuse. You can't tell me that someone who does not like gay people at home is suddenly going to come to work, turn that entirely off, and then treat gay people like total equals and not discriminate in any fashion. Sorry, I don't buy it.

Comment: Re:Minor detail glossed over in the headline (Score 2) 72

No. The phone should display a notification if an application is side loaded over USB. It shouldn't be possible to install an application without the user's knowledge. Trusting the connection should merely allow the phone and the computer to communicate. It should not allow remote control of the device.

It DOES display a notification when a computer attempts to establish a link, along with requiring user confirmation.

Comment: Future of C++ Standard Library (Score 3, Interesting) 427

by DaphneDiane (#47671471) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

One of the recent concerns raised with C++ compared to other popular languages is the breadth of the standard library. I know that the C++ standard committee was looking at adding a C++ transformed version of Cairo to the standard. And of course their is boost. What else do you see coming to address the perceived API shortcomings?


Murder Suspect Asked Siri Where To Hide a Dead Body 160

Posted by samzenpus
from the worst-laid-plans dept.
An anonymous reader writes A Florida man currently on trial for murder reportedly attempted to use Siri to garner ideas about where to bury the body of his dead roommate. According to police allegations, a University of Florida student named Pedro Bravo murdered his roommate via strangulation in late September of 2012 over a dispute involving Bravo's ex- girlfriend. According to a detective working the case, Bravo subsequently fired up Siri on his iPhone and asked it "I need to hide my roommate."

Comment: timing - which year (Score 2) 72

by SteveWoz (#47628049) Attached to: Expensive Hotels Really Do Have Faster Wi-Fi

I travel a ton and stay in dozens of different hotels every year. Domestically, and in maybe 50% of the foreign cases, the high priced hotels had worse and slower internet up until a couple of years ago. For the last 2 years they have gotten better, on the average. Oh, I was in a 5-star Vegas resort last night that had horrible bandwidth. In the past, my joke was accurate that the difference between a Four Seasons (just an example) and a Super 8 is that at the Super 8 the internet worked and was free. The most important thing to me in a hotel is computer use. The fancy suites in major hotels are often set up for entertaining friends and DON'T even have a computer desk. I ask my wife to book me into Super 8's whenever possible.

Comment: Re:im happy google took this on (Score 1) 46

by maccodemonkey (#47572399) Attached to: Google, Linaro Develop Custom Android Edition For Project Ara

Just think different a little bit. Integrate the secure enclave into the button/sensor module.

I don't think that would work.

I'm pretty sure the secure enclave has authorization hooks to the hardware decryption on the CPU. Even if you moved the hardware encryption/decryption to the thumbprint reader, this brings up another problem with Ara... If you change the CPU or your hardware encryption module, do you loose your data if it was encrypted with the old key?

Comment: Re:People expecting their marketing for free (Score 5, Interesting) 258

by maccodemonkey (#47570725) Attached to: Is the App Store Broken?

Too many people want to get rich by selling apps and expect Apple to pay for the marketing of their apps for free on the App Store.

I don't think this is quite what people are expecting. Rather, the problem is Apple directly prohibits most ways that an app can be promoted. Want to do a demo? No great way to do it in the app store. A trial? Forbidden. Want to offer a download directly from the developer? Nope.

So really what developers are requesting is simple: If Apple wants to directly hand hold the distribution and retail channel of an application, they either need to improve visibility for applications within that retail channel, or give developers more flexibility in how they can market applications. Apple isn't entirely responsible, but because they want developers to be so reliant on their store front, the argument is that Apple needs to actually provide a good store front to make that trade off worth it.

It would be like if you struck a deal with Target where they had full control over how your product was sold and exclusive rights to sell it, and then they stuck it in a dark corner of their store and never sold a single unit.

Comment: Re:Too many apps, too much appcrap (Score 5, Informative) 258

by maccodemonkey (#47570681) Attached to: Is the App Store Broken?

Question for you, as someone who has developed a mobile app:

How much harder is it to optimize a mobile version of the webpage vs writing an app from scratch and getting it approved for App Store release?

Mobile developer here who has done hybrid apps, Android apps, iOS apps, web apps, etc.

It's hard.

Web apps do not get the native scrolling mechanism, so scrolling feels very funky in web apps. Web app developers write their own inertial scrolling mechanisms to try to deal with it, but web apps always feel wrong as a result.

You also don't get access to a lot of native functions. No barcode scanning. No access to the user's preloaded Facebook account (with authorization, of course.)

There is another problem in that, especially on Android, web technologies are just badly supported. It's getting better in more recent versions of Android where Chrome is actually the engine used end to end by everyone, but earlier versions still on Google's old ass version of WebKit blew chunks.

Loading can be a problem as well. Real apps by definition cache a certain amount of code and resources on the device. A web page has to fetch all resources from start to finish. So while a real app has it's loading UI cached on device, and can display it right away when the user taps a link, a web page has to go fetch a UI over the network to display a loading UI for the operation the web app is about to do over the network. Gross.

The other really messy thing is a real app is pretty easily able to figure out what kind of device it's on and render content accordingly. Web apps can kind of guess what type of display/device they are running on, but again, it can be messy. Especially with new things coming like Adaptive UI/multi windowing coming on iOS where your window or screen size may have no real connection to what kind of device you're running on. Web pages at this point basically assuming they're always rendering full screen on mobile, and do their layout computations based on that, but that looks like it will change on future iOS and Android devices.

You also have a problem with native widgets. If I code a real iOS app, if I run it on iOS 6, it looks like iOS 6. If I run it on iOS 7, it looks like iOS 7. I don't have to create new assets, the app automatically ingests the correct look from the widget set built into the OS. With a web page, I get the "joy" of building my widget set from scratch, and trying to make it at least resemble the system UI widgets the user has been trained to use. And better yet, if I make my web app look like an iOS app, I suddenly have a bunch of Android users unhappy my web app looks like an Android app.

Finally, web apps don't offer any way to be embedded as extensions on iOS, or activities on Android. You can kind of fake it with some really really ugly URL handling handshaking, but this is really problem prone.

TL; DR: Mobile web frameworks/browsers are still immature, and don't offer basically mobile specific functionality that's needed to do apps well. It's not a problem of it being hard to do a web app just as good as a native app, it's a problem of it being impossible because the feature sets just aren't there.

Comment: Re:Don't repeat yourself in a multilingual project (Score 1) 170

Online games won't play unless at the latest patch level, for example.

Because the user is using the application during a 2-hour period of having no access to the Internet.

These are mutually exclusive. Online games stop you from doing client side things because they online. An offline application can't know that validation has changed or there is an app update because it's offline. At that point, what do you do, toss out any data the user entered while they were offline?

One easy fix (again): Do your validation on the server end only. Save the data locally, and when the user goes to submit it and it fails, then you throw an error. User doesn't lose any data, and your validation will always be good.

So your suggested workflow is just to let the user enter grossly invalid data for two hours then have the server present pages of error messages once a connection is reestablished.

As I noted above, there isn't really a way around this. Even if I follow your approach, when the client and server versions mismatch because the user was offline they'll get the same pages of errors. An offline user can't get a client update to fix the client side validation because again (drumroll) they're offline.

And, when they come back online, and they get the automatic update, they now have a local user database chock full of invalid data according to local validation. Do you just toss out all that data now because it no longer meets local validation? Or are you intentionally going to punch holes through local validation to grandfather now broken data in?

Boy, I hope your QA team has a large alcohol budget and the world's largest whiteboard for their validation testing matrix.

Hence the growth of Node.

It's true Node is growing, but again, data validation is usually either trivial enough it can be done on the client end in any language, or complicated enough you probably don't want to be doing it on the client end any way.

Comment: Re:Don't repeat yourself in a multilingual project (Score 1) 170

I don't usually see server architectures and client architectures sharing too much in the way of logic code

Input validation logic and any logic related to offline use needs to be the same (or at least provably identically behaving) on server and client.

I don't buy that's a reasonable excuse to force the client and server to be the same language.

First off, I don't buy that a client necessarily needs to do validation at all if the server is doing it. In fact, if you're doing complex validation on the client end, I think that is a Bad Thing (TM). What if your validation is wrong? Well you could just fix your server. But now your client's validation doesn't match, unless you're going to go around and force all your clients to update. Maybe at gunpoint or something. Who knows. But regardless, your client is going to think input is valid, and your server won't. Have you handled that case? What does that UI response look like? Have you unit tested it? Were you silly enough to think if it passed validation on the client end, it MUST pass on the server end? Cause if you did, you're screwed.

So I guess my simplest answer would be, if you need to do complicated validation why the heck are you doing it on the client? Just send it to the server, and then let the server return an error. That way you can fix your validation quickly server side if anything goes wrong, and you don't end up in test case hell in case the server and client disagree. You can also update your validation without touching your client code. And it really reduces your test cases and simplifies your unit testing flow.

For very simple validation (i.e. a credit card is always X number of digits, or a user needs to fill in these fields before they can press the submit button), I could see doing client side work. But that validation is so simple it's not hard to re-code. It's also usually so tied to the UI layer, you're going to be writing a lot of platform specific code any way.

I also still don't buy that being able to share code like that is worth the cost of locking entire ecosystems to a language and stifling language development in favor of a monoculture.

Again, if this is the metric we're working on, I could just take it up one level and say everyone should learn JavaScript instead of Java (and everyone should stop using Java) because you can't run Java in a web browser... Well... I take it back. Maybe it's an argument for the return of Java applets instead. :)

Those who can, do; those who can't, simulate.