9 ms·

>require these applications to be recoded, recompiled and redistributed. Aka "updated". The entire post is basically "ok how about we be really good from now

>require these applications to be recoded, recompiled and redistributed. Aka "updated". The entire post is basically "ok how about we be really good from now on and suffer no consequences, cause it'd be really shitty for us if we had to be penalised". They also posture a lot talking about how big their customers are, almost boasting about how inflexible and slow these big companies are, as if that's somehow Google's or general Internet users' problem.

deleted 10y ago
[deleted]
dude01 10y ago
Yeah, they're using the argument: we're too big to fail.
- walrus01 10y ago
  there are a number of similarities between symantec and some wall street dinosaurs.
snomad 10y ago
Isn't that largely Google's stance with regard to Android? They blame the carriers and point to how slow they are, meanwhile tons of smart phones go without patching, which is no good for the general internet or users'
- AceJohnny2 10y ago
  No, there's a huge difference. The difference here is that the Manufacturers and the Carriers are gatekeepers to the customer's phones. The manufacturer made customizations to Android for their phone. Android isn't a cleanly-separated stack where the manufacturer modifies only a certain part of the stack for their phone but Google could go and update another part without risk of breaking anything (is any software project?) Then, the manufacturers sell the phones to carriers, who usually request extra customizations to (at best) add their logo, or replace default apps with the carrier's own version. This means that any updates to Android likely require updates to this customization. But even if that customization was free (from a development perspective), Carriers still have maintenance/service contracts with the manufacturers such that any manufacturer's updates must go through the carrier's "quality control" procedure. You wouldn't want an update to make the, say, LTE radio misbehave and break the carrier's network would you? Oh no... (and you certainly wouldn't want to "forget" to replace the good default app with the Carrier's crappy one) So there you go, a quick glimpse into the complex economic/contractual obligations that delays or blocks Android updates. FWIW, Google has been working both technically and contractually to untangle this mess, and is one reason for the existence of their "own" line of Nexus and now Pixel phones.
  - pcwalton 10y ago
    Google holds all the cards. They have to sign off, or the phones will lose access to the Play Store and Google services like Maps. Google only needs to play the cards it already holds.
    - mentat 10y ago
      It does play those cards, for instance to mandate full disk encryption. They're moving the standard forward, just not as fast as some may want.
    - sangnoir 10y ago
      The networks have to sign off too, or the phones won't get the OTA updates or be allowed to connect to the network. The SoC / OEMs also have to sign off because they are the ones with access to the driver source code which needs to be updated and recompiled against a new release. If Google plays hardball, these parties can always threaten Google with "We're leaving the OHA; we will be going with Amazon's Android fork and bundle Kindle and Prime apps." I'm sure Bezos will throw in Amazon Maps for free.
- bitmapbrother 10y ago
  I'm constantly amazed by how some people think Google has this magical ability to update an OS that was built by another OEM. That's like asking Debian to update Ubuntu.
  - tyingq 10y ago
    They set the terms for licensing Android, and have used leverage for other things they want or don't want. Edit: Yes, really. https://arstechnica.com/gadgets/2014/02/new-android-oem-licensing-terms-leak-open-comes-with-restrictions/ https://arstechnica.com/gadgets/2014/02/new-android-oem-lice...
    - bitmapbrother 10y ago
      So let's say they put in a rule that said all OEM's must update their devices every month or lose access to Google Play apps and services. What happens when the carriers start delaying or preventing the patches and updates from flowing to the devices? Does Google uphold the rule and revoke their access? Or do they start extending the time by 1 month? Or how about 2 months? Or what about 6 months? What's the point of adding a rule you can't enforce?
      - MichaelGG 10y ago
        Easy, just apply the block to new devices -- the only thing the OEMs care about. They can easily write the contract to that effect.
        bitmapbrother 10y ago
        In the case of the carrier preventing the transmission of patches or OS upgrades you would be punishing the OEM for a problem created by the carrier and out of the control of the OEM. Tangentially, If I was a carrier I would use this to my advantage when negotiating. If you thought carriers were bad now, just wait until they have the power to withhold Google Play services and apps to an OEM's future phones.
- LeifCarrotson 10y ago
  Similar, but the system architecture is different. The CA system is composed of alow-moving companies like Symantec dependent on, or more specifically, beholden to fast-moving companies like Google. In the mobile space, the situation is inverted. Android can move quickly, but they have little to no leverage over the slow-moving carriers.
  - pas 10y ago
    https://news.ycombinator.com/item?id=14208865 https://news.ycombinator.com/item?id=14208865
geofft 10y ago
There's an argument that it's good for end user security to force mobile apps to be updated, even if there weren't a specific reason to distrust Symantec's roots, because who knows when the next Heartbleed will come out.
tyingq 10y ago
>recoded, recompiled and redistributed. I suppose that's true for mobile apps with embedded certs. Bet there's an app store / play store approval logjam for Symantec customers that miss this news, and all come crashing in after the expiry.
- pas 10y ago
  Were Google really nice, they could scan their app store and notify the developers if their app contains embedded shitty certs.
eykanal 10y ago
This comment irritates me. 1) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." Even more so, consider what would happen if Google were to update Chrome to not accept these certs. For internal applications, the IT departments of all these companies—which likely total a few hundreds of thousands of users in total—would simply mandate that Chrome is no longer an acceptable browser. For external applications, companies would have to engage in an enormous PR effort to communicate to customers that their product doesn't work with Chrome. These companies have done nothing wrong, but they're the one being punished, as customers don't know and don't care about cert issues. 2) "Updating" can be an enormous effort. As the blog post states explicitly, there are a lot of use cases where updating a deployed app is very difficult, almost impossible, or cost prohibitive. Again, remember that the person being punished here is not Symantec; you're publishing some poor development company who happened to use Symantec—one of the most popular cert providers on the planet—for an SSL cert. Not good. I'm not taking sides on the issue, because I honestly don't know that much about it. But comments like the above really trivialize the huge impact that something like this will have.
- fosco 10y ago
  >) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." not doing something is allowing the previous lack of security standards to put all of those people in danger. there is a tradeoff with every decision. the entire PKI ecoysystem relies on self management and I think google is making a tough decision, but one that ultimately has already led to better decisions regarding security.
  - mdip 10y ago
    > not doing something is allowing the previous lack of security standards to put all of those people in danger. So glad others are making this point. Not to mention that the CA system is one who's sole feature and only purpose is trust. There is zero security if you can't trust the root. We'd love to live in a world where providing security didn't require a trusted third-party, but that's not the world the internet operates on, today. Transparency is provided by establishing strict guidelines and expectations for CAs. Maintaining this trust is enforcing those guidelines equally among the CAs regardless of size/scope and punishing (preferably severely) any violations. Otherwise the old saying of "rules that are not enforced are just suggestions" comes into play. Because it's a trust-based model, the consequences for violations of that trust have to be strong enough to make a compromised actor willing to refuse government intelligence divisions, corporate criminal actors or even organized crime that has the resources and could stoop to any level of blackmail/bribery to squeeze out a certificate that would allow one to spoof a connection to a high-value target like Amazon, Google, Paypal or Microsoft.
clhodapp 10y ago
For some reason, technical professionals associated with large organizations seem to actively enjoy pretending that basic upkeep is beyond the means of their organization (or has a poor value proposition). I suspect that it comes from a perverse enjoyment of being "pragmatic" in the face of "idealism" but really they're just saying "My org refuses to pay the costs associated with correctly operating the technologies it uses". If you're going to take that attitude, you need to expect that your bluff is going to be called from time to time and you'll have to do some large, unscheduled projects when it happens... that's what being pragmatic actually means: recognizing the positive and negative effects of your options and owning the whole package.
- duxup 10y ago
  I recall a lot of horror stories from mobile telco providers when the US government proposed to users to take their phone number from one carrier to the next. It was just one terrible prediction after another that involved so many risks and complications.... until they had to do it and then it just worked.
  - hackcasual 10y ago
    I worked in telecoms at the time. It was a huge pain in the ass, but in the end it was fixable. The company I worked for actually made a nice chunk providing the HLR (home location register) updates needed to get it to work.
- skuhn 10y ago
  It's especially irksome to me in this case because Symantec (and maybe some of their actual customers) are acting like this is unheard of. Services did just recently have to update their certs to move away from SHA1 intermediate CA cert, didn't they? The current Symantec SHA1 intermediate CA cert is valid between Feb 2010 and Feb 2020, so it seems like there was probably a cert change ~7 years ago too. The horror!
- borplk 10y ago
  Spot on. A variation of this happens about browsers as well. How hard is it to run some version of Chrome or Firefox that is within the last 5 major releases? I don't care how big your organisation is, it's not that hard. Yet they want to off-load the costs to the rest of the world to keep sites compatible with their IE8.
fooey 10y ago
Symantec has got to be facing some very large and very serious lawsuits from those very same giant companies they're try to leverage. This is happening because Symantec was grossly negligent. They're going to be held to account for that. All those giant companies should be firing up their lawyers and starting emergency procedures to change to a different provider. Anyone still using Symantec at this point is absolutely playing with fire.

deleted 10y ago

[deleted]

dude01 10y ago

Yeah, they're using the argument: we're too big to fail.

walrus01 10y ago
there are a number of similarities between symantec and some wall street dinosaurs.

snomad 10y ago

Isn't that largely Google's stance with regard to Android? They blame the carriers and point to how slow they are, meanwhile tons of smart phones go without patching, which is no good for the general internet or users'

AceJohnny2 10y ago
No, there's a huge difference. The difference here is that the Manufacturers and the Carriers are gatekeepers to the customer's phones. The manufacturer made customizations to Android for their phone. Android isn't a cleanly-separated stack where the manufacturer modifies only a certain part of the stack for their phone but Google could go and update another part without risk of breaking anything (is any software project?) Then, the manufacturers sell the phones to carriers, who usually request extra customizations to (at best) add their logo, or replace default apps with the carrier's own version. This means that any updates to Android likely require updates to this customization. But even if that customization was free (from a development perspective), Carriers still have maintenance/service contracts with the manufacturers such that any manufacturer's updates must go through the carrier's "quality control" procedure. You wouldn't want an update to make the, say, LTE radio misbehave and break the carrier's network would you? Oh no... (and you certainly wouldn't want to "forget" to replace the good default app with the Carrier's crappy one) So there you go, a quick glimpse into the complex economic/contractual obligations that delays or blocks Android updates. FWIW, Google has been working both technically and contractually to untangle this mess, and is one reason for the existence of their "own" line of Nexus and now Pixel phones.
- pcwalton 10y ago
  Google holds all the cards. They have to sign off, or the phones will lose access to the Play Store and Google services like Maps. Google only needs to play the cards it already holds.
  - mentat 10y ago
    It does play those cards, for instance to mandate full disk encryption. They're moving the standard forward, just not as fast as some may want.
  - sangnoir 10y ago
    The networks have to sign off too, or the phones won't get the OTA updates or be allowed to connect to the network. The SoC / OEMs also have to sign off because they are the ones with access to the driver source code which needs to be updated and recompiled against a new release. If Google plays hardball, these parties can always threaten Google with "We're leaving the OHA; we will be going with Amazon's Android fork and bundle Kindle and Prime apps." I'm sure Bezos will throw in Amazon Maps for free.
bitmapbrother 10y ago
I'm constantly amazed by how some people think Google has this magical ability to update an OS that was built by another OEM. That's like asking Debian to update Ubuntu.
- tyingq 10y ago
  They set the terms for licensing Android, and have used leverage for other things they want or don't want. Edit: Yes, really. https://arstechnica.com/gadgets/2014/02/new-android-oem-licensing-terms-leak-open-comes-with-restrictions/ https://arstechnica.com/gadgets/2014/02/new-android-oem-lice...
  - bitmapbrother 10y ago
    So let's say they put in a rule that said all OEM's must update their devices every month or lose access to Google Play apps and services. What happens when the carriers start delaying or preventing the patches and updates from flowing to the devices? Does Google uphold the rule and revoke their access? Or do they start extending the time by 1 month? Or how about 2 months? Or what about 6 months? What's the point of adding a rule you can't enforce?
    - MichaelGG 10y ago
      Easy, just apply the block to new devices -- the only thing the OEMs care about. They can easily write the contract to that effect.
      - bitmapbrother 10y ago
        In the case of the carrier preventing the transmission of patches or OS upgrades you would be punishing the OEM for a problem created by the carrier and out of the control of the OEM. Tangentially, If I was a carrier I would use this to my advantage when negotiating. If you thought carriers were bad now, just wait until they have the power to withhold Google Play services and apps to an OEM's future phones.
LeifCarrotson 10y ago
Similar, but the system architecture is different. The CA system is composed of alow-moving companies like Symantec dependent on, or more specifically, beholden to fast-moving companies like Google. In the mobile space, the situation is inverted. Android can move quickly, but they have little to no leverage over the slow-moving carriers.
- pas 10y ago
  https://news.ycombinator.com/item?id=14208865 https://news.ycombinator.com/item?id=14208865

geofft 10y ago

There's an argument that it's good for end user security to force mobile apps to be updated, even if there weren't a specific reason to distrust Symantec's roots, because who knows when the next Heartbleed will come out.

tyingq 10y ago

>recoded, recompiled and redistributed. I suppose that's true for mobile apps with embedded certs. Bet there's an app store / play store approval logjam for Symantec customers that miss this news, and all come crashing in after the expiry.

pas 10y ago
Were Google really nice, they could scan their app store and notify the developers if their app contains embedded shitty certs.

eykanal 10y ago

This comment irritates me. 1) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." Even more so, consider what would happen if Google were to update Chrome to not accept these certs. For internal applications, the IT departments of all these companies—which likely total a few hundreds of thousands of users in total—would simply mandate that Chrome is no longer an acceptable browser. For external applications, companies would have to engage in an enormous PR effort to communicate to customers that their product doesn't work with Chrome. These companies have done nothing wrong, but they're the one being punished, as customers don't know and don't care about cert issues. 2) "Updating" can be an enormous effort. As the blog post states explicitly, there are a lot of use cases where updating a deployed app is very difficult, almost impossible, or cost prohibitive. Again, remember that the person being punished here is not Symantec; you're publishing some poor development company who happened to use Symantec—one of the most popular cert providers on the planet—for an SSL cert. Not good. I'm not taking sides on the issue, because I honestly don't know that much about it. But comments like the above really trivialize the huge impact that something like this will have.

fosco 10y ago
>) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." not doing something is allowing the previous lack of security standards to put all of those people in danger. there is a tradeoff with every decision. the entire PKI ecoysystem relies on self management and I think google is making a tough decision, but one that ultimately has already led to better decisions regarding security.
- mdip 10y ago
  > not doing something is allowing the previous lack of security standards to put all of those people in danger. So glad others are making this point. Not to mention that the CA system is one who's sole feature and only purpose is trust. There is zero security if you can't trust the root. We'd love to live in a world where providing security didn't require a trusted third-party, but that's not the world the internet operates on, today. Transparency is provided by establishing strict guidelines and expectations for CAs. Maintaining this trust is enforcing those guidelines equally among the CAs regardless of size/scope and punishing (preferably severely) any violations. Otherwise the old saying of "rules that are not enforced are just suggestions" comes into play. Because it's a trust-based model, the consequences for violations of that trust have to be strong enough to make a compromised actor willing to refuse government intelligence divisions, corporate criminal actors or even organized crime that has the resources and could stoop to any level of blackmail/bribery to squeeze out a certificate that would allow one to spoof a connection to a high-value target like Amazon, Google, Paypal or Microsoft.

clhodapp 10y ago

For some reason, technical professionals associated with large organizations seem to actively enjoy pretending that basic upkeep is beyond the means of their organization (or has a poor value proposition). I suspect that it comes from a perverse enjoyment of being "pragmatic" in the face of "idealism" but really they're just saying "My org refuses to pay the costs associated with correctly operating the technologies it uses". If you're going to take that attitude, you need to expect that your bluff is going to be called from time to time and you'll have to do some large, unscheduled projects when it happens... that's what being pragmatic actually means: recognizing the positive and negative effects of your options and owning the whole package.

duxup 10y ago
I recall a lot of horror stories from mobile telco providers when the US government proposed to users to take their phone number from one carrier to the next. It was just one terrible prediction after another that involved so many risks and complications.... until they had to do it and then it just worked.
- hackcasual 10y ago
  I worked in telecoms at the time. It was a huge pain in the ass, but in the end it was fixable. The company I worked for actually made a nice chunk providing the HLR (home location register) updates needed to get it to work.
skuhn 10y ago
It's especially irksome to me in this case because Symantec (and maybe some of their actual customers) are acting like this is unheard of. Services did just recently have to update their certs to move away from SHA1 intermediate CA cert, didn't they? The current Symantec SHA1 intermediate CA cert is valid between Feb 2010 and Feb 2020, so it seems like there was probably a cert change ~7 years ago too. The horror!
borplk 10y ago
Spot on. A variation of this happens about browsers as well. How hard is it to run some version of Chrome or Firefox that is within the last 5 major releases? I don't care how big your organisation is, it's not that hard. Yet they want to off-load the costs to the rest of the world to keep sites compatible with their IE8.

fooey 10y ago

Symantec has got to be facing some very large and very serious lawsuits from those very same giant companies they're try to leverage. This is happening because Symantec was grossly negligent. They're going to be held to account for that. All those giant companies should be firing up their lawyers and starting emergency procedures to change to a different provider. Anyone still using Symantec at this point is absolutely playing with fire.