Many thanks to Thomas
The power of journalism: Thomas has been able to get clearer (if not *entirely* clear) answers on this point than I (and others) have managed.
Thank you Thomas and El Reg!
145 publicly visible posts • joined 30 Sep 2008
IMHO:
* IRC is a "user-to-user service"
* whether a particular implementation of it is a "regulated user-to-user service" will depend on who is using it and how. For internal-only business conversations? Probably out of scope. Used for customer support / enquiries? Probably in scope.
I put the question.
I did not get an answer, straight or otherwise.
Nor did Ofcom provide answers to other questions I asked about some of the other exemptions in Schedule 1 which could be valuable to people running small hobbyist sites, including:
1) how Ofcom will interpret "email" for the purposes of Schedule 1, paragraph 1. Ofcom said that there is a "common definition", but despite prompting, it did not provide it.
2) how Ofcom will apply the "or other concern" wording in Schedule 1 paragraph 7, and whether closed groups, like a forum run solely for members of a cub pack, with no external access, could take advantage of it.
3) how Ofcom will apply s227(3), the effect of which is intended to be that the "provider" of a service cannot also be a "user" of it (a sensible position). But the opening words appear to limit it to "when acting in the course of the provider’s business", and so it may not be applicable in the context of hobbyists, and so understanding Ofcom's intent here would be valuable.
I’ve used Mastodon as a self-hosted fedi server for several years now and, while I wish the installation process was simpler, each update, including this one, has been smooth. Mine is a single-user instance, and it ran fine on a Raspberry Pi 4 for ages; now, it is on an Intel NUC and is coping better with the volume of traffic.
I used both the fediverse and Twitter for several years, but I stopped using Twitter a few months back - for both fun and work stuff, the fediverse works really well for me.
Or, if the bill passes, rebels representing *****tone and Stocksbridge.
Thoughts and prayers for the MP for Scunthorpe.
And it will make it even trickier for some men to find the MP for Clitheroe, in the definitely-not-a-euphemism Ribble Valley.
I have quite a collection of pine64 products. I use the PineTime watch every day, and it is great for my needs. I use a PinePhone Pro occasionally, but it is more for tinkering than every day use (for me) at this stage. If/when the camera gets support, I'll be even more interested.
I had a PineBook Pro, but, even knowing its limitations before I bought it, I found it too slow for my needs. I passed it on to someone whose own PBP had suffered a mishap. I love the idea of it, and I want to support pine64's efforts, but I can't see me buying another one at the moment.
> For Touchscreen PC tablet support, I'd be interested to know which Linux distros support this the most.
The touchscreen on my Microsoft Surface devices works perfectly on Debian, using the linux-surface project. I write on the screen using Xournal++ most days.
It took about 20 seconds to load, and it "just worked". There was a slight delay. Enough to be noticeable, but not enough to get in the way of using it. As a bit of a showpiece, I thought it was rather impressive. Although I'd still pick Collabora Online, perhaps unsurprisingly.
It's a reasonably complicated answer.
The GDPR applies to anyone who falls within both its material and territorial scope. So an organisation in the UK can be subject to the GDPR.
But the UK has its own version - the UK GDPR - which is very similar to the GDPR but with a few small tweaks, in addition to the Data Protection Act 2018. As with the GDPR, anyone who falls within the material and territorial scope of the UK GDPR is subject to it.
In some cases, it is clear cut which applies. In others, it is not, and you end up looking at the specifics of each processing activity.
SARs are purpose-blind, and the controller has no basis for attempting to "look behind" a SAR, to try to establish the applicant's motive. Similarly, they have no basis for rejecting a SAR as being made "for the wrong reason".
The controller simply needs to get on and deal with it in the same way as any other SAR, and provide the information required by Article 15 (UK) GDPR.
This is one of the areas in which I see controllers make life unnecessarily hard for themselves. Lots of people - both controllers and subjects - still misunderstand what is covered by a SAR. It's common (in my experience, at least) to see people using it to try to get copies of documents, or things which are not their personal data or which is not information related to the processing of their personal data. If that's what they want then, yes, discovery is far more likely to yield those results, if it is available). Similarly, controllers get themselves in a tizz about what they are required to provide, especially in the face of an assertive data subject or a represented data subject, asking for things to which they are not legally entitled.
While there are undoubtedly times when discovery will be the better tool for the job, discovery is only available in limited situations. If someone is merely "under investigation", for example, discovery is unlikely to be available to them at that stage. Whether a SAR then would reveal anything useful might be a different matter, especially given the exemptions available to withhold the provision of information under a SAR, but SARs are available when discovery is not.
We're only a relatively small business, but my plan is that, by switching from donating when I think about it to making it a monthly thing, I am more likely to do it, and I factor it into our budget.
I've also started writing up to which projects we've donated / paid for something each month, mainly in case it is of interest to others.
Deciding which project gets what is tricky, but my thinking is that "doing something" is, in this case, better than "doing nothing", or just carrying on as we were before.
I mean, why make something convenient and easy to use (I know, I know, they're printer manufacturers) when you can just blame covid and have your customers click through warnings and get an unsatisfactory experience?
... I didn't feel I met the criteria they had set out for being a developer. I'm a keen user, and I'm happy to make what meagre contributions I can, but I don't have the skills to make software work on a new hardware platform. So I didn't apply for one, knowing that slots were limited. When they become available to the general public - if they become available to the general public - then I'll be buying one.
(I like my PineTime, and my old model PinePhone, but I didn't get on with the PineBook Pro.)
We've offered .onion services (e.g. dlegal66uj5u2dvcbrev7vv6fjtwnd4moqu7j6jnd42rmbypv3coigyd.onion) for most of our web-facing stuff for a few years now, and we've used a bit of a kludgy workaround using web server config and exit node IP addresses to redirect Tor users to the .onion version automatically. We've supported alt-srv and onion-location for a quite a while now too, so great to see this will get broader usage.
> And the attitude was exactly like yours...
Honestly, I'm not surprised, given the volume of marketing bumpf we get sent. Missing what might be a useful seminar is perhaps the price to pay for not sitting through numerous sales pitches.
Bravo if you are or were doing things with BILETA — although I'd have thought you are mostly hitting lawyers in academia with that crowd (as most BILETA attendees are academics, and IT law academics at that, rather than the broad gamut of practitioners, with a few notable exceptions)?
> They would not even attend free seminars on basic IT security because it detracted from the time they could bill to clients
I — lawyer — don’t typically attend free seminars on IT stuff, security or otherwise, since they are nearly always, in my experience, a sales pitch disguised as a seminar. Possibly one or two small bits of useful information, but mostly a list of dangers and pitfalls, and an explanation of how the presenter's company's chargeable product / service can solve them. (Perhaps it's exactly the same for non-lawyers going to a lawyer's seminar...?)
I tried to persuade the Law Society to run a "basics of IT security" session for lawyers in small firms, who may not have IT staff, where the content was vetted so it was practical and implementable and not (just) a sales pitch, but I got no-where, which was a shame.
You can have a binding contract without even the postcard — oral contracts are still contracts. Some specific situations require things to be in "signed writing", but that's the exception.
You might have *evidential* issues, but the lack of a written agreement, let alone the lack of a signature, does not vitiate the existence of a contract in most cases.
In this case, there was no dispute that the email was sent, with the content in question, from the person from whom it purported to have been sent. So no issue in terms of whether it was fraudulent.
If the defendant had alleged that they had never sent that email, and it was someone else spoofing their account, then the case would have looked very different, in terms of the points arguedt.
(Very few contracts under English law require a signature, so a trivially-copyable signature is unlikely to make a major different either way.)
For anyone bored, there are a couple of good sources of information on signatures under English law:
1.) The (very) recent Law Commission report on electronic execution of documents: https://www.lawcom.gov.uk/project/electronic-execution-of-documents/
2.) The (now rather aged) excellent article by Chris Reed, from 2000: https://warwick.ac.uk/fac/soc/law/elj/jilt/2000_3/reed/
But do bear in mind that most contracts under English law do not require signatures to be binding. There are some important exceptions, but the presence of a "signature", in many cases, is nothing more than evidential.
Most commenters on here seem to be fumbling around in the dark, making comments over law they don't understand :)
IMHO, the decision did little more than apply existing law on signatures, looking at the purpose of the bit of text added automatically.
See, for example, the very recent work on this issue, from the Law Commission: https://www.lawcom.gov.uk/electronic-signatures-are-valid-say-governments-legal-experts/
> merely an offer
So anyone receiving the email can accept the offer?
Would it not make more sense to phrase it as an "invitation to treat", which is not capable of acceptable?
> a properly signed and agreed contract
What is the difference between a "signed" contract and a "properly signed" contract? After all, the court here held that the inclusion of the email signature was "signed", and thus presumably also "properly signed".
What is an "agreed" contract (as that suggests that there are contracts which are not "agreed")?
If — as is the case for most contracts — neither a signature nor even written evidence is required, what impact does this wording have, if any?
etc.
[Bloody lawyers etc.]
No ambiguity there!
a.) accredited by whom? (“Do our training and get our accreditation — you can hack without fear of prosecution!”)
b.) who decides what is “ethical”? Which ethical model is to be applied? Is there some kind of ethics oversight board?
c.) allowing people to hack to “prevent criminal activity” seems broad? ("I hacked your computer and wiped it. Now it can't be used by criminals!")
The GDPR establishes the right of access — Article 15 — but it is subject to the specific exclusion / limitation in paragraph 25, Schedule 2, Data Protection Act 2018. The ICO's guidance essentially parrots this paragraph. This limits the scope of Article 15, and extends the time to respond.
What fun.
There’s some rather shonky logic in the commentary here, IMHO.
First, I'd have thought that the starting point is to work out who is the controller of the processing which takes place on each key server, on what basis the data are being processed, what rights apply to the data subjects, whether any exceptions apply, whether any exemptions apply, and so on. Without this, it's all a bit nebulous.
Similarly, the reference to "implied consent" sounds like a red herring, since consent requires a "clear affirmative action" by the data subject — it is either "consent" or it is not — and, in any case, (a) consent can be withdrawn at any time (Article 7(3) GDPR), and (b) the right to erasure, under Article 17(1)(b) expressly applies to processing done on the basis of consent, where that consent is withdrawn. So, even if "implied consent" is a thing, you can't argue "implied consent" as the basis of continued processing, in the face of an objection / request for withdrawal of consent.
Lastly, I’m not sure where the concept that “the right of erasure only applies where it is practical” comes from. The right may not apply where the request is manifestly unfounded or excessive (Article 12(5)), but that’s hardly the same as whether the deletion is “practical”.
I suspect we simply have here a situation in which those designing and operating the key servers did so — perhaps entirely reasonably, at the time — without considering this kind of issue.
I'm not sure that's true, as the shielding law treats each transmission in isolation.
A company which offered an Internet access service and its own IPTV service would be shielded from liability in respect of a transmission initiated by a user of its Internet access service, but would not be shielded for something it chose to distribute via its IPTV service.
The ruling stems from the Cartier litigation, which relates to website blocking injunctions issued to make it a little bit harder to access sites which infringe on certain trade marks.
It should apply to blocking orders based on infringement of copyright, but I guess that's a battle for another day.
It will be interesting to see whether it has an impact on blocking orders imposed on ISPs under the Digital Economy Act, in respect of porn sites which do not implement age verification, but there's a completely different framework. While it seems reasonable to me that the same approach should be taken, and that the BBFC should reimburse ISPs for their costs, that seems... unlikely.
It has no direct bearing on the Norwich Pharmacal orders used to obtain subscriber information from ISPs, in my opinion.
That describes one of the potential solutions — AVSecure — pretty well:
"Age verification cards will be obtainable at over 30,000 retail stores across the UK. It will allow face-to-face age verification to be completed at the point of sale. If you don’t clearly look over 18, you will be asked to show ID to the cashier in the same way you are asked when buying alcohol or cigarettes."
I'm not sure about the OTP bit though, although I *think* I've heard that mentioned...
It depends.
A site can be made available “on a commercial basis” while still not being chargeable to visitors. For example, if the site derives income from advertising, or if it exists to drive traffic to paid sites.
There are draft regulations on what “on a commercial basis” means, here: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/600735/Draft_Online_Pornography_Commercial_Basis_Regulations_2017.pdf
(This is consistent with other areas of law, such as intermediary liability rules.)
The requirement to have age-verification in place applies to any person who "makes pornographic material available on the internet to persons in the United Kingdom on a commercial basis other than in a way that secures that, at any given time, the material is not normally accessible by persons under the age of 18." (s14(1) DEA 2017)
It does not matter whether that person is based in the UK or elsewhere.
An ISP can be compelled by an administrative (non-judicial) blocking order to take the steps either specified in the blocking notice, or else as "appear to the provider to be appropriate", to "prevent persons in the United Kingdom from being able to access the offending material using the service it provides". (s23(1))
The legislation expressly permits overblocking: "The steps that may be specified or arrangements that may be put in place ... include steps or arrangements that will or may also have the effect of preventing persons in the United Kingdom from being able to access material other than the offending material using the service provided by the internet service provider." (s23(3))
"Pornographic material" is defined in s15. It's too long for me to paste here, but it covers quite a lot, with an emphasis on material which was "produced solely or principally for the purposes of sexual arousal". And, since different people like different things, that potentially covers quite a lot.
Clause 60 sits within Part 3, and Part 3 applies only to "processing by a competent authority", defined as "a person specified in Schedule 7, and any other person if and to the extent that the person has statutory functions for any of the law enforcement purposes, but excluding intelligence agencies".
At the moment, Schedule 7 contains pretty much what one would expect to be treated as law enforcement agencies.
For now, at least, "normal" data controllers can appear to be able to sleep a little easier...
I'm happily using FreePBX at home — as a lawyer, it started as a way for me to learn more about VoIP and over the top communications services to be able to give better advice, and ended up being useful enough that I keep it going.
- My understanding is that 5060 need not be open, if the PBX registers outbound with the SIP trunk — the FreePBX GUI makes this very easy, if the trunk provider supports it
- If 5060 does have to be open, could it not be limited to certain IP ranges of the trunk providers?
- If it has to be open fully (e.g. to permit incoming SIP URI calls from any originator), FreePBX comes with fail2ban pre-installed, and there is an "intrusion detection" function in the GUI: configuring it to read from the security log and to ban an IP after [x] failed password attempts was not trivial (for me), but I did get it to work
(I wanted incoming SIP URI calls "because I can" rather than for anything else, and it generates a lot of spam (spit?) which needs to be handled — separate to password attacks — but, so far, that has seemed manageable.)