https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-01-18T19:58:53ZOpen Source Mobile CommunicationsOsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=71832018-01-18T19:58:53Zlaforge
<ul><li><strong>Target version</strong> set to <i>Event Operation</i></li></ul> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=71842018-01-19T03:46:48Zipse
<ul></ul><p>Last activity timestamp is critically important for commercial networks who need to recycle SIM cards or phone numbers. This recycling is normally performed based on the inactivity time which requires activity timestamps to be stored. E.g. that's the case for the network we're currently installing in Palau where there is a significant customer churn due to tourists, while numbering capacity is very limited.</p> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=100302018-06-23T18:59:24Zlaforge
<ul><li><strong>Assignee</strong> set to <i>stsp</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=117692018-09-30T11:26:57Zlaforge
<ul></ul> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=126662018-11-22T18:15:21Zstsp
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=128302018-12-04T15:40:30Zstsp
<ul></ul><p>Initial patch proposed here: <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-hlr/+/12121">https://gerrit.osmocom.org/#/c/osmo-hlr/+/12121</a></p> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=128592018-12-07T13:15:30Zstsp
<ul></ul><p>Above patch has been merged.<br />The HLR DB now stores a timestamp of the last location update recoded in the DB.</p>
<p>This timestamp can already be viewed with sqlite:<br /><pre>
sqlite> select imsi,last_lu_seen from subscriber;
901990000000001|2018-12-04 14:17:12
</pre></p>
<p>I will prepare a patch to display the timestamp somewhere in the VTY as well.</p>
<p><a class="user active" href="https://osmocom.org/users/14">ipse</a>, is there anything else that needs to be done in order to meet your use case?</p> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=128602018-12-07T14:53:06Zstsp
<ul></ul><p>See <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-hlr/+/12202">https://gerrit.osmocom.org/#/c/osmo-hlr/+/12202</a> for a patch which adds VTY support.</p> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=128612018-12-07T15:09:00Zstsp
<ul></ul><p>I am wondering if there should be an option to toggle use of this feature.<br />While storing the timestamp will be useful for some users, other users may have privacy concerns.</p>
<p>Should we make this feature optional? If so, I think it should be left disabled by default.<br />The last_lu_seen column would simply not be populated while this feature is disabled; code making<br />use of this column has already been written under the assumption that this column may be empty.</p> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=128652018-12-08T08:04:43Zlaforge
<ul></ul><p>On Fri, Dec 07, 2018 at 03:09:00PM +0000, stsp [REDMINE] wrote:</p>
<blockquote>
<p>I am wondering if there should be an option to toggle use of this feature.<br />[...]<br />Should we make this feature optional?</p>
</blockquote>
<p>No, it is a mandatory feature of a HLR as per 3GPP specs, as far as I know. Also,<br />every time we make something optional, we grow our configuration complexity matrix,<br />and over time some features will likely never be tested with either of the two<br />settings, causing hidden bugs, ...</p> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=128742018-12-10T11:43:07Zstsp
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>On Fri, Dec 07, 2018 at 03:09:00PM +0000, stsp [REDMINE] wrote:</p>
<blockquote>
<p>I am wondering if there should be an option to toggle use of this feature.<br />[...]<br />Should we make this feature optional?</p>
</blockquote>
<p>No, it is a mandatory feature of a HLR as per 3GPP specs, as far as I know. Also,<br />every time we make something optional, we grow our configuration complexity matrix,<br />and over time some features will likely never be tested with either of the two<br />settings, causing hidden bugs, ...</p>
</blockquote>
<p>I understand your concerns about the test matrix. This can quickly become a real burden.</p>
<p>Regarding 3GPP specs: I believe we should not simply defer decisions which potentially impact the privacy of phone network users to a spec. We want to follow the specs specifically because we want to interoperate with devices made by other vendors. We should not be looking to the spec for guidance with respect to ethical questions regarding our implementation. This responsibility is strictly our own.</p>
<p>So I would instead ask the ethical question: Should a permanent record of personal data be created by default in a phone network which runs the Osmocom stack?</p>
<p>I believe the ethical answer is that such data gathering should be opt-in. In which case operators who enable this feature will carry the responsibility of handling the data properly. As a developer I don't want to be responsible for forcing this decision onto every direct or indirect user of an Osmocom HLR.<br />If this feature is opt-out then the operator might even be unaware that such data is being recorded, which leaves the data at risk of being exposed accidentally.</p> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=128782018-12-10T14:06:29Zstsp
<ul></ul><p>This proposed patch disables the feature by default: <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/12228">https://gerrit.osmocom.org/c/osmo-hlr/+/12228</a><br />My main motivation for making this proposal are the privacy concerns outlined above.</p>
<p>I don't think test coverage will become a problem in this particular case.<br />The existing DB unit tests will exercise the timestamp recording code path during 'make check'.</p> OsmoHLR - Feature #2838: HLR doesn't store timestamps e.g. of last subscriber activityhttps://osmocom.org/issues/2838?journal_id=129292018-12-12T16:41:23Zstsp
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul><p>Above patch has been rejected.</p>
<p>I don't see what else can be done for this task. Closing this issue.</p>