Douglas Crockford ('inventor' of JSON) is considered an authority on JavaScript and it's history said:
"ECMA.... created a committee and started working on the standard [ECMAScript==JavaScript] Microsoft joined the committee and dominated the work of the committee. The most important contribution of Microsoft was all of the bugs, defects and blunders that they so carefully documentated were to remain in the standard."
Well that should be pretty easy to predict: Adobe will drop Flash, why do you think they are building/releasing HTML5 IDE/authoring applications ? They even created a Flash-to-HTML5-conversion tool.
Apple does not support Flash on their iOS-devices and Microsoft won't support any plugins for using with their touch-optimised interface Metro.
"Software Development Engineers - SPDY SPDY is an open source network transport protocol which we have leveraged in the design of Amazon Silk. In this role, you will have end-to-end ownership of our use of SPDY. You will be expected to have strong familiarity with the protocol and to use that knowledge to come up with innovative ways to improve the customer experience. We're looking for strong team players who thrive in a startup-like environment where flexibility is essential and delivering rock solid, customer focused solutions is paramount."
Here are some facts about DNSSEC and handling of certificates with DNSSEC: 1. DNSSEC is used to sign the answers from the authoritive nameservers of a domain 2. This means answered can only be dropped, not faked. Obviously this only works if the the receiver verifies it. 3. 'above' the top-level-domains (com, org, edu, country tlds: uk, de) is the root, which has it's own nameservers 4. the procedure for signing the root and the procedures to get something changed at the root are long and have many checks, I don't expect anymore to be able to change or hack it. 5. the public key (or hash of that) of the root is the only thing that is needed to verify anything which is DNSSEC-signed if it is part of the normal DNS-hierarchy. 6. Each TLD has one organisation, the registry, who deals with the content of the TLD, the TLD points to the individual domains within the TLD 7. When a domain is registered by their owner they do this at a 'registrar', they register it for them at the registry 8. If the TLD supports DNSSEC, they will sign their own domain, the TLD, first and send a 'DS-record' to the root 9. the DS-record is a hash of the public key of the domain 10. sometimes the hosting-provider is also the registrar or they outsource that part to one. 11. When a domain-owner wants their domain DNSSEC-signed they will need to sign their domain. And they will need to update their keys every few weeks or months just to be save. 12. They also need to send a DS-record to their parent, the TLD. 13. All parts of this process can be handled by the domain owner or outsourced to for example a hosting-provider: creating the content of the domain, setting up and maintaining the nameservers, hosting the nameservers, signing the domain, being a registrar. 14. so when a domain-owner handles their own signing, they usually are not the registrar. So they have to send the DS-record to the registrar which sends it to the register (TLD-operater). 15. This might be automated with a XML-protocol over HTTPS like: EPP or possible send by email with PGP for example. 16. when a TLD is signed and a DS-record for a domain is put in DNS, then this tells clients that a domain has to be signed with a suitable key. 17. when a TLD is signed and no DS-record for a domain is put in DNS (if something does not exist, this is also signed), then this tells clients that a domain is not signed. 18. DNSSEC is just signing, it is not encrypted. 19. There are a few protocols that can be used to add a signed record in DNS with the (hash of) a certificate which could tell a browser or other application which certificate to expect. The protocol with the most traction is probably DANE. 20. some systems use offline-signing for DNSSEC, which means every time a change in DNS is made, the whole domain has to re-signed on a seperate system 21. some systems use online-signing for DNSSEC, which means the key for signing is stored on the nameserver
So where are some of the problems ? - if a TLD is stationed in a country where the government has access to the TLD, they can point it where they like. Maybe doing a man-in-the-middle attack of some sorts if they only redirect the traffic. If a domain is signed, it will not be possible/easy to redirect only part of that traffic with the use of DNS. - if a hosting-provider gets hacked, all the domains can be changed or transfered. - if a hosting-account gets hacked, the domains of a domain owner could be changed or transfered. - handling DS-records properly is obviously very important - when online signing is used, if a nameserver is hacked, the keys might stolen as well - a lot of systems don't yet understand DNSSEC, so applications can't use them yet. They are for example: operating systems, DNS-serversoftware, firewalls, DSL-routers with DNS-relay functions. - DNSSEC-signed answers are a lot bigger, some systems don't understand large(r) answers either - a client can ask a 'caching DNS-server' (like at the ISP) to verify the DNS-answer, but obvi
Hmm... well, if you enable javascript just on the sites you frequently visit will not make you save for attacks with BEAST.
With BEAST the attacker is between you and all (most/enough) sites you visit. If you have any site you allow JavaScript on (AND which only uses HTTP) the attacker can inject JavaScript on that page as well. Well, than again. Just disable Java-applets, seems the current attack still depends on Java-applets.
If you want to check on TLS/1.1 TLS/1.2 you will need to enable it in your browser AND check the website you linked, not OR. Both need to have it enabled.
What DNSSEC can bring is, is a way for the domain-owner to communicate which certificate and thus which CA is used on his/her website for HTTPS (SSL/TLS).
This is definitely very useful, but don't expect DNSSEC to be deployed everywhere any day soon. Many DNS-relays in DSL-routers, corporate firewalls and so on are just braindead.:-(
Here is what I found on the Tor-site: "For efficiency, the Tor software uses the same circuit for connections that happen within the same ten minutes or so. Later requests are given a new circuit, to keep people from linking your earlier actions to the new ones."
Slashdot Mirror
Douglas Crockford ('inventor' of JSON) is considered an authority on JavaScript and it's history said:
"ECMA.... created a committee and started working on the standard [ECMAScript==JavaScript] Microsoft joined the committee and dominated the work of the committee. The most important contribution of Microsoft was all of the bugs, defects and blunders that they so carefully documentated were to remain in the standard."
http://www.livestream.com/etsy/video?clipId=pla_1463e546-47ed-4a93-b59a-bd52b236e8b8 13:00+
And obviously after the vendor lock-in of the business users of Microsoft to ActiveX/IE6 they did nothing for many years, which made matters worse.
Because Microsoft wants apps to do 'even more fancy things' then should be allowed from a normal site ?
I don't know, maybe I interpreted their presentations wrong.
I've not installed the Windows 8 developer releases.
I don't know if you ever checked.
But most code is actually just minified or something like packer is used which can also be undone easily and thus no variables are lost.
Then you misunderstood what Microsoft is doing.
IE10 won't allow websites to do anything scary.
'apps' running 'in' the Metro interface will have lots of extra capabilities and the apps are installed from the Windows Store.
I think the Metro interface might be powered by IE10, but I'm not sure.
Minified JavaScript ? That isn't too complicated. Just have a look here:
http://jsbeautifier.org/ ?
Well that should be pretty easy to predict: Adobe will drop Flash, why do you think they are building/releasing HTML5 IDE/authoring applications ? They even created a Flash-to-HTML5-conversion tool.
Apple does not support Flash on their iOS-devices and Microsoft won't support any plugins for using with their touch-optimised interface Metro.
"Remember JavaScript was originally called "ActionScript", and Netscape licensed the name from Sun "
Actually, you mean LiveScript. LiveScript is the original name. ActionScript is the JavaScript derived language used by Flash.
1. Funny thing is, Windows 8 will add "HTML5" as a first class citizen. Next to C++ and .NET
Actually Microsoft was sooo fine with JavaScript that Microsofts adoption of it blocked the changes to make JavaScript a proper language.
Ericsson had done so in 2010:
https://labs.ericsson.com/developer-community/blog/beyond-html5-implementing-device-and-stream-management-webkit
The "Device API" however has been replaced with "Video conferencing and peer-to-peer communication":
http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html#introduction-10
I'm not aware of anyone that supports it currently.
Which allows you to pop up a message saying "would you like to increase it ?"
Bit by bit the Firefox developers are fixing all the causes of that.
It wasn't the brighest idea to do rapid releases before they addressed all of that.
Maybe the underestimated the impact ?
But to keep doing that probably makes it worse.
"Funny" thing is, Firefox has supported the same type of extensions as Chrome has (non-platform specific/non-binary) for as long as Chrome has.
Firefox developers recently made it even easier for extension developers to move to the new type.
Of all the binary-extensions that break, more than 75% are not on addons.mozilla.org.
Yes, it is somewhat bad. But it might not be as bad as some people say it is.
I don't know how to classify the old Windows Phone, I just know one thing the browser definitely was not smart.
The use of SPDY does seem likely:
"Software Development Engineers - SPDY
SPDY is an open source network transport protocol which we have leveraged in the design of Amazon Silk. In this role, you will have end-to-end ownership of our use of SPDY. You will be expected to have strong familiarity with the protocol and to use that knowledge to come up with innovative ways to improve the customer experience. We're looking for strong team players who thrive in a startup-like environment where flexibility is essential and delivering rock solid, customer focused solutions is paramount."
http://aws.amazon.com/amazonsilk-jobs/
Those devices which existed before iOS/Android/WebOS/whatever are now sometimes called 'feature phones'.
Here are some facts about DNSSEC and handling of certificates with DNSSEC:
1. DNSSEC is used to sign the answers from the authoritive nameservers of a domain
2. This means answered can only be dropped, not faked. Obviously this only works if the the receiver verifies it.
3. 'above' the top-level-domains (com, org, edu, country tlds: uk, de) is the root, which has it's own nameservers
4. the procedure for signing the root and the procedures to get something changed at the root are long and have many checks, I don't expect anymore to be able to change or hack it.
5. the public key (or hash of that) of the root is the only thing that is needed to verify anything which is DNSSEC-signed if it is part of the normal DNS-hierarchy.
6. Each TLD has one organisation, the registry, who deals with the content of the TLD, the TLD points to the individual domains within the TLD
7. When a domain is registered by their owner they do this at a 'registrar', they register it for them at the registry
8. If the TLD supports DNSSEC, they will sign their own domain, the TLD, first and send a 'DS-record' to the root
9. the DS-record is a hash of the public key of the domain
10. sometimes the hosting-provider is also the registrar or they outsource that part to one.
11. When a domain-owner wants their domain DNSSEC-signed they will need to sign their domain. And they will need to update their keys every few weeks or months just to be save.
12. They also need to send a DS-record to their parent, the TLD.
13. All parts of this process can be handled by the domain owner or outsourced to for example a hosting-provider: creating the content of the domain, setting up and maintaining the nameservers, hosting the nameservers, signing the domain, being a registrar.
14. so when a domain-owner handles their own signing, they usually are not the registrar. So they have to send the DS-record to the registrar which sends it to the register (TLD-operater).
15. This might be automated with a XML-protocol over HTTPS like: EPP or possible send by email with PGP for example.
16. when a TLD is signed and a DS-record for a domain is put in DNS, then this tells clients that a domain has to be signed with a suitable key.
17. when a TLD is signed and no DS-record for a domain is put in DNS (if something does not exist, this is also signed), then this tells clients that a domain is not signed.
18. DNSSEC is just signing, it is not encrypted.
19. There are a few protocols that can be used to add a signed record in DNS with the (hash of) a certificate which could tell a browser or other application which certificate to expect. The protocol with the most traction is probably DANE.
20. some systems use offline-signing for DNSSEC, which means every time a change in DNS is made, the whole domain has to re-signed on a seperate system
21. some systems use online-signing for DNSSEC, which means the key for signing is stored on the nameserver
So where are some of the problems ?
- if a TLD is stationed in a country where the government has access to the TLD, they can point it where they like. Maybe doing a man-in-the-middle attack of some sorts if they only redirect the traffic. If a domain is signed, it will not be possible/easy to redirect only part of that traffic with the use of DNS.
- if a hosting-provider gets hacked, all the domains can be changed or transfered.
- if a hosting-account gets hacked, the domains of a domain owner could be changed or transfered.
- handling DS-records properly is obviously very important
- when online signing is used, if a nameserver is hacked, the keys might stolen as well
- a lot of systems don't yet understand DNSSEC, so applications can't use them yet. They are for example: operating systems, DNS-serversoftware, firewalls, DSL-routers with DNS-relay functions.
- DNSSEC-signed answers are a lot bigger, some systems don't understand large(r) answers either
- a client can ask a 'caching DNS-server' (like at the ISP) to verify the DNS-answer, but obvi
Maybe, I did misread his comment this time round.
I guess I expected APK to mention how to enable TLS/1.1 and TLS/1.2, because they are not enabled by default.
Yes, I had read that article before.
Should I respond...?
Hmm... well, if you enable javascript just on the sites you frequently visit will not make you save for attacks with BEAST.
With BEAST the attacker is between you and all (most/enough) sites you visit. If you have any site you allow JavaScript on (AND which only uses HTTP) the attacker can inject JavaScript on that page as well. Well, than again. Just disable Java-applets, seems the current attack still depends on Java-applets.
If you want to check on TLS/1.1 TLS/1.2 you will need to enable it in your browser AND check the website you linked, not OR. Both need to have it enabled.
Be sure not to choose to remember the choice permanently by adding the certificate (or CA !) to your certificate store.
Let me guess the person above has disabled the GeoTrust CA.
Why not combine it ?
You can have a convergence.io notary which does not just check HTTPS-sites, but also checks DNSSEC.
As I posted above, I think a Tor exit node might be a good place for an attacker.
It might be slightly harder to pulll off, you'll need a bit of luck.
What DNSSEC can bring is, is a way for the domain-owner to communicate which certificate and thus which CA is used on his/her website for HTTPS (SSL/TLS).
This is definitely very useful, but don't expect DNSSEC to be deployed everywhere any day soon. Many DNS-relays in DSL-routers, corporate firewalls and so on are just braindead. :-(
Here is what I found on the Tor-site:
"For efficiency, the Tor software uses the same circuit for connections that happen within the same ten minutes or so. Later requests are given a new circuit, to keep people from linking your earlier actions to the new ones."
https://www.torproject.org/about/overview
That doesn't sound all that great.