3 ms·

I dunno. It's also pretty weird to borrow 95% of a spec, miss out on a half dozen important security features, not acknowledge the relationship between your wo

I dunno. It's also pretty weird to borrow 95% of a spec, miss out on a half dozen important security features, not acknowledge the relationship between your work and the spec, and not contribute back to the community that funded the spec.

toyg 7y ago
It's very "pirate of Silicon Valley", i.e. very old-school Apple: "so sue me". Regardless, the right answer is to engage privately first, to see why they missed that 5% and if there is any way to find agreement, not to go pedal-to-the-metal with public shaming.
- CydeWeys 7y ago
  As someone who's tried to contact Apple before, posting publicly is about the only thing that would ever work. Good luck getting in contact with anyone there who'll speak to you. They're worse than most other companies, and most other companies are already quite bad.
  - toyg 7y ago
    In that case, a simple line saying "we tried to contact you to no avail" would have avoided looking rude.
    - CydeWeys 7y ago
      I just don't get why you're so stuck on this one point on etiquette. To me, saying "We tried to contact you to no avail" is ruder than omitting the line.
      - toyg 7y ago
        An open letter is obviously not a communication to the recipient, but to the public. It's a rhetorical exercise you use so that the public will put pressure on the counterpart; hence it has to win the public to your side. In order to have the public on your side, you have to be as clear as possible about your motives and your methods - otherwise you'll get people questioning them, which is exactly what you can see in this thread. That's a fail. A simple paragraph saying "we tried to engage with you but could not because X" would have made the writer more sympathetic to the public, imho, and avoided most of the challenges you see here. If that looks rude to the counterpart, it doesn't really matter; everyone knows any politeness is fundamentally insincere anyway, because if one had not wanted to ruffle their feathers, one wouldn't have published anything in the first place.
  - seandougall 7y ago
    For an individual, yeah. Apple belongs to a number of standards bodies and consortia, though; when they deviate from an existing standard, they usually do do more deliberately than this letter implies.
    - CydeWeys 7y ago
      I was not trying to get in contact with them in my capacity as an individual.
tptacek 7y ago
The big tech companies all tend to have excellent security teams, each of which have particular strengths. Google's obviously includes low-level vulnerability research and browser security. Apple's includes hardware security and cryptography. I would be surprised if they "missed out on a half dozen important security features".
- will4274 7y ago
  The article describes the missing security features. Did you read it? The lack of nonce makes replay protection impossible. The lack of c_hash opens up vulnerabilities in connect flows where the service incorrectly assumes the two tokens refer refer to the same user. Returning the id token on the query leaks it in the Referer header.
  - tptacek 7y ago
    I don't know enough about Sign In With Apple to map its security features to those of OpenID; I'm guessing you don't either.
    - jogux 7y ago
      Neither of you need to; the article contains a link to https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md https://bitbucket.org/openid/connect/src/default/How-Sign-in... where a bunch of experts have analysed the current (beta) signin with Apple against the spec. In particular it's "signing with apple on the web" that they've analysed, which is open for anyone to analyze using the developer tools in a browser etc. Apple are actually following the OpenID standard, that's why the list is differences is concise and to the point. Several of the pieces that are missing/different are items that were added to OpenID to prevent attacks that have been used against pure OAuth 2. Many of the potential attacks relate to fooling the third party sites as to what happened, so it is difficult/impossible to mitigate them with magic on Apple's side. (disclaimer: I'd listed as a contributor on above doc. I'm writing here in a purely personal capacity.)
blondin 7y ago
> It's pretty weird to borrow 95% of a spec, miss out on a half dozen important security features, not acknowledge the relationship between your work and the spec, and not contribute back to the community that funded the spec. they all been doing this all the time

toyg 7y ago

It's very "pirate of Silicon Valley", i.e. very old-school Apple: "so sue me". Regardless, the right answer is to engage privately first, to see why they missed that 5% and if there is any way to find agreement, not to go pedal-to-the-metal with public shaming.

CydeWeys 7y ago
As someone who's tried to contact Apple before, posting publicly is about the only thing that would ever work. Good luck getting in contact with anyone there who'll speak to you. They're worse than most other companies, and most other companies are already quite bad.
- toyg 7y ago
  In that case, a simple line saying "we tried to contact you to no avail" would have avoided looking rude.
  - CydeWeys 7y ago
    I just don't get why you're so stuck on this one point on etiquette. To me, saying "We tried to contact you to no avail" is ruder than omitting the line.
    - toyg 7y ago
      An open letter is obviously not a communication to the recipient, but to the public. It's a rhetorical exercise you use so that the public will put pressure on the counterpart; hence it has to win the public to your side. In order to have the public on your side, you have to be as clear as possible about your motives and your methods - otherwise you'll get people questioning them, which is exactly what you can see in this thread. That's a fail. A simple paragraph saying "we tried to engage with you but could not because X" would have made the writer more sympathetic to the public, imho, and avoided most of the challenges you see here. If that looks rude to the counterpart, it doesn't really matter; everyone knows any politeness is fundamentally insincere anyway, because if one had not wanted to ruffle their feathers, one wouldn't have published anything in the first place.
- seandougall 7y ago
  For an individual, yeah. Apple belongs to a number of standards bodies and consortia, though; when they deviate from an existing standard, they usually do do more deliberately than this letter implies.
  - CydeWeys 7y ago
    I was not trying to get in contact with them in my capacity as an individual.

tptacek 7y ago

The big tech companies all tend to have excellent security teams, each of which have particular strengths. Google's obviously includes low-level vulnerability research and browser security. Apple's includes hardware security and cryptography. I would be surprised if they "missed out on a half dozen important security features".

will4274 7y ago
The article describes the missing security features. Did you read it? The lack of nonce makes replay protection impossible. The lack of c_hash opens up vulnerabilities in connect flows where the service incorrectly assumes the two tokens refer refer to the same user. Returning the id token on the query leaks it in the Referer header.
- tptacek 7y ago
  I don't know enough about Sign In With Apple to map its security features to those of OpenID; I'm guessing you don't either.
  - jogux 7y ago
    Neither of you need to; the article contains a link to https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md https://bitbucket.org/openid/connect/src/default/How-Sign-in... where a bunch of experts have analysed the current (beta) signin with Apple against the spec. In particular it's "signing with apple on the web" that they've analysed, which is open for anyone to analyze using the developer tools in a browser etc. Apple are actually following the OpenID standard, that's why the list is differences is concise and to the point. Several of the pieces that are missing/different are items that were added to OpenID to prevent attacks that have been used against pure OAuth 2. Many of the potential attacks relate to fooling the third party sites as to what happened, so it is difficult/impossible to mitigate them with magic on Apple's side. (disclaimer: I'd listed as a contributor on above doc. I'm writing here in a purely personal capacity.)

blondin 7y ago

> It's pretty weird to borrow 95% of a spec, miss out on a half dozen important security features, not acknowledge the relationship between your work and the spec, and not contribute back to the community that funded the spec. they all been doing this all the time