We are attempting to compile a list of all the known corporate landlords and property managers who use Landlord Credit Bureau.
We will not be publishing the details of small landlords and don’t feel there is a public interest in having their individual names made public.
Corporate landlords and property management firms we feel are fair to comment on. If you feel you have been listed here improperly please let us know at email@example.com and we will work with you to ensure the record is correct.
Landlord Credit Bureau CEO Zac Killam is a partner in LiveWell Property Management.
They are believed to own 21 + properties in the Hamilton area.
LiveWell partners Zac Killam and Matt Christie own the building I live in through a numbered Ontario corporation:
Since being exposed by the media and becoming the subject of a Federal privacy investigation, LiveWell Properties have been scrubbing their already slim online presence. More to come on this but for now here is LiveWell abandoning its online portal and rental listings:
They appear to be rebranding to LWPM as all their old URLS redirect to a new Buildium portal:
They no longer list any of their available properties for rent on their website.
Vionell Holdings Partnership is a licensed multi-family, condominium property management firm that has operations in Brandon, Portage la Prairie, and Thompson, Manitoba. Our team of professionals manage the properties by providing excellent service in the areas of leasing, maintenance, budgeting and financial reporting.
In a major reversal of policy the company says it will be revealing the “secret” database field to tenants. The field was previously only viewable by other landlords, raising serious concerns about potential abuse. This represents a major victory for tenants rights across the country but it is a change that isn’t without its own controversies.
Previously, the Tenant Record generated by Landlord Credit Bureau had a field called “Landlords Experience Regarding This Tenancy” which consisted of six yes or no questions. It was made clear that this field was not shared with tenants, only other landlords.
Once the existence of the secret field was made public, Landlord Credit Bureau made a series of alterations to the tenant record which we documented here:
On Friday April 16th, this message was posted to the Landlord section of the LCB website:
There is some cause for celebration here because this secret field was potentially truly insidious. Imagine being a tenant on LCB and your record looks clean on your end, yet you keep getting denied apartments. You might never know the reason was a past landlord decided to answer “Yes” to one or more of the six questions. If you can’t see what you are being accused of, how can you correct it?
Making this field transparent to all users is a major victory for tenants who were being exploited by this field hidden to the advantage of landlords. What remains are serious concerns about how they are going about this process of “transparency”.
Note that the landlord is asked if they want to keep their responses as is or to reset the whole field in bulk for all their tenants. If the landlord doesn’t respond to this question by April 30th, LCB says they will reset the questions in the field.
We believe tenants have a right to see what their landlords reported about them in that field when they thought it was going to be a secret. Allowing landlords to reset their answers or resetting by default if landlords don’t respond in time denies tenants access to information that never should have been hidden from them in the first place and permits landlords to conceal potential abuse of this formerly landlords-only field.
If a landlord wrongly reported a tenant on one of the six questions and the reporting may have harmed the rental prospects of that tenant they have a right to know. They have a right to pursue their landlord for damages if they feel like this field was unfairly used against them. By wiping out the entries in this field before tenants get a chance to see them, Landlord Credit Bureau is essentially wiping out the evidence tenants would need in order to prove abuse or malfeasance on the part of their landlord.
It also demonstrates a shocking lack of confidence in the integrity of their data. Landlord Credit Bureau is so concerned about how landlords have been using this secret field that it would prefer to wipe the whole record clean rather than risk letting tenants see what was recorded in there.
Take note of the timing. They make the announcement on the website on the 16th of April. The landlord is told if they don’t answer by April 30th their answers in that field for all tenants will be reset. May 3rd they are going to let tenants see the field. Most landlords won’t be logging in to the site between April 16th and the 30th – by the 15th most reporting is finished for the month. It’s safe to assume many landlords won’t be logging in until May 1st and finding their records reset.
No proactive email communication went out to landlords or tenants about this major change. Nothing that would prompt the landlord to go log in and check their answers for accuracy. Nothing that would alert the tenant to the fact that there has been a secret field this whole time that is about to be revealed to them.
When we became aware of this change and the potential loss of crucial evidence it represented we immediately reported it to investigators from the Office of the Privacy Commissioner and the Ministry of Government and Consumer Affairs. We also provided the information to several elected officials who are working on the LCB file as well as journalists we have been working with.
In our letter to the Ministry of Government and Consumer Affairs we asked them to invoke their investigatory powers under the Consumer Reporting Act and obtain a warrant to search for and seize the Landlord Credit Bureau database and all backups. We are not made privy to details of the investigation so we do not know if anything like this was done, all we can confirm is that both agencies received our letter. At this point we can only assume they took whatever appropriate action is within their power.
The end of the LCBs secret field is a big win for tenants in Canada but now we need to know what was documented about us in that field. If the LCB want to be truly transparent they could release the unedited contents of the secret field to each tenant so they can review and verify. Until there is real transparency where we get to hear what landlords will say about us when they think we can’t hear them this is little more than a coverup operation to protect landlords who LCB is clearly also concerned have abused the hidden field.
This post is the third (and final) in a series on known data security claims made by the Landlord Credit Bureau. See below for the previous entries:
I wanted to examine the last bit of the LCB Security Policy to make sure we covered the whole thing. The policy statement in question is here:
The claims about Amazon are fairly uncontroversial but do contain some points worth raising.
On the surface my main criticism is that Amazon AWS and Amazon RDS Encryption describe a whole host of technologies and capabilities that depend very much on the specific technologies implemented by the user.
Amazon RDS, for example, is Amazon Relational Database Services. It’s a broad category description of a huge toolbox of technologies offered by Amazon. Generally speaking we can say that Amazon has a very robust security infrastructure and they do indeed contract for US Military and Intelligence work. What we don’t know is what kind of technology stack LCB is using. Amazon RDS allows many different database types, each with their own advantages and drawbacks. Some of these technologies are free and open source, some of them are extremely pricey closed source solutions designed for maximum security.
Without this specific knowledge it’s difficult to critique these claims effectively. On the whole its at least encouraging from a data security perspective because Amazon RDP does not allow customers root level access on their systems and manages all patches/upgrades/updates, reducing the probability of some unpatched vulnerability exposing their database to hackers. Other than that and agreeing overall with the physical security advantages of Amazon servers there isn’t much more to intelligently add.
What we did find interesting was when we went to try and verify that Landlord Credit Bureau was indeed using Amazon Web Services. Typically websites and applications using AWS leave a signature you can spot if you do a WHOIS lookup of their web domain.
Users of AWS typically have to change the DNS name servers they use over to Amazon DNS name servers – dubbed Amazon Route 53 by Amazon. Thinking this would be an easy way to verify the LCB was using Amazon AWS we did some digging through their WHOIS records. We found a few matters of interest but we’ll start with the Amazon claims.
First though we need to take a look at how users interact with the LCB websites and the actual LCB web application.
Since we are Canadian users, we are going to start with the Canadian version of the LCB website – landlordcreditbureau.ca
The IP address resolves to Canadian servers so we can be fairly comfortable knowing the data being stored and transmitted from this address is at least staying in Canada.
The domain name registrar they used has made their WHOIS record private, which is standard practice now for most internet domains
The reason I bring up point #2 here and that is because when I registered the domain for Landlord Credit Bureau Facts, my WHOIS information was also kept private by my registrar, DreamHost. Again, this is a standard practice, you don’t have to ask for it, you don’t have to pay extra.
In his lawsuit against us, Zac Killam claims that by having my WHOIS information kept private (a default setting for all new registrations) I was “hiding” my identity:
So I find it very interesting that when I check the WHOIS for his websites and find the records are all private. He accuses me of some kind of plot to hide my identity when his domains are set up the exact same way. Should I assume he is trying to hide his identity? What nefarious plot is he hiding here? Or are we just talking about a standard feature of all new domain registrations in the modern era of the internet? Readers can judge for themselves.
This doesn’t paint the whole picture however, since the actual Landlord Credit Bureau web application doesn’t run off the Canadian .ca domain. Requests to sign in to either the Tenant or Landlord side of the application, regardless of what country the user is logging in from all go through this URL: app.landlordcreditbureau.com
So let’s look at the WHOIS for landlordcreditbureau.com
Some really interesting things happening on this record but let’s start with the Amazon claim. If we focus in on the Name Servers section of the WHOIS record you can see they are the DNS servers for their domain registrar, EasyDNS. What we would expect to see here is Amazon AWS name servers, not the EasyDNS servers.
Based on this evidence one might conclude that Landlord Credit Bureau aren’t using Amazon Web Services because there is no apparent route to Amazon Route 53 in their DNS setup. Case closed, right?
It took a bit of a deep dive but I think it’s pretty easy now to see that while we can’t explicitly prove they are using AWS and other Amazon technologies they are certainly set up to do so. Given the evidence I’ve been able to assemble so far I see no reason to doubt their Amazon claims at this time.
Moving on from Amazon, let’s focus in on something that really jumped out at me the first time I saw this record: the IP address for the server is located in the United States, in Ashburn Virginia to be precise and under a GoDaddy.com ASN.
It’s a legit data center, well appointed and with physical security features that you would expect from a facility of its kind.
What concerns me about this record is that it reveals that all of the tenant data being generated in Canada is being stored in the United States. Every time a landlord logs in to the service the data is being sent to and recovered from the US. Every time a tenant logs in to the service that data is being sent to and recovered from the US.
Recall that this is highly sensitive information about Canadians – rental payment history, home address, your Equifax credit score, name, date of birth, details of problems you’ve had with the landlord, comments from the landlord about you. All of it hopping across the border to servers in the United States.
Why is this significant?
When your data leaves Canada and gets stored on servers in the US, that data is now subject to US law. There are no US federal laws governing privacy of personal data, only individual state laws. Your data is also subject to search and seizure by US law enforcement as well as monitoring by US intelligence agencies through provisions in the USA PATRIOT Act.
Virginia is only second state in the US to adopt a comprehensive privacy law. They only did so as of March 4 2021, just over a month from this writing, and the law isn’t as robust or tested as the PIPEDA is in Canada. It also includes exceptions if you aren’t storing the personal data of 100,000 people or more, or 25,000 if more than half of your revenue comes from the sale of personal data.
It’s also worth noting that Quebec and Alberta prohibit businesses from storing Canadians personal data outside Canada entirely. LCB doesn’t operate in Quebec, but they do in Alberta. In fact, their legal framework page has a full Alberta section but none of it mentions how its legal for them to store your data in the US.
Here in Ontario, the LCB is governed by the Consumer Reporting Act as they are a licensed Credit Reporting Agency. Does the CRA have anything to say about storing data outside of Canada?
If we look at a comparison of service packages published by the Landlord Credit Bureau on the Landlord portal there’s this entry, which seems to indicate your data isn’t just being shared with Canadian landlords, it’s landlords all over the world potentially. They claim to be the “only international tenant database”.
In conclusion, Landlord Credit Bureau is storing your data in the US, possibly in contravention of Canadian laws. This also means your data is now subject to US laws and to search by US law enforcement and intelligence agencies. To most Canadians this isn’t exactly comforting.
Last week we took a look at Landlord Credit Bureaus claims about EI3PA data security compliance and found they left us with more questions than answers. You can check out that coverage here:
NOTE: Since publishing the above post last week, Landlord Credit Bureau has removed all references to being EI3PA compliant from its website without noting the change.
Here is how their FAQ looked last week:
Here is what it looks like this week:
So were they mistaken about being EI3PA compliant or did they deliberately mislead the public about their practices? If they can’t be honest or accurate about their data security claims, how secure do you think your data is?
Today we are going to examine the first half of their published Security Policy. You can view their policy here.
The first paragraph is notable only for the fact that the writer chooses to highlight how they use SSL encryption on their site. That’s great, SSL is important in keeping data being transferred between their site and your device secure but SSL is commonplace technology. Google won’t index your website anymore unless you have a valid SSL certificate and have HTTPS enabled. It’s not the first technology I’d be invoking to assure users of my system that their highly sensitive personal information was safe.
The second paragraph is where things get interesting because specific technology and methodology is addressed a bit. First they claim that unique usernames allow them to track and audit user activity, which again is fair enough and what you’d expect. It would be interesting to know what kind of user activity is logged though and how long change logs are kept but otherwise take no issue with this part.
Hashing passwords is the practice of not storing a users actual password in a database table but instead storing an encrypted version of it. The ins and outs of it are complex if you aren’t well versed in cryptography (and I’m no expert in it) but if you want a primer on basic crypto jargon and how some of it works The Guardian has a pretty informative piece here. Let me stand on the shoulders of giants a bit and offer their explanation:
The cryptographic method deployed by Landlord Credit Bureau is called bcrypt. The Guardian piece helpfully has a section on the technology so once again I will defer to them:
My understanding of bcrypt is that it is a highly effective way to encrypt hashes as it is what is considered “computationally infeasible” to crack by brute force. This essentially means that it could take millions of years to brute force crack a single hashed value.
This sounds like a highly secure system and it is – in theory. It’s deployed all over the place protecting your passwords for all kinds of things. It turns out that how secure bcrypt is becomes highly dependent on how the individual user implements it and what kind of hardware and software tools the hacker has at their disposal.
Let’s look at two example cases.
Workplace-focused team chat app Slack was hacked in March of 2015. They used bcrypt to encrypt user passwords, as reported by TechCrunch:
In the case of the Slack hack, attackers were able to exploit the app so they could log passwords in real time as they were entered. In this case bcrypt did its job but the infrastructure around it failed. The impacts of the hack could still be felt at Slack 4 years later when they had to force password resets on 100,00 more accounts they confirmed were compromised.
So it’s clear that even when bcrypt works it depends on the rest of the applications infrastructure also being secure.
A more concerning example is the infamous Ashley Madison hack of September 2015. This time hackers were able to obtain the database for the popular adult “affair seekers” website and directly attack the user passwords, which were protected by bcrypt.
Once again, what we are seeing is not a specific vulnerability in bcrypt being exploited but rather attackers taking advantage of errors made in the sites programming. So far, bcrypt hasn’t been the point of failure in these examples.
So what about directly attacking a bcrypt hash? How long would it take?
To understand that we need to understand something called a Work Factor, which is a system cryptographers use to describe the amount of effort it takes to break a code.
Going by the above benchmark from 2016, a Work Factor (cost) of 5 allows a pretty standard desktop server to process 384.04 passwords per second. Using a specialized rig of 8 high-end GPUS you can achieve 115,642 hash functions a second. As you scale up, the fewer hash functions you can perform per second, creating a bottleneck for the performance of your site or application.
So how long to crack these different Work Factors?
This chart assumes you are using the same kind of high-end GPU rig. The main factor after Work is what kind of password scheme you are implementing. Ironically, we can see that passwords which would be considered PCI DSS compliant are the most vulnerable. A Work Factor 5, PCI compliant password could be cracked in a mere 5 days.
So what kind of password is the Good kind that’s taking 29 million years to crack?
The US Department of Commerce National Institute of Standards and Technology published a draft standard for digital identify management in 2017. You can read the full paper here.
Here are their findings about passwords (referred to here as Memorized Secrets):
These standards are a long way from being adopted and so most implementations of bcrypt aren’t really taking advantage of its features to provide maximum protection.
Technology deployed by attackers has come a long way since these 2015 breaches as well. Using GPUs in cracking setups has become yesterdays tech – modern crackers have moved on to clusters of Field Programmable Gate Arrays or FPGAs to take on the job and the performance gains are massive.
Here are their benchmarking numbers for CPU and GPU based hashing:
Now here is a comparison between a single GPU and a single FPGA:
FPGAs can run 4x the hashing operations of a normal GPU. When clustered in an array of 18 FPGAs:
So that’s 2.1 million password attempts per second. All in one neat little 4U rack mountable package.
Scattered Secrets began using a cluster of 4 of these arrays to achieve 8 million plus attempts per second.
These devices dramatically alter the time considerations for brute force cracking bcrypt and other hash functions. But how effective is FPGA-based bcrypt cracking in real world scenarios?
Scattered Secrets were able to put it to the test in 2019 when the database of Dutch adult web forum Hookers.nl was leaked to the web. The site used a mix of older MD5 hashed passwords and newer bcrypt hashed passwords. In just 3 days the group was able to crack 57% of the total user passwords on the site using very basic dictionary attacks.
How did they perform against bcrypt? In 3 days they were able to crack 11,675 of the passwords protected by bcrypt – 24% of the total.
The vulnerability? Weak passwords that are easily recognized by dictionary-based cracking software. You use dictionaries to help you make educated guesses about passwords, dramatically reducing the amount of time needed to crack them. Here are the top 35 passwords used by users of Hookers.nl:
What we are seeing is that the answer to whether bcrypt is secure or not relies on factors that can have little to do with bcrypt itself. What really counts are the Work Factor and the complexity of your password. Since we know Landlord Credit Bureau doesn’t enforce any special password schemes resembling the type recommended by groups like NIST, it’s safe to assume there are plenty of accounts which would be vulnerable to this kind of attack.
Let’s assume a fairly robust Work Factor for LCB though. Ashley Madison used a work factor of 12 back in 2015 and needed to be cracked through other software exploits. How would a Work Factor 12 site stand up, even with regular PCI compliant passwords?
Back in 2016 the benchmark was 641 days to break a Work Factor 12 password using an 8xGPU cluster. It could manage just over 900 attempts per second. We’ve shown that FPGAs give about 4x the performance over GPUs so using a single FGPA we should expect to reduce that 641 days to about 160. Add 17 more FPGAs and you can see how that time is going to keep shrinking until it’s down to just a few short days. Given current technology I’d consider even Work Factor 12 to be vulnerable to brute force at this point and that capability will only increase as the technology improves.
In the case of the Landlord Credit Bureau, let’s highlight some risk factors:
Cryptographically strong passwords not enforced on the site
Unknown bcrypt Work Factor (anything less than 12 with their password schema should be considered easily crackable)
No two-factor authentication
Potential vulnerabilities in other aspects of the LCB infrastructure that could be exploited in order to reveal passwords and other data
The currently published Security Policy of the Landlord Credit Bureau doesn’t do anything to address these risk factors, nor does it reveal any kind of corporate quality system that would address things like routine vulnerability testing. Adoption of standards like PCI DSS and ISO 27001 would be very welcome first steps towards a more robust and open model for data security but as we have seen, even these standards have been found to be lacking when it comes to meeting the challenges of the modern Internet.
Next time we will take a look at the rest of the Security Policy and examine the claims being made.
This evening we received an amended notice of civil claim from Blakes law firm on behalf of Zac Killam and the Landlord Credit Bureau. Note that it is from Iris Fischer, the new lawyer leading the case, and not Laura Cundari who originally launched the suit. Why the change? Never did get an answer on that.
All the copyright infringement claims have been dropped.
They have dramatically decided to label our website, blog and Twitter account the Unlawful Blog, Unlawful Twitter Account.
They added the Twitter account, which was not active prior to the first lawsuit.
They’ve added a whole bunch of “defamatory statements” to the list of issues they take with the blog. Literally every single one of the things they take issue with is demonstrably true or well within fair commentary.
They now claim that we have a “vendetta” against Landlord Credit Bureau and Zac Killam. Why? What prompted such a vendetta? They don’t even bother to speculate, they just assert it and run with it.
It’s also notable that Mr. Killam has not opted to sue QP Briefing or The Hamilton Spectator. I have a feeling he’s not going to sue Canadaland either.
NOTE: Since publishing this post last week, Landlord Credit Bureau has removed all references to being EI3PA compliant from its website without noting the change. So were they mistaken about being EI3PA compliant or did they deliberately mislead the public about their practices?
Here is what the FAQ section looks like now:
While reviewing a copy of the Frequently Asked Questions section of the Landlord Credit Bureau site for tenants something jumped out at me immediately when they began talking about data security.
A longtime concern of mine has been how LCB stores its data and to what extent it is compliant with existing standards for Information Technology security in general and sensitive payment data in particular. To date I’ve only seen vague claims of compliance with “regulatory bodies”.
With the discovery of the FAQ that LCB publishes on the tenant member section of its website we’ve found new claims they’ve made about data security that are extremely troubling. Let’s take a look.
Experian is a competitor to Equifax and TransUnion. Notably they have not operated in Canada since April of 2009.
So why is Landlord Credit Bureau saying they are EI3PA compliant when this certification is only for doing business with Experian and they don’t do business with Experian? When it’s impossible for them to be doing business with Experian in Canada? Great questions. Presumably only Zac Killam knows how they are making this very specific claim of data security certification which is obviously not correct.
LCB is in business with Equifax in both its Canadian and US operations so they can’t even claim it’s for the US side of the business. It’s truly baffling.
Since we know they are doing business with Equifax, let’s just examine the data security standards that we know Equifax claims compliance with. We know a lot about the data protection standards Equifax has implemented because of an investigation into their security practices by the Privacy Commissioner of Canada following a data breach that saw the personal data of 143 million Equifax customers hacked in 2017.
Here is a summary of the oversight mechanisms Equifax reported to the Privacy Commissioner:
The two main data security compliance models used by Equifax are ISO 27001, which is an Information Security Management certification and PCI DSS which is a certification system for payment card data security. No mention of EI3PA because it’s not a standard used by anyone but Experian.
What is true is that the EI3PA is basically the same program as PCI DSS, just tweaked for credit reporting and exclusive to Experian data aggregators. What is also true is that the Privacy Commissioner found that ISO 27001 compliance and PCI DSS compliance was insufficient in the case of Equifax for protecting customer data.
If we are expecting Landlord Credit Bureau to be at least as secure as Equifax – and we should considering they are handling the same kind of sensitive personal information and credit data – then at a minimum we’d expect to see ISO 27001 and PCI DSS certifications. So when LCB claims to be compliant in a security standard that is vendor-specific for a vendor that doesn’t even operate in this country I start to get very worried about the actual integrity of their data because it sounds an awful lot like they are just making it up. If they are willing to make up their data security compliance regime, what do you think their actual security practices are like?
Unfortunately the concerns don’t end here. Recall that their statement in the FAQ said that they “won’t go into detail here because we don’t want to share with hackers”. Not only is this just a really weird thing for a company tasked with storing credit information about you to say, it’s also the opposite of what open information security standards are about and not compliant with even the EI3PA program they claim to be compliant with.
Compliance regimes like ISO or PCI DSS rely on openly published standards that anyone with the time and inclination can go look up and evaluate for themselves. Obscurity is not security and thinking you are protecting yourself by not openly sharing your security standards is not an industry best practice, it’s a naive delusion.
The fact is, what security professionals the world over rely on is openly published and vetted standards and practices that are frequently presented as challenges to hackers. There are no big secrets in this world, just people who are diligent in their tradecraft and people who aren’t.
Worse in this case though is that LCB claims this EI3PA certification and part of getting this certification is having a detailed, openly published security policy.
Here is what Landlord Credit Bureau has published in public about their data security policies:
None of this even mentions EI3PA or any other kind of data security certification.
Looking for more evidence of this EI3PA compliance I take note of the following from the RSI security websites breakdown of the standard:
The Landlord Credit Bureau tenant and landlord portal do not support multi-factor authentication. So once again, even if EI3PA certification was something relevant to LCB operations in Canada they would still not be compliant with the standard.
Another red flag that comes up is the EI3PA standard for avoiding vendor-supplied defaults. This is a common information security practice as many hardware and software vendors provide their wares with a bunch of default settings already enabled. Part of the discipline of information security is keeping these defaults from being exploited. This often involves disabling or otherwise altering the default setting so it cannot be easily exploited.
If you visit the following URL on the Landlord Credit Bureau website you will be taken to a login page that allows administrator access to the site (https://landlordcreditbureau.ca/wp-login.php). The LCB site is run by popular content management software called WordPress and they provide this URL as one of several defaults for admin logins.
Once again we can see that Landlord Credit Bureau is not compliant with the EI3PA certification standard. Nor would any of these issues see them in compliance with PCI DSS or ISO 27001. These observations should raise serious concerns in the minds of anyone who has their data being stored and used by Landlord Credit Bureau at this point. The Ministry of Government and Consumer Affairs needs to demand an audit into LCBs data security practices in order to restore public confidence.
As reported in The Hamilton Spectator as well as this blog, Landlord Credit Bureau had set up a secret field in their tenancy records that only other landlords can see, posing some obvious questions about how tenants can even dispute reports they aren’t able to see.
Originally, the tenant record contained a field that looked like this:
In response to the Hamilton Spectator piece, Zac Killam took to Outline.com, using the annotation feature to defend himself and his business.
In those annotations, Zac Killam addresses the question of the secret field, something he didn’t do when given the opportunity by the Spectator.
In it he defends the practice, comparing it to a landlord phoning references. This comment was made on March 25 2021.
By March 30th however, the language on the tenancy record changed:
Suddenly, the information IS shared with the tenants. Funny there’s no announcement of this big change.
Now by April 7th things have changed again and we have not one but two variant tenancy records with very different language. The first reads as follows:
Now it’s kind of difficult to tell if this field is shared between all parties or not. The language is very unclear and seems to leave things up to the landlord to ask the tenant about things reported in this field to “verify” them. Which really sounds like what LCB should be doing in the first place – sharing this field with tenants so they can see it and dispute it. Putting the onus on the landlord allows them to keep collecting and hiding this data.
Confusing the matter further is the existence of another sample tenancy record with much different language once again:
This version tells us that by May 3rd 2021 the field once shown only to other landlords will be visible to tenants as well. Is there a reason to delay this until May 3rd? Difficult to say without knowing more but presumably it’s to give landlords some time to verify their records and ensure what they are reporting is accurate so when tenants finally see the field there should be no disputes.
It’s interesting to note the part about tenants providing consent for future landlords to pull their record. The current mechanism for ensuring a tenant has given consent to have their record pulled constitutes a checkbox where the landlord affirms they have consent. No uploading a signed consent form, just a checkbox. Scouts honour.
It should be deeply concerning that a company which is supposed to be trusted with extremely sensitive personal data that can have a huge impact on our daily lives can’t seem to settle on a major piece of corporate policy like this. It’s almost as if they’re just making it up as they go along.
In August of last year this blog started up and reported the fact that LiveWell Property Management and the Landlord Credit Bureau had an ethically dubious relationship. Zac Killam was a director of both companies.
To us this represented a serious conflict of interest – how could our landlord be expected to impartially adjudicate disputes with information reported to the Landlord Credit Bureau when he is also financially involved with the Landlord Credit Bureau? It sounded so many alarm bells in me I knew I had to get the word out.
Toronto housing lawyer Benjamin Ries had this to say of the relationship in QP Briefing:
This is what Zac Killam considers “no conflict of interest”. He holds part of a $1.35 million dollar note on the building I live in. The building he has been using to harvest data from with Landlord Credit Bureau.
When Matt Christie says he’ll “send our request to the landlord”, who does he mean exactly? Who else is there but him and Zac? How many more shell corporations will we have to turn over?
Zac talked about his “interest in a small number of rental units” but I guess didn’t think it was important to tell people that one of those “small number of rental units” happened to be the one my family lives in.
How can the Ministry of Government and Consumer Services continue to licence Mr. Killam as a credit reporting agency given all we know now about what he considers “no conflict of interest”?