• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

[rs] Remote Scheduling Portal

Status
Not open for further replies.
@prpr

As far as I am concerned, any information no matter how insignificant, that is unique to me or anything I own, is worth preserving. I regard a MAC address to be one of those things. It may be completely OTT, I don't care.

My reply to the OP was in good faith, but was worded in such a way as to make him think before publishing such information again...'Is it wise to....?

Quite frankly, prpr, I couldn't give a rats ass what you think. You have a great knack of getting under someone's skin. Does it come naturally? Or do you have to practice?

I suppose you shoe size will match that of you head, rather large.

@the moderator

Feel free to delete/edit this post. I just had to let my feelings known and my spleen is duly vented!



Sent from my iPad using Tapatalk HD
 
I think if there is a security risk, we should be told what that risk is rather than take it on faith that there is one. prpr tends to be very irritating in the way he expresses things (down to youth I expect, wouldn't we all like some of that?), but he raises a valid point and for once I am on his side (if I take what he says rather than the way he says it). I have expressed the same previously: in what way could public knowledge of your HDR-FOX's MAC address (or even its IP address on the local network) be exploitable?

When I was five I might have accepted it when somebody told me "when you die you go to heaven"*. Now I say "extraordinary claims require extraordinary evidence". Somebody might make an individual decision not to reveal their MAC address or whatever, but that doesn't mean everyone else has to follow suit. Everyone else might decide to follow suit if there is an arguable chain of events that could potentially lead from its revelation to some undesirable situation. At least when I am negative about AR I have evidence to support my position.

* In my childhood we had hymns at school, went to church on Sunday, and next door were into the Billy Graham stuff and I even went along with that for a bit... but did I ever actually believe it as fact? I don't think so, it was just a social thing.
 
Old device deleted.

I haven't received any Auto Scheduler emails for any existing searches though. (e.g. Match of the Day). I have tried "Reset Matched Events" too.

I was hoping I would get all these existing searches automatically re-scheduled on my new box.
 
As I say, I might be OTT regarding security. You are probably right, however, I still stand by what I said. It's a unique piece of information and as such I will regard it as I would my bank account number etc. The perceived risk may be just that, perceived.

I was only offering advice in good faith and stand by what I said.
 
I'm not arguing about what you said, I am commenting on the flurry of panic that resulted from it.

Chicken Licken: "The sky is falling"
 
Old device deleted.

I haven't received any Auto Scheduler emails for any existing searches though. (e.g. Match of the Day). I have tried "Reset Matched Events" too.

I was hoping I would get all these existing searches automatically re-scheduled on my new box.

Not sure if its related, but getting the following repeated in the rs.log

Runtime Error: /mod/webif/lib/system.class:73: Collected errors:
* opkg_conf_load: Could not lock /tmp/opkg.lock: Resource temporarily unavailable.
in procedure 'require' called at file "/mod/sbin/rs_process", line 5
at file "/mod/var/mongoose/lib/setup", line 7
in procedure 'system' called at file "/mod/webif/lib/safe_delete", line 7
at file "/mod/webif/lib/system.class", line 73
 
I deleted "Match Of The Day" auto schedule entry and recreated it last night. Got an auto schedule email for Match of the Day this morning. Maybe that's what I need to do for all entries for which RS has previously scheduled (on my old box). I'm happy to do this if that's what's required.
 
I have removed all of the history entries for your auto scheduling entries.. see if that helps.
 
Not sure if its related, but getting the following repeated in the rs.log
It isn't related - rs is just checking to see whether undelete is installed and can't while there is another package management operation in progress.. it should sleep and retry though so I will fix that.
 
in what way could public knowledge of your HDR-FOX's MAC address (or even its IP address on the local network) be exploitable?

The MAC address is used as a unique identifier for the RS service and it's also passed to Humax whenever you use their portal (although the system ID and serial number is also sent IIRC).

Posting the MAC address could enable third parties to make some connections and I have never posted mine. Then again, I'm the type of person who would never use GoogTwitBookTube+ either..

I wouldn't be concerned about publishing the internal IP address details. It still isn't considered best practice in security circles since it helps a potential attacker to build up a picture of the network. I once did a set of Internet-based security tests against a large Internet Cafe chain (with their permission) and finding details of their internal IP addressing scheme on public forums was key input to an exploit that took their whole system offline.
 
As far as I am concerned, any information no matter how insignificant, that is unique to me or anything I own, is worth preserving. I regard a MAC address to be one of those things.
When you write someone a cheque, you give them your name, signature, sort code and account number.
If you buy something online, you give them your card number, expiry date and "security" code.
When you call someone, you probably give them your phone number.
Similarly when you send a letter.

Does any of this worry you?

God, you've identified yourself as being in South Manchester, UK. I used to live there. I could come and find you and do unspeakable things with your MAC address.....

Oh dear, now I've given away info. about myself. How terrible. What am I going to do?
I guess I could edit it out, but nothing's ever really erased is it? Somone might find it somewhere, sometime and use it against me.
Quite frankly, prpr, I couldn't give a rats ass what you think. You have a great knack of getting under someone's skin. Does it come naturally? Or do you have to practice?

I suppose you shoe size will match that of you head, rather large.
I hope you got one of those tedious "This post is overly aggressive/threatening" type messages from Brian for this. If you didn't, you deserve one.
Quite frankly, I don't give a sh*t about you either. Your rampant paranoia is not my problem, although you seem to want to make it so.

Feel free to delete/edit his post.
It's not up to you to direct any censoring of posts. Butt out.
 
I think you can be too paranoiac about publishing things like MAC address etc. BUT if someone wanted to come and find you it is possible using a Wi-Fi MAC address, this is because the streetview camera cars also store the location of Wi-Fi MAC address's, this is used by skyhook to plot your location on maps without using GPS, so someone really could " find you and do unspeakable things . . ." There is an article HERE that discusses it. I am not saying publishing a Humax MAC address is as harmful but I wouldn't do it
 
Known Issues (struck out when fixed)

  • Remote Scheduling is not compatible with devices using padding for recordings instead of Accurate Recording (AR). This will be addressed in the next update;
  • The EPG data displayed on the portal is not yet regionalised so you may see programmes from a particular region rather than your own. However, when you schedule a recording based on a regional programme then that will be adjusted automatically to reflect your local schedule. This will be addressed in a future update.
  • The EPG display currently takes no account of the channels which are available on your device.
  • The conflict checking is still a little keen and may flag conflicts when there are none.
  • Setting wake-up/sleep events miscalculates the event times by an hour during BST.
  • This service has not yet been tested with HD Fox T2 devices although it should support them.
  • The wireless-helper package currently only supports wireless networks using WPA or WPA2. It is planned to extend support to at least WEP in a future release.
af123, I have just been looking at the first post, and the third issue above has been fixed, so should be struck out. Has there been any progress on the second issue yet?
 
Status
Not open for further replies.
Back
Top