I've been using android studio for a while now, it's much better than eclipse for editing android resources or referencing them from code. But I haven't changed our build process. I still use ant & adb from the command line for building and testing everything on actual hardware.
POODLE, BREACH, CRIME etc all require the attacker to control some bytes in the ssl stream in order to deduce other bytes that they shouldn't be able to see. POODLE requires the attacker to change the http url & form post body in order to force the alignment of bytes, BREACH and CRIME are gzip length attacks. Both require the attacker to control bytes in a http request in order to guess the contents of other bytes in the request that they wish to know, like a session cookie.
All of these are attacks on HTTP & SSL, not on SSL alone.
It's a protocol problem if a man in the middle can control some bytes in the encrypted stream. The biggest problem with attempts to keep HTTP & SSL secure, is the combination of sensitive application and user supplied data sent over the same stream in both directions.
In Australia we forced the utility companies to buy any solar power you sent to the grid using a separate meter, at a fairly high rate to encourage adoption.
Those higher tariffs are now over. So now we pay around 30-40c kWh (AUD, from memory) for mains, and they only pay about 5c kWh for any solar power you provide. But at least you're better off if you can use that power yourself.
In Australia Telstra maintain the copper line, if there's a problem you log the fault and they fix it within 2 days or they have to pay you. Unless they file a claim for a natural disaster, which can give them an extra couple days to fix it.
At the other end of the copper, your wire may be patched directly into your ISP's equipment. Though in practice I think there are only 2 or 3 companies running the DSLAM's. Smaller ISP's then lease them per line.
Weston has the potential to clean up the UI quirks, I hope they're headed in the right direction. It's way past time we got rid of X11, it's been holding us back for far too long. If they can't do it, I doubt anyone else will bother.
For 20-ish years windows games have been optimised for windows proprietary drivers, and vice versa. That's a lot of invested effort from both sides, that the linux eco-system hasn't had. Frankly I'm surprised at the recent rate of improvements, but linux is still a long way from parity.
So, how long until a VPS provider only allows access via tor, with payments via bitcoin, in order to profit off anyone who wants to build silk road 3.0+?
Just because you can prove that there are *some* programs that can't be proven to halt, doesn't mean that there isn't a subset of programs that *can* be proven to halt.
We can build a language / compiler that rejects all programs that aren't provably correct. It might be difficult to get any useful work done, but it's not impossible.
Something like the rust programming language might be more useful in practice. You can still write completely unsafe code, while being careful to limit the impact of doing so.
Which should highlight if the application you're using can detect the attack or not. If the software you are testing can't detect the MITM, then it's broken. If google could write a better MITM detector, then it should be implemented in the libraries used by every application. Not in a separate tool.
It's quite trivial to adapt them for robot visibility as well (perhaps even incorporating stuff like specialized radio signals).
Or blink a bright IR diode... In the short term the cars will need to learn how humans do it. In the longer term the cars may have their own information channel to augment how we currently do it.
That's not what I'm talking about, and I can and have done that with git using only a single copy of the history of the repository.
I mean that I can make a whole bunch of changes to one file, then tease those changes apart into multiple patches and commit them in the order I want. And if I'm not happy with how things ended up, I can re-order or re-write those patches before I push them upstream. To do the same in a single branch with SVN, I'd have to copy the file, revert it, then manually apply each change one at a time. Hoping that I get everything right the first time.
If I want to run a suite of tests against every patch one at a time, I can script that in a couple of minutes. Or if I notice that something is broken, I can do a binary(-ish) search of everything I've done to find it.
Mastery of git makes almost any workflow possible.
Every time I'm forced to use SVN or TFS, I'm annoyed by how difficult it is to work on multiple patches for multiple features at the same time. With git I can create my own local feature branches, and create as many versions of each patch series as I want, until I'm happy to push them for review. And I never feel like I'm at risk of losing any half finished work I've already completed.
And then there's the launchd / inetd way of launching services that systemd also copies. The service config file can list a set of sockets that the service binds in order to service requests. For example Apache binds to port 80 and 443. So long as all services (including mounting filesystems...) describe *all* of their external interfaces, dependencies no longer matter at all.
The init system can bind all of the sockets that every service needs all at once, and either start the real service the first time the socket is used, or start them all at once. If one service connects to another, the first request will block until the other service is ready to handle it. Then all you have to worry about is the potential for deadlocking, which you'd have to consider anyway.
X the network protocol is bearable, if you are trying to use a Motif style application remotely. But almost nobody is actually doing that any more. Most GUI frameworks were just using X to push graphics buffers.
The async design of the X protocol had a number of weak points. If both the client and the server changed something, this could lead to undefined behaviour. A number of fairly simple use cases resulted in the client needing to wait for multiple network round trips. RDP is a much saner protocol in comparison.
On linux specifically the problems were even bigger. The X server was doing absolutely everything graphics related, including driving the graphics card(s) and input devices directly.
So there's been a big effort to split up the responsibilities of the X server, shifting lots of low level driver "stuff" into the kernel. Building wayland / weston to just do local window compositing. Building a vastly simplified X server that displays windows as a wayland client. And supporting other protocols like RDP for remote desktops.
People have been free to fork it and run with it. Nobody has done that.
Seriously? Forking is practically how git works, and there are lots of people running kernels with patches that aren't in mainline. Practically every distribution does this. And every embedded hardware shop.
Of course these people usually merge new changes from the mainline kernel periodically. So maybe that doesn't count for your definition of "fork".
In this case, the new browser software version will break any server that only supports SSL3.0. When practically every user fails to connect to your server, including your own people, you know you have a problem to fix. Creating some work for web site owners in the interest of their own security.
I'm saying that if you gave the users the option of breaking some of the web, some small percentage of users would do it without understanding the consequences. This creates a situation that is much harder to deal with. If users report the problem to web site owners, or browser vendors, tracing the source of the problem is more difficult.
This is the same reason that Firefox no longer has a prominent option to disable Javascript. Users would disable it, then complain that web sites don't work without telling anyone that they had changed anything. The cost of supporting that option was too high.
Giving the user a browser option that will break compatibility with some web sites, adds more bug / support effort to work out what the user actually did. For most users, giving them an option like this is only going to cause you trouble later.
If you have too many configuration options, nobody will test every permutation to check that they actually work. Since we're talking about web browsers, most of that testing burden would fall on web site developers.
Having an option for a security setting may allow you to quickly inform users on how to mitigate a security issue. But that only works if all of your users track vulnerability news and have the capability to follow those instructions. Not true of most users of web browsers.
So IMHO, the best approach in this case is to make sure your software is secure out of the box. With no nobs that a user can toggle to break anything. Using software update channels to push security fixes when necessary.
Slashdot Mirror
I've been using android studio for a while now, it's much better than eclipse for editing android resources or referencing them from code. But I haven't changed our build process. I still use ant & adb from the command line for building and testing everything on actual hardware.
With semantic versioning, that just means that they haven't broken backwards compatibility. Java 1.8 can still run code compiled for Java 1.0.
POODLE, BREACH, CRIME etc all require the attacker to control some bytes in the ssl stream in order to deduce other bytes that they shouldn't be able to see. POODLE requires the attacker to change the http url & form post body in order to force the alignment of bytes, BREACH and CRIME are gzip length attacks. Both require the attacker to control bytes in a http request in order to guess the contents of other bytes in the request that they wish to know, like a session cookie.
All of these are attacks on HTTP & SSL, not on SSL alone.
It's a protocol problem if a man in the middle can control some bytes in the encrypted stream. The biggest problem with attempts to keep HTTP & SSL secure, is the combination of sensitive application and user supplied data sent over the same stream in both directions.
In Australia we forced the utility companies to buy any solar power you sent to the grid using a separate meter, at a fairly high rate to encourage adoption.
Those higher tariffs are now over. So now we pay around 30-40c kWh (AUD, from memory) for mains, and they only pay about 5c kWh for any solar power you provide. But at least you're better off if you can use that power yourself.
... the other guy just sucks.
True, but the world of programming is full of these people. If your entire team is full of them, you won't even realise it.
In Australia Telstra maintain the copper line, if there's a problem you log the fault and they fix it within 2 days or they have to pay you. Unless they file a claim for a natural disaster, which can give them an extra couple days to fix it.
At the other end of the copper, your wire may be patched directly into your ISP's equipment. Though in practice I think there are only 2 or 3 companies running the DSLAM's. Smaller ISP's then lease them per line.
Weston has the potential to clean up the UI quirks, I hope they're headed in the right direction. It's way past time we got rid of X11, it's been holding us back for far too long. If they can't do it, I doubt anyone else will bother.
For 20-ish years windows games have been optimised for windows proprietary drivers, and vice versa. That's a lot of invested effort from both sides, that the linux eco-system hasn't had. Frankly I'm surprised at the recent rate of improvements, but linux is still a long way from parity.
So, how long until a VPS provider only allows access via tor, with payments via bitcoin, in order to profit off anyone who wants to build silk road 3.0+?
Just because you can prove that there are *some* programs that can't be proven to halt, doesn't mean that there isn't a subset of programs that *can* be proven to halt.
We can build a language / compiler that rejects all programs that aren't provably correct. It might be difficult to get any useful work done, but it's not impossible.
Something like the rust programming language might be more useful in practice. You can still write completely unsafe code, while being careful to limit the impact of doing so.
Which should highlight if the application you're using can detect the attack or not. If the software you are testing can't detect the MITM, then it's broken. If google could write a better MITM detector, then it should be implemented in the libraries used by every application. Not in a separate tool.
This is not a new problem, suddenly created by this clock. It already exists with our standard definition of time.
TAI as a time scale is a weighted average of the time kept by over 200 atomic clocks in over 50 national laboratories worldwide
So now we'll be averaging due to relativity differences as well as precision errors.
... they *don't* want other search engines to use this?
Or are they planning to somehow force search engines to license the process?
It's quite trivial to adapt them for robot visibility as well (perhaps even incorporating stuff like specialized radio signals).
Or blink a bright IR diode... In the short term the cars will need to learn how humans do it. In the longer term the cars may have their own information channel to augment how we currently do it.
That's not what I'm talking about, and I can and have done that with git using only a single copy of the history of the repository.
I mean that I can make a whole bunch of changes to one file, then tease those changes apart into multiple patches and commit them in the order I want. And if I'm not happy with how things ended up, I can re-order or re-write those patches before I push them upstream. To do the same in a single branch with SVN, I'd have to copy the file, revert it, then manually apply each change one at a time. Hoping that I get everything right the first time.
If I want to run a suite of tests against every patch one at a time, I can script that in a couple of minutes. Or if I notice that something is broken, I can do a binary(-ish) search of everything I've done to find it.
Mastery of git makes almost any workflow possible.
Every time I'm forced to use SVN or TFS, I'm annoyed by how difficult it is to work on multiple patches for multiple features at the same time. With git I can create my own local feature branches, and create as many versions of each patch series as I want, until I'm happy to push them for review. And I never feel like I'm at risk of losing any half finished work I've already completed.
And then there's the launchd / inetd way of launching services that systemd also copies. The service config file can list a set of sockets that the service binds in order to service requests. For example Apache binds to port 80 and 443. So long as all services (including mounting filesystems...) describe *all* of their external interfaces, dependencies no longer matter at all.
The init system can bind all of the sockets that every service needs all at once, and either start the real service the first time the socket is used, or start them all at once. If one service connects to another, the first request will block until the other service is ready to handle it. Then all you have to worry about is the potential for deadlocking, which you'd have to consider anyway.
... and less than two arms, legs, eyes, etc.
Better, the article should only be hidden for certain search terms, like someones name, when that person is not otherwise remarkable.
But this doesn't really add anything. You can use facebook for this purpose anyway by posting an "I'm ok, and so is " status message.
X the network protocol is bearable, if you are trying to use a Motif style application remotely. But almost nobody is actually doing that any more. Most GUI frameworks were just using X to push graphics buffers.
The async design of the X protocol had a number of weak points. If both the client and the server changed something, this could lead to undefined behaviour. A number of fairly simple use cases resulted in the client needing to wait for multiple network round trips. RDP is a much saner protocol in comparison.
On linux specifically the problems were even bigger. The X server was doing absolutely everything graphics related, including driving the graphics card(s) and input devices directly.
So there's been a big effort to split up the responsibilities of the X server, shifting lots of low level driver "stuff" into the kernel. Building wayland / weston to just do local window compositing. Building a vastly simplified X server that displays windows as a wayland client. And supporting other protocols like RDP for remote desktops.
People have been free to fork it and run with it. Nobody has done that.
Seriously? Forking is practically how git works, and there are lots of people running kernels with patches that aren't in mainline. Practically every distribution does this. And every embedded hardware shop.
Of course these people usually merge new changes from the mainline kernel periodically. So maybe that doesn't count for your definition of "fork".
In this case, the new browser software version will break any server that only supports SSL3.0. When practically every user fails to connect to your server, including your own people, you know you have a problem to fix. Creating some work for web site owners in the interest of their own security.
I'm saying that if you gave the users the option of breaking some of the web, some small percentage of users would do it without understanding the consequences. This creates a situation that is much harder to deal with. If users report the problem to web site owners, or browser vendors, tracing the source of the problem is more difficult.
This is the same reason that Firefox no longer has a prominent option to disable Javascript. Users would disable it, then complain that web sites don't work without telling anyone that they had changed anything. The cost of supporting that option was too high.
Giving the user a browser option that will break compatibility with some web sites, adds more bug / support effort to work out what the user actually did. For most users, giving them an option like this is only going to cause you trouble later.
If you have too many configuration options, nobody will test every permutation to check that they actually work. Since we're talking about web browsers, most of that testing burden would fall on web site developers.
Having an option for a security setting may allow you to quickly inform users on how to mitigate a security issue. But that only works if all of your users track vulnerability news and have the capability to follow those instructions. Not true of most users of web browsers.
So IMHO, the best approach in this case is to make sure your software is secure out of the box. With no nobs that a user can toggle to break anything. Using software update channels to push security fixes when necessary.
Tick this box to break the internet? Those kinds of options just cause user frustration. Security should not be optional.