(In reply to :Ehsan Akhgari from comment #44) > Right, but first and foremost we need to decide how to do the sanitization. For example if the input context ID is `"foo^bar"`, what should we put in the origin attribute that a) doesn't include the `"^"` character and b) when deserializing can allow us to translate it back to `"^"` in a loss-less manner. The simplest idea I could think of is something like applying a simple encoding like base64, except that it can generate slashes and equal signs, both of which are undesirable here, but perhaps they can be dealt with as a special case? Or perhaps employing another similar encoding could be the way to go. I don't think we need to have a symmetric mapping method. I'm actually inclined to restrict the accepted characters in the string at the API level to avoid complications in Gecko and unexpected ID collisions.
Bug 1501108 Comment 45 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to :Ehsan Akhgari from comment #44) > Right, but first and foremost we need to decide how to do the sanitization. For example if the input context ID is `"foo^bar"`, what should we put in the origin attribute that a) doesn't include the `"^"` character and b) when deserializing can allow us to translate it back to `"^"` in a loss-less manner. The simplest idea I could think of is something like applying a simple encoding like base64, except that it can generate slashes and equal signs, both of which are undesirable here, but perhaps they can be dealt with as a special case? Or perhaps employing another similar encoding could be the way to go. I don't think we need to have a symmetric mapping method. I'm actually inclined to restrict the accepted characters in the string at the API level to avoid complications in Gecko and unexpected ID collisions. Alternatively, (still considering we don't need to reverse the mapping) we could just use some scheme a la `gv-ctx-SHA1(<user-id>)`.
(In reply to :Ehsan Akhgari from comment #44) > Right, but first and foremost we need to decide how to do the sanitization. For example if the input context ID is `"foo^bar"`, what should we put in the origin attribute that a) doesn't include the `"^"` character and b) when deserializing can allow us to translate it back to `"^"` in a loss-less manner. The simplest idea I could think of is something like applying a simple encoding like base64, except that it can generate slashes and equal signs, both of which are undesirable here, but perhaps they can be dealt with as a special case? Or perhaps employing another similar encoding could be the way to go. I don't think we need to have a symmetric mapping method. I'm actually inclined to restrict the accepted characters in the string at the API level to avoid complications in Gecko and unexpected ID collisions. Alternatively, (still considering we don't need to reverse the mapping) we could just use some scheme a la `gv-ctx-SHA1(<user-id>)` at any level in the process.
(In reply to :Ehsan Akhgari from comment #44) > Right, but first and foremost we need to decide how to do the sanitization. For example if the input context ID is `"foo^bar"`, what should we put in the origin attribute that a) doesn't include the `"^"` character and b) when deserializing can allow us to translate it back to `"^"` in a loss-less manner. The simplest idea I could think of is something like applying a simple encoding like base64, except that it can generate slashes and equal signs, both of which are undesirable here, but perhaps they can be dealt with as a special case? Or perhaps employing another similar encoding could be the way to go. I don't think we need to have a symmetric mapping method. I'm actually inclined to restrict the accepted characters in the string at the API level to avoid complications in Gecko and unexpected ID collisions. Alternatively, (still considering we don't need to reverse the mapping) we could just use some scheme a la `gv-ctx-SHA1(<user-id>)` at any level in the process. I think I would prefer this solution since it's the simplest way to ensure a safe filename and avoid collisions.
(In reply to :Ehsan Akhgari from comment #44) > Right, but first and foremost we need to decide how to do the sanitization. For example if the input context ID is `"foo^bar"`, what should we put in the origin attribute that a) doesn't include the `"^"` character and b) when deserializing can allow us to translate it back to `"^"` in a loss-less manner. The simplest idea I could think of is something like applying a simple encoding like base64, except that it can generate slashes and equal signs, both of which are undesirable here, but perhaps they can be dealt with as a special case? Or perhaps employing another similar encoding could be the way to go. I don't think we need to have a symmetric mapping method. I'm actually inclined to restrict the accepted characters in the string at the API level to avoid complications in Gecko and unexpected ID collisions. Alternatively, (still considering we don't need to reverse the mapping) we could just use some scheme a la `gv-ctx-SHA1(<user-id>)` at any level in the process. I think I would prefer this solution since it's the simplest way to ensure a safe string and avoid collisions.
(In reply to :Ehsan Akhgari from comment #44) > Right, but first and foremost we need to decide how to do the sanitization. For example if the input context ID is `"foo^bar"`, what should we put in the origin attribute that a) doesn't include the `"^"` character and b) when deserializing can allow us to translate it back to `"^"` in a loss-less manner. The simplest idea I could think of is something like applying a simple encoding like base64, except that it can generate slashes and equal signs, both of which are undesirable here, but perhaps they can be dealt with as a special case? Or perhaps employing another similar encoding could be the way to go. I don't think we need to have a symmetric mapping method. I'm actually inclined to restrict the accepted characters in the string at the API level to avoid complications in Gecko and unexpected ID collisions. Alternatively, (still considering we don't need to reverse the mapping) we could just use some scheme a la `gv-ctx-SHA1(<user-id>)` at the input level in GV. I think I would prefer this solution since it's the simplest way to ensure a safe string and avoid collisions.
(In reply to :Ehsan Akhgari from comment #44) > Right, but first and foremost we need to decide how to do the sanitization. For example if the input context ID is `"foo^bar"`, what should we put in the origin attribute that a) doesn't include the `"^"` character and b) when deserializing can allow us to translate it back to `"^"` in a loss-less manner. The simplest idea I could think of is something like applying a simple encoding like base64, except that it can generate slashes and equal signs, both of which are undesirable here, but perhaps they can be dealt with as a special case? Or perhaps employing another similar encoding could be the way to go. I don't think we need to have a symmetric mapping method. I'm actually inclined to restrict the accepted characters in the string at the API level to avoid complications in Gecko and unexpected ID collisions. Alternatively, (still considering we don't need to reverse the mapping) we could just use some scheme a la `gv-ctx-SHA1(<user-id>)` at the input level in GV. I think I would prefer this solution since it's the simplest way to ensure a safe string and avoid collisions without restricting the user string options.
(In reply to :Ehsan Akhgari from comment #44) > Right, but first and foremost we need to decide how to do the sanitization. For example if the input context ID is `"foo^bar"`, what should we put in the origin attribute that a) doesn't include the `"^"` character and b) when deserializing can allow us to translate it back to `"^"` in a loss-less manner. The simplest idea I could think of is something like applying a simple encoding like base64, except that it can generate slashes and equal signs, both of which are undesirable here, but perhaps they can be dealt with as a special case? Or perhaps employing another similar encoding could be the way to go. I don't think we need to have a symmetric mapping method. I'm actually inclined to restrict the accepted characters in the string at the API level to avoid complications in Gecko and unexpected ID collisions. Alternatively, (still considering we don't need to reverse the mapping) we could just use some scheme a la `gv-ctx-SHA1(<user-string>)` at the input level in GV. I think I would prefer this solution since it's the simplest way to ensure a safe string and avoid collisions without restricting the user string options.