Re: Ok, I have a question
Or it might just temporarily enable wifi to phone home...
73 posts • joined 22 Dec 2009
Ahhh..... WordPerfect 6.1 - it was absolutely magical. Reveal codes to show what was going on under the hood, a couple of minutes spent deleting unwanted bits and pieces, and job done - perfect. Small docs as well, which was helpful back when a 1GB drive was expensive.
Oh... and the document indexer was great as well - we had a structured file system for all our documents/correspondence, and the indexer ran every night. Ended up with a searchable index of >100,000 docs and it only took a second or two to find what you wanted. Not bad for the 90's :)
This hits the nail on the head. Unfortunately, the vast majority of people are lazy about security. And even if you're not being lazy, how many people actually double-check the URL of a link before clicking on it? How many people check the SSL certificate on their email provider when it changes? How many people check the issuing CA on a certificate before deciding to trust it?
I suspect that even if you tried to block people from entering card details (i.e. recognisable patterns of information corresponding to a card), the workarounds employed by bad actors wouldn't deter people. In fact, the workarounds would probably be dressed up as being *extra* security to encourage people to trust the site...
This is an issue of human behaviour, a subconscious desire to conform, and a generally irrational desire to complete something once we've decided to do it. Especially when it's a really good deal and somebody else might beat us to it - quick - buy buy buy.
The simple fact is that people want to enter their card details and complete their purchase :(
I hate to stir the hornets nest that is UK Gov IT projects, but wouldn't the Verify service https://www.theregister.co.uk/2019/07/18/verify_to_be_flagged_undeliverable_by_gov_projects_watchdog/ do the trick here?... ;)
Exactly. This sounds like security through obscurity. It's really simple - either (a) there are *physically* separate networks for the avionics and other systems, or (b) they share the same network.
If it's (a) then great - just tell us. If it's (b) then it's open to attack and it is impossible to guarantee that there will be no access to the avionics network portion from the entertainment/crew info network portions. Somewhere there will be a bug/issue with a protocol, API etc. etc. that can be exploited. Difficult to exploit is not the same as impossible to exploit.
And, yes, passenger info systems need access to flight info, but that doesn't have to come from the avionics network portion - just include additional sensors.
Given the science that they did and the cost of the hardware (everything from hydrogen maser atomic clocks to thousands of helium-filled HDs - too much heat/friction from air-filled HDs), it's an absolute bargain.
Fantastic Horizon program on BBC 4 about this last night: How to See A Black Hole: The Universe's Greatest Mystery
There's also a series of six papers published in a special issue of The Astrophysical Journal Letters.
Beers (just not up at telescope altitude ;) to all those involved
Like people have said above, it's a compromise agreement/settlement agreement, i.e. we are sacking you but want some additional undertakings (e.g. that you won't sue us for age discrimination, or won't engage in a class action). You don't have to give them to us, but if you do then in exchange (as a compromise) we'll give you some extra benefits (e.g. cash / pension etc. etc.). There's no requirement to sign it, but people often do because they want the additional benefits.
However, the issue here is that IBM have allegedly failed to comply with the statutory requirements which make such an agreement legal i.e. have withheld the age data.
The gyroscopes can maintain the angular orientation of the satellite. However, this (giant) mirror will still act as a solar sail - radiation pressure from reflection - https://en.wikipedia.org/wiki/Radiation_pressure
So what happens to that radiation pressure? In order for the satellite to remain in its orbit, something has to counteract it. The maximum radiation pressure would presumably be 9.08N (see link above) per square kilometer of mirror, although in reality it would presumably be somewhat less depending on the angle of the mirror to the sun. Not an insignificant amount of force to counter, particularly given its continuous nature, and it will have to be countered.
Here's the decision... https://www.gov.uk/employment-tribunal-decisions/ms-s-winchester-v-commissioners-for-hm-revenue-and-customs-and-others-2207946-2017 - brief, but an indication of the time and money that will have been spent on this.
I suspect that it's the (unfortunately) regular occurrence where it's only when somebody who actually understands the law (so in this case, clearly not HMRC themselves) gets hold of the case that the right thing finally gets done. Let's hope that the whole court proceedings process hasn't been too much of a toll on Susan Winchester or her business. Could this be the death knell for CEST?...
GiffGaff and O2 are both owned by Telefonica, and GiffGaff runs on O2, so they've had their toes in the water for ages here. The market changes (and what O2 is currently offering to customers) reflects that. It will be interesting to see how both O2 and GiffGaff develop their offer.
Don't know if other major telco-owned MVNs like GiffGaff are running in the UK, but I wouldn't be surprised to see others popping up to try and capture that growing part of the market whilst the mainstream brands are used to service the customers who are willing to pay premium prices and/or want premium services.
Yes... there are some convenient online systems from uk.gov (fx: dons protective headgear... ;)
When a car is purchased with all this internet connected stuff, is the data controller identified to the buyer? Is there a way for the new registered keeper to notify the data controller to revoke all third party access (including previous owner/registered keeper access)? Is there a way for the registered keeper to verify who has access to data associated with their vehicle?
Surely we just need a system where (a) the DVLA issues the registered keeper with a time-limited single use code specific to the vehicle, (b) they can then go onto the data controller's website and use it to associate the vehicle with them, and then (c) they can access the full list of connected devices/accounts and modify as appropriate.
Place a statutory obligation on anybody who sells a vehicle to notify the buyer of all data controllers and you're sorted.
I'd definitely suggest giving dns66 (https://github.com/julian-klode/dns66) a tryt - it'll set itself up as a VPN on your phone so all traffic is routed through it, and then just black-hole ad sites. Don't know whether the domains the FB app is talking to are blocked by it, but it's worth a try. If the problem app is installed as a system app then you might have to go into the dns66 "APPS" settings and toggle it to show system apps since dns66 is set up so that traffic from system apps is (by defaut) not re-routed.
If using dns66 then you can also get it to use a chosen DNS server, e.g. an ad-blocking DNS server.
I seem to recall that part of the reason why MS were able to resist the original warrant (and why e.g. Google weren't in other cases) was that they had compartmentalized things and that MS (USA) wasn't actually in control of the data.
Irrespective, the Data Controller at MS (Republic of Ireland) is responsible for safeguarding the data located in the RoI under local (EU) laws, and so they should be able to block any request for the data from the US Gov via MS (USA).
It'll be interesting to see how this one pans out...
They're already doing that with allowing the likes of Google to access patient data on NHS Spine and do analytics/ data mining on it. At a fundamental level, that kind of thing (subject to *proper* data protection) has a real potential to deliver clinical benefits for patients. However, for that to happen the data custodian must guard the data and ensure it is properly protected. Without that, nobody will trust the NHS and, hey presto, a large group of patients (inevitably including some who are highly vulnerable) won't engage with medics / the NHS.
Erm...the bill says that insurers don't have to cover you if there is "a failure to install safety-critical software updates that the insured person knows, or ought reasonably to know, are safety-critical".
So if there's no "safety-critical software update" then you're still covered by your insurance policy. If the manufacturer EOLs the vehicle and stops supplying patches then the insurer can't dump the liability on you. Then again, it might not be possible (or might be very expensive) to insure vehicles (which drive themselves) when the manufacturer decides that they have gone EOL. Then again, you won't actually own a car anymore will you? Odds are you'll be in an Uber (or suchlike) vehicle.
Remember - this bill primarily deals with (a) liability of insurers, and (b) EV charging. Current draft is: https://publications.parliament.uk/pa/bills/cbill/2017-2019/0112/cbill_2017-20190112_en_2.htm#pt1-l1g4
Doesn't mean that it will illegal not to install a CarOS patch or root/install a custom firmware, but it might mean you're not insured.
Big thing is that this is enabling legislation, and is therefore intentionally broad, so that it works now and decades into the future - fundamental principles are in there to provide stability/certainty, and then it's up to insurers and courts to deal with the real-life scenarios.
So this will all come down to the insurers, who will in turn force the hand of manufacturers as per AC's comment above. Insurers will also have to come up with some good standard T&Cs, e.g. requiring patch installation within a "reasonable period" which they define e.g. no more than 7 days of public release by the vehicle manufacturer. Manufacturers will presumably have to push delivery of OTA patching on release, and force install within a given time period, e.g. at the end of the period preventing new journeys until the patch is installed. Manufacturers might also have to e.g. provide very clear and prominent notifications about CarOS patch status before commencement of a journey.
Rooted CarOS - probably wave goodbye to being insured, at least with any conventional insurer. Rooted entertainment system - might still be insured *if* it doesn't have any impact on vehicle safety, but read the fine-print on the insurance contract. Might encourage a truly hard (physical) divide between car-critical systems and entertainment, but that's going to require the manufacturers to go for safety over shiny things, convenience and cost, so odds of that happening?...
So does this mean that Google will support devices for longer? Will this mean that they end-of-life devices after *more* than 3 years?
I know it's been said (many) times before, but this is something that Apple have got right. If this means that Android devices are supported longer then that would be great.
Seriously, that's a truly stupid amount of money for a phone. A dual-SIM OnePlus 3T is £399 all-in for the 64GB model, £439 for the 128GB model, and their current production OS build is at Android 7.1.1 and is basically stock Android with no manufacturer cr*p to remove (*no* Bixby or anything like it), can be easily rooted if you want to go that way, and doesn't have a fingerprint sensor in a stupid place.
I know the S8 comes with a curvy screen but is it worth £400?...
"1. IEEE 802.11z reduces the number of times a packet gets transmitted over the air from 2 to 1."
"3. If client devices are perhaps newer and capable of operating at data rates or in frequency bands not supported by the access point they can do so."
Just working my way through Gal's Project Zero article (which is absolutely excellent - do read it), he says when searching for possible vulnerabilities to exploit:
"Broadcom provides many features which can be licensed by customers -- not all features are present on all devices"
"Searching through my firmware repository I can see that the vast majority of devices do, indeed, support TDLS. This includes all recent Nexus devices (Nexus 5, 6, 6P) and most Samsung flagships.
"What’s more, TDLS is specified as part of the 802.11z standard ..."
So basically, if the Broadcom WiFi SoC is 802.11z compliant, his TDLS-based attacks will work on it.
He hasn't given a list of all affected devices, but clearly "the vast majority of devices" isn't good news.
Go read the article - it's absolutely excellent :)
Nice intro to graph theory and graph databases, thanks. Might go and do some more reading - would love to understand *how* nodes and edges are expressed/stored within graph databases, how the graph database engines work, and how that can then facilitate insight into large complex datasets
@AC - thanks for the Numberphile video link
@Phil W - which takes us back to the whole question of the package being mis-sold. OFCOM said to El Reg that the ISP are not at fault for selling a package when on the day of activation there isn't capacity on the cabinet/exchange. That's very different to a situation where the cabinet/exchange is not capable of delivering the service at all (i.e. where FTTC doesn't exist). If FTTC doesn't exist then surely the ISP is at fault for accepting an order for a service it absolutely cannot deliver.
Ahhh... that brings me to my my slightly angry and possibly OTT wishlist (similar thing with a family member's hacked Yahoo account).
I would love to see... mandatory 2FA at login, a single use PIN code required from your mobile before a forward address is set up, a one-off re-validation of all existing email forwarding, a BIG CLEAR MESSAGE every time you login if any email forwards are set up on your account, and an easily accessible "delete all email forwarding" button.
Obviously, might get in the way of pushing Yahoo! news at users, but surely that's got to be more important than click-through advertising income. What? It isn't?... ;)
Exactly. Just need to know what kind of screen lock is enabled (pattern, PIN, password, fingerprint) and in most cases the set of combinations to brute-force reduces very significantly. So, effectively, pattern, PIN, are now totally compromised on most devices (well... they weren't exactly strong in the first place). Most passwords will be similarly compromised.
Don't know how fingerprints are processed to convert across to a numerical form for the crypto, but I do wonder whether fingerprint or an appropriately long/complex password are the only realistic options now.
Also wonder how this affects Blackhone etc.
I'm really pleased to see that they are doing this - the EU law is clearly written to require informed consent before dropping cookies on browsers, but clearly websites drop cookies on browsers anyway and the pop-up is just to tell you that they have done that, not to obtain positive consent first (as opposed to e.g. some kind of passive of implied consent).
As per other earlier comments, the current click-through warnings are utterly pointless and just seem to be done to provide a veneer of "You must have consented because we told you that we had done it."
If this causes websites to actually do what the law requires them to do and obtain positive consent before dropping cookies on browsers then that's great. If websites want to block access to people who don't consent then that's up to them, but the point is that they have to obtain positive consent first.
The CH website used to better in 2004 - back then, they had static URLs for individual companies i.e. you could bookmark the information page for individual companies. Unfortunately, a year or two later they started including session IDs in URLs, and that borked bookmarks.
I use UK Gov online services fairly frequently as part of my work, and the primary difference I have seen is a re-skinning of the service home page. The web pages for the actual services themselves haven't changed.
As ever, delighted to see my taxes being spent well...
I'd just say watch out for the 12V LED bulb prices though - they can be significantly higher than for 240V equivalents. For example, 240V GU10 dimmable LEDs are an awful lot cheaper than the 12V GU5.3 equivalents. That said, given expected bulb life it might be that the additional cost of the bulbs is a relatively minor issue.
GU10 dimmable LEDs - £4 each: http://www.screwfix.com/p/lap-gu10-led-lamp-346lm-5w-pack-of-5/3797g
GU5.3 dimmable LEDs - £16 each: http://www.screwfix.com/p/sylvania-led-lamp-mr16-350lm-7w/57901
Having read the article, it has however reminded me that I need to double-check the minimum load that my dimmers support - just looking at replacing halogens all round the house, and new dimmers would be an unwanted additional cost.
I'm not exactly clear from the website article of the exact architecture of the Superfish MITM software setup, but if it's acting as a proxy and is intercepting all traffic without informed user consent then there has to be a privacy aspect here - they may be processing private information and so the Data Protection Act could come into play.
If Superfish were masquerading as other businesses via certificates issued under their root certificate then I wonder if the other businesses would have a cause of action in terms of passing off. Certainly if I was Bank of America or any other business offering services via https or suchlike then I'd be pi**ed off about the potential damage to my reputation and business if customers knew that I would do nothing about other people pretending to be me and intercepting private sessions with my customers. Any EULA the consumer nominally agreed to would be irrelevant in terms of whether or not an act of passing off had occurred.
I would also wonder about copyright infringement - by modifying webpages users were requesting to display ads for other "similar" products, and doing that without the consent of the copyright owner, then that might be an unauthorised adaptation of the copyright work (the webpage).
As other commentards have said, roll on DNSSEC.
Thanks. I think it's an issue of *how* they support the libraries - I believe that the current iPhoto supports multiple local libraries. That's not the issue - it's a case of needing to have the data split between locations, or at least have the main data stored on a LAN and some duplication of data onto the local machine for convenience/ease of use.
For example, photos + thumbnails + metadata stored in a library located on a NAS. Laptop connects up to the NAS for the first time, pulls the thumbnails + metadata for the library over to it and stores them locally. As and when photos are required, they are pulled from the NAS. As changes (additions, deletions, modifications) are made to the library on the NAS (assuming it's shared), they can be sync'd across to the laptop. Ditto, when the laptop disconnects and reconnects to the NAS, changes can be sync'd across to it. When changes are made to a photo on the laptop, the data can by sync'd back to the library on the NAS. When the laptop is disconnected from the NAS, the thumbnails and metadata are still available locally and the app behaves gracefully when users try to access the photos.
Yes... the file-server NAS setup is good for me - I've got a Synology box sat at home happily storing a few TB of data - Time Machine backups, music, video etc. and that's great. So I have the available space and device on the LAN. Just need to be able to use it.
As before, the use scenario is that I have a large amount of photos which cannot all be stored locally on the machine. However, I want a unified photo app so that I can access *all* of the photos through a uniform interface, irrespective of where they are stored - locally or on a NAS device somewhere else on the LAN. At times, I will want to use the app and access (locally stored) photos when not connected to the LAN, and I don't want the app to throw a hissy-fit about not being to access the other photos. Overall, the basic cloud/cloud app scenario.
To me, the basic question is whether the new Photo app will allow a NAS device to be the "cloud" or whether it is locked down to a specific cloud provider i.e. iCloud.
Thoughts/feedback much appreciated. TIA.
I'm just using the free iPhoto app on my MacBook Pro at home. However, the big issue that I've got is the library - I've got the best part of 200GB of photos in iPhoto (I know...) stored locally on my machine and need the space back. I've been avoiding doing anything about it, especially in the knowledge that iPhoto is being ditched, and so this is a good time to look at the available options. I *really* do not want to put my library on a cloud service - cost, speed etc. etc.
My major question is whether the Photos app supports libraries located on a NAS, i.e. can I have multiple libraries with some located on a NAS? And if I can, how is this set up? Are indexes stored locally for speedy and easy access, or does everything have to come from the NAS?
If not, I know that it has been asked in many places many times before, but any suggestions for a suitable non-pro package?
Exactly - if the single file is decrypted locally then the key must be in memory in one form or another. Presumably the key is stored on a remote server which will only allow a single use of the free decrypt button (so no taking an image of the machine and then using the "free decrypt button" on different files on different copies of the image).
Since the key is the critical asset here, it might be that using the "free decrypt button" results in the chosen encrypted file being sent to the remote server, decrypted, and returned to the affected machine. That way, the key is not made accessible in any form, and the remote machine can control/restrict access to the "free decrypt button" functionality.
Spent an hour last night doing remote support on a parent's PC, and the amount of cr*p which had been installed since I last looked at it was scary. Odds of this (or something like it) appearing on a family member's machine at some point is, unfortunately, scarily high and there's little or no chance of them starting to do backups to removable media.
Ho hum :(
It looks like the technology is going to be something to do with this patent application, which was published on 9 October 2014 (US equivalent published a week later): WO2014/164901
Title: "SYSTEM AND METHOD FOR AUGMENTED AND VIRTUAL REALITY"
Claim 1: A user display device, comprising:
a housing frame mountable on a head of a user;
a first pair of cameras coupled to the housing frame to track a movement of the user's eyes and to estimate a depth of focus based on the tracked eye movements; a projection module having a light generating mechanism to generate and modify, based on the estimated depth of focus, a projected light associated with a display object such that the display object appears to be in focus;
a lens mounted on the housing frame; and
a processor communicatively coupled to the projection module to communicate data associated with the display image to the projection module.
Also, this one: WO2012/154620, titled: "MASSIVE SIMULTANEOUS REMOTE DIGITAL PRESENCE WORLD"
Looking at the somewhat limited specification (http://www.apple.com/ipad-air-2/wireless/), it talks about short-term contracts when travelling, and lists UK and US networks.
As per earlier comments, it would seem ludicrous (and potentially anti-competitive) to block use of other networks at a software level.
So I suspect that the actual iPad Air 2 will still have a slot for a physical SIM, and that the Apple SIM is (at least for the moment) an additional software option offering pre-configured SIM services, useful when you are e.g. travelling, or want cellular services on a device when you don't have a physical SIM.
So when you're visiting the US and want cellular access on your iPad Air 2 which has got a UK SIM card in it, you just go to the config page, get presented with the Apple SIM options, make a selection (e.g. based on signal strength where you are located), make payment via the iTunes store, and that's it - job done.
Apple have made the sale, take their cut from the network operator, and you have the network access you need.
When you get back home, your device reverts to using the network which its physical SIM card is configured for.
No competition problems since this is just a convenient additional service for users and doesn't impose any additional limitations upon them, and in fact can be argued to provide them with a significant benefit.
Obviously, this is just the beginning and clearly long-term things will develop. However, so long as a physical SIM slot still exists in the device then there's no issue.
I would be bothered about the contracts between the network operators and Apple - the network operators will want to be able to provide lower cost services when accessed through a physical SIM, but if Apple have put a "most favoured nation" type clause in the contract for provision of services via the Apple SIM then, effectively, the network operators who sign up will be signing their own death warrants. Then again, maybe if the contracts through Apple are truly short-term or require the presence of a physical SIM in the device with a "home country" type feature locked to that physical SIM (the short-term Apple SIM contracts only being available for other countries) then that might keep network operators happy. We shall see...
Like the article says (and various other articles have said before and commentards commented on), this is a fundamental problem with Android. I've got a Nexus 5 and Android's permissions handling is the main thing that would push me back towards using an iOS device.
I suspect that this might all hang on whether or not Uber uses GPS data from the actual journey to determine the fare.
So, for example, if you go onto the Uber website/app, provide your journey details, and get a fixed price for the journey then there's no taximeter issue since there's no metering in the vehicle and e.g. delays in the journey, detours etc. won't affect the price.
However, if the fare is determined at the end of the journey based on GPS data logged by a device in the vehicle (and e.g. transmitted to an Uber server which calculates the fare) then there must be a strong argument that it brings a taximeter into effect in the vehicle. There's caselaw where having part of a device/system in a different location wasn't a get-out-of-jail-free card.
So I think that it might depend on exactly what that GPS data is used for - logging journeys for live journey status info, passenger safety and optimising future fare calculations is one thing. Using it to meter the journey is another...
Yep... definitely not competitive against 3 with its unlimited 4G data deal. Ditto, GiffGaff are offering a similar 4G package (running on O2's infrastructure) at £12.99. However, if the price difference isn't too much (and e.g. BBC iPlayer still requires a wifi connection to download/stream shows) then maybe the majority of people just won't bother to move.
Thanks for all the suggestions and feedback.
mxtoolbox.com was an easy way of checking whether STARTTLS is stated as being supported - just do an MX lookup on the chosen domain to identify the MX server(s) and then click on the "SMTP Test" button for each MX server. The "Session Transcript" box then shows the response to EHLO - as per comments, you're looking for "250-STARTTLS".
However, http://checktls.com is vastly better (since it's designed just to check TLS) - does a very detailed check of all MX servers, and gives a commented, easy to understand, session transcript/analysis. Amongst other things, it checks the full certificate chain and gives a nice colour-coded summary results panel.
So with the email address/domain I was interested in, MX servers include service19.mimecast.com and service20.mimecast.com. The results tell me that both have incorrect certificate chains because Mimecast are using certificates issued for *.mimecast.com instead of the specific service19 and service20, and include RFC references. The summary results include the helpful message that:
"Note: Cert failures do not affect TLS encryption, but may mean the site isn't who they say they are."
Another email address I tried has Google providing all MX servers, and passed all checks.
Yahoo fails for the same reason as Mimecast.
Interestingly, there's a lot of variation in the crypto algorithms used, which is interesting since I would expect there to be some kind of an industry consensus on what to use. Thoughts/comments anybody?
Minor tweak on the question from @theodore - I'm wondering if there's an *easy*/convenient way to double-check whether STARTTLS is correctly set up on a domain.
For example, an email address I can send mail to from my domain, or a service that can be pointed at an email address on my domain, and which will return results on whether STARTTLS is correctly set up.
Just set up voicemail on a new mobile on EE, and it does give you the option of requiring a PIN every time you call the voicemail number, even from your own phone. It seems from the page on the 3 website linked to by the article that they have the same option.
That said, the marketing droids could have actually given a direct answer to the question/issues raised, rather than the usual tripe that they seem to churn out.
I guess that ultimately this might come down to the mobile phone companies providing the mass-market convenient option of not having to enter a PIN when calling from a number that appears to be your own, whilst providing the "always on" PIN requirement for those who want some security.
CLI spoofing has been an easy option for many years, so the fact that it provides a way to get into people's voicemail doesn't surprise me. Oh well...
I'm going to put my neck on the line here, but... maybe since multiple streams from multiple providers have gone down then it's an issue with an expired certificate held by the CDN, e.g. Akamai or whoever else they use. If the CDN is delivering an encrypted Flash stream then it should have master video streams which are then encrypted on a per-user basis (http://en.wikipedia.org/wiki/Protected_Streaming). If encryption is with a key held by the CDN (e.g. its own key used to encrypt a whole range of streams) then that might explain why BBC, Sky etc. are affected.
Ultimately, you will have to pay for all of the gas and electricity you have used. So whether it's worth under-paying now depends on how gas and electricity prices move in the future - if they e.g. increase above inflation (or at a greater rate than the interest rate on your bank account minus tax) then it's actually better to pay for everything now (or even over-pay i.e. pay for gas and electricity you haven't used yet) since you'll end up paying more for the same gas/electricity later.
Biting the hand that feeds IT © 1998–2021