Comment Re:How? (Score 1) 248
From the linked document:
If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.
From the linked document:
If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.
Yes, of course it does.
Here, have a look at the protocol:
http://applidium.com/en/news/cracking_siri/
Yes, really.
They abandoned the old Red Hat Linux distro years ago and now they sponsor Fedora, but it's essentially a community project. Red Hat don't provide support; indeed the Fedora project itself only supports ~one year worth of releases.
The vast majority of their efforts clearly go into Red Hat Enterprise Linux.
Yeah, I'm sure they have never have thought of that problem...
Or, if you just read their website, it says that the company gets the customer's CLI as normal.
Yes.
Privacy > Customise Settings > Preview my Profile.
By default it shows what "most people" (i.e. strangers) see. You can then customise it for individual friends on your list.
Newer Android devices, especially tablets, have HDMI output.
There. Now you can copy movies with your non-rooted device.
True, although it costs 40 cents more - plus the cost of an SMS - than buying a regular stamp.
That's not true.
UMTS signalling traffic is actually a big worry too.
Setting up and tearing down radio resource connections all the time has a burden on the network. Mobile applications, with their diverse update patterns (e.g. polling every 30 minutes (email apps), or minute or even few seconds (e.g. IM apps)), can make it difficult for carriers to set up their RRC inactivity timers and various other settings in a way that minimises signalling load on the network.
I can't compile programs written in the Java language to Dalvik?
You need to differentiate between the bytecode and the virtual machine. Anyway, the answer is no, not directly.
The "Java language" or Java bytecode does not run on the Dalkiv virtual machine.
Desktop: The Java language is compiled to Java bytecode and run on the Java virtual machine.
Android: The Java language is compiled to Java bytecode. Using an Android tool, Java bytecode is transformed to Dalvik bytecode, which is then run on the Dalvik virtual machine.
I don't believe the patents in this case have anything to do with the Java language, the Java compiler, the Dalvik translator, or the Dalvik bytecode format.
Sun's patents generally regard the virtual machine technology. Google have implemented an incompatible virtual machine, but of course with similarities to Java.. that's where the problems appear to lie.
Stop foaming at the mouth.
Calm down, dear.
Dalvik is compatible with the Java language.
No it's not. Nor is the JVM compatible with the Java language.
The Java language != Java bytecode != Dalvik bytecode
Dalvik
... was created both to be Java compatible and also under the assumption that Sun was friendly towards open source systems.
Google wrote an entire new, incompatible bytecode language and virtual machine to circumvent licensing any Java components from Sun.
So I doubt Google made any assumptions about the "open source friendliness" of Sun.
Clicking on that link and reading the heading "Gloda is an index, not a data store" would suggest yes.
Android apps don't necessarily have to have a launcher icon (e.g. services, live wallpapers etc.).
Apps can also run automatically at boot time, therefore unless the user somehow discovered that the installed app was malicious and manually uninstalled it, they'd be stuck with this malware forever — assuming Google didn't have this remote-removal functionality.
You get 140 bytes of data per SMS, so with the default GSM 7-bit alphabet that gives you 160 characters.
I can't remember how alternative encodings work, but I seem to recall you get about 70 characters when you text with extended character sets, suggesting that it's some sort of UTF-16 like encoding scheme. That number drops if you start doing message concatenation.
Some of that is true, but XML and the XMPP protocol are highly compressible.
XMPP uses a long-lived TCP connection between servers, so the continued exchange of <message from="foo@wavesandbox.com/Wave" to="bar@example.com/Wave"> will compress to substantially fewer bytes on the wire.
The XMPP Foundation has done a lot of work on this, and continues to work on scalability issues; particularly between federated servers. Indeed, XMPP has reached a point where it's a fairly mature, secure and speedy technology — clearly making it desirable for companies such as Google to use as a foundation for interesting applications such as Wave.
If all else fails, lower your standards.